[opensuse] bind DNS: forwarders not working unless named is restarted
Hi 12.1 in HA setup with 2 DNS corresponding to two replicating DC's. DC1 192.168.1.2, DC2 192.168.1.3 Our internal zones are loaded fine after boot, but hitting any of the forwarders pointing out to Internet fails. Here is the line in /etc/named.conf on DC1: forwarders { 217.70.240.135; 217.70.70.136; 192.168.1.3 }; and on DC2: forwarders { 217.70.240.135; 217.70.70.136; 192.168.1.2 }; Both the forwarders are online and nslookup-able e.g.: lynn@hh1:~> nslookup
217.70.240.135 Server: 192.168.1.2 Address: 192.168.1.2#53
Non authoritative answer: 135.240.70.217.in-addr.arpa name = dns1.dragonet.es. Authoritative answers can be found from: 240.70.217.in-addr.arpa nameserver = dns1.dragonet.es. 240.70.217.in-addr.arpa nameserver = dns2.dragonet.es. dns1.dragonet.es internet address = 217.70.240.135 dns2.dragonet.es internet address = 217.70.240.136 But I have to restart named for the forwarders to kick in. I've tried enabling forward first; but no difference. Is it possible to have the forwarders consulted without having to restart? Thanks, L x Jul 2 17:00:17 hh3 named[3687]: starting BIND 9.8.1-P1 -u named Jul 2 17:00:17 hh3 named[3687]: built with '--prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--localstatedir=/var' '--libdir=/usr/lib' '--includedir=/usr/include/bind' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-openssl' '--enable-threads' '--with-libtool' '--enable-runidn' '--with-libxml2' '--with-dlz-mysql' '--with-dlz-ldap' 'CFLAGS=-fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -DNO_VERSION_DATE -fno-strict-aliasing' 'LDFLAGS=-L/usr/lib' Jul 2 17:00:17 hh3 named[3687]: adjusted limit on open files from 4096 to 1048576 Jul 2 17:00:17 hh3 named[3687]: found 1 CPU, using 1 worker thread Jul 2 17:00:17 hh3 named[3687]: using up to 4096 sockets Jul 2 17:00:17 hh3 named[3687]: loading configuration from '/etc/named.conf' Jul 2 17:00:17 hh3 named[3687]: reading built-in trusted keys from file '/etc/bind.keys' Jul 2 17:00:17 hh3 named[3687]: using default UDP/IPv4 port range: [1024, 65535] Jul 2 17:00:17 hh3 named[3687]: using default UDP/IPv6 port range: [1024, 65535] Jul 2 17:00:17 hh3 named[3687]: listening on IPv4 interface lo, 127.0.0.1#53 Jul 2 17:00:17 hh3 named[3687]: listening on IPv4 interface eth1, 192.168.1.2#53 Jul 2 17:00:17 hh3 named[3687]: generating session key for dynamic DNS Jul 2 17:00:17 hh3 named[3687]: sizing zone task pool based on 3 zones Jul 2 17:00:17 hh3 named[3687]: Loading 'AD DNS Zone' using driver dlopen Jul 2 17:00:18 hh3 named[3687]: samba_dlz: started for DN DC=hh3,DC=site Jul 2 17:00:18 hh3 named[3687]: samba_dlz: starting configure Jul 2 17:00:18 hh3 named[3687]: samba_dlz: configured writeable zone 'hh3.site' Jul 2 17:00:18 hh3 named[3687]: samba_dlz: configured writeable zone '_msdcs.hh3.site' Jul 2 17:00:18 hh3 named[3687]: set up managed keys zone for view _default, file '/var/lib/named/dyn//managed-keys.bind' Jul 2 17:00:18 hh3 named[3687]: Warning: 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 0.IN-ADDR.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 127.IN-ADDR.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 254.169.IN-ADDR.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 2.0.192.IN-ADDR.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 100.51.198.IN-ADDR.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 113.0.203.IN-ADDR.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: D.F.IP6.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 8.E.F.IP6.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 9.E.F.IP6.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: A.E.F.IP6.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: B.E.F.IP6.ARPA Jul 2 17:00:18 hh3 named[3687]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA Jul 2 17:00:18 hh3 named[3687]: command channel listening on 127.0.0.1#953 Jul 2 17:00:18 hh3 named[3687]: couldn't add command channel ::1#953: address not available Jul 2 17:00:18 hh3 named[3687]: zone 0.0.127.in-addr.arpa/IN: loaded serial 42 Jul 2 17:00:18 hh3 named[3687]: zone localhost/IN: loaded serial 42 Jul 2 17:00:18 hh3 named[3687]: managed-keys-zone ./IN: loaded serial 0 Jul 2 17:00:18 hh3 named[3660]: Starting name server BIND ..done Jul 2 17:00:18 hh3 named[3687]: running -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday 02 July 2012, lynn wrote:
Hi 12.1 in HA setup with 2 DNS corresponding to two replicating DC's. DC1 192.168.1.2, DC2 192.168.1.3
Our internal zones are loaded fine after boot, but hitting any of the forwarders pointing out to Internet fails. Here is the line in /etc/named.conf on DC1: forwarders { 217.70.240.135; 217.70.70.136; 192.168.1.3 }; and on DC2: forwarders { 217.70.240.135; 217.70.70.136; 192.168.1.2 };
Both the forwarders are online and nslookup-able e.g.: lynn@hh1:~> nslookup
217.70.240.135
Server: 192.168.1.2 Address: 192.168.1.2#53
Non authoritative answer: 135.240.70.217.in-addr.arpa name = dns1.dragonet.es.
Authoritative answers can be found from: 240.70.217.in-addr.arpa nameserver = dns1.dragonet.es. 240.70.217.in-addr.arpa nameserver = dns2.dragonet.es. dns1.dragonet.es internet address = 217.70.240.135 dns2.dragonet.es internet address = 217.70.240.136
But I have to restart named for the forwarders to kick in. I've tried enabling
You mean it does not work right after reboot? I've had similar problems in past because of several reasons, for example if network setup was not really completed before starting named. I thought I got everything solved but yesterday I noticed again a broken named on one of my 11.4 boxes. Maybe the latest bind update two weeks ago did something bad? Anyway to avoid problems with incomplete network setup etc. you could do RUN_PARALLEL="no" in /etc/sysconfig/boot (requires sysvinit). Then see whether the problem still persists. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/07/12 11:01, Ruediger Meier wrote:
On Monday 02 July 2012, lynn wrote:
But I have to restart named for the forwarders to kick in. I've tried enabling
You mean it does not work right after reboot? I've had similar problems in past because of several reasons, for example if network setup was not really completed before starting named. I thought I got everything solved but yesterday I noticed again a broken named on one of my 11.4 boxes. Maybe the latest bind update two weeks ago did something bad?
Anyway to avoid problems with incomplete network setup etc. you could do RUN_PARALLEL="no" in /etc/sysconfig/boot (requires sysvinit). Then see whether the problem still persists.
cu, Rudi
Hi Rudi This is 12.1 systemd with: rpm -q bind bind-9.8.1P1-4.11.1.i586 and ls -l /usr/sbin/named -rwxr-xr-x 1 root root 560484 Jun 5 12:17 /usr/sbin/named June 5th. I've tried putting rcnamed restart in /etc/boot.local but it seems that the network is still not up when boot.local is run. ifup eth1 rcnamed restart is a little more reliable, but I need something where someone can just press the switch and reboot without me having to be called out. I can't risk changing to sysvinit until we get some downtime, August maybe. Is this too minor an issue for a buzilla? L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn wrote:
On 03/07/12 11:01, Ruediger Meier wrote:
On Monday 02 July 2012, lynn wrote:
But I have to restart named for the forwarders to kick in. I've tried enabling
You mean it does not work right after reboot? I've had similar problems in past because of several reasons, for example if network setup was not really completed before starting named. I thought I got everything solved but yesterday I noticed again a broken named on one of my 11.4 boxes. Maybe the latest bind update two weeks ago did something bad?
Anyway to avoid problems with incomplete network setup etc. you could do RUN_PARALLEL="no" in /etc/sysconfig/boot (requires sysvinit). Then see whether the problem still persists.
cu, Rudi
Hi Rudi This is 12.1 systemd with: rpm -q bind bind-9.8.1P1-4.11.1.i586 and ls -l /usr/sbin/named -rwxr-xr-x 1 root root 560484 Jun 5 12:17 /usr/sbin/named June 5th.
I've tried putting rcnamed restart in /etc/boot.local but it seems that the network is still not up when boot.local is run. ifup eth1 rcnamed restart is a little more reliable, but I need something where someone can just press the switch and reboot without me having to be called out.
I can't risk changing to sysvinit until we get some downtime, August maybe.
Is this too minor an issue for a buzilla? L x
If bind _genuinely_ requires the network to be up to complete start-up but doesn't wait for the network, yes, that is a bug. The fix would appear to be to amend <something> in the systemd service file to make bind wait for the network to be started. -- Per Jessen, Zürich (18.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/07/12 12:11, Per Jessen wrote:
lynn wrote:
On 03/07/12 11:01, Ruediger Meier wrote:
On Monday 02 July 2012, lynn wrote:
If bind _genuinely_ requires the network to be up to complete start-up but doesn't wait for the network, yes, that is a bug. The fix would appear to be to amend <something> in the systemd service file to make bind wait for the network to be started.
Hi Two of the forwarders point to our ISP's DNS servers. No one can browse until I have restarted named. I can reproduce this on both DC's. I don't know enough about systemd to be able to tell at what stage the network is started but the init script states that network is required: ### BEGIN INIT INFO # Provides: named # Required-Start: $network $remote_fs $syslog # Required-Stop: $network $remote_fs $syslog # Should-Start: ldap # Should-Stop: ldap # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: Domain Name System (DNS) server, named # Description: Berkeley Internet Name Domain (BIND) implementation of the # Domain Name System (DNS) server named. ### END INIT INFO L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-07-03 11:56, lynn wrote:
/etc/boot.local but it seems that the network is still not up when boot.local is run.
You do know that boot.local is not supported by systemd, you have to add the support yourself. And the implementations I have seen do not guarantee the point where it runs: not at the very start of the boot sequence, not at the end... You could use cron with an @reboot line, maybe it runs later; if not, simply add a delay in your script or call line. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/y0n0ACgkQIvFNjefEBxo06wCeOX7OBS6D26fIUbquQQjCDs3V kXEAnjWLJEPO9ryUeKbRU6QJGwrojpHJ =BOmN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/07/12 13:07, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-03 11:56, lynn wrote:
/etc/boot.local but it seems that the network is still not up when boot.local is run.
You do know that boot.local is not supported by systemd, you have to add the support yourself.
Hi Carlos, hi everyone No. boot.local works fine with systemd. Just add your commands to /etc/init.d/boot.local and it runs them. I can't find out _when_ it runs them however. And the implementations I have seen do not
guarantee the point where it runs: not at the very start of the boot sequence, not at the end...
You could use cron with an @reboot line, maybe it runs later; if not, simply add a delay in your script or call line.
Yeah, I know. I just get the feeling we're losing it a bit at the server end. On peanut-gallery 12.04 Linux, the forwarders just work. With us, they don't. I know it's niggles and I know that there are workarounds. In the current situation, the last thing I want to do is distract the dev's from their 12.2 work. I think that for openSUSE servers, 11.4 evergreen or 12.1 with sysvinit is the way to go. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn wrote:
On 03/07/12 13:07, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-03 11:56, lynn wrote:
/etc/boot.local but it seems that the network is still not up when boot.local is run.
You do know that boot.local is not supported by systemd, you have to add the support yourself.
Hi Carlos, hi everyone
No. boot.local works fine with systemd. Just add your commands to /etc/init.d/boot.local and it runs them. I can't find out _when_ it runs them however.
And the implementations I have seen do not
guarantee the point where it runs: not at the very start of the boot sequence, not at the end...
You could use cron with an @reboot line, maybe it runs later; if not, simply add a delay in your script or call line.
Yeah, I know. I just get the feeling we're losing it a bit at the server end. On peanut-gallery 12.04 Linux, the forwarders just work. With us, they don't. I know it's niggles and I know that there are workarounds.
Lynn, I guess you've looked at _how_ they don't work? That is, is forwarding attempted, but fails or is it not attempted at all? The former would indicate a network issue, the latter a bind issue (which I tend to think is unlikely).
I think that for openSUSE servers, 11.4 evergreen or 12.1 with sysvinit is the way to go.
With updates, systemd does end up working quite well, but I certainly wouldn't install 12.1 for anything with a long life expectancy. -- Per Jessen, Zürich (21.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-07-03 19:24, Per Jessen wrote:
With updates, systemd does end up working quite well, but I certainly wouldn't install 12.1 for anything with a long life expectancy.
I would not be surprised at services that need network starting up before network is really working, and thus failing. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/zMqYACgkQIvFNjefEBxqBAgCgyjScFsmB/3N3jdtjUsOPAF86 oagAn0LAXSZvveZ6qLUGnVHNdwUeJd/Q =evoV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/07/12 19:24, Per Jessen wrote:
lynn wrote:
On 03/07/12 13:07, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-03 11:56, lynn wrote:
Lynn, I guess you've looked at _how_ they don't work? That is, is forwarding attempted, but fails or is it not attempted at all?
Yes. /var/log/messages gives a clean bind startup, Our dynamic DLZ zones are loaded and work perfectly, Replication of the internal DNS partitions for AD between our two internal bind9 servers is also fine. If I add the forwarders to /etc/resolv.conf via Yast and remove them from /etc/named.conf, all is also OK. The
former would indicate a network issue, the latter a bind issue (which I tend to think is unlikely).
bind issues with openSUSE are not uncommon. e.g. there is still a bug in the latest version whereby the working directory is not writeable after a default install.
With updates, systemd does end up working quite well, but I certainly wouldn't install 12.1 for anything with a long life expectancy.
Quite often you have no choice. One has to go in and make the best of what is already there. There are NFS and Kerberos compatibility issues between 11.4 and 12.1. 12.1 on everything works. I'm sure that 11.4 on everything works too. Just not forwarding via named. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn wrote:
On 03/07/12 19:24, Per Jessen wrote:
lynn wrote:
On 03/07/12 13:07, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-03 11:56, lynn wrote:
Lynn, I guess you've looked at _how_ they don't work? That is, is forwarding attempted, but fails or is it not attempted at all?
Yes. /var/log/messages gives a clean bind startup, Our dynamic DLZ zones are loaded and work perfectly, Replication of the internal DNS partitions for AD between our two internal bind9 servers is also fine. If I add the forwarders to /etc/resolv.conf via Yast and remove them from /etc/named.conf, all is also OK.
So which one is it - a) is forwarding attempted, but fails or b) is it not attempted at all? -- Per Jessen, Zürich (20.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/07/12 20:31, Per Jessen wrote:
lynn wrote:
On 03/07/12 19:24, Per Jessen wrote:
lynn wrote:
On 03/07/12 13:07, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-03 11:56, lynn wrote:
Lynn, I guess you've looked at _how_ they don't work? That is, is forwarding attempted, but fails or is it not attempted at all?
Yes. /var/log/messages gives a clean bind startup, Our dynamic DLZ zones are loaded and work perfectly, Replication of the internal DNS partitions for AD between our two internal bind9 servers is also fine. If I add the forwarders to /etc/resolv.conf via Yast and remove them from /etc/named.conf, all is also OK.
So which one is it -
a) is forwarding attempted, but fails or b) is it not attempted at all?
Without a wireshark (next step I suppose, was just hoping someone else had come across this before and had a solution), I'd go for b. From a cold start, booting DC1 and restarting named gets us out. Before the restart, the domain admin can get tickets. So internal DNS is working fine, otherwise Kerberos would throw a wobbly. A subsequent boot of DC2 and a deliberate failover on DC1 maintains the forwarders. I can't reproduce this on Ubuntu LTS and need to be sure that this is not an openSUSE issue before I dare go anywhere near the samba list. To get this far takes. . . L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn wrote:
On 03/07/12 20:31, Per Jessen wrote:
So which one is it -
a) is forwarding attempted, but fails or b) is it not attempted at all?
Without a wireshark (next step I suppose, was just hoping someone else had come across this before and had a solution), I'd go for b.
Here's the thing - whether or not forwarding is working, the name lookup should work. Forwarding is just a way of pointing bind to some "upper" name-servers; without forwarding, bind will still do the lookup, just directly. I guess you know forwarding is broken because your queries aren't forwarded to the _right_ nameservers? I mean, you have a special reason for needing to use the dragonet.es nameservers? I think it would be good to verify if forwarding happens or not (use tcpdump) and then do a "dig <something>", then "dig +trace <something>" that will require forwarding. That ought to give us something to start on. -- Per Jessen, Zürich (17.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/12 07:57, Per Jessen wrote:
lynn wrote:
On 03/07/12 20:31, Per Jessen wrote:
Hi Per, hi everyone
I guess you know forwarding is broken because your queries aren't forwarded to the _right_ nameservers? I mean, you have a special reason for needing to use the dragonet.es nameservers?
Only that it would relieve our own servers.
I think it would be good to verify if forwarding happens or not (use tcpdump) and then do a "dig <something>", then "dig +trace <something>" that will require forwarding. That ought to give us something to start on.
It looks as if our servers are doing it all (192.168.1.2 is the DNS on DC1): dig google.es ; <<>> DiG 9.8.1-P1 <<>> google.es ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2680 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;google.es. IN A ;; ANSWER SECTION: google.es. 130 IN A 74.125.230.95 google.es. 130 IN A 74.125.230.87 google.es. 130 IN A 74.125.230.88 ;; AUTHORITY SECTION: google.es. 86230 IN NS ns1.google.com. google.es. 86230 IN NS ns2.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 345551 IN A 216.239.32.10 ns2.google.com. 345551 IN A 216.239.34.10 ;; Query time: 17 msec ;; SERVER: 192.168.1.2#53(192.168.1.2) ;; WHEN: Wed Jul 4 10:48:42 2012 ;; MSG SIZE rcvd: 153 dig +trace google.es ; <<>> DiG 9.8.1-P1 <<>> +trace google.es ;; global options: +cmd . 516050 IN NS m.root-servers.net. . 516050 IN NS h.root-servers.net. . 516050 IN NS f.root-servers.net. . 516050 IN NS d.root-servers.net. . 516050 IN NS c.root-servers.net. . 516050 IN NS e.root-servers.net. . 516050 IN NS g.root-servers.net. . 516050 IN NS k.root-servers.net. . 516050 IN NS l.root-servers.net. . 516050 IN NS j.root-servers.net. . 516050 IN NS b.root-servers.net. . 516050 IN NS a.root-servers.net. . 516050 IN NS i.root-servers.net. ;; Received 436 bytes from 192.168.1.2#53(192.168.1.2) in 226 ms es. 172800 IN NS ns3.nic.fr. es. 172800 IN NS f.nic.es. es. 172800 IN NS ns15.communitydns.net. es. 172800 IN NS ns-ext.nic.cl. es. 172800 IN NS ns1.cesca.es. es. 172800 IN NS sns-pb.isc.org. es. 172800 IN NS a.nic.es. ;; Received 453 bytes from 192.112.36.4#53(192.112.36.4) in 297 ms google.es. 86400 IN NS ns2.google.com. google.es. 86400 IN NS ns1.google.com. ;; Received 73 bytes from 194.69.254.1#53(194.69.254.1) in 227 ms google.es. 300 IN A 74.125.230.87 google.es. 300 IN A 74.125.230.88 google.es. 300 IN A 74.125.230.95 ;; Received 75 bytes from 216.239.34.10#53(216.239.34.10) in 100 ms /etc/named.conf options { directory "/var/lib/named"; managed-keys-directory "/var/lib/named/dyn/"; forwarders { 217.70.240.135; 217.70.240.136; 192.168.1.3; }; listen-on-v6 { none; }; notify no; tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab"; }; zone "." in { type hint; file "root.hint"; }; zone "localhost" in { type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.0.0.zone"; }; include "/etc/named.conf.include"; include "/usr/local/samba/private/named.conf"; named startup: Jul 4 11:04:34 hh1 named[3188]: starting BIND 9.8.1-P1 -u named Jul 4 11:04:34 hh1 named[3188]: built with '--prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--localstatedir=/var' '--libdir=/usr/lib' '--includedir=/usr/include/bind' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-openssl' '--enable-threads' '--with-libtool' '--enable-runidn' '--with-libxml2' '--with-dlz-mysql' '--with-dlz-ldap' 'CFLAGS=-fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -DNO_VERSION_DATE -fno-strict-aliasing' 'LDFLAGS=-L/usr/lib' Jul 4 11:04:34 hh1 named[3188]: adjusted limit on open files from 4096 to 1048576 Jul 4 11:04:34 hh1 named[3188]: found 1 CPU, using 1 worker thread Jul 4 11:04:34 hh1 named[3188]: using up to 4096 sockets Jul 4 11:04:34 hh1 named[3188]: loading configuration from '/etc/named.conf' Jul 4 11:04:34 hh1 named[3188]: reading built-in trusted keys from file '/etc/bind.keys' Jul 4 11:04:34 hh1 named[3188]: using default UDP/IPv4 port range: [1024, 65535] Jul 4 11:04:34 hh1 named[3188]: using default UDP/IPv6 port range: [1024, 65535] Jul 4 11:04:35 hh1 named[3188]: listening on IPv4 interface lo, 127.0.0.1#53 Jul 4 11:04:35 hh1 named[3188]: listening on IPv4 interface eth1, 192.168.1.2#53 Jul 4 11:04:35 hh1 named[3188]: generating session key for dynamic DNS Jul 4 11:04:35 hh1 named[3188]: sizing zone task pool based on 3 zones Jul 4 11:04:35 hh1 named[3188]: Loading 'AD DNS Zone' using driver dlopen Jul 4 11:04:35 hh1 named[3188]: samba_dlz: Unknown parameter encountered: "wide links" Jul 4 11:04:35 hh1 named[3188]: samba_dlz: Ignoring unknown parameter "wide links" Jul 4 11:04:35 hh1 named[3188]: samba_dlz: started for DN DC=hh3,DC=site Jul 4 11:04:35 hh1 named[3188]: samba_dlz: starting configure Jul 4 11:04:35 hh1 named[3188]: samba_dlz: configured writeable zone 'hh3.site' Jul 4 11:04:35 hh1 named[3188]: samba_dlz: configured writeable zone '_msdcs.hh3.site' Jul 4 11:04:35 hh1 named[3188]: set up managed keys zone for view _default, file '/var/lib/named/dyn//managed-keys.bind' Jul 4 11:04:35 hh1 named[3188]: Warning: 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 0.IN-ADDR.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 127.IN-ADDR.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 254.169.IN-ADDR.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 2.0.192.IN-ADDR.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 100.51.198.IN-ADDR.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 113.0.203.IN-ADDR.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: D.F.IP6.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 8.E.F.IP6.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 9.E.F.IP6.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: A.E.F.IP6.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: B.E.F.IP6.ARPA Jul 4 11:04:35 hh1 named[3188]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA Jul 4 11:04:35 hh1 named[3188]: command channel listening on 127.0.0.1#953 Jul 4 11:04:35 hh1 named[3188]: couldn't add command channel ::1#953: address not available Jul 4 11:04:35 hh1 named[3188]: zone 0.0.127.in-addr.arpa/IN: loaded serial 42 Jul 4 11:04:35 hh1 named[3188]: zone localhost/IN: loaded serial 42 Jul 4 11:04:35 hh1 named[3188]: managed-keys-zone ./IN: loaded serial 0 Jul 4 11:04:35 hh1 named[3160]: Starting name server BIND ..done Jul 4 11:04:35 hh1 named[3188]: running -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn wrote:
On 04/07/12 07:57, Per Jessen wrote:
lynn wrote:
On 03/07/12 20:31, Per Jessen wrote:
Hi Per, hi everyone
I guess you know forwarding is broken because your queries aren't forwarded to the _right_ nameservers? I mean, you have a special reason for needing to use the dragonet.es nameservers?
Only that it would relieve our own servers.
Okay.
I think it would be good to verify if forwarding happens or not (use tcpdump) and then do a "dig <something>", then "dig +trace <something>" that will require forwarding. That ought to give us something to start on.
It looks as if our servers are doing it all (192.168.1.2 is the DNS on DC1):
dig google.es
[snip - worked fine]
dig +trace google.es
[snip - no forwarding happened]
/etc/named.conf options { directory "/var/lib/named"; managed-keys-directory "/var/lib/named/dyn/"; forwarders { 217.70.240.135; 217.70.240.136; 192.168.1.3; };
plus default "forward first". Looks fine. So, once you restart bind, forwarding to dragonet.es works? How does that look with "dig +trace google.es" ? -- Per Jessen, Zürich (20.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/12 11:44, Per Jessen wrote:
lynn wrote:
On 04/07/12 07:57, Per Jessen wrote:
lynn wrote:
plus default "forward first". Looks fine. So, once you restart bind, forwarding to dragonet.es works? How does that look with "dig +trace google.es" ?
Right after boot: dig google.es ; <<>> DiG 9.8.1-P1 <<>> google.es ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 49629 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;google.es. IN A ;; Query time: 9 msec ;; SERVER: 192.168.1.2#53(192.168.1.2) ;; WHEN: Wed Jul 4 19:26:46 2012 ;; MSG SIZE rcvd: 27 Next, we restart named: dig google.es ; <<>> DiG 9.8.1-P1 <<>> google.es ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58555 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;google.es. IN A ;; ANSWER SECTION: google.es. 300 IN A 74.125.230.248 google.es. 300 IN A 74.125.230.247 ;; AUTHORITY SECTION: google.es. 338357 IN NS ns3.google.com. google.es. 338357 IN NS ns1.google.com. google.es. 338357 IN NS ns2.google.com. google.es. 338357 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 334208 IN A 216.239.32.10 ns2.google.com. 334208 IN A 216.239.34.10 ns3.google.com. 334208 IN A 216.239.36.10 ns4.google.com. 334208 IN A 216.239.38.10 ;; Query time: 1143 msec ;; SERVER: 192.168.1.2#53(192.168.1.2) ;; WHEN: Wed Jul 4 19:27:52 2012 ;; MSG SIZE rcvd: 205 No forwarding is being done. Now we stop named and put the forwarder in resolv.conf: dig google.es ; <<>> DiG 9.8.1-P1 <<>> google.es ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56773 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;google.es. IN A ;; ANSWER SECTION: google.es. 300 IN A 74.125.230.247 google.es. 300 IN A 74.125.230.248 ;; AUTHORITY SECTION: google.es. 338025 IN NS ns4.google.com. google.es. 338025 IN NS ns1.google.com. google.es. 338025 IN NS ns2.google.com. google.es. 338025 IN NS ns3.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 333876 IN A 216.239.32.10 ns2.google.com. 333876 IN A 216.239.34.10 ns3.google.com. 333876 IN A 216.239.36.10 ns4.google.com. 333876 IN A 216.239.38.10 ;; Query time: 291 msec ;; SERVER: 217.70.240.135#53(217.70.240.135) ;; WHEN: Wed Jul 4 19:33:25 2012 ;; MSG SIZE rcvd: 205 Now we get to the DNS of our ISP. Our Internal DNS is not starting up at boot correctly although it shows a clean startup log and it resolves our own internal suff fine. Maybe this is the time to give up. It is not serious enough for a bugzilla. The only way I can get named to start during boot is to comment out the forwarders line. forward first doesn't work either. It always uses our internal named. I just need a way of restarting named right after boot:-( L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn wrote:
On 04/07/12 11:44, Per Jessen wrote:
lynn wrote:
On 04/07/12 07:57, Per Jessen wrote:
lynn wrote:
plus default "forward first". Looks fine. So, once you restart bind, forwarding to dragonet.es works? How does that look with "dig +trace google.es" ?
Right after boot: dig google.es
; <<>> DiG 9.8.1-P1 <<>> google.es ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 49629 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That is the real problem. I don't think this is about forwarding at all - I don't know how recursion got turned off, and I don't know how a restart will turn it back on, but that is the real problem. -- Per Jessen, Zürich (20.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Carlos E. R. -
lynn -
Per Jessen -
Ruediger Meier