Skip to main content
Resources

Message from the Internet Architecture Board to Stuart Lynn

[Note: Bracketed paragraph numbers have been inserted for ease of future reference.]

Subject: Re: Request for Advice on VGRS IDN Announcement
Date: Sat, 25 Jan 2003
From: Geoff Huston
To: M. Stuart Lynn

Dear Stuart,

[1] Thanks for your message. After reviewing the announcement, examining the behavior of the deployed system, discussing the issue with colleagues external to the IAB, and meeting with VeriSign's technical staff to go over the system's aim and implementation, the IAB has come to the following consensus.

[2] The IAB feels that the system VeriSign had deployed for .com and .net 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. The IAB understands the efforts that VeriSign has made to limit the applicability of this system to queries which would normally not correspond to registered domains, and it recognizes the importance of the distribution of IDN-capable systems to end users. While the IAB agrees with VeriSign that rapid adoption of IDN-capable systems is desirable, the IAB feels that the very limited gain in distribution cannot balance the shortcomings of this deployment strategy.

[3] The IAB has begun the process of shepherding the creation of an Informational RFC on concerns with operational practices with the DNS. We anticipate discussing the issues raised in your notes in more detail as part of that document. Given the scope of the issue, and our desire to ensure that it will have adequate review by the (DNS) operational community, we will be enlisting the help of the broader IETF community through relevant IETF working groups. In advance of that document, we have outlined below the issues with the VeriSign system which led us to the conclusion above.

[4] As a lookup system, the DNS is designed to provide authoritative answers to queries. The DNS protocol specifies behavior for queries whose targets do occur in a zone by describing the data format for the specific resource records and the wire format for the response. The DNS protocol also specifies behavior for queries whose targets do not occur in a zone by describing the wire format for a negative response.

[5] The system deployed for .com and .net does not follow the specification for targets not in a zone. Instead, it examines the target and decides whether to give the specified negative response or a synthesized record based on whether the target contains a code point above 127. This is a violation of the DNS protocol as described in RFC 2308, Section 2.1. While it is possible within the DNS protocol to include wildcard records which cover all queries not otherwise specified by a zone, this is not what VeriSign has done. Negative answers for records which do not contain code points above 127 continue to be sent.

[6] It would, of course, be theoretically possible to add zone entries for all records containing code points above 127. Given that the Verisign system does not recognize "." as a label delimiter for testing these records, the size of the resulting zone is unimaginably large. VeriSign confirms that they are not managing a zone of the size this would imply and is, instead, synthesizing these entries. This implies that the zone as currently served by VeriSign cannot be transferred using either AXFR or file transfers in master file format. Though the choice of who may employ AXFR or file transfer to get copies of a zone is a policy decision, the IAB notes that the current system does not allow any of the standard methods for transfer to be used.

[7] More importantly, queries against these new synthesized entries should follow the same specifications as those for any other entry in same zone. The system deployed for .com and .net does not. Queries for A (Address) RRs for the name \248l.com return A RRs, but queries for other types such as NS (name server) or MX (mail exchange) return an NXDOMAIN (no such domain) response, which would implies that there are no records of any type at the name \248l.com. To put this more strongly: a DNS implementation with negative response caching enabled (highly recommended, in order to reduce the number of unnecessary queries sent to the root and TLD servers) would come to different conclusions about the existence of the A RRs for the name \248l.com depending on the precise order of query operations it had processed in the recent past. For the order of the queries issued to result in different responses is a serious data integrity issue.

[8] Other data integrity issues are commonly cited as key reasons for the deployment of DNSSEC. The IAB notes that the system deployed for .com and .net cannot be administered under any current proposal for DNSSEC without maintaining an online signing key. There are well-known security threats to any online signing system, but this also poses a significant risk of denial of service, because the combination of synthesized records and online signing is prohibitively expensive. While DNSSEC is not yet deployed, the IAB believes that this design sets a precedent which, if it remains or has spread elsewhere when DNSSEC deployment starts, would cause serious operational problems.

[9] Without DNSSEC, operators often rely on data checks using related data sources. As a registry, the .com and .net zone operator would normally provide data on entries in the .com and .net zones via provisioning protocols (such as EPP) and information service protocols (such as whois). Since these synthesized entries have no corresponding entries in the information service protocol, the normal diagnostic methods of following data from one protocol to another will fail.

[10] The system VeriSign has deployed for .com and .net has made some provisions to assist in the diagnosis of problems. The hosts corresponding to the A records returned to these queries listen on two ports: 25 (SMTP) and 80 (HTTP). Efforts to connect to send mail via port 25 are met by immediate failure at the MTA level, and an explanatory message is sent; this allows the sending or intermediate MTA to immediately return an error and thus avoids queuing of mail sent to addresses using these names. HTTP connections are examined and their host and user-agent headers used to construct a response.

[11] While the effort is well meant, there are several problems with this approach. First, any attempt to connect to ports other than 25 and 80 is refused. For any application which treats connection refused errors as transient, that application's external time-out must be reached before the user is notified and any queued traffic is discarded. While VeriSign has handled this issue for SMTP, the more general case is still a problem.

[12] Second, the examination of the host and user-agent headers to construct a response results in essentially two messages: a 404 error indicating that the resource is unavailable or a web page which presents a guess about what domain or domains might have been the target of the query and possibly a pointer to the VeriSign plug-in. The first response is a misuse of the 404 response code as described in RFC 2616, section 10.4.5; an application level error like 404 is not a replacement for the DNS-level NXDOMAIN. Though this may appear to be a minor error since the user experience is often similar, it is important to remember that not all systems using the DNS have human users. While a human user may have the insight to recognize that a 404 error occurred because the host is not present, despite a previously successful DNS response, systems or agents without human users cannot make a similar deduction.

[13] In the case where a web page is returned, the IAB is particularly concerned that the page contains guesses about what domain might have been the target. Part of this concern arises because the domains which are presented are not consistent from platform to platform and the inputs which result in a particular response do not seem to follow the expected standards. The greater part of the concern, however, comes from a fundamental bias against presenting multiple choices to a DNS query, even mediated by an HTTP-based application. The DNS is not a search service, and presenting speculative mappings based on HTTP inputs is not the service that the registry is expected to provide.

[14] At the core of all of the IAB's concerns is the architectural principle that the DNS is a lookup service which must behave in an interoperable, predictable way at all levels of the DNS hierarchy. Furthermore, as a lookup service it is such a fundamental part of the Internet's infrastructure that converting it to an application-based search service, as the deployed system does, is not appropriate even in the case where the query presented would not normally map to a registered domain.

[15] To restore the data integrity and predictability of the DNS infrastructure, the IAB believes it would be best to return the .com and .net TLD servers to the behavior specified by the DNS protocols. VeriSign should, of course, be free to continue to distribute its plug-in in other ways, and we hope with them that the deployment of IDN-capable systems is as rapid as possible.

best regards,


The IAB
per Geoff Huston
IAB Executive Director

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."