Bind8 -> Bind9 Problems [FreeBSD-5]

Mark_Andrews at isc.org Mark_Andrews at isc.org
Mon Feb 3 03:06:55 UTC 2003


> Hello you all,
> 
> I get crazy, but I can't resolve the following problems...
> 
> I am/was running BIND 8.3.4-REL without problems on my home machine 
> under FreeBSD 5.0-CURRENT. Now I installed BIND 9.2.2rc1 in parallel 
> under /usr/local (BIND 8.3.4-REL resides under /usr).
> 
> First I noticed that BIND9 doesn't support the -g <group> commandline 
> switch anymore, so the startup scripts have to be changed accordingly 
> and can't be used for both versions of bind :-(
> 
> But my real problem is, that with BIND9 I cannot login as ordinary user 
> via xdm/kdm any more. The login-screen freezes for approx. 5 minutes 
> until the login succeeds. But then I cannot use xterm, there's no 
> keyboard input possible. (???) This never happened with BIND8...
> 
> It works as 'root' via xdm/kdm and it works on the console for any(!) 
> user... (???)
> 
> I switched on tracing and got the following (when logging in as ordinary 
> user via 'kdm'):
> 
> --------8><------------------------
> 
> --- debuglevel 1 ---
> 
> Feb 01 18:15:29.270 client 192.168.200.1#49211: query: . IN A
> Feb 01 18:15:29.280 createfetch: . A
> Feb 01 18:15:49.280 client 192.168.200.1#49212: query: . IN A
> Feb 01 18:15:49.280 createfetch: . A
> 
> --- debuglevel 2 ---
> 
> Feb 01 18:17:45.831 received control channel command 'trace'
> Feb 01 18:17:58.639 client 192.168.200.1#49213: query: . IN AAAA
> Feb 01 18:17:58.640 createfetch: . AAAA
> Feb 01 18:18:03.642 client 192.168.200.1#49214: query: . IN AAAA
> Feb 01 18:18:03.642 createfetch: . AAAA
> Feb 01 18:18:13.652 client 192.168.200.1#49215: query: . IN AAAA
> Feb 01 18:18:13.724 createfetch: . AAAA
> Feb 01 18:18:33.662 client 192.168.200.1#49216: query: . IN AAAA
> Feb 01 18:18:33.663 createfetch: . AAAA
> Feb 01 18:19:13.673 client 192.168.200.1#49217: query: . IN A
> Feb 01 18:19:13.673 createfetch: . A
> Feb 01 18:19:18.683 client 192.168.200.1#49218: query: . IN A
> Feb 01 18:19:18.684 createfetch: . A
> 
> --------8><------------------------

	Well the first question is what why are you getting queries
	for "." in the first place.  It looks like something is
	doing getaddrinfo("")/gethostname(".").
 
> (I did it up to debuglevel 4, but for the first posting this is long 
> enough I think :-)
> 
> I have to mention here that I've no IPv6 interfaces configured nor do I 
> have IPv6 support compiled into the kernel. Why the AAAA queries?

	Because you really do need to make both AAAA and A queries
	when following a search list otherwise getaddrinfo("foo")
	can result in addresses that refer to different machines
	depending apon the flags.
 
> OK, then, it queries the root-domain so I compared the behaviour of 
> BIND8 and BIND9:
> 
> I did a 'dig .' with BIND8...
> 
> ; <<>> DiG 8.3 <<>> . 
> ;; res options: init recurs defnam dnsrch
> ;; got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; QUERY SECTION:
> ;;      ., type = A, class = IN
> 
> ;; Total query time: 1 msec
> ;; FROM: current.best-eng.de to SERVER: default -- 192.168.200.1
> ;; WHEN: Sun Feb  2 09:09:53 2003
> ;; MSG SIZE  sent: 17  rcvd: 17
> 
> ... and with BIND9
> 
> ; <<>> DiG 9.2.2rc1 <<>> .
> ;; global options:  printcmd
> ;; connection timed out; no servers could be reached
> 
> *With* an external connection I got:
> 
> ; <<>> DiG 9.2.2rc1 <<>> .
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23948
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;.                              IN      A
> 
> ;; AUTHORITY SECTION:
> .                       10764   IN      SOA     A.ROOT-SERVERS.NET. NSTL
> D.VERISIGN-GRS.COM. 2003020101 1800 900 604800 86400
> 
> ;; Query time: 1 msec
> ;; SERVER: 192.168.200.1#53(192.168.200.1)
> ;; WHEN: Sun Feb  2 09:15:52 2003
> ;; MSG SIZE  rcvd: 92
> 
> so the query was forwarded and answered.
> 
> But why isn't it working without INet-connection any more? I have the 
> feeling that I'm close to the solution but I can't see it...

	Because the client is timing out before named gives up.
 
