In message <B42E8628-7F12-40F4-B74C-598116D0AF17@xxxxxxxxx>, Jari Arkko writes: > > >> If that is something you want, this document is certainly not the > >> place to do it. That's a protocol specification change, and this > >> document is not altering the DNS protocol in any way. > >> > >> Best regards, > > > > Well reflecting back the bit isn't permitted and requiring that > > such queries get answered are parts of the existing specification > > which are not being followed. Requiring just these parts be correctly > > followed will make future deployment easier. > > For what it is worth, I agree with Andrew that this document is > not a protocol specification, and these other things belong > elsewhere. And it seems you have a draft already, so... There is follow the existing RFC and clean up ambiguities. The error code selection is cleanup. The non reflecting of reserved bit and correct EDNS behaviour are existing behaviour. Expecting root servers to follow the defined parts of the protocol should be a no brainer. The draft-andrews-dns-no-response-issue isn't formally changing anything. It is pointing out a real problem and it is requesting that parent zone operators, in particular TLD and public SLD operators, regularly audit the servers that they are delegating namespace to for compliance and to report non-compliance even if that has to go through a intermeditory. It's also providing something that the delegated zone operators / nameserver vendors can check their servers with. I'm not sure that it would be the best document to update RFC 103[45]. It would be scope creep to do so. I think something more like RFC 2181 would be more appopriate for that. I don't mind working on such a document. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx