[sf-lug] pdns-recursor

[Rick Moen]

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.  ;->