DNS and DHCP - On the Server or The Firewall?
A few years ago, one of the major "truths" about our business changed. It had long been the wisdom that DHCP and DNS should be served from the Windows Server, specifically from the (primary) domain controller. The primary reason for this is that we ("we" being Windows engineers) find it very convenient to manage DHCP from the same place where we manage DNS. But DHCP does not have to be served from the same place as DNS.
Because they're inter-connected, we're going to talk about routers/firewalls, DNS, and DHCP. We'll cover the first two fairly quickly because they are not really up for debate. DHCP is another topic.
Routers and Firewalls
In many documents, Microsoft simply refers to "the router" to describe whatever device you point to to move data off the local area network. Strictly speaking this is a gateway. And for 95% of all the networks we work with, that gateway is a firewall. See the diagram.
There are basically three kinds of firewalls you'll come across: 1) Old, junkie firewalls that are not very configurable; 2) Super powerful firewalls that can absolutely do whatever you want; and 3) Plug and Play firewalls that can be configured by automated scripts to do what you need them to do.
Most of the arguments in favor of putting DHCP on the server make reference to the first kind of firewall. This has literally become a straw man argument. These firewalls are almost non-existent today. This is particularly true when you consider how little we actually ask the firewall DHCP service to do.
The high-end firewalls can, by definition, do what we need them to do. The only question is whether we choose to use that function.
The third kind of firewall - Universal Plug and Play or UPnP - has evolved only recently. UPnP is defined and promoted by the UPnP Forum, an industry collaboration that seems to help manufacturers develop devices that can discover each other and configure automatically. See http://www.upnp.org/. UPnP has been around for most of a decade. It was published as an international standard in 2008 and has been refined considerably since then.
Most consultants have not really paid attention to the evolution of UPnP. You can review the specifications at http://upnp.org/sdcps-and-certification/standards/sdcps/. You will want to look at the specific notes under Internet Gateway:1 and Internet Gateway:2.
One of the cool things that UPnP can do is to understand DNS and become a DNS forwarder. This includes the DNS portion of active directory. Don't get too far ahead of me here, but imagine if the server could automatically configure the UPnP firewall.
DNS Belongs on The Server
This discussion will be short and to the point: Put DNS on the Server. Now, really, you could make the firewall a backup DNS controller and have it get info from the server. But since you're all on the same network, it makes sense to just go to the server.
DNS is critical for directory services. This is particularly true when the server is hosting a variety of functions, such as a Small Business Server. "//Companyweb" is not an entry you'll find in a lot of DNS servers. But if you don't have it in your in-house DNS server, you'll need to add it to a hosts file on each machine.
Microsoft pretty much requires the following:
1) Primary DNS is on the Server
2) All workstations point to the server for DNS
We like to add the following two items:
3) The server forwards requests to Google Public DNS (188.8.131.52 and 184.108.40.206) and NOT the ISP
4) Local workstations use the Google Public DNS as their secondary
Number 3 is because ISPs are horrible at keeping clients informed when they change DNS addresses. In addition, this setup means you don't have to change anything if you change ISPs or your ISP changes your IP address.
Number 4 increases the probability that workstations will be able to reach the Internet even if the server is unavailable. The only glitch is when the server is half-up, reachable by ICMP, but the DNS service is not responding. This is a very rare occurrence.
DHCP: Server or Firewall?
Without getting into details on some private conversations with people at Microsoft, let me just say that putting DHCP on the server was resulting in many, many calls to tech support. One goal for moving it was simply to create a more stable environment, thus resulting in fewer calls.
A big clue about where the industry standard is going is:
By default, all versions of SBS 2011 and Windows Server Essentials 2012 do not enable the DHCP function on the server.
The official recommendation is that DHCP is on the router (firewall).
In fact, these operating systems automatically configure the router with DHCP.
Since SBS 2008, the server has always been able to set up UPnP routers (firewalls). But since the protocol was very new in 2008, I think there was not much noise about it. See http://blogs.technet.com/b/sbs/archive/2011/09/22/running-dhcp-server-on-sbs-2011-essentials-with-a-static-ip.aspx. And see http://social.technet.microsoft.com/wiki/contents/articles/923.aspx.
Many firewalls also serve up wireless access, and that subnet needs to have it's own DHCP. Putting both DHCP scopes on the same device (the firewall) allows that device to manage traffic between the wired and wireless subnets very efficiently.
If you have a plug and play firewall, these Windows Servers will configure the firewall to turn on DHCP, set up the appropriate IP range, and exclude the server's static IP. Note that DHCP will be set up with Dynamic DNS enabled. So both the firewall and the server will exchange information about the devices on the network.
On a Standard SBS Server, you have many options that need to be configured. Depending on which options you enable, the UPnP configuration will open only the necessary ports, including
SMTP - TCP 25
HTTP - TCP 80
HTTPS - TCP 443
SharePoint via RWW - TCP 987
VPN - TCP 1723
RDP - TCP 3389
AND it will forward each of these ports to the Windows Server. So the ports are not just fully open, but can only be used to access the server.
After the server is finished configuring the firewall with UPnP, the Windows Console collects and displays information about your firewall so you can verify it. To see this information, simply view the Internet connection properties.
NOTE: Even if your firewall does not have UPnP enabled, I believe you should put DHCP on the firewall. I only mention the UPnP information to make the point that this is the emerging default. So people with lots of money to spend on research think it's a good idea. :-)
What About VPN?
When I present this information in public, I'm always asked about VPN. Don't you have to enable DHCP on the server in order to use the server for RRAS or VPN?
The VPN service (RRAS) hands out IP addresses to anyone who dials in. If you know what you're doing, and have a reason, you can also hard code IP addresses for machines that dial in. But basically, the VPN service has it's own little DHCP-like service that hands out addresses and a few scope options (DNS, gateway) to the machine calling in.
If you are suspicious about this, enable the RRAS role but not the DHCP role. You will still be able to connect. In fact, I'll be you have some machines out there that are already configured that way and you just didn't know it.
Advantages of DHCP on the Server?
The primary advantage I hear about having DHCP on the server is that we find it very convenient to manage DHCP from the same place where we manage DNS. (See the first paragraph above.) Okay, that's fine. But think about it. You normally configure DHCP once and never again.
You might make a little change here or there if you migrate a Primary Domain Controller. But having DHCP on the firewall makes that migration a lot easier. As you muck around with DNS settings between the old and new servers, have both servers up at once, and reboot the old and new servers for various reasons, DHCP will simply hum along on the firewall - and no one in the office will know the difference.
Technically, configuring both DHCP and DNS on the same machine might be a bit easier. But since you have to open a new screen for configuring the DHCP role or a new screen for configuring the firewall, it's all the same to me.
I believe DHCP is more stable on the firewall and make the network more stable. The server is infinitely more likely to be rebooted than the firewall.
Implementing this policy is really just a matter of making everyone on the support team aware. You might write up a brief memo that says "It is our policy to serve DHCP from the firewall unless there is a specific reason to do otherwise." And then give a brief description of the preferred configuration, similar to what I posted above.
I would really like to hear alternatives to this policy. This is a topic that is very entrenched in our assumptions about networks. It's not a "religious" debate like HP vs. Dell, but really just a different view of how IP addressing will be served up going forward.
- - - - -
About this Series
SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.
Find out more about the series, and view the complete "table of contents" for SOP Friday at SmallBizThoughts.com.
- - - - -
Next week's topic: Labeling Equipment
by Erick Simpson
Deliverables - Pricing and Positioning - Staffing Requirements
Hiring, Managing and Training - Technical Roles and Responsibilities
Processes and Procedures - Target Markets - Customer satisfaction and Loyalty
. . . and More!