> What is my 'named.root' good for? The root-servers are noticed there...

	It's to provide hints as to where the root servers are.  It
	isn't used to answer queries but to find out where to get
	answers from.

	If you want answers from the root zone when disconnected from the
	net then you need to have a local copy of the root zone.  The
	same is true for any other zone.
 
> Finally. I include my 'named.conf' here, but I assume it's correct - at 
> least for BIND8 it *is* obviously correct...

	It's also correct for BIND 9.

	You can work around this problem by making your server a
	slave of ".".  A number of root servers allow "." to be
	transfered.  You can also get via ftp in which case you
	would make yourself a master.  "notify no;" is *very*
	important to prevent your nameserver sending unnecessary
	NOTIFY requests to the roots.  This replaces the root
	hints zone.

	zone "." {
		type slave;
		masters {
			 192.5.5.241;	// f.root-servers.net
		};
		file "root.db";
		notify no;		// don't send notify requests
	};

	Note 1. the jury is still out on if this causes more or less load
	on the root servers than using a hints zone.

	Note 2. if you have multiple server only one should do this.  The
	other servers should tranfer from this servers.

	Mark
 
> --------8><------------------------
> 
> // $FreeBSD: src/etc/namedb/named.conf,v 1.13 2002/11/26 07:55:44 ume 
> Exp $
> //
> 
> options {
>         directory "/etc/namedb";
>         pid-file "/var/run/named/pid";
>         listen-on {
>             192.168.200.1;
>             127.0.0.1;
>         };
> 
>         forward only;
> 
>         forwarders {
>                 213.73.102.1;
>                 62.50.1.159;
>         };
> 
>         /* Do not allow any zone transfers */
>         allow-transfer { none; };
> 
>         /* This is a local Server only */
>         allow-query {
>                 192.168.200.0/24;
>                 127.0.0.0/8;
>         };
> 
> };
> 
> zone "." {
>         type hint;
>         file "named.root";
> };
> 
> zone "0.0.127.in-addr.arpa" {
>         type master;
>         file "localhost.rev";
> };
> 
> // RFC 3152
> 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" 
> {
>         type master;
>         file "localhost-v6.rev";
> };
> 
> // RFC 1886 -- deprecated
> 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.INT" 
> {
>         type master;
>         file "localhost-v6.rev";
> };
> 
> 
> key DHCP_UPDATER {
> algorithm HMAC-MD5.SIG-ALG.REG.INT;
> secret xxxxxxxxxxxxxxxxxxxxxxxxxx;
> };
> 
> zone "best-eng.de" {
>         type master;
>         file "db.best-eng";
>         allow-update {
>             key DHCP_UPDATER;
>             192.168.200.0/24;
>         };
> };
> 
> zone "200.168.192.in-addr.arpa" {
>         type master;
>         file "db.192.168.200";
>         allow-update {
>             key DHCP_UPDATER;
>             192.168.200.0/24;
>         };
> };
> 
> --------8><------------------------
> 
> Can anyone please help me?
> -- 
> Ciao/BSD - Matthias
> 
> Matthias Schuendehuette <msch [at] snafu.de>, Berlin (Germany)
> Powered by FreeBSD 5.0-CURRENT
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org


More information about the bind-users mailing list