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