Edward Lewis wrote: > On 3/27/15, 16:00, "Paul Vixie" <[email protected]> wrote: > >> ... have you read >> <http://datatracker.ietf.org/doc/draft-vixie-dnsext-resimprove/> and do >> you have comments? > > Speaking for myself ... - I read it back in time. I distinctly remember ... > that I didn't support it's ideas. > > I get the idea of using the cutpoint TTL to determine when to refresh apex > data. I get that if a zone is hijacked, this would lower recovery time.
not just hijacked. see also "oops". > ... > I more cling to the sanctity of a delegation. When a parent delegates to a > child, the child is the master over it's contents, not the parent. Outside of > permitting the delegation (holding an NS set) and indicating its security > entry parameters, all else is property of the child. so, the NS set is ok to mess with, the DS set is ok to mess with, but the NS TTL is not? i cannot imagine how you differentiate the parent-vs-child "mastery" in these three cases. > ... > A resolver does have free-will to do what it needs to find answers to > queries. It could choose to over amp queries if it wants up to date > information at all times (whether for rainy days or just because). Most do > judging from work I've done in the past. (E.g., very, very few queriers > honored a multi-day TTL I had for a particular record set.) (Had I known > this, it would have made difference in how I set TTL values.) this is an unrelated topic, but it does make me want some of our research brethren to look at the query logs on various busy authority servers (root, tld, uni, ent, isp) and characterize the treatment of DNS TTL by isolating same-question same-questioner "flows". such a study would have to ignore the repeated-query flows from recursives who are behind firewalls and therefore don't hear answers to their questions. (that's "many.") > But I think that it is unwise to optimize for "rainy days" when "sunny days" > are more frequent. > ... > ... unless you can show me statistics that say hijacked zones matter enough, > I'm not going to optimize that direction. let's be clear. i'm suggesting that if a registrant could cause a near-global cache flush of a zone by merely visiting their registrar interface and adding or deleting an NS RR (perhaps with a plan of deleting it or adding it back a day later), this would be a great way to solve the "oops" problems we see. for example: > -------- Original Message -------- > Subject: [dns-operations] resolver ops: please refresh gov.on.ca > Date: Fri, 12 Dec 2014 21:49:24 -0500 > From: Mark E. Jeftovic <[email protected]> > Organization: easyDNS Technologies Inc. > To: [email protected] <[email protected]> > > > > All resolver nameserver operators, if you could refresh your caches for > gov.on.ca > > There has been an incident where the government of ontario nameservers were > briefly hijacked > > We will post details to follow > > in the meantime, if you can refresh your caches, the proper records should > be: [...] your question about cost:benefit is interesting. if we assume that verisign changed its TTL for delegations under COM from two weeks to two hours, or if the EPP system would allow registrars (but *not* registrants) to set it and this became a common CYA value (Cover Your A$$) in case of crime or "oops", then we could expect one new query per actively-caching full resolver per two-hour period. if 50M of COM's subdomains are accessed by 10M full resolvers within any given two hour period, that's 30M queries per hour added to COM server load which is ~8K queries per second. i think the COM servers (counting all anycast servers of all COM name server names) receive O(10^6) queries per second today, most of which are junk (negative responses, or responses that can't be delivered to the initiator due to initiator-side firewall problems). if we replay this without O(10^7) servers, either because many of them don't cache more than a handful of COM names during any given two hour period (so, DSL and cable modems), or because most of them will never be upgraded to follow the convention i am suggesting regarding delegation-TTL based purge, then the actual number of queries drops from ~8K/sec (which is de minimis) to something ~0. likewise if the two-hour working set of COM names is less than O(5x10^7) then the cost of wide adoption of the proposed convention is ~0. in summary, this proposed convention does not optimize for rainy days. its costs are noise-level, especially compared to the junk queries all over the DNS today. its benefits will be rare, but important when seen. -- Paul Vixie _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
