<<< Date Index >>>     <<< Thread Index >>>

Re: [alac] [fwd] RE: [council] ALAC statement on resolution of non-existing domain names (from: Jeff.Neuman@xxxxxxxxxx)


Back-ups are there! I sent a mail to nobody@xxxxxxxxxxxxxxxxx - a
non-existent domain 4 hours ago. It is still sitting in my mail queue.

Mreply: read error from sundayfolayan.com.
$_IDENT:sfolayan@xxxxxxxxxxxxxxxxxxxx []
Mreply: read error from sundayfolayan.com.
rRFC822; nobody@xxxxxxxxxxxxxxxxx
H?P?Return-Path: <Ag>
H??Date: Tue, 16 Sep 2003 16:16:40 +0100 (WAT)
H??From: Sunday Folayan <sfolayan@xxxxxxxxxxxxxx>
H??X-Sender: sfolayan@xxxxxxxxxxxxxxxx
H??Reply-To: sfolayan@xxxxxxxxxxxxxx
H??To: nobody@xxxxxxxxxxxxxxxxx
H??Subject: Testing Verisign

The important thing is that the same feature can be built into browsers
(HTTP alone), not necessarily DNS - which affects all other services, in
this case - SMTP.

That i am wet, is not the only proof that it is raining. I just can look
out of the window - That is assuming that I am not blind.


On Tue, 16 Sep 2003, Thomas Roessler wrote:

> Date: Tue, 16 Sep 2003 21:29:46 +0200
> From: Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
> To: alac@xxxxxxxxx
> Subject: [alac] [fwd] RE: [council] ALAC statement on resolution of
    non-existing domain names (from: Jeff.Neuman@xxxxxxxxxx)
> FYI.
> -- 
> Thomas Roessler  <roessler@xxxxxxxxxxxxxxxxxx>
> At-Large Advisory Committee: http://alac.info/
> ----- Forwarded message from "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx> -----
> 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 []
>    ----- 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 -----