What is Authoritave, Non Authoritative, Recurvise DNS Server

What is a Authoritative Name Server?

Basically authoritative DNS means the place where the Domain is actualy hosted. For Eg. if Www.example1.com is hosted nameserver1 then the response from nameserver1 is known as authoritative

It's distinction between a nameserver that's an official nameserver for the domain you're querying, and a nameserver that isn't. Nameservers that aren't authoritative are getting their answers second (or third or fourth...) hand - just relaying the information along from somewhere else.

An authoritative answer comes from a nameserver that is considered authoritative for the domain which it's returning a record for (one of the nameservers in the list for the domain you did a lookup on), and a non-authoritative answer comes from anywhere else (a nameserver not in the list for the domain you did a lookup on).containing complete and accurate information, and therefore respected:

So, for example, If we do an nslookup of maps.google.com we would get a response from one of my configured nameservers. (Either from my ISP, or my domain.) It would come back as non-authoritative because neither my ISP's nameservers, nor my own are in the list of nameservers for google.com. They aren't Google's nameservers, so they're not the authoritative source that creates the NS records.

The list of authoritative nameservers for Google is below (from whois.internic.net).

Domain Name: GOOGLE.COM

Registrar: MARKMONITOR INC.

Whois Server: whois.markmonitor.com

Name Server: NS1.GOOGLE.COM

Name Server: NS2.GOOGLE.COM

Name Server: NS3.GOOGLE.COM

Name Server: NS4.GOOGLE.COM

Non-authoritative nameservers 

Non-authoritative nameservers get their NS records from the authoritative servers somewhere down the line.

The answer you've received is essentially a cached or forwarded response from your local DNS server. Basically, a non-authoritative name server is one that does not contain the records for the zone being queried; your local DNS is likely not going to have Google's name records, for example.

You can get the name servers that are authoritative for a given domain by running host -t ns example.com to retrieve the NS record for example.com.

In the case of Google, we see:

$ host -t ns google.com

google.com name server ns4.google.com.

google.com name server ns1.google.com.

google.com name server ns2.google.com.

google.com name server ns3.google.com.

If you subsequently run your nslookup command against one of those servers, you will get the authoritative answer:

$ nslookup www.google.com ns1.google.com

Server:         ns1.google.com

Address:        216.239.32.10#53

www.google.com  canonical name = www.l.google.com.

Name:   www.l.google.com

Address: 173.194.43.49

Name:   www.l.google.com

Address: 173.194.43.50

Name:   www.l.google.com

Address: 173.194.43.48

Name:   www.l.google.com

Address: 173.194.43.52

Name:   www.l.google.com

Address: 173.194.43.51

If you're using nslookup, to get the NS record type, you can run something like this in interactive mode:

$ nslookup

> set querytype=ns

> google.com

Server:         127.0.0.1

Address:        127.0.0.1#53

Non-authoritative answer:

google.com      nameserver = ns3.google.com.

google.com      nameserver = ns4.google.com.

google.com      nameserver = ns1.google.com.

google.com      nameserver = ns2.google.com.

Authoritative answers can be found from:

ns1.google.com  internet address = 216.239.32.10

So, setting querytype=ns does what the above host command did.

What is a Recursive DNS Server?

Basically the DNS server which is managed by ISP.

You might have been able to guess what a recursive DNS server does by its name—it recurses, which means that it refers back to itself. Recursive DNS nameservers are responsible for providing the proper IP address of the intended domain name to the requesting host. Recursive nameservers are like the phone operator looking up a phone number from multiple phone books on behalf of the requesting party (the users’ computer on behalf of an application), some phone books will list just last names, then other phone books exist per last name, and list first names.

For example, when making a request to a website from your browser, the host (computer) will then make a request to recursive DNS server to find the IP address associated with the website; this is assuming your operating system and Web browser do not already have a response cached. From there, the recursive server will check to see if it has a cached DNS record from the authoritative nameserver, and still has a valid time-to-live (TTL). If the recursive server does not have the DNS record cached, it begins the recursive process of going through the authoritative DNS hierarchy, which I will explain further down in this post.

