In message <519AD17D(_dot_)8040501(_at_)network-heretics(_dot_)com>, Keith
Moore writes:
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.
Ack.
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.
When the problems exist on the nameservers of Fortune 500 companies
nameservers it isn't consumer-grade routers. It is badly designed
nameservers or their load distributing front ends.
This is similar to the name error issue a nameserver vendor had
when responding to unknown types (e.g. AAAA) in the past. The BBC's
nameservers were a prime example at the time (now fixed). They
returned name error for a existing name (www.bbc.co.uk from memory).
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org