[sf-lug] pdns-recursor
Alex Kleider
a_kleider at yahoo.com
Sun May 16 19:43:58 PDT 2010
..and I dig your answers!
Thank you again
..and as an aside, O'Reily should be paying you to write books.
This last round of inquiry on my part resulted from having read the first 3 chapters of their DNS and BIND book by Liu and Albitz, which (the books first 3 chapters, I mean,) from my perspective, failed to clarify what you've done in a couple of emails.
cheers,ak
--- 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