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://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20090521/40b5a279/attachment.pgp>