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 RR Delegation
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.
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: