[sf-lug] DNS/BIND, etc.

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> > o  Publishing DNS data is called running an "authoritative nameserver".
> > o  Handing other folks' DNS data is called running a "recursive
> > nameserver".
> Yes, among other possible descriptors (e.g. running a caching-only or
> caching-mostly nameserver).

{sigh}

Although it's true that some recursive-nameserver configurations are
(sloppily) referred to as "caching", e.g., by RHEL/Fedora/CentOS, that's
a really bad name for that function -- because caching is orthogonal to 
recursion.

Theoretically, you could write a nameserver that does recursive service
but doesn't cache its results.  (That would be a bit perverse, and I don't 
know of any.)  Conversely, nameserver packages that cache but know nothing 
about how to recurse and instead do less-helpful alternative iterative service 
(http://www.inetdaemon.com/tutorials/internet/dns/iterative.shtml) are common:
dnsmasq, pdnsd, etc.  

Last, it's also not unheard-of to create a really modest caching
nameserver package that doesn't do even _iterative_ service of its own,
but is purely a forwarder that knows the IP of a _real_ nameserver -- 
or leaves that job up to the machine's resolver library (DNS client). 
I believe dproxy and nscd would be good examples.

And, whether they cache or not (and pretty much _everything_ caches except
OS client resolver libraries), nameservers that aren't _just_ forwarders
offer either recursive or merely iterative service, which makes a big
difference.

I know it's not your fault, but terms like "caching-only" and
"caching-mostly" obscure the actual important bits.  Fortunately, I
think I've just figured out how to fully de-obfuscate the topic.  Here:


The mythical village of Lan has some talkative people (programs) in it.
Oddly, they spend most of their time talking about DNS data ;-> , but
all have quirks about their respective conversational styles.

o  Larry, the local DNS library (the crummy BIND8-derived code bundled
   into GNU libc), is the guy with all the questions.  He's the guy 
   who goes around asking other people about DNS records.  Larry has 
   a really awful memory (no cache), so he ends up asking the same
   questions over and over.

o  Nick (nscd, the nameservice caching daemon) is a kid whom Larry
   has ride on his shoulders occasionally.  Although he doesn't 
   accept queries himself, exactly, he listens to answers Larry 
   gets from others, remembers them, and whispers them in Larry's
   ear when the forgetful old guy is about to go bother others about
   them yet again.  Larry's glad to carry Nick around, to help
   compensate for his memory problem.  On the downside, Nick's a
   bit sloppy and doesn't bother to commit to memory the data's
   spoiled-by dates.  (He doesn't cache TTLs.)[1]

o  Frank is a forwarder (a copy of dproxy).  He's not really bright,
   but has a pretty good memory.  If you ask him a DNS question, he
   either says "Dunno, so I'll ask Ralph", or he says "Hey, someone
   asked me that just yesterday, and I got the answer via Ralph.
   Let's see if I still have the paper... yes.  Here's your IP (or
   other requested datum -- and you're in luck, as it still has 6
   days remaining in its TTL)."  Thus, he forwards all queries he 
   receives -- always to Ralph only, never anyone more suited to the 
   query -- and caches whatever Ralph tells him.  

   When Larry gets such answers, he might also seek some context
   information from Frank.  (Remember, Larry has sucky short-term
   memory.)  "Hey, Frank, thanks.  Is that answer something you know
   from your own knowledge?"  "No, man, it's just what I hear."

o  Nils is an authoritative nameserver (running the "nsd" software), 
   charged ONLY with answering questions of the form "What is
   [foo].lanvillage.com?"  When Larry asks him such a question, he
   answers and adds that it _is_ from his own knowledge (authoritative).
   If you ask him about anything outside lanvillage.com, he
   frowns and say "Dunno, man."

o  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,
   below.)  Like everyone else in this vilage 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 cache), Ralph goes off for a while, and says:  "I
   looked on my desk to see if the answer were there (in cache),
   but it wasn't.  So, I checked to see if answers to the question
   'Where are nameservers for the linuxmafia.com domain?' were there,
   but they weren't either.  So, I check to see if answers to the 
   question 'Where are nameservers for the .com top-level domain?'
   were there, but they weren't either.  So, I finally fell back
   on my Rolodex's list of 13 IP addresses of root nameservers, 
   picked one, and visited it.  I asked it where I can get answers
   to .com questions.  It gave me a list of .com nameserver IPs.
   I picked one, visited it, and asked who knows about linuxmafia.com
   DNS matters.  It gave me a list of linuxmafia.com IPs, I picked
   one, visited it, asked it where uncle-enzo.linuxmafia.com is,
   brought the answer back, and here y'are.  Oh, and I've made a 
   note who knows where .com information is, where specifically
   linuxmafia.com information is, and also where
   uncle-enzo.linuxmafia.com is, just in case I'm asked again."

   Larry's fond of Ralph, because Ralph does all the work and
   doesn't come back until he can give either the answer or
   "Sorry, this took too long", or "There's no such host", or 
   something similarly dispositive.

