To make Alexei's argument's syntax agree with the intended
semantics:
He means to say, "Technically, there is no grounds for
implementing SiteFinder
by means of inserting
wildcards to the .com and .net zones. Rather, there
are specific grounds for *not* inserting wildcards, regardless of the
purpose
of those wildcards, in .net and .com
zones.
(E.g.: in contrast with .museum zone, which is generally
special-purpose,
and for which assumptions about which
services are expected (www only)
are reasonable and
valid, the .com and .net zone are general-purpose,
and
pretty much any service, including all assigned values for TCP and UDP
ports from the IANA, should and must be presumed to be used
across the
collection of IPv4 space.)
The crux of the problem appears in a particular case, for
which *no* workaround exists, and for which no workaround *can* exist, from a
straight derivational logic of state-machine origins.
The DNS *resolver* system, is only one of the places where the
global namespaces is *implemented*.
Any assigned DNS name *may* be placed into the
DNS. And *only* the owner of that name has authority to register that name, or
cause its value to return from any query.
An assigned name, however, can *also*, or even *instead* of
being placed into
the DNS *resolver* system, be put
into other systems for resolving and returning name->address mappings.
These include: the predecessor to BIND, which is the archaic "/etc/hosts"
file(s) on systems; Sun's NIS or NIS+ systems (local to any NIS/NIS+ domain
space); LDAP and similar systems; X.500 (if this is by any chance distinct
from LDAP - I'm no expert on either); and any other arbitrary system for
implementing name->address lookups.
And the primary reason for *REQUIRING* NXDOMAIN
results in DNS, is that in any host system which queries multiple sources,
only a negative response on a lookup will allow the search to continue to the
next system in the search order.
Implementing root-zone wildcards, places restrictions on both
search-order, and content population, of respective name-resolution systems,
which violates any combination of RFCs and best-common practices.
And, most importantly, *cannot* be worked around,
*period*.
Until the RFCs are extended to permit population of zones with
authoritative *negative* information, and all the servers and resolvers
implement support for such, *and* operators of root zone databases
automatically populate assigned zones with such negative values, wildcards
*will* break, in unreconcileable fashion, existing, deployed systems which
refer to multiple implementations of zone information services, and for which
*no* workaround is possible.
Apologies for a long, semi-on-topic post. Hopefully this will
end this thread, and maybe even put a stake through the heart of the VeriSign
filing (at least this version of it). While the law generally doesn't
recognize mathematically excluded things as a matter of law, when it comes to
affirmative testimony, counter-arguments can demonstrably be shown as de-facto
purgury (sp?).
Brian Dickson
(who has had to deploy
systems in heterogeneous environments, and is aware
of
deployed systems that broke because of *.com)