Deployment of standards compliant nameservers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



	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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]