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

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
> 
> Steve Litt 
> September 2018 featured book: Quit Joblessness: Start Your Own Business
> http://www.troubleshooters.com/startbiz
> 
> _______________________________________________
> svlug mailing list
> [email protected]
> http://lists.svlug.org/lists/listinfo/svlug