List of DNS Reocrds and Its explanations

Differences between the A, CNAME, ALIAS and URL records

A, CNAME, ALIAS and URL records are all possible solutions to point a host name (name hereafter) to your website. 

However, they have some small differences that affect how the client will reach your site.

Before going further into the details, it’s important to know that A and CNAME records are standard DNS records, whilst ALIAS and URL records are custom DNS records. Both are translated internally into A records to ensure compatibility with the DNS protocol.

Here’s the main differences:

The A record maps a name to one or more IP addresses, when the IP are known and stable.

The CNAME record maps a name to another name. It should only be used when there are no other records on that name.

The ALIAS record maps a name to another name, but in turns it can coexist with other records on that name. The URL record redirects the name to the target name using the HTTP 301 status code.

Some important rules to keep in mind:

The A, CNAME, ALIAS records causes a name to resolve to an IP. Vice-versa, the URLrecord redirects the name to a destination. The URL record is simple and effective way to apply a redirect for a name to another name, for example to redirect www.example.com to example.com.

The A name must resolve to an IP, the CNAME and ALIAS record must point to a name.

Which one to use

Understanding the difference between the A name and the CNAME records will help you to decide.

The general rule is:

use an A record if you manage what IP addresses are assigned to a particular machine or if the IP are fixed (this is the most common case)

use a CNAME record if you want to alias a name to another name, and you don’t need other records (such as MX records for emails) for the same name

use an ALIAS record if you are trying to alias the root domain (apex zone) or if you need other records for the same name

use the URL record if you want the name to redirect (change address) instead of resolving to a destination.

You should never use a CNAME record for your root domain name (i.e. example.com).

The A and CNAME records are the two common ways to map a host name (name hereafter) to one or more IP address. Before going ahead, it’s important that you really understand the differences between these two records. I’ll keep it simple.

The A record points a name to a specific IP. For example, if you want the name blog.dnsimple.com to point to the server 185.31.17.133 you will configure:

blog.dnsimple.com.     A        185.31.17.133

The CNAME record points a name to another name, instead of an IP. The CNAME source represents an alias for the target name and inherits its entire resolution chain.

Let’s take our blog as example:

blog.dnsimple.com.      CNAME   aetrion.github.io.

aetrion.github.io.      CNAME   github.map.fastly.net.

github.map.fastly.net.  A       185.31.17.133

We use GitHub Pages and we set blog.dnsimple.com as a CNAME of aetrion.github.io, which in turns is itself a CNAME of github.map.fastly.net, which is an A record pointing to 185.31.17.133. In short terms, this means that blog.dnsimple.com resolves to 185.31.17.133.

To summarize, an A record points a name to an IP. CNAME record can point a name to another CNAME or an A record.

The chief difference between a CNAME record and an ALIAS record is not in the result—both point to another DNS record—but in how they resolve the target DNS record when queried.  As a result of this difference, one is safe to use at the zone apex (e.g., naked domain, such as example.com) and the other is not.

Let’s start with the CNAME record type.  It simply points a DNS name, like www.example.com, at another DNS name, like lb.example.net.  This introduces a performance penalty, since at least one additional DNS lookup must be performed to resolve the target (lb.example.net).  In the case of neither record ever having been queried before by your recursive resolver, it’s even more expensive time-wise, as the full DNS hierarchy must be traversed for both records:

You as the DNS client (or stub resolver) query your recursive resolver for www.example.com.

Your recursive resolver queries the root name server for www.example.com

The root name server refers your recursive resolver to the .com Top-Level Domain (TLD) authoritative server.

Your recursive resolver queries the .com TLD authoritative server for www.example.com.

The .com TLD authoritative server refers your recursive server to the authoritative servers for example.com.

Your recursive resolver queries the authoritative servers for www.example.com, and receives lb.example.net as the answer.

Your recursive resolver caches the answer, and returns it to you.

You now issue a second query to your recursive resolver for lb.example.net.

Your recursive resolver queries the root name server for lb.example.net.

The root name server refers your recursive resolver to the .net Top-Level Domain (TLD) authoritative server.

Your recursive resolver queries the .net TLD authoritative server for lb.example.net.

The .net TLD authoritative server refers your recursive server to the authoritative servers for example.net.

Your recursive resolver queries the authoritative servers for lb.example.net, and receives an IP address as the answer.

Your recursive resolver caches the answer, and returns it to you.

Each of these steps consumes at least several milliseconds, often more, depending on network conditions.  This can add up to a considerable amount of time that you spend waiting for the final, actionable answer of an IP address.

