In message <519AD17D.8040501@xxxxxxxxxxxxxxxxxxxx>, 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@xxxxxxx