Tips to Ensure DNS Security
The domain name service (DNS) performs a critical function on the Internet — it allows the translation of human-friendly domain names into machine-friendly IP addresses. Domain Name System services translate domain names into IP addresses, making it a critical service that can’t go down. DNS-based attacks are on the rise, and as such, organizations need to architect these services to be more secure.
At the same time, core infrastructure services such as DNS are critical choke points for the network. Without a solid DNS, Windows Active Directory will collapse. And for Internet browsing, user satisfaction depends upon speedy and reliable DNS.
Building a safe and solid DNS infrastructure doesn’t require a lot of resources, but it does take some planning and good design. There are a few simple steps that you can take to protect your DNS servers from attack:
Separate DNS Service from DNS Resolution
DNS service defines name-to-address mappings and advertises them locally or to the Internet, whereas DNS resolution navigates the Internet’s tree of name servers to look up those mappings. The most important step in reliable DNS design is to understand the difference between DNS service and resolution. Try to keep those functions separate, on separate servers.
Every network needs DNS resolution, and the best way to provide this is with a pair of small, dedicated virtual machines (VMs) that run nothing but a DNS resolver configuration. Aim for minimal configuration and customization to reduce the cost of maintaining these servers. And don’t tweak the configuration as servers are deployed, other than the bare minimum of network addressing and routing.
If you have multiple security zones within a building, such as Internet and guests versus internal users, you can drop pairs of DNS resolvers in each security zone. By building on simple and small resolver VMs, your support and licensing costs are minimal, and the organization gains automatic resistance from misbehaving clients and intentional denial of service (DoS) attacks.
Keep your DNS version current.
This is the single most important step that you can take. There are well-known vulnerabilities in older versions of the Berkeley Internet Name Domain (BIND) system and other DNS packages. Patches are available to eliminate these vulnerabilities, but they’re only effective if they’re installed! It’s essential that you stay on top of this issue. One way of keeping yourself informed is to monitor CERT advisories.
Deal with Active Directory
Active Directory presents a wrinkle because it works well only when workstations in a domain use the same server for both name server and name resolution.
Although IT managers can set domain workstations to point to a separate name resolver from the Active Directory DNS servers, this configuration makes many wary because it takes them out of the Microsoft comfort zone and away from the most standard configuration.
Deal with Active Directory DNS and domains by keeping a strict separation. Any names stored in Active Directory, such as workstation names and pointers to domain controllers, should be strictly maintained in the world of Active Directory DNS, and kept separate from other DNS names, whether public (such as your external web server) or private (such as internal web and SharePoint servers).
For example, if your organization’s main domain is example.com, make sure that all Active Directory servers are in a subdomain, such as ad.example.com or example.lcl, which never is seen outside of the trusted local network. Anything else should go into separate servers.
Users who are inside the network may need to use different names than when they’re at home or on the road, so it’s best to have a consistent set of names to reduce user confusion. For that reason, it’s a good idea to generally avoid using the .lcl domain for local domains because those names won’t work on the general Internet.
Separate Name Service as Much as Possible
As mentioned above, keep name service separate from name resolution. If you don’t make daily changes to your organizational DNS, you can migrate this entirely to a cloud-based service or to your own VMs running in a cloud data center.
Name Service must be Internet accessible because it serves names toward Internet clients. This raises questions of scalability and DoS resilience. Pushing that name service offsite to a large cloud provider is an easy way to address those issues at a low cost.
If you must have onsite DNS servers for local names, augment those with cloud servers. With a little work, you can create “shadow primary” servers that keep the authoritative information onsite and hidden from the Internet, but ensure they automatically update cloud servers for Internet service.
Pick the Right Platform
When choosing the right platform for your needs, there are multiple commercial DNS products to choose from. IT managers typically find they’ll need to use Microsoft DNS with Active Directory as a resolver and server; but for other activities, products from makers such as BlueCat Networks and Infoblox provide enterprise-class controls and ease of use. IT managers who want to go old-school with text file configuration can also find multiple open-source options, starting with the venerable ISC BIND and more than a dozen alternatives.
Select Multiple Views
Many organizations have a “split-brain” DNS service, which gives one set of results to users inside the network (such as private IP addresses) and a different set to users outside the network. It’s tempting to put those on separate servers, but this raises long-term support headaches as multiple servers have to be updated for every change in a name.