mail us  |  mail this page

contact us
training  | 
tech stuff  | 

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:

  1. 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.

  2. 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:

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.

Pro DNS and BIND by Ron Aitchison

Contents

tech info
guides home
dns articles
intro
contents
1 objectives
big picture
2 concepts
3 reverse map
4 dns types
quickstart
5 install bind
6 samples
reference
7 named.conf
8 zone records
operations
9 howtos
10 tools
11 trouble
programming
12 bind api's
security
13 dns security
bits & bytes
15 messages
resources
notes & tips
registration FAQ
dns resources
dns rfcs
change log

Creative Commons License
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 Firefox

Search

web zytrax.com

Share

share page via facebook tweet this page

Page

email us Send to a friend feature print this page Decrease font size Increase font size Display full width page

Resources

Systems

FreeBSD
NetBSD
OpenBSD
DragonFlyBSD
Linux.org
Debian Linux

Software

LibreOffice
OpenOffice
Mozilla
GitHub
GNU-Free SW Foundation
get-dns

Organizations

Open Source Initiative
Creative Commons

Misc.

Ibiblio - Library
Open Book Project
Open Directory
Wikipedia

Site

CSS Technology SPF Record Conformant Domain
Copyright © 1994 - 2017 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
Hosted by super.net.sg
web-master at zytrax
Page modified: August 02 2017.