On 2012-05-21, Geoff Steckel <g...@oat.com> wrote: > On 05/20/2012 10:49 PM, Nick Holland wrote: >> On 05/20/12 17:49, David Diggles wrote: >>> Ok, I am interested in opinions on why one should migrate from BIND to >>> unbound? >> 1) It is unlikely there will be any more updates to BIND9 in OpenBSD >> base install. >> 2) It is even more unlikely that the comedyfest that BIND10 appears to >> be added to OpenBSD base install (*snicker* python?? *snicker*) >> 3) BIND sucks. Degree of suckage has varied from release to release, >> but it has consistently remained a bad idea implemented poorly. >> 4) Unbound& NSD sucks less. >> >> Nick. > My site needs both split horizon and pretty complete authoritative support. > Does anyone have suggestions about BIND replacement(s) for this scenario? > Right now BIND works for me (for some value of "works".) > > One machine serving as: > 1) primary nameserver for multiple domains > 2) secondary nameserver for multiple domains > 3) internal nameserver for domains in (1) with additional records > 4) internal nameserver for internal domains > > If there is a discussion of this in an archive some place I'll look for it. > I didn't see much useful searching for split horizon and unbound. > > thanks! > Geoff Steckel > >
I think this type of setup is the simplest way to handle this with a combination of nsd + unbound: - Local clients point to an IP address running unbound - NS records point to an address running nsd for the authoritative zones - For the authoritative zones, unbound does a normal lookup for the "main" records but has additional local-data lines for the additional records in (3). - Unbound has local-zone / local-data lines which are very straightforward when (4) is a reasonably simple case (e.g. override a few A records, add some others, etc) OR - Unbound has stub-zone lines if (4) requires a full authoritative server (DNSSEC etc) IIRC, if you are providing reverse DNS for RFC1918 zones you need to override the default static zones in unbound. If you require that the internal domains cannot be resolved from external addresses (e.g. if someone points directly at the authoritative server and knows the domain name), at the moment you would need a separate copy of nsd bound to a different address/port and firewall it off or bind to a local-only address. I wonder though, there is already of course a per-zone acl setting for zone transfers, so perhaps it might not be considered too much feature-creep to add a per-zone query ACL to NSD... Of course continuing to use BIND is another option.
