Cache/auth architecture question

Unbound
1

Hello.

I'm trying to convert existing BIND infrastructure to
nsd/unbound pair, and am facing some.. difficulties
with rudimentary auth-zone support in unbound and
complete lack of replication in it.

Here's why.

While unbound is used for simple cases like single
home machine (definitely recursive-only, no local
data at all), or for large caches facing clients
of an ISP (where local data is irrelevant), it all
works very well.

But I've a situation where I've a mixed case --
recursive behaviour and local data.

Our company has several divisions which are located
at different places. Each has its own subdomain for
local access, reverse zones and so on. They're
replicated to/from central servers as appropriate.

This replication works quite well between NSD servers,
as it were before with BIND. Each server knows a set
of other servers and a set of zones it has locally and
pulls from other places.

Note the data in question is purely local zones, used
internally only, like name of local mail server or
database server and so on.

Now I'm moving on to the recursive nameservers setup.
And it looks like I have to pair each NSD that stores
local data with unbound which is configured to query
local NSD for every zone that NSD knows about. I.e,
100% duplicate configuration -- repeating in unbound
the same as already configured in NSD.

I tried keeping that stuff as local-data statements
in unbound config files, but since it has to be
replicated into several places (as more than one
place acceses the same server), lack of replication
mechanism does not help here to keep them in-sync.
Also lack of CNAME support in unbound is not good
for that, since many names pointing to other
division's servers are CNAMEs to their zones.

So I tried NSD+unbound pair instead, and now am
facing almost the same 'keep 'em in-sync' thing
(but now it's less pressing) -- have to configure
list of "local" zones in two places on each node.
And the whole config becomes... clumsy.

Note that in this case, NSD does very very little
(the "amount" of RRs it manages), but it does
replication.

What's the best way to achieve somethig like that
using the "split brain" such as nsd/unbound?

The goal is to have as independent nodes as possible,
so that each can work in case of various network
failures, at least locally. Plus redundancy.

Maybe some other "mass-replicating" tools like
cfengine..

What I liked about BIND and NSD replication is --
no matter if the network is up or down, if any
remote node is reachable or not at the moment,
the replication will happen when they'll be able
to talk with each other (And having dead link
isn't that uncommon. And even if it IS uncommon,
when it actually fails it's very unfortunate to
sit here and wait when it becomes working again,
instead of letting the computers to do their work).

Thanks!

/mjt

2

Indeed I think it's best to totally avoid use of the local-zone and
local-data support in unbound except for the few necessary static and
invariant zones that should always be there.

Instead, just as is suggested in the unbound.conf(5) manual page, I set
up private authoritative NSD servers to manage all that data, and I
point my unbound servers at them using stub-zone settings. NSD already
supports replication for zone data -- let it do that job! I think once
you get out of your head the mistaken idea that you can use unbound to
serve any kind of useful authoritative data, and instead see it only
ever as a cache server, then it might become easier to envision how to
use nsd and unbound together for more complex corporate infrastructures.

See also the related answer in this message as further confirmation:

  http://www.unbound.net/pipermail/unbound-users/2009-March/index.html

The parts I've had trouble with when upgrading from BIND for similar
uses are: (a) lack of ACLs per zone to ensure private data stays private
where "private" may have more than one level/meaning; and (b) longing
for something like NOTIFY support in unbound for something like
automated dynamic cache flush control (when using BIND I made every
caching server a secondary for every local and private domain both so
that it hopefully couldn't get corrupted by bogus responses and also so
that dynamic NOTIFY messages would cause zone transfers and updates on a
more timely basis). (unless of course unbound could be told to never
cache any data for anything under a stub-zone domain -- I'm still not
100% sure of whether it does or does not cache RRs from stub-zone
domains and/or sub-domains, but my tests suggest it does even without
setting stub-prime: on) With properly working NOTIFY support in BIND-8
I got very used to more dynamic control over local zones while still
having sane TTLs.

As for keeping the configuration files for nsd and unbound up-to-date,
well it's no different than any other setup with several layers and
mirrors, even with BIND. I.e. it's outside the scope of what the server
does itself -- the server doesn't maintain it's own configuration.
Perhaps as you suggest something like cfengine would help here. For DNS
servers I've usually resorted to custom awk and/or python scripts and
rsh/ssh to build and push config hunks that are included into the main
config file on each nameserver host. Perhaps in your case a simple awk
script could take a canonical list of local zones and server IPs and
generate config file one include hunk for nsd and one for unbound.

FYI, as an aside on a somewhat related matter, here are the
local-zone/local-data settings I use, followed by some example stub-zone
settings. In theory these more complete default local-zone records
should all be built in as the default (instead of the current incomplete
defaults) and only the appropriate "nodefault" settings would be
necessary for the private zones which are used in your local
infrastructure.

server:

        # ... (the rest of your config, of course)

        # "local-zone:" should be a top-level itme, not a sub-clause of
        # "server:"!

        # this is a more correct and complete expression of the default
        # internal "localhost." zone