This blogpost presents some considerations regarding the design and the implementation of a secured Domain Name System (DNS) on an internal network (SME and/or corporate).
The target audience for this post is people with a broad technical ICT-related knowledge in general, and a conceptual knowledge about networking and DNS.
You can find an excellent explanation about DNS and the various DNS roles here. A high level explanation about Active Directory can be found here. Please note that the linked content is under the control of third parties, and therefore, tomsnauwaert.com cannot accept any responsibility for the (availability of the) content presented therein.
The following topics are handled in this post:
The public authoritative DNS server is the final holder of the IP of the FQDN (Fully Qualified Domain Name) of a machine out there on the Internet you are looking for. It is the name server, which has the original zone records. It has been configured from the original source, and it returns answers to queries that have been predetermined by the administrative authority for that specific zone. These DNS servers are giving responses to queries just for the zones they are configured. This makes them very efficient and fast.
In the case of corrupted or altered data on the authoritative DNS servers, your company may become completely inaccessible from the Internet. All communication on the Internet relies on the ability of the authoritative DNS servers to translate (resolve) DNS records (host names, E-mail domains, ...) to IP addresses, because the actual communication on the Internet is performed between IP addresses.
For reasons of independence of domain registries and Internet Service Providers, one can decide to run its own set of public authoritative DNS servers.
It is however important that the best practices beneath are followed when running public authoritative DNS servers:
Figure 1 - Public Authoritative DNS Infrastructure
Figure 1 above shows that our public authoritative DNS servers are made available for queries coming from the Internet using public virtual IP addresses (VIP) that are routed via 2 independent Internet Service Providers. This design decision was made to ensure that the public authoritative DNS service remains available in the case of an interruption in the service of one of the ISPs.
The servers that are responsible for the resolution of the DNS queries coming from the Internet are slave DNS servers, which are hidden behind a redundant Internet Access Street on a DMZ (demilitarised zone) with private space IP addresses. The Firewall component of the Internet Access Street is responsible for the NATting (Network Address Translation) of the VIP addresses to the private space addresses. Only DNS (UDP port 53) and potentially ICMP traffic are allowed towards the slave DNS servers through the Internet Access Street. The Internet Access Street should be application aware, and thus capable of filtering out incorrectly crafted DNS (and ICMP) packets potentially affecting the slave DNS servers.
The authoritative master DNS server holding the original copy of the authoritative zone files is inaccessible from the Internet for security reasons. The DNS replication of the zone files towards the slave DNS servers is performed over the Out of Band (OoB) management network (VLAN).
The operational management of the DNS Servers is also performed using the OoB management Network. The slave DNS servers should be listening on UDP port 53 (DNS) on both the DMZ and the Management interface. The reason is that the slave DNS server needs to be able to receive notifications from the master DNS server in the case of changes to authoritative DNS zones, so that the slave DNS servers can initiate a replication. Potential monitoring and logging traffic should also be performed over the OoB network to ensure that production traffic is not affected.
My preferred platform (cost effective and easy to maintain) to run authoritative DNS servers is a Virtual machine running a minimal footprint (core) of a stable distribution of Linux (e.g. RHEL/CentOS 7 or 8) and a stable version of bind. To ensure an additional layer of security on the authoritative DNS server itself, I make sure that the network adapters are managed by NetworkManager. I also make sure that the network adapters are configured in the correct firewalld zone, and that only the required protocols are allowed towards the respective zones. On top of that I make sure that SELinux is enabled and that the SELinux policies are set to 'enforcing'.
A recursive DNS server receives DNS requests from clients and servers, and possibly other DNS Servers. the recursive DNS Server then performs a lookup of the query on the authoritative servers following the whole DNS hierarchy (root servers, top level domain servers, authoritative servers). When the record that was the subject of the DNS query is found, the recursive DNS servers sends the answer back to the machine initiating the query, and stores the answer in its cache for a predetermined period of time (which is defined in the authoritative zone), to speed up future DNS queries.
Figure 2 - Recursive DNS Infrastructure
The recursive DNS Servers are connected to each subnet containing clients that send their queries directly to the recursive DNS Servers. These clients are Internal authoritative DNS servers, which are discussed in the next section, mobile and other IoT (Internet of Things) devices, possible industrial ICT devices on a Production network. The multihomed setup of the DNS servers is done to eliminate the need of extra Firewall policies or even extra IP routes. The chosen design is also more performant than a design in which the DNS queries are routed through the internal network.
The recursive DNS Servers have no authoritative zones, except for the zone containing records of the root servers. The only objective of the recursive DNS servers is to resolve queries coming from the clients. Please note that it is possible to define forwarding towards recursive DNS servers of ISPs, but experience learns that this is no always the best solution when it comes to performance and availability.
The recursive DNS Servers should be listening on the DNS port (UDP 53) only (and potentially ICMP too). On the management VLAN, extra required ports such as SSH and can be allowed.
Similar to the authoritative DNS architecture, my preferred platform (cost effective and easy to maintain) to run recursive DNS servers is a Virtual machine running a minimal footprint (core) of a stable distribution of Linux (e.g. RHEL/CentOS 7 or 8) and a stable version of bind. To ensure an additional layer of security on the authoritative DNS server itself, I make sure that the network adapters are managed by NetworkManager. I also make sure that the network adapters are configured in the correct firewalld zone, and that only the required protocols are allowed towards the respective zones. On top of that I make sure that SELinux is enabled and that the SELinux policies are set to 'enforcing'.
The internal authoritative DNS server is the holder of the IP of the FQDN (Fully Qualified Domain Name) of the machines on the internal VLANs that are defined in the internal domain. It is the name server, which has the original zone records for the internal network. In most cases, the internal authoritative DNS servers consist of a set of Microsoft Active Directory servers.
Although the fact that machines that are joined to the active directory domain should be registered automatically in the DNS domain, it is possible to manually add devices (such as network devices, Linux servers, ...) to the internal DNS domain(s) too. In most cases, the internal authoritative DNS servers are also serving as recursive servers, because most devices that are included in the active directory domain, point to the domain controllers (also running the internal authoritative DNS servers) for DNS resolution.
It is possible to allow the internal authoritative DNS servers to query the whole DNS hierarchy out there on the Internet (root servers, top level domain servers and authoritative servers), I prefer to configure forwarders on the internal authoritative DNS servers to transfer the load to dedicated recursive DNS servers as discussed in the previous section.
Figure 3 - Internal Authoritative DNS Infrastructure
In the case of a Microsoft Active Directory implementation, the authoritative DNS zone records are integrated in the active directory. The replication of these zones is handled by the active directory itself (DFS Replication).
I prefer not to use a multi-homed configuration of Microsoft Active Directory servers (amongst others for the reason that in a lot of cases the management subnet is defined as a site in the active directory servers and contains active directory servers). Instead, the operational management of the Microsoft Active Directory servers is performed through the internal firewalls.
Please note that the public authoritative DNS servers and the recursive DNS servers point to the Internal authoritative DNS server for their own DNS Client resolution (e.g. for the resolution of the addresses of the websites containing patches and updates). The internal authoritative DNS servers point to each other for their own systems' DNS resolution.
A DNS Firewall is a network security solution that prevents network users and systems from connecting to known malicious Internet locations. DNS Firewall works by employing DNS Response Policy Zones (RPZs) and actionable threat intelligence to prevent data exfiltration.
DNS Firewalls can also provide insights on threats, help isolate infected devices for remediation, and stay current with the evolving threat landscape through an automated threat intelligence feed.
The Internet Access Street contains a DNS Firewall inspecting all queries coming from the recursive DNS servers that are being discussed in this section.
I've done a few attempts to make one comprehensive schematic overview combining all of the above, but to be honest, the result was quite messy. Instead I've decided to document a few scenarios with DNS queries to clarify the whole of the design.
In this scenario, a user working on a Microsoft Windows 10 PC that resides on the Internal network wants to browse the Internet to https://www.google.com. We assume that there are no Proxy servers configured and that the client PC will connect to the Internet through the Internet access street directly. To be able to do so, the client PC needs to resolve the IP address of the host www.google.com.
Figure 4 - Client DNS request
In figure 4 above, the numbered arrows represent the various DNS queries of this scenario. The queries are referred to as the number on the figure followed by a Q. The answers to these queries are labelled with an R.
0Q: The client will look in its own DNS cache for the address of www.google.com. If a match is found, the process is completed.
1Q: The client PC sends the query for www.google.com to its configured DNS servers, which are the internal authoritative DNS servers in this case.
2Q: The Internal authoritative DNS servers check if the address for www.google.com is cached. If the address of www.google.com is cached, the rest of the process is skipped until step 1R. The query is forwarded to all configured forwarders, which are the recursive DNS servers. In the configuration above both recursive DNS servers are configured as forwarders of the internal authoritative DNS servers (active directory servers).
3Q: The recursive DNS servers check their cache for www.google.com, if the address is available in the cache, then the process continues at step 2R. Otherwise the recursive DNS servers send a query to the root servers to find the address(es) of the DNS servers for the .com top level domain.
3R: The DNS root server answers the query from the recursive servers with the address of the Top Level Domain DNS servers for the .com top level domain.
4Q: The recursive DNS servers send a query to the DNS Top Level Domain Servers to find the address(es) of the authoritative DNS servers for the google.com domain.
4R: The DNS Top Level Domain server answers the query from the recursive servers with the address(es) of the Authoritative DNS servers for the google.com domain.
5Q: The recursive DNS servers send a query to the authoritative DNS Servers for google.com to find the address(es) of the host www.google.com.
5R: The Authoritative DNS Server for the domain google.com answers the query from the recursive servers with the address(es) of the host www.google.com. The answer to the query is also stored in the cache of the recursive DNS server.
2R: The Recursive DNS Server answers the query 2Q from the Internal Authoritative DNS servers with the address(es) of the host www.google.com. The answer to the query is also stored in the cache of the internal Authoritative DNS server functioning as a recursive DNS server in this case.
1R: The Internal Authoritative DNS Server answers the query 1Q from the Client PC with the address(es) of the host www.google.com.
The queries 3R, 4R & 5R are all inspected by the DNS Firewall in the Internet Access Street. In the case that a query for a malicious domain/host is detected, the query is blocked, and a preconfigured address is returned.
In this scenario, the Internal authoritative DNS server, which is a Microsoft Windows Active Directory server which resides on the Internal network wants to perform a check for updates. Therefore the FQDN update.microsoft.com must be resolved. We assume that there are no Proxy servers configured and that the Active Directory Server will connect to the Internet through the Internet access street directly.
You'll see that this scenario is very similar to scenario 1. I added this scenario anyway, because the active directory server also points to itself for DNS resolution.
Figure 5 - AD Server DNS request
In figure 5 above, the numbered arrows represent the various DNS queries of this scenario. The queries are referred to as the number on the figure followed by a Q. The answers to these queries are labelled with an R.
0Q: The DNS client of Active Directory Server 2 will look in its own DNS cache (thus not the cache of the DNS server running on Active Directory Server 2) for the address of update.microsoft.com. If a match is found, the process is completed.
1Q: The DNS client of Active Directory Server 2 sends the query for update.microsoft.com to its configured DNS servers, which are the internal authoritative DNS servers in this case, this also includes the machine Active Directory Server 2. This means that DNS client running on Active Directory Server 2 will indeed send the query also to the DNS Server on the machine itself.
2Q: The Internal authoritative DNS servers (active directory servers) check if the address for update.microsoft.com is cached (note the difference between the cache of the DNS client process and the cache of the DNS server process). If the address of update.microsoft.com is cached, the rest of the process is skipped until step 1R. The query is forwarded to all configured forwarders, which are the recursive DNS servers. In the configuration above both recursive DNS servers are configured as forwarders of the internal authoritative DNS servers (active directory servers).
3Q: The recursive DNS servers check their cache for update.microsoft.com, if the address is available in the cache, then the process continues at step 2R. Otherwise the recursive DNS servers send a query to the root servers to find the address(es) of the DNS servers for the .com top level domain.
3R: The DNS root server answers the query from the recursive servers with the address of the Top Level Domain DNS servers for the .com top level domain.
4Q: The recursive DNS servers send a query to the DNS Top Level Domain Servers to find the address(es) of the authoritative DNS servers for the microsoft.com domain.
4R: The DNS Top Level Domain server answers the query from the recursive servers with the address(es) of the Authoritative DNS servers for the microsoft.com domain.
5Q: The recursive DNS servers send a query to the authoritative DNS Servers for microsoft.com to find the address(es) of the host update.microsoft.com.
5R: The Authoritative DNS Server for the domain microsoft.com answers the query from the recursive servers with the address(es) of the host update.micrsoft.com. The answer to the query is also stored in the cache of the recursive DNS server.
2R: The Recursive DNS Server answers the query 2Q from the Internal Authoritative DNS servers with the address(es) of the host update.microsoft.com. The answer to the query is also stored in the cache of the internal Authoritative DNS server functioning as a recursive DNS server in this case.
1R: The Internal Authoritative DNS Server answers the query 1Q from the DNS Client on the machine Active Directory Server 2 with the address(es) of the host update.microsoft.com.
The queries 3R, 4R & 5R are all inspected by the DNS Firewall in the Internet Access Street. In the case that a query for a malicious domain/host is detected, the query is blocked, and a preconfigured address is returned.
In this scenario, a user working a PC somewhere on the Internet network wants to browse to https://www.tomsnauwaert.com. We assume that there are no Proxy servers configured for the external client and that the external client is connected to the Internet directly. To be able to do so, the external client PC needs to resolve the IP address of the host www.tomsnauwaert.com.
Figure 6 - DNS resolution request external client
In figure 6 above, the numbered arrows represent the various DNS queries of this scenario. The queries are referred to as the number on the figure followed by a Q. The answers to these queries are labelled with an R.
0Q: The client will look in its own DNS cache for the address of www.tomsnauwaert.com. If a match is found, the process is completed.
1Q: The client PC sends the query for www.tomsnauwaert.com to the recursive DNS server of its ISP.
2Q: The recursive DNS server checks its cache for www.tomsnauwaert.com, if the address is available in the cache, then the process continues at step 1R. Otherwise the recursive DNS servers send a query to the root servers to find the address(es) of the DNS servers for the .com top level domain.
2R: The DNS root server answers the query from the recursive servers with the address of the Top Level Domain DNS servers for the .com top level domain.
3Q: The recursive DNS servers send a query to the DNS Top Level Domain Servers to find the address(es) of the authoritative DNS servers for the tomsnauwaert.com domain, which is our public authoritative DNS server.
3R: The DNS Top Level Domain server answers the query from the recursive servers with the public address(es) of our Authoritative DNS servers for the tomsnauwaert.com domain.
4Q: The recursive DNS servers send a query to our authoritative DNS Servers for tomsnauwaert.com to find the address(es) of the host www.tomsnauwaert.com.
4R: Our Authoritative DNS Server for the domain tomsnauwaert.com answers the query from the recursive servers with the address(es) of the host www.tomsnauwaert.com. The answer to the query is also stored in the cache of the recursive DNS server.
1R: The recursive DNS Server answers the query 1Q from the Client PC with the address(es) of the host www.tomsnauwaert.com.
The query 4R is inspected by the Internet Access Street. In the case that a maliciously crafted query was sent, the query is blocked in the Internet Access Street and no address is returned.
In this scenario, one of our public Authoritative DNS servers perform a check for updates, for which the FQDN mirror.centos.org must be resolved.
Figure 7 - DNS Client on Public Authoritative Server resolves address
In figure 7 above, the numbered arrows represent the various DNS queries of this scenario. The queries are referred to as the number on the figure followed by a Q. The answers to these queries are labelled with an R.
0Q: The DNS client of the Public Authoritative DNS Server will look in its own cache for the address of mirror.centos.org. If a match is found, the process is completed.
1Q: The DNS client of the Public Authoritative DNS Server sends the query for mirror.centos.org to its configured DNS servers, which are the internal authoritative DNS servers residing on the management VLAN in this case.
2Q: The Internal authoritative DNS servers check if the address for mirror.centos.org is cached. If the address of mirror.centos.org is cached, the rest of the process is skipped until step 1R. The query is forwarded to all configured forwarders, which are the recursive DNS servers. In the configuration above both recursive DNS servers are configured as forwarders of the internal authoritative DNS servers (active directory servers).
3Q: The recursive DNS servers check their cache for mirror.centos.org, if the address is available in the cache, then the process continues at step 2R. Otherwise the recursive DNS servers send a query to the root servers to find the address(es) of the DNS servers for the .org top level domain.
3R: The DNS root server answers the query from the recursive servers with the address of the Top Level Domain DNS servers for the .org top level domain.
4Q: The recursive DNS servers send a query to the DNS Top Level Domain Servers to find the address(es) of the authoritative DNS servers for the centos.org domain.
4R: The DNS Top Level Domain server answers the query from the recursive servers with the address(es) of the Authoritative DNS servers for the centos.org domain.
5Q: The recursive DNS servers send a query to the authoritative DNS Servers for centos.org to find the address(es) of the host mirror.centos.org.
5R: The Authoritative DNS Server for the domain centos.org answers the query from the recursive servers with the address(es) of the host mirror.centos.org. The answer to the query is also stored in the cache of the recursive DNS server.
2R: The Recursive DNS Server answers the query 2Q from the Internal Authoritative DNS servers with the address(es) of the host mirror.centos.org. The answer to the query is also stored in the cache of the internal Authoritative DNS server functioning as a recursive DNS server in this case.
1R: The Internal Authoritative DNS Server answers the query 1Q from the Public Authoritative DNS servers with the address(es) of the host mirror.centos.org.
The queries 3R, 4R & 5R are all inspected by the DNS Firewall in the Internet Access Street. In the case that a query for a malicious domain/host is detected, the query is blocked, and a preconfigured address is returned.
That's it! I hope you enjoyed reading this blogpost. Feel free to contact me in the case of comments and/or questions.
November 18th, 2019 by Tom Snauwaert.