Perhaps we should be getting Jari, Suzanne and Andrew to push this at IGF meetings.
In message <20151110152511.6f1a1...@pallas.home.time-travellers.org>, Shane Ker r writes: > Mark, > > On Fri, 06 Nov 2015 10:54:02 +1100 > Mark Andrews <ma...@isc.org> wrote: > > > I keep getting told the IETF can't tell people what to do > > but that is *exactly* what we do do when we issue a BCP. > > We tell people what best current practice is and ask them > > to follow it. > > > > Today we have TLDs that do perform all sorts of checks on > > servers they delegate zones to and some do inform the > > operators of those zones that they have errors. Those > > checks cover in part tests described in > > draft-andrews-dns-no-response-issue. > > > > So do we adopt this or do we continue to lie to ourselves > > about what BCP actually do? > > My guess is that part of the resistance is because you are going to be > asking people to spend money on something that does not provide them or > their customers any (direct) benefits. Further, it breaks the > registry-registrar model in some cases, where registries are kept away > from registrants by a 1.6 km-high wall. Who are the customers of a registry? The registrants and those that lookup names in the registry. Yes, everyone else *is* a customer of the registry and by performing tests and informing the registrants you help both sets of customers. As for costs, a machine/vm running checks and sending out email every 3 months. That's effectively all <https://ednscomp.isc.org/compliance/summary.html> is though it doesn't send the email and it runs the checks daily, it does have to hooks to send out email built in but they are not activated. Once this becomes a regular thing many/most/all tlds do the human costs go down as it becomes something people can lookup answers for what to do when they get the email. You ask the registant to contact their DNS/Firewall vendor for the fix after explaining the issue. If they are hosting their own DNS they should know who that is. If they are using a DNS operator the message gets relayed to the operator or they can switch DNS operators to one which does the right thing. The DNS operator then needs to contact their vendors for a fix. As for the no direct contact this doesn't require direct contact. The registrars can perform the checks for the servers of all zones registered through them or they can relay the messages from the registry. > My prediction about the eventual outcome is that you would end up with a > document that works as well as BCP 38; meaning that it is nice to have > for people that want some recommendations about what to check (and > can't be bothered to look at other registries' online documentation, or > contact registries directly and ask what they do). So we don't say what's right because you fear that not everybody will perform the actions. We don't need to get every TLD to check to have a real impact. We just need several to check and inform, preferably big ones. Lots of zones are hosted by big players and getting them fixed has a big impact on the overhaul health of the DNS. e.g. UltraDNS and related companies fixing their service resulted in a 18% fix for the root and TLD servers, a 5% fix for the Alexa top 1000, a 2% fix for Gov servers in the Alexa top 1M and about the same for the AU servers in the Alexa top 1M. The bottom 1000 is too noisy to see if there was a change there. See the Sep 28 2015 steps in <https://ednscomp.isc.org/compliance/ts/allok.html>. > If your true goal is to get ICANN to act as the some sort of enforcer > for DNS operational purity, then please do so via ICANN channels rather > than the IETF. ;) This is actually IETF business. We can set community consensus of what is a resonable requirement. If nothing else ICANN will come back to us looking for checks to be enforced. Additionally the CCtlds are not bound by ICANN but by RFCs. > To be clear, I am not opposed to a document which lists various checks > a parent zone may want to do, and the costs & benefits of each, as long > as it doesn't end up with you screaming at the microphone because TLD > .XX doesn't implement the recommendations. :) > > Cheers, > > -- > Shane -- 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
