[sf-lug] DNS/BIND, etc.

[Michael Paoli]

DNS/BIND, etc.

Yes, ... good information, to which, for those looking for a bit more
detail or some other pedantic little bits :-> , I might add ...

> Date: Thu, 21 Aug 2008 12:03:10 -0700
> From: Rick Moen <rick at linuxmafia.com>
> Subject: Re: [sf-lug] looking for a domain name service provider
> To: sf-lug at linuxmafia.com

> Quoting vincent polite (vpolitewebsiteguy at yahoo.com):
> > Well, I can't claim to be an authority. But since DNS is basically a
> > database relating the domain name to the the IP address, It doesn't
> > seem like it would be to hard to do. I'm not sure how it spreads
> > across the net.

> To further clarify, server-end DNS is of two types:  Either your server
> is publishing DNS data, or it's not (and is merely fetching, providing,
> and caching as necessary DNS data published elsewhere).
... or both :-)

> 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).

> If you own a domain, you'll want to have it be served up by minimum two
> authoritative nameservers operating on fixed IP addresses somewhere in
> the world.  (The RFC-recommended numbers are minimum three, maximum
> seven.)

> 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.  Many folks will
often even be running their own authoritative nameservers ... without
even (particularly) needing to consider it.  E.g. many DNS servers are
in fact authoritative for bits that folks often don't explicitly
consider - such as for localnet (including the 127.x.x.x addresses) ...
  but they're often only authoritative for what's quite local and only
quite locally, in most circumstances.  These are at least some of the
domains that would typically be authoritative quite locally:
0.0.127.in-addr.arpa.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
255.in-addr.arpa.
0.in-addr.arpa.

> On the other hand, _everyone_ has reason to run a recursive (aka
> "recursive-resolver") nameserver on the local LAN or local machine.
> One reason:  Not doing so throws away siginficant bandwidth and
> performance on the traffic overhead and delays resulting from
> unnecessary DNS-query transactions across your upstream link.
> Another reason:  Security.  ISP nameservers tend to have extremely bad
> security (and reliability, and performance).
Yes, running such recursive resolve / caching-only or caching-mostly
nameserver, costs a wee bit of disk space and memory, but saves
considerably on bandwidth and reduces latency.  As for ISPs and the
security of their nameservers, quality/security varies substantially.
Some are good/excellent, others are ... well, ... not.  Using an ISPs
nameserver, however, at least before going to The Internet at large for
DNS (and whether or not one is running one's own nameservers), does
help reduce the load on DNS further upstream from the ISPs nameservers
- and in and of itself, that would generally be a good thing.  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.  On the other hand, if the client's systems are
generally much better maintained/secured and run more properly than the
ISP's nameservers, ... well, then may want to just entirely skip the
ISP's nameservers (or only go to them first for domains the ISP is
itself authoritative on or perhaps just those it's also primary for).

> The smaller your network operation, and the less bandwidth you have to
> waste, the greater your advantage from a local recursive nameserver.
> Yet, these are the exact people whose reaction to my suggestion is
> inevitably "Oh, my computing's too small, simple, and slow to need a
> nameserver.  Besides, it's too difficult to do."
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, and if the client is *very* tight on disk and RAM, nscd might
help with the bandwidth (and some other service caching), at a lower
cost to disk and RAM than BIND or the like.

> 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.

> That's it.  PowerDNS Recursor is now running and will handle recursive
> queries posed to it, and will cache that data, saving bandwidth on
> repeat queries (which happen a great deal).

> You _do_ need to set the local machine to send its queries there.
> A *ix machine's DNS client library is configured via /etc/resolv.conf .
> Edit that file to have this one "nameserver" line and no other
> "nameserver" lines:

> 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.  On the other hand, by not adding such additional lines, one
may be more secure, and more quickly note the absence of a running
nameserver on the host.

> You also need to make sure your DHCP client software (if any) doesn't
> overwrite that namserver line.  There are many ways to do this; the
> least complex is to install the "resolvconf" package.  (Just install it;
> the DHCP client should then do The Right Thing.)
Yes, various bits of software can potentially alter /etc/resolv.conf
when one may - or may not - want that to happen.  PPP software will
also rather commonly do that.  Fortunately most such software can
typically be (re)configured to get the desired preferred behavior.