In the case of an ALIAS record, all of the same actions are taken as with the CNAME, except the authoritative server for example.com performs steps six through thirteen for you, and returns the final answer of an IP address.

This offers two advantages and one significant drawback:

Advantages

Faster final answer resolution speed. In most cases, the authoritative servers for example.com are more powerful and have faster Internet connectivity than your own computer and connection.  They can therefore traverse the DNS hierarchy and retrieve the final answer much faster than you can.

Answer looks like an A record. Since an ALIAS record returns the final answer consisting of one or more IP addresses, it can be used anywhere an A record can be used—including the zone apex. This makes it more flexible than a CNAME, which cannot be used at the zone apex.

Disadvantages

Geotargeting information is lost. Since it is the authoritative server for example.com that is issuing the queries for lb.example.net, then any intelligent routing functionality on the lb.example.net record will act upon the location of the authoritative server, not on your location. The EDNS0 edns-client-subnet option does not apply here. This means that you may be potentially mis-routed: for example, if you are in New York, and the authoritative server for example.com is in California, then lb.example.com will believe you to be in California and will return an answer that is distinctly sub-optimal for you in New York.

One important thing to note is that NS1 collapses CNAME records provided they all fall within the NS1 system, i.e., NS1’s nameservers are authoritative for both the CNAME and the target record. Collapsing simply means that the NS1 nameserver will return the full chain of records, from CNAME to final answer, in a single response.  This eliminates all the additional lookup steps, and allows you to use CNAME records, even in a nested configuration, without any performance penalty.

And even better, NS1 supports a unique record type called a Linked Record. This is basically a symbolic link within DNS that acts as an ALIAS record might, except with sub-microsecond resolution speed.  To use a Linked Record, simply create the target record as you usually would (it can be of any type) and then create a second record to point to it, and select the Linked Record option.  Note that Linked Records can cross domain (zone) boundaries and even account boundaries within NS1, and offer a powerful way to organize and optimize your DNS record structure.

How to Enable chroot in DNS

A chroot jail is a way to isolate a process and its children from the rest of the system. It should only be used for processes that don't run as root, as root users can break out of the jail very easily.

The idea is that you create a directory tree where you copy or link in all the system files needed for a process to run. You then use the chroot() system call to change the root directory to be at the base of this new tree and start the process running in that chroot'd environment. Since it can't actually reference paths outside the modified root, it can't perform operations (read/write etc.) maliciously on those locations.

On Linux, using a bind mounts is a great way to populate the chroot tree. Using that, you can pull in folders like /lib and /usr/lib while not pulling in /user, for example. Just bind the directory trees you want to directories you create in the jail directory.

Setup Bind DNS Server in Chroot Jail on CentOS 7

1. Install Bind Chroot DNS server :

# yum install bind-chroot -y

2. Initialize the /var/named/chroot environment by running:

# /usr/libexec/setup-named-chroot.sh /var/named/chroot on

Use of Dot in DNS Zone File

When a period is at the end of a value it tells name server that we do not want the domain name added to the end of that value.

If we leave the dot out, then the domain name will be added to the domain to the end of the value.

For Eg:

Correct Entries

example.com.    NS    ns1.example.com.

example.com.    NS    ns1

Incorrect Entries

example.com.    NS    ns1.example.com

Above Line will again try to add domain.com in the end it will become like ns1.example.com.example.com.

In simple if there  is a dot at the end of a name in a resource record or directive, the name is qualified and it is the whole name including the host, and it is a Fully Qualified Domain Name – FQDN and the resource record is unchanged.

If there is NO dot at the end of the name then the name is unqualified and DNS adds the value of the domain in the end.

In the absence of an $ORIGIN directive the zone name from the named.conf file for this zone is used as an $ORIGIN directive.

What is Origin Directive

$ORIGIN

Appends the domain name to unqualified records, such as those records without dot in the resource record.

For example, a zone file may contain the following line:

$ORIGIN example.com.

Any names used in resource records that do not end in a trailing period (.) are appended with example.com.

Note : The use of the $ORIGIN directive is unnecessary if the zone is specified in /etc/named.conf because the zone name is used as the value for the $ORIGIN directive by default.

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.

Difference between Zone and Domain/Domain Name Server and Domian Name System

Difference between zone and domain

Domain name servers store information about part of the domain name space called a zone. The name server is authoritative for a particular zone. A single name server can be authoritative for many zones.

Understanding the difference between a zone and a domain is sometimes confusing. A zone is simply a portion of a domain. If there are no subdomains, then the zone and domain are essentially the same. In this case the zone contains all data for the domain

