Protecting Browsers from DNS Rebinding AttacksStanford UniversityCollin Jacksoncollinj@cs.stanford.e

Protecting Browsers from DNS Rebinding Attacks

Stanford University

Collin Jackson

collinj@cs.stanford.eduabarth@cs.stanford.eduabortz@cs.stanford.edu

Stanford University

Adam Barth

Stanford University

Andrew Bortz

Stanford Weidong University

Shao wshao@cs.stanford.edu

ABSTRACT

DNS rebinding attacks subvert the same-origin policy of

browsers and convert them into open network proxies. We survey new DNS rebinding attacks that exploit the inter-action between browsers and their plug-ins, such as Flash Player and Java. These attacks can be used to circumvent ?rewallsand are highly cost-e?ectivefor sending spam e-mail and defrauding pay-per-click advertisers, requiring less than $100to temporarily hijack 100, 000IP addresses. We show that the classic defense against these attacks, called “DNSpinning,”is ine?ectivein modern browsers. The pri-mary focus of this work, however, is the design of strong defenses against DNS rebinding attacks that protect mod-ern browsers:we suggest easy-to-deploy patches for plug-ins that prevent large-scale exploitation, provide a defense tool, dnswall , that prevents ?rewallcircumvention, and detail two defense options, policy-based pinning and host name authorization.

Categories and Subject Descriptors

K.6.5[Management of Computing and Information Systems ]:Security and Protection

General Terms

Security, Design, Experimentation

Keywords

Same-Origin Policy, DNS, Firewall, Spam, Click Fraud

1. INTRODUCTION

Users who visit web pages trust their browser to prevent malicious web sites from leveraging their machines to attack others. Organizations that permit JavaScript and other ac-tive content through their ?rewallrely on the browser to protect internal network resources from attack. To achieve

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for pro?tor commercial advantage and that copies bear this notice and the full citation on the ?rstpage. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior speci?cpermission and/ora fee.

CCS’07,October 29–November2, 2007, Alexandria, Virginia, USA. Copyright 2007ACM 978-1-59593-703-2/07/0011... $5.00.

Stanford Dan Boneh

dabo@cs.stanford.edu

University

these security goals, modern browsers implement the same-origin policy that attempts to isolate distinct “origins,”pro-tecting sites from each other.

Figure 1:Firewall Circumvention Using Rebinding Pinning is no longer an e?ectivedefense against DNS re-binding attacks in current browsers because of vulnerabil-ities introduced by plug-ins. These plug-ins provide addi-tional functionality, including socket-level network access, to web pages. The browser and each plug-in maintain sep-arate pin databases, creating a new class of vulnerabilities we call multi-pin vulnerabilities that permit an attacker to mount DNS rebinding attacks. We demonstrate, for exam-ple, how to exploit the interaction between the browser and Java LiveConnect to pin the browser to one IP address while pinning Java to another IP address, permitting the attacker to read and write data directly on sockets to a host and port of the attacker’schoice despite strong pinning by each component.

Our experiments show how an attacker can exploit multi-pin vulnerabilities to cheaply and e?cientlyassemble a tem-porary, large-scale bot network. Our ?ndingssuggest that nearly 90of web browsers are vulnerable to rebinding at-tacks that only require a few hundreds of milliseconds to conduct (seeTable 1). These attacks do not require users to click on any malicious links:users need only view an at-tacker’sweb advertisement. By spending less than $100on advertising, an attacker can hijack 100, 000unique IP ad-dress to send spam, commit click fraud, or otherwise misuse as open network proxies.

The bulk of our work focuses on designing robust defenses to DNS rebinding attacks that protect current and future browsers and plug-ins:

