The Village of Lan: A Networking Fairy Tale
By Rick Moen
There was a time, about a year ago, when I was trying to tell people on a LUG mailing list why they should consider using a genuine, full-service recursive nameserver on their local networks, rather than just the usual forwarders and such. One of the leading lights of that LUG countered with his own suggestion: "Run a caching-only or caching-mostly nameserver". Argh! People get so mislead by such really bad terminology.
The concept of a "caching" DNS nameserver really doesn't tell you anything about what the nameserver really does. All nameservers cache;[1] that's not a name that conveys useful information.
What I needed, to clarify the matter, was a compelling and vivid metaphor, so I conjured one up. Here's what I posted back to the LUG mailing list, reproduced for the possible entertainment of Linux Gazette readers:
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 iterative service 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 [and authoritative-only DNS server daemons; see footnote]), 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.
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.
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.)
(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.)
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."
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."
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 village except Larry [and Nils; see footnote], 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.
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.
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.132By 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.
[1] Post-publication quibble:
An authoritative-only DNS nameserver, one that deals solely in data
it publishes to the Internet, lacks caching because the concept
inherently doesn't apply (as "cache" means "local copy for quick
access of data originating elsewhere").
Rick is [2010: was] a member of The Answer Gang.
His first computer was his dad's slide rule, followed by visitor access
to a card-walloping IBM mainframe at Stanford (1969). A glutton for
punishment, he then moved on (during high school, 1970s) to early HP
timeshared systems, People's Computer Company's PDP8s, and various
of those they'll-never-fly-Orville microcomputers at the storied
Homebrew Computer Club -- then more Big Blue computing horrors at
college alleviated by bits of primeval BSD during UC Berkeley summer
sessions, and so on. He's thus better qualified than most, to know just
how much better off we are now.
When not playing Silicon Valley dot-com roulette, he enjoys
long-distance bicycling, helping run science fiction conventions, and
concentrating on becoming an uncarved block.
Rick has run freely-redistributable Unixen since 1992, having been roped
in by first 386BSD, then Linux. Having found that either one
sucked less, he blew
away his last non-Unix box (OS/2 Warp) in 1996. He specialises in clue
acquisition and delivery (documentation & training), system
administration, security, WAN/LAN design and administration, and
support. He helped plan the LINC Expo (which evolved into the first
LinuxWorld Conference and Expo, in San Jose), Windows Refund Day, and
several other rabble-rousing Linux community events in the San Francisco
Bay Area. He's written and edited for IDG/LinuxWorld, SSC, and the
USENIX Association; and spoken at LinuxWorld Conference and Expo and
numerous user groups.