TTL Caching

Kevin Darcy kcd at daimlerchrysler.com
Sat Feb 10 02:47:13 UTC 2001


Tim Maestas wrote:

> On Fri, 9 Feb 2001, Kevin Darcy wrote:
>
> >
> > I wonder: if an A record's TTL were *larger* than that of a CNAME which
> > pointed to it, would Microsoft's product now *increase* the CNAME's TTL to
> > make them equal? That would seem to be clearly in violation of the RFC's.
> > Maybe you could package that up as a test case, so they have to fix their
> > code anyway (which in turn might fix your *real* problem).
>
>         In this situation, the TTL's are followed, although
>         you end up with *2* entries in the resolver cache for
>         the A record, one with the TTL of the A record as passed
>         back by DNS, one with the same TTL as the CNAME.  It
>         seems the way they construct the cache, each query gets
>         it's own "section" with all the records contained in the
>         response (authority, answer, and additional) getting cached with
>         the same TTL.  Then, there is a seperate "section" with just
>         the A record, with the correct TTL.  In this situation, the
>         NS and A records contained in authority and additional sections
>         get cached with the TTL of the originally queried for CNAME.
>         It's really a big mess.

Does their server actually *answer* with both of those A records, having
identical RDATA values and different TTLs?

That would violate RFC 2181 in a big way; section 5 (suppression of duplicate
records) *and* section 5.2 (minimization of TTLs within an RRset) .


- Kevin




More information about the bind-users mailing list