BIND 8.2.1 Bug / BIND 8.1.x feature?

Frank Miller frankm at system-associates.com
Tue Sep 14 21:46:11 UTC 1999


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




More information about the bind-users mailing list