1. To combat ?rewallcircumvention, we recommend or-ganizations deploy DNS resolvers that prevent external names from resolving to internal addresses. We pro-vide an open-source implementation of such a resolver in 300lines of C called dnswall [15].2. For Flash Player, Java, and LiveConnect, we suggest speci?c,easy-to-deploy patches to prevent multi-pin vulnerabilities, mitigating large-scale exploitation of DNS rebinding for ?rewallcircumvention and IP hi-jacking.

Flash Player 9

192±5. 7ms Internet Explorer 6(noplug-ins) 1000ms Internet Explorer 7(noplug-ins) 1000ms Firefox 1.5and 2(noplug-ins) 1000ms Safari 2(noplug-ins) 1000ms

LiveConnect

1294±37ms Opera 9(noplug-ins) 4000ms

Table 1:Time Required for DNS Rebinding Attack by Technology (95Con?dence)

3. We propose two options for protecting browsers from DNS rebinding:smarter pinning that provides better security and robustness, and a backwards-compatible use of the DNS system that ?xesrebinding vulnerabil-ities at their root (whichwe implemented as a 72-line patch to Firefox 2). The remainder of the paper is organized as follows. Sec-tion 2describes existing browser policy for network access. Section 3details DNS rebinding vulnerabilities, including standard DNS rebinding and current multi-pin vulnerabili-ties. Section 4explains two classes of attacks that use these vulnerabilities, ?rewallcircumvention and IP hijacking, and contains our experimental results. Section 5proposes de-fenses against both classes of attacks. Section 6describes related work. Section 7concludes.

2. NETWORK ACCESS IN THE BROWSER

To display web pages, browsers are instructed to make network requests by static content such as HTML and by active content such as JavaScript, Flash Player, Java, and CSS. Browsers restrict this network access in order to to pre-vent web sites from making malicious network connections. The same-origin policy provides partial resource isolation by restricting access according to origin , specifying when content from one origin can access a resource in another ori-gin. The policy applies to both network access and browser state such as the Document Object Model (DOM)interface, cookies, cache, history, and the password database [20].The attacks described in this paper circumvent the same origin-policy for network access.

Access Within Same Origin. Within the same origin, both content and browser scripts can read and write net-work resources using the HTTP protocol. Plug-ins, such as Flash Player and Java, can access network sockets directly, allowing them to make TCP connections and, in some cases, send and receive UDP packets as well. Java does not restrict access based on port number, but Flash Player permits ac-cess to port numbers less than 1024only if the machine authorizes the connection in an XML policy served from a port number less than 1024.

Access Between Di?erentOrigins. In general, con-tent from one origin can make HTTP requests to servers in another origin, but it cannot read responses, e?ectivelyrestricting access to “send-only.”Flash Player permits its movies to read back HTTP responses from di?erentorigins, provided the remote server responds with an XML policy authorizing the movie’sorigin. Flash Player also permits

reading and writing data on TCP connections to arbitrary port numbers, again provided the remote server responds with a suitable XML policy on an appropriate port.

By convention, certain types of web content are assumed to be public libraries, such as JavaScript, CSS, Java ap-plets, and SWF movies. These ?lesmay be included across domains. For example, one origin can include a CSS ?lefrom another origin and read its text. Scripts can also read certain properties of other objects loaded across domains, such as the height and width of an image.

Prohibited Access. Some types of network access are pro-hibited even within the same origin. Internet Explorer 7blocks port numbers 19(chargen),21(FTP),25(SMTP),110(POP3),119(NNTP),and 143(IMAP),Firefox 2blocks those plus 51additional port numbers, but Safari 2does not block any ports. Some of these port restrictions are designed to prevent malicious web site operators from leveraging vis-iting browsers to launch distributed denial of service or to send spam e-mail, whereas others prevent universal cross-site scripting via the HTML Form Protocol Attack [41].Origin De?nition.Di?erentde?nitionsof “origin”are used by di?erentparts of the browser. For network access, browsers enforce the same-origin policy [38]based on three components of the Uniform Resource Locator (URL)from which it obtained the content. A typical URL is composed of the below components:

