[ale] cacheing DNS?

[Michael H. Warfield]

On Tue, 2012-05-08 at 16:46 -0500, John Heim wrote:
> I'm confused about caching DNS and recursion. I keep reading that best 
> practice is to not use the same dns servers for the machines on your LAN as 
> you do for those outside your LAN.

That is, more or less, a misstatement, as it really breaks down
differently though I can certainly understand where it looks that way
without getting into a lot of detail.  Which is what I'm about to do.
You have been warned...

First, name servers roughly break down into authoritative name servers,
which serve up data on zones for which they are responsible, and caching
resolvers which can be recursive or forwarding or some combination of
both.  While an authoritative name server may (depending on software)
act as both an authoritative name server for certain zones and a
resolving name server for others, this tends to be a bad practice and I
highly recommend against it.

As a rule, obviously, if you are the owner of a domain name, you need
some public authoritative name servers outside of your network to
provide your zone information to querying parties or nobody could find
you.  That doesn't mean your "master" needs to be publicly exposed, the
public servers can all be slaves that pull data from a protected private
master, which is what I generally recommend for robust DNS deployments.

So, if you have a couple of public authoritative name servers exposed to
queries for your domain / zones out on the net, you have one or more
private masters which only the slaves can reach.  Historically, it has
been best common practice that you should have at least three available
public authoritative name servers located in diverse locations both
geographically and topologically.  You can get away with two.  At one
time long time ago, you couldn't even register a domain without having
at least two.

Years ago, Microsoft had all five of their public authoritative name
servers all on the same network.  But, they were all slaves to a private
master (well, they got one thing right at least).  Someone, at one
point, made an accidental change to a firewall rule that cut the slaves
off from the master and then went home, blissfully unaware of what they
had just done, after their shift was over.  Many many hours later, after
the TTL (Time To Live) expired in the individual slaves, the slaves
basically fell over and refused to provide authoritative results.
Result - Microsoft fell off the Internet.  They figured out what THAT
problem was after much confusion and fear they were under attack and
they got it back up the next day.  But!  It was not before the word had
spread on the net that they had all their public servers on one small
network with a single route in.  By the time they got the slaves back
talking with the master, they discovered the router to the net was being
DDoS and they were then down for several MORE days.

IAC...  Your exposed public authoritative name servers should have
recursion completely disabled for anything other than itself.  You don't
need any recursive name servers exposed to the public network.  I've had
customers who did NOT understand this and had public recursers exposed
only to find attackers spoofing their local network addresses in
requests to the public recurser in creating DDoS attacks.  Painful to
fix.  Solution was to shut down those exposed recursers (note - I did
not say open) and only use recursers that were safely behind a security
perimeter that could block spoofed packets. 

Which brings me to your recursers.  These should only be behind your
security perimeter specifically because they can be abused to attack you
or other sites.  Even if you restrict recursion to certain clients, DNS
is UDP based and is trivial to spoof.  You also want to limit your
attack surface from DNS Cache Poisoning attacks.

If you're running a simple home network, a single cacher is probably
sufficient.  Having more doesn't add anything more than a little
redundancy in case one goes down.  If you have a larger network with
multiple subnetworks, it gets more complicated and you may want several
name servers, possibly with different routes to the internet.  That does
come with a performance penalty in that what gets cached in one name
server is not automatically cached in another.  But, multiple caching
servers also provide some additional resilience against cache poisoning
attacks as well and can limit their scope.

Yes, you can have your recursive cachers also be internal authoritative
name servers for your zones at the cost of some additional complexity
and not all name server software supports both modes.  Bind will work
perfectly fine as an authoritative name server and caching name server
simultaneously but dnsmasq does not support being an authoritative name
server at all.  There are some examples of name server software which
can also only be authoritative (mostly used by the root name servers and
not very common).  Also, with dnsmasq, you don't get a full blown
caching recurser.  Dnsmasq is a forwarding name server and won't query
the root name servers for tld redirection.  Dnsmasq has to be configured
for the next level resolver to forward queries to.  In the case of your
typical home router / wireless router, dnsmasq gets its next level DNS
server configuration information either from the static configuration or
the dhcp responses on its Internet interface.

Now there are two other, specialized cases that probably don't fit in
with what you're interested in.

One case is a filtering slave.  This is a slave that pulls zone
information from a master and then, possibly after some manipulation,
acts as a master to other slaves.  In a sense, you have slaves pulling
from slaves but the leaf slaves don't see this.  This is one way of
implementing DNSsec using a "bump on the wire" model where your signing
machine pulls zone information from your authoritative master, signs the
zone information and then provides the signed zone information to the
public slaves.  OpenDNSSEC can work this way.  It's a cute trick to make
a "drop in" DNSsec signer without making radical changes to your
existing infrastructure.  Even without performing manipulations, there
may be cases where you have slaves which can not reach your master, so
you slave one slave off another slave.  I do this now with many of my
zones and domains.

The other case is not really even a name server per se, although it
looks like one to your authoritative name servers.  It's a monitoring
server.  It pulls zone transfers from ALL of your authoritative name
servers and compares the results.  If name servers get out of sync (or
get compromised) the monitor can spot the discrepancies and raise
alarms.  This would have tipped off Microsoft to their failures
lllooonnnggg before they had egg on their face and their shortcomings in
the news and providing entertainment.

> So if I'm the admin of example.org and if 
> I want redundant DNS servers for both internal and external queries, do I 
> have to run four DNS servers?  Do people really do that?

I run far more than that.

I have a private authoritative name server that acts as my master name
server.  Outside of my network, I have 3 authoritative name servers
which are slaved off my master.  Additionally, I have slave
configurations with Hurricane Electric pointing their servers at one of
my public slaves (they can't reach my private master) pulling my zone
information from them and, in turn, providing me with an additional 5
dispersed authoritative name servers in their constellation.

NONE of my authoritative name servers allow outside recursion, PERIOD!
The BIND global directive "allow-recursion" is set to an acl that
amounts to local host only.

Separately, I have internal resolvers (also BIND) on my local networks
(including my network colocated at an ISP) that are only accessible from
their local networks.  I have a couple of them on each network.  I also
use machine local dnsmasq instantiations where I need fine grained
control to manage internal (as in behind VPN) resolutions where the
external public view for some external domains I access does not include
the resource records from the internal view.

In your case, I would say, yes, 4, just not broken down the way you have
it.  I would make it 1 internal private master, 2 external public
authoritative slaves that can talk to your master, and 1 internal
caching, recursive, resolver.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20120509/2da049d9/attachment.bin