Question about BIND's handling of mismatched glue

Jim Reid jim at rfc1035.com
Tue Nov 12 16:57:50 UTC 2002


    Ollie> I found the following similar post to the list from not long ago:

    Ollie>  http://marc.theaimsgroup.com/?l=bind-users&m=103292931926205&w=2

    Ollie> which suggests that the glue records in the GTLD servers
    Ollie> are 'copies' of the A records in the child zone.

Right.

    Ollie> Is this 'automatic' in the sense that if the child A RRs
    Ollie> for the glue records disappear, they will also disappear
    Ollie> from the GTLD servers by some means (i.e. GTLD servers
    Ollie> query authoritative servers at intervals), or in a looser
    Ollie> sense that they ought to match but this is not enforced? 

It's the latter. The child has to ensure that any glue held at the
parent is correct and up to date. The parent has no way of knowing
that, let alone automatically updating the info by itself.


Your posting isn't really a question about mismatched glue, although
there's a *lot* of this in the resolution of lifelinenetwork.org. One
of the servers for lifelinenetwork.org is lame and the delegation of
this zone is broken in other ways. According to the .org servers, this
zone is delegated to ns3.baiden.com and ns4.baiden.com. The latter
gives a SERVFAIL when it's queried for lifelinenetwork.org.

The baiden.com zone is badly screwed up. The com zone delegates this
to ns.adlhosting.com and ns4.baiden.com. Both of these have glue
records with the same IP address, 81.27.96.160, which is somewhat less
than clever. [A zone should have >1 name server to avoid single points
of failure.] When this IP address is queried it says the name servers
for baiden.com are ns.adlhosting.com and ns2.inetc.net. This is not
the same as the parent delegation, though fortunately there is an
overlap. Both these servers say that ns[34].baiden.com do not exist.
Since they are definitive for the baiden.com zone, their answer
"over-rules" the glue for ns[34].baiden.com in the .com zone about the
delegation of lifelinenetwork.org. [At this point I couldn't be
bothered checking the delegations, glue and NS RRsets for inetc.net
and adlhosting.com: they may well be broken too.] 

So the results someone gets from looking up lifelinenetwork.org are
unpredictable. It depends what's in your server's cache. If your
server used the referral glue to query the (bogus?) IP address for
ns4.baiden.com, it gets a SERVFAIL error as that server is not
authoritative for lifelinenetwork.org. Resolution fails. If your
server used that glue to query ns3.baiden.com, it would have got an
authoritative answer back, albeit with yet more broken NS records. So
resolution would have sort of worked. If your server had previously
queried the only baiden.com name server for ns[34].baiden.com your
server would definitely have known that ns[34].baiden.com do not exist
and should have cached that, making lifelinenetwork.org unresolvable
until the negative cache entries expire. How enchanting.

    Ollie> Presumably, I've followed the same steps that BIND ought to:

Not quite. dig +trace is your friend....

    Ollie> - get nameserver names and glue records for zone from root
    Ollie> and GTLD servers

Yup.

  Ollie> - query each such nameserver for the SOA record for the zone

No. SOA records are not looked at during resolving. Slave servers look
at them to pick up new copies of the zone. That's essentially the only
thing which looks at SOA records, except for people doing DNS
troubleshooting and maybe stuff making dynamic updates that needs the
SOA MNAME to identify where the update requests get sent.

Once a server has got glue from the parent, it has to query the glue
to get the definitive NS RRset for the delegation. One of the glue
records is chosen for this at random. For this zone, there are two
glue records. So half those queries for the NS RRset go to
ns3.baiden.com which sort of works and half go to ns4.baiden.com which
don't because it's not authoritative for lifelinenetwork.org.

    Ollie> I can't see how it's giving SERVFAIL, when at least one of 
    Ollie> the authoritative nameservers is giving correct data
    Ollie> (213.171.200.58). 

One of the servers for lifelinenetwork.org isn't authoritative for the
zone. It's *that* which is returning SERVFAIL. It's giving up because
it has resolved lifelinenetwork.org -- which is yet another error:
authoritative servers should not have recursion enabled -- and found
the delegation pointing at itself even though it doesn't know about
the zone.

    Ollie> I do notice that the glue for BAIDEN.COM nameservers
    Ollie> doesn't match what the authoritative servers say, but
    Ollie> should this matter? 

Yes, of course it matters. If it didn't matter, there would be no
need to keep the parent and child's NS RRset and glue in sync. That
would mean delegation would still work even if the servers being
delegated to knew nothing about the zones they were supposed to serve.
DNS doesn't and can't work like that.

    Ollie> Does BIND trust the glue from the GTLD servers?

Not as much as it trusts the answers it gets from the definitive
(authoritative) servers for a zone.

BTW I've CC'ed this reply to the whois contact for baiden.com and
lifelinenetwork.org, so hopefully someone there will fix these
errors.


More information about the bind-users mailing list