Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements
On Wed, Oct 19, 2022 at 03:21:27PM -0400, Tim Wicinski wrote: > This starts a Working Group Last Call for > draft-ietf-dnsop-dnssec-validator-requirements > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/ > > The Current Intended Status of this document is: Informational > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, please speak > out with your reasons. > > This starts a two week Working Group Last Call process, and ends on: 2 > November 2022 Repost of my belated comments in the thread, apologies about not doing it right the first time... -- Viktor. > Recommendations for DNSSEC Resolvers Operators >draft-ietf-dnsop-dnssec-validator-requirements-04 Before I dive into some paragraph-by-paragraph details, and bury the lede, my main high-level issue is with sections 9, primarily on substance, but also for IMHO notably stilted and fuzzy language. The most significant issue is that the I-D recommends at the bottom of section 9 to cap the TTLs of all dependent RRsets by the TTLs of the DS, KSK and ZSK records. > RUNTIME: > > * To limit the risks of incoherent data in the cache, it is > RECOMMENDED DRO enforce TTL policies of RRsets based on the TTL of > the DS, KSK and ZSK. RRsets TTL SHOULD NOT exceed the DS, KSK or > ZSK initial TTL value, that TTL SHOULD trigger delegation > revalidation as described in [I-D.ietf-dnsop-ns-revalidation]. > TTL SHOULD NOT exceed the signature validity. This is not necessary for correctly operated authoritative zones, that retain "inactive" ZSKs and KSKs in the DNSKEY RRset for a few TTLs after the keys become inactive, and likewise drop hashes of inactive KSKs from the DS RRset only after new KSKs have been published for a sufficient time. What we'd need instead of TTL capping is more akin to "revalidation" where under normal/expected conditions, cached RRsets continue to "enjoy" their natural TTL (as tweaked by any resolver limits). That TLL can for many RRsets be higher than e.g. the TTL of the parent zone DS RRset. With "revalidation", if a DS record refreshed after TTL expiration is (as is typically the case) identical to its previous value, or in any case continues to establish a chain of trust to the cached DNSKEY RRset, nothing needs to happen to the caching of the descendent records. Similarly, DNSKEY RRset refreshes that still include the ZSK originally used to validate a cached RRset need not have any affect on the validity of the signed data. The above DS and ZSK continuity conditions are expected standard practice from the signer. So long as these hold, validated records should be cached for their advertised TTLs as bounded by the signed origin TTLs and resolver cache time limits. Resolvers *MAY* take action to revalidate cached data should abrupt changes take place in the DS RRset (no longer building a trust path to the cached DNSKEYs) or abrupt changes in the DNSKEY RRset (no longer validating cached RRSIGs), but should not be expected to do so. As resolvers gain implementation experience with this revalidation generally, and DNSSEC trust chain revalidation specifically, and are seen to perform revalidation safely and scalably (without thundering herd query storms), and revalidation becomes a common implementation feature, perhaps then we might reconsider resolver cache expectations. We're not there yet, and in the meantime crude truncation of all TTLs to the smaller of the DNS/DNSKEY TTLs is IMHO not a good outcome. Moreover, this recommendation would be a barrier to shorter DS TTLs, which are necessary to reduce mean time to recovery, making enabling DNSSEC less daunting to risk averse authoritative zone operators. > Abstract > >This document clarifies the scope and responsibilities of DNSSEC >Resolver Operators (DRO) O.K. so far. > as well as operational recommendations that >DNSSEC validators operators SHOULD put in place in order to implement >sufficient trust that makes DNSSEC validation output accurate. There's a missing verb in this part of the sentence. "As well as ???" Also: s/DNSSEC validators/DNSSEC validator/ > 1. Introduction >The purpose of a DNSSEC Resolver Operator (DRO) is to provide DNSSEC >validation in to their users. Well, the purpose is to provide DNSSEC resolution. DNSSEC validation is a part of that, but isn't the whole. >By validating with DNSSEC a received Resource Record Set (RRset), the >resolver provides a high level of certainty that the information >carried by the RRset is effectively as published by the legitimate >owner of the RRset. s/certainty/assurance/ > The act of DNSSEC validation [RFC4033][RFC4035] >
Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
On 5/11/23, 7:30 PM, "DNSOP on behalf of Mark Andrews" wrote: > >It’s not a challenge to track what is lame. It’s dead simple. You just > have to look. Getting >it addressed is the challenge. Speaking from experience (which means I'm about to launch an amplification attack here: taking a short message and adding in stories from the past few decades in this area), this is very true. Using the analogy of observing symptoms, diagnosing cause, prescribing a fix, and following through, it's easy to tell when someone coughs - but, if the cause happens to be from a personal habit, very difficult to mitigate. In following this discussion, admitting that I have no idea what "rfc8499bis" is (not a title, not a document file name, not a link), I ought to throw in this question: "Why do broken delegations (lame, unreachable address, etc.) matter?" So in some sense I'm committing an IETF sin. In my experience with lameness, the problem was rather specific. In that era, a server, given a question it could not answer would refer the querier to the root zone - perhaps as some sort of joke initially. The trouble was that some resolvers were not in on the joke (and I bet there was no technical document specifying what an "upwards referral" signified) but it turned out to be pretty easy to fix the problematic resolvers. (It was one major, proprietary source who, surprisingly to many in the open source fandom, actually fixed their bug.) I'm not sure my work in quantifying the amount of lameness ever mattered as the eradication process undertaken seemed to overcome by the fix of the resolvers (nevertheless, it was pretty interesting research to conduct). (This is the central thought of this rant:) It's true that if a registrant misconfigures their delegation or servers, their service will suffer. But does this have fallout for anyone other than their service users? Other than researchers who poke into this stuff (like me)? Does it impact the registry delegating to the registrant? From other experience, I once dove into an incident (details I can't divulge). One of the things I identified was the source of the queries for a particular DNSSEC-related data set. In the top-ten queries was a "labs" machine - a research organization was "pounding" the servers for this data set to the extent they were a noticeable portion of the incoming traffic. At times, research is not measuring traffic but becoming the traffic. And from another experience, I once had to deal with a customer who had a zone delegated to the servers that we operated but neglected to tell us. (The very picture of lameness, completely unrelated to my earlier lameness quantification.) Our monitors did not know the incoming queries were headed for one of our current customer's zone as we didn't know the zone was theirs. We thought it was simply DDoS-related traffic. A factor here is that the operations I am talking about were not a TLD of any kind (hence the last label was not tell-tale). And yet another experience, I've dealt with situations where a major change was being proposed but those that needed to play along had absolutely no relationship with us. The Internet encourages people to plug in and play without being subject to remote monitoring. At times that is very good. At times that is very frustrating. What I learned from that was no one can set expectations on what someone else will do on the Internet. One can't expect protocol conformance from an entity with which you have no relationship, but you need to be prepared to deal with whatever comes (a take on "liberal accept, conservative send" - that adage attributed to Jon Postel). It's fine to quantify situations. It's fine to launch campaigns to improve the "health" of the Internet and fine to measure the impact of the campaigns. But you can never expect to see "success". This is really frustrating when changes (including clarifications) are sorely needed to improve the state of operations across the global public Internet. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
Yeah, that's a better way to put it. But the main point still stands, that it would be a signficant operational change to insist that all delegated NS be active when delegated, and even moreso to insist that they continue to be active. ... Well, OK, you do that, half the emails bounce, half of what's delivered is reported as spam, and the third half are ignored. Now what? In practice it isn’t quite as bad as that. Require registrars to refuse renewals until the issues are addressed. Please see "signficant operational change" above. My feeling is that if it's not important enough for *you* to have your DNS working, it's not important for *me* either. I'm happy to help people who are having trouble fixing problems, but not to waste time on people who don't care. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
