I recently received an email asking about DNS server placement.  In part the email reads, “why whould a computer from the internet need to reach a “public” DNS server inside a private DMZ as if it were a web server? Are there occasions when a machine would need to reach accross the internet and resolve a private IP address? It seems backwards and highly unsecure, especially where there is no VPN.”

Questions in this vein are not too uncommon and over the years I have encountered a good number of people confused about where a DNS server should be placed and why.  The answer is not simple because there are many correct ones.  A lot depends on the layout of your network and your organization’s naming scheme.  To give a frame of reference for discussing this let’s consider three different general network layouts.  For each network I briefly review traffic flow typically allowed by the firewall.  This is important when trying to understand where a DNS server should be and why.  The networks are:

Network 1: Single Firewall With NO DMZ/Screened Subnet

Network 1 is the simplest scenario and more likely to be seen in a home network or a very small business.  The firewall allows internal nodes to establish connections to the Internet and there may be a limited ability for nodes on the Internet to make incoming connections to certain hosts on the internal LAN (but not by default).

Network 2:  Single Firewall With a Screened Subnet.

In Network 2 there is a single firewall with at least three interfaces.  One interface connects to the Internet, one to the ‘DMZ’ and the other to the internal network.  The servers in the DMZ are referred to as “public” because they are intentionally available to the Internet.  With appropriate rules configured traffic will be able to flow (in a limited fashion, of course) from the Internet to the DMZ but not from the Internet to the internal network.  The internal network can initiate outbound connections to the Internet as well as to the DMZ.  The DMZ may have limited ability to make connections in to certain nodes on the internal LAN.

One of the most important things going on with Network 2 is that hosts on the Internet cannot send uninitiated traffic into the internal LAN.  The DMZ area, commonly called a ’screened subnet’ in this single-firewall setup is protected by the firewall but the firewall does allow administrator configured rules that permit hosts on the Internet to send traffic into the DMZ.  This ability to be ‘touched’ by nodes on the Internet makes this DMZ network segment less trusted than the internal segment (which cannot be reached directly from the Internet).

Network 3: Dual-Firewalls with DMZ LAN segment In-Between

In Network 3 there are two firewalls.  The outer firewall (the one touching the Internet) is the first line of defense and controls the flow of traffic form the Internet into the DMZ as well as the flow of traffic from the internal LAN and the DMZ out to the Internet.  The inner firewall controls the flow of traffic from the DMZ into the internal LAN and it also controls the flow of traffic coming from the internal LAN going to the DMZ and the Internet.  In general, the DMZ nodes may have some limited ability to initiate connections to internal LAN hosts but the Internet will have zero ability to initiate inbound connections to the internal LAN.  This is a more aggressive security posture, offering multiple layers of firewall defense.  It is also slightly more complex in its configuration.

So where should your DNS servers be?  Let’s examine that a bit.

First we need to define the basic intent of DNS.  We know DNS resolves host names to IP addresses (and vice versa if configured) but we can separate that into two different areas:  internal host names and external (public) host names.  Internal nodes need to be able to resolve both internal and external host names.  For example, while at work I need to be able to resolve sql6.itdojo.com (an internal node) to an IP address just as much as I need to be able to resolve www.starwars.com (an external node).  The same may not be true for nodes on the Internet.  Should a node on the Internet be able to resolve sql6.itdojo.com to an IP address?  If yes, you need a DNS server that is reachable to the Internet node.  If you only have a single internal DNS server (like in Network 1) you will need to expose that internal server to the Internet for incoming queries.  This means that anybody on the Internet can resolve any internal host name.  That is generally considered a bad idea.  Rather than exposing your internal DNS server you may opt for Network 2 or Network 3, which have different DNS servers in the DMZ/screened subnet area that are reachable from the Internet while the internal private DNS server is not.  This is a step in the right direction from a security perspective because it prevents Internet nodes from resolving the names of internal hosts (which reside only on the internal DNS).  The only names that can be resolved by nodes on the Internet are the ones you place in the zone file on the DMZ-located DNS server.  This typically only includes the names of the servers in the DMZ/screened subnet.  The challenge with this scenario is in your DNS naming convention.  If both the private DNS server and the DMZ DNS server host the zone file for the same domain (itdojo.com in this example) you will have to duplicate entries on each server (and they may be different addresses if your firewall is NAT-ing between the private LAN and the DMZ/Internet) because primary-zone-file-holding DNS servers won’t forward to a query to another DNS server with the same name (e.g., the server is authoritative for the name space and will not forward requests to another server to resolve its own primary zone queries).  This increases the complexity of administration (but is not the end of the world).

An alternate solution would be to use a completely different name for the internal name space.  If your Internet presence is itdojo.com, consider using a child domain of that name space internally (or a different name altogether); corp.itdojo.com or itdojo.net, for example.  This allows your internal nodes to query for sql6.corp.itdojo.com and get internal resolution while queries for ftp.itdojo.com and still be forwarded to the DMZ-located DNS server.  On the flip-side, an attacker on the Internet can query the DMZ DNS server all day long and only resolve the nodes that have been manually entered by the administrator but will not be able to get queries directly to (or forwarded to) the internal corp.itdojo.com DNS server.  This helps protect against attackers building a list of available nodes in your environment.  And since so many shops have the bad habit of naming their servers after they function they provide this is an important consideration.

The placement of DNS servers is further complicated if you use Active Directory.  Active Directory-Integrated DNS zones are contained in the Active Directory database, not in a separate file or database.  This means that the DNS server will also need to be a domain controller.  Placing a domain controller in the DMZ is punishable by death in most organizations so AD-integrated solutions will have to be exclusively internal.  You are essentially compelled to use an internal DNS/external DNS scheme.  Whether you use different namespaces (itdojo.com vs. itdojo.net) is up to you.  I’ve met people who feel strongly about both ways of doing it.

The simple truth of all this discussion is this:  Hosts on the Internet should never be able to resolve the names of resources on the internal LAN that you have no intentions of ever sharing with the Internet.  It’s not keys-to-the-castle information but it’s a big help to a would-be attacker.  This means it is all but impossible to have Network 1 and expose your internal DNS to the Internet.  With no DMZ or screened subnet your only real alternative is to pay a 3rd party to host your DNS for resolution of Internet available resources (www, ftp, smtp, etc.)  The internal DNS server in Network 1 should never be directly reachable from the Internet.  Realistically, the only nodes that should be resolvable by the DMZ DNS server are the services offered in the DMZ (www, ftp, ssh, smtp, dns, pop3, etc.).  Hosts on the internal LAN should be able to resolve all addresses, inside or out (yes, there are exceptions to this).

If anyone has additonal questions on this topic please email me or ask in the comments and I will address them.

Cheers,

Colin Weaver