In message <[email protected]>, "John Levine" writes: > > Minor errors: > > 2.1: "otherwise identical responses" -> "otherwise identical queries"
addressed > > 8.1: something's dodgy with the XML, the html version that xml2rfc > produces puts the examples before the corresponding text rather than after. It doesn't happen w/ the xml2rfc I have. I expect this is a bug in xml2rfc. That said the .xml is available for anyone to look at if they have a suggestion. > Section 2: > > I'd use a word other than "class" since it's not used in its DNS > technical sense. Kind(s)? > Section 3: > > While I agree that it would be a good idea for TLD operators to audit > the name servers to which their 2LDs are delegated, contacting people > who can fix it is a mess. While there are only three TLDs where the > registrar keeps the WHOIS info, two of them are the large .NET and > the giant .COM so in practice registrars have to do a lot of the work. > Some domains have DNS service from the registrar, some from a hosting > or other provider who may or may not be one of the registration contacts, > some other places. So you do what you can. but sometimes they'll still > not get it. You can always contact the registrant, possibly through a registrar, and through them get the server fixed / changed. They are responsible for picking a service that works. They also are who are ultimately affected when the remedy if last resort is applied. For the most part the TLD operators do the correct thing anyway. https://ednscomp.isc.org/compliance/tld-report.html > As to the advice to TLD operators to un-delegate broken servers, good > luck with that. For ICANN contracted TLDs it'd require a change to > the RAA which is unlikely to happen, and for everyone else, the > registrant is likely to say "it works fine for me", which it probably > does for simple A and MX queries. I'm not sure what to say instead, > but it seems unwise to instruct people to do something you know they > won't do. Parent zone administrators are already instructed to do just that as the last step in attempting to remediate problems cause by broken / misconfigured servers. This does happen for sites spewing spam. It can happen for other causes. I don't want thing to escalate to the point where it becomes necessary to remove a zone but you have to leave it there as a tool of last resort. > Section 5: in the last sentence, I don't understand whether it means > that none of them are attack vectors, or that some are and some aren't. What other word than "All" would you have me use in "All of these are not attack vectors" ? > Section 8.1: this list of tests is great. I stared at it and I think > it's all correct, other than the XML formatting problem, but due to the > length and all the fiddly details the more people who look at it and > ideally who implement it, the better. They should be as they were cut-and-pasted from the scripts used to generate the pages linked from https://ednscomp.isc.org. > Section 9: turning off servers that partly work is likely to have > security implications, like zones disappearing from the Internet. I'm not sure it is but can add something. > There are lots of minor typographic and grammar problems that I > haven't mentioned. A thorough copy edit by someone other than the > author would be useful. (This isn't saying anything bad about the > author, just that we can't catch our own mistakes. BTDT, got copies > of Internet for Dummies with egregious typos that went through three > editions.) > > One final thought: if the registry or someone is going to test all > those nameservers anyway, should it also check other errors like > lame delegation and broken or inconsistent DNSSEC keys at the same > time? They should already be doing that. RFC 1034 already say to do this. That said this document is focusing of server/firewall implementation faults not DNS configuration faults. Checking of delegations by TLD operators should be nothing new as they have been required from the very beginnings of DNS to do this [RFC1034]. Checking for compliance of nameserver operations should just be a extension of such testing. > R's, > John > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
