The Internet Corporation for Assigned Names and Numbers (ICANN) has released an advisory concerning VeriSign’s deployment of DNS wildcard (Site Finder) service. It includes the following statement:

“Since the deployment, ICANN has been monitoring community reaction, including analysis of the technical effects of the wildcard, and is carefully reviewing the terms of the .com and .net Registry Agreements.

In response to widespread expressions of concern from the Internet community about the effects of the introduction of the wildcard, ICANN has requested advice from its Security and Stability Advisory Committee, and from the Internet Architecture Board, on the impact of the changes implemented by VeriSign. ICANN’s Security and Stability Advisory Committee is expected to release an objective expert report concerning the wildcard later today.

Recognizing the concerns about the wildcard service, ICANN has called upon VeriSign to voluntarily suspend the service until the various reviews now underway are completed.”

The Internet Architecture Board (IAB), a committee of the Internet Engineering Task Force (IETF) has also released its own document containing a number of observations on the implications of the use of wildcards in DNS zones, and makes some recommendations concerning their use.

In a section called “Problems encountered in a recent experiment with wildcards” the IAB’s document states:

“We must emphasize that, technically, this was a legitimate use of wildcard records that did not in any way violate the DNS specifications themselves. One of our main points here is that simply complying with the letter of the protocol specification is not sufficient to ensure the operational stability of the applications which depend on the DNS: there are protocol features which simply are not safe to use in some circumstances.”

The document goes on to conclude:

“The Principle of Least Astonishment suggests that the deployment of wildcards was disastrous for the users. It had widesweeping effects on other users of the Internet far beyond those enumerated by the zone operator, created several brand new problems, and caused other internet entities to make hasty, possibly mutually incompatible and possibly deleterious (to the internet as a whole) changes to their own operations in an attempt to react to the change.”

[...]

“For zones which do delegations, we do not recommend even wildcard MX records. If they are used, the owners of zones delegated from that zone must be made aware of that policy and must be given assistance to ensure appropriate behavior for MX names within the delegated zone. In other words, the parent zone operator must not reroute mail destined for the child zone without the child zone’s permission.

We hesitate to recommend a flat prohibition against wildcards in “registry”-class zones, but strongly suggest that the burden of proof in such cases should be on the registry to demonstrate that their intended use of wildcards will not pose a threat to stable operation of the DNS or predictable behavior for applications and users.

We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity.”