bind 8.1.2 vs bind 8.2.2 on SunOS 4.1.X

Mark_Andrews at iengines.com Mark_Andrews at iengines.com
Thu Oct 28 02:10:19 UTC 1999


	I would fix the following error:

 ex-biff-boot.ftel.co.uk has CNAME and other data (invalid)

	This has always been illegal and has always been logged.
	BIND 8.2 made it a hard error which leads to SERVFAIL (rc=2)
	being returned which in turn caused the resolver to terminate
	it search.

 428.   [bug]           CNAME and other data is now a hard error.

	Mark

> [[ Platinum Beta people, I think the Sun DNS people were talking about
> shipping Bind 8.latest with Solaris 8, and 8.2.2 is the latest.  I
> suspect that Solaris machines are disproportionately likely to be on a
> net with a 4.1.X machine... ]]
> 
> I've taken my eye off the bind ball over the past twelve months, but I
> need dynamic update so I've started in on moving to 8.2.2 from (largely)
> 8.1.2.  My Auspex doesn't like it: the ancient resolver that ships with
> SunOS 4.1.4 and is used by ypserv appears to choke.
> 
> My Auspex is called ``kevin.ftel.co.uk''.  I'm using a resolv.conf that
> lists nameserver 127.0.0.1, domain ftel.co.uk and has the `hosts' yellow
> pages map empty to redirect through to the DNS.
> 
> Using 8.1.2, ``ypmatch foo hosts'' and ``ypmatch foo.ftel.co.uk hosts''
> both work.  Using 8.2.2, if I have the domain line in resolv.conf, I can
> only look up unqualified names, with it out I can only look up fqdns.
> 
> Bumping the resolver tracing up a bit, for the case of ``lookup
> foo.ftel.co.uk, domain set to ftel.co.uk'' I see a query for
> ``foo.ftel.co.uk.ftel.co.uk'' come in, for which a no is sent back, but
> I then don't see the expected foo.ftel.co.uk.co.uk and so on.  Under
> 8.1.2, I do.  I'm lost at this point, but I presume there's a difference
> in the nature of the null response which causes the resolver to give up.
> For a non-existant foo, I think the pattern is clearer.
> 
> 8.1.2:
> 
> Version = named 8.1.2 Wed Nov 18 15:24:54 GMT 1998
>         igb at kevin.ftel.co.uk:/export/staff-home/igb/src/networking/bind-8.1.2
> /src/SunOS-4.1.4-aushp/bin/named
> conffile = /etc/named.conf
> datagram from [127.0.0.1].1086, fd 36, len 48
> req: nlookup(djkfakjs.ftel.co.uk.ftel.co.uk) id 134 type=1 class=1
> req: found 'djkfakjs.ftel.co.uk.ftel.co.uk' as 'ftel.co.uk' (cname=0)
> ns_req: answer -> [127.0.0.1].1086 fd=36 id=134 size=110
> datagram from [127.0.0.1].1086, fd 36, len 43
> req: nlookup(djkfakjs.ftel.co.uk.co.uk) id 135 type=1 class=1
> req: found 'djkfakjs.ftel.co.uk.co.uk' as 'co.uk.co.uk' (cname=0)
> ns_req: answer -> [127.0.0.1].1086 fd=36 id=135 size=111
> datagram from [127.0.0.1].1086, fd 36, len 37
> req: nlookup(djkfakjs.ftel.co.uk) id 136 type=1 class=1
> req: found 'djkfakjs.ftel.co.uk' as 'ftel.co.uk' (cname=0)
> ns_req: answer -> [127.0.0.1].1086 fd=36 id=136 size=99
> Debug off
> 
> Now, I run 8.2.2 without touching any other files:
> 
> Debug level 1
> Version = named 8.2.2-REL Wed Oct 27 16:56:40 BST 1999
>         igb at kevin.ftel.co.uk:/export/staff-home/igb/src/networking/bind-8.2.2
> /src/auspex/bin/named
> conffile = /etc/named.conf
>  [[ much select debugging deleted ]]
> datagram from [127.0.0.1].1118, fd 36, len 54
> req: nlookup(dskjfhasdkjdhk.ftel.co.uk.ftel.co.uk) id 142 type=1 class=1
> req: found 'dskjfhasdkjdhk.ftel.co.uk.ftel.co.uk' as 'ftel.co.uk' (cname=0)
> ns_req: answer -> [127.0.0.1].1118 fd=36 id=142 size=54 rc=2
> datagram from [193.123.211.5].1087, fd 22, len 37
> 
> And that's it: game over from the resolver's point of view.
> 
> Any thoughts from anyone?  As things stand, this blocks a move to 8.2.2
> until I get SunOS 4.1.4 out of my network (which is happening in a few
> weeks) but I also need to test against Solari with old resolvers (I have
> production 2.4 machines).
> 
> ian
> 
> 
> 
> 
> 
> 
> 
> 
--
Mark Andrews, Internet Engines Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at iengines.com


More information about the bind-workers mailing list