RE: [council] ALAC statement on resolution of non-existing domain names
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@does-not-exist.org] Sent: Tuesday, September 16, 2003 2:22 PM To: council@dnso.org 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@does-not-exist.org> At-Large Advisory Committee: http://alac.info/
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@does-not-exist.org> At-Large Advisory Committee: http://alac.info/ On 2003-09-16 15:05:27 -0400, Jeff Neuman wrote:
From: "Neuman, Jeff" <Jeff.Neuman@neustar.us> To: 'Thomas Roessler' <roessler@does-not-exist.org>, council@dnso.org 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@neustar.us> 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@does-not-exist.org] Sent: Tuesday, September 16, 2003 2:22 PM To: council@dnso.org 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@does-not-exist.org> At-Large Advisory Committee: http://alac.info/
Content-Description: Returned mail: see transcript for details
From: Mail Delivery Subsystem <MAILER-DAEMON@NeuStar.com> To: "Neuman, Jeff" <Jeff.Neuman@neustar.us> 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@kjkjhlkhlkjh.com> (reason: 550 User domain does not exist.)
----- Transcript of session follows ----- ... while talking to kjkjhlkhlkjh.com.:
RCPT To:<hkjhlkjhliuhoihoih@kjkjhlkhlkjh.com> <<< 550 User domain does not exist. 550 5.1.1 <hkjhlkjhliuhoihoih@kjkjhlkhlkjh.com>... User unknown
From: "Neuman, Jeff" <Jeff.Neuman@neustar.us> To: "'hkjhlkjhliuhoihoih@kjkjhlkhlkjh.com'" <hkjhlkjhliuhoihoih@kjkjhlkhlkjh.com> Date: Tue, 16 Sep 2003 14:59:51 -0400 Subject: test Return-Receipt-To: "Neuman, Jeff" <Jeff.Neuman@neustar.us>
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@Neustar.us <mailto:Jeff.Neuman@Neustar.us>
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.
participants (2)
-
Neuman, Jeff -
Thomas Roessler