[DNSOP] Measuring DNS TTL Violations in the wild
Hi, In the light of the recent discussions on TTL violations and server stale here on the list, I decided to take a look on how often resolvers perform TTL violations in the wild. To do that, I used almost 10K Ripe Atlas probes. You can find a report and datasets at: https://labs.ripe.net/Members/giovane_moura/dns-ttl-violations-in-the-wild-with-ripe-atlas-2 Now, what was more scary were the violations that *increased* the TTL of of RR some more than 10x. That may put users at risk of service domains that may have been already taken down. /giovane ps: related thread on oarc list at : https://lists.dns-oarc.net/pipermail/dns-operations/2017-November/017039.html ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL Violations in the wild
I strongly disagree with your "terminology", TTL is a hint about maximum caching period, not a demand or a contract. A resolver can at any time for any reason discard cached entries. Many Authoritative operators have "unreasonable" TTL's like less than 10 seconds or multiple days and I see no reason why resolvers do not apply minimal and/or max caching rules that are reasonable. Olafur On Fri, Dec 1, 2017 at 3:48 PM, Giovane C. M. Moura wrote: > Hi, > > In the light of the recent discussions on TTL violations and server > stale here on the list, I decided to take a look on how often resolvers > perform TTL violations in the wild. > > To do that, I used almost 10K Ripe Atlas probes. You can find a report > and datasets at: > > https://labs.ripe.net/Members/giovane_moura/dns-ttl- > violations-in-the-wild-with-ripe-atlas-2 > > Now, what was more scary were the violations that *increased* the TTL of > of RR some more than 10x. That may put users at risk of service domains > that may have been already taken down. > > /giovane > > ps: related thread on oarc list at : > https://lists.dns-oarc.net/pipermail/dns-operations/2017- > November/017039.html > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL clamping in the wild
> On Dec 1, 2017, at 11:38 AM, Ólafur Guðmundsson wrote: > > > I strongly disagree with your "terminology", TTL is a hint about maximum > caching period, not a demand or a contract. > A resolver can at any time for any reason discard cached entries. Agreed. > Many Authoritative operators have "unreasonable" TTL's like less than 10 > seconds or multiple days and I see no reason why resolvers do not > apply minimal and/or max caching rules that are reasonable. Yes, I remember a load balancer from the last century that had serious issues with DNS requests with low TTLs. We ended up replacing it. TTL is certainly a MAX, but no reason you can’t return a shorter value. My stub resolver may see a lower number if an item is about to be evicted from cache, should we not see that? Clamping the max seems helpful and causes the least enduser harm, so is quite wise. The same would be true hitting a large anycast dns server like 75.75.75.75 or 8.8.8.8, 4.2.2.1, you may hit a different backend for whatever reason so see varying TTLs for the same query within a 10 second interval based on that. That’s not bad, it’s working as designed. I think measurements are interesting though, so identifying TTL clamping in the wild would be an interesting study. - jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL Violations in the wild
> On Dec 1, 2017, at 8:38 AM, Ólafur Guðmundsson wrote: > > I strongly disagree with your "terminology", TTL is a hint about maximum > caching period, not a demand or a contract. You say its just a hint. If you put a TTL of 1 hour on your data, and I have a recursive name server that reuses it for 2 hours, 12 hours, 5 days... thats okay? If its just a hint then we are we spending all this effort on "serve stale"? DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL Violations in the wild
On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane wrote: > > > On Dec 1, 2017, at 8:38 AM, Ólafur Guðmundsson > wrote: > > > > I strongly disagree with your "terminology", TTL is a hint about maximum > caching period, not a demand or a contract. > > You say its just a hint. If you put a TTL of 1 hour on your data, and I > have a recursive name server that reuses it for 2 hours, 12 hours, 5 > days... thats okay? > > If its just a hint then we are we spending all this effort on "serve > stale"? > > DW > > Strictly speaking yes, it is the same as when a Secondary does not update the zone for a long time. DNS is not a strict coherency protocol, thus playing loose with the time things are with in reason is ok. Stretching TTL from 1 Hour to 1 day is IMHO BAD, doing it for 10% or 10 minutes is fine. We are getting into religion here, the original poster called people that cap TTL's Heretics, I disagree with that labeling of myself and others that are applying sane caps. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL Violations in the wild
On 1 Dec 2017, at 9:16, Ólafur Guðmundsson wrote: > We are getting into religion here, the original poster called people that > cap TTL's Heretics, Looking through the mail archives, no one other than you is using that term. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL clamping in the wild
> On Dec 1, 2017, at 12:23 PM, Paul Hoffman wrote: > > On 1 Dec 2017, at 9:16, Ólafur Guðmundsson wrote: > >> We are getting into religion here, the original poster called people that >> cap TTL's Heretics, > > Looking through the mail archives, no one other than you is using that term. I think this is subject to interpretation, some people view the done differently. The subject line felt hostile.. 2nd attempt to adjust subject-line to make it less hostile. - jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL clamping in the wild
I would be very interested in a bit more precision here. Is there a way to say what is permissible vs impermissible re TTLs, and is there a way to say what is desirable vs undesirable re TTLs? We all understand that longer TTLs reduce the frequency of refresh at the expense of slower response whenever the authoritative information changes. However, some fraction of the recursive resolvers impose minimum and/or maximum limits on the TTLs they receive from the authoritative servers. Shortening TTLs increases the amount of traffic between the recursive resolvers and authoritative resolvers and lengthens the response time for some queries. However, I don’t think there is any service guarantee with respect to an individual query that is violated by shortening the TTL. Lengthening a TTL, on the other hand, does change one of the service guarantees. When there is a change in the entry in the authoritative server, what is the maximum time until that change is guaranteed to be propagated throughout the net? This depends primarily on the TTL. However, when the TTL is lengthened by the recursive resolvers, the upper bound for propagation of a change is similarly increased. Is there any common understanding of how much lengthening is permitted? Is commonplace? Let me make a guess that the only lengthening that takes place in practice is a floor of ten seconds. Comments? Thanks, Steve > On Dec 1, 2017, at 12:52 PM, Jared Mauch wrote: > > > >> On Dec 1, 2017, at 12:23 PM, Paul Hoffman wrote: >> >> On 1 Dec 2017, at 9:16, Ólafur Guðmundsson wrote: >> >>> We are getting into religion here, the original poster called people that >>> cap TTL's Heretics, >> >> Looking through the mail archives, no one other than you is using that term. > > I think this is subject to interpretation, some people view the done > differently. > The subject line felt hostile.. 2nd attempt to adjust subject-line to make it > less hostile. > > - jared > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
