Name Server Record (NS)
Defined in RFC 1035. NS RRs appear in two places. Within the zone file, in which case they are authoritative records for the zone's name servers. At the point of delegation for either a subdomain of the zone or in the zone's parent in which case they are non-authoritative. Thus, the zone example.com's parent zone (.com) will contain non-authoritative NS RRs for the zone example.com at its point of delegation (point of delegation is the term frequently used to describe the NS RRs in the parent that delegate a zone of subdomain) and subdomain.example.com will have non-authoritative NS RRS in the zone example.com at its point of delegation. NS RRs at a point of delegation are never authoritative only NS RRs within the zone are regarded as authoritative. While this may look a fairly trivial point, is has important implications for DNSSEC. This relationship is shown in the Diagram below.
NS Parent - Child Delegation
NS RRs are required because DNS queries respond with an authority section listing all the authoritative name servers and for queries to sub-domains (including the zone's parent) where they are required to allow referral to take place.
NS RRs are part of what is sometimes called the zone's infrastructure records and are defined at the zone apex (exceptionally at a point of delegation for subdomains). Infrastructure RRs (which include SOA, NS and MX RRs) are unique in that they return other names not addresses, as such they should be stable and to mimimize DNS access can and should have very long TTLs (days and weeks).
Format
owner-name ttl class rr target-name
example.com. IN NS ns1.example.com.
NS records appear either at the zone's apex or the point of delegation as discussed. By convention a zone's name servers are defined immediately after the SOA record but they can be defined anywhere convenient in the zone file. The requirement is that at least two name servers are defined for each public domain (private domains may use only one if required, many public domains provide more than two name servers) - there will always be at least two NS RRs in each public zone file. There is no requirement that any name servers are within the domain for which they are authoritative. Thus, a domain may have zero or more (including all) its name servers within the zone (in-zone) or zero or more (including all) of its name servers in other domains (out-of-zone). If the name server does lie within the domain (in-zone) it must have a corresponding A/AAAA RR in the zone file. The A/AAAA RRs which define name servers that lie within the domain are frequently called glue records. Strictly glue records are essential only with referrals which occur only at a point of delegation which may be in the zone's parent or in this zone where a subdomain is being delegated. In practice glue records are used for two purposes:
To speed up queries - and consequently reduce DNS load - by providing the name and IP addresses (the glue) for all authoritative name servers, both within and external to the domain name being queried. The root and TLD servers for example provide this information in all referrals. In the case of the TLD servers the glue data is not obtained from the domain zone file but from the Registrar when the domain name is registered.
To break the query deadlock for referrals which return name servers within the domain being queried. Assume a query for a domain, say the A RR for www.example.com, returns a referral containing the name but not the IP address of a name server, say ns1.example.com, which lies within the domain example.com. Since the IP address of the name server is not known this will naturally result in a query for the A RR of ns1.example.com which will return, again, a referral with the name but not the IP of ns1.example.com which result in another query ..... and so on in an endless loop! When the glue address record is provided this problem does not occur.
When dealing with a user domain zone file the A RRs for the name servers that lie within the domain are not glue records, they are conventional A RRs, but if a sub-domain is being delegated from the user domain zone file the AA RRs for the sub-domain name servers that lie inside the sub-domain are glue records and are absolutely essential. This is illustrated below in the example fragments. The name server defined in the SOA record, the so called primary master, requires a corresponding NS RR.
Note: The A or (IP Address) records are provided in the Additional Section of the query response. Strictly, only A/AAAA RRs for the glue records need be returned in this section but in practice both in-zone and out-of-zone RR are provided but this can be controlled by the minimal-responses statement in BIND.
The owner-name field can be any of:
- A Fully Qualified Domain Name (FQDN) e.g. example.com. (ends with a dot)
- An unqualfied name (does not end with a dot)
- An '@' (substitutes the current value of $ORIGIN)
- a 'space' or 'blank' (tab) - this is replaced with the previous value of the name field. If no name has been previously defined this may result in the value of $ORIGIN.
Examples & Variations
; zone fragment for example.com
; name servers in the same zone
$TTL 2d; zone TTL default = 2 days or 172800 seconds
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 ; serial number
3h ; refresh = 3 hours
15M ; update retry = 15 minutes
3W12h ; expiry = 3 weeks + 12 hours
2h20M ; minimum = 2 hours + 20 minutes
)
IN NS ns1 ; unqualified name
; the line above is functionally the same as the line below
; example.com. IN NS ns1.example.com.
; at least two name servers must be defined
IN NS ns2
; the in-zone name server(s) have an A record
ns1 IN A 192.168.0.3
ns2 IN A 192.168.0.3
This fragment shows where neither of two name servers lie within the domain:
; zone fragment for example.com
; name servers not in the zone
$TTL 2d; zone TTL default = 2 days or 172800 seconds
$ORIGIN example.com.
example.com. IN SOA ns1.example.net. hostmaster.example.com. (
2003080800 ; serial number
3h ; refresh = 3 hours
15M ; update retry = 15 minutes
3W12h ; expiry = 3 weeks + 12 hours
2h20M ; minimum = 2 hours + 20 minutes
)
; name servers not in zone - no A records required
IN NS ns1.example.net.
IN NS ns1.example.org.
The following fragments show the delegation of sub-domain and the use of the glue records:
; zone fragment for example.com
; name servers in the same zone
$TTL 2d ; default TTL is 2 days
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 ; serial number
2h ; refresh = 2 hours
15M ; update retry = 15 minutes
3W12h ; expiry = 3 weeks + 12 hours
2h20M ; minimum = 2 hours + 20 minutes
)
; main domain name servers
IN NS ns1.example.com.
IN NS ns2.example.com.
; mail domain mail servers
IN MX mail.example.com.
; A records for name servers above
ns1 IN A 192.168.0.3
ns2 IN A 192.168.0.4
; A record for mail server above
mail IN A 192.168.0.5
....
; sub-domain definitions
$ORIGIN us.example.com.
; we define two name servers for the sub-domain
@ IN NS ns3.us.example.com.
; the record above could have been written without the $ORIGIN as
; us.example.com. IN NS ns3.us.example.com.
; OR as simply
; IN NS ns3
; the next name server points to ns1 above
IN NS ns1.example.com.
; address record for sub-domain name server - essential glue record
ns3 IN A 10.10.0.24 ; 'glue' record
; the record above could have been written as
; ns3.us.example.com. IN A 10.10.0.24 if it's less confusing
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
