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