Why NS record is needed in Zone file?

Here is a detailed article about how DNS works.

Your statement...

Even if this information is not available in zone file then still name resolution will happen smoothly.

is incorrect.

The TLDs don't hold resource records for all second level domains, they query their zone information for authoritative records that indicate what servers have the domain information which is being queried.

This TLD query looks for SOA and the NS records associated for the indicated FQDN.  If the TLD cannot find an authoritative servers (NS Records) the root DNS servers will not know where to direct the DNS query to.  

Also understand that there is caching of DNS records involved in the operation of DNS servers.  DNS Servers typically cache query responses to enhance response times to frequently requested domains.  Since caching is involved, DNS records have an associated TTL (Time To Live) information on every record, indicating how long a record should be hold in a local cache before the caching server should try to refresh the records.
**DNS clients (non-servers) also cache information about DNS names it has previously resolved.

Meaning that there is a time delay (depending on the domain configuration) is DNS record updates replicating around the global DNS infrastructure.

It would then be possible for you to delete your NS records and for a short time, DNS resolution could continue uninterrupted.

So, to summarize, NS records are required in a DNS Domains to tell querying clients (other servers or clients) what servers at what IP Addresses are authoritative for the domain being queried.  Without knowing which IP Address to communicate with (from the SOA and NS records), DNS queries would not function.

Dan

> The TLDs don't hold resource records for all second level domains, they query their zone information for authoritative records

This is not true.

TLD servers hold glue for subordinate zones. This is why,  when a domain is registered through a registrar, Name Server entries must be defined.

Without glue you have an unrecoverable race condition when the name server records for a given domain are held within the same zone.

To get the name servers for domain.com, I need to resolve ns1.domain.com.
To resolve ns1.domain.com, I need to resolve the name server record set for domain.com.
To get the name servers for domain.com, I need to resolve ns1.domain.com.
To resolve ns1.domain.com, I need to resolve the name server record set for domain.com.
And on.

You don't have to take me word for this, the condition can be tested, in this example using nslookup (which I cannot validate because... firewall).

nslookup
set norecurse
set server a.gtld-servers.net
set type=ns
google.com

Select allOpen in new window

Also visible using trace here:

https://www.digwebinterface.com/?hostnames=google.com&type=NS&showcommand=on&colorize=on&trace=on&ns=resolver&useresolver=8.8.4.4&nameservers=a.gtld-servers.net

The second from last response is the glue for the parent (not the result of a recursive query).

True... minor disconnect from brain and fingers.  I will move the "all" in that sentence, indicating that TLDs do not hold all the resource records for second level domains.

The glue being reference to is the SOA, which contains the NS information.

Here is an article with a detailed description of DNS Name Resolution:  http://blog.catchpoint.com/2014/07/01/dns-lookup-domain-name-ip-address/

Dan

Glue references NS records, not an SOA. Each domain has exactly one SOA record which would inject a signficant lack of fault tolerance if it were the only thing used as glue.

Root zones hold (NS record) glue for TLDs, TLDs hold (NS record) glue for subordinate domains.

This chain extends into private DNS infrastructure as well. MS DNS, for example, uses glue in the parent zone when delegating child zones.

> Exactly one SOA

For the sake of vague completion.

Each instance of a zone has one SOA record, but this does not necessarily mean SOA records are the same across all instances within a given namespace. The SOA record is assumed to be the same across all instances in the traditional master/slave replication model. If an out-of-band replication mechanism is used, the SOA may differ in each instance of the zone. Microsoft's DNS replication via Active Directory is a solid example of this.

Per-instance SOA records are normally used to indicate the zone is writable (on that specific server). This is important when supporting dynamic updates as a dynamic update does depend on the SOA record.

Tangent failure. I still think this is a good question with logical basis.

Thank you everyone for the detailed answer.

I am curios what will happen if there is mismatch of NS record in gTLD's glue record and zone file in authorized zone. Will it break anything?

Technically no as long as both leave you with valid name servers. Most analysis tools examine that aspect and flag a warning if there is a mismatch.

Bad practice, perhaps, not terminal.

Thank you, one more thing.

What is the use of NS server which is mentioned in the SOA record? Do resolver client use that NS server to send query?

Thanks!

The SOA record is used by systems performing dynamic update to figure out where they can send an update.

If you have AD integrated zones, each server should believe itself to be the SOA.

Sorry, AD integrated, crossed thread.

The SOA is used for dynamic update discovery (writable zone), and it's used when considering zone transfers (based on the serial number). That applies to both AXFR and IXFR.