Redirection and synthesized DNS responses do more harm than good

This is a revision to an article originally published in January 2008. 

Many PC and Internet users are familiar with the concept of a wildcard symbol. From a DOS command window, type "dir *.exe" and MS-DOS will display all the files of type "executable" in the current directory. 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. In both cases, 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". Not exactly what you're after, right? 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. Again, not exactly what you expected, right?

What is a Synthesized DNS Response?

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. Many Internet applications have not been designed to process such responses. For example, think of the effect such a change would have on an application designed to identify broken external hyperlinks on a web site. Let's examine this more carefully.

How Do DNS Wildcards Work?

In normal operating circumstances, a name server that receives a query for an uninstantiated name from a client returns a DNS standard error code value of "name error." This error code alerts the requesting client that the name is not instantiated. When a synthesized response-based service is implemented, a 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 uninstantiated domain names, the service is called a wildcard service.

When wildcard records are used, the "name error" response cannot occur. The name server provides consistently 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 "example.bla" rather than "example.blah". If the TLD .bla uses a wild card service, .bla's TLD 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.

Unintended Consequences of Suppressing "Name Error" Responses

Previous attempts at introducing wildcard resource records at the TLD level have exposed applications that are adversely affected by this change in behavior. 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 adds delay to mail processing. Email is also affected when the TLD operator hosts an email server at the IP address returned in the synthesized response and automates "bounce" responses, as mail servers must deal with additional load (bounced traffic) and any delays introduced at the TLD operator's server. Email antispam measures that attempt to validate the sender's domain will not block bogus senders. Not exactly what the mail admin expected, right?

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

Redirection can facilitate malicious activities

 In 2007, commercialization of redirection and synthesized responses attracted the attention of the security community. Error resolution services and registrars were wildcarding zone files and modifying DNS messages at affiliated resolvers along the response path. These new practices exposed domains to new attacks. Dan Kaminsky was able to demonstrate that vulnerabilities in web applications running on the ad servers these redirected responses point to can be exploited by attackers to embarrass the domain operator or by phishers to commit fraud and identity theft (see Ad Replacers Let Dan Kaminsky RickRoll the Entire Web). ICANN's SSAC exposes the vast threat landscape posed by vulnerable ad replacers, explaining that "any third party who provides an iterative resolver that participates in the resolution process is a potential man in themiddle and has the ability to modify messages it receives from an authoritative name server before forwarding these to a client.”

Stop this train before it wrecks

Stopping money trains is difficult. ICANN's SSAC has commented that "synthesized DNS responses at the TLD level (and subordinate levels) is a destabilizing practice. It also creates opportunities for DNS abusethat can be easily avoided and should be prohibited at TLD registries. We urge ICANN,and the global DNS community to find appropriate mechanisms to ban this practice at the TLD level." For the record, this is the fourth time in five years that SSAC has had to iterate this statement. ICANN is attempting to lead (in this case, derail?) by example: at its public meeting in Sydney in June 2009, the ICANN Board of Directors resolved that new top-level domains should not use DNS redirection and synthesizing of DNS responses, and a prohibition against redirection and synthesizing of DNS responses appears the draft Registry Agreement for new gTLDs. At the request of the board, ICANN staff have prepared an explanatory memorandum, Harms and Concerns Posed by NXDOMAIN Substitution (DNS Wildcard and Similar Technologies) at Registry Level.

These actions only address redirection at the top level of the domain. To mitigate the threat entirely, Internet users and corporations alike must push back on broadband access providers and DNS providers who affiliate with or operate error resolution services.  Noted DNS expert Paul Vixie calls error resolution "lying", and I wholeheartedly concur. If I ask you a question and you give me an answer that differs from the "truth", it's a lie(truth here being the answer the authoritative zone file would answer).

Don't do business with liars.

Comments

[The Skeptic]

Thanks for the compliment. Response modification, interruption marketing and certain forms of parking/landing pages are too often used for scams. I try to use reputation/rating systems (mywot.com, robtex.com) and URL block lists (SURBL, SpamHaus, PhishTank) when I'm uncertain about a site. It's not exactly convenient but it's way less convenient than removing malware.

[fixing redirect]

Wow, I took away so much from reading this. The problem is that in some shape or form this is actually happening, just maybe not in the exact way specified here. The google redirect virus is one way that scammers are getting people redirected to websites where they are trying to make a profit. I think this is called interruption marketing? I would really like to see it stopped.
This is definitely a bookmark for me - you know your stuff!

[Matt]

A related article,$1B Market for Meddling With DNS Poses Security Problem, can be found at http://www.csoonline.com/article/410363/_1B_Market_for_Meddling_With_DNS_Poses_Security_Problem