<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>Re: Verisign vs. ICANN</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Stephen J. Wilcox (SJW) wrote:</FONT>
<BR><FONT SIZE=2>SJW> I do not believe there is any technical spec prohibiting this,</FONT>
<BR><FONT SIZE=2>SJW> in fact that DNS can use a wildcard at any level is what enables</FONT>
<BR><FONT SIZE=2>SJW> the facility.</FONT>
</P>
<P><FONT SIZE=2>It is not always the case that everything a spec defines, is included</FONT>
<BR><FONT SIZE=2>or enumerated in the spec, particularly when specs refer to other specs</FONT>
<BR><FONT SIZE=2>and it is the combination(s) of specs which define proper behaviour.</FONT>
</P>
<P><FONT SIZE=2>(If every protocol which was built on TCP, had to also include the contents</FONT>
<BR><FONT SIZE=2>of the TCP spec, the whole RFC system would quicly collapse under its own</FONT>
<BR><FONT SIZE=2>weight.)</FONT>
</P>
<P><FONT SIZE=2>SJW> I think this is a non-technical argument..</FONT>
<BR><FONT SIZE=2>SJW> altho it was demonstrated that owing to the age and status of the com/net</FONT>
<BR><FONT SIZE=2>SJW> zones a number of systems are now in operation which make </FONT>
<BR><FONT SIZE=2>SJW> assumptions about the response in the event of the domain not existing...</FONT>
</P>
<P><FONT SIZE=2>If it were merely an *internal* issue *within* the DNS system, perhaps there</FONT>
<BR><FONT SIZE=2>would be areas of disagreement which could be settled via either extending,</FONT>
<BR><FONT SIZE=2>or clarifying, the relevant RFCs. However, the issue is, to some degree,</FONT>
<BR><FONT SIZE=2>actually outside of the proper scope of the DNS lookup/resolver system.</FONT>
<BR><FONT SIZE=2>(see below...)</FONT>
</P>
<P><FONT SIZE=2>On Sat, 19 Jun 2004, Alexei Roudnev (AR) wrote:</FONT>
<BR><FONT SIZE=2>AR> The technical roots of the problem are: proposed services VIOLATES</FONT>
<BR><FONT SIZE=2>AR> internet specification (which is 100% clean - if name do not exist,</FONT>
<BR><FONT SIZE=2>AR> resolver must receive negative response).</FONT>
<BR><FONT SIZE=2>AR> So, technically, there is not any ground for SiteFinder - vice versa</FONT>
</P>
<P><FONT SIZE=2>To make Alexei's argument's syntax agree with the intended semantics:</FONT>
</P>
<P><FONT SIZE=2>He means to say, "Technically, there is no grounds for implementing SiteFinder</FONT>
<BR><FONT SIZE=2>by means of inserting wildcards to the .com and .net zones. Rather, there</FONT>
<BR><FONT SIZE=2>are specific grounds for *not* inserting wildcards, regardless of the purpose</FONT>
<BR><FONT SIZE=2>of those wildcards, in .net and .com zones.</FONT>
</P>
<P><FONT SIZE=2>(E.g.: in contrast with .museum zone, which is generally special-purpose,</FONT>
<BR><FONT SIZE=2>and for which assumptions about which services are expected (www only)</FONT>
<BR><FONT SIZE=2>are reasonable and valid, the .com and .net zone are general-purpose,</FONT>
<BR><FONT SIZE=2>and pretty much any service, including all assigned values for TCP and UDP</FONT>
<BR><FONT SIZE=2>ports from the IANA, should and must be presumed to be used across the</FONT>
<BR><FONT SIZE=2>collection of IPv4 space.)</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>The DNS *resolver* system, is only one of the places where the global namespaces is *implemented*.</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>An assigned name, however, can *also*, or even *instead* of being placed into</FONT>
<BR><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>And, most importantly, *cannot* be worked around, *period*.</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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?).</FONT></P>
<P><FONT SIZE=2>Brian Dickson</FONT>
<BR><FONT SIZE=2>(who has had to deploy systems in heterogeneous environments, and is aware</FONT>
<BR><FONT SIZE=2>of deployed systems that broke because of *.com)</FONT>
</P>
</BODY>
</HTML>