Verisign vs. ICANN

Tue Jun 22 05:24:45 UTC 2004

Re: Verisign vs. ICANNThanks, Dickson - next time I'll try to write exact text  from the very beginniong -:). This is
_exactly_ what I want to say, with examples I was too lazy to write myself.

  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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20040621/f7bda958/attachment.html>