mail this page
products | company | support | training | contact us
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. 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 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.
NS RRs are required because DNS queries respond with an authority section listing all the authoritative name servers, for sub-domains or queries to the zones parent where they are required to allow referral to take place.
name ttl class rr name example.com. IN NS ns1.example.com.
By convention name servers are defined immediately after the SOA record but 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) - there will always be at least two NS RRs in each zone file. There is no requirement that any name servers are within the domain for which they are authoritative. If the name server does lie within the domain it should have a corresponding A record. The A RRs which define name server that lie within the domain are frequently called glue records. Strictly glue records are essential only with referrals which include name servers within the domain being queried. 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. 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! When the glue record is provided this problem does not occur.
When dealing with a SLD (Second Level Domain) zone file the A RRs for the name servers that lie within the domain are not strictly glue records, they are conventional A RRs, but if a sub-domain is defined in the SLD 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.
The name field can be any of:
; 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 fragments 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 shows 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. A 10.10.0.24 if it's less confusing
3 reverse map
4 dns types
5 install bind
8 dns records
12 bind api's
13 dns security
bits & bytes
notes & tips
This work is licensed under a Creative Commons License.
If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Mozilla