BIND 8.2.1 Bug / BIND 8.1.x feature?

[Mark_Andrews at isc.org]

	This is perfectly understandable when you look at the credability
	of the different answer sources.

	The com servers refer you to NS.INGRAMBOOK.COM and NS2.CW.NET,
	these servers tell you that the server is NS1.INGRAMBOOK.COM
	authoritatively.

	Now what happens is that the A record for NS1.INGRAMBOOK.COM
	times out fast as it is additional data.  The nameserver then
	queries for NS1.INGRAMBOOK.COM by working back up the heirarchy
	until it find a NS RRset with A records.  This will usually be
	the COM RRset but may be the root RRset.

	Now the COM servers return the referal above.  It contains a
	different RRset to the one we have, however it also has a lower
	creadability than the existing RRset so we don't add it to the
	cache and we are back where we started.

	This could all be avoided by maintaining the delegation records
	in the parent zone.  I've cc'd the contact for INGRAMBOOK.COM
	so he can sort out the delegation.

	Jeff,
		The NS RRsets in the parent and child zone are supposed
	to be the same.  The only time when they should be different is
	when you are moving the zone to a different set of servers and
	the parent zone has not yet been updated.  At this point in time
	the child zone should contain *both* the old and the new
	nameservers.  Once the parent zone is updated you can then remove
	the old servers.

	Mark

> Chris,
> 
> I just had an issue today with a domain that was all of a sudden
> unresolvable from a root caching server, that displays the same problem
> as you described.  This system was just brought up with bind-8.2.1.
> 
> ingrambook.com:
> 
>  Domain Name: INGRAMBOOK.COM
> 
>    NS.INGRAMBOOK.COM            208.129.249.2
>    NS2.CW.NET                   204.70.57.242
> 
>         origin = ns1.ingrambook.com
>         mail addr = root.ingrambook.com
>         serial = 96100183
>         refresh = 10800 (3H)
>         retry   = 3600 (1H)
>         expire  = 604800 (1W)
>         minimum ttl = 86400 (1D)
> 
> Authoritative answers can be found from:
> ingrambook.com  nameserver = ns1.ingrambook.com
> ns1.ingrambook.com      internet address = 208.129.249.2
> 
> Now, I noted that the domain lookup would time out after talking
> to the root server.  Hmm!!!!  I'd expect to see that transpire
> again after a day, I would assume.  A server on the same network would
> succeed with the resolution.
> 
> Frank
> 
> ==========================================================================
> 
> From: chris <chris at ISC-Nospam.megabytecoffee.com>
> Date: Fri, 10 Sep 1999 13:42:02 -0700
> Subject: BIND 8.2.1 Bug / BIND 8.1.x feature?
> 
> ----------------------------------------------------------------------------
> ----
> 
> In a recent switch from BIND 8.1 to BIND 8.2 I started receiving calls
> about our resolver DNS servers not being able to resolve some domains.
> After tracking this down a bit I noticed that the domains that were
> having problems all had one thing in common.. In the zone record they
> had the IN NS lines set to some other nameservers then the ones listed
> with internic. What it looked like was happening is that if we have a
> zone, we'll call it zone.tld and with internic the nameservers are
> ns1.somecompany.tld and ns2.somecompany.tld. Their zone file looks like
> this:
> 
> $ORIGIN tld.
> zone  8640    IN      SOA     ns.zone.tld. hostmaster.zone.tld. (
>                 1999072703 288 7200 60480 8640 )
>         8640    IN      NS      ns.zone.tld.
>         8640    IN      NS      ns3.zone.tld.
>         8640    IN      MX      5 mail.zone.tld.
> $ORIGIN zone.tld.
> www    8640    IN      A       10.10.10.1
> ns1     8640    IN      CNAME   joe
> ns2     8640    IN      CNAME   john
> ns3     8640    IN      CNAME   ashle
> ns4     8640    IN      CNAME   lisa
> joe     8640    IN      CNAME   joea
> john   8640    IN      CNAME   johna
> ashle  8640    IN      CNAME   ashlea
> lisa     8640    IN      CNAME   lisaa
> johna  8640    IN      A       10.10.10.2
> joea    8640    IN      A       10.10.10.3
> ashlea  8640    IN      A       10.10.10.4
> lisaa    8640    IN      A       10.10.10.5
> 
> 
> Basically what I'm seeing is that named goes to look up www.zone.tld for
> the first time, asks the root nameserver, the root nameservers return
> that ns1.somecompany.tld is the nameserver for that domain, then named
> queries the ns and gets this zone. Once named has this zone, it notes
> that the authoritative nameservers for this domain are not really
> nsX.somecompany.tld, but they are ns and ns2.zone.tld. The zone is
> expired so named can't look up what ns.zone.tld is, so it times out.
> Normaly I would just say think to my self that the zone is set up
> wrong.. and have it fixed, but it looks as if the older versions of bind
> would allow this. Since we upgraded our resolvers they are now not able
> to look up these domains after the zone first expires, unless I restart
> named.
> 
> Has anyone see this? Does anyone know why this has changed?
> 
> - Chris
> 
> 
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org