In message <6A13CEB4-8906-4EC5-9210-571D5474E7FC@xxxxxxx>, manning bill writes: > 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. Which has what to do with requesting that a known problem get fixed? One that is clearly caused by nameservers operating outside the expected behaviour of nameservers. > 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. Well I didn't ask for a complete compliance test to be run. I ask for a specific test for a known problematic issue to be run. > 3) - The full DNS standards fail to include the RFC 2026 language that > would suggest mandatory capabilities. And this has what to do with the issue? Yes older RFCs don't all use the formal language of RFC 2026. That doesn't mean that the intent was not clear or that one should not address operational issues that arise. > 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 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx