Friday, November 16, 2012

SOP Friday: DNS and DHCP Allocation - Server vs. Firewall

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 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 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 ( and 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 And see

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

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.

Comments welcome.

- - - - -

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

- - - - -

Next week's topic: Labeling Equipment


Check Out the #1 Best-Selling book on Managed Services ever!

Managed Services in A Month
by Karl W. Palachuk

3nd Edition - Newly Revised and Updated with TEN new chapters

Paperback - Ebook - Audio Book

Unlike some books with old copyrights that sell for $60 or more, this book is 100% up to date and is only $29.95.

Now includes information on making cloud services part of your managed service offering!

Learn More!



  1. Anonymous6:33 AM


    I do have one thought on this. Sonicwall firewalls have a few limitations in their implementation of DHCP that makes it much less robust than its windows counterpart.

    1. Hostnames don't show up in the DHCP server on a SonicWALL firewall. Now, this is only a minor inconvenience, but I've never understood why they do it that way. If I plug a new device in, I need to know its MAC address to be able to find it on a SW firewall. The DHCP mmc snap-in shows me all of the information.

    2. Reservations are much more difficult on a SonicWALL. Particularly, you need to put a reservation outside of the DHCP scope. Now, this is best practice, so I do understand where they are coming from, but sometimes it is a huge hassle to change a device's IP when you determine that it needs to become static. On Windows, you can put a reservation anywhere you like.

  2. Thanks for the feedback, Anon.

    In a small business environment, I'm not sure there's a need for reservations. We put servers in one range (hard coded), printers in another (hard coded), other static devices in another, and then have a DHCP scope. In that way, nothing can conflict.

    When you get a SonicWall with UPnP, it won't matter how annoying it is to configure manually because you won't need to!

  3. Good post, Karl, as always.

    There´s on thing coming to my mind here: UPNP can be a "security hole" if you let it be acivated.

    I think, we have to add "deacivate UPNP after configuring your router" to your policy.


  4. Rolf:

    As with any technology, you need to be careful not to create or allow an insecure setup. As far as I know, all UPnP-capable devices have UPnP turned off by default. I don't know that for a fact, but I believe that might be part of the specification.

    At any rate, you should turn off UPnP when you're finished using it.

    The biggest concern with UPnP is that it does not require authentication by default. So if you can reach it on the LAN, and UPnP is enabled, then you can configure it. That's why you should just turn it off when not in use.

    Note also that configuration from the WAN port is turned off by default.

    You can implement the DSS - Device Security Service - on most devices. And there are a few bolt-on products you can implement if you want to do a little coding. I have no personal experience with this since turning off the UPnP protocol is easy.

    The latest security information and recommendations for the UPnP protocol were published in 2011. Go to and download the first PDF document.


    1. Thank you, Karl, for that input.

      I will read it that weekend :=)

  5. Interesting article, but for our clients Sonicwall-like firewall is a bit too much. We use Drayteks and Zyxels as ADSL modems and routers/firewalls and always put DHCP on the server. Main reason for that is that Windows DHCP is more flexible and in fact allows what mentioned routers doesn't, eg. reservations or configuring own DNS servers for workstations. I know that this article is about another grade of clients/networks, but I wanted to add my 2p.

  6. Thanks Carl, it was always about convenience but I am keen to make the network, and especially the Internet, more reliable if the server is down. Will test this out, although it doesn't look like Cyberoam (our current firewall of choice) support dynamic updates of DNS which will probably be an issue.

    In regards to the secondary DNS settings on the workstation, I have seen problems with doing this kind of setup (so that Internet is available when the server, and therefore DNS, is down). I have seen workstatons trying to use the secondary DNS servers to resolve local system names which of course times out. Perhaps there is a trick to avoid this?

    Finally what about features like NAP and how does IPv6 factor in to this?

  7. Thanks Karl, interesting article. Will try this out this week but Cyberoam do not seem to cater for Dynamic DNS and that will be a problem I suspect.

    With regard to adding external DNS services as the secondary DNS (I would rather point secondary DNS to the router and configure the router to use the DNS that makes sense for it's particular connection hwoever). I have seen it where when you do this the workstation can randomly try the secondary DNS to find local servers and of course fail. Is there a trick to avoid this happening?

    Finally what about NAP? Or does no one actually use it? And how does IVv6 fit in to this scenario?

  8. Thanks, Jakub. I gotta say: I don't know of any router (or other device) that serves up DHCP and does have the ability to assign DNS servers. It's a core function.

    Thanks for the 2p!

  9. Mark:

    We never use the ISP's DNS servers, which is often the preferred DNS for routers, because many ISPs change DNS servers, rotate them in and out of service, and have routing issues between their round-robin DNS servers. All of these things require that a request time out and then be sent up-stream. Each attempt causes a delay in name translation.

    By NAP do you mean the old Network Access Point for sharing resources between ISPs? That never really took off.

    As for IPv6, I would say it is not yet widely enough adopted to worry about. I keep waiting for it to take off, but the work-arounds for IPv4 have held out ten years longer than expected!

    1. IPv6 is required for SBS and is being used more and more from my experience, could be an issue?

      Have not experienced too many problems with ISP DNS here, but it can happen so fair point.

      What I was mainly referring to is that if you set the workstation to have the external DNS service like Google as a secondary DNS server, then it can end up being stuck on that DNS server and stop working for internal lookups. What I think happens is that if it timesout contacting your primary server and starts using the secondary DNS server, it will stick with that until that one times out (the server not the lookup). This can leave you with workstations that cannot resolve internal addresses.

      I have had this happend whenever we have tried to implement this as a way to allow Internet access when the server is down. Now we just change the DNS if and when it is needed. Would love to hear how you work around this issue.

      NAP in the context of DHCP stands for Network Access Protection and is a feature in Windows Server 2008 that controls access to network resources based on a client computer’s identity and compliance with corporate governance policy. Probably not used widely in SMB land. I know I have only seen it implemented at larger sites.

      How many firewalls will dynamically update Windows DNS from DHCP? I know Cyberoam don't.

  10. I'd say IPv6 is turned on more and more. But since most equipment (including desktops) do not have it on, it is present but not really functional.

    So we've had the ISP issues, but we've never experienced the workstation issue you mention. The workstations should always check the primary server first and the secondary second. I don't know of any mechanism that would "set" them to look at the secondary and stay there.

    I'm not sure what your last question means.

    Thanks for the comments!

  11. Hi Karl, I spoke with a few peers who agreed and had seen problems, I would have to do some more testing but I know first hand things broke when we used external DNS for secondary on the workstations. I have also had word that using Google as your DNS can cause CDN issues, here in Australia it seems our ISP DNS is a lot more stable than in the US perhaps?

    IPv6 is on by default on every Windows 7 PC we work with and I see plenty of IPv6 traffic on LANs, especially with SBS involved.

    My last point is that there are still devices that do not update DNS when they acquire a dynamic IP, so DHCP on Windows server will take care of it. Not sure many firewalls support that or if it is a big issue?

    As always love your content and appreciate the article, has got a few of us thinking.

  12. Our ISPs are pretty good 99% of the time. But when they're not, they don't admit it.

  13. I can confirm that we see problem with secondary external DNS on workstations. I would say that having secondary domain controller and DNS is the only sure solution. Of course not on the same box :)

  14. Secondary DNS in-house is impractical for really small businesses. A UPnP router/firewall should be able to act like a secondary, but I believe you'd have to leave UPnP enabled for it to get dynamic updates from the server. No recommended.

    Question: Does this DNS snag on workstations go away with a reboot?

    I wonder if it's related to having a long lease time on the DHCP, so once secondary is engaged, it doesn't revert back until the DHCP lease is renewed?

    Anyway, thanks for the input.

  15. Yes, this is probably the case.

  16. I cannot disagree more with the notion that workstations on a domain should have any external DNS address, even as a secondary DNS. It causes far more grief than the tiny benefit that it may generate. If the local DNS is broken and does anything else other than DNS, it will need to be fixed immediately-- the amount of time bought by the secondary DNS will be very minimal. I have fixed several networks lost by other consultants simply by removing all ISP DNS entries from workstations. As others have explained, it doesn't take much for the workstation to get stuck on one of the secondaries for no apparent reason. Using ISP DNS entries even as secondaries is very, very bad practice, and I was frankly shocked when I heard Karl recommending this at SMB Nation. If you have a reliable, stable local DNS, ISP or Google secondaries are not necessary.

  17. Well, my experience is obviously not universal.

    This intrigues me because we've never seen it.

    Since the only goal for adding a second DNS is to access the internet when the server's unavailable, leaving it blank should be fine on a small network, as long as the server is stable.

    If anyone has Microsoft Technet articles or other info on this, I would love the links. I'd like to see if I can create this situation or figure out how it happens. Theoretically, it should never happen. But, theoretically, nothing should ever go wrong with a network! :-)

  18. Anonymous6:24 PM


    The secondary DNS is always attempted as result of the primary timing out. The issue that has been seen around when you add google dns as secondary is when your local DNS server is timing out. Then of course a big role plays local DNS client cache which does not expire very soon. So if you pinged local machine and got "could not find host" then tried again you will get the same result for a while unless "ipconfig /flushdns".

    Advice: I would never implement external DNS server on a client machine that is part of windows domain network - headaches are to follow.

    Cheers guys,
    Enjoyed reading!

    Aleksandar Klisarski

  19. How should I handle the following situation?
    1. Main office, plus a dozen branch offices; some branch offices have Domain controllers, but most do not.
    2. MPLS connecting all branch offices to Main Office; each branch office also has ISP connection for Internet
    3. Sonicwall handles DHCP for those branches without a DC.
    4. I cannot resolve (from Main Office) hostnames for PCs at branch locations that use Sonicwalls for DHCP
    5. Yes, the branch office sonicwalls point to the main office DC for DNS

  20. That's a big question, but the answer is fairly simple. You need to make sure that each office is using a different subnet (e.g., 192.168.1.x, 192.168.2.x, 192.168.3.x). Then you need to set up routes so that the SonicWalls know how to get to those networks (if they really do).

    SonicWall gurus might chime in with advice for bridges or VPNs. Not sure that's necessary.


Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!