The NS record

Like a number of other DNS record types, the original DNS specifications (RFC 1034 and 1035) introduced this record type in 1987. Along with the Start of Authority (SOA) record type, NS records are integral to the proper functioning of the DNS.

The NS record has only one data field besides the usual DNS TTL field: the fully qualified DNS name of a name server that is authoritative for the domain.

Each NS record specifies the name of one authoritative name server for a particular DNS zone. To specify a list of name servers that are authoritative for a particular DNS zone, a set of NS records is published, where each NS record in the set specifies one authoritative name server.

What is an authoritative name server?

A name server is a server running DNS software listening for DNS requests on port 53. When this server receives a DNS request, it consults its local database of DNS data. If it finds an answer in its local database, it responds with the requested data. If it does not find the data in its local database, then depending on the role and configuration of the name server, it will either return an error or consult other name servers to determine the answer.

An authoritative name server is a name server that has been delegated a DNS zone, and hosts a complete copy of that particular DNS zone. So, an authoritative name server for the zone example.org is a server listening for DNS requests on port 53 whose local DNS database contains a complete copy of the zone example.org.

The master authoritative name server for a zone will often host a copy of the zone served from a standard DNS data file. The zone must have at least one other authoritative name server and will generally have three more. There can be only one primary (also sometimes called master) server for a DNS zone, so the other authoritative DNS servers may use DNS zone transfer (see RFC 5936 and RFC 1995) to copy the zone data.

Name servers that use zone transfer to retrieve a copy of a zone are called secondary servers. However, and somewhat confusingly, secondary servers are authoritative. They hold a copy of the DNS zone, but that copy is just as good from the perspective of authority as the master copy of the zone served by the primary server.

So, if a zone has four authoritative names servers, it may have one primary name servers and three secondary name servers. This pattern is common, but it is not always optimal. The master server might be hidden to protect it from attack, and the four authoritative name servers advertised in the NS records for the zone might all be secondary servers.

Alternatively, a proprietary replication protocol may be used instead of zone transfer. This is commonly seen in the large cloud scale DNS providers.

At the end of the day, it does not matter how DNS data is replicated among the authoritative name servers for the zone. All that matters is that each of the authoritative name servers has a complete copy of the DNS zone and is ready and willing to respond to DNS requests for all the DNS names contained within the zone. See also RFC 8499 for a more technical definition of "authoritative server" and a number of related DNS terms.

NS records at the zone root

Every zone in the DNS must have exactly one SOA record and two or more NS records at the root of the zone. These SOA and NS records are mandatory and together signify the existence of a zone in the DNS. The zone root for an example zone might include records such as:

example.org. 86400 SOA  ns1.example.org. admin.example.org. (...)
example.org. 86400 NS   ns1.example.org.
example.org. 86400 NS   ns2.example.org.
example.org. 86400 NS   ns3.example.org.
example.org. 86400 NS   ns4.example.org.

In this example, we have the SOA record and four NS records at the root of the DNS zone. It is typical to have four NS records for a zone. Most DNS cloud providers today automatically provide four name server records but as few as two NS records is legal.

The requirement to have a minimum of two NS records ensures a basic level of redundancy and is specified by RFC 1034 section 4.1 and also by RFC 1912 section 2.8. A zone may have more than four NS records but this is typically unnecessary.

The time-to-live (TTL) value for NS records should be relatively long. One to two days is typical. Shorter TTL values for NS records are not recommended. As discussed in our article on TTL selection in the DNS, a small outage in the DNS lasting longer than the TTL of the NS records could cause a total outage for all records in the zone.

NS records in delegations

As explained in our article on zone delegation in the DNS, NS records exist at the root of every DNS zone and also at the same name in the parent DNS zone. To resolve a DNS name, a DNS resolver must follow a chain, or trail, of NS records. This begins at the DNS root zone and extends downwards through child zones. That would be the root zone "." followed by org. and then example.org. in this case.

