OpenDNS DNS Tampering

Preface/Definitions

OpenDNS

OpenDNS is a DNS resolution provider that offers open public DNS servers for people to use as an alternative to the ones issued by ISPs. OpenDNS's resolvers are located at 208.67.222.222 and 208.67.220.220 (possibly others)

NXDOMAIN

Non-Existent Domain, a DNS-specification response for a domain that does not exist within the DNS hierarchy.

RR

A Resource Record (RR) is a record held by an authoritative DNS server that is responded to queries.

Authoritative Server

A server that is capable of responding affirmatively with a RR response for a domain or subdomain.

Resolver

A server that is used by clients to access DNS for the purposes of looking up RRs.

DNS

The Domain Name System (DNS) is a hierarchical system that provides RRs to querying clients. Most commonly, translating names (e.g. digibase.ca) to IP addresses (e.g. 72.38.129.202) by way of Address (A) type RRs. The full workings of DNS is beyond the scope of this document.

HTTP

HyperText Transfer Protocol (HTTP) is a protocol in which "the web" is based upon, providing dynamic and static content delivered typically through web browsers like Firefox, Chrome, Opera and Internet Explorer.

The Problem

OpenDNS offers mechanisms to provide filtering of domain names for parental filtering, ad blocking, malware blocking, also offers "suggestion" pages for domains that return an NXDOMAIN response. While this may be useful, it should be discouraged as it is a violation of the DNS standard as DNS is not the place for such filtering as it requires OpenDNS's servers to act authoritatively for domains in which they do not operate. OpenDNS claims these features can be turned off by a web control panel but at least some of them are enabled by default.

Details/Example

Consider the following example of a known working name: ip.digibase.ca which is our website for obtaining your own IP: We will use the DNS diagnostic "dig" tool. We will not utilize our own resolver to provide impartiality of these results. We will utilize 4.2.2.4, which is operated by Level3, an internet backbone provider and 208.67.222.222 which is operated by OpenDNS.

Test for existing name: ip.digibase.ca

Level3 Response:

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1 <<>> ip.digibase.ca @4.2.2.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15400
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ip.digibase.ca.                        IN      A

;; ANSWER SECTION:
ip.digibase.ca.         7200    IN      A       72.38.129.202

;; Query time: 90 msec
;; SERVER: 4.2.2.4#53(4.2.2.4)
;; WHEN: Fri Jan 17 18:58:34 EST 2014
;; MSG SIZE  rcvd: 59

OpenDNS Response:

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1 <<>> ip.digibase.ca @208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33452
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ip.digibase.ca.                        IN      A

;; ANSWER SECTION:
ip.digibase.ca.         7200    IN      A       72.38.129.202

;; Query time: 56 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Fri Jan 17 19:00:04 EST 2014
;; MSG SIZE  rcvd: 59

Both are good and correct responses.

Test for non-existing name: fasdiofanjsiofoasgfa.digibase.ca

Now, with the above in mind consider the following example for a DNS name that does not exist: fasdiofanjsiofoasgfa.digibase.ca.

Level3 Response:

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1 <<>> fasdiofanjsiofoasgfa.digibase.ca @4.2.2.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37843
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;fasdiofanjsiofoasgfa.digibase.ca. IN   A

;; AUTHORITY SECTION:
digibase.ca.            7200    IN      SOA     ns.digibase.ca. admin.digibase.ca. 1376043521 10800 3600 950400 7200

;; Query time: 143 msec
;; SERVER: 4.2.2.4#53(4.2.2.4)
;; WHEN: Fri Jan 17 19:02:11 EST 2014
;; MSG SIZE  rcvd: 106

Notice the "NXDOMAIN" status, which is correct since the name (and in extension, the RR) does not exist.

OpenDNS Response:

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1 <<>> fasdiofanjsiofoasgfa.digibase.ca @208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9133
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;fasdiofanjsiofoasgfa.digibase.ca. IN   A

;; ANSWER SECTION:
fasdiofanjsiofoasgfa.digibase.ca. 0 IN  A       67.215.65.132

;; Query time: 48 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Fri Jan 17 19:07:08 EST 2014
;; MSG SIZE  rcvd: 77

Notice here how OpenDNS has responded with an RR to this lookup where it should have sent no RR and an NXDOMAIN response. This is a violation of the DNS standard as it has spoken authoritatively for a name it has no authority for.

The Issue with this

OpenDNS is responding not only authoritatively for domain names they have not authority to respond for (violating DNS standards in the process) but also:

• DNS does not only provide RRs for web traffic but many other protocols like FTP (file transfer), IRC (chat), IMAP (mail), POP3 (mail), IM (messaging) protocols among others. OpenDNS's behavior does not account for these instances and insists to treat all traffic as web traffic.
• OpenDNS may choose to mark a domain onto their malware list (via false positive) and direct traffic accordingly as such as well for domains that may not actually host malware.
• This behavior has the potential to capture any web traffic to domains that may be temporarily unavailable due to issues in DNS to OpenDNS's servers, potentially allowing OpenDNS to log such requests or capture cookies, even accidently. Information that a DNS resolver provider is not privy to.
• This behavior presents a "Connection Refused" response for non-HTTP traffic, which implies to the user that a server is down, and that DNS is not at fault

Conclusion

It is advised to avoid DNS resolver operators that tamper with responses aside from basic rate limiting. Some ISPs may partake in similar actions to monetize typo'd names and such, You may utilize fasdiofanjsiofoasgfa.digibase.ca or any other name you know doesn't exist on your command line with the 'nslookup' tool that is available by default on most platforms to determine if your provider does this, nslookup should return that the name doesn't exist. If you get a response, your provider is tampering. The command format is nslookup name-of-choice. If your provider partakes in this, it is advised to utilize alternate servers.

A note for DNS resolver operators

Unless it is absolutely nessasary, do not tamper with responses and violate the DNS standard unless absolutely necessary. It is not only a violation of standards, it is also morally questionable. Be responsible when you make decisions and make no assumptions about traffic that passes via your resolver. Using DNS for advertising purposes is morally objectionable as it is leveraging your control over your user's destinations for your own purposes. Users are using your servers because they want reliable responses, give those reliable responses and leave advertising and filtration out of DNS.