Black Friday Dedi Sale
00 Days
:
00 Hours
:
00 Mins
:
00 Secs

KNOWNHOST KNOWLEDGE BASE

Hosting Question? Find the Solution - Browse our Guides, Articles, and How-To's

Difference between parent and authoritative nameservers?

Category: Getting Started
Tags: # # # #

How DNS Works

Anyone that has ever configured their own custom/vanity nameservers will know that the nameservers must be set at both the server and at the registrar. Very few people really understand why. Understanding why means that you need to first understand a bit about how DNS works.

To revisit the process of configuring your own custom/vanity nameservers/hosts/hostnames (names for these nameservers can vary according to registrar), one must do the following:

  1. Create the glue records. This means that you must assign A records to ns1 and ns2 under the main domain at the registrar.
  2. Set these newly created nameservers as the nameservers to be used by the domain.
  3. Add the same A records for ns1 and ns2 in the DNS zone file for the main domain at the server.

Thus, you must have the same glue records set for the nameservers at the registrar and at the server. Not having the same IPs as glue records (A records for the nameservers) may result in an Authoritative vs Parent nameserver conflict error and cause the domain route requests correctly. The registrar will report the nameservers you’ve registered to the domain’s TLD nameservers, which will then provide the location of your DNS zone file via the glue records when queried so that records such as MX and A can be retreived as requested.

The process can be described as follows. There is a single Root Nameserver for all domains, and this is denoted by a single period. If you’ve every paid close attention to the nameservers in your server’s panel, often times you will see that they are followed by a period like so:

  ns1.domain.com.

That period is the very first nameserver to be queried when your browser sends a request for a domain to your ISP’s DNS recursors. First, the query requests to know what nameservers to query next depending on the domain’s TLD. A TLD is the last part of a domain name, e.g., ‘com’, ‘org’, ‘net’, etc., We can query the Root NS directly to get a listing of the 13 Parent Nameservers that currently exist.

  $ dig NS +short .
  a.root-servers.net.
  b.root-servers.net.
  c.root-servers.net.
  d.root-servers.net.
  e.root-servers.net.
  f.root-servers.net.
  g.root-servers.net.
  h.root-servers.net.
  i.root-servers.net.
  j.root-servers.net.
  k.root-servers.net.
  l.root-servers.net.
  m.root-servers.net.
  $

Let say that we are wanting to find the TLD nameservers for ‘.org’ domains. We could do so like so:

  $ dig +short org. NS
  c0.org.afilias-nst.info.
  d0.org.afilias-nst.org.
  a0.org.afilias-nst.info.
  a2.org.afilias-nst.info.
  b0.org.afilias-nst.org.
  b2.org.afilias-nst.org.
  $

To find the Parent Nameservers for ‘.com’ domains, we would do the following:

  $ dig +short com. NS
  e.gtld-servers.net.
  c.gtld-servers.net.
  h.gtld-servers.net.
  b.gtld-servers.net.
  d.gtld-servers.net.
  m.gtld-servers.net.
  k.gtld-servers.net.
  $

