[sf-lug] pdns-recursor

[Rick Moen]

Quoting Alex Kleider (a_kleider at yahoo.com):

[OpenDNS:]

> I believe I remember reading good things about them (probably on this
> list) and would be interested in opinions how they might fit into the
> discussions of setting up one's own name server.
> 
> My question specifically is:
> 
> if one is using unbound as a name server, is there any thing to be
> said for changing the default configuration (use of the root name
> servers) to using the OpenDNS servers? Their literature certainly
> indicates that response times will be less but one has to assume that
> there's some bias there.
> 
> If the answer is 'yes,' a follow up question might be how to do so,
> but I haven't looked into that yet.

Some aspects to consider.


1.  Response time:  Their literature is correct that their (OpenDNS's)
response time is generally going to be better than using typical ISP
nameservers that are remote from your local LAN.  By contrast, their
response time cannot help being much worse that running a _local_ 
nameserver such as you do with Unbound.

If that's not obvious, draw a crude network diagram, consider the effect
of the fact that most DNS lookups against Unbound will be cache hits,
and note that the slowest link is probably the one between your local 
LAN and your immediate upstream (your ISP).


2.  Initial cache:   Imagine one machine on your local network whose DNS
client (via /etc/resolv.conf) is configured to consult (local) Unbound,
and a second machine on your local network whose DNS client is
configured to consult (remote) OpenDNS.  Imagine that you've _just now_ 
started up the Unbound process.

Machine #1 is going to hit an empty cache (in Unbound), because Unbound
just started.  Unbound will need to recursively fetch the answer from
the Internet before answering the question.  Meanwhile, machine #2 will 
be almost certainly getting served OpenDNS's answer straight out of its 
cache, because OpenDNS's software has been building its (probably huge)
rolling cache for a long time.  (Of course, it's responses will always
come with transit delay over the ISP link; see point #1.)  So, the
immediate situation upon startup will favour OpenDNS because of cache
hits.  This difference will evaporate quickly, though.  If you mostly
leave the Unbound process running, the OpenDNS initial advantage doesn't 
recur.


3.  Correct vs. incorrect results:   Unbound gives categorically correct
responses to queries, including responding "NXDOMAIN" (no such host)
on queries that don't resolve.   OpenDNS deliberately breaks DNS RFC
standards to give a deliberately wrong answer (except when responding to
people who're purchasing paid OpenDNS services as opposed to the
free-of-charge service) whenever the correct answer is "NXDOMAIN".

Here is a query of a non-existent host against the copy of BIND9 running
on my server (reached as IP 127.0.0.1 = localhost):

$ dig i-dont-exist.linuxmafia.com @127.0.0.1 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60614
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; AUTHORITY SECTION:
linuxmafia.com.         10800   IN      SOA     ns1.linuxmafia.com.
rick.deirdre.NET. 2010062201 7200 3600 2419200 10800
$


Note the 'status: NXDOMAIN'.  That's the answer.  It says there is no
such DNS entity as i-dont-exist.linuxmafia.com.

The IP addresses of OpenDNS's free-of-charge service are 208.67.222.222
and 208.67.220.220.  Let's see what happens when we ask one of them the
same question:

$ dig i-dont-exist.linuxmafia.com @208.67.222.222
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2851
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; ANSWER SECTION:
i-dont-exist.linuxmafia.com. 0  IN      A       67.215.65.132
$

OpenDNS says 'Yes, I do know what host i-dont-exist.linuxmafia.com is.
It's a real DNS entry, and it resolves to IP address 67.215.65.132.

Why do they deliberately break DNS RFC standards to issue grossly
incorrect answers?  Because that's how their business model works.  
The 67.215.65.132 IP address is that of an OpenDNS-operated Web server,
AKA guide.opendns.com .  _If_ your query is on behalf of a Web browser, 
then the result is that your Web browser shows that server's Web pages
instead of timing out on an effort to look up a nonexistent host.  The
Web server provides (typically) suggestions about what you might have
meant to type, e.g., 'Maybe you meant to type www.google.com instead of 
wwww.google.com' or such.  Plus it serves you advertising.  The
advertising helps fund OpenDNS's operations.

If your query is _not_ on behalf of a Web browser, then the software in
question gets misleading information from DNS.  E.g., you might have
been trying to send e-mail to 'somebody at yahoo.com', but instead typed
'somebody at yahooo.com'.  Ordinarily, your e-mail client would interpret
the NXDOMAIN DNS result as an SMTP delivery failure right away.  Because
OpenDNS is giving a deliberately wrong false positive, your e-mail
client will attempt an SMTP session to 67.215.65.132 .

You make up your own mind, but I personally object strongly to software
that deliberately breaks key Internet standards, especially when I can
run better software locally, instead.


4.  Security of the DNS server.  Compared to typical ISP recursive
nameservice, OpenDNS service almost certainly has a much better
likelihood of being secure against compromise by remote attackers, but
only because typical ISP nameservice is really bad in that area.
The comparison to a good local recursive nameserver such as an instance
of Unbound is a different matter.  Even with halfassed administration,
you are likely to run a more secure installation than OpenDNS's because,
although they might have a slight edge in having an alert Network
Operations staff in charge, you have the advantage of tighter control
over what queries your nameserver will accept and from where, which
means you can more easily avoid DNS cache poisoning, one of the main
types of remote attack against recursive nameservers.


5.  Anti-phishing/malware/etc.  In addition to providing deliberately 
incorrect answers in place of NXDOMAIN, OpenDNS also carefully avoids
giving you correct IP return values when they are on OpenDNS's
maintained blacklist of Very Bad People sites, e.g., sites believed to
be attempting to publish MS-Windows malware.  In other words, OpenDNS 
filters the world to 'protect' you from getting correct DNS-returned IP
addresses of sites OpenDNS doesn't think you should visit.

Again, you make up your own mind, but I am uncomfortable with some
strangers, even well-intended and reputable ones such as David Ulevich's
OpenDNS staff, deciding which correct DNS answers I should receive
versus which ones should be withheld from me for my own good.  If I want
to filter my DNS, I'll do it locally according to _my_ filtering
criteria.



6.  Privacy.  When you configure your DNS clients to use OpenDNS
services, OpenDNS's nameservers acquire real-time information on all
nameservice resolutions you and your users perform.  By contrast, when
you use a local recursive server (such as Unbound) under your sole
control, that DNS-level loggable information is available only locally,
i.e., logged by _you_ and available to you only.

It should be noted that all of your packets pass through your upstream
connectivity provider's (ISP's) routers, so a nosy ISP (or an intruder
who compromised your ISP's routers) could acquire much of the same
inforamtion there.   However, one difference is that the quantity of
detailed, real-time information available there is much less if you use
a local recursive nameserver (because of cache hits).  Also, your ISP 
has a legal, contractual obligation of good faith and fair dealing that
makes it a serious tort offense to violate your privacy, whereas you do
not have the same contractual obligation from OpenDNS.



Lineus bottomus:   OpenDNS (or Google Public DNS, for that matter) is
arguably a big step forward over using your local ISP recursive
nameserver -- but that's setting the bar pretty low.  Running your own
local nameserver, instead, is in my view a much larger step forward.  

Your mileage may differ.<tm>


By the way, I've written about all this in the recent past:
http://linuxmafia.com/~rick/googledns.html
http://linuxmafia.com/~rick/lan.html

-- 
Cheers,             The genius of you Americans is that you never make 
Rick Moen           clear-cut stupid moves, only complicated stupid moves 
rick at linuxmafia.com that make us wonder at the possibility that there may be 
McQ!  (4x80)        something to them that we are missing. --Gamel Abdel Nasser