Private DNS: Tutorial, Best Practices & Examples

Most engineers are familiar with the conventions and best practices associated with setting up DNS. However, not all are aware of the many improvements that are possible when using private DNS, an alternative way to handle the records used to resolve internal resource names by keeping those records private (not able to be resolved by public DNS). The additional flexibility in the use of the organization’s DNS records, advanced security features, and the wide array of configurations available make private DNS very appealing for both simple and complex topologies. 

The following article is an in-depth explanation of how private DNS works, including examples of architectures and best practices for implementing private DNS successfully.

Summary of private DNS key concepts

Here is an overview of what’s covered in this article.

How private DNS works	Private DNS works using a series of queries and responses, exactly like public DNS; the main difference relates to how the records are maintained and distributed.
Private DNS architectures	Examples of private DNS architectures include dedicated, split-horizon, DNS forwarding, SDN, and cloud-based DNS.
DNS over TLS (DoT)	DoT adds a layer of encryption to DNS traffic using the Transport Layer Security (TLS) protocol.
Benefits of private DNS	Private DNS offers improved security, better performance, and enhanced privacy.
Implementing private DNS	Adding private DNS architectures to an environment requires a thorough planning process that includes architecture choice, testing, proper monitoring, and utilizing security and privacy best practices.
IPv6 in private DNS	Private DNS works mostly the same way for IPv4 and IPv6, but IPv6 requires taking some additional considerations into account.

How private DNS works

Private DNS is a way to create a custom DNS namespace within an internal network. It allows organizations to develop their own domain names that can be resolved by the devices on their internal networks without having to use public DNS servers. 

Here’s how private DNS works:

1. The organization sets up a private DNS server within its private network. This DNS server acts as the authoritative DNS server for the organization’s custom domain names. 
2. IP addresses are assigned to devices within the internal network. 
3. The organization creates custom domain names and associates them with the IP addresses of its devices.
4. Information about IP addresses and custom domain names is stored in the private DNS server’s zone files. 
5. When a device on the private network needs to access another device by its custom domain name, it queries the private DNS server.
6. The private DNS server looks up the IP address associated with the domain name in its zone files and returns the IP address to the requesting device. 
7. The requesting device can then use the IP address to establish a connection with the desired device on the private network.

Benefits of private DNS

Improved security and control

Public DNS servers are accessible to anyone on the Internet, making them vulnerable to attack. Hosting a private DNS server allows an organization to limit its exposure to external threats such as DNS attacks, which can disrupt or compromise conventional DNS resolution. 

Using private DNS, organizations can have complete control over their DNS records, including managing their own subdomains and configuring access controls. This can prevent unauthorized access or changes to DNS records, which could be used to redirect traffic or launch phishing attacks.

This feature also allows organizations to keep their DNS queries and responses within their own networks rather than sending them to public DNS servers. This can enhance privacy by reducing the amount of data that is shared with third-party DNS providers.

Finally, private DNS also allows organizations to implement their own security policies, such as blocking certain domains or types of traffic. This can help prevent malware infections or other security problems.

Better performance

Private DNS can enhance performance in a number of ways.

Public DNS servers can be slow to respond to DNS queries, especially during times of high traffic. By hosting a private DNS server inside the organization’s network, most clients will be able to resolve DNS entries very quickly because there is a direct connection to the server via the local network, resulting in reduced latency. This ensures faster response times, which can improve the user experience and reduce the likelihood of timeouts or connection errors.

Private DNS servers can optimize traffic routing by directing users to geographically closer servers or balancing traffic across multiple servers. Private DNS also adds the capability of ad-hoc customization, which is not an option for public DNS servers. This can improve the performance of applications and services by reducing network latency and improving response times.

Privacy

Given the presence of the word “private” right in the name, it’s no surprise that private DNS can help enhance privacy within the organizations that use it. Here’s how.

Consider that conventional DNS queries can draw a map for potential attackers monitoring network traffic being sent over the Internet. Trends can be detected about websites that are frequently visited or by tracking the frequency with which DNS records are changed. Similarly, DNS scraping tools can be used by an attacker to identify very useful information about any domain:

• Subdomains
• Zone transfer vulnerabilities
• Lists of mail servers
• Email addresses
• Technology stacks

Allowing an organization to keep DNS queries and responses within its own network helps enhance privacy by reducing the amount of data shared with third-party DNS providers. 

In addition, private DNS allows organizations to have greater control over their DNS data. They can manage their own DNS servers and DNS records, configure access controls, and customize security policies. This can help prevent unauthorized access to DNS records or rogue changes to them, either of which could be used to redirect traffic or launch phishing attacks.

Private DNS architectures

There are a number of different private DNS setups used in the industry, which vary in terms of their setups and the hardware and software components they use. We’ll take a look at three different architectures in this section; please also see the discussion of selecting architectures in the best practices section later in the article.

Split-horizon DNS servers

In this architecture, the same DNS server is used to manage both public and private DNS zones. The server responds to requests for public domains from the public Internet while responding to requests for private domains from devices within the organization’s internal network.

Cloud-based DNS

This architecture involves using a cloud-based DNS software-as-a-service (SaaS) product to manage the domain name resolution process for the organization’s network. The service can be configured to provide private DNS resolution for the organization’s internal network while also providing public DNS resolution for external requests. However, responsibility for the infrastructure and security falls on the cloud provider rather than the domain owner, which can present an entirely different set of issues.

Private DNS with a software-defined network

In this architecture, private DNS resolution is integrated into a software-defined network (SDN) that provides network virtualization and other advanced features. Private DNS resolution can be implemented using virtual DNS servers that are deployed within the SDN. The advantage then becomes the ability to manage the DNS infrastructure from a software platform; this is similar to cloud-based DNS, but here the domain owner is solely responsible for the security and infrastructure.

Private DNS implementation and best practices

The following actions can help assist in the implementation of private DNS and provide the best potential for using it effectively.

Plan carefully

When designing a DNS deployment, it is important to keep the following considerations in mind.

In a Windows server environment, DNS should be running on a domain controller (DC). Typically, DCs are deployed in pairs, and many organizations choose to create at least one physical server and any number of virtual servers for redundancy.

The software chosen will be the most significant part of the planning process. Windows standard DNS features are arguably the easiest to configure and, in theory, create less of an opportunity for mistakes when configuring. Windows DNS integrates with Windows Active Directory, creating a database of services running on the network. 

If standard DNS services through Windows are not being used, and alternatives like Bind 9 are going to be implemented, then a Linux server is required. In terms of virtualization, this is a good opportunity to explore Docker containers as a use case in your environment as well.

Choose the right architecture

Each of the DNS architectures described earlier has a variety of use cases, so it is important to look at your organization as a whole and evaluate the requirements.

Typically, the architecture chosen should allow for both client and location growth. For example, suppose that an organization is currently operating out of one physical location and has 100-200 or so clients, but it hosts most of its applications in-house. In this scenario, split horizon DNS would be an excellent choice, providing the versatility of using the local domain name and the public domain to resolve to different locations depending on where the client is located. For example, a client inside the organization might access www.example.com and be directed to an alternate web server IP than a user outside the local network trying to resolve the same URL.

In an instance where the organization is spread out across multiple locations—maybe even continents—it might be preferential to implement a cloud-based or SDN-based DNS server. In the case of cloud-based DNS, this gives the opportunity to move or add additional virtual servers in different regions that may be closer to other locations, resulting in reduced latency but still utilizing the flexibility of private/public DNS. Either of these architectures would also utilize a software-based GUI for managing DNS, allowing multiple users to manage the setup from anywhere.

Test thoroughly

Thorough testing is essential to ensuring that the private DNS deployment is working correctly and providing the desired level of performance and reliability. Test all aspects of the DNS resolution process, including name resolution, caching, and error handling.
GRC’s DNS Benchmark is an excellent way to retrieve test data for your new DNS server. This software will give you the output similar to the following and allow you to check all DNS resolution metrics:

Additionally, with DNS Benchmark, you can compare your data against hundreds of available DNS servers to make sure you are meeting industry expectations.

Start configuring a few workstations as a test group to use the new DNS servers as the primary DNS. From the workstations, any number of tools can be used to inspect DNS resolution, including:

• Nslookup on Windows devices
• DNS Leak Test
• MX Toolbox DNS Check

Monitor and maintain

Once the private DNS deployment is up and running, it’s important to monitor the system regularly to detect and address any issues that may arise. Regular maintenance and updates are also essential to keep the system secure and current.

Here’s a resource to help you get started monitoring DNS:

• The Comprehensive Guide to DNS Monitoring

