TTL Caching

[Tim Maestas]

On Fri, 9 Feb 2001, Kevin Darcy wrote:

> 
> arbitrary TTL-reduction. I think Microsoft is following the letter but not
> the spirit of the RFC.

	I agree.

> 
> It also seems likely that they *misread* RFC 2181 at first and thought that
> the CNAME and A records had to have the same TTL (not true, only RRs in a
> particular RRset need to have their TTL's equalized/minimized, and in this
> case they are different RRsets). Then, after attempting a fix and failing,
> they found what they believed to be a loophole as an excuse to get out of
> fixing the code.

	Wouldn't surprise me in the least.

> 
> 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.

	MS seems to have taken RFC2181 to mean that they can cache
	any record at any value, as long as it does not exceed
	the TTL given back.
> 
> You might try bringing this up on namedroppers. Maybe the authors of
> RFC 2181 can comment as to their original intent. Given this feedback, they
> also might want to rephrase that section if the RFC is ever
> superceded/updated/clarified.

	I may do that.  Thanks, Kevin.

-Tim

> 
> 
> - Kevin
> 
> Tim Maestas wrote:
> 
> >         I've got a question regarding the caching of TTL's I'm
> >         hoping someone can clarify.  We've been arguing this with
> >         Microsoft, and low and behold, they quoted rfc2181, section 8.
> >         Specifically, this paragraph:
> >
> >   "Implementations are always free to place an upper bound on any TTL
> >    received, and treat any larger values as if they were that upper
> >    bound.  The TTL specifies a maximum time to live, not a mandatory
> >    time to live."
> >
> >         The problem is that the caching resolver in Win2k seems to be
> >         broken, caching records with CNAMEs incorrectly.  MS acknowledged
> >         this, and gave us a fix.  However it still seemed as if their
> >         implementation was broken.  We have a CNAME record, with a 3600
> >         TTL.  The canonical name it references has a 1 second TTL.  MS
> >         Win2k resolver caches both records with a 1 second TTL.  They say
> >         that acording to rfc2181 this is legal, as the TTL is really only
> >         a maximum time to live, and they are not required to cache what
> >         the DNS server returns.  Is this correct?
> >
> >         (BTW, the original problem, with unpatched Win2k, was that the
> >         A record of the canonical name referenced in the CNAME RR was
> >         cached with the TTL of the CNAME.  Basically their fix just
> >         reversed this behaviour, resulting in what I explained above).
> > -Tim
> >
> > ------------------------------------------
> > http://www.dnsconsultants.com
> > DNS and other network consulting
> > ------------------------------------------
> 
> 
> 
>