Once we have the Parent Nameservers, we can then query them for the Authoritative Nameservers for the domain like so (let’s use google.com as an example and query one of the ‘com’Authoritative nameservers returned above:

  $ dig @j.gtld-servers.net. google.com. NS

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @j.gtld-servers.net. google.com. NS
  ; (2 servers found)
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20211
  ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
  ;; WARNING: recursion requested but not available

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;google.com.			  IN	  NS

  ;; AUTHORITY SECTION:
  google.com.		  172800	IN	NS	ns2.google.com.
  google.com.		  172800	IN	NS	ns1.google.com.
  google.com.		  172800	IN	NS	ns3.google.com.
  google.com.		  172800	IN	NS	ns4.google.com.

  ;; ADDITIONAL SECTION:
  ns2.google.com.	  172800	IN	AAAA	2001:4860:4802:34::a
  ns2.google.com.	  172800	IN	A	216.239.34.10
  ns1.google.com.	  172800	IN	AAAA	2001:4860:4802:32::a
  ns1.google.com.	  172800	IN	A	216.239.32.10
  ns3.google.com.	  172800	IN	AAAA	2001:4860:4802:36::a
  ns3.google.com.	  172800	IN	A	216.239.36.10
  ns4.google.com.	  172800	IN	AAAA	2001:4860:4802:38::a
  ns4.google.com.	  172800	IN	A	216.239.38.10

  ;; Query time: 217 msec
  ;; SERVER: 192.48.79.30#53(192.48.79.30)
  ;; WHEN: Sun Jun 09 11:35:13 CDT 2019
  ;; MSG SIZE  rcvd: 287

  $

This information returned represents the Nameservers that were set for google.com at google.com’s domain registrar and the IPs shown is where the domain’s zone file should reside.

We can then query any one of these authoritative nameservers for any records that may exist on the DNS server at that location like so:

  $ dig txt +short google.com @ns1.google.com.
  "v=spf1 include:_spf.google.com ~all"
  "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"
  "globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="
  "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
  $

Our nameservers returned above should also be returned when we query the nameservers themselves:

  $ dig NS +short google.com @ns1.google.com.
  ns1.google.com.
  ns3.google.com.
  ns4.google.com.
  ns2.google.com.
  $

The glue records for these nameservers should also match:

  $ dig A +short ns1.google.com @ns1.google.com.
  216.239.32.10
  $

Now that we have followed the recursor to the Authoritative nameservers, querying those nameservers yields the IP address associated with the domain and we are able to load the domain from that IP Address via just the domain name. We can also send mail to the domain’s email accounts since we can also retrieve any MX records it may have set.

Working in hosting, we’ve encountered many issues relating to DNS. Often times, a client may have the same set of nameservers in the server and at the host, so all appears to be fine but the domain isn’t loading. This could be due to the glue records set at the host versus those set at the server being different.

Another issue could be when the client has changed the DNS recently and all TLD nameservers have yet to update with the new records, so results from different test locations are differing.

A simple script that can be used for testing for these types of discrepancies is below. It will do the following:

  1. Test the TLD Nameservers to print out the nameservers set at those, and this information should represent the nameservers and glue records set at the domain’s registrar.
  2. Test that the domain is resolving via Dig and provide the records that it is currently resolving to.
  3. If you provide the IP of the DNS server you expect the domain to be using (for example, if you’ve just migrated the domain and/or its DNS to a new server, it will query that server directly to print out the NS records for the domain and the glue records for that NS as is set in the server specified. This optional IP parameter represents the server IP that you expect to hold the DNS zone file for the domain.
#!/bin/sh
 
if [ "$1" = '-h' ]; then
  printf "\nusage: ./parent-vs-ns-check.sh <domain> <optional server IP that is expected to host the DNS for the domain> \n e.g. ./parent-vs-ns-check.sh dnscheckdomain.com 123.45.67.89 \n \n"
  exit;
elif [ "$1" = '--help' ]; then
  printf "\nusage: ./parent-vs-ns-check.sh <domain> <optional server IP that is expected to host the DNS for the domain> \n e.g. ./parent-vs-ns-check.sh dnscheckdomain.com 123.45.67.89 \n \n"
  exit;
else
S=${IFS}
IFS=.
for P in $1; do
  TLD=${P}
done
IFS=${S}
 
printf "\n \nTLD: ${TLD} \n\n"
DNSLIST=$(dig +short ${TLD}. NS)
for DNS in ${DNSLIST}; do
  echo "Checking ${DNS}"
  dig +norec +nocomments +noquestion +nostats +nocmd @${DNS} $1 NS
done
 
echo
echo
echo "DNS VIA DIG"
dig ns +short $1
dig a +short $(dig ns +short $1)
 
if [ ! -z $2 ] ; then 
  echo
  echo 
  echo "DNS AT SERVER IP $2:"
  dig ns +short $1 @"$2"
  dig a +short $(dig ns +short $1 @"$2") @"$2"
fi  
fi

Authoritative Nameservers Tips and Tricks

If you don’t get any nameservers back from the parent nameserver when using this script, the problem is at the registrar.

If you don’t get any nameservers back from Dig and from your DNS server IP that should be hosting the DNS, the problem is most likely at the server. If the issue is at the server, there are a few issues to check:

  1. Check to see if the domain’s zone file failed to load due to errors. To check this, either log into WHM and use the “Edit DNS Zone” interface to try to reload the domain’s zone file. Select the domain from the drop-down to open it, scroll to the bottom of the file, and click “Save”. Does it save successfully, or does it report errors and display a message stating that it did not load due to errors?
  2. If the zone did not load due to errors, fix the errors highlighted in red and then reload the zone file. If no errors are reported, check for duplicate records. Does ns1 and ns2 both have their own zone files and do they also have A records set in the main domain’s zone file as well? If so, remove the DNS zone files for ns1 and ns2 if they already have A records set for them in the main domain’s zone file. For example, the domain mdomain1.tld has its own vanity nameservers and when you open the zone file for mdomain1.tld, you see that its NS records are ns1.mdomain1.tld and ns2.mdomain1.tld. You also see that both ns1.mdomain.tld and ns2.mdoamin.tld both have A records set in that same zone file. You go back to the list of zone files under /var/named/ or you go back to WHM’s Edit DNS Zone and you notice that a complete file exists for each nameserver named as ns1.mdomain1.tld.db and ns2.mdomain1.tld.db. This redundancy seems to disrupt their functioning, so you will need to delete the zone files for ns1 and ns2 but leave the A records set for ns1 and ns2 in the zone file for mdomain1.tld.
  3. Make sure that the set of nameservers at the server and at the registrar match exactly. Make sure both have A records (glue records) and resolve to the same IPs.

As always, if you have any trouble with your DNS, please feel free to open a support ticket and we’ll be glad to help! 🙂

Related Articles: