On Aug 23, 2013, at 2:06 PM, Daniel Kalchev <[email protected]> wrote:
> > On 22.08.13 22:59, [email protected] wrote: >>> From: Doug Barton <[email protected]> >>> As stated before, the problem is that after the "early adopter" period >>> is over we'll be stuck with NTAs forever. This is one of those >>> fundamental disagreements between those who believe that DNS should >>> always be forgiving of operator error, and those of us who do not. >> Running the DNS for 100+ school districts and 400,000+ devices, I really, >> REALLY don't want to be the one saying "Sorry, you can't use the site >> called for in your lesson plan today because they messed up the DNSSEC >> records." Management's response would be "Just make it work!" >> >> Without a per domain NTA, the only option would be to turn off DNSSEC, >> returning to square one. > > If turning off DNSSEC is your way to "Just make it work!" then it is > perfectly legitimate thing to do. You could do it in a limited scale for that > specific lesson today and turn in on afterwards. If the authoritative server operator of a significantly important domain does not treat DNS serious enough to keep it working, can really the resolver operator of a significantly important validating resolver do a better job? (Where the job is including the task of detecting attacks on DNS/DNSSEC.) We are already designing protocols that depends on working DNSSEC, and by disabling DNSSEC for significantly important domains nilly willy will probably hurt more than help in a not so distant future. As being in .se, I might be somewhat coloured by the fact that we have been running it since 2005. Yes, we have had our share of failures as expected, but very few of them would have been help by NTAs. If some large american resolver operators want to solve this for their customers, feel free. I do not believe that this practice should be documented by the IETF. (Because what you in essence do is to turn over control over a domain name on parts of DNS from the authoritative name server to a resolving name server in another administrative domain.)
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
