Re: [DNSOP] Measuring DNS TTL Violations in the wild
On Dec 5, 2017, at 23:04, Lanlan Pan wrote: > Some authorititatives set the NS RR TTL<60s, they don't follow the best > practice guide. The trouble here is understanding the motivations of any particular parameter, and doing so at scale. You could assume as a resolver operator that a zone manager (note, not an authoritative server operator) has made a mistake when you get a response with a low TTL, or you could take the position that it's not your business to make such inferences. Local policy to meet your own objectives in the operation of your resolver is different from seeking to correct decisions made by zone managers. Assuming errors (hence "correction") is a slippery slope to having no single source of truth. There are protocol design decisions relating to TTLs that relate to metadata that a resolver operator *can't* reasonably adust, like signature validity periods. More philosophically, the loose-coherency and data persistence associated with caching works because its boundaries are understood. The ability to use the system as a whole relies upon an explicit contract between zone manager and resolver operator, and if that contract fractures, applications and user-experience will follow. Any changes to the contract (and I'm not suggesting there can't be changes) need to be conservative, well documented and carefully implemented. Playing fast and loose with the interpretation of TTLs on every other resolver doesn't sound like any of those things. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL Violations in the wild
Mukund Sivaraman 于2017年12月2日周六 下午10:39写道： > On Fri, Dec 01, 2017 at 05:16:47PM +, Ólafur Guðmundsson wrote: > > On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane > > wrote: > > > > > > > > > On Dec 1, 2017, at 8:38 AM, Ólafur Guðmundsson < > ola...@cloudflare.com> > > > 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. > > An authoritiative server operator knows what the consequence of setting > SOA RDATA fields is. It isn't the same as a cache extending TTL as it > sees fit, in spite of the loose coherency among primary and secondaries. > > I don't agree a downstream cache has authoritiative say about extending > TTLs (except exceptional circumstances where the authority is > unreachable ~serve-stale). > Some authorititatives set the NS RR TTL<60s, they don't follow the best practice guide. Authoritatives think they "do the right thing" to spread latest NS RR. Needless to say A RR. Some resolvers extend all RR's TTL<60s to 3600s，just to reduce the queries, when the authority is reachable. Resolvers think they "do the right thing", too. > Mukund > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL Violations in the wild
At Sat, 2 Dec 2017 20:09:25 +0530, Mukund Sivaraman wrote: > > Strictly speaking yes, it is the same as when a Secondary does not update > > the zone for a long time. > > An authoritiative server operator knows what the consequence of setting > SOA RDATA fields is. It isn't the same as a cache extending TTL as it > sees fit, in spite of the loose coherency among primary and secondaries. > > I don't agree a downstream cache has authoritiative say about extending > TTLs (except exceptional circumstances where the authority is > unreachable ~serve-stale). +1. I'd accept some level of liberty that an implementation can take, such as ISC BIND 9 extending a 0-TTL of glue to 1 second: /* * Glue with 0 TTL causes problems. We force the TTL to * 1 second to prevent this. */ if (rdataset->ttl == 0) rdataset->ttl = 1; but it should be limited to a quite small range. How much is acceptable may be debatable, but I wouldn't consider "Stretching TTL from 1 Hour [...] for 10% or 10 minutes" to be acceptable at the discretion of an implementation. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Measuring DNS TTL Violations in the wild
On Sat, Dec 02, 2017 at 08:09:25PM +0530, Mukund Sivaraman wrote: > I don't agree a downstream cache has authoritiative say about extending > TTLs (except exceptional circumstances where the authority is > unreachable ~serve-stale). I will note that this WG spent a fair amount of effort on RFC 7583. That text is actually bad advice if you are supposed to expect resolvers to extend the TTL on RRsets, because the Ready state depends on caches expiring. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ 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 01, 2017 at 05:16:47PM +, Ólafur Guðmundsson wrote: > 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. An authoritiative server operator knows what the consequence of setting SOA RDATA fields is. It isn't the same as a cache extending TTL as it sees fit, in spite of the loose coherency among primary and secondaries. I don't agree a downstream cache has authoritiative say about extending TTLs (except exceptional circumstances where the authority is unreachable ~serve-stale). Mukund ___ 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 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 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
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
