Re: Draft response on .Com & .Net issue

[Thomas Narten <narten@us.ibm.com>]

> 	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.

I think the scope and focus as outlined above is appropriate. The text
below seems generally reasonable to me.

> 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.

This would be a good document to have. Something of a roadmap that
shows how to introduce IDNs successfully. What steps need to be taken,
what order to do things in, identifying what work still needs to be
done, etc. Is that was is being thought of here?

> 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.

This would also be a fine document to have. But I wonder who will
write it and/or drive the effort (it could become large) , and whether
it can be scoped to keep it from becoming too all-encompassing. I.e,
the above could be read as a "things you shouldn't do with the DNS",
and almost endless list. But in principle this would be a useful
document ot have.

> Dear Stuart,

On the whole, I think this response is good. Specific comments below.

One general comment. The response is fairly long, and I assume the
target audience isn't entirely technical. Some of the issues cited
seem like they are "implementation" issues in that they could be
responded to by tweaking the implementation (with varying degrees of
pain). I'd hate for this response to be used to "fix" the easy
concerns to make it appear like the majority of concerns have been
responded to. In other words, it would be good to be clear about what
the major concerns are which are less fundamental.

It might be good to more clearly break the discussion into two parts,
one that focuses on protocol issues that are fundamentally hard to
fix, and a second section that talks about things that are probably
fixable through some implementation changes. I suspect that we want to
be sure that the fundamental issues are not buried and are given more
prominence.

> 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

risks what? risk hindering, risks being at odds with? Could be more
clear/direct.

> 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 above might be hard to grok by less technical folk. Possible
rewording:

 The DNS protocol specifies behavior for queries whose targets exist
 in a zone by describing the semantics and on-the-wire data formats
 for request and response messages.  The DNS protocol also defines the
 protocol for responding to queries for targets that do not exist in a
 zone, by describing the wire format for a negative response [RFC
 XXX].
 
> 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.

Fill is enabled above, but not throughout???

> 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.

The above is a pretty specific technical point. Will the target
audience understand it? (FWIW, I don't...)

> VeriSign confirms that they are not managing a zone of the size this
> would imply and is, instead, synthesizing these entries.  This implies

s/a zone of the size this would imply/in this manner/

> 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.

Cite relevant RFCs.  Indeed, a pass through the note should be made to
add references when talking about specific protocol issues.

> 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

s/the effort is/the above steps are/
> 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.

s/for SMTP/for SMTP and HTTP/?

> 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.

Is the above an implementation issue? I'd want to be careful about
complaining about things that can be easily fixed...

> 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.

For the above two paragraphs, it might be more clear to talk in one a
paragraph about SMTP, and in the another about HTTP rather than mixing
the two throughout. Talking about both together makes it harder to
keep track of which issue is with which approach, IMO.

> 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.

The core concern is listed last?

> 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

It might be good to at the end include a summary paragraph summarizing
the techinical concerns, especially the most important ones.

Thomas