[registrars] FW: [council] ALAC statement on resolution of non-existing domain names
- To: <registrars@xxxxxxxx>
- Subject: [registrars] FW: [council] ALAC statement on resolution of non-existing domain names
- From: "Tim Ruiz" <tim@xxxxxxxxxxx>
- Date: Wed, 17 Sep 2003 08:11:21 -0500
- Importance: Normal
- Sender: owner-registrars@xxxxxxxxxxxxxx
Posted at the request of Jeff Neuman.
From: Neuman, Jeff [mailto:Jeff.Neuman@xxxxxxxxxx]
Sent: Wednesday, September 17, 2003 6:53 AM
To: 'Tim Ruiz'; Neuman, Jeff
Subject: RE: [council] ALAC statement on resolution of non-existing
I am merely stating that there are two sides to the debate and before
to a conclusion, both sides should be heard. I am enclosing a response
SESAC to the IAB statement that you reference. I would appreciate you
posting this to the Registrars list so that they can see as well.
From: Steve Crocker [mailto:steve@xxxxxxxxxxxx]
Sent: Monday, August 04, 2003 5:14 PM
To: Paul Twomey; 'Dan Halloran'
Subject: [secsac] SECSAC recommendation re VGRS
Paul and Dan,
The SECSAC hereby forwards its recommendation to the board regarding
Verisign's announced support for international domain names. This
recommendation has been delayed, for which we offer both an apology and
In this particular case, the SECSAC was drawn into the discussion after
Stuart Lynn contacted the IAB for advice on this matter. We deliberated
came to the consensus opinion included below. However, the IAB had also
responded with a noticeably different opinion. We would normally expect
IAB and the SECSAC to have quite similar views on matters of technology,
architecture and security, so we held off submitting our recommendation
an attempt to coordinate our thinking with the IAB's. Unfortunately, we
not able to engage the IAB in this discussion and time continued to
Finally, Geoff Huston sent a reply on behalf of the IAB. This is
As you might expect, the IAB and the SECSAC have taken this opportunity
establish closer ties to each other so as to improve communication
our groups. We expect this will strengthen the quality of our advice
Chair, Security and Stability Advisory Committee
SECSAC comments on VGRS
We have followed the exchange between the IAB and Verisign in which the
has raised particular technical issues regarding Verisign's announced
support for international domain names. Verisign has responded that it
in the process of changing what it is doing to address those concerns.
committee has no issue with what Verisign is doing.
This is a brief description of what Verisign is currently doing and
Any DNS query to a Verisign server with an eighth bit set in an octet
the second label of a domain name would receive an IP address record (A
in its response, i.e., the address of a special purpose Verisign server.
The resulting action by the client would be to make a connection (or use
to deliver its data) to the indicated address. The current behavior of
Verisign server is to ignore (silently drop) all connection requests and
packets received other than tcp/80 (HTTP).
Upon receiving a tcp/80 connection request, the Verisign server uses the
additional information in the HTTP request (it would also contain the
domain name with an eighth bit set that was received in the DNS
query) to identify the various international domain names (IDNs) that
match the domain name. The client web browser will receive a web page
presents the various alternatives and an opportunity to download a
that fixes the incorrect behavior, i.e., the plug-in ensures that future
queries are properly encoded before being sent to a DNS server. If the
chooses not to download the plug-in they can simply select the desired
from the list offered and they will be redirected there immediately.
Verisign has indicated that the planned behavior (scheduled for
sometime after mid-May) in response to connection requests to the
purpose server is as follows:
- Connection requests to tcp/25 (SMTP) will be accepted but any mail
sent will be rejected with a 550 response code with human-readable
error message text. This will have the have effect of stopping the
attempted delivery of undeliverable messages.
- Any TCP connection attempts to ports other than 80 (HTTP) and 25
(SMTP) will be reset, i.e., the same behavior any ordinary host would
exhibit when receiving a connection to a port without a listening
- Any UDP packets received will result in an ICMP port unreachable
response, i.e., the same behavior any ordinary host would exhibit when
receiving a similar packet to a port without a listening process.
The technical issue is that the DNS protocol requires that when names as
presented (QNAMEs) do not exist the correct reply is "non-existent
(NXDOMAIN). However, as an operational matter, we also know that a
significant fraction of all queries are for NXDOMAINs (in the case of
root servers it is the majority). Verisign is simply observing that
number of the queries it gets are not really for NXDOMAINs but are
incorrectly because the software making the query is "broken."
In that context they are a providing a service for those users with
software. They are both providing a way for the user to get the answer
actually want and providing a plugin that ensures the user will not have
this problem in the future (bootstrapping the deployment of IETF
The downside is that some number of users who do such broken things
queries for a non-existent domain name with the eighth bit set in one of
octets) get a response with an address in it. If the application being
by the client user is web-based (e.g., a browser), then they will get
web page described above. All other applications will not get the most
desirable response, since preferred response should have been NXDOMAIN
the DNS. This is not a technically correct interpretation of the DNS
More generally, what Verisign is doing is deploying a mapping layer on
of the DNS, in this case primarily to assist some number of users.
Similarly, the following registries are providing a mapping layer on top
Specifically, they are returning "wildcard" address records for
domain names. The web page they display when attempting to connect to a
non-existent domain name is a sales pitch attempting to sell it to you.
some cases the sales pitch is an auction offering the domain name to the
The critical difference between what these example sites are doing and
Verisign is doing is that Verisign is providing a service that
the use of the web by users, without offering a "sale." The example
above are using the opportunity to sell domain names to the highest
If we are to take issue with what Verisign is doing, then we it seems
reasonable to take issue with the others as well. However, although the
practices give us some discomfort, we can't really see a technical basis
objecting to what Verisign is doing.
Verisign's original announcement:
VeriSign Enables Companies to Enhance Their Online Brands in
Virtually Any Language Using Internationalized Domain Names
IAB's response to the request:
Verisign's response to the IAB response:
Verisign's followup announcement:
VeriSign Confirms Support for IETF IDN Standard
30 July 2003
ICANN Security and Stability Advisory Committee
I refer to your note of the 19th May 2003 to the Chair of the Internet
Architecture Board (IAB), seeking to coordinate your committee's views
Verisign Global Registry Services (VGRS) Internationalized Domain Name
services (IDN) with the published views of the IAB.
Your letter notes that the ICANN Security and Stability Advisory
(SECSAC) does not appear to be as uncomfortable with Verisign's
the IAB appears to be, and you are seeking to compare notes on this.
It is noted that the IAB response refers specifically to the proposal to
synthesize A records for certain queries, and did not address the
proposal to synthesize NS records in response to queries for
domains. The IAB has not yet reached any conclusion as to whether this
subsequent VGRS proposal adequately addresses the IAB's original areas
In reviewing the documents, the IAB agrees that it does appear that the
and SECSAC are looking at this practice from different perspectives. The
took the position of comparing the VGRS proposal to the standard
specifications, and noted a number of aspects of the proposal where the
mechanism did not conform to these standard specifications. The SECSAC
appears to have looked at this matter from the perspective of
The expressed differences in opinion are therefore not surprising. The
feels that the most helpful way to provide some clarification of these
issues is to document them clearly as general questions relating to the
intended behavior of the DNS. This is currently underway within the IAB.
IAB then intends to take these general questions to a larger IETF forum
discussion. Clear outcomes from this consideration will be passed to
for their consideration.
IAB Executive Director,
for the IAB
From: Tim Ruiz [mailto:tim@xxxxxxxxxxx]
Sent: Wednesday, September 17, 2003 5:16 AM
Subject: RE: [council] ALAC statement on resolution of non-existing
Jeff Neuman wrote:
>To state there are "grave technical concerns" is probably one of
>the greatest overstatements that I have heard in a long time.
The IAB has responded to a similar issue regarding VeriSign's
implementation of IDN. Their conclusion:
"...the system...contains significant DNS protocol errors, risks the
further development of secure DNS, and confuses the resolution
mechanisms of the DNS with application-based search systems."
That sounds pretty grave to me.
Full text of their response can be found at