Secure DNS deployment guide: 15 best practices for authoritative services

Earlier this year, in March 2026, NIST published SP 800-81r3, their guide for secure DNS deployment. This was the second revision of this document (first published 13 years prior) and covers roughly three segments:

1. using DNS as part of network architecture
2. secure DNS consumption
3. Security of authoritative DNS servers.

If you haven't already, we highly recommend reading our summary of it to get up to speed. That said, this guide will focus on the last segment, security of authoritative DNS servers. In some ways, it continues where NIST left off, and, having spent more than a decade building products focused on DNS security, we wanted to provide additional detail in the form of easy-to-follow best practices for security of authoritative DNS servers.

This is the guide everyone needs to read to inform themselves about the key threats, determine which apply to them, and decide on mitigation strategies that best work for them. Don't worry, it's short!

If your audience is the general public, it’s best not to host your own authoritative DNS servers for a couple of reasons. First, it's not a small job. To start, you need to support a widely distributed user base, which requires deploying to multiple servers worldwide using Anycast so they all appear to be the same IP address. From there, you need to account for resilience, and you'll ideally want at least two rungs of servers across two independent networks. Then you have to worry about keeping them up and in sync. And on top of all that, worry about denial-of-service attacks. This list goes on, but you get the idea. It really isn't a small job.

Second, many high-grade managed DNS providers are available at a very reasonable cost. Hosting your own DNS gives you no unique advantage, costs you more, and isn’t done as well as the major providers. You are much better off spending your time and resources on other endeavors. In fact, if you want a very robust DNS presence, you will likely consider using two managed providers to stay online if one goes down.

This advice doesn't necessarily apply if you're deploying an authoritative DNS server for a private audience. That's much less work; you'll want to keep your data private anyway, and you can deploy very close to your users.

When you outsource your DNS needs to a third party, the usual approach is for them to maintain your authoritative data, which you update via a proprietary API. This is usually not a problem if you're starting afresh, but you might already have a DNS server that serves as your source of truth. Or perhaps it's already embedded in your organization with workflows you don't want to change.

It's absolutely fine to retain control of your primary, but you generally don't want to expose it on the public internet. Denial-of-service attacks are common, and attackers usually target the weakest point. If they find where your primary lives, it's likely to be attacked first.

You have options here. First, you can keep it online, but without advertising the name or IP address. Or, you can deploy with a firewall that allows access from your DNS provider's networks, but not from the public internet.

In this setup, your primary is your control plane, while your managed DNS providers run the query (data) plane.

This one goes without saying, but it's still worth discussing: mixing authoritative and recursive functionality is never a good idea. Although they both look like DNS servers from a distance, their jobs are very different. Except in trivial situations, recursive functionality is more demanding and can negatively impact the authoritative component.

A primary nameserver will normally only communicate with its secondaries. It has a simple job: to hold the master domain information and distribute it to the servers responsible for communicating with the public. In contrast, recursive servers have to serve a wide audience (often the public, which is exactly the opposite of what you want for an authoritative DNS server), chase any other DNS server on the internet, operate a cache, and so on.

By definition, authoritative servers contain public information, but that doesn't mean it has to be served in bulk to anyone who asks. Obscurity continues to serve a purpose. Zone transfers are a mechanism designed to propagate updates from primaries to secondaries, but a common finding is that they're available to everyone. In practice, it's best to retain this information on a need-to-know basis.

If you can, use network access controls and authentication to ensure the zone information doesn't fall into the wrong hands. The usual approach is to use TSIG authentication, which uses fast symmetric algorithms. If you need to authenticate a large number of parties, there is also SIG(0) that uses public cryptography, but it requires more effort to deploy and maintain.

Some DNS servers advertise their version numbers. This is another thing to check and disable.

A common tactic used by attackers is to target your management interfaces. If you're hiding your primary, keeping it away from the public internet will eliminate a significant attack vector.

If your authoritative data is with a managed DNS provider, use all available means to protect the management interfaces and API endpoints. Use two-factor authentication at a minimum, and also consider restricting what IP addresses can be used for access.

For many small companies, DNS zone configuration doesn't change that often and can be maintained as static configuration. Traditionally, dynamic DNS updates (e.g., RFC 2136) have been reserved for larger companies with complex environments. However, automated domain validation for X.509 certificate issuance via the ACME protocol became very popular, and one method is via DNS change.

Allowing dynamic DNS updates conflicts with your ability to lock down your primary nameserver and keep it secure. There are two aspects to consider:

• Remote endpoints have to connect to where your data lives
• You have to ensure that each entity is only allowed to change a narrow set of data, not everything

Your managed DNS provider may have a good solution for this in their APIs, but it'll still require resources to architect and manage. If hosting your own nameserver, consider using a hardened proxy rather than exposing your primary on the internet.

As an alternative, some vendors offer ACME validation services that rely on a one-time CNAME record configuration from your domain to a third-party endpoint. After that, they can manage the ACME validation for you. This helps by avoiding dynamic DNS updates, but on the other hand, your certificate validation now depends on a third party.

Version control is your friend. While it is most important that your zones contain and distribute accurate information, knowing when changes occurred and why helps you determine whether the information is indeed correct. In fact, distributing your DNS configuration to the world is not a significant challenge today, but ensuring your information stays correct actually is.

If your DNS configuration is in the form of zone files, put them under version control, such as Git. Protect the main branch and use pull-request workflows to document and validate changes as they happen. DNSControl and octoDNS are two popular open source tools that support this type of workflow.

The information you put in your DNS configuration is there for a purpose and has to be distributed to those who need it. Accept that everything you put in your zones is public information. Don't put in anything you don't want found out, because it will inevitably come out. Periodically review what's advertised in your zone files and check whether any parts can be removed.

Here's a brief overview of the common reconnaissance techniques:

• Zone transfers. If zone transfers are enabled, they're the most efficient way to get the entire zone file. As already discussed, though, zone transfers should be disabled by default and enabled only where they're really needed.
• Passive DNS services. Historically, DNS never protected traffic in transit. Because the data in those UDP packets contains a lot of useful information (e.g., for profiling), an entire passive DNS monitoring industry sprang up. These companies deploy probes all around the world, at the busiest junctions, and record everything they can. The data is then made available for a fee to anyone who can pay. Statistically speaking, some of your more obscure subdomains may not be observed, but the popular ones definitely will.
• Certificate Transparency. Certificate Transparency (CT) is a system that monitors issuance of all public certificates. Because certificates include domains and subdomains, they leak information that was previously often private. Now, information about even obscure subdomains becomes public knowledge once a single certificate is issued. Wildcards, if used safely, can help somewhat, but unfortunately, sharing certificates among unrelated services increases the "blast radius" of a compromise or expiration.
• Brute forcing of resource records. With only a small number of main resource records, brute-forcing them is very easy and produces little noise after a subdomain is discovered.
• DNSSEC information leakage. When DNSSEC was originally designed, the main approach it took was to pre-sign all data, then avoid any cryptographic operations at run-time. This created a problem when responding to arbitrary non-existing domains. Dynamic signing was considered to be too costly. Two solutions were NSEC and NSEC3 records, which avoided dynamic signing. However, their design made it possible to "tree-walk" (fully discover) any DNSSEC-enabled zone. Modern solutions for this problem are known as "White Lies" (RFC 4470) and, more recently, "Black Lies" (RFC 9824).
• DNS domain enumeration. If all else fails, attackers can always rely on the "good old" brute force enumeration. Armed with dictionaries containing the most common DNS labels (often customized based on what's already known about your estate), they'll just try everything, often at speed. These attacks tend to be very noisy and unsophisticated; good monitoring should be able to catch it because they generate a large number of NXDOMAIN responses.

As already discussed, everything you put into your authoritative DNS zones will become public, one way or another. You can't remove what you really need, but be careful about oversharing. Companies often use a domain name for both public and private needs; in the latter case, their authoritative DNS will contain internal information.

If you're starting from scratch, consider using separate domain names for public and private activities. If you're already sharing a domain name, consider a split-zone DNS deployment, where the public side has only what's truly public, and you distribute private information via a separate infrastructure that only your internal users can access.

For information hiding, the best approach is to use a private PKI for your internal certificates. There is a non-trivial cost associated with that, consisting of the effort and expense of maintaining a private CA and the need to embed its root certificates on all client devices.

Initially a simple service that mostly delivered information about IP addresses (A records), DNS grew increasingly complex over time. Today, it has quite a few moving pieces and failure modes. Not only will there be multiple servers (primary and secondary), but they will also be distributed worldwide. They have to operate over IPv4, IPv6, and over UDP and TCP. At scale, problems arise all the time, and the best way to detect them is through active monitoring.

DNS server query logs are often forgotten, but if you're hosting your own servers, they should definitely be monitored and stored alongside all other logs. If you're following these best practices, your primary nameserver logs will be quite slim. Anything appearing there will indicate a broken control.

By default, the entire domain spaces of your authoritative zones are under your direct control. DNS is naturally distributed, with pointers not only to other places you control, but also to third parties. This is most commonly done via CNAME records, subzone delegation, and sometimes, rarely, even via DNAME records.

These delegations are typically added so that the third party can provide a service of one kind or another, but it should be understood that each delegation introduces an element of risk. Thus, they should be tracked and monitored as part of your risk management. Involve your application security team, as they can assess whether delegated domains can affect the security of parent or sibling domains. Inform your PKI monitoring, because third parties may be issuing certificates on your behalf from a set of CAs different from yours.

Your monitoring platform should ideally provide a complete inventory of third party delegations. Annotate them with purpose and ownership, and, if possible, set an expiration date. Do include in this list service delegations to domains that don't belong to you.

The third-party delegations we discussed in the previous best practice carry risk when they're active, but sometimes carry even more when they stop working. When that happens, they may be taken over by a malicious third party.

The most common reasons this occurs:

• A subscription to a third-party service is purchased, with a CNAME added to point to the vendor's infrastructure. Some time later, the subscription is canceled, but the CNAME remains in place. If the destination of the CNAME is also deleted, that's easy because the DNS resource record is then broken. However, more often than not, these CNAMEs point to a generic destination (i.e., one destination for all customers), leading to a dangling service that is much harder to detect.
• A new service is configured in the cloud, identified by one or more IP addresses. DNS records are added with A and AAAA records. Some time later, the service is shut down, but the DNS records remain. The cloud provider now assigns the now-defunct IP addresses to its other tenants.

These are two of the most common problems that arise, but DNS is inherently full of ways to point from one place to another. Virtually every DNS resource record (RR) can cause a problem of this type: A, AAAA, CNAME, NS, SOA, MX, CAA, SRV, TXT, HTTPS… you name it.

The root problem is that once a pointer is configured, there is no way to keep it in sync with its destination. Comprehensive and continuous monitoring of the entire DNS surface is the only way to catch these problems early, and before they can be exploited by malicious actors.

Your adversaries will attack you in any way they can. Sometimes, if they can't abuse your domain names directly (e.g., by exploiting a dangling record), they will register domain names that could, in the eyes of your employees and customers alike, pass as yours.

You can be alerted to these similar domain names via a third-party service, such as Red Sift Brand Trust. Discovery is achieved by monitoring the entire inventory of the world's domain names, alongside a variety of other techniques.

Don't release or forget to renew domain names that were once in use. If you do, they're likely to be re-registered and possibly used against you. After all, they used to belong to you, and they're likely to still have some of your implicit reputation.

In addition, domain ownership is sometimes used to create trust connections with third parties. If a domain name is dropped, whoever gets it will inherit the existing trust connections.

DNSSEC remains a divisive topic, and you may have noticed that we didn't include DNSSEC in our best practices. The thing is, we’re torn. On the one hand, DNSSEC provides functionality not available elsewhere: cryptographic integrity of authoritative DNS resolution. (For an example of why this is important, take a look at this blog post, which discusses how it improves the security of Web PKI.)

On the other hand, adoption remains very low. DNSSEC is difficult to run, and the tooling is still immature. Most companies avoid DNSSEC unless it's automated by their hosting platform, even though security suffers.

To make matters worse, the looming threat of cryptographically relevant quantum computers will mean that DNSSEC will have to change the underlying cryptographic algorithms, but it's still not clear what the changes will look like and even whether UDP will continue to serve as the main transport mechanism due to the much larger sizes of post-quantum signatures.

As a summary, we think that DNSSEC serves a very important purpose, but we couldn't classify it as a best practice because it hasn't been universally accepted as such.

If a dangling DNS record or a dangling service is exploited, the resulting fallout can be very uncomfortable. However, there is a possible mitigation that relies on the fact that modern browsers require valid X.509 certificates. If we could prevent attackers from obtaining a valid certificate, their exploitation attempts might fail.

By default, if you control an IP address that is pointed to by a DNS domain, you can obtain a certificate for it. But it doesn't have to be that way, because domain owners can publish policies that guide domain validation. The technology for this is called Certification Authority Authorization (CAA), and it has to be observed by all public CAs.

In the context of dangling DNS, you have a couple of options with CAA: 1) you could centralize certificate issuance for the entire domain name, completely preventing individual servers from getting certificates directly; or 2) you could enforce that, for every given domain, there is a specific ACME account that has to be used.

Red Sift's Attack Surface Monitoring (ASM) platform, formerly Hardenize, was the world's first platform for deep continuous discovery and monitoring, designed for companies that want to monitor their own internet presence. Within ASM, the DNS component of this product fully implements the monitoring aspects outlined in this document, including monitoring the health of authoritative services, connections to third parties, and detecting dangling DNS records and services.

Red Sift's Brand Trust offering stops lookalike domain attacks before they damage your brand. It detects, monitors, and takes down malicious lookalikes with AI-powered domain and brand protection.

• RFC 9499: DNS Terminology
• NIST SP 800-81 Rev. 3: Secure DNS Deployment Guide
• Red Sift: NIST’s secure DNS deployment guide: best practices
• IANA: Technical requirements for authoritative name servers