There are two types of NS records: authoritative and referral. An authoritative NS record authorizes a name server to resolve queries. A referral NS record diverts queries to the authoritative name server. Each authoritative name server needs both types of NS records. It requires an authoritative NS record in the domain's zone file for which it resolves queries and a referral NS record in the parent domain's zone file that forwards queries to this domain.
An NS record only lists an authoritative name server. It does not map the authoritative name server with the IP address. Because of this, if the NS server is available within the domain, we need to add a host (A) record for the authoritative name server.
Creating an authoritative name server record
Let's take an example. Suppose you want to configure a name server ns1 as the authoritative name server for the domain xyz.example.com. In this case, you need to create an authoritative NS record in the zone file of xyz.example.com and a referral NS record in the zone file of example.com.
The following image shows the zone file of the xyz.example.com domain.
An NS record uses the following syntax.
domain-name TTL class resource-type authoritative-name-server
Let us understand the above syntax field-by-field.
This tutorial is the fifth part of the tutorial series "DNS zone files Explained with Examples.". Each tutorial of this series explains a specific aspect of the zone file. Other tutorials of the series are the following.
DNS zone file Format, Configuration, and Directives
The TTL and ORIGIN directives in the zone file
Types of resources records in zone files
The SOA Record Explained in the DNS zone file
The MX record in a zone file explained
The domain-name Field
This field defines the domain for which it configures the authoritative name server. If we leave this field empty, DNS uses the previous record's name field's value in this field. Usually, NS records are placed just after the SOA record. So, if we keep this field empty, DNS picks the SOA record's name field's value as the default value for this field.
In the SOA record, administrators usually use a single character @ in the name field. DNS replaces the character @ with the value of the $ORIGIN directive. With this setup, the SOA record automatically receives the domain name from the $ORIGIN directive, and NS records receive it from the SOA record.
In our example, we configured the domain name xyz.example.com. in the $ORIGIN directive. From this directive, DNS will automatically configure the domain-name field of the SOA record and NS records.
The TTL Field
This field defines the maximum time resolver systems can cache this record. If we leave this field blank, DNS uses the default value of the $TTL directive.
The class Field
A record can belong to three classes IN, CH, and HS. Currently, only the IN class is in use. It shows the record belongs to the Internet class.
The resource-type Field
This field defines the record type. The most important record types are SOA (Start of Authority), NS (Name Server), MX (Mail server), A (host or service), and CNAME (Alias). To define a name server, we use the NS record type here.
The authoritative-name-server Field
This field defines the authoritative name server for the domain we configure in the domain-name field. In our example, we configured the name server ns1.xyz.example.com as the authoritative name server for the domain xyz.example.com (automatically configured from the SOA record in the domain-name field).
The host record
If the authoritative name server is available within the domain, we need to create a host record for it. A host record maps a service or a host to an IP address.
It uses the following syntax.
resource-name TTL class resource-type IP address
The resource-name field defines the name of the service or host which you want to map with an IP address.
The TTL and class fields have the same meaning as the TTL and class fields of an NS record.
Resource type A belongs to an IPv4 address. For an IPv6 address, the resource type is AAAA.
The IP address field defines the IP address of the resource configured in the resource-name field.
Creating a referral name server record
Resolver systems can access an authoritative name server through referral name servers. DNS system organizes authoritative name servers in a hierarchy. Each authoritative name server resolves queries for its domain and provides a referral for the child domain. When an authoritative name server receives a query, it checks whether the query belongs to it or its child domain. If the query does not belong to it or its child, it returns an error indicating the requested host or service is not available. If the query belongs to it, it resolves the query. If the query belongs to its child domain, it provides a referral to the child domain's name server. It only provides referrals for its child domains. It knows nothing about its grandchild domains. If its child domain has child domains, the child domain will be responsible for providing referrals to its child domains.
Let's take an example to understand this process.
Suppose a user wants to access the ftp server available within the xyz.example.com domain. It sends a query to the resolver system to find the IP address of ftp.exyz.example.com. By default, a resolver system only knows the IP address of top-level name servers. In this case, the top-level name server is the com name server. It sends a query to the com name server.
The com name server provides a referral to the example.com name server. The example.com name server provides a referral to the xyz.example.com name server. The xyz.example.com name server provides the IP address of the ftp.xyz.example.com server.
The following image shows this process.
Now, let's suppose the administrator forget to create a referral for the xyz.example.com name server on the example.com name server. In this situation, the resolver system will not reach the authoritative name server, and the query for ftp.xyz.example.com will end with an error.
The following image shows this process.
To create a referral for an authoritative name server, you need to add an NS record in the parent domain's zone file. In the preceding example, we need to add an NS record for the ns1.xyz.example.com name server in the example.com domain's zone file.
To add a referral NS record, we use the same syntax. But in the referral NS record, we use the child domain's name in the domain-name field. We can either use the child domain's FQDN name or configure the $ORIGIN directive again to use the relative name in this field.
The following image shows how to add a referral NS record for the ns1.xyz.example.com name server in the zone file of the example.com name server. It uses the FQDN method to configure the child domain's name in the domain-name field.
If we use the $ORIGIN directive to configure the name of the child domain, the file will look like this.
Glue NS records
Since referral NS records stick the child domain's name servers with the parent domain's name server, they are also known as glue NS records. A glue record must include the name and IP address of the child domain's name server.
Resolver systems can access a name server only if they know its IP address. They can learn it only from its parent domain's name server.
If you create a glue record without the host (A) record for the child domain's name server, the resolver systems cannot access the child domain's name server.
Resolver systems ask a name server to resolve a query or provide a referral. If a name server provides a referral, resolver systems check whether the referral includes the IP address and name or only the name. If it includes both, they send the same query to the offered IP address. If it includes only the name, they first resolve the name into the IP address and then forward the same query to that IP address.
If the referred domain name server is the child of the name server which provides the referral, resolver systems fail to get the referred domain name server's IP address. It creates an infinite loop of queries between resolver systems and the name server.
The following image shows what will happen when the administrator forgets to add the IP address in the glue record of xyz.example.com. in the zone file of example.com.
This situation only occurs when the referred name server is available within the domain. If the referred name server is available in another domain, resolver systems resolve it from the name server of that domain.
The following image shows this situation. In this situation, the example.com name server provides a referral for an external name server without an IP address. Since it is an external name server, the resolver system resolves its name from the name server of that domain.
Creating a backup name server
DNS is an essential service. You should configure at least two name servers for each domain. You should configure the primary name server within the domain. You should configure the secondary name server outside the domain in a different geographical location. This setup allows resolver systems to access resources even if the primary name server fails.
We use the same syntax to add an NS record for the backup name server. If the backup name server is available within the domain, we also need to add a host (A) record for it. If the backup name server is available outside the domain, we don't need to add a host (A) record for it.
The following image shows how to add NS records for two backup name servers in the zone file of xyz.example.com. domain.
Lame delegation
As I mentioned earlier, In a DNS system, only authoritative name servers can resolve queries. Because of this, we also need to configure the backup name server as the authoritative name server for the domain.
If we don't do this, a situation called lame delegation occurs. A lame delegation occurs when an NS record points to a name server (configured in the authoritative-name-server field ) that does not answer authoritatively for the domain ( configured in the domain-name-field).
In the above example, we configured two backup name servers: ns2.xyz.example.com. and ns3.xyz.example.net. We need to configure both backup name servers as the authoritative name servers for the domain xyz.example.com.
To authorize that name server (ns2.xyz.example.com. or ns3.xyz.example.net.) to resolve queries for this domain (xyz.example.com), we need to create a zone file for this domain (xyz.example.com) on that name server (ns2.xyz.example.com. or ns3.xyz.example.net.) In that zone file, we need to add all records of this file. In simple words, we need to create a copy of this zone file on that name server.
To simplify this process, we can configure that name server (ns2.xyz.example.com. or ns3.xyz.example.net.) as the slave or client name server for this domain (xyz.example.com). A slave name server automatically fetches the zone file from the master name server and uses it to resolve queries if the master name server is not available.
A name server can act as a primary name server for one domain and a backup name server for another domain at the same time. This flexibility allows administrators to use existing name servers to configure backup name servers for other name servers. Let's take an example. Suppose we have two primary name servers ns1.example.com. and ns1.example.net. for the domains example.com and example.net. We can configure the ns1.example.com. name server as the backup name server for the ns1.example.net name server and the ns1.example.net name server as the backup name server for the ns1.example.com name server.
This setup allows us to configure backup name servers without adding any additional name servers to the network.