> People keep saying that something has been broken. But in fact, nothing > has been broken, except false assumptions that were false to begin with. You're simply wrong, and there have been numerous examples of this. > NXDOMAIN means the domain isn't in the DNS distributed databse. It > doesn't mean that it isn't registered. The app doesn't care whether the domain is registered. The app cares whether the domain exists in DNS, because using DNS to look up the address is the way the app is designed to work. Putting the domain in DNS is (either implicitly or explicitly) part of the application protocol. > However, NXDOMAIN hasn't been > wrongly sent. It is not the case that NXDOMAIN _MUST_ be sent. That would > preclude wildcard records. Wildcard records make a global assertion for an entire zone. This is not an assertion that VeriSign is entitled to make. VeriSign does not have the right to make assertions about all unregistered domains in NET or COM. > Further, lack of NXDOMAIN does't mean the record exists. Only NXDOMAIN > has meaning. No NXDOMAIN response means nothing. That is the case we > have. No the case we have is not the lack of a response. It is a response containing an A record. That A record is a lie. > > Note that this is not the same problem that VeriSign is causing - > > VeriSign is uniformly mis-representing the COM and NET registries and > > mis-reporting NXDOMAIN error conditions for these zones as successful > > queries, which is not the same thing as producing inconsistent results > > depending on who is asking. But it does relate to the question of > > whether the DNS is the authority for DNS name information or just a way > > of obtaining the information. > > It is not _mis-reporting_ anything. That is precisely what it is doing. Keith