[71725] in North American Network Operators' Group
Re: Verisign vs. ICANN
daemon@ATHENA.MIT.EDU (Alexei Roudnev)
Tue Jun 22 01:25:29 2004
From: "Alexei Roudnev" <alex@relcom.net>
To: "Dickson, Brian" <BDickson@arbinet.com>, <nanog@merit.edu>
Date: Mon, 21 Jun 2004 22:24:45 -0700
Errors-To: owner-nanog-outgoing@merit.edu
This is a multi-part message in MIME format.
------=_NextPart_000_0C99_01C457DE.8E1C6BC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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)
------=_NextPart_000_0C99_01C457DE.8E1C6BC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: Verisign vs. ICANN</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Thanks, Dickson - next time I'll try to write exact =
text =20
from the very beginniong -:). This is _exactly_ what I want to say, with =
examples I was too lazy to write myself.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<P><FONT size=3D2>To make Alexei's argument's syntax agree with the =
intended=20
semantics:</FONT> </P>
<P><FONT size=3D2>He means to say, "Technically, there is no grounds =
for=20
implementing SiteFinder</FONT> <BR><FONT size=3D2>by means of =
inserting=20
wildcards to the .com and .net zones. Rather, there</FONT> <BR><FONT=20
size=3D2>are specific grounds for *not* inserting wildcards, =
regardless of the=20
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=20
special-purpose,</FONT> <BR><FONT size=3D2>and for which assumptions =
about which=20
services are expected (www only)</FONT> <BR><FONT size=3D2>are =
reasonable and=20
valid, the .com and .net zone are general-purpose,</FONT> <BR><FONT =
size=3D2>and=20
pretty much any service, including all assigned values for TCP and =
UDP</FONT>=20
<BR><FONT size=3D2>ports from the IANA, should and must be presumed to =
be used=20
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=20
which *no* workaround exists, and for which no workaround *can* exist, =
from a=20
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=20
global namespaces is *implemented*.</FONT> </P>
<P><FONT size=3D2><STRONG><EM>Any assigned DNS name *may* be placed =
into the=20
DNS. And *only* the owner of that name has authority to register that =
name, or=20
cause its value to return from any query.</EM></STRONG></FONT></P>
<P><FONT size=3D2>An assigned name, however, can *also*, or even =
*instead* of=20
being placed into</FONT> <BR><FONT size=3D2>the DNS *resolver* system, =
be put=20
into other systems for resolving and returning name->address =
mappings.=20
These include: the predecessor to BIND, which is the archaic =
"/etc/hosts"=20
file(s) on systems; Sun's NIS or NIS+ systems (local to any NIS/NIS+ =
domain=20
space); LDAP and similar systems; X.500 (if this is by any chance =
distinct=20
from LDAP - I'm no expert on either); and any other arbitrary system =
for=20
implementing name->address lookups.</FONT></P>
<P><FONT size=3D2><STRONG><EM>And the primary reason for *REQUIRING* =
NXDOMAIN=20
results in DNS, is that in any host system which queries multiple =
sources,=20
only a negative response on a lookup will allow the search to continue =
to the=20
next system in the search order.</EM></STRONG></FONT></P>
<P><FONT size=3D2>Implementing root-zone wildcards, places =
restrictions on both=20
search-order, and content population, of respective name-resolution =
systems,=20
which violates any combination of RFCs and best-common =
practices.</FONT></P>
<P><STRONG><EM><FONT size=3D2>And, most importantly, *cannot* be =
worked around,=20
*period*.</FONT> </EM></STRONG></P>
<P><FONT size=3D2>Until the RFCs are extended to permit population of =
zones with=20
authoritative *negative* information, and all the servers and =
resolvers=20
implement support for such, *and* operators of root zone databases=20
automatically populate assigned zones with such negative values, =
wildcards=20
*will* break, in unreconcileable fashion, existing, deployed systems =
which=20
refer to multiple implementations of zone information services, and =
for which=20
*no* workaround is possible.</FONT></P>
<P><FONT size=3D2>Apologies for a long, semi-on-topic post. Hopefully =
this will=20
end this thread, and maybe even put a stake through the heart of the =
VeriSign=20
filing (at least this version of it). While the law generally doesn't=20
recognize mathematically excluded things as a matter of law, when it =
comes to=20
affirmative testimony, counter-arguments can demonstrably be shown as =
de-facto=20
purgury (sp?).</FONT></P>
<P><FONT size=3D2>Brian Dickson</FONT> <BR><FONT size=3D2>(who has had =
to deploy=20
systems in heterogeneous environments, and is aware</FONT> <BR><FONT =
size=3D2>of=20
deployed systems that broke because of *.com)</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0C99_01C457DE.8E1C6BC0--
