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