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