By using NS records to follow the trail starting at the root zone, a DNS resolver will eventually reach a name server that is authoritative for the zone. The authoritative server will provide an answer to the original DNS query.

The IP addresses of name servers

You may have noticed that each NS record contains the DNS host name of a single authoritative name server, for example ns4.example.org. This is not sufficient for a DNS resolver to contact the name server. For a DNS resolver to contact a name server, it must know the IP address or addresses of the name server.

DNS gets a bit recursive here. The DNS itself is used to look up the IP addresses of name servers, which are then used by the DNS to contact other name servers in the DNS.

So, for example, if a recursive DNS resolver needs to answer a query for a name in example.org, it will have to perform additional DNS queries to determine the IP addresses of ns1.example.org, ns2.example.org, etc. The DNS is designed to minimize these queries by allowing them to be included as additional data in a delegation response. Caching is also used to minimize these queries.

However, it is vital that the DNS can resolve the host names of each of the authoritative name servers for every zone. If this is not the case, then that zone will likely be unresolvable. This will lead to an outage for any client attempting to use a web server or other resource for the zone.

NS record ordering and preference

The operator of a DNS zone cannot specify that one name server is the master and should be consulted first, for example. This means that the zone operator must ensure that all name servers for the zone have identical zone data and that replication of changes between the name servers occurs quickly and reliably.

DNS resolvers will attempt resolution against more than one available name server for a zone if necessary. So for example, if ns3.example.org is temporarily offline for maintenance, DNS resolvers who attempt to query it during the period of outage will retry the query against another of the name servers for the zone.

Anycast for name server IP addresses

It is common for the provider of any service on the Internet to want to ensure the fastest possible response to their clients. Nobody wants a slow, laggy web page! DNS is required for HTTP and virtually every protocol on the Internet, so fast DNS resolution is critical.

One way in which DNS resolution can be sped up is to have the authoritative DNS servers very close to customers. To this end, some cloud DNS providers have hundreds of datacenters around the world, so that virtually every person on Earth can get a fast DNS response.

It would be very difficult indeed to have hundreds of IP addresses for each of the name servers for a zone, so instead Anycast is used to very elegantly simplify this issue. With Anycast, each name server has only one or two IP addresses (perhaps one IPv4 address and one IPv6 address).

When a query is sent from anywhere in the world to one of these IP addresses, Anycast ensures that it is automatically routed to the nearest data center, and hence the client experiences the fastest possible DNS resolution.

Anycast is itself a very complex subject. It is largely built on the Border Gateway Protocol (BGP). Due to its complexity, and also due to malicious attacks, many high-profile outages in the past have involved BGP issues. Anycast is still a very powerful tool to improve DNS performance and is used by most major DNS providers today.

Dnsperf.com is a good resource to compare the relative speeds of the major authoritative DNS providers.

Common issues

Since DNS resolution depends on the chain of NS records from the DNS root zone down to every zone in the DNS, NS record configuration is critical.

Lame delegations, where one or more NS records have become incorrect, are a common reason for DNS resolution failure. Maintaining the NS records in both the parent and child zones can at times be a difficult task. DNS zone operators should exercise extreme care when making any changes to their NS records, since the change must be made at both the root of the zone and in the delegation in the parent zone. An error in NS record configuration in either zone can result in an outage.

Another common problem is when DNS changes do not replicate between name servers. Either due to human error or system failure, a change made on one name server might not replicate to the other name servers. In this scenario, some clients will see the change and some will not, depending on which name server is consulted. This will lead to sporadic outages for some clients.

RFC 1912 section 2.8 has a good discussion of potential NS record issues.

Finding the NS records for a zone

The NS records of a zone can be queried with the dig or nslookup command line tools. To find the NS record for example.org, use this command:

dig NS example.org

On operating systems that support nslookup, you can use the following:

nslookup -type=ns example.org

You can also check the NS records of any domain name in our name server lookup tool, or by entering it here: