Re: (forw) Re: New document on Unbound caching DNS server

2 questions to clear up, Rick:

1) In your responses, when you use the word "nameserver", do you always
   mean something that is either completely or majority authoritative?

2) When you use the word "client", do you really mean "resolver"?




On Tue, 18 Sep 2018 01:22:30 -0700
Rick Moen <rick-IyCrq+X4Fdq2oZ/[email protected]> wrote:

> Quoting Steve Litt ([email protected]):
> 
> > I'm having trouble getting definitions. Some ambiguities, and some
> > downright contradictions. More on that later...  
> 
> Understandable.  This is an area where there are indeed those things
> to be found.
> 
> 
> > Unbound also does what's generally called RFC 1034 calls iterative
> > requests: If not in cache it queries 8.8.8.8 or some other recursive
> > server. I believe you call that an "iterative" server in "The
> > Village of Lan", but you seem to call it a forwarder in your "The
> > Basics of DNS" and seem to mix the calls in your "DNS Server (and
> > Related) Software for Unix" (also called Bestiary).  
> 
> Maybe.  Let's see.  Don't forget that for me, getting some of these
> things straight has also been a learning process, so it wouldn't
> surprise me if some later pieces used technical terms a bit
> differently (and, one hopes, better ;-> ) than the earlier ones.
> 
> _However_, I'm not sure you are correct about what I called iterative
> and what I called a forwarder.  As I said, let's see.
> 
> Let's start with what 'recursive' means, because this is where the
> critical difference lies.  Applied to a nameserver daemon, it means
> capable of optimally handling a query received that was sent with its
> 'RD' (recursion desired) bit set.  Upthread, I described what the
> server does in that case.  I'll add, here, that the server will set
> the RA (recursion available) bit on such an answer sent to the client.
> 
> The answer will be either DNS resolution or not.  If not, there will
> be flags indicating why not, such as NXDOMAIN (sorry, I don't have an
> answer for you) or others such as SERVFAIL and kin.  
> 
> So, when I say 'recursive nameserver', I mean one returning correct
> DNS answers with the RA bit set following, as necessary, the act of
> recursing through delegation trees and thereby consulting applicable
> content servers.  (THe most obvious reason why such an operation might
> not be necessary is if it has a qualifying answer in cache whose TTL
> hasn't yet expired.)  I'm quite certain my use of the term is the
> standard one.
> 
> Next, consider 'iterative'.  It denotes a nameserver with full
> knowledge or, and ability to consult, the global DNS namespace,
> querying remote servers as necessary to get answers, but that lacks
> the ability to recurse through hierarchies before responding.  My
> surmise (supported in part by talking with my friend and MaraDNS
> author Sam Trenholme) is that this shortfall typically arises because
> writing recursive nameserver software is extremely difficult,
> requiring writing very exacting _threaded_ code.  A number of open
> source projects have attempted to solve that project but then been
> abandoned uncompleted, e.g., dents, moodns, Oak DNS Server.  
> 
> Sam Trenholme says he found that writing the recursive code for the
> original MaraDNS 1.x suite was by far the most difficult part of the
> project.  He was also dissatisfied enough with the results that he
> did a from-scratch rewrite module called Deadwood for MaraDNS 2.x,
> and it is now the default recursive server component in 2.x.  (The
> 1.x recursive daemon is also provided in case someone needs it, but
> is no longer recommended.)
> 
> If an otherwise all-around nameserver cannot recurse, then any
> responses it sends to clients with have a zero in the RA (recursion
> available) bit, to signal to the clients that when it says 'Sorry, I
> don't have an answer for you, but you might want to ask the NS
> entities for linuxmafia.com') to a query for a particular DNS entity
> like uncle-enzo.linuxamfia.com, that this is not exhaustive
> information.  The client would then come back with a new query, 'OK,
> then, what are the NS values for domain linuxmafia.com?.  If the new
> response is 'Sorry, I don't have an answer for you, but you might
> want to ask the NS entities for com.', then the client would come
> back with such a query, and worst case might have to repeat again to
> get the list of root-zone NS server IPs, then query back down the
> ladder to finally get the uncle-enzo.linuxamfia.com answer.  (This is
> covered in RFC 1034 section 4.3.1 among other places.)  Only after
> all that doesn't get anything but NXDOMAIN, should the answer be
> considered exhaustive.
> 
> Again, I'm quite certain this is the standard meaning of 'iterative'
> in relation to server software:  unable to comply with the 'RD'
> request, and thus falling back on iterative service only, which is a
> baseline capability of all content servers not limited just to
> authoritative service.
> 
> Last, consider 'forwarder'.  In contrast to an iterative server or a
> recursive server, a forwarder nameservice daemon has zero knowledge
> of, and zero ability to consult, the global DNS namespace.  It
> doesn't know where the root nameservers are, even.  All it knows is
> one or two IP addresses (of remote recursive nameservers) you
> furnished in its configuration file, and how to hurl any DNS query it
> receives across networks to the first of those IP addresses that can
> be reached, repeating the query to it, receiving back whatever
> response the remote recursive nameserver issued, and repeating that
> response back to the client.  A forwarder isn't missing only the
> intelligence required to recurse through hierarchies to chase down a
> response; it's missing pretty much all understanding of globel DNS.
> It just shovels queries out to some IP (or rather, the first
> available of a list of IPs to try), and repeats back what the remote
> machine says.
> 
> I am not completely certain whether the term 'forwarder' has a
> universally agreed-upon definition, but I have high confidence that if
> you asked a nameserver author what it means, you'd get that back as a
> reply.
> 
> Now, I should also tell you, the categories I show in (say) the table
> of contents for
> http://linuxmafia.com/faq/Network_Other/dns-servers.html are my best
> guess / surmise after plowing through often murky project Web pages
> and documentation -- in most cases.  In a few cases, happily, I have
> extensive enough personal experience with the software that I will
> vouch strongly for the categories' accuracy.  But I'm perfectly fine
> with admitting that some category errors may still lurk there despite
> my best efforts. 
> 
> Let's return to your passage that I quoted above:
> 
> > Unbound also does what's generally called RFC 1034 calls iterative
> > requests: If not in cache it queries 8.8.8.8 or some other recursive
> > server  
> 
> I believe you are misinterpreting, here, that passage in the middle of
> RFC 1034 section 2.3.  And you are also not correctly understanding
> what Unbound does, _absent special configuration_.  The RFC passage:
> 
>    In any system that has a distributed database, a particular
>    name server may be presented with a query that can only be
>    answered by some other server.  The two general approaches to
>    dealing with this problem are "recursive", in which the first
>    server pursues the query for the client at another server, and
>    "iterative", in which the server refers the client to another
>    server and lets the client pursue the query. 
> 
> Unbound doesn't do the latter, i.e., if it lacks a cached response,
> then it doesn't merely send the client 'Sorry, I don't have an answer
> but you might ask [FOO] and give up, which is what RFC 1034 means by
> 'refer the client to another server and let the client pursue the
> query'.  Instead, Unbound recurses through other appropriate content
> servers.  (It would use specifically 8.8.8.8 or something like that
> only if you enabled whatever optional unbound.conf syntax that
> enables the sysadmin to declare forwarder IPs.  Which, by the way, is
> a really bad idea to do unless you have a really good reason, because
> doing that partially lobotimises Unbound, forcing it to send all
> queries to just _one_ place instead of permitting it to use its
> intelligence to find the _right_ places in the global namespace to
> ask.)
> 
> And, by the way, in case you're curious about this, the term
> 'authoritative' concerning a DNS datum means, in an operational
> sense, 'has the AA = authoritative answer bit set'.  So, for example,
> if you shovel all queries out the door to Google's 8.8.8.8 cluster,
> including, say, one about uncle-enzo.linuxmafia.com, if the 8.8.8.8
> host happens to have the answer with unexpired TTL in its gigantic
> cache (as it often does), then it will return that answer still with
> it AA bit set.  How did that bit get set, you ask?  Because one of
> the 8.8.8.8 hosts in the recent past queried it either from one of
> the six authoritative servers for domain linuxmafia.com or from
> another content server that had it cached, in any event ultimately
> derived from the six authoritative servers, the ultimate source that
> issued the information with the AA bit set in the first place.
> 
> 
> > I believe you call that an "iterative" server in "The Village
> > of Lan", but you seem to call it a forwarder in your "The Basics of
> > DNS" and seem to mix the calls in your "DNS Server (and Related)
> > Software for Unix" (also called Bestiary).  
> 
> I don't think so.  Can you tell me where?
> 
> 'Forwarder' means lacks the intelligence to to any local resolution,
> but instead just hurling all queries over the transom to one or more
> predeclared IP address, and repeating back to clients what they say.  
> This has the advantage of being the easiest type of nameserver daemon
> code to write.  Being extremely simple, it's also relatively easy to
> not make embarrassing coding gaffes, though the bugfix security-patch
> histories of pdnsd and Dnsmasq have been scary enough to give one
> pause.
> 
> 'Iterative' means the daemon can at least choose on its own where to
> send queries rather than just hurling them out to one of a small
> number of predeclared IP addresses, _but_ unable to correctly process
> a query with the 'RD' bit set, and thus limited to replying only in
> the iterative fashion.  The code is an order of magnitude more
> complex than that of a simple forwarder, but doesn't aspire to solve
> the infamously difficult, programmer-challenging problem of doing
> recursive resolution.
> 
> 'Recursive' means able to do everything including fully recursing
> through all required hierarchies on a query with the RD bit set
> before giving the client any answer, and signaling that the answer
> has that definitive status by setting the answer's RA bit.
> 
> 
> > Thanks. I was under the impression that authoritative servers could
> > not descend their own hierarchies  
> 
> Um, what?
> 
> I don't even know for certain what you mean by an authoritative server
> descending its own hierarchy.  
> 
> Let me try to conjure up a specific linuxmafia.com example.  I can
> have aritrary numbers of levels of subdomains resolvable right at
> ns1.linuxmafia.com and its four fellow nameservers that are
> authoritative for the linuxmafia.com domain -- locally defined right
> there in the main zonefile or in #include files, or however one's
> choice of authoritative software stores such definitions.  For
> example, I could have subdomains halogen and noble:
> 
> fluorine.halogen.linuxmafia.com
> chlorine.halogen.linuxmafia.com
> bromine.halogen.linuxmafia.com
> iodine.halogen.linuxmafia.com
> astatine.halogen.linuxmafia.com
> tennessine.halogen.linuxmafia.com
> 
> helium.noble.linuxmafia.com
> neon.noble.linuxmafia.com
> argon.noble.linuxmafia.com
> krypton.noble.linuxmafia.com
> xenon.noble.linuxmafia.com
> radon.noble.linuxmafia.com
> oganesson.noble.linuxmafia.com
> 
> If I were to define those two subdomains and those 13 hosts within 
> the linuxmafia.com namespace, then _absolutely_ all six nameservers
> authoritative for namespace linuxmafia.com could decend into the two
> subdomains and resolve any record in the database concerning the
> thirteen hosts and the two subdomains.
> 
> If the software running ns1.linuxmafia.com (my main nameserver
> machine) were running authoritative _only_ nameserver software, such
> as (say) NSD or tinydns, then it would refuse requests for anything
> outside the specific domains for which it believes itself
> authoritative.  (IIRC, it would say 'SERVFAIL'.)  Like, e.g., if you
> asked it to resolve the 'A' record for www.redhat.com .  However, at
> the moment because of certain legacy considerations,
> ns1.linuxmafia.com is still running BIND9, so it will happily parse
> the query for an 'A' record on www.redhat.com, think 'Oh, that's not
> one of _my_ domains for which I'm authoritative', then pass the query
> to its recursive nameservice code, find the NS server IP addresses
> for domain redhat.com (if necessary recursing down all the way to the
> DNS root), then query a redhat.com nameserver for the answer, store
> the result in cache, and report back the answer to the client process.
> 
> ==Moreover==, if I wished, I could have the zone _delegate_ authority
> for each subdomain, halogen.linuxmafia.com and noble.linuxmafia.com,
> to separate authoritative nameservers specific to each.  
> 
> (I believe that answers your question 'Can you confirm that a
> purely authoritative server can query  its subdomains' nameservers?'
> The answer is 'yes, of course.')
> 
> 
> 
> This is in fact how queries reach the linuxmafia.com domain's
> nameservers in the first place, because there are 'glue' NS records
> for domain linuxmafia.com inside the com. domain's (the parent
> domain's) zone records.
> 
> $ dig -t ns com. +short
> c.gtld-servers.net.
> d.gtld-servers.net.
> b.gtld-servers.net.
> i.gtld-servers.net.
> a.gtld-servers.net.
> j.gtld-servers.net.
> h.gtld-servers.net.
> f.gtld-servers.net.
> g.gtld-servers.net.
> l.gtld-servers.net.
> e.gtld-servers.net.
> m.gtld-servers.net.
> k.gtld-servers.net.
> [rick@linuxmafia]
> $ dig -t ns linuxmafia.com. @c.gtld-servers.net.
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 201
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 6
> ;; WARNING: recursion requested but not available
> 
> ;; AUTHORITY SECTION:
> linuxmafia.com.         172800  IN      NS      ns1.linuxmafia.com.
> linuxmafia.com.         172800  IN      NS      ns.primate.net.
> linuxmafia.com.         172800  IN      NS      ns.tx.primate.net.
> linuxmafia.com.         172800  IN      NS      ns3.linuxmafia.com.
> linuxmafia.com.         172800  IN      NS      ns6.linuxmafia.com.
> 
> ;; ADDITIONAL SECTION:
> ns1.linuxmafia.com.     172800  IN      A       198.144.195.186
> ns.primate.net.         172800  IN      A       198.144.194.12
> ns.primate.net.         172800  IN      AAAA
> 2001:470:1f00:ffff::6b7 ns.tx.primate.net.      172800  IN
> A       72.249.38.88 ns3.linuxmafia.com.     172800  IN      A
> 198.144.209.73 ns6.linuxmafia.com.     172800  IN      A
> 209.205.200.166 $
> 
> See the responses to the second query?  Those are entries _inside_ the
> com. domain's zonefile -- the 'glue records' that permit the entire 
> chain of delegation to work at all.
> 
> 
> >>      Unbound can also resolve local LAN hosts via its local-zone,
> >>      local-data, and local-data-ptr server commands in its
> >> configuration file. In other words, instead of delegating
> >> authority to another server, Unbound can do authoritative DNS, to
> >> a limited degree, all by itself.
> >>
> >> Um, the alternative scenario isn't _delegation_, but rather
> >> consulting data at or derived from authoritative servers.  
> > 
> > I don't understand the distinction. The data isn't at or derived
> > from auth servers, it's written right into unbound.conf.  
> 
> 
> I was objecting to your (false) dichotomy between locally defined
> resolution and _delegation_.  My poing is that sending a query to 
> recursive nameservers elsewhere because the item requested simply
> isn't in the server's authoritative namespace (what Prof. Bernstein
> calls its 'bailiwick') is not called _delegation_.  Delegation is
> something else entirely.
> 
> Delegation is something like ns1.linuxamfia.com thinking 'Oh, the
> client wants information within the halogen.linuxmafia.com.
> namespace.  That's indeed in my namespace, but it's in a portion of
> my namespace that my owner wants me to delegate to a different
> nameserver that handles that entire subdomain's authoritative
> information.'
> 
> Or it'd be something like com.'s nameservers saying 'Oh, the client
> wants information within the linuxmafia.com. namespace.  That's
> indeed in my namespace, but it's in a portion of my namespace that
> my owner wants me to delegate to one of a set of six different
> nameservers that handles that entire linuxmafia.com subdomain's
> authoritative information.'  (See the glue records above.)
> 
> A delegated query is still within the domain's bailiwick.  Queries
> about linuxmafia.com. are still within the com. nameservers'
> bailiwick. Queries about halogen.linuxmafia.com are still within
> linuxmafia.com's nameservers' bailiwick.  
> 
> Queries _outside_ that bailiwick, such as the way an 'A' record query
> for www.redhat.com. is outside the linuxmafia.com. nameservers'
> bailiwick, will not be _delegated_, as my domain's nameservers cannot
> do that and wouldn't know how to.  Instead, if they are being fielded
> by an authoritative-only daemin, the queries will fail (I believe with
> 'SERVFAIL' set on the answer).  If they are being fielded by a daemon
> such as BIND9 that is multifaceted and can do services other than
> authoritative ones, it will be redirected to an appropriate recursive
> server elsewhere.
> 
> 
> 
> > I was under the impression iterative was like this:
> > 
> > Steve: Dwayne, what's the IP address of uncle-enzo.linuxmafia.com?
> > Dwayne: Dwaynecache, you have uncle-enzo.linuxmafia.com? 
> > Dwaynecache: No
> > Dwayne: Google 8.8.8.8, what's the IP address of
> >              uncle-enzo.linuxmafia.com?
> > 8.8.8.8: Dwayne, it's 198.144.195.186  
> 
> No.  Why the Gehenna would a nameserver offering iterative service
> unconditionally offload the query to specifically 8.8.8.8?  That makes
> no sense.  That's being just a dumb forwarder.  Gosh, Steve, I hope
> you aren't configuring your namservice software to shovel all queries
> outbound to just one or two fixed IP address.  That would be
> lobotomising the software on your end, forcing it to pretend as if it
> cannot figure out how to query appropriate nameservers.
> 
> 
> 
> 
> >>    Unbound is fast becoming the go-to DNS caching server, replacing
> >>    Bind
> >>
> >> No, it's fast becoming the go-to _recursive_ DNS nameserver,
> >> replacing the _recursive_ functionality of BIND9.  
> > 
> > Recursive, caching, and iterative if BIND9 has iterative
> > abilities.  
> 
> Please, for the love of Ghu,  forget 'caching' as a category, because
> it's pretty meaningless in that context, and a distraction from
> distinctions that actually matter.
> 
> _Of course_ BIND9 has iterative capabilities.  Anything beyond a dumb
> forwarder does.  Any recursive nameserver includes iterative
> functionality by implication (and I believe you'll find that stated in
> RFC 1034 as well), kind of like saying 'In addition to talking, Jim
> also breathes.'
> 
> You can force a recursive server to dummy down its abilities by
> omitting the 'RD' bit on queries, e.g., by using the +norecurse flag
> with 'dig':
> 
> 
> DIG(1)
> BIND9                              DIG(1)
> 
> NAME
>        dig - DNS lookup utility
> [...]
> 
>        +[no]recurse
>            Toggle the setting of the RD (recursion desired) bit in
> the query. This bit is set by default, which means dig normally sends
>            recursive queries. Recursion is automatically disabled
> when the +nssearch or +trace query options are used.
> 
> Demonstrating:
> 
> $ dig www.redhat.com @ns1.linuxmafia.com +norecurse
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33676
> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 2
> 
> ;; AUTHORITY SECTION:
> com.                    139204  IN      NS      c.gtld-servers.net.
> com.                    139204  IN      NS      j.gtld-servers.net.
> com.                    139204  IN      NS      d.gtld-servers.net.
> com.                    139204  IN      NS      b.gtld-servers.net.
> com.                    139204  IN      NS      g.gtld-servers.net.
> com.                    139204  IN      NS      e.gtld-servers.net.
> com.                    139204  IN      NS      i.gtld-servers.net.
> com.                    139204  IN      NS      f.gtld-servers.net.
> com.                    139204  IN      NS      k.gtld-servers.net.
> com.                    139204  IN      NS      l.gtld-servers.net.
> com.                    139204  IN      NS      m.gtld-servers.net.
> com.                    139204  IN      NS      h.gtld-servers.net.
> com.                    139204  IN      NS      a.gtld-servers.net.
> 
> ;; ADDITIONAL SECTION:
> c.gtld-servers.net.     84924   IN      A       192.26.92.30
> c.gtld-servers.net.     84924   IN      AAAA    2001:503:83eb::30
> $
> 
> Asked in that fashion (_with recursion disabled_) ns1.linuxmafia.com
> didn't know, basically, but it returned in the AUTHORITY and
> ADDITIONAL sections the suggestion to ask the com. nameservers, which
> it helpfully listed.
> 
> Now, here's the same query and response from ns1.linuxafia.com
> without disabling recursive mode (non-disabled being default, as the
> man page said):
> 
> $ dig www.redhat.com @ns1.linuxmafia.com
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15662
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 8, ADDITIONAL: 0
> 
> ;; ANSWER SECTION:
> www.redhat.com.         3600    IN      CNAME
> ds-www.redhat.com.edgekey.net. ds-www.redhat.com.edgekey.net. 21600
> IN CNAME ds-www.redhat.com.edgekey.net.globalredir.akadns.net.
> ds-www.redhat.com.edgekey.net.globalredir.akadns.net. 3600 IN CNAME
> e3396.dscx.akamaiedge.net. e3396.dscx.akamaiedge.net. 20   IN
> A       23.72.6.193
> 
> ;; AUTHORITY SECTION:
> dscx.akamaiedge.net.    4000    IN      NS      n0dscx.akamaiedge.net.
> dscx.akamaiedge.net.    4000    IN      NS      n3dscx.akamaiedge.net.
> dscx.akamaiedge.net.    4000    IN      NS      n5dscx.akamaiedge.net.
> dscx.akamaiedge.net.    4000    IN      NS      n4dscx.akamaiedge.net.
> dscx.akamaiedge.net.    4000    IN      NS      n6dscx.akamaiedge.net.
> dscx.akamaiedge.net.    4000    IN      NS      n1dscx.akamaiedge.net.
> dscx.akamaiedge.net.    4000    IN      NS      n7dscx.akamaiedge.net.
> dscx.akamaiedge.net.    4000    IN      NS      n2dscx.akamaiedge.net.
> $ 
> 
> Anyway, seriously, it would have been correct to say that 'Unbound is 
> fast becoming the go-to _recursive_ DNS nameserver, replacing the
> _recursive_ functionality of BIND9', not 'the go-to DNS caching
> server' (what you wrote).  Really.  Not kidding.
> 
> 
> 
> 
> 
> > And now for a terminology problem that's REALLY kicking my butt...
> > 
> > From RFC-1034 I understand that a DNS *client* is really just a
> > computer program, like Firefox or ssh  
> 
> Or 'dig'.  If you really want to understand DNS, get to know how to 
> use 'dig', sir.  It's your friend.  Read the man page, make sure you
> understand its basics, and some of its neat tricks such as 'trace'
> mode.
> 
> 
> > According to RFC-1034 section 4, the term "Name Server"
> > applies to an authoritative server, which may or may not have other
> > abilities. I can't tell from RFC-1034 or 1035 what a "resolver" is,
> > other than it gets its queries from clients like Midori and passes
> > those requests to Name Servers it knows about.  
> 
> In practice, the term 'resolver' is such an overloaded term that it's
> best avoided.
> 
> Probably if I read the DNS-defining RFCs closely, I could tell you
> what it's supposed to mean in that context, but that wouldn't help
> you very much in the real world, because it's used far too vaguely
> and to refer to too diverse a collection of distinct things.  This is
> why my pages and articles eschew the term except with appropriate
> qualifers such as in the phrase 'resolver library'.
> 
> > Thus, it seems like Unbound is more of a resolver than a server  
> 
> {sigh}
> 
> 'Resolver' can mean lots of different things.  'Server' means 'machine
> or process spoken to by clients for a particular purpose'.
> 
> 
> 
> 
> >   
> > > 
> > > Also, if you're going to post documentation about DNS server
> > > software, you should make sure you understand fundamental concepts
> > > _first_ before doing so, such as 'recursive', 'authoritative', and
> > > 'glue records'.  I won't be so egotistical as to suggest my
> > > several pieces about DNS (all linked from
> > > http://linuxmafia.com/~rick/ )  
> > 
> > 
> > I've now read these.
> > 
> >   
> > > , but
> > > there are good industry guides on the open Web that are well worth
> > > skim-reading, such as Zytrax's:
> > > http://www.zytrax.com/books/dns/  
> > 
> > 
> > I've now skimmed its table of contents.
> > 
> >   
> > > 
> > > For heaven's sake, please revise that essay, _and_ learn the
> > > subject properly.    
> > 
> > 
> > OK.
> > 
> >   
> > > 
> > > 
> > > ----- Forwarded message from Rick Moen <rick-IyCrq+X4Fdq2oZ/[email protected]>
> > > -----  
> > .     
> > > 
> > > Strictly speaking, that's a fruit-basket to orange comparison.
> > > Unbound doesn't replace BIND9.  It replaces one function of BIND9.
> > > 
> > > Quoting from the table of contents in my page
> > > http://linuxmafia.com/faq/Network_Other/dns-servers.html:
> > > 
> > >   o  BIND9: authoritative, recursive, AXFR, client
> > >   o  Unbound: recursive[1]  
> > 
> > 
> > Unbound also does what's generally called RFC 1034 calls iterative
> > requests: If not in cache it queries 8.8.8.8 or some other recursive
> > server. I believe you call that an "iterative" server in "The
> > Village of Lan", but you seem to call it a forwarder in your "The
> > Basics of DNS" and seem to mix the calls in your "DNS Server (and
> > Related) Software for Unix" (also called Bestiary). Meanwhile,
> > Unbound actually implements these via its forward-zone and
> > forward-addr constructs. I have to decide on a single name for
> > this, to use throughout.
> > 
> > 
> > [snip]
> > 
> >   
> > > 
> > > Thanks.  Skim reading it now.
> > > 
> > >    according to its Web site, [Unbound] also does recursive
> > > queries, although I'm not sure exactly what they mean by that
> > > 
> > > It means it complies with the request implied by the 'RD' bit
> > > (recursion desired) being set on a query.  That bit being set
> > > loosely translates to 'Just go ahead and chase through as many
> > > delegations as necessary to get me the answer, rather than making
> > > me, the DNS client, micromanage the delegation process and climb
> > > the delegation hierarchy until we get answers.  
> > 
> > Thanks. I was under the impression that authoritative servers could
> > not descend their own hierarchies, and that the recursive resolver
> > or recursive DNS server had to do all of that itself.
> >   
> > > 
> > > I explain the recursive vs. iterative difference in my 2010
> > > article 'The Village of Lan: A Networking Fairy Tale':
> > > 
> > >   Dwayne is a nameserver offering iterative service only (running
> > >   dproxy). You can get any DNS answer out of him _eventually_, but
> > > he's not willing to bounce around the state following leads. A
> > > conversation with Dwayne is sort of punctuated:
> > > 
> > >   "Do you know where uncle-enzo.linuxmafia.com is?" "No."
> > >   "Well, do you know who knows?" "No."
> > >   "Well, do you know who knows where to find .com nameservers?"
> > > "No." "Well, can you ask the root nameserver where to find .com
> > > nameservers?" "OK." [Gives list of 13.]
> > >   "Can you ask .com nameserver #1 who answers for linuxmafia.com?"
> > > "OK." [Gets list of six nameserver IPs.]  
> > 
> > 
> > I was under the impression iterative was like this:
> > 
> > Steve: Dwayne, what's the IP address of uncle-enzo.linuxmafia.com?
> > Dwayne: Dwaynecache, you have uncle-enzo.linuxmafia.com? 
> > Dwaynecache: No
> > Dwayne: Google 8.8.8.8, what's the IP address of
> >              uncle-enzo.linuxmafia.com?
> > 8.8.8.8: Dwayne, it's 198.144.195.186
> > 
> > I was under the impression that what you described above was more
> > like recursive. BUT, I thought that rather than "can you ask .com
> > nameserver #1", I would ask .com nameserver #1 myself. Can you
> > confirm that a purely authoritative server can query  its
> > subdomains' nameservers?
> > 
> >   
> > >   "Can you ask linuxmafia.com nameserver #1 where
> > >   uncle-enzo.linuxmafia.com is?" "OK." [Queries and gets answer.]
> > > 
> > > 
> > > In contrast to:
> > > 
> > >   Ralph is a recursive nameserver (an instance of PowerDNS
> > > Recursor). Ralph is a born researcher: He doesn't have any DNS
> > > knowledge of his own (offers no authoritative service), but
> > > absolutely lives for finding out what DNS data can be unearthed
> > > from guys in other villages. If you ask him a DNS question, he'll
> > > figure out whom to ask, go there regardless of where it takes
> > > him, if necessary chase around the state following leads, and
> > > only bother you when he has the final answer. (This is the
> > > "recursive" part. Compare with the iterative approach.) Like
> > > everyone else in this village except Larry, he has a good memory
> > > (caching).
> > > 
> > >   Let's say, Larry asks Ralph, "What's
> > > uncle-enzo.linuxmafia.com?" In the worst case, if Ralph is just
> > > back from vacation (has a depleted  
> > 
> > 
> > [snip Ralph's behavior, which matches how I think recursive servers
> > work.]
> >  
> >    
> > > Returning to your article
> > > 
> > >     A caching DNS server
> > > 
> > > Ugh.  I really wish someone would take that phrase out and garrote
> > > it, because all DNS software (except authoritative-only daemons)
> > > does caching, so saying a server is 'caching' tells you nothing
> > > useful.  
> > 
> > 
> > I came to the same conclusion and will be removing that phrase. If
> > something caches, it's a feature, not a subset nor an identifier.
> > 
> >   
> > > 
> > > IMO, your terminology, there, is a problem, as it suggests a
> > > category distinction that really isn't real and isn't the issue.
> > > 
> > >    Unbound is capable of passing queries to authoritative servers
> > > 
> > > Well, I would _hope_ so.  If it couldn't, it would never get any
> > > data at all.  That's the only place the data ultimately comes
> > > from, you know.
> > > 
> > >    Unbound can also resolve local LAN hosts via its local-zone,
> > >    local-data, and local-data-ptr server commands in its
> > > configuration file. In other words, instead of delegating
> > > authority to another server, Unbound can do authoritative DNS, to
> > > a limited degree, all by itself.
> > > 
> > > Um, the alternative scenario isn't _delegation_, but rather
> > > consulting data at or derived from authoritative servers.  
> > 
> > 
> > I don't understand the distinction. The data isn't at or derived
> > from auth servers, it's written right into unbound.conf.
> > 
> >   
> > > 
> > >    Unbound is fast becoming the go-to DNS caching server,
> > > replacing Bind
> > > 
> > > No, it's fast becoming the go-to _recursive_ DNS nameserver,
> > > replacing the _recursive_ functionality of BIND9.  
> > 
> > Recursive, caching, and iterative if BIND9 has iterative abilities.
> > AND, it offers limited abilities to answer queries about the subnet
> > on which it works. But it doesn't do auth like BIND9, you need NSD
> > or another auth server to do that.
> > 
> > And now for a terminology problem that's REALLY kicking my butt...
> >   
> > >From RFC-1034 I understand that a DNS *client* is really just a
> > >computer  
> > program, like Firefox or ssh, that queries a DNS *resolver*, via
> > library calls. According to RFC-1034 section 4, the term "Name
> > Server" applies to an authoritative server, which may or may not
> > have other abilities. I can't tell from RFC-1034 or 1035 what a
> > "resolver" is, other than it gets its queries from clients like
> > Midori and passes those requests to Name Servers it knows about.
> > Thus, it seems like Unbound is more of a resolver than a server,
> > but I've not yet seen an RFC that makes it clear where resolver
> > leaves off and Name Server begins.
> > 
> > Thanks for pointing this all out to me. Confusion in the terminology
> > surrounding DNS makes it much harder to understand.
> > 
> > Thanks,
> >  
> > SteveT