Subject: timeout of glue A record

From: Gunnar Lindberg <[email-masked]>
Date: Thu, 20 Feb 2003 16:39:02 +0100 (MET)

Is this a bug or a flaw in the DNS design? Some days ago we saw:

    % dig @our-ns1 foo.bar ns
    ;; ANSWER SECTION:
    foo.bar.            23h19m44s IN NS  b.ns.foo.bar.
    foo.bar.            23h19m44s IN NS  a.ns.foo.bar.
    ;; ADDITIONAL SECTION:
    ;; None - NB  <-----------------

    % dig @our-ns2 foo.bar ns
    ;; ANSWER SECTION:
    foo.bar.            2m51s IN NS     a.ns.foo.bar.
    foo.bar.            2m51s IN NS     b.ns.foo.bar.
    ;; ADDITIONAL SECTION:
    a.ns.foo.bar.       2m51s IN A      192.n.m.1
    b.ns.foo.bar.       2m51s IN A      192.n.m.2

So, our-ns1 had a reference to their NSs (the names to be specific)
but the corresponding glue A records were missing. What happened
before to get us into this state is beyond my knowledge, but since
our-ns2 was counting down the glue A's ttl I take it they reached 0
and were simply discarded.

After 2m51s our-ns2 was able to refresh both set of records, while
our-ns1 stayed out of sync for another 23h19m44s.

It would seem reasonable to me that the DNS should not keep NS
records unless it has at least some A records to support them.

Is this a bug or design flaw?

	Gunnar Lindberg
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: bert hubert <[email-masked]>
Date: Thu, 20 Feb 2003 17:31:15 +0100

> Is this a bug or a flaw in the DNS design? Some days ago we saw:

This is something a recursor has to deal with. Check out the 'syncres.cc'
file in the PowerDNS tar.gz (http://www.powerdns.com/downloads) for one way
to deal with this problem.

It is not really a bug in DNS design, it is a resolver challenge. Different
implementations solve it in different ways. One of the hardest problems is
to make sure that you don't end up in a loop but break out high enough so
you get records back.

DJB has some notes on this somewhere on http://cr.yp.to/djbdns/notes.html
which describe how his software and BIND solve this problem.

Regards,

bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Rob Austein <[email-masked]>
Date: Thu, 20 Feb 2003 11:52:39 -0500

> records unless it has at least some A records to support them.

The resolver has to detect and recover from this situation.  One way
or another, the recovery involves lowering the NS TTLs (either
explicitly, or just by realizing that it has gotten into this trap and
issuing a query for the NS RRset even though there's an unexpired NS
RRset in the resolver's cache).
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.