Blog

Authoritative vs Non-authoritative DNS answers

  • Email
  • /
  • Fri Mar 20 20:29:00 CET 2020

Authoritative vs. Recursive DNS Servers

The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services, or other resources connected to the Internet or a private network (Definition from Wikipedia).

DNS services are divided in two different types: Authoritative and Recorsive.

A root name server is a name server for the root zone of the Domain Name System (DNS) of the Internet.(Definition from Wikipedia).

The output of the following command nslookup -q=ns . is

Server: dns.google
Address: 8.8.8.8

Non-authoritative answer:
(root) nameserver = a.root-servers.net
(root) nameserver = b.root-servers.net
(root) nameserver = c.root-servers.net
(root) nameserver = d.root-servers.net
(root) nameserver = e.root-servers.net
(root) nameserver = f.root-servers.net
(root) nameserver = g.root-servers.net
(root) nameserver = h.root-servers.net
(root) nameserver = i.root-servers.net
(root) nameserver = j.root-servers.net
(root) nameserver = k.root-servers.net
(root) nameserver = l.root-servers.net
(root) nameserver = m.root-servers.net

coomnadlinedns

 

The root name servers gives

Authoritative name servers provide DNS record information and they are hosted by a provider or domain name registrar.

Recursive name servers are the server deputed to connect authoritative servers and end-users because they have to “climb” the DNS tree to get the proper authoritative name server and collect the DNS information required.

Recursive servers are mainly referred to as resolving servers, and often your ISP (Internet Service Provider) or specialty resolving DNS providers.nslookup -q=ns . a.root-servers.net

Usually, these servers use to cache DNS record information, so a lot of queries related to some popular domains never end up reaching the authoritative name servers.

Obviously, If a domain’s record is not cached, then the resolving server will “climb” the DNS tree up to the authoritative server for the domain’s record.

The DNS Tree

a name server (DNS server) answers to the question: “Which is the IP related to this domain?” it’s a repository where the domain is mapped with an IP, but it doesn’t mean all these information is stored in a single server.

They are actually distributed worldwide. These nameservers, named the root nameservers, store only the locations of the TLD (top-level domains).

TLD’s are the characters that you usually see at the end of a domain such as .com, .net and so on..
Every TLD has its own set of nameservers that are used to store the information that says who is authoritative for storing the DNS records for that domain.

Usually, the authoritative nameserver is the DNS provider or the DNS registrar.

AUTHORITATIVE DNS and NON-AUTHORITATIVE

We can register a domain name and purchase a hosting service separately.
We can then register the domain name with any company and choose the server that hosts our web pages at any other company.
If we want everything to work properly we need to link the domain name to the server hosting the site.
To do this you need to configure the servers dedicated to DNS.
The servers dedicated to DNS are computers that host the DNS (Domain Name System), a database created to convert the text domain name into a numerical code (IP address) that is understandable to the machines and essential for computers on the network to communicate with each other.
By setting up DNS correctly, you can link our domain name to the server that hosts our website.
When registering a domain and requesting a hosting service from the same company, we do not have to worry about DNS because it does all the service provider.
The Name Servers of company A from which we registered the domain are said to be authoritative for that domain.

The authoritative term indicates competence, not a hierarchical priority order.

DNS databases that are located within those servers are DNS authoritative.
Authoritative DNS is the DNS that contains data specific to the domain name, respond to requests for that domain and provide the related data (web, mail, FTP, etc.).
In summary, an authoritative server is the DNS server “master” DSN for a certain domain, a non-authoritative DNS can have all the information of the master and be interrogated to provide information about the domain, but changes on the DNS records must be performed on the Authoritative DNS and, subsequently, propagated to non-authoritative servers.

HOW DNS works.

To understand DNS propagation, it is crucial to first explain HOW DNS works.

For example, your domain on Iwantmyname manages its DNS through three different servers: ns1.iwantmyname.com, ns2.iwantmyname.com, ns3.iwantmyname.com
However, this does not mean that anyone visiting your site will have to refer to these three servers to know “where” to go.

On the contrary, it will almost certainly use different DNS servers (normally those of its ADSL provider).

So a user who uses (for example) AOL connectivity, to go to your site will refer to what will be pointed out by AOL’s DNS servers.

The DNS servers are connected to each other, worldwide, and make up a real network that continues to exchange and update data.
So if you make a change to DNS, it will take some time for it to propagate on all Internet DNS servers:

How much time? It depends

… it is a progressive event, which can start a few minutes after the change and end up to 48 hours later.

This time is called DNS PROPAGATION TIME and, although not in principle controllable, it is possible to do something to try to reduce it to a minimum.

DNS propagation: Time-To-Live (TTL)
 
The “Time-To-Live”, or TTL, is a parameter of the configuration of a DNS that becomes important when you intend to change your configuration or change the DNS server.

The TTL is the time, expressed in seconds, for which another DNS server can consider the information received valid.

That is, a small value (eg 3600, then one hour) will cause another DNS server, after receiving the DNS configuration data of your domain, to consider them valid for one hour; therefore, to any request, the arrivals in about 60 minutes will respond with the same configuration. After 60 minutes, it will take care to update the data again.

Thus, a low TTL guarantees – in principle – a greater speed of propagation of changes on the internet.

However, you should not give in to the temptation to always use low TTLs: these must be used only for modifications, while for the rest of the time high TTLs must be used.

This for a number of reasons:

a low TTL will result in the other DNS servers responding to any requests not with the cached data, but requesting an update of the same; this will then make the response of your site less fast

a TTL too low, or kept low for too long, can be ignored by some DNS servers, so even if you set a TTL of 30 minutes, it may be that after a week some DNS servers decide to ignore this information, and raise ( also significantly the value of TTL, in this way, in reality, we get the opposite of the desired result)

Two days before the change of DNS, intervene lowering the TTL appropriately

In the two following days, this information (ie “these DNS are to be verified every 30 minutes”) will be propagated through the internet

How to proceed then in the modification of the DNS for these to propagate with the maximum possible speed?

Then perform the DNS change, leaving the TTL low

Finally, 36 h after the change of DNS, intervene again only on TTL, raising them appropriately.

What are the values to set the TTL?

The rules (RFC2308) indicate a value between 3600 and 86400 (that is, between one hour and 24h)

If no changes are made to the DNS, it is preferable to set a value as high as possible, which will generally make our site more “responsive”: therefore 86400

If instead, we have to make changes, it is better to lower this value as much as possible, taking care, however, to remain within reasonable values: considering that a value too low (like 600) could also be completely ignored by many DNS servers, it is convenient to use a value of 3600

BLOG

  • Calendar and address book

    View
  • Share, and Use PGP Encryption Keys for Secure Communication

    View
  • Mastering Email Security: Unveiling the Secrets of DKIM Signatures

    View
  • Web Security, External Webpage Resources, and Their Threats to Your Privacy

    View
  • What an email alias address is and when it could be useful

    View
  • Address book and privacy

    View
  • Save attachments to Dropbox from incoming emails with Servermx

    View
  • Dropbox Email Integration

    View
  • How to Easily Switch Your Email Hosting Provider to Servermx

    View
  • Best email hosting comparison 2020

    View
  • Authoritative vs Non-authoritative DNS answers

    View
  • How to check DNS propagation?

    View
  • How the “catch-all” option works?

    View
  • Email and Web Hosting Separate? Excellent choice.

    View
  • Punycode conversion for MX records

    View
  • Free domains, where and how

    View
  • How to set email web client with your domain name

    View
  • What Are MX Records?

    View
  • One common cliché about POP and IMAP

    View

Our contacts