There are numerous cyber-attacks that can be prevented simply by monitoring your DNS servers. Some of these include the following:

• DNS cache Poisoning
• DNS hijacking
• DNS tunneling

Take security and privacy into account

As mentioned earlier, private DNS can inherently provide improved security and privacy for network traffic, but it’s important to consider other security measures, such as DNS over TLS (DoT), to further enhance the security and privacy of the system. 

DoT adds a layer of encryption to DNS traffic by using the Transport Layer Security (TLS) protocol. When a user’s device sends a DNS request over a network that supports DoT, the request is encrypted using TLS. The request is then sent to a DNS resolver that also supports DoT, which decrypts the request and processes it. The resolver then encrypts the response using TLS and sends it back to the user’s device, where it is decrypted and processed.

Microsoft recently added support for DNS over TLS to Windows 11 Insider Build 25158 and higher. An indepth look at configuration can be found here.

The DNS Privacy Project has made some amazing progress in helping to create more secure DNS standards and software. The solutions page on the DNS privacy project website lists all advancements to security protocols that are current or being developed.

Private DNS implementation example

Let’s take a look at an example to further illustrate how implementation and best practices might look in a sample network.

Reality Technology is a new small business in the process of planning its technology infrastructure and practices; as part of this effort, its IT team is trying to decide whether to use private DNS as part of the network topology. All traffic will be within the same LAN, and remote workers will use a VPN solution to connect. A diagram of the proposed network and workloads is shown below.

During the planning phase, it was decided that an additional VM can be added to the topology to act as the domain controller for the RealityTech.int domain, moving the DHCP/DNS role from the firewall appliance to the server, utilizing dedicated DNS architecture. This architecture will allow for better security and scalability by removing the single point of failure that currently exists due to the firewall handling DNS resolution. The proposed solution will also allow for the use of private DNS records to resolve the internal applications hosted on the VMs.

With the planning phase complete and the architecture in place, the organization will move to the testing phase. During testing, the company will need to verify that the internal IP of the DNS server can be distributed through DHCP and that endpoints can resolve external IPs. It will also check that internal subdomain fully qualified domain names (FQDNs) can be assigned to the two applications servers by internal IP and be resolved correctly. The testing phase is also a good opportunity for the company to evaluate redundancy in the architecture and make appropriate additions, depending on the priority of the app servers.

The monitoring and maintenance planning phase includes using remote monitoring and management (RMM) software with checks and alerts configured on the domain server, monitoring core DNS services and the network connectivity to the server. Users must be trained on the appropriate response channels when experiencing issues with app server name resolution.

Security and privacy should always be considered in any infrastructure implementation decision. The primary concern in this architecture would be hardening the internal network, which is the most likely avenue of attack, considering that the private DNS server can’t be reached externally. Measures to prevent any outside access to the internal network would be a priority; there are no outside-facing resources, so the firewall’s access list should be created accordingly. Furthermore, the network can withstand the extra overhead associated with DNS over TLS, so it should be implemented for additional security.

Private DNS in an IPv6 environment

The discussion thus far has assumed a standard IPv4 address scheme being applied in the private DNS design. Most of the concepts and best practices discussed above also apply when implementing private DNS in IPv6 networks, but there are a few extra considerations that should be taken into account:

• AAAA Records: AAAA (quad A) DNS records are used to translate domain names to IPv6 addresses. Like A records, which are used to map domain names to IPv4 addresses, AAAA records are a fundamental component of the DNS system.
• IPv6 and SLAAC: Stateless Address Autoconfiguration is defined by RFC 4862 and acts as an alternative to DHCP or static addressing. SLAAC still needs to have reverse DNS records for these addresses. RFC 4472 suggests solutions for resolving this issue: By configuring wildcard records for the complete range of IPv6 clients with SLAAC, a possible outcome is the dynamic generation of PTR records by the DNS resolver upon receiving reverse DNS queries.

Conclusion

Private DNS can provide many benefits for organizations and networks, such as improved security, privacy, and performance. By using a dedicated DNS server or other private DNS architecture, organizations can gain more control over the DNS resolution process, which can help improve network reliability and security. 

Deploying private DNS requires careful planning, testing, and ongoing maintenance to ensure that the system is working correctly and providing the desired level of performance and security. By following best practices and considering the specific needs of their network, organizations can successfully deploy private DNS and enjoy the benefits it provides.