Redirecting DNS for Ads and Profit

Redirecting DNS for Ads and Profit Nicholas Weaver Christian Kreibich Vern Paxson ICSI ICSI ICSI & UC Berkeley [email protected] [email protected] [email protected] Abstract In the ICSI Netalyzr [8], our widely used network debugging and diagnostic tool,2 we have employed tests Internet Service Providers (ISPs) increasingly try to grow their for various forms of NXDOMAIN wildcarding since we profit margins by employing “error traffic monetization,” the started offering the service in mid-2009. In this paper we practice of redirecting customers whose DNS lookups fail to illuminate the DNS error monetization market by com- advertisement-oriented Web servers. A small industry of com- bining Netalyzr’s measurements with an analysis of the panies provides the associated machinery for ISPs to engage in this monetization, with the companies often participating in redirection pages collected between January 2010 and operating the service as well. We conduct a technical analysis May 2011, the location and content of the ad servers, of DNS error traffic monetization evident in 66,000 Netalyzr and the marketing material provided by the companies sessions, including fingerprinting derived from patterns seen involved. We identify ISPs employing DNS error mon- in the resulting ad landing pages. We identify major players etization, their choice of monetization provider (includ- in this industry, their ISP affiliations over time, and available ing shifts of provider and apparent in-house realization), user opt-out mechanisms. One monetization vendor, Paxfire, potential redirection policy customizations, as well as transgresses the error-based model and also reroutes all user availability of opt-out mechanisms. search queries to Bing, Yahoo, and (sometimes) Google via We also observe a more aggressive form of DNS- proxy servers controlled or provided by Paxfire. driven traffic manipulation, search-engine proxying. 1 Introduction One monetization provider, Paxfire [11], optionally sup- ports blanket redirection of users’ entire Web traffic for Error traffic monetization solutions leverage the con- www.bing.com, search.yahoo.com, and some- text provided by ISP customer traffic in order to rewrite times www.google.com. Paxfire routes Bing and Ya- protocol error messages to valid responses, redirecting hoo through its own servers while treatment of Google users to Web servers—ad servers, in the following—that depends on ISP policy, for which we observe three alter- show advertisements or search results hopefully of inter- natives: Google’s traffic remains unmolested; redirected est to the user. Examples of such protocol errors include through Paxfire’s servers; or redirected through Paxfire HTTP 404 status codes and, more commonly, DNS re- proxies located within the ISP’s network. sponses with return code 3 (Name Error), indicating that In x 2 we sketch the typical architecture used for error the looked-up name could not be resolved to an IP ad- traffic monetization. In x 3 we describe our methodol- dress. Rewriting of such DNS responses also goes by ogy, including DNS and HTTP data collection and redi- the name “NXDOMAIN wildcarding,” and is the focus rection page categorization. Next, we briefly summa- of this paper. rize the monetization providers and their modes of op- ISPs commonly deploy this controversial practice eration (x 4), along with the corresponding ISP relation- with the assistance of a monetization provider. These ships and monetization policies (x 5). We then discuss third parties supply the infrastructure needed to rewrite Paxfire’s search-engine proxying and which ISPs em- the name errors, and Web servers to redirect traffic to ploy this feature (x 6) before we conclude the paper (x 7). the ad servers. One provider claims that ISPs deploy- ing their solution will see profits of 1–3 USD per cus- 2 DNS Error Monetization tomer per year [14].1 ICANN has criticized this practice due to its potential to cause both security and stabil- DNS-based error monetization tries to convert DNS ity problems, and called out the existence of third-party name errors into clicks on advertisements that are hope- involvement [5]. Security researchers have exploited fully relevant in the context of the user’s error-causing cross-site scripting vulnerabilities in two providers’ ad traffic. This conversion generally operates under the as- servers to demonstrate fairly sophisticated phishing and sumption that the error occurs in Web surfing, as the cookie theft attacks [7]. redirection of the otherwise failing traffic only succeeds for Web traffic. For other applications, say VoIP, email, 1We currently have no way of validating these profit claims. The same provider previously claimed 2–4 USD per customer per year. 2http://netalyzr.icsi.berkeley.edu Figure 1: The typical architecture employed by ISPs Figure 2: A typical search results page resulting from in tandem with monetization providers to facilitate DNS DNS wildcarding. error monetization. know which ISP sourced the traffic. On occasion mon- or FTP, the advertisement context does not exist and etization providers also locate redirection servers within redirection would imply serious privacy implications. the ISPs’ networks. ISPs and monetization providers most commonly im- Finally, the ad server may operate in-house at the ISP plement the redirection procedure using four compo- or at the monetization provider. It serves pages branded nents, shown in Figure1: a recursive DNS resolver, a to the ISP and commonly containing a combination of DNS response rewriter, a redirection Web server, and the “sponsored” search results (i.e., advertisements), actual ad server itself. Whether ISP or monetization provider search results derived from the attempted domain name owns, controls, or operates these components varies. and any keywords it can extract from the original URL, The ISP usually provides the recursive DNS resolver. and a link to opt-out instructions for the customer. Fig- When a user enters a URL into the browser or clicks ure2 shows an example search page Cox Communica- on a link (Ê), the browser sends a DNS request to this tions presents to its users. DNS resolver, which performs the actual DNS queries Monetization providers explicitly sell this service to on behalf of the customers and acts as a cache for DNS ISPs as a method to increase revenue, while ISPs ad- Ë replies ( ). When the name lookup fails, it forwards vertise it to their users as a navigational aid presenting the resulting NXDOMAIN error ( ) to the response search results and sometimes also providing a link cor- rewriter, which consists of a software module on the ex- recting common spelling mistakes (e.g. a link on the isting resolver [9] or an in-path device placed between page for yahoo.cmo pointing to yahoo.com). the recursive resolver and the user [11]. The rewriter Name error rewriting causes significant collateral inspects incoming DNS responses and depending on damage. Web browsers commonly rely on these errors its rule-set rewrites responses indicating name error re- to present browser-specific assistance, such as falling sponses to regular A-record responses containing the IP back to a web search. Wildcarding names that do not address of a redirection server (Í). The rule-set’s cov- begin with www assumes that a Web browser generated erage varies, and may trigger on all name errors, only the lookup. This may break non-HTTP protocols, dis- on those for names beginning with a www subdomain, rupt local services that rely on name suffixes in the lo- or exclude name errors only affecting the given subdo- cal DNS search path, and expose the user to cross-site main. When triggering, the redirection server redirects scripting vulnerabilities [7]. Therefore it is critical the the client to the ad server (Î), which provides the adver- ISPs provide effective opt-out mechanisms [2]. tisements and search results to the client (Ï). Typically, the monetization provider operates the redi- 3 Wildcard Detection and Redirection rection server, a simple web server whose only task is to examine the Host headers and URLs the Web browsers Fingerprinting request, and to generate an HTTP-level redirection re- Since mid-2009 we have provided the ICSI Netalyzr ser- sponse with a suitable URL pointing the browser at vice, a popular network diagnostic, measurement, and the ad server. According to our dataset, monetization debugging applet. Users around the world run it from providers typically assign a different redirection server their browsers in order to debug or clarify their network IP address to each ISP, allowing the redirection sever to connectivity. To date, we have collected 259,000 sessions from 193,000 distinct IP addresses located in vir- While other competitors may exist, the major ISPs in the tually every country of the world. For more details, we Netalyzr dataset do not employ them. refer the reader to our main paper on the service [8]. The differences between monetization providers lie Netalyzr includes tests to detect NXDOMAIN wild- mostly in the rule determining the set of names whose re- carding. We employ random string nonces to com- sulting name errors they rewrite, the implementation of pose nonexistent names in the following ways. Net- the redirection, and the opt-out mechanism. The rewrit- alyzr first uses the system’s DNS library to check if ing rule in practice either matches all name errors or only a name of the form www.nonce.com is wildcarded. those whose names begin in www, and thus reflects dif- If so, it explores variations to determine the policy ferent levels of collateral damage. The redirection mech- for non-Web names (nonce.com), alternative TLDs anism is also important, as the methods vary in reliabil- (nonce.org), common typos (www.yahoo.cmo), ity. The HTTP specification provides for clean redirec- subdomains (nonce.example.com), and DNS server tions using status code 302, which any HTTP client un- failures.

Load more