[sf-lug] pdns-recursor

[Alex Kleider]

Yet again, Rick, thanks.
I'll let unbound, running on my Sheevaplug 24/7, (continue to) do the job and forget about OpenDNS.
cheers,
alex

a_kleider at yahoo.com


--- On Wed, 7/21/10, Rick Moen <rick at linuxmafia.com> wrote:

> From: Rick Moen <rick at linuxmafia.com>
> Subject: Re: [sf-lug] pdns-recursor
> To: "Linux userGroup" <sf-lug at linuxmafia.com>
> Date: Wednesday, July 21, 2010, 11:47 PM
> 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
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/
>