On Wed, 17 Sep 2003, Keith Moore wrote: > > > > I strongly disagree. The DNS is the ultimate authority on whether a > > > domain exists, since the way you create a domain is by making an > > > entry in the DNS. Making existence of a domain depend on a > > > separate registry makes no sense and is inconsistent with > > > longstanding practice. > > > > No, the ultimate authority of whether a domain exists is the registry > > of domain names. > > There is no registry of domain names; there are only registries for a > few zones. Well, ICANN registers the Top level domains for something like 80+ top level zones including country code zones. You can't have a TLD unless you register with ICANN, first, and meet the requirements for a TLD. These TLD sub-registries then have their own rules. ".com" and ".net" are two that are (partially) handled by NetSol. I know that there used to be a database of files which contained the registration info. The DNS Zone files for .com, .net, .org etc were generated by scripts that read these files. That database is accessed by whois, which also accessed the files. I suspect this flat file database has been converted to a relational database, but I can't be sure. When Network solutions was created, the flat files were transfered to them, from SRI, I think. I think there were paper records that were kept, too. When you sent in registation email, scripts would process registration templates into the flat files. Network solutions first added fees to this process. Later, other registries were created. > You could claim that the registry for the other zones is > in a zone file somewhere, and that's the ultimate authority for that > zone, but that would be a stretch. If a domain isn't listed in DNS then > practically speaking it does not exist. No, this isn't the case. A domain may not be in DNS in the case that it exists but is suspended for some reason. There may be other reasons, such as the DNS zones have been updated since the domain was created. > Even if the domain might not be in DNS but still be in the registry for > that zone, and there were a way to query that registry, would you expect > apps to special-case handling of the zones that were defined by > registries? Given that they couldn't get the RRs for that domain > anyway, what would be the point of their doing so? I wouldn't expect that, unless of course, they are other registries trying to register the domain. People keep saying that something has been broken. But in fact, nothing has been broken, except false assumptions that were false to begin with. People have been told these assumptions are false by people on the various DNS lists. They were well aware of the falseness of their assumptions, or they ought to have been. This is not something that is surprising to any reasonable person in any way whatsoever. These people just assumed that if they kept using reverse DNS this way, that they would be able to keep doing it. Well, that isn't how it works, is it? > We've got ~16 years of history that says that NXDOMAIN means that the > domain does not exist, that is fully consistent with the protocol > specifications and which is built into apps. Changing this behavior > would be incompatible with all that code, and VeriSign's attempt to > subvert the COM and NET zones is not a compelling reason to do so. NXDOMAIN means the domain isn't in the DNS distributed databse. It doesn't mean that it isn't registered. However, NXDOMAIN hasn't been wrongly sent. It is not the case that NXDOMAIN _MUST_ be sent. That would preclude wildcard records. 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. There is nothing that says a registry has to return NXDOMAIN instead of a wildcard match. > p.s. Now, with something like LLMNR we might someday have a way of > distributing domain names and their RRsets that is separate from DNS, > and it could be very useful for it to do so. But in order to be viable > it needs to produce results that are consistent with DNS. We can't have > two different lookup services for the same names producing mutually > inconsistent results. > > 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. Just the opposite in fact. The purpose of a wildcard is to match queries that aren't matched by other records. This is legal report and response for any zone. --Dean