It seems like a first step might be to set up a web page and/or write up
an I-D with
a) a description of the problem
b) documentation a procedure and/or code that can be used to test name
server software for compliance
c) recommendations for zone operators that delegate to other zones
The next step might be for TLD operators to encourage the TLD registrars
to (a) inform their customers of this issue, (b) test their customers'
servers, and report the test results to their customers. Ideally those
registrars would be able to refer their customers to updated or improved
servers.
Longer term it might be appropriate to do some other things, like
a) define standard tests for compliance
b) define a mechanism by which a server could be queried to find out its
implementation name, version, etc.
Keith
p.s. I wonder if the problem you describe might at least partially be
caused by DNS proxies and interception proxies, including but not
limited to those incorporated in consumer-grade routers.
On 05/20/2013 08:26 PM, 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