This is a two-part post. The first part will cover basics, and the second part will cover more advanced topics in securing DNS.
DNS isn’t this monolithic thing where one size fits all but, there are some things to consider. We will take a look at some infrastructure segmentation and some configuration security. Please note that the content is generic, but the screenshots show how it would be done using the Infoblox Grid Manager.
Recursion and Authoritative DNS servers have different capacity needs and different security requirements.
So if you can, keep these on different hardware. If different hardware isn’t possible, then at the very least keep them in separate views. In the case where you use views and the same hardware, consider using the match destination option — trust me it will come in handy when you have to troubleshoot.
Let’s look at securing the authoritative side first.
If you are self-hosting then you are going to need to have at least two (2) name servers hosting your zones – preferably more. These name servers should be spread across as many networks as you can so that when someone fat fingers a firewall rule (because that never happens), it doesn’t take out your services that depend on DNS – which let’s face it, is everything on which your business relies. If you can do anycast, the same rules apply. Advertise the serving IPs across as many networks as you can to avoid outages due to network events.
If you have the budget for external DNS hosting, then you will want to use an ACL to restrict the queries and zone transfers to/from your providers; I say providers here for a good reason. One of the risk remediation recommendations from the Oct 2016 Dyn attack was to have more than one provider so that if one suffers an outage, your services still work. The outage need not be an attack. A configuration issue could also cause an outage, so keep that in mind (https://www.wired.com/story/how-a-tiny-error-shut-off-the-internet-for-parts-of-the-us/).
If on the other hand you are self-hosting and have an external DNS secondary service, then you still need that ACL for zone transfers.
You will also need to allow queries for the zones – and mind those match client and match destination statements along with your view ordering.
You will also want to make certain that this view has recursion disabled even if the member has recursion disabled already. There are some complex configurations that might call for recursion being inherited from the member, but that adds complexity. Complexity is the enemy of security.
One last thing you might consider in securing your authoritative data is using DNSSEC to sign your external zone data. This ensures that those who do DNSSEC validation (like Google DNS and Comcast) won’t cache a spoofed/poisoned reply from an attacker / bad actor. If you do decide to sign your zone data, there are a number of decisions to make. We will cover this in the next post.
Now let us consider the recursion side of DNS.
This is where your DNS will go ask other DNS servers for info that it doesn’t have cached. This should be simple right? Well, yes and no. It depends on your specific needs and other infrastructure configuration like firewalls and the like. If we consider a popular firewall policy that allows just about anything out, then there is a huge issue here with malware like DNSChanger. This would have clients send queries outside your approved infrastructure that may return incorrect data and allow an attacker to hijack a domain your users visit for things like banking, logistics, supply chain, etc. The picture gets pretty bleak when any of these are compromised. It is best to lock the firewall policies to only allow clients to use DNS to your recursive resolver IPs in your network.
On the DNS server config, the first thing is to not be an open resolver; you will become part of amplification DDoS networks if you do, and nobody wants that. You should apply an ACL to recursion to allow only your networks to do recursive queries. Notice that this is a member or grid level setting.
You should explicitly set the recursion property to enable at the view level. This will reduce the complexity of the configuration which also helps when you are troubleshooting at 3 AM.
That isn’t to say that the spoofed reply can’t be done when you use your approved infrastructure. It just becomes harder, and you can employ some mitigating features like DNSSEC and/or Recursive Resolver Provider. Using a recursive service shields your DNS servers from getting those spoofed replies directly, and your provider should be trashing those bad replies before they ever get to your recursive layer. If the provider is attacked, you can easily do your own recursion with a simple config change or use forward first as opposed to forward only.
In part 2 of this post, we will cover some more advanced topics like DNSSEC, Responsive Policy Zones (RPZ) and Response Rate Limiting (RRL). Stay tuned.