For example, the Domain google.com may contain all of the data for google.com, maps.google.com and testing.google.com(Like SOA, MX, TXT...). 

However, the zone google.com contains only information for google.com and references to the authoritative name servers for the subdomains. The zone google.com can contain the data for subdomains of google.com if they have not been delegated to another server. For example, maps.google.com may manage its own delegated zone. testing.google.com may be managed by the parent, google.com.

Domain name server & domain name system

DNS(domain name server) is the backend system that resolves domain names and IPs worldwide. DNS (domain name system) is the whole system in whcih the process of resolving is done. You can say DNS as Domain name system or server.

NSLOOKUP, DIG and HOST Command

a) nslookup

This is deprecated by Bind developers. But still used to resolve Hostname into IP address.

b) host  

Host is also used to convert names into IP addresses and vice versa. Without arguments it will give the list of options.

Sample output of host command : ansim0.example.local has address 192.168.1.10

c) dig

Dig and host commands basically output the same info. 

dig +short www.yahoo.com

host www.yahoo.com

dig www.yahoo.com

host -d www.yahoo.com

basically prints the same output. The dig command includes some timing stats and the actual query that will be performed.

nslookup -debug www.yahoo.com

Although the output is in a different format, the information that is printed out is basically the same as dig.

If you want the full enchilada...

nslookup -d2 www.yahoo.com

...or

dig -d2 www.yahoo.com

How the Domain Name System (DNS) works

1. Client enters ‘www.example.com’ internet address. Client computer needs the IP address translation of ‘example.com’ and first checks its own DNS cache for this information. If this is the first time using this website or the cache has been cleared it cannot find the IP address here.

2. The client computer (or “query”?) is then redirected to the Internet Service Provider’s (ISP’s) DNS Server. The ISP’s DNS server checks its own cache but it will not be there if the site has not been accessed before.

3. The ISP’s DNS server redirects the query to the Root DNS Server. Every DNS server has a file that contains a list of all of the root DNS servers. Totally there are 13 root DNS servers.

4. The root DNS server maintains information about where a top-level (like .com, .in) DNS server is located and returns this information to the ISP’s DNS Server.

5. The ISP’s DNS server redirects the query to a top-level (.com) DNS server.

6. The top-level (.com) DNS server knows the IP address of the DNS server(Authoritative DNS server) for the example.com domain and returns that information to the ISP’s DNS server.

7. The ISP’s DNS server redirects the query to the actual authoritative DNS server for the example.com domain.

8. The DNS server for www.example.com returns the IP address of the host of www.example.com to the ISP’s DNS server.

9. Lastly, the ISP’s DNS server sends the IP address to the client computer so the client can access www.example.com

When your browser connects to a website say example.com, the browser first queries your local DNS server to get the IP address of example.com.

If the local DNS server doesn't have the A record of example.com, it will query one of the root DNS servers.

The root DNS server will say: I don't have the A record but I know the top-level domain DNS server which is responsible for .com domains.

Then your local DNS server query the top-level domain DNS server which is responsible for .com domains. The TLD DNS server will respond: I don't know either but I know which DNS 
server is authoritative for example.com.

So your local DNS server queries the authoritative DNS server. Because the actual DNS record is stored on that authoritative DNS server, so it will give your local DNS server an answer.

First you have to understand how DNS system works. DNS system can be divided into three tiers. They are:

a) root DNS servers

b) top-level domain DNS servers

c) authoritative DNS servers
d) Local DNS server (Which Will be IP of ISP) whose IP address is specified on your operating system.

When your browser connects to a website say example.com, the browser first queries your local DNS server to get the IP address of example.com.

If the local DNS server doesn't have the A record of example.com, it will query one of the root DNS servers.

The root DNS server will say: I don't have the A record but I know the top-level domain DNS server which is responsible for .com domains.

Then your local DNS server query the top-level domain DNS server which is responsible for .com domains. The TLD DNS server will respond: I don't know either but I know which DNS 
server is authoritative for example.com.

So your local DNS server queries the authoritative DNS server. Because the actual DNS record is stored on that authoritative DNS server, so it will give your local DNS server an answer.

Then this query result is cached on your local DNS server but it can be outdated. When the TTL time has expired, your local DNS server will update the query result from the authoritative DNS server. Whenever you query a DNS record on your local DNS server, it returns a non-authoritative (unofficial) answer. If you want an authoritative answer, you must explicitly specify the authoritative DNS server when you use nslookup or other utilities. I think a local DNS server should be called caching DNS server.