On Tue, Jun 3, 2014 at 1:57 PM, Dave Warren <[email protected]> wrote: > In general, I agree that it makes sense to split authoritative and resolver > roles. However, in the case of Windows and Active Directory, Active > Directory is built under the assumption that your DNS servers accept AD > authenticated dynamic updates, both from AD itself and from clients, so it's > best practice to only specify Microsoft DNS servers for Active Directory > domain controllers, member servers and workstations when possible.
First a caveat - all of my clients and experience (after my big iron days that is) are small businesses. Most are non-AD but a couple of them do have AD domains running on Microsoft servers (no giant Forests, one domain). One is an inherited account and the other needed to run software that required an AD. Not my preference (which is Linux/BSD servers), but they work. So file this under some guys opinion and probably not applicable to your environment. First, unless a box is a server there's no pressing need for it to have DNS entry. Nice, can be helpful, but not absolutely needed in most cases. > My theory is that each site (physical location as well as Active Directory > site/subnet) would have one unbound server that performs internet > resolution, with multiple AD servers that forward to the unbound server. At one site I run the Unbound resolver/cache on an OpenBSD box configured with stub-zones for the AD domain (forward and reverse). All clients are configured to query this Unbound box. The AD server forwards to Unbound anything it is not authoritative for. The important thing this accomplishes (at least in my paranoid mind) is that it removes the AD from direct Internet access for DNS purposes (admittedly I have some trust issues with MS systems and Internet access). With a side benefit that the AD does not supply DNS answers directly to the clients - it's DNS workload is very low, as it is a server with little to no need to resolve outside its authoritative domain (just the occasional update, new software download, etc.). Also, and maybe a bit unexpectedly the clients still update their DNS entries (although as I mentioned earlier I don't find this all that necessary) on the AD as even though their resolvers point to Unbound the SRV records (cached by Unbound for all clients) are what allow them to locate the AD and update. At any rate the performance is quite good, and (if anecdotal "evidence" can be offered) improved (I ran no performance tests). But more importantly I have piece of mind that the AD has very limited Internet exposure. I have also run with all clients pointing to the AD with a forward to the Unbound server (no stub-zone to the AD), which does limit the AD's Internet footprint, but I like the setup using the stub-zone, reducing the DNS workload on the AD and even possibly preventing some DNS nonsense from internal systems. Chris _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
