Ted Hardie wrote:Also, while I expect the IAB will shepherd the creation of and take responsibility for the content of said document, any of the plans I have heard so far suggest the IAB will not create this document alone -- nor should it.
[To which Leslie replied:]
I suggest: "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. We expect to have the document drafted by <reasonable estimate here>."
[And Ted responded:]
Is this "drafted for review by the operational community" or "drafted
with the input of the operational community"? I think we can stick
ourselves with the first date, but that the second date needs IESG &
WG Chair input and buy-in. I'd suggest saying "We expect to refer a
draft of the document to the relevant IETF working groups by
<reasonable estimate here>."
Leslie. Ted Hardie wrote:
Folks,
As you know from Leslie's message, ICANN has asked the IAB to
comment on the system VeriSign has deployed for .com and .net. Below
is a draft of the reply; your technical review and input would be
greatly appreciated. I personally hope that we can send a reply by
the end of this week, so please give it what attention you can as
soon as possible.
There has been some discussion of the best way to structure
the response to ICANN. I believe that this is actually one of at
least two documents required here. This one is required because ICANN
asked us to comment on a specific situation; while it references
general principles (data integrity, interoperability, unified DNS name
space), it focuses on exactly why these principles are at risk in the
current case. The second document required is one which describes an
appropriate set of mechanisms for the introduction of IDNs. I believe
some of the work Patrik has already done fits here, but that the work
will be significantly easier and more complete once the RFCs
documenting the IDN system are out. The third document is one Ran has
suggested and which is mentioned in this note: a more general document
on the DNS and the effects of various non-standard resolution systems
on its coherence and usefulness. This last, I personally believe,
would require working group review by DNSOP, DNSEXT, and possibly IDN,
and might be best done as a working group item rather than an IAB
document.
Obviously, knowing which documents will appear and when has an
effect on the structure of this note. Were the other two documents
already in place, a response could consist of pointers to those
documents. Given that they are not, the IAB has currently chosen to
include the explanatory text that would otherwise be incorporated by
reference.
Thanks for your review,
Ted Hardie
Dear Stuart,
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.
The IAB feels that the system VeriSign has 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.
The IAB plans to prepare an Informational RFC on current IAB concerns
with the DNS System. We anticipate discussing the issues raised in
your notes in more detail as part of that document. In advance
of that document, we have outlined below the issues with the
VeriSign system which led us to the conclusion above.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
--
-------------------------------------------------------------------
"An essential element of a successful journey
is recognizing when you have arrived."
-- ThinkingCat (c.1983 - 2002)
Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------