On Fri, May 25, 2012 at 2:37 PM, Geoff Steckel <[email protected]> wrote: > Thanks very much! I think using NSD for the "outward facing" authoritative > service makes sense. Retaining BIND is probably best for the internal > service > since I see no way to add the local domains, etc. to unbound/nsd while > retaining recursive search of external servers. It may be possible. > I just can't see how to do it without truly complex setup.
At least in the simple cases I use it's pretty straightforward. NSD is pure authoritative. Unbound is resolver/cache plus it can serve up "local data", that is data that we configure it serve up, it does not retrieve it from elsewhere. The local data has some limitations (I don't believe it serves up all record types for one) but it can be sufficient in many cases. If one needs more complicated authoritative data, with referrals, wildcards, CNAME/DNAME support, or DNSSEC authoritative service then use a stub-zone. You can run NSD for the outside world, and Unbound can serve up the local data or you can run another copy of NSD for your inside data if your needs are greater than Unbound's local data (I don't serve authoritative data to the outside world so I only use one copy of NSD - could probably get away with Unbound only these days as its local data serving has really improved). Quick overview: Unbound serves local data directly: ====================================== local-data: "host10.myinternal.com. A 192.168.1.10" local-data: "host11.myinternal.com. A 192.168.1.11" ====================================== Unbound gets data from NSD: ====================================== private-domain: "myinternal.com" (above necessary if you want to serve up RFC1918 address from the stub zone) stub-zone: name: "myinternal.com" stub-addr: 127.0.0.1 (here NSD is running on localhost) OR stub-addr: 192.168.1.1@5353 (here NSD is on alt port) ====================================== Unbound forward requests to another cache for a specific domain: ====================================== forward-zone: name: "zapster.example" forward-addr: 172.34.78.1 ====================================== Breifly (and a bit too simplistically) anything not in local-zone, local-data, stub-zone or forward-zone will get resolved via root servers. If you use a DNS service such as OpenDNS, Google Public DNS, etc. you can forward all queries not previously defined by: ====================================== forward-zone: name: "." forward-addr: 8.8.8.8 forward-addr: 8.8.4.4 ====================================== Let's say you appreciate the domain blocking that something like OpenDNS provides but you don't like the way it hijacks some domains, such as google.com. Order your forward zones like so: ====================================== forward-zone: name: "google.com" forward-addr: 8.8.8.8 forward-addr: 8.8.4.4 forward-zone: name: "." forward-addr: 208.67.222.222 forward-addr: 208.67.220.220 ====================================== Using local-zone you can easily block domains as well: ====================================== local-zone: "facebook.com." refuse local-zone: "fb.me." refuse ====================================== One way to keep facebook from tracking you :) Use it to stop the isatap and wpad nonsense: ====================================== local-zone: "isatap.myinternal.com." refuse local-zone: "wpad.myinternal.com." refuse local-zone: "wpad.com." refuse local-zone: "wpad." refuse ====================================== (working in a Windows wonderland) Just trying to give you an idea how flexible it really is. Between local-zones, local-data, stub-zones, forward-zones and resolving you may find it fits in nicely. Chris
