A couple of remarks below: On Nov 4, 2014, at 18:07, Brian Dickson <brian.peter.dick...@gmail.com> wrote:
> The good news is, for most cases, setting up a DLV-based "fix" can be done, > with only the DNSKEY(KSK). > I.e. modifying responses is not required AT ALL, and no new DNSKEYs or > signatures are needed. Recall that DLV is a registry and thus has all the inherent risks of any registry. > (Please ignore my previous responses.) That will cost you plenty, you’ve posted a lot through the years. ;) > Long version: > > In order to assist validating forwarders, broken DNSSEC zones can be > "repaired" using DLV, and ONLY DLV. Assuming that the problem lay in the keys available to build the trust chain. > Take the result of "dnssec-dsfromkey" for the apex KSK, append the DLV domain > name to the owner names. > Insert into the DLV zone, sign, bazinga. Use of this DLV, with the modified > suite of bind tools, securely resolves. > > As currently implemented in BIND-9.10.1, a modification is needed to > lib/dns/validator.c. > The good news is, it is a one-line change. In BIND (only), no? (Well, yes, just an annoying way to say that there are other implementations.) > Basically, it changes the logic, if no DS->DNSKEY validated match can be > made, to fall through to use DLV. This harks back to something I looked up just today - section 2.7 of RFC 3008 - which restricted the signer ID in the SIG RR to be the name of the zone apex. Here you are not changing the signer ID but the authoriative source of the zone apex key set. In the spirit of “any trusted chain in a storm” you have to make sure you can trust the “alternate source.” Hence my remark above that DLV is a registry with the inherent risks of a registry. > (In the current logic, DLV is only queried if no DS exists above a secure > zone, from a secure zone. The change extends the logic to make this "no VALID > DS" instead of "no DS".) > > No changes to the answers served by a resolver (who is the target of > forwarders) are required. > > There is not even a requirement that the NTA resolver operator be the > operator of the "fix-up" DLV. > > Given the relative rarity of DNSSEC failures which do not get fixed quickly > enough relative to their perceived value I have an experience that says “perceived value” is in the eye of the beholder. For a while “$we” turned on DNSSEC validation. When one, tiny, low-query-volume, corner-of-the-internet, zone “broke” we got a trouble ticket. That ended the validation experiment (the front-line didn’t know the code base in use had NTA). Didn’t matter that it wasn’t a marque zone, just one that someone who’d bother to complain wanted to get to. The point is, if the front-liners knew how to uss the NTA, they’d still be using DNSSEC. Because they wouldn’t have feared the trouble ticket and, while running, would have gained experience and confidence. That’s been lost. > , it may be worth asking for volunteers to run one (or more) centralized > fix-up DLV instances. I become scared of you when you start talking about “(or more) …DLV instances.” In the same sense that more X.509 certificate authorities degraded the trust in X.509 chain building, more sources of data to build trust chains hasn’t had a good track record. > So, other than the operational implications to downstream validators of > NTA-implementing resolvers, it may be sufficient to add the observation > regarding DLV as a possible way of fixing broken DS->DNSKEY (on a third-party > basis) as a sub-paragraph. IMHO, under the banner of “local policy” (as evidenced in 2.7 or RFC 3008 and elsewhere), a local determination to press the NTA button in an implementation is well within what an operator should want. Adding in untold other sources to an implementation is not within the spirit of “local policy” (beyond deciding to use or not the implementation) - on par with some recent OS release apparently deciding to store private documents on it’s cloud service “for safe keeping.” ;) Dropped the rest of the mail thread here… _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