Basically, it's what the name says it is. An authoritative answer comes from a nameserver that is considered authoritative for the domain which it's returning a record for (one of the nameservers in the list for the domain you did a lookup on), and a non-authoritative answer comes from anywhere else (a nameserver not in the list for the domain you did a lookup on).

What it GTLD

Generic top-level domains (gTLDs) are one of the categories of top-level domains (TLDs) maintained by the Internet Assigned Numbers Authority (IANA) for use in the Domain Name System of the Internet. A top-level domain is the last label of every fully qualified domain name. They are called generic for historic reasons; initially, they were contrasted with country-specific TLDs in RFC 920.

The core group of generic top-level domains consists of the com, info, net, and org domains

When someone registers a domain name, he/she can specify which DNS server is the authoritative DNS server. This information is called an NS record. The NS record will tell a top-level domain DNS server which nameserver holds the domain's A record, MX record, etc.

How zone transfer happens in DNS

Zone transfer uses TCP for transport. The client requesting a zone transfer may be a slave server or secondary server, requesting data from a master server, sometimes called a primary server. 

Zone transfer comprises a introduction followed by the actual data transfer. The introduction comprises a Start of Authority (SOA) resource record for the "zone apex", the node of the DNS namespace that is at the top of the "zone". The fields of this SOA resource record, in particular the "serial number", determine whether the actual data transfer need to occur at all. The client compares the serial number of the SOA resource record with the serial number in the last copy of that resource record that it has. If the serial number of the record being transferred is greater, the data in the zone are deemed to have "changed" (in some fashion) and the slave proceeds to request the actual zone data transfer. If the serial numbers are identical, the data in the zone are deemed not to have "changed", and the client may continue to use the copy of the database that it already has, if it has one.

The actual data transfer process begins by the client sending a query (opcode 0) with the special query type AXFR (value 252) over the TCP connection to the server. The server responds with a series of response messages, comprising all of the resource records for every domain name in the "zone". The first response comprises the SOA resource record for the zone apex. The other data follows in no specified order. The end of the data is signaled by the server repeating the response containing the SOA resource record for the zone apex.

Some zone transfer clients perform the SOA lookup of the preamble using their system's normal DNS query resolution mechanism. These clients do not open a TCP connection to the server until they have determined that they need to perform the actual data transfer. However, since TCP can be used for normal DNS transactions, as well as for zone transfer, other zone transfer clients perform the SOA lookup preamble over the same TCP connection as they then (may) perform the actual data transfer. These clients open the TCP connection to the server before they even perform the preamble.

The preceding describes full zone transfer. Incremental zone transfer differs from full zone transfer in the following respects:

The client sends the SOA resource record for the zone apex that it currently has, if any, in the IXFR message, letting the server know which version of the "zone" it believes to be current.

Though the server may respond in the normal AXFR manner with the full data for the zone, it may also instead respond with an "incremental" data transfer. This latter comprises the list of changes to the zone data, in zone serial number order, between the version of the zone that the client reported to the server as having and the version of the zone that is current at the server. The changes comprise two lists, one of resource records that are deleted and one of resource records that are inserted. (A modification to a resource record is represented as a deletion followed by an insertion.)

Zone transfer is entirely client-initiated. Though servers can send a NOTIFY message to clients (that they have been informed about) whenever a change to the zone data has been made, the scheduling of zone transfers is entirely under the control of the clients. Clients schedule zone transfers initially, when their databases are empty, and thereafter at regular intervals, in a pattern controlled by the values in the "refresh", "retry", and "expire" fields in the SOA resource record of the zone apex.

In your case, you probably have the correct internal address in /etc/hosts.

If you host your DNS outside reistrar then you need to register your name server IP's to registrar. Registries use the Extensible Provisioning Protocol (EPP) to facilitate their registrar interactions. It's worth noting that this is a whole separate protocol from DNS itself, specifically dealing with name registration and provisioning. It only indirectly populates the relevant zone in DNS.

Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

As more of a sidenote, the root servers deal with the root zone (aka .), a TLD zone is not the same as the "root". If you register for instance example.com through your registrar nothing changes in the root zone, your delegation is only entered into the com zone.