I believe that there are a couple of problems with this plea… 1) - The IETF has -never- tested for or assured compliance with their document series. 2) - The only DNS test suite I am aware of is the older TAHI test suite from http://www.tahi.org/ - which was focused on IPv6 development and is now closed. 3) - The full DNS standards fail to include the RFC 2026 language that would suggest mandatory capabilities. So, while a nice idea, it is hardly practical from an IETF (or any top-down) perspective… /bill On 20May2013Monday, at 17:26, Mark Andrews wrote: > > I call upon the IESG to discuss with IANA, the RIRs, ICANN > and TLD operators how to deal with the problems caused by the > deployment of non standards compliant nameservers. > > For a long time there have been operational problems > cause by the deployment of non standards compliant nameservers that > fail to respond to DNS queries directed at them or respond incorrectly. > > The biggest problem with respect to deployment of new > types is nameservers that fail to respond to types they don't > understand. RFC 1034 allows for several different responses: > > * name error > * no error no data > * not implemented > * refused > * formerr > > "Name error" and "no error no data" are the expected responses for > queries with unknown types. This is reinforced by RFC 3597. But > any of the other responses is acceptable. Failure to respond however > is not acceptable. It introduces systematic timeouts which are > indistinguishable from network errors without extended analysis of > query response behaviour. > > While the percentage of nameservers misbehaving like this are > relatively small they have a disproportionate effect on protocol > development. They are also easily identifiable when looked for by > querying for a know type at a name that is know to exist, the zone > apex, that is supported by virtually all nameservers (e.g. A) and > querying for a random unallocated type, then querying again for the > original type. If you get a answer, no response, answer then the > nameserver in question almost certainly has this issue and you are > not looking at a dead server or network congestion issue. > > I'm not sure what the solution should be but regular audits of > delegated nameservers by infrastructure operator and removal of > delegations after a grace period to correct the faulty nameserver > and checking of nameserver behaviour at registration time would go > a long way to addressing the problem. > > Removal of the delegation is one of the suggested remediations > identified in RFC 1034 for nameservers that are causing operational > problems. It is not the first step by it is a step in the process. > > Mark > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx