5 Tips for Designing a Safer DNS

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. Follow these best practices to build a more secure and resilient DNS.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

A better strategy is to use a DNS server tool, such as ISC BIND, that offers multiple views. BIND can deliver one set of answers to inside users, while a separate set goes to external users. This reduces the number of databases that must be maintained, while offering a high level of security and scalability.