[sf-lug] pdns-recursor

[Rick Moen]

Quoting Alex Kleider (a_kleider at yahoo.com):

> It's working!
> 
> Adding 
> access-control: 10.0.0.0/8 allow
> to /etc/unbound/unbound.conf
> did the trick.
> Grant was pointing me in that direction but I didn't really appreciate
> what he was trying to tell me until I read Rick's notes on how to
> trouble shoot DNS.
> 
> Thank you very much.

You're very welcome.

> Am I right in my assumption that what's in /etc/resolv.conf on the
> plug (the machine running unbound) becomes irrelevant?

Well, not really.  It's a good question, and the matter actually bears
thinking about.

Brief review of context:  Any TCP/IP machine is (or can be) a DNS
client.  Unix machines have client functionality tucked away inside part
of the system libc (which is GNU glibc in Linux's case).  The
configuration files for that client functionality are -- on most Unix
machines -- /etc/resolv.conf and /etc/nsswitch.conf .  (Don't worry
about the latter if it seems mysterious.  Leave it alone.)

Most people don't think about resolv.conf (let alone nsswitch.conf),
because they either set it once and forget, or leave its contents
entirely up to DHCP.  However, it's worth remembering that _each_ 
machine has a client setup, which affects how _its own_ TCP/IP stack 
works -- and not anything else.  That client setup thus affects only
programs running _on_ the machine in question.

Applying that general truth to host 'plug':  If you tweak the contents
of /etc/resolv.conf on 'plug', you are determining where the DNS queries
go that are generated by programs running _on_ plug that make reference
to hosts elsewhere by hostname -- DNS-using network applications.

You might be surprised to learn that Unbound (like other nameservers)
is _not_ one of those DNS-using network applications.  Unbound doesn't
use DNS client services.  Why?  Because that would create a
chicken-and-egg problem.  So, e.g., unbound.conf's references to
machines elsewhere is by IP address only.

But presumably you have things other than Unbound running on 'plug', or
you might want to, at least, and you want to be able to use DNS services
there.  So, you wonder, should you tell 'plug' to consult 'plug' only
for its DNS?


> Should I change it to a one liner consisting of 
> nameserver localhost
> and delete what was there before, namely:
> search sonic.net
> domain sonic.net
> nameserver 208.201.224.11
> nameserver 208.201.224.33
> ??????

You could.  The argument in favour is 'Hey, I like sonic.net, but my own
recursive nameserver is the last word in really, really close, and I'd 
rather get local nameservice from, y'know, a really local source.'

The argument against is:  'If Unbound is hung or not running, then all
nameservice on plug will be offline.'

You could make a good argument either way.  One fence-straddling option
would be to put '#' marks in front of the two existing lines referencing
sonic.net nameserver IPs.  If Unbound is ever not running, you just
uncomment one or both of those lines, and you instantly will get local
DNS services back.

'Hope that helps.

By the way, you can certainly get away with 'nameserver localhost' in
/etc/resolv.conf, because the static hosts mapping file, /etc/hosts,
includes a stable and reliable definition of what IP the name 'localhost'
should always resolve to (unless you screw up that file, which can 
result in some really puzzling problems, let me tell you).  _However_,
the 'nameserver' lines in /etc/resolv.conf should really point only to 
numerical IP addresses.  Therefore, 'nameserver localhost' is a slightly
irregular way to say it, avoidably making local nameservice dependent on
the /etc/hosts file.  The correct way to say that is 'nameserver 127.0.0.1'.