RE: [alac] [fwd] Re: [council] ALAC statement on resolution of non-existing domain names (from: roessler@xxxxxxxxxxxxxxxxxx)
Thomas -
This is an informative discussion you're having with Jeff and it would be
useful if you could cc the ALAC forum -- <forum@xxxxxxxxxxxxxx> so it can be
posted there as well (with Jeff's agreement). A new topic section will be
added to our forum on this issue and it will be featured on the ALAC
homepage under "Current Issues" (per discussion with Vittorio).
Thanks.
Denise
michel@xxxxxxxxx
-----Original Message-----
From: owner-alac@xxxxxxxxx [mailto:owner-alac@xxxxxxxxx]On Behalf Of
Thomas Roessler
Sent: Wednesday, September 17, 2003 6:15 AM
To: alac@xxxxxxxxx
Subject: [alac] [fwd] Re: [council] ALAC statement on resolution of
non-existing domain names (from: roessler@xxxxxxxxxxxxxxxxxx)
This one just went to the GNSO Council, in reply to Neumann's note
from yesterday.
Regards,
--
Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
At-Large Advisory Committee: http://alac.info/
----- Forwarded message from Thomas Roessler
<roessler@xxxxxxxxxxxxxxxxxx> -----
From: Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
To: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
Cc: council@xxxxxxxx
Date: Wed, 17 Sep 2003 15:11:09 +0200
Subject: Re: [council] ALAC statement on resolution of non-existing domain
names
Mail-Followup-To: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>, council@xxxxxxxx
X-Spam-Level:
I believe that some clarifications are in order with respect to Jeff
Neumann's note, as some of his statements are quite misleading.
1. The statement I forwarded was not a personal statement, but a
committee statement that was also sent to the board. The ALAC had
discussed the issue when NeuStar was experimenting with wildcard
records in .biz, so a quick reaction was easily possible.
2. Sitefinder is not a planned new service about which you'd ask the
operator questions, but has been deployed on the net. Its effect on
protocols is measurable, and its design is documented on the
Verisign web site.
3. When mailing lists and discussion forums around the net are
filled with discussions about the issue, the most constructive
course of action is *not* to call for ALAC-specific input, but
rather to step forward and articulate the fundamental concern that
underlies much of what we are hearing.
That's what we have done, and I'll happily do it again: Sitefinder
is moving error handling decisions away from the edges of the net
(where they belong, where they were happening now, and where they
can best be tuned to fit users' needs), to central servers operated
by Verisign.
4. When operators around the net are scrambling to put measures in
place that undo the effects of Verisign's steps, and when this
demand leads to the release of a new version of BIND that makes this
possible, then this is *not* an indication that the change does not
cause serious problems as it can easily be patched around -- as Jeff
wants councillors to believe --, but rather an indication that
Sitefinder should be taken out of service.
This also illustrates that "grave technical concerns" are probably
an understatement.
5. The gTLD registries constituency should be able to appreciate the
difficulties that are related to making even small global changes to
Internet infrastructure: The problems encountered in rolling out new
gTLDs illustrate this. They also illustrate just how important
adherence to standards and design principles is for *all* parts of
the Internet community.
gTLD registries bear a specific responsibility for the reliable
functioning of a core part of the Internet's infrastructure.
Breaking design principles that underly the net is not compatible
with this responsibility.
6. Jeff's statement that sitefinder "only redirects web sites" is
NOT TRUE. A records are being used by virtually all TCP/IP based
protocols. VIRTUALLY ALL TCP/IP BASED PROTOCOLS ARE AFFECTED BY
SITEFINDER.
7. Jeff's statement that sitefinder does not affect e-mail because
no MX records are involved in the service is NOT TRUE. More
specifically, section 5 of RFC 2821 mandates an "implicit MX" rule:
When no MX records are present for a domain name, but an A record
exists, then e-mail software will directly try to deliver messages
to the host pointed at by the A record. E-MAIL IS BEING AFFECTED BY
THIS.
That's why Verisign has put a "Snubby Mail Rejector Daemon" in
place, by the way; unfortunately, this is a poorly-written piece of
software that leads to problems by itself.
8. Talking about specific implications, sitefinder is breaking spam
filters throughout the net, it's impacting e-mail delivery, it's
even breaking network printing in some places. More generally, it
confuses users of any TCP/IP-based services -- a refused connection
(or a timeout, when the service is down) is often an indicator of
temporary network or server problems, and not something that would
cause the user to re-check a domain name he has typed in.
I'm looking forward to discussing this issue on the next council
call.
Kind regards,
--
Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
At-Large Advisory Committee: http://alac.info/
On 2003-09-16 15:05:27 -0400, Jeff Neuman wrote:
> From: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
> To: 'Thomas Roessler' <roessler@xxxxxxxxxxxxxxxxxx>, council@xxxxxxxx
> Date: Tue, 16 Sep 2003 15:05:27 -0400
> Subject: RE: [council] ALAC statement on resolution of non-existing domain
> names
> Return-Receipt-To: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
> X-Spam-Level:
>
> Thomas, I believe you have characterizations in this note without any
> back-up. To state there are "grave technical concerns" is probably one of
> the greatest overstatements that I have heard in a long time. Before
coming
> to any conclusions in your study, I would first submit a list of questions
> to VeriSign to answer and then gather input from the community (if you so
> desire).
>
> For example, it is my understanding that VeriSign has devised a method, as
> we have as well (in our test several months ago), of only redirecting
> websites and not MX records. Therefore, e-mail is unaffected.
>
> Also, when stating that "users are deprived the opportunity of
> choosing....". Please provide examples of this? What users do you know
> that "choose" how they get an error message back. For example, do those
who
> use MSN browser "choose" to get an MSN search redirect rather than an
error
> message? And what is to stop other browsers from doing the same thing.
In
> addition, please provide concrete examples as to how software makers are
> being deprived. Thomas, I am a little disappointed in your analysis as it
> provides broad generalizations and no proof. Lets get past emotion and
get
> the true real concrete facts out on the table. Yes, there are
applications
> out there that depend on the error message. However, these applications
can
> easily be updated to accomplish the same functionality. In fact, I
noticed
> a patch on the OpenSRS list that someone devised (in less than 24 hours)
> which updates many DNS programs.
>
> Rather than giving the "technical purist" argument (i.e., the Internet is
a
> sacred animal and anything that alters some of the functionally of the
past
> is "grave"), please provide us with concrete examples, which you have
> tested, in which the technical parameters of the internet are violated and
> explain in detail exactly how the every day common user of the Internet is
> affected.
>
> There are two sides to every coin. Are you also examining the benefit to
> the common Internet user that may be looking for a place to go on the
> Internet and cannot find his or her way? What about the benefits of a
> search engine to make the Web more easily navigable? Or has the ALAC
> already reached the same conclusion you have (in less than 24 hours).
>
> The VeriSign service has been alive and well for 24 hours? Did the
Internet
> break? One last note.....to show that the MX records are still returning
> errors, I have attached an error e-mail message which took less than 4.5
> seconds to get returned to my inbox (yes, I did time it). I would say the
> Internet as we know it is alive and well.
>
> Thomas, I would urge that if you truly intend to study this, that you
create
> a MUCH more objective Issue Statement. I am not saying you shouldn't
> continue to study, but I, like the rest of this council, should start with
> an open mind.
>
> Thanks.
>
> Jeff
>
>
>
> -----Original Message-----
> From: Thomas Roessler [mailto:roessler@xxxxxxxxxxxxxxxxxx]
> Sent: Tuesday, September 16, 2003 2:22 PM
> To: council@xxxxxxxx
> Subject: [council] ALAC statement on resolution of non-existing domain
> names
>
>
> For your information.
>
>
>
> The At-Large Advisory Committee would like to bring to ICANN's
> attention concerns about Verisign's surprising roll-out of the
> "SiteFinder" service for .com and .net.
>
> SiteFinder works by re-directing queries for non-existing domain
> names to the IP address of a search service that is being run by
> Verisign.
>
> This practice raises grave technical concerns, as it de facto
> removes error diagnostics from the DNS protocol, and replaces them
> by an error handling method that is tailored for HTTP, which is just
> one of the many Internet protocols that make use of the DNS. We will
> leave it for others to explain the details of these concerns, but
> note that returning resource records in a way which is countrary to
> the very design of the DNS certainly does not promote the stability
> of the Internet.
>
> These concerns are not mitigated by Verisign's efforts to work
> around the consequences of breaking the Internet's design on a
> service-by-service basis: These workarounds make specific
> assumptions on the conclusions that Internet software would be
> drawing from nonexisting domain names; these assumptions are not
> always appropriate.
>
> When working as intended, the service centralizes error handling
> decisions at the registry that are rightly made in application
> software run on users' computers. Users are deprived of the
> opportunity to chose those error handling strategies best suited for
> their needs, by chosing appropriate products available on a
> competitive marketplace. Software makers are deprived of the
> opportunity to compete by developing innovative tools that best
> match the user's needs.
>
> We urge ICANN to take whatever steps are necessary to stop this
> "service."
>
> --
> Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
> At-Large Advisory Committee: http://alac.info/
>
>
Content-Description: Returned mail: see transcript for details
> From: Mail Delivery Subsystem <MAILER-DAEMON@xxxxxxxxxxx>
> To: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
> Date: Tue, 16 Sep 2003 14:58:35 -0400
> Subject: Returned mail: see transcript for details
>
> The original message was received at Tue, 16 Sep 2003 18:58:35 GMT
> from [10.32.90.4]
>
> ----- The following addresses had permanent fatal errors -----
> <hkjhlkjhliuhoihoih@xxxxxxxxxxxxxxxx>
> (reason: 550 User domain does not exist.)
>
> ----- Transcript of session follows -----
> ... while talking to kjkjhlkhlkjh.com.:
> >>> RCPT To:<hkjhlkjhliuhoihoih@xxxxxxxxxxxxxxxx>
> <<< 550 User domain does not exist.
> 550 5.1.1 <hkjhlkjhliuhoihoih@xxxxxxxxxxxxxxxx>... User unknown
>
> From: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
> To: "'hkjhlkjhliuhoihoih@xxxxxxxxxxxxxxxx'"
<hkjhlkjhliuhoihoih@xxxxxxxxxxxxxxxx>
> Date: Tue, 16 Sep 2003 14:59:51 -0400
> Subject: test
> Return-Receipt-To: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
>
>
> Jeffrey J. Neuman, Esq.
> Director, Law & Policy
> NeuStar, Inc.
> Loudoun Tech Center
> 46000 Center Oak Plaza
> Building X
> Sterling, VA 20166
> p: (571) 434-5772
> f: (571) 434-5735
> e-mail: Jeff.Neuman@xxxxxxxxxx <mailto:Jeff.Neuman@xxxxxxxxxx>
>
> The information contained in this e-mail message is intended only for the
> personal and confidential use of the recipient(s) named above. This
message
> may be an attorney-client communication and/or work product and as such is
> privileged and confidential. If the reader of this message is not the
> intended recipient or an agent responsible for delivering it to the
intended
> recipient, you are hereby notified that you have received this e-mail
> message and any attachments hereto in error and that any review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
notify
> us immediately by e-mail, and delete the original message.
>
>
----- End forwarded message -----