scheme://hostname:port/path

Current browsers treat two objects as belonging to the same origin if, and only if, their URLs contain the same scheme, host name, and port number (e.g.,http://amazon.com/is a di?erentorigin than http://amazon.co.uk/, even though the two domains are owned by the same company). Other resources use fewer components of the URL. For example, cookies use only the host name.

Objects on the Internet, however, are not accessed by host name. To connect to a server, the browser must ?rsttrans-late a host name into an IP address and then open a socket to that IP address. If one host name resolves to multiple IP addresses owned by multiple entities, the browser will treat them as if they were the same origin even though they are, from an ownership point-of-view, di?erent.

3. DNS REBINDING VULNERABILITIES

The network access policy in web browsers is based on host names, which are bound by the Domain Name Sys-tem (DNS)to IP addresses. An attacker mounting a DNS rebinding attack attempts to subvert this security policy by binding his or her host name to both the attack and target server’sIP addresses.

3.1Standard Rebinding Vulnerabilities

A standard rebinding attack uses a single browser tech-nology (e.g.JavaScript, Java, or Flash Player) to connect to multiple IP addresses with the same host name. Multiple A Records. When a client resolves a host name using DNS, the authoritative server can respond with mul-tiple A records indicating the IP addresses of the host. The ?rstattack using DNS rebinding [8]in 1996leveraged this property to confuse the security policy of the Java Virtual Machine (JVM):

1. A client visits a malicious web site, attacker.com , con-taining a Java applet. The attacker’sDNS server binds attacker.com to two IP addresses:the attacker’sweb server and the target’sweb server. 2. The client executes the attacker’sapplet, which opens a socket to the target. The JVM permits this connec-tion, because the target’sIP address is contained in the DNS record for attacker.com . Current versions of the JVM are not vulnerable to this at-tack because the Java security policy has been changed. Ap-plets are now restricted to connecting to the IP address from which they were loaded. (Currentattacks on Java are de-scribed in Section 3.2.)

In the JavaScript version of this attack, the attacker sends some JavaScript to the browser that instructs the browser to connect back to attacker.com . The attacker’sserver refuses this second TCP connection, forcing the browser to switch over to the victim IP address [21].By using a RST packet to refuse the connection, the attacker can cause some browsers to switch to the new IP address after one second. Subsequent XMLHttpRequests issued by the attacker’scode will connect to the new IP address.

Time-Varying DNS. In 2001, the original attack on Java was extended [36]to use use time-varying DNS:

1. A client visits a malicious web site, attacker.com , containing JavaScript. The attacker’sDNS server is con?guredto bind attacker.com to the attacker’sIP address with a very short TTL. 2. The attacker rebinds attacker.com to the target’sIP address. 3. The malicious script uses frames or XMLHttpRequest to connect to attacker.com , which now resolves to the IP address of the target’sserver. Because the connection in Step 3has the same host name as the original malicious script, the browser permits the at-tacker to read the response from the target.

Pinning in Current Browsers. Current browsers defend against the standard rebinding attack by “pinning”host names to IP address, preventing host names from referring to multiple IP addresses.

?Internet Explorer 7pins DNS bindings for 30minutes. 1

Unfortunately, if the attacker’sdomain has multiple A records and the current server becomes unavailable, the browser will try a di?erentIP address within one second. ?Internet Explorer 6also pins DNS bindings for 30min-utes, but an attacker can cause the browser to release its pin after one second by forcing a connection to the current IP address to fail, for example by including the element . 1

and The HKEY ServerInfoTimeOut duration is set by the in

registry keys DnsCacheTimeout CurrentVersion USER Internet SOFTWARE Settings

Microsoft Windows

?Firefox 1.5and 2cache DNS entries for between 60and 120seconds. DNS entries expire when the value of the current minute increments twice. 2Using JavaScript, the attacker can read the user’sclock and compute when the pin will expire. Using multiple A records, an attacker can further reduce this time to one second. ?Opera 9behaves similarly to Internet Explorer 6. In our experiments, we found that it pins for approxi-mately 12minutes but can be tricked into releasing its pin after 4seconds by connecting to a closed port. ?Safari 2pins DNS bindings for one second. Because the pinning time is so low, the attacker may need to send a “Connection:close ”HTTP header to ensure that the browser does not re-use the existing TCP con-nection to the attacker. Flash Player 9. Flash Player 9permits SWF movies to open TCP sockets to arbitrary hosts, provided the destina-tion serves an XML policy authorizing the movie’sorigin [2].According to Adobe, Flash Player 9is installed on 55. 8of web browsers (asof December 2006) [1];according to our own experiments, Flash Player 9was present in 86. 9of browsers. Flash Player is vulnerable to the following re-binding attack:

1. The client’sweb browser visits a malicious web site that embeds a SWF movie. 2. The SWF movie opens a socket on a port less than 1024to attacker.com , bound to the attacker’sIP ad-dress. Flash Player sends . 3. The attacker responds with the following XML:

4. The SWF movie opens a socket to an arbitrary port number on attacker.com , which the attacker has re-bound to the target’sIP address. The policy XML provided by the attacker in step 3in-structs Flash Player to permit arbitrary socket access to attacker.com . Flash Player permits the socket connections to the target because it does not pin host names to a single IP address. If the attacker were to serve the policy ?lefrom a port number ≥1024, Flash Player would authorize only ports ≥1024.

3.2Multi-Pin Vulnerabilities

Current browsers use several plug-ins to render web pages, many of which permit direct socket access back to their ori-gins. Another class of rebinding attacks exploit the fact that these multiple technologies maintain separate DNS pin databases. If one technology pins to the attacker’sIP ad-dress and another pins to the target’sIP address, the at-tacker can make use of inter-technology communication to circumvent the same-origin restrictions on network access. Some of these attacks have been discussed previously in the full-disclosure community [4].

4. ATTACKS USING DNS REBINDING

An attacker can exploit the DNS rebinding vulnerabilities described in Section 3to mount a number of attacks. For some of these attacks, the attacker requires the direct socket access a?ordedby DNS rebinding with Flash Player and Java, whereas others require only the ability to read HTTP responses from the target. The attacks fall into two broad categories, according to the attacker’sgoal:

?Firewall Circumvention. The attacker can use DNS re-binding to access machines behind ?rewallsthat he or she cannot access directly. With direct socket access, the attacker can interact with a number of internal services besides HTTP. ?IP Hijacking. The attacker can also use DNS rebinding to access publicly available servers from the client’sIP address. This allows the attacker to take advantage of the target’simplicit or explicit trust in the client’sIP address. To mount these attacks, the attacker must ?rstinduce the client to load some active content. This can be done by a variety of techniques discussed in Section 4.4. Once loaded onto the client’smachine, the attacker’scode can communi-cate with any machine reachable by the client.

4.1Firewall Circumvention

A ?rewallrestricts tra?cbetween computer networks in di?erentzones of trust. Some examples include blocking connections from the public Internet to internal machines and mediating connections from internal machines to Inter-net servers with application-level proxies. Firewall circum-vention attacks bypass the prohibition on inbound connec-tions, allowing the attacker to connect to internal servers while the user is visiting the attacker’sInternet web page (seeFigure 1).

Spidering the Intranet. The attacker need not specify the target machine by IP address. Instead, the attacker can guess the internal host name of the target, for example hr.corp.company.com , and rebind attacker.com to a CNAME record pointing to that host name. The client’sown recur-sive DNS resolver will complete the resolution and return the IP address of the target. Intranet host names are often guessable and occasionally disclosed publicly [30,9].This technique obviates the need for the attacker to scan IP ad-dresses to ?ndan interesting target but does not work with the multiple A record technique described in Section 3.1. Having found a machine on the intranet, the attacker can connect to the machine over HTTP and request the root document. If the server responds with an HTML page, the attacker can follow links and search forms on that page, eventually spidering the entire intranet. Web servers inside corporate ?rewallsoften host con?dentialdocuments, rely-ing on the ?rewallto prevent untrusted users from accessing the documents. Using a DNS rebinding attack, the attacker can leverage the client’sbrowser to read these documents and ex?ltratethem to the attacker, for example by submit-ting an HTML form to the attacker’sweb server.

Compromising Unpatched Machines. Network admin-istrators often do not patch internal machines as quickly as Internet-facing machines because the patching process is time-consuming and expensive. The attacker can attempt

to exploit known vulnerabilities in machines on the internal network. In particular, the attacker can attempt to exploit the client machine itself. The attacks against the client it-self originate from localhost and so bypass software ?re-walls and other security checks, including many designed to protect serious vulnerabilities. If an exploit succeeds, the attacker can establish a presence within the ?rewallthat persists even after clients close their browsers.

Abusing Internal Open Services. Internal networks contain many open services intended for internal use only. For example, network printers often accept print jobs from internal machines without additional authentication. The attacker can use direct socket access to command network printers to exhaust their toner and paper supplies.

Similarly, users inside ?rewallsoften feel comfortable cre-ating ?leshares or FTP servers accessible to anonymous users under the assumption that the servers will be avail-able only to clients within the network. With the ability to read and write arbitrary sockets, the attacker can ex?ltratethe shared documents and use these servers to store illicit information for later retrieval.

Consumer routers are often installed without changing the default password, making them an attractive target for re-con?gurationattacks by web pages [40].Firmware patches have attempted to secure routers against cross-site scripting and cross-site request forgery, in an e?ortto prevent recon-?gurationattacks. DNS rebinding attacks allow the attacker direct socket access to the router, bypassing these defenses.

4.2IP Hijacking

Attackers can also use DNS rebinding attacks to target machines on the public Internet. For these attacks, the at-tacker is not leveraging the client’smachine to connect to otherwise inaccessible services but instead abusing the im-plicit or explicit trust public services have in the client’sIP address. Once the attacker has hijacked a client’sIP ad-dress, there are several attacks he or she can perpetrate. Committing Click Fraud. Web publishers are often paid by web advertisers on a per-click basis. Fraudulent publish-ers can increase their advertising revenue by generating fake clicks, and advertisers can drain competitors’budgets by clicking on their advertisements. The exact algorithms used by advertising networks to detect these “invalid”clicks are proprietary, but the IP address initiating the click is widely believed to be an essential input. In fact, one common use of bot networks is to generate clicks [7].

Click fraud would appear to require only the ability to send HTTP requests to the advertising network, but adver-tisers defend against the send-only attacks, permitted by the same-origin policy, by including a unique nonce with every advertising impression. Clicks lacking the correct nonce are rejected as invalid, requiring the attacker to read the nonce from an HTTP response in order to generate a click.

This attack is highly cost-e?ective,as the attacker can buy advertising impressions , which cost tens of cents per thousand, and convert them into clicks , worth tens of cents each. The attack is su?cientlycost-e?ectivethat the at-tacker need not convert every purchased impression into a click. Instead, the fraudster can use most of the purchased impressions to generate fake impressions on the site, main-taining a believable click-through rate.

We ran the rebinding experiment on the 44, 301(86. 9)impressions that reported Flash Player 9. We did not at-tempt to exploit other rebinding vulnerabilities (seeTa-ble 2). The experiment was successful on 30, 636(60. 1)impressions and 27, 480unique IP addresses. The attack was less successful on the 1, 672impressions served to Mac OS, succeeding 36. 4of the time, compared to a success rate of 70. 0on the 49, 535(97. 2)Windows impressions. 4Mac OS is more resistant to this rebinding attack due to some caching of DNS entries despite their zero TTL.

For each successful experiment, we measured how long an attacker could have used the client’snetwork access by load-ing the target document at exponentially longer intervals, as shown in Figure 2. The median impression duration was 32seconds, with 25of the impressions lasting longer than 256seconds. We observed 9impressions with a duration of at least 36. 4hours, 25at least 18. 2hours, and 81at least 9. 1hours. In aggregate, we obtained 100. 3machine-days of net-work access. These observations are consistent with those of [24].The large number of attacks ending between 4. 2and 8. 5minutes suggests that this is a common duration of time for users to spend on a web page.

backwards compatibility because those servers might not be already serving policy ?les.

used for embedded content (e.g.,www.yahoo.com em-beds images from us.i1.yimg.com ). We then issued DNS queries for these hosts every 10minutes for 24hours, recording the IP addresses reported.

In this experiment, 58reported a single IP address consistently across all queries. Note that geographic load balancing is not captured in our data because we issued our queries from a single machine, mimicking the behavior of a real client. Averaged over the 42of hosts reporting multiple IP addresses, if a browser pinned to an IP address at random, the expected frac-tion of IP addresses available for rebinding under class C network pinning is 81. 3compared with 16. 4un-der strict IP address pinning, suggesting that class C pinning is signi?cantlymore robust to server failure. Other heuristics for pin width are possible. For example, the browser could prevent rebinding between public IP ad-dresses and the RFC 1918[35]private IP addresses. This provides greater robustness for fail-overs across data centers and for dynamic DNS. LocalRodeo [22,45]is a Firefox ex-tension that implements RFC 1918pinning for JavaScript. As for security, RFC 1918pinning largely prevents ?rewallcircumvention but does not protect against IP hijacking nor does it prevent ?rewallcircumvention in the case where a ?rewallprotects non-private IP addresses, which is the case for many real-life protected networks and personal software ?rewalls.

Even the widest possible pinning heuristic prevents some legitimate rebinding of DNS names. For example, public host names controlled by an organization often have two IP addresses, a private IP address used by clients within the ?rewalland a public IP address used by clients on the Inter-net. Pinning prevents employees from properly connecting to these severs after joining the organization’sVirtual Pri-vate Network (VPN)as those host names appear to rebind from public to private IP addresses.

Policy-based Pinning. Instead of using unpinning heuris-tics, we propose browsers consult server-supplied policies to determine when it is safe to re-pin a host name from one IP address to another, providing robustness without degrading security. To re-pin safely, the browser must obtain a policy from both the old and new IP address (becausesome at-tacks ?rstbind to the attacker whereas others ?rstbind to the target). Servers can supply this policy at a well-known location, such as /crossdomain.xml, or in reverse DNS (seeSection 5.4).

Pinning Pitfalls. Correctly implementing pinning has sev-eral subtleties that are critical to its ability to defend against DNS rebinding attacks.

?Common Pin Database. To eliminate multi-pin at-tacks, pinning-based defense require that all browser technologies that access the network share a common pin database. Many plug-ins, including Flash Player and Silverlight, already use the browser’spins when issuing HTTP requests because they issue these re-quests through the browser. To share DNS pins for other kinds of network access, either the browser could expose an interface to its pin database or the operating system could pin in its DNS resolver. Unfortunately, browser vendors appear reluctant to expose such an interface [12,33]and pinning in the operating system

either changes the semantics of DNS for other applica-tions or requires that the OS treats browsers and their plug-ins di?erentlyfrom other applications.

?Cache. The browser’scache and all plug-in caches must be modi?edto prevent rebinding attacks. Cur-rently, objects stored in the cache are retrieved by URL, irrespective of the originating IP address, creat-ing a rebinding vulnerability:a cached script from the attacker might run later when attacker.com is bound to the target. To prevent this attack, objects in the cache must be retrieved by both URL and originat-ing IP address. This degrades performance when the browser pins to a new IP address, which might occur when the host at the ?rstIP address fails, the user starts a new browsing session, or the user’snetwork connectivity changes. These events are uncommon and are unlikely to impact performance signi?cantly.?document.domain. Even with the strictest pinning, a server is vulnerable to rebinding attacks if it hosts a web page that executes the following, seemingly in-nocuous, JavaScript:

document.domain =document.domain;

After a page sets its domain property, the browser al-lows cross-origin interactions with other pages that have set their domain property to the same value [42,17].This idiom, used by a number of JavaScript li-braries 6, sets the domain property to a value under the control of the attacker:the current host name.

5.4Fixing Browsers (Default-AllowSockets)

Instead of trying to prevent a host name from rebinding from one IP address to another—afairly common event—adi?erentapproach to defending against rebinding is to pre-vent the attacker from naming the target server, essentially generalizing dnswall to the Internet. Without the ability to name the target server, the attacker cannot mount a DNS rebinding attack against the target. This approach defends against rebinding, can allow socket access by default, and preserves the robustness of dynamic DNS.

Host Name Authorization. On the Internet, clients re-quire additional information to determine the set of valid host names for an given IP address. We propose that servers advertise the set of host names they consider valid for them-selves and clients check these advertisements before binding a host name to an IP address, making explicit which host names can map to which IP addresses. Host name autho-rization prevents rebinding attacks because honest machines will not advertise host names controlled by attackers.

Reverse DNS already provides a mapping from IP ad-dresses to host names. The owner of an IP address ip is delegated naming authority for ip .in-addr.arpa and typi-cally stores a PTR record containing the host name associ-ated with that IP address. These records are insu?cientfor host name authorization because a single IP address can have many valid host names, and existing PTR records do not indicate that other host names are invalid.

6

based For example, ics web application “Dojo”framework, AJAX library, jsMath Struts AJAX servlet/JSPMathemat-sni?”library, library and are Sun’svulnerable “Ultimatein this client-side way.

JavaScript client

The reverse DNS system can be extended to authorize host names without sacri?cingbackwards compatibility. To authorize the host www.example.com for 171.64.78.146, the owner of the IP address inserts the following DNS records:auth.146.78.64.171.in-addr.arpa.

IN A 171.64.78.146

www.example.com.auth.146.78.64.171.in-addr.arpa.

IN A 171.64.78.146To make a policy-enabled resolution for www.example.com , ?rstresolve the host name a set of IP addresses normally and then validate each IP address as follows:1. Resolve the host name auth. ip .in-addr.arpa . 2. If the host name exists, ip is policy-enabled and ac-cepts only authorized host names. Otherwise, ip is not policy-enabled and accepts any host name. 3. Finally, if ip is policy-enabled, resolve the host name

www.example.com.auth. ip .in-addr.arpa to determine if the host name is authorized.

An IP address ip implicitly authorizes every host name of the form *.auth.ip .in-addr.arpa , preventing incorrect re-cursive policy checks. For host names with multiple IP ad-dresses, only authorized IP addresses should be included in the result. If no IP addresses are authorized, the result should be “notfound.”If an IP address is not policy en-abled, DNS rebinding attacks can be mitigated using the techniques in Section 5.3.

The policy check can be implemented in DNS resolvers 7, such as ones run by organizations and ISPs, transparently protecting large groups of machines from having their IP addresses hijacked. User agents, such as browser and plug-ins, can easily query the policy records because they are stored in A records and can issue policy checks in paral-lel with HTTP requests (providedthey do not process the HTTP response before the host name is authorized). Stan-dard DNS caching reduces much of the overhead of redun-dant policy checks issued by DNS resolvers, browsers, and plug-ins. As a further optimization, policy-enabled resolvers can include policy records in the “additional”section of the DNS response, allowing downstream resolvers to cache com-plete poli