ICANN participation

Many PC and Internet users are familiar with the concept of a wildcard operation. The concept is simple to understand. A special character (commonly an asterisk) is reserved by an operating system search operation to mean "return any match in a search". For example, if a user were to search for the string "ma" from an operating system command line (e.g., MS-DOS, or any flavor of LINUX or BSD), the operating system will return a list of files having names that exactly match the string. However, if a wild card were appended, e.g., "ma*", the operating system will respond by listing all the files that begin with the string "ma" in the current directory, e.g., "map.txt" or "maintenance-budget.xls". Wildcard operations are available in GUI-based operating systems as well. Windows XP users can use "Search" and MAC OS X users can use "Spotlight" to find a single file, or all files that begin with a string of characters: the latter is also an example of an implicit wildcard operation. These wildcard operations share a common trait: if the operating system cannot find any matches to the search "argument", it returns a "not found" error.

Imagine the confusion and potential abuse that might exist if an operating system returned an automatic or "synthesized" response like, "I didn't find the files you wanted, but here's a list of services and software you might want to purchase". Now imagine that any time you attempt to connect to a web site within a given domain, and the domain name you enter as a URL does not exist, and instead of receiving a "server not found" error (HTTP 404), you are instead redirected to a domain name monetization page, or a page offering you the opportunity to purchase the domain name you entered.

The introduction of wildcard or synthesized response based services at the Top Level Domain (TLD) or registry level of the DNS does exactly this. Synthesized responses return unanticipated domain name resolution responses to web users. Users may find this annoying but can often recover. However, many Internet applications have not been designed to process such responses and may not behave as intended. For example, think of the effect such a change would have on an application designed to identify broken external hyperlinks on a web site.

How Wildcards Work

In normal operating circumstances, a name server that receives a query for a non-existent or unregistered name from a client returns a DNS standard error code value of "name error." This error code alerts the name resolver component of the requesting client's application that the name is not instantiated. When a synthesized response-based service is implemented by a domain authority, its name server returns a positive response rather than an error code: specifically, the name server associates a seemingly legitimate IP address for a domain name that is not currently registered in DNS. When a single A resource record is used as the synthesized response for all domain names, whether unregistered or non-existent, the service is called a wildcard service.

When a registry uses a wildcard service, it never returns the "name error" response. Instead, the TLD's authoritative name server returns a positive response to every query. The effect of this change is easily demonstrated. Imagine that a user mistypes a domain name and enters "exampl.<tld>" rather than "example.<tld>". If the TLD uses a wild card service, its name servers will return a positive response (e.g., one that redirects the user to a web page that offers information or a registration service) rather than a "page not found". A web user may be able to infer that an error has occurred, but Internet applications that rely on the "name error" response from the DNS may fail or not operate as intended since the "no such name" response no longer occurs.

Previous attempts at introducing wildcard resource records at the TLD level have exposed applications that are adversely affected by this change in behavior [See SAC006]. Email, telnet, SSH, FTP and other servers that receive a synthesized response will attempt to connect to the IP address returned in the response. Email servers are configured to retry connection attempts, so the synthesized responses add delay to mail processing and wastes Internet resources. It's important to appreciate that an email server may try to connect for days, so an email administrator may not discover a configuration error or mistyped domain name for an unacceptably long time.

A TLD operator may choose to host an email server at the IP address returned in the synthesized response and have the server automatically return "bounce" responses, as mail servers must deal with additional load (bounced traffic) and any delays introduced at the TLD operator's server. Alternatively, the TLD operator's email server might be configured to accept the connection and return a response that the addressee does not exist on that machine. This misleads the sender into believing that the domain name is correct but the person's email address is wrong. Significant privacy issues exist if the TLD's email server is configured to store mail messages, even for a short term. Email antispam measures that attempt to validate the sender's domain will not block bogus senders.

Telnet, SSH, FTP and other applications will also behave differently when they receive a synthesized response. So will administrative processes that perform logging, auditing, accounting and billing also rely on the ability to distinguish positive from negative responses from DNS server, and are adversely affected as well (see Site Finder Review for details).

Wildcards or Application Behavior?

It's important to note that there other ways to change application behavior when a user or client resolver attempts to resolve a DNS name that isn't instantiated. A wildcard can be added at the registry level, or by a names server closer to the user; for example, any name server that processes a DNS response message on behalf of a client resolver can inspect and modify the response before caching or forwarding it to the requesting user or client resolver.

Similarly, an application such as a web browser or HTTP proxy can be configured to behave in a particular way when receiving a "not found" error from the DNS, such as redirecting the user to a trusted index or search page.

Much of the community's attention focuses on the use of wildcards at the registry level, and this is deliberate. While there are various risks associated with the different mechanisms for handling a "not found" error from the DNS, the consequences of these tend to be more troubling as wildcard use becomes more general. In particular, the strong reservations expressed here against wildcards at the registry or TLD level are due in part to the following observations:

• A registry wildcard is well outside a user's or enterprise domain administrator's scope of control. Neither an individual user or the user's local name service administrator (an ISP or enterprise DNS administrator) have business relationships with registries. These parties may not be able to influence or exercise control over a result returned by name servers under the control of the registry and thus cannot enforce a distinction between instantiated and uninstantiated names.
• A registry level wildcard presumes that the all applications will in general benefit from or at least tolerate responses from the DNS that do not distinguish between instantiated and uninstantiated names. A local user may find it beneficial to have web requests redirected to an index or search page when name resolution is requested for an uninstantiated DNS name; however, this "redirection" behavior can disrupt email service for an entire enterprise.

Recommendations and Conclusion

ICANN's Security and Stability Advisory Committee SSAC issued a report (SAC006) on 9 July 2004 on Redirection in the COM and NET Domains. The report recommends that "Synthesized responses should not be introduced into top-level domains (TLDs) or zones that serve the public, whose contents are primarily delegations and glue, and where delegations cross organizational boundaries over which the operator may have little control or influence.". More recently, the Registry Services Technical Evaluation Panel (RSTEP) published its report on a request by another Top Level Domain registry, (Tralliance) to introduce a wildcard service (see search.travel Wildcard Report). In the report, RSTEP consider a similar set of issues to those SSAC considered in SAC006, in the context of another top level domain (.travel). They did so quite thoroughly, and concluded that the wildcard service "does create a reasonable risk of a meaningful adverse effect on security and stability." The recommendations in SAC006 remain applicable today. TLDs should refrain from using services that make use of wildcard services and synthesized DNS reponses.