bjorn.hellqvist at teliacompany.com
Mon Jan 21 09:08:20 UTC 2019
As an ISP we have encountered issues in the past with extremely low TTL's. (like TTL=1)
In the cases we have done some digging, the problem occurred when there is a chain of resolvers. This ended up as SERVFAIL for the customer. In the real world, chaining is not uncommon and a chain of up 4-5 resolvers have been seen. I never had the time to investigate it thoroughly by setting up a chain of 5 resolvers in our lab to see if I could replicate it.
This is why I think it should be a lower limit for the TTL. I would prefer 10 seconds. And the people that needs to do load sharing should do it in some other way.
Also was it not so that a TTL=0 was treated differently by different resolver vendors, either do not cache or cache forever?
It might not be that anymore, but I have a vague memory from the past about that. Or was that just rumors and propaganda I heard in some X vs Y war in my pre-DNS work era?
Senior System Expert (Internet Services, DNS & Automation)
> -----Original Message-----
> From: dns-operations [mailto:dns-operations-bounces at dns-oarc.net] On
> Behalf Of Doug Barton
> Sent: den 21 januari 2019 8:25
> To: dns-operations at lists.dns-oarc.net
> Subject: Re: [dns-operations] TTL=0
> Answers in-line below.
> On 2019-01-20 12:30 PM, John W. O'Brien wrote:
> > On 2019/01/20 14:27, Matthew Pounsett wrote:
> >> For the moment, ignoring the case where an authoritative server
> >> answer with TTL=0... say for the sake of argument it responds with
> >> TTL=1. The caching server should cache it for one second, and after
> >> one second should remove it from the cache. Therefore, it should
> >> never respond from cache with a TTL of 0.
> > At t0 the resolver receives an authoritative answer with TTL=1 and
> > caches it, then at t1=t0+10ms receives a query for that record. Should
> > it respond from cache with TTL=1 or TTL=0? What about for a query
> > t2=t0+500ms? t3=t0+501ms? t4=t0+999ms?
> I covered this in my previous response, but there seems to be significant
> delay in delivering mail to this list, so perhaps you missed it.
> The answer to your question is that it in each case, assuming that the TTL is
> still 1, it should respond with the answer and that TTL. The spec does not
> (currently) allow for finer grained control than that.
> > What should a forwarding resolver
> > do with a response from a full recursor having TTL=1?
> Pass it along as it receives it. Again, we don't have a mechanism to signal that
> N milliseconds of the 1s TTL have expired while the reply was in transit.
> > Is the TTL in the
> > response rounded up or down from the cache timer, which presumably has
> > much finer than 1s resolution?
> Not clear here whose cache timer you're referring to, but I'm not sure it
> matters. Nothing should be rounded, the TTL value should be passed as-is.
> > If the resolver rounds up, then it will serve with TTL=1 throughout
> > the last second a record is served from the cache.
> No, it shouldn't round anything. It should pass the answer with the TTL it has.
> > A downstream cache might
> > then cache it for almost another full second beyond what the authority
> > intended, a third tier cache for almost another full second beyond
> > that, and so forth.
> Yes, this is one of the weaknesses of the architecture you describe.
> Fortunately it only has a measurable impact if you're dealing with a lot of
> highly dynamic records with very short TTLs. In that environment, this
> architecture is not suitable.
> > If the resolver rounds down, then it will serve from the cache with
> > TTL=0 throughout the last second. No downstream resolver will cache
> > answers during that last second. The expiration deadline specified by
> > the authority is respected.
> I see the argument that you're making, but there is nothing in the spec that
> permits it. (Feel free to demonstrate if I'm wrong.)
> > It seems to me that TTL=0 is a perfectly cromulent value on the wire,
> > either from an authority or a resolver.
> It is, in the scenarios described in 1035 as quoted by Matthew in the message
> I responded to earlier. Not in the "recursor received an answer with TTL>0
> and is responding from cache" case.
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> dns-operations mailing list
More information about the dns-operations