NS TTL Discrepancy??
Mark Andrews
Mark_Andrews at isc.org
Mon Mar 8 21:17:10 UTC 2004
> In article <c2ieqe$ph9$1 at sf1.isc.org>,
> Jonathan de Boyne Pollard <J.deBoynePollard at Tesco.NET> wrote:
>
> > RSP> This is what appears to be a recently discovered problem.
> >
> > It's not recently discovered, and it's not a problem.
> >
> > RSP> [...] If this happens, the DNS resolver knows to go to
> > RSP> ns1.example.com and ns2.example.com, but it now can't get
> > RSP> to them. The problem is that to get the A record for
> > RSP> ns1.example.com and ns2.example.com, the DNS resolver must
> > RSP> go to the NS records for example.com -- but, it can't get
> > RSP> to them without the A record, and you're stuck in a loop.
> >
> > This is why we have "additional" section processing, "glue" resource record
> > sets, and fallback to the nearest enclosing superdomain whose content DNS
> > servers are known. Far from being recently discovered, this chicken-and-eg
> g
> > problem was addressed in RFC 1034.
>
> If the glue A records time out of the cache before the NS records do,
> the chicken-and-egg problem returns. So you should ensure that the TTLs
> on your nameservers' A records are at least as long as the TTLs on the
> NS records.
Resolvers just have to detect this situation and ask the parent
server for the missing glue. This works until the child changes
the nameservers w/o informing the parent then you get a broken
delegation.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users
mailing list