NS TTL Discrepancy??

[Jonathan de Boyne Pollard]

JdeBP> This is why we have "additional" section processing, "glue"
JdeBP> resource record sets, and fallback to the nearest enclosing
JdeBP> superdomain whose content DNS servers are known.  Far from
JdeBP> being recently discovered, this chicken-and-egg problem was
JdeBP> addressed in RFC 1034.

BM> If the glue A records time out of the cache before the NS 
BM> records do, the chicken-and-egg problem returns.  

In this situation, one falls back to the nearest enclosing superdomain whose
content DNS servers are known (i.e. for which both halves of the delegation
information are known).

BIND's particular problem with this, very probably what you report having
observed (since it is quite commonly triggered), is not a chicken-and-egg
problem.  It is an interaction with BIND's "credibility" rules, and it happens
when there's a mismatch between the delegation information published by the
superdomain content DNS servers and the delegation information published by
the subdomain content DNS servers.  (In detail: The situation arises when the
first half of the delegation, published by the subdomain content DNS servers,
cannot be matched up with the second half of the delegation, published by the
superdomain content DNS servers, to form the actual delegation; i.e. where the
superdomain content DNS servers publish "glue" resource records that don't
match any of the "NS" resource records that the subdomain content DNS servers
publish.)  BIND gets itself out of the chicken-and-egg situation by querying
the superdomain content DNS servers only to put itself right back into it by
refusing to believe the new delegation information that it has just received
because it isn't "credible" enough.  

Other resolving proxy DNS server softwares, without BIND's "credibility"
rules, don't have this particular problem.