BIND 8.2.1 Bug / BIND 8.1.x feature?
Mark_Andrews at isc.org
Mark_Andrews at isc.org
Tue Sep 14 23:22:21 UTC 1999
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
More information about the bind-users
mailing list