Domain Controllers as internal DNS servers
Our company environment is growing rapidly and I'm in the process of upgrading our Domain Controllers, but before I do I wanted to do a quick sanity check to make sure I'm still doing everything the best way possible.
Focusing on my primary HQ site, I have 3 domain controllers (2 virtual, 1 physical) all running Windows Server 2008 R2. I wish to migrate to Windows Server 2012 R2. I don't believe in 'upgrading' Windows, I always prefer 'migration' to keep the servers/environments clean of upgrade artifacts.
The two virtual DCs provide all DNS services for all of my workstations and member servers. Workstations get the DNS addresses through DHCP options while all member servers have the DNS server IPs configured static.
Question: Is it still normal to use your domain controllers as the DNS resolvers for all of your workstations and servers, or should I create new dedicated DNS servers?
Question: Is it good practice to use the real IPs of the domain controllers on workstations and servers for DNS resolvers or should I use virtual IPs/load balancing?
Solution 1:
Is it still normal to use your domain controllers as the DNS resolvers for all of your workstations and servers, or should I create new dedicated DNS servers?
I have 2000+ clients in my company and 4 domain controllers. 2 of them are also acting as DNS Server with no issue for 4 years now.
Is it good practice to use the real IPs of the domain controllers on workstations and servers for DNS resolvers or should I use virtual IPs/load balancing?
Once again, for 2000+ clients i use real DNS resolver IP with no issues.
I provide these metrics as a kind of "reference". Depending on your number of clients, DNS load could be higher and my topology could not applies to you...But IMHO you can go safely with DC+DNS
As stated by Microsoft :
Most often, you will install DNS servers on all domain controllers
But i let you read the full article here
Solution 2:
Using your DCs as DNS servers is quite reasonable. Also, you can't really hide them since so many things require direct communication with them.
The only reason you wouldn't want to use them as your DNS servers is if the load of DNS is too high and lots of queries are for the same names, at which point you'd want to use an intermediate resolver that caches things, or if you want to do fancy things with DNS that would be better served by something like BIND. If you need to change later, you can always change your DNS options, and if you have more than two domain controllers you can also vary the DNS servers on each of your subnets to help balance load.
The security risk of using DCs like this is pretty much zero.
Solution 3:
As a datapoint, I work for a Fortune 200 in the Financial Services industry, and for about a year, served as the DNS Hostmaster for the enterprise. We used to use the built-in Microsoft DNS solution (and F5 LTM for IP anycasting the resolver address and the nameserver in the SOA), which works, but which we decided was non-optimal for our purposes.
Points in its favor
- Free as part of Active Directory
- Works well enough for basic use
- Automatic enrollment of DNS records for DHCP clients (if the clients were Windows clients ; Mac, Linux and SunOS, not so much)
Reasons we needed more
- In an effort to be permissive, it does not strictly follow the spec, allowing in incorrect or even impossible information (including CNAME at zone-apex, for which there was an unapproved proposed RFC, but much, much worse, records with whitespace in either the record-name or the response-value, which confuses the hell out of anything BIND-based)
- The mechanism to keep associated A,TXT,SRV,PTR records synchronized was not sufficient, and we spent substantial time manually reconcilling
- The integrated DHCP daemon required split-scopes for HA, meaning in a fault-condition, half the vailable pool is lost, rather than the standards-track (and used in ISC-based solutions) DHCP failover (https://kb.isc.org/article/AA-00502/0/A-Basic-Guide-to-Configuring-DHCP-Failover.html)
- There was not an out-of-the-box mechanism to easily visualize IP exhaustion/availability/density based on the PTR records
We wound up implementing a top-tier integrated DHCP+DNS+IPAM solution and haven't looked back (including having it perform dynamic zone synchronization and IP Anycast).
There is, of course, a caveat: for SRV record registration to work for Active Directory Service Discovery and for Windows Cluster Server record registration and deregistration to work. you must create an ACL that contains all the domain controllers and MS Cluster Server boxes, and allow them to perform dynamic DNS updates. To insure data integrity and sanity, for all other hosts and all other records, you should only allow them to update via the DHCP daemon or via the GUI/API (in other words, disallow dynamic DNS updates and AXFR for all non-whitelisted boxes).