DNS Best Practices for Security and Performance

The Domain Name System (DNS) makes all networked communication possible. DNS may seem like an invisible force or entity, until something goes wrong, then it’s apparent: If DNS service goes down, then nothing works.

This article will outline the best practices and the most important security measures to keep your DNS infrastructure healthy. Make sure to take into account the points listed below to build a secure and robust DNS.

DNS Performance Best Practices

Ensure DNS Redundancy and High Availability

As DNS is the pillar of network applications, the DNS infrastructure needs to be highly available. To accomplish the essential redundancy, you need to have at least the primary and secondary DNS servers in your organization.

To keep the business-critical services running, having at least two internal DNS servers is a must. All active directory, file sharing, and email services rely on proper DNS operation. Without healthy and functional internal DNS servers, internal devices cannot communicate.

If one DNS server runs into an issue, the other one takes over immediately. Admins configure machines to use secondary DNS automatically if the primary is not responsive. An IP of an internal DNS server can be any address within a private network IP range.

By making DNS servers redundant, you can achieve high availability of the DNS infrastructure. Continuous replication from primary to secondary servers will keep your DNS records in sync and safe from failures. You can ensure that there will never come a time when there are no services available for an end user.

Hide DNS Servers and DNS Information

Not every DNS server and each piece of information need to be made available to all users.

First, make accessible only the servers and the data necessary for the individuals using these servers. This is especially important if your domain names need to be visible by the public.

Second, hide your primary DNS server. Primary servers must not be visible to external users. Records for these servers should not be available in any publicly accessible nameserver database. Only secondary DNS servers should address requests from end-users.

If a DNS server is accessible from outside your network, that server needs to be an authoritative-only DNS server. There is no need for external users to query your recursive DNS servers. Responding only to iterative queries for the respective zones a server is authoritative for, is a high-performance configuration.

Finally, only system admins and IT personnel should have access to primary servers within your organization. If you leave primary DNS servers visible to all internal users, that may become a significant security issue. As a rule of thumb, hide the DNS servers and the data from users that do not need to have access to them.

Should I Use an External or Internal DNS Server?

The answer to this question depends on the internal setup.

To allow devices on one domain to talk to each other, you need to point them to an internal DNS server. External DNS servers cannot resolve hostnames of internal devices.

For instance, when a computer DESKTOP1 sends a DNS query for office-printer or a server hr-1, only an internal DNS can provide a resource record. If you set a device to use an external DNS, such as Google’s 8.8.8.8, you will not be able to use internal resources.

In internal environments, you need to set both the primary and secondary DNS to an internal nameserver. Even when the primary DNS server fails, there will be no connectivity issues. The secondary DNS server contains all records and acts as a backup. In case of an issue, this server responds to all queries until the primary server is back up and running.

Use the Local or Closest DNS Server

Large organizations often have offices around the globe. If the infrastructure allows, you should set up a local DNS server in every office.

The reason is a local server reduces response times for DNS requests. When a query travels across WAN to a remote nameserver, a user gets longer load times.

With a high number of clients, the number of DNS queries grows. One centralized set of DNS servers can handle all requests, but with more latency. By pointing users’ machines to a local or closest nameserver, response times are reduced to a minimum.

In this case, latency does not go higher than 50ms. Moreover, the number is usually much below that value. Using the closest DNS server improves load times for all machines. This way, you also take the burden off the remote server in HQ and improve its performance. The recommendation for having at least two DNS servers remains in effect here as well.

DNS Security Best Practices

DNS servers are a frequent target of cyber-attacks. Securing DNS infrastructure is a crucial step in preventing breaches into your organization. To avoid a major impact on your DNS setup, make sure to employ the security measures outlined below.

Enable DNS Logging

DNS logging is the most efficient way to monitor DNS activity. The logs let you know if someone is meddling with your DNS servers. Besides client activity, debug logs tell you when there are issues with DNS queries or updates.

DNS logs also show the traces of cache poisoning. In this case, an attacker changes the data stored in the cache and sends clients off course. For example, an IP address of www.youtube.com might be changed to an IP address of a malicious site. When a client sends a query to DNS for youtube.com, the server now returns the wrong IP. Users then visit websites they did not want to visit and become a target of hackers.

Even though DNS debug logging brings up security to a higher level, some system admins decide to disable it. The main reason is to increase performance. Monitoring network activity can help you detect some attacks, such as DDoS, but not cache poisoning. Therefore, we highly recommend enabling DNS debug logs.

Lock DNS Cache

Whenever there is a query from a client, DNS finds the information and stores it in the cache for future use. This process allows the server to respond faster to the same queries. Attackers can exploit this feature by altering the stored information.

A step further from enabling DNS debug logs is locking DNS cache. This feature determines when the cached data can be changed. The server keeps lookup information during the amount of time defined by the TTL (time to live). If cache locking is disabled, then the information can be overwritten before the TTL expires. This leaves room for cache poisoning attacks.

Depending on the operating system, cache locking may be enabled by default. The cache locking scale goes up to 100 percent. When the value is set to 70, overwriting the data is not possible for 70% of the TTL. By defining cache locking to 100, changing the cached information is blocked until the TTL expires.

Filter DNS Requests to Block Malicious Domains

DNS filtering is an effective way to prevent users from accessing a website or a domain. The main reason to block name resolution for a domain is if that domain is known to be malicious. When a client sends a query for a blocked website, a DNS server stops any communication between them.

DNS filtering massively reduces the chances of viruses and malware reaching your network. When a client cannot reach a malicious page, the number of threats that can crawl inside your infrastructure is minimal. This way, your IT staff does not have to work around the clock to clean up the viruses.

Besides security, organizations may want to block a domain due to a business policy or for productivity reasons. The list of blocked domains can include social media, gambling, pornography, video streaming pages, or any other website. DNS can filter requests by a user, a group, or block access for all users.

Modern software security and firewall solutions include DNS filtering as standard. Some of these appliances provide regularly updated lists of bad domains. By employing a ready-made software solution, you can automate DNS filtering and avoid adding new entries manually.

Validate DNS Data Integrity with DNSSEC

Domain Name System Security Extensions (DNSSEC) ensure clients receive valid responses to their queries. Data integrity is achieved by DNSSEC digitally signing DNS data provided to nameservers. When an end-user sends a query, a DNS server provides a digital signature with the response. Hence, clients know they received valid information for the request they sent.

This added layer of security helps with fighting off DNS protocol attacks. Since DNSSEC offers the data integrity and origin authority, DNS spoofing attacks and cache poisoning are successfully averted. Clients are then confident they are visiting the pages that they intended to visit.

Configure Access Control Lists

Access Control Lists (ACL) are another way of protecting DNS servers against unauthorized access and spoofing attacks. Only IT administrators and system admins should have access to your primary DNS. Configuring ACLs to allow inbound connections to a nameserver from specific hosts ensures that only the intended staff can communicate with your servers.

Additionally, ACLs need to define which servers can make zone transfers. Attackers may try to determine your zone setup by sending zone transfer requests through secondary DNS servers. If you block all zone transfer requests over secondary servers, an attacker cannot obtain zone information. This configuration prevents third-parties from getting insight into how you have organized the internal network.

Conclusion

There is always room for improvement in the DNS design and security of your infrastructure. Constant threats are lurking and waiting to exploit vulnerabilities in your IT system.

However, if you follow the points listed in this guide, you will cover the most important aspects your DNS infrastructure needs to stay secure and resilient.

If you are looking to specialize or expand your knowledge further in IT security, we recommend our articles on Best IT Security Certifications and Top Cyber Security Podcasts.