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@icann.org 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