In message <cahw9_ik5yvsc07co_cjz2go2oquyqbjjverw6ceexbuj2cv...@mail.gmail.com>, Warren Kumari writes: > Over on the BIND-Users list there is currently a discussion of > fema.net (one the "Federal Emergency Management Agency" domains) > being DNSSEC borked > (https://lists.isc.org/pipermail/bind-users/2014-October/094142.html) > > This is an example of the sort of issues that an NTA could address -- > I'd like to note that currently neither Google Public DNS (8.8.8.8) > nor Comcast (75.75.75.75) have put in an NTA for it, but if it were > fema.gov, and this were during some sort of national disaster in the > US, things might be different... > W
It is also a example of why valid whois data is required. whois fema.net -> contact details whois fema.gov -> a farce Mark > On Mon, Oct 27, 2014 at 10:04 AM, Dan York <y...@isoc.org> wrote: > > Many others have made the points I would have made about the operational > > value of NTAs so I won't repeat those... but I want to just say that I think > > Paul Ebersman nails it here: > > > > On Oct 26, 2014, at 12:09 PM, Paul Ebersman <list-dn...@dragon.net> > > wrote: > > > > I see NTA as a tool that we should try to never use but which is > > invaluable when we do need it. > > > > > > Exactly! Hopefully everything "just works" 99% of the time... but in the > > event something doesn't work right the operators have a narrow "scalpel" > > tool in their toolbox that they can pull out rather than resorting to more > > drastic measures such as, for example, disabling all DNSSEC validation. > > > > Ideally NTAs never get used and as DNSSEC deployment moves along and DNS > > operators get increasingly familiar with the operational practices required > > of DNSSEC then the need for NTAs will eventually fade away. > > > > My agenda in pushing this draft is not to advocate wide spread use but > > to guarantee that all of my vendors have an RFC to code against so that > > I have consistent behavior and plenty of server choices for server > > diversity. > > > > > > Yes! If we have an operational need to have a way to generate DNSSEC > > validation exceptions, let's please have *one* way that we can collectively > > agree upon rather than having every different operator come up with some > > custom mechanism that works only for them. This will make the overall > > deployment that much easier if the one method is spread across multiple > > software vendors and systems. > > > > My 2 cents, > > Dan > > > > P.S. Nice quote, Warren! > > > > -- > > Dan York > > Senior Content Strategist, Internet Society > > y...@isoc.org +1-802-735-1624 > > Jabber: y...@jabber.isoc.org > > Skype: danyork http://twitter.com/danyork > > > > http://www.internetsociety.org/deploy360/ > > > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > -- > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
