DNS Best Practices: A Quick Guide for Organizations
Nowadays, the traditional on-site computing architecture is moved to remote facilities that are normally under the management of a third party as enterprises convert, entirely or in part, to cloud-based services. Too frequently after an attack, the targeted organization discovers that it cannot dependably solve the information required to access that remote infrastructure, preventing it from carrying out its business. Companies suffer if you can’t access your DNS servers or believe the data they offer.
As we previously discussed, DNS also gives IP addresses for Internet domain names, which is crucial security data for a network within a company. Computer security initiatives too frequently concentrate on the edge and endpoint-based security procedures that are based on log analysis. It’s critical to keep in mind that DNS requests and responses can provide a wealth of security-related data about network activity. Both authorized users and potential cybercriminals can learn a great deal about a company’s infrastructure from the DNS records alone.
Although some could contend that one reason for the efficiency of DNS is that it is invisible to the typical user, others may counter that this makes it easier for criminals to go undetected. One intriguing pattern we’ve noticed is that certain admins disable query logging on nameservers, usually for efficiency reasons. This approach is regrettable as DNS logging is a key tool an organization can employ to identify a rogue entity causing damage to its DNS infrastructure or other areas of the ecosystem.
Cybersecurity experts can benefit from tracking DNS requests and responses from network activity itself in addition to logs. For instance, keeping an eye on the normal flow of traffic to and from a company’s DNS servers can assist analysts to spot DDoS attacks that use those nameservers promptly.
When creating a safe and dependable DNS infrastructure, you might want to take into account the following guidelines.
DNS Best Practices
Make sure DNS is highly available and redundant
The DNS infrastructure must be highly available since DNS is the foundation of data networks. You must have at least the primary and secondary DNS servers in your business in order to achieve the necessary redundancy.
Having a minimum of two internal DNS servers is necessary to maintain the business-critical services in operation. All email, file-sharing, and active directory services depend on reliable DNS performance. Internal DNS servers are required for proper internal device communication. In the particular instance of publically available servers, a company should provide geographically dispersed servers in their domain name registration to guard against physically localized incidents as well as routing diversity, preferably from providers with distinct Autonomous System Numbers (ASNs), to guard against massive denial-of-service attacks that may impair a provider’s capacity to serve your DNS information.
Only make available what is necessary
When talking about DNS best practices, making sure that only the data required for the parties utilizing the server is accessible there is one of the primary things that companies can do. The main servers in your company should only be accessible by system administrators and IT staff. If all internal users have access to your principal DNS servers, it could pose a serious security risk. As a general rule, keep the DNS servers and the information out of the reach of people. All additional servers and associated data must only be accessed internally. Servers that are accessible to the general public ought to operate authoritatively exclusively; not recursively. Your iterative nameservers are not required to be used by people outside of your company. These people need to be using the nameservers that their ISP has provided for them to use.
Conceal your primary servers
Next, conceal your main DNS server. External users should not be able to see primary servers. There shouldn’t be any publicly accessible nameserver databases that include the data for these servers. Requests from end users ought to only be handled by secondary DNS servers.
A DNS server must be an authoritative-only DNS server if it is reachable from outside your network. External users are not required to query your recursive DNS servers. An elevated configuration involves a server only responding to recursive queries for the specific zones for which it is the authoritative server.
Preventing anyone other than those in charge of maintaining the servers and the data they hold from accessing the primary nameservers helps to secure the trustworthiness of the DNS data. When using nameservers that are publicly accessible, the primary nameservers must be protected by a firewall with the right firewall rules in place to guarantee that only the secondary nameservers can execute queries on and transfers to the primary nameservers.
Use your local DNS server
Typically, big companies have offices all over the world. Every office needs a local DNS server, which you should install if the infrastructure permits.
The explanation is that a local server speeds up DNS request responses. A user experiences slower load times when a query goes over a wide area network to a distant nameserver. A regular web page could connect to dozens or hundreds of sites, and each one might call for a DNS lookup before the page can be loaded. The latency between both the end user and the designated nameserver might lengthen load times unnecessarily and increase the workload on the support desk.
All devices load faster when the nearest DNS server is used. By doing this, you relieve some of the strain on the remote server at headquarters and enhance its functionality. Here as well, the advice to run at least two DNS servers is still valid.
Limit access
In addition to firewall ACLs, zone transfers should be secured by on-server TSIGs and access control lists (ACLs). Not just by privileged access management, but also by restricting access to the nameservers from hosts other than those utilized by those employees, primary nameservers should only be available to those people responsible for their upkeep and maintenance. All zone transfer requests should be rejected by secondaries. Nameservers shouldn’t act as recursive servers if they are supplying authoritative data. By reducing their attack surface, nameservers that are just serving authoritative data and not acting as recursive servers help to assure availability. ACLs on the server and firewall-based ACLs should be used to limit all traffic to the nameserver. These ACLs restrict access to the server, stopping specific attack types like denial-of-service attacks while guaranteeing that traffic that really does reach the server is legitimately using the service.
Safeguard the integrity of your data
Domain Name System Security Extensions (DNSSEC) should be used whenever possible, but especially with zone data that is accessible to the general public, to guarantee the accuracy of the data being delivered. DNSSEC digitally signs DNS information so nameservers may validate its accuracy before responding to queries with it. The Internet Corporation for Assigned Names and Numbers (ICANN) asserts that full DNSSEC deployment will assist in ensuring that end-users are connecting to the genuine website or any other service associated with a specific domain name. Public key infrastructure (PKI) is used for this authentication, creating a chain of confidence between the root server located at the top of the DNS tree and the lowest end nodes, or the nameserver for the end user.
Heimdal® Threat Prevention - Endpoint
- Machine learning powered scans for all incoming online traffic;
- Stops data breaches before sensitive info can be exposed to the outside;
- Advanced DNS, HTTP and HTTPS filtering for all your endpoints;
- Protection against data leakage, APTs, ransomware and exploits;
How Can Heimdal® Help?
DNS filtering is the first stage toward a secure DNS. Even if it isn’t exactly a novelty in cybersecurity or a match to DNSSEC, it is nonetheless important. A strong DNS filtering engine like the one used by Heimdal® Threat Prevention is more than capable of catching malicious data packets that could damage your endpoints and network. Our product reduces latency by using both local and cloud queries. The DNS traffic filtering engine examines data packets each time your machine performs a DNS query to check for anything suspicious hidden in the Internet traffic. Additionally, Heimdal Threat Prevention will automatically block the connection if it detects any odd behavior when querying.
Wrapping Up…
The DNS is an essential tool in any workplace as it is integral to the framework of the World Wide Web. Understanding how it works and how to secure it appropriately should therefore be at the top of your company’s list of priorities. If you adhere to the advice provided above, you will take care of the crucial elements your DNS infrastructure requires to remain safe and dependable. You can also do that with the help of Heimdal. Contact us at sales.inquiries@heimdalsecurity.com for additional details or to schedule a demo.
DNS Security for Dummies
An eBook that gives a comprehensive role-based security approach and addresses the numerous dangers to the Domain Name Systems (DNS) as cyberattacks increase globally.
If you liked this article, follow us on LinkedIn, Twitter, Facebook, YouTube, and Instagram for more cybersecurity news and topics.