DNS Security Best Practices
DNS is now critical to the operation of nearly every non-trivial networked application. DNS has also become dauntingly complex, both in theory and in its implementations. And unfortunately, hackers increasingly target DNS infrastructure. This confluence of factors isn’t unprecedented—it’s the same combination that drove IP routing, network storage, and firewalls to appliance implementations, because only appliances could deliver the requisite simplicity of management, reliability, and security.
Use Dedicated DNS Appliances
DNS Appliances, like other network appliances, are purpose-built and as such are both hardware and software configured for ease of management, security, and performance. Common OS servers cannot match the tuning that these appliances offer. DNS appliances benefit from all the same advantages that other network appliances do, including but not limited to unnecessary ports, limited driver requirements, to limiting other network chatter on interfaces, to maximizing RAM availability – these appliances win in every area. Additional information can be found here: the benefits of using dedicated DNS appliances.
Keep DNS Server Software Up-to-Date
Hackers are not waiting around to see if the latest exploit is stable, so you have to stay up to date as well. With DNS becoming an ever-increasing target of attacks both against DNS itself and by using DNS for everything from command and control to data exfiltration, it has never been more imperative to be on the latest and greatest code for your solution. Having the latest software allows you to mitigate the latest attacks.
Historic independent server design makes this best practice quite daunting as server updates not only had to be done a per-server basis but you had to weigh operating system upgrades against all the functions you leveraged. Having a centrally managed solution that allows for architecture-wide upgrades can drastically simplify this process. It is easy to take DNS for granted as it is an incredibly resilient protocol. It doesn’t slow down or give warning signs when it is out of date. So, you have to be proactive about patching and upgrades.
Have an Onsite DNS Backup
No matter how foolproof your design, you always have to prepare for the worst. Having an onsite backup provides you with the ability to get your DNS operations and, maybe more importantly, everything that depends on your DNS, back up and running as quickly as possible. Again, a central solution that allows you to spin up an entire DNS architecture all at once is a huge benefit. These solutions can often be backed up in a single file.
Automate your backups whenever possible and try to keep the frequency regular enough that rolling back to these backups will not cause undue issues. Things like Dynamic DNS happen in near real time. There is no way you could have a perfectly accurate backup at all times, but that is not what you want to dictate the frequency. Things like Active Directory changes reflected in DNS SRV records being accurate, though, are. So daily backups or possibly weekly should do the trick for most organizations. What you are looking at is the rate of change of your DNS data and what is critical to having your services back up and running as quickly as possible.
Avoid Single Points of Failure
Like all critical piece of your network infrastructure, avoiding single points of failure applies just as much to DNS. While historically DNS was considered a “service” and less a “network” component, we recognize more and more that the network and users of the network are dead in the water without DNS. Given that web, mail, chat, and even sometimes voice can depend on DNS, it must be considered a critical network component. Add to that the increasing use of DNS as part of an organization’s comprehensive network security architecture and it becomes even more critical. While DNS inherently provides protocol redundancy, in today’s world that is not always enough. The time to switch between servers varies on many factors, including client OS and the server software running on intermediate servers. While these failovers can be tolerable for simple usage, it cannot compete with providing hardware redundancy to the protocol redundancy, allowing failures to be faster and invisible to clients as the IP of the server doesn’t change.
Turn Off Recursion on Authoritative servers
Inside your organization:
DNS attacks come in two main types: those that target your authoritative servers such as DDoS Attacks and those that attack the caching functions of your recursive servers. So by not providing a single target for both, you avoiding keeping all your eggs in a single basket. Yet, the bigger issue is based on the whole protocol of DNS and how the DNS hierarchy works. It is the distributed nature of DNS that recursive servers have to talk to whatever DNS server the parent servers send them to. This means that you have no control over which other servers your DNS servers actually talk to. By allowing your servers that hold your authoritative servers (which hold your data) to talk to any DNS server in the world is just not a best practice. Adding a dedicated recursive caching layer to your design means that your authoritative servers only connect to dedicated caching recursive servers that do not contain your organization’s data. It also can speed resolution as a centralized cache can be more robust and actually result in less DNS traffic being sent.
On the Public facing side:
Allowing recursion on your external-facing DNS servers has long been a strict no-no. Allowing this is referred to as open recursive servers. Google and others make good money providing this service either in money or in gathering your information, but for the typical organization ensuring that you have recursion disabled on any public facing DNS server is a strong best practice. It makes it easy for attackers to find weaknesses in caching functions that could, in turn, diminish or stop the ability of the server to answer your authoritative data. Attacks that cause server restarts or buffer overflows are just two examples of the risks you add when mixing authoritative and recursive functions on one server.
