This website uses cookies

We use cookies to personalize content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners who may combine it with other information that you've provided to them or that they've collected from your use of their services. Please read more at our privacy policy page.



X

DNS best practices: Inexpensive ways to avert costly security breaches

Domain Name Systems are responsible for translating domain names to IP addresses. An organization can’t afford for its DNS to go down, because that can potentially stop access to critical web-based links. However, DNS-based attacks are a harsh reality of the current cybersecurity risks environment. Remember the recent DDoS (Distributed Denial of Service) attack that severely affected Dyn. This attack temporarily took down PayPal, Amazon, The New York Times, and websites of other Internet giants. Apart from being a vital component of the modern company’s IT infrastructure, healthy DNS is critical for Windows Active Directory and several other services to operate seamlessly. As a result, enterprises are looking to enhance their knowledge of DNS best practices, and this guide brings a lot of them together, so read on.

DNS best practices: Make only the most necessary information available

The first thing enterprises must do is to ensure that only the information absolutely necessary for the involved parties using the web server should be made available on the server. For instance, if there are domain names that need to be resolved by the public, then the public should only be given access to the servers responsible for the same, and the data necessary for the same. All other DNS data and servers should be restricted for access internally only. Also, publicly available servers should only be authoritative and not recursive. That’s because external parties don’t need to use recursive name servers. This practice can significantly curb damage in case of an outage or security breach, and in general, limits the threat surface area.

Isolate DNS service from DNS resolution

A DNS service basically defines name and address mapping, and then sends the info locally to the Internet. DNS resolution, on the other hand, navigates through the World Wide Web’s hierarchies of name servers and finds these mappings. DNS best practices and a robust DNS system design are all about isolating DNS service from the DNS resolution. You can use a pair of dedicated virtual machines to deliver the much-needed DNS resolution. Make sure that these VMs just run the basic DNS resolver config, and perform no other function. For companies with multiple security zones within a localized area, pairs of DNS resolvers can be set up in each zone. Simple, basic, and small resolver VMs make sure that companies are able to achieve automatic resistance to DDoS attacks, as well as misbehaving clients, at a low cost.

Make DNS servers parts of high-availability clusters

Large-scale denial of service attacks can render providers incapable of serving DNS data. This is where the idea of high availability comes to the fore. DNS servers should operate as parts of high availability pair of clusters. This ensures that in case one fails, the other is able to sustain operations. All kinds of DNS server resources — right from primary and secondary name server, authoritative or recursive — can be made available by ensuring inclusion in a high availability cluster. Also, for publicly accessible servers, enterprises must look for geographically diverse servers to ensure safety against physically localized events.

Hide primary servers

Any server that hosts the master copy of any zone needs to be set as a hidden primary. For primary servers, follow these best practices:

  • They should exist only to serve critical data to secondary nameservers.
  • They must not be listed as nameservers for any zone.
  • End users should not be able to send and receive info from these servers.

Such an arrangement ensures that only those individuals have access to the primary servers who’re actually responsible for its maintenance and upkeep. Also, firewalls can be used to protect primaries when they work with external nameservers. The firewall must be configured to make sure that only the secondary nameservers can make queries to the primaries.

Choose the right platform

Choose the right DNS management platform for your enterprise — this is very important, considering it can be tough to manage migrations later. IT managers often prefer Microsoft DNS because they need this tool to work with Active Directory as a server and resolver. There are other products from vendors such as Infoblox and BlueCat Networks, for example, that offer easy-to-use DNS management suites. For small businesses that are still using old-style text file configuration, there are several open source tools they can choose from, including BIND,  and a lot more.

Local servers

Local workload distribution is the key to making DNS healthy for your enterprise. You don’t want helpdesks and end users to be slowed down because of an overloaded central nameserver. As an alternative, look to use local nameservers for regional offices of the enterprise. For organizations with a lot of branches and regional setups, it’s highly recommended to use authoritative and recursive nameservers on-site for serving these locations. The distribution of query loads on multiple servers makes sure that names are resolved very quickly. Remember, even a typical web page could consist of thousands of linked resources, each of them requiring a DNS lookup for proper page load. In such situations, high latency can be a huge problem, unless you have local servers.

Don’t put split DNS service on different servers

Some companies use a split service, where users within the company network (using private IPs) get one set of results, and users outside get another set of results from the DNS service. If your enterprise uses split DNS service, it can be a headache to put the services on different servers. That’s because every name change will require you to make two updates. We mentioned BIND earlier — it's one of the better tools you can use to manage multiple views. The tool can deliver different sets of results to internal and external users, and reduces the actual number of different databases that an enterprise needs to use.

Building a strong DNS does not take a lot of expensive resources, but it does take a lot of planning to devise a robust design. Follow the DNS best practices shared in this guide, and you will do a great job.

Photo credit: Shutterstock