[council] ICANN Security and Advisory Committee response to Verisign service

["Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>]

From: http://www.icann.org/correspondence/secsac-to-board-22sep03.htm

Message from Security and Stability Advisory
Committee to ICANN Board
22 September 2003
 
------------------------------------------------------------------------
--------

Recommendations Regarding VeriSign's Introduction of Wild Card Response
to 
Uninstantiated Domains within COM and NET

ICANN Security and Stability Advisory Committee

BACKGROUND

On September 15, 2003, VeriSign changed the way its COM and NET name
servers respond when presented with a query for a COM or NET domain name
for when no name server record exists [1]. This change was reported on
September 5, 2003 [2] and September 9, 2003 [3], but the implications of
the change were not broadly recognized until it was deployed.

Previously, such queries returned RCODE 3 ("name error"), the negative
response defined in the official DNS protocol specification, RFC1035
[4]. VeriSign now returns an IP address for a special server, thereby
creating the appearance the requested domain name exists. The special
server handles the subsequent requests for application level services,
e.g. web, email, etc.

This special server is currently listening on port 80 for HTTP (web) and
port 25 for SMTP (email) transactions. The web server returns a page
indicating the domain name is not registered and offers search and/or
registration services. The email server originally bounced all email
with a 550 error code, which indicates a permanent failure and would
result in the message being bounced back to the sender. Its precise
behavior is still subject to change in response to community feedback,
substantially changing the way email is queued, routed, and responded to
in the COM and NET domains.

Applications or protocols which previously relied on an RCODE 3 response
for a non-existing domain have suffered by this change in behavior for
COM and NET. Workarounds at the routing and DNS level have been deployed
to stop the effect of these wildcards, and these workarounds are an
additional source of potential instability.

SECURITY AND STABILITY ISSUES

The Security and Stability Advisory Committee is examining the situation
from several viewpoints.

* Conformance with the protocol specifications as defined by the
engineering community. 

* Conformance with accepted best practices and operational procedures as
defined by the engineering and operational communities. 

* Consideration of the technical stability and security of the domain
name system and the Internet as a whole in light of the both the change
introduced by VeriSign and the corresponding changes being introduced by
others. 

* Current procedural and governance controls to assure review and
analysis of changes to the critical components of the Internet. 

* Public confidence in the stability and reliable operation of the
Internet. Security and stability is not limited to a narrow
interpretation of the technical specifications of the protocol
documents; it also includes engineering, operational, business, and
policy issues. 

To gather information on security and stability implications, we invite
inputs from all interested parties. Send inputs to:

secsac-comments@xxxxxxxxx

Further, we will meet publicly in the Washington, D.C. area on October
7, 2003, for interested parties to present factual information relevant
to the security and stability of the Internet. Details will be available
shortly.

Although we continue to gather inputs, there is already enough
information to support the following opinions and recommendations.


OPINIONS

VeriSign's change appears to have considerably weakened the stability of
the Internet, introduced ambiguous and inaccurate responses in the DNS,
and has caused an escalating chain reaction of measures and
countermeasures that contribute to further instability.

VeriSign's change has substantially interfered with some number of
existing services which depend on the accurate, stable, and reliable
operation of the domain name system.

* Many email configuration errors or temporary outages which were benign
have become fatal now that the wildcards exist. 

* Anti-spam services relied on the RCODE 3 response to identify forged
email originators. 

* In some environments the DNS is one of a sequence of lookup services.
If one service fails the lookup application moves to the next service in
search of the desired information. With this change the DNS lookup never
fails and the desired information is never found. 

VeriSign's action has resulted in a wide variety of responses from ISPs,
software vendors, and other interested parties, all intended to mitigate
the effects of the change. The end result of such a series of changes
and counterchanges adds complexity and reduces stability in the overall
domain name system and the applications that use it. This sequence leads
in exactly the wrong direction. Whenever possible, a system should be
kept simple and easy to understand, with its architectural layers
cleanly separated.

We note that some networks and applications were performing similar
services prior to VeriSign's change. In fact, some user applications and
services worked differently depending on the network the user was using.
However, VeriSign's change pushes this service to a much lower layer in
the protocol stack and a much deeper place in the Internet's global
infrastructure, which prevents the user from choosing what services to
use and how to proceed when a query is made to a non-existent domain.


RECOMMENDATIONS

Recognizing the concerns about the wildcard service, we call on VeriSign
to voluntarily suspend the service and participate in the various review
processes now underway.

We call on ICANN to examine the procedures for changes in service,
including provisions to protect users from abrupt changes in service.

We call on the IAB, the IETF, and the operational community to examine
the specifications for the domain name system and consider whether
additional specifications could improve the stability of the overall
system. Most urgently, we ask for definitive recommendations regarding
the use and operation of wildcard DNS names in TLDs and the root domain,
so that actions and expectations can become universal. With respect to
the broader architectural issues, we call on the technical community to
clarify the role of error responses and on the separation of
architectural layers, particularly and their interaction with security
and stability.


[1] Announcement of VeriSign change

[2] Wall Street Journal report of VeriSign change

[3] New York Times report of VeriSign change

[4] RFC1035, Domain Names - Implementation and Specification