o  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 five nameserver IPs.]
   "Can you ask linuxmafia.com nameserver #1 where
       uncle-enzo.linuxmafia.com is?"  "OK."  [Queries and gets answer.]

   Next time Dwayne is asked any of the first three questions, his
   answer is no longer "No", because he is able to answer from memory
   (cache).
   
   Notice that Dwayne, although not as helpful and resourceful as
   Ralph, is at least going about things a bit more intelligently
   than Frank does:  Dwayne is able to look up the chain of people
   outside to query (iteratively) to find the right person, whereas
   Frank's idea of research is always "Ask Ralph."

At the outskirts of the Village of Lan is a rickety rope-bridge to the
rest of the state.  (Think "Indiana Jones and the Temple of Doom", or 
"Samurai Jack and the Scotsman".)  All of Lan's commerce has to go over
that bridge (an analogy to, say, a SOHO network's overburdened DSL
line).  Frank or Dwayne's bouncing back and forth across that bridge 
continually gets to be a bit of a problem, because of bridge congestion.
Ralph's better for the village, because he tends to go out, wander
around the state, and then come back -- minimising traffic.  And all of
these guys with functional short-term recall (everyone but Larry)
is helping by avoiding unnecessary bridge crossings.

o   On the far side of the (slow, rickety, congested) ropebridge is
    Ollie (the OpenDNS server).  Ollie is willing to do recursive
    service the way Ralph does, but instead of saying "I checked,
    and there is no such DNS datum" where that is the correct answer,
    it says "guide.opendns.com" (IP 208.67.219.132), which is the
    IP of a OpenDNS Web server, advertising-driven, that tries to 
    give you helpful Web results (plus ads) -- something that's 
    less than useful, and in fact downright harmful, if what's 
    attempting to use DNS isn't a Web browser.  (Gee, ever heard
    of e-mail, for example?)

    I don't know about you, but I think "That place doesn't exist"
    is a better answer than "guide.opendns.com, IP 208.67.219.132",
    when "That place doesn't exist" _is_ in fact the objectively 
    correct answer.  Ollie says:

    $ dig i-dont-exist.linuxmafia.com @resolver2.opendns.com +short
    208.67.219.132
 
    By contrast, my own nameserver gives the actually correct answer:
    $ dig i-dont-exist.linuxmafia.com @ns1.linuxmafia.com +short
    $
    (Specifically, it says "NXDOMAIN", which means "That place doesn't 
    exist.")


Getting back to Larry:  Larry can outsource all of his queries across
the rickety, thin, congested ropebridge to Ollie -- and spend time 
waiting for Ollie and watching him barge continually across it every
time there's a query -- and know that Ollie gives bullshit answers every
time the correct answer _should_ be "That place doesn't exist."

Larry can use Dwayne's services -- something of an exercise in
frustration but better than nothing.  He can tap Frank, which is
_barely_ better than nothing.  Or, he can use Ralph.

Regardless of whom he asks, he _can_ let Nick ride on his shoulders and
serve as his aide-memoire -- with the drawback that Nick carelessly 
disregards something really, really important (TTLs).

Personally, if I were Larry, I'd give Frank, Dwayne, and Ollie a pass, 
dump Nick, and give Ralph a call.



> > So, folks generally don't need to even consider operating authoritative
> > nameservice:  Only domain owners do.
> 
> Well, for The Internet, anyway.  There's also Intranet (RFC 1918)
> namespace, e.g., large corporations, and sometimes even smaller
> businesses, will often run their own purely internal DNS for their
> internal networks ... and they would be authoritative - within the
> scope of those networks, anyway, but not authoritative - and typically
> not even accessible or queryable, from The Internet.

Well, of course.  But I was trying to post an explanation simple enough
to get actually comprehended and acted on _by the target audience_ -- and
someone blindly using ISP nameservers and resisting the notion of _even_
running a local recursive nameserver (as the querent was balking at
doing) isn't worried about internal DNS.

[snip neepery including, for ghod's sake, the loopback zone]

Michael, are you just _opposed_ to simple, clear explanations
appropriate to the question, or what?  ;->



> As for ISPs and the security of their nameservers, quality/security
> varies substantially.  Some are good/excellent....

Let's clear the air about this:  Using _any_ ISP recursive server is
increasing your exposure to cache poisoning by orders of magnitude, over 
merely running a distro package's default install of a decent recursive
package (e.g., pdns-recursor) locally -- because of the ISP server's
defining trait of accepting queries from a large number of other people
(IPs) whom you mostly don't know or have any reason to trust.  Also,
using _any_ ISP recursive server is going to waste your connectivity
bandwidth, and give you noticeably worse performance, compared to
running locally.

The "reduce load on DNS further upstream by using an ISP nameserver"
argument is basically bullshit, because caching means that the delta of
load is negligible.  You're right, it's non-zero.  Technically.  Kind of
like homeopathy.  

Do you know what I'd say, Michael, to a sysadmin who said "Don't run a
local nameserver:  That causes one extra query to a root nameserver per
top-level domain, and one extra query to a TLD nameserver per
second-level domain, until the cache is primed"?  The polite form of my
response would be "You seem to be suffering a serious shortage of
perspective."


> The degree to which one would want to trust/use an ISP's nameservers,
> may also depend - or (should?) be considered along with the relative
> security of and risk to the client system.  E.g. if it's likely the
> ISP's nameservers are and will be better secured and generally run
> quite properly, than the client systems, then it's probably fine to
> use the ISP's nameservers.

Michael, it's _not_ likely.  

ISP nameservers have for a long time been the Typhoid Mary of the
Internet.  Don't take my word for it.  Read (or listen to) Dan
Kaminsky's annual studies presented every year at LISA.


I feel sort of like I'd said "Don't put up with rat infestations in your
house; they're disease vectors", and your response was "Well, that
depends on the rat.  Rats don't _have_ to be disease carriers.  My 
third-grade class had a rat named Fluffy that was perfectly healthy and
clean."

That's terrific about Fluffy, but the fact is, allowing rat infestations 
in one's house is a bad idea for reasons including their being disease
vectors.



> Such a nameserver is at least one good way to get those advantages.
> There are also other ways to often get at least some of those
> advantages.  E.g. nscd can potentially help at least somewhat with
> that....

Spoken like someone who's not actually studied nameserver packages.
Linux's nscd, especially the code that handles host information, is
utter rubbish code -- and, in particular, ignores TTL.


> > Here's how you turn on PowerDNS Recursor on Ubuntu:
> > $ sudo apt-get install pdns-recursor
> 
> Yes, and likewise for Debian.  By default, Debian does quite the right
> thing when one installs BIND - it sets up a caching-mostly
> configuration, caching for most stuff, and being authoritative for
> localnet and some other domains/zones that should never be queried for
> DNS via The Internet.

And I specifically did _not_ recommend BIND9 for that application, and
specifically mentioned better things, because those alternatives avoid 
BIND9's design problems.


> > nameserver 127.0.0.1
> I'd certainly put that *first*, but it *may* be advisable to put in
> another line or two of additional nameservers, ... so DNS will still
> function if/when the primary (local) nameserver is down for some
> reason.

Terrific, so you end up having no idea in advance whether your query
goes to the local nameserver you set up to localise traffic and apply
your own security controls, or to one or more ISP nameserver across a
slow connection and outside your control?  <headsmack>  Doesn't sound
very smart to me.

I'd leave them in the /etc/resolv.conf file, _commented out_.

> Yes, various bits of software can potentially alter /etc/resolv.conf
> when one may - or may not - want that to happen.

Read the resolvconf docs, Michael.  Just about all such packages now
support it, and do _not_ override.


[1] I hear that the Linux nscd implementation's rather severe fault of
not caching TTLs is slated to soon be fixed.  Meanwhile, smart people
don't use its host caching functions.