[sf-lug] pdns-recursor
Alex Kleider
a_kleider at yahoo.com
Wed Jul 21 22:04:22 PDT 2010
This thread dates back to the spring but my interest in it has been renewed by the recent announcement of the party put on by 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.
cheers,
alex
a_kleider at yahoo.com
--- On Sun, 5/16/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: Sunday, May 16, 2010, 7:21 PM
> Quoting Alex Kleider (a_kleider at yahoo.com):
>
> > Once again: thank you, Rick.
> > I thought I had it all figured out and almost didn't
> post the
> > question; ..glad I did.
>
> Just looking through the question you posed, though, I
> realise I
> probably didn't quite do it justice:
>
> > From what I've read, the implication is that a
> 'recursive server'
> > (e.g. unbound) is a name server that is willing
> to _accept_ recursive
> > requests but itself uses _iteration_ (so in
> that sense is
> > 'iterative') to get the answer to the recursive
> request.
>
> Just to not confuse you: You _are_ correct that a
> recursive nameserver
> like Unbound or PowerDNS Recursor itself may well use
> iteration to get the
> answer from elsewhere a step at a time. But we call a
> nameserver
> iterative or recursive based on how it _answers_ queries to
> DNS clients,
> not how it asks them of various upstream authoritative
> nameservers to
> acquire information it doesn't yet have in cache.
>
> The point is that any query, either one from a DNS client
> or one from a
> recursive nameserver to a different nameserver to acquire
> information,
> can have the RD bit set, requesting 'Please, if you're
> willing, Mr.
> Nameserver, don't just tell me you don't have the answer to
> my query in
> cache. Instead, go chase down the information at
> other nameservers and
> get back to me with either the ultimate answer or "No such
> entity".'
>
> The 'no such entity' answer, by the way, is called
> NXDOMAIN, which
> you'll sometimes see in dig results. E.g.:
>
> $ dig i-dont-exist.com
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status:
> NXDOMAIN, id: 41353
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
> ADDITIONAL: 0
>
> ;; AUTHORITY SECTION:
> com.
> 900 IN
> SOA a.gtld-servers.net.
> nstld.verisign-grs.com. 1274062271 1800 900 604800 86400
> $
>
> You might be interested to know that adding the '+trace'
> flag to a dig
> query causes it to send out a series of queries with _no_
> RD bit, such
> that dig itself works down the delegation chain, sending a
> bunch of
> iterative queries. Example:
>
> $ dig uncle-enzo.linuxmafia.com @ns1.linuxmafia.com +trace
> .
> 231480 IN
> NS h.root-servers.net.
> .
> 231480 IN
> NS g.root-servers.net.
> .
> 231480 IN
> NS k.root-servers.net.
> .
> 231480 IN
> NS j.root-servers.net.
> .
> 231480 IN
> NS e.root-servers.net.
> .
> 231480 IN
> NS m.root-servers.net.
> .
> 231480 IN
> NS d.root-servers.net.
> .
> 231480 IN
> NS f.root-servers.net.
> .
> 231480 IN
> NS i.root-servers.net.
> .
> 231480 IN
> NS c.root-servers.net.
> .
> 231480 IN
> NS b.root-servers.net.
> .
> 231480 IN
> NS l.root-servers.net.
> .
> 231480 IN
> NS a.root-servers.net.
> ;; Received 272 bytes from
> 198.144.195.186#53(198.144.195.186) in 3 ms
>
> com.
> 172800 IN NS
> a.gtld-servers.net.
> com.
> 172800 IN NS
> b.gtld-servers.net.
> com.
> 172800 IN NS
> c.gtld-servers.net.
> com.
> 172800 IN NS
> d.gtld-servers.net.
> com.
> 172800 IN NS
> e.gtld-servers.net.
> com.
> 172800 IN NS
> f.gtld-servers.net.
> com.
> 172800 IN NS
> g.gtld-servers.net.
> com.
> 172800 IN NS
> h.gtld-servers.net.
> com.
> 172800 IN NS
> i.gtld-servers.net.
> com.
> 172800 IN NS
> j.gtld-servers.net.
> com.
> 172800 IN NS
> k.gtld-servers.net.
> com.
> 172800 IN NS
> l.gtld-servers.net.
> com.
> 172800 IN NS
> m.gtld-servers.net.
> ;; Received 506 bytes from
> 128.63.2.53#53(h.root-servers.net) in 4875 ms
>
> linuxmafia.com.
> 172800 IN
> NS ns.primate.net.
> linuxmafia.com.
> 172800 IN
> NS ns.tx.primate.net.
> linuxmafia.com.
> 172800 IN
> NS ns1.linuxmafia.com.
> linuxmafia.com.
> 172800 IN
> NS ns1.thecoop.net.
> linuxmafia.com.
> 172800 IN
> NS ns2.linuxmafia.com.
> ;; Received 261 bytes from
> 192.33.14.30#53(b.gtld-servers.net) in 5380 ms
>
> uncle-enzo.linuxmafia.com. 86400 IN
> A
> 198.144.195.186
> linuxmafia.com.
> 86400 IN
> NS ns1.thecoop.net.
> linuxmafia.com.
> 86400 IN
> NS ns.tx.primate.net.
> linuxmafia.com.
> 86400 IN
> NS ns.primate.net.
> linuxmafia.com.
> 86400 IN
> NS ns2.linuxmafia.com.
> linuxmafia.com.
> 86400 IN
> NS ns1.linuxmafia.com.
> ;; Received 201 bytes from
> 198.144.195.186#53(ns1.linuxmafia.com) in 3755 ms
> $
>
>
> So, dig starts by asking ns1.linuxmafia.com where the root
> nameservers
> are. Then, dig asks one of the root nameservers
> (h.root-servers.net)
> what the .com nameservers are. Then, dig asks one of
> the .com
> nameservers (b.gtld-servers.net) what linuxmafia.com's
> nameservers are.
> Last, dig asks one of linuxmafia.com's nameservers
> (ns1.linuxmafia.com)
> what uncle-enzo.linuxmafia.com is.
>
> dig's +trace option is pretty much the opposite of sending
> out a query
> to your local recursive nameserver with the 'RD' bit set
> and asking it
> to do all your work for you. '+trace', by contrast,
> is deliberately
> leaving that bit off on a 'never mind; I'll do it myself'
> basis.
>
> You might say I dig dig. ;->
>
>
> _______________________________________________
> 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/
>
More information about the sf-lug
mailing list