Sent from my iPhone
> On Nov 1, 2014, at 4:30 PM, Warren Kumari <war...@kumari.net> wrote: > > On Fri, Oct 31, 2014 at 8:17 PM, Brian Dickson > <brian.peter.dick...@gmail.com> wrote: >> I think it is good to minimize disruption caused by broken DNSSEC domains, >> for all the reasons listed in the document. >> >> However, I also believe there is a second-order negative effect of >> implementing NTAs as described. >> >> Validating stub resolvers and validating forwarding resolvers, will still >> break. > > Yup. This is a feature, not a bug. > > NTA only makes the local / "ISP resolver" not perform validation for > the domain. Anyone "downstream" who is doing validation will still > perform the validation, and this will fail -- this is, IMO, the right > thing to have happen. > Downstream validators are presumably a: more security conscious and b: > more able to troubleshoot DNS issues than my auntie. There is subtlety in using DLV instances. On the one hand, passing along answers that have known DNSSEC validation problems avoids blocking your auntie. On the other hand, if it is known to have problems, stitching things up in ways that still don't validate without use of DLV isn't really any worse. And on the gripping hand, adding the fix in DLV, for only those who have configured that specific DLV, means those clients are able to validate. Furthermore, those doing advanced level DNS operations are unlikely to use NTA implementer services. And, IMHO, advanced operators could signal a desire for unmodified answers the traditional way, via the CD bit. Adding the DLV function provides a scaling benefit in terms of how many validating forwarders need to make the NTA mod to resolve the affected domain. Without DLV, there is still an incentive to turn off validation -- which is what NTA is explicitly trying to prevent. Having forwarders validate should be something we all encourage and support, especially in this sort of document. I definitely think it is up to each operator as to whether they do this. However, I would like this to be included in the draft as an optional aspect of setting up NTAs, so that operators can evaluate the pros and cons, and make informed choices. Brian > > There is a big difference between handing back an answer as though you > are not a validator (the NTA), and signing someone else's answer. > > W > >> I do have a suggestion, which I hope is worth exploring and considering. >> >> For anyone using an open, well-known resolver (either provided by their ISP, >> or operated as a "public service"), include instructions on use of a >> provider-specific DLV and provider-specific "alternative trust anchor >> (DNSKEY)". >> >> Whenever it is necessary to over-ride broken DNSSEC zones, most likely on >> the Secure Entry Point, do the following: >> (1) Add a KSK to the apex DNSKEY RRset. For convenience use the same KSK for >> all such instances, and publish the public DNSKEY used. >> (2) Sign the apex DNSKEY RRset with this new KSK >> (3) Add this KSK into the DLV operated by the resolver operator at the >> appropriate location. For example, if example.com is broken, put the KSK at >> example.com.dlv.example.net, if the operator of the public resolver is >> example.net. >> (4) Observe successful validation of example.com by anyone configured to use >> dlv.example.net as their DLV. >> >> I haven't tried this, and there might be some specific modifications to what >> I described needed to make the configuration correct/functional. I don't >> believe it introduces new insecurities to anyone who already has placed >> trust in the resolver at example.net. >> (Is it the case that things that use DLV validate the chain of trust to the >> DLV itself, from the root, if there is not a separate trust anchor for the >> DLV zone? That would be optimal, security-wise, I believe.) >> >> Thoughts? >> >> Brian Dickson > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
