[Unbound-users] cache/auth architecture question

[Greg A. Woods]

At Tue, 19 May 2009 15:24:02 +0400, Michael Tokarev <mjt at tls.msk.ru> wrote:
Subject: [Unbound-users] cache/auth architecture question
> 
> 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.
> 
>[[....]]
> 
> 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.


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
        #
        local-zone: "localhost." static
        local-data: "localhost. IN SOA localhost. hostmaster.localhost. 1 3600 1200 604800 10800"
        local-data: "localhost. IN NS localhost."
        local-data: "localhost. IN A 127.0.0.1"
        local-data: "localhost. IN AAAA ::1"
        #local-data: "localhost. IN HINFO VIRTUAL UNKNOWN"
        local-data: 'localhost. IN TXT "The default loopback interface"'
        local-data: "loopback-net.localhost. IN A 127.0.0.0"
        #local-data: "loopback-net.localhost. IN HINFO NETWORK NONE"
        local-data: 'loopback-net.localhost. IN TXT "The default IPv4 loppback network"'
        local-data: "loopback-bcast.localhost. IN A 127.255.255.255"
        #local-data: "loopback-bcast.localhost. IN HINFO BROADCAST NONE"
        local-data: 'loopback-bcast.localhost. IN TXT "The default IPv4 loppback network broadcast address"'
        #
        local-data: "0.0.0.127.in-addr.arpa. IN PTR loopback-net.localhost."
        local-data: "0.0.0.127.in-addr.arpa. IN A 255.0.0.0"
        local-data: '0.0.0.127.in-addr.arpa. IN TXT "The loopback interface network and its netmask."'
        local-data: '1.0.0.127.in-addr.arpa. IN TXT "The pointer to _the_ canonical localhost."'
        local-data: "255.255.255.127.in-addr.arpa. IN PTR loopback-bcast.localhost."
        local-data: '255.255.255.127.in-addr.arpa. IN TXT "The loopback network broadcast address."'

        # these RFC 1912 suggested zones do not exist in the default
        # internal settings, but they should!
        #
        local-zone: "0.in-addr.arpa." static
        local-data: "0.in-addr.arpa. IN SOA localhost. hostmaster.localhost. 1 3600 1200 604800 10800"
        local-data: "0.in-addr.arpa. IN NS localhost."
        local-data: '0.in-addr.arpa. IN TXT "To stop bogus queries for net 0, as per RFC 1912"'
        #
        local-zone: "255.in-addr.arpa." static
        local-data: "255.in-addr.arpa. IN SOA localhost. hostmaster.localhost. 1 3600 1200 604800 10800"
        local-data: "255.in-addr.arpa. IN NS localhost."
        local-data: '255.in-addr.arpa. IN TXT "To stop bogus queries for net 255, as per RFC 1912"'

        # turn off the internal defaults for zones we manage externally

        local-zone: "168.192.in-addr.arpa" nodefault

        local-zone: "0.168.192.in-addr.arpa" nodefault

        local-zone: "255.168.192.in-addr.arpa" nodefault


stub-zone:
       name: "example.com"		# replace with your public domain
       stub-addr: AUTH.NS.IP.ADDR	# replace with your public Auth NS

stub-zone:
        name: "office.example.com"	# replace with your private domain
        stub-addr: 192.168.0.254	# replace with your private Auth NS

# ... and so on....

# (note: I always use a proper subdomain for internal private domains)

stub-zone:
        name: "backups.example.com"
        stub-addr: 192.168.0.254

stub-zone:
        name: "168.192.in-addr.arpa"
        stub-addr: 192.168.0.254

stub-zone:
        name: "0.168.192.in-addr.arpa"
        stub-addr: 192.168.0.254

stub-zone:
        name: "255.168.192.in-addr.arpa"
        stub-addr: 192.168.0.254


-- 
						Greg A. Woods
						Planix, Inc.

<woods at planix.com>       +1 416 218-0099        http://www.planix.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20090521/40b5a279/attachment.bin>