4

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?

Improve this question

3 Answers 3

Reset to default
5

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

Improve this answer
4
  • I assume when you upgrade/migrate the domain controllers then you decommission one, provision the new server with the decommissioned servers IP address, and repeat?
    – Christoph Berthoud
    Jul 21, 2014 at 0:52
  • This is quite right...but this was not in your initial question and i think it should be a full other thread...
    – krisFR
    Jul 21, 2014 at 0:55
  • Not thread, but question.
    – Falcon Momot
    Jul 21, 2014 at 20:53
  • @Falcon Momot Yeah right, but is this comment useful ?
    – krisFR
    Jul 21, 2014 at 21:14
4

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.

Improve this answer
1
  • 2
    In fact, it enhances security, since by default, installing DNS with AD DS creates AD Integrated DNS zones, which stores the Zone information in Active Directory, and permits transfers of Zone data only between other ADI DNS servers, reducing the risk of man in the middle attacks on DNS.
    – Davidw
    Jul 21, 2014 at 0:48
1

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).

Improve this answer
4
  • Par5t of that was using outdated tech. I use integrated DHCP and have HA with no split sope thanks to replication that is available in CURRENT versions of Windows Server. IP address Management is standard sind 2012. That kills 2 of your 4 points as "using outdated technology".
    – TomTom
    Jul 27, 2014 at 14:46
  • I am thrilled to hear that these features were added in later versions of AD, since AD as a whole is a fantastic tool-set (I especially like how it makes Kerberos and DNS, both of which can be scary, accessible to everyone). When I was DNS hostmaster, we were transitioning from Windows 2003R2 to Windows 2008. It sounds like the state of technology has moved a lot since then.
    – DTK
    Jul 27, 2014 at 15:13
  • And I don't see where I referred to "using outdated technology". Maybe the Serverfault gremlins ate that sentence, and also wiped from my memory. At the time, there were not the features we needed in the GA versions of Windows. It sounds like there are now, for which I am glad (since replatforming DNS+DHCP is a huge effort and pretty scary for stakeholders, since a mistake in DNS can cause a bigger outage than virtually anything else, including bricking one of the backbone routers).
    – DTK
    Jul 27, 2014 at 15:20
  • It has - this basically is a 2012 generation technology. It has moved a serious lot and is quite usable now. Especially DHCP was a seriously - ah - "limiting setup". Could still be better (DHCP reservations and leases in AD) but at least it does 2 node replication now.
    – TomTom
    Jul 27, 2014 at 15:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .