Let us discuss these topic.
- Zone file.
- Record Types
- DNS resolution
These are the sequence order we will follow before we will understand how DNS resolution happens. Again, the information that is shared in this page, consider it to be at beginner level.
Zone file:
Well zone files are a text file that is neither encoded nor it is encrypted and it defines a particular zone. It describes that particular DNS zone.
The zone file contains the mapping between domain names and its respective IP addresses and also other resources, organized in the form of text representations of resource records (RR)
A zone file can either be a DNS master file, authoritatively describing a zone or it may be used to list the contents of a DNS cache.
It also referred as a single domain of the hierarchical name structure of the DNS. The format of a zone file is defined in RFC 1035 and RFC 1034.
I have no zone file created on my system so for the purpose of an example, I am sharing an image from the Internet.

This zone file does not have all the record type of information but can give you a general idea how exactly a zone file looks like. With progress of this discussion, I will show few of the zone records that is present in a zone file.
The zone files represent a sequence of line-oriented entries and each of these lines are either a directive or a text description that defines a single resource record (RR).
Now directives are control entries that affect the rest of the zone file. The first filed of a directive consists of a dollar sign followed by a keyword.
• $ORIGIN – This is followed by a domain name to be used as the origin for the following relative domains.
• $INCLUDE – This will be followed by a file name and optional origin domain name.
• $TTL – This value represents the time-to-live which means it is a number followed by this term that defines how long a file will remain active before making a request for the new one. Simply saying, how long a DNS resolver will cache a query before making a similar query request.
• $GENERATE – This is a non-standard extension accepted by BIND and few other name servers which is used for inserting multiple RR with one entry.
A zone file record consists of several fields as shown here and either of these records are considerable.

or

If suppose we are keeping the name field blank then the record inherits the field from the previous record in that file. Also, if we use @ it will mean the current origin.
Types of records
There are certain types of records to consider in a DNS zone file. Let us check few of them.
SOA – It stands for Start of Authority. When you see this record in the zone file that means it is the Authoritative Name Server for the current DNS zone. This record will appear at the beginning of the DNS zone file.
Address Mapping record (or A Record) – If we see this record that means we will be seeing the hostname and its corresponding IPv4 address. Also known as DNS host record.
IPv6 Address record (AAAA Record) – Also CNAME Record most people refer to this as quad-A record. Also stores a hostname and its corresponding IPv6 address.
CNAME Record – We will come across more often in any IT industry infrastructure job (mostly). Well, this is known as Canonical Name record and it is used as an alias as a hostname representing another hostname. So, when a DNS client requests a record that contains a CNAME, which points to another hostname. The DNS resolution process is repeated with the new hostname.
For example: if my Public facing name is networkcnl.com which is my website name but I think I want to give a different name than this which is easier and fast to type. So, say I give network.com and I map this CNAME to networkcnl.com and what happens here when people do a query for network.com first, the resolution first happens for network.com and once the DNS client receives the real name for networkcnl.com and again a DNS resolution happens here for this domain. All these processes happen in the backend and not shown to user. Only network.com webpage will be shown to user in the web browser, rest of this DNS processes is taken care in the backend.
Mail exchanger record (MX Record) – This record is used for SMTP email server for the domain i.e., it is used for routing outgoing emails to an email server.
NS Record or Name Server Record – NS specifies that networkcnl.com is delegated or belongs to a specific Authoritative Name Server and provides the address of the name server.
Reverse-lookup Pointer Records (PTR Record) – Another important record that allows a DNS resolver to provider an IP address and receive a hostname (reverse DNS lookup).
Text Record (TXT Record) – TXT record basically provides the ability to associate a arbitrary text with a hist or any other name.
Certificate record (CERT Record) – this store encryption certificates.
Let us quickly check how does a DNS resolution now works. We are now already aware of the types of records and information on zone. It is a good time to start with DNS resolution (the flow diagram is mentioned in the DNS Part I).
Setting the stage:

Figure-a
In the figure-a it is trying to depict here that there is a user machine (P1) which is connected to internet and trying to connect to a Web server for a webpage named as www.networkcnl.com. The user will open a web browser on the machine and types www.networkcnl.com on the address bar and hits enter. The user will see the webpage loading up in less than a second or two only if the information is not in its local machine as cache and depending how far the user is sitting from the Web server.
Now if we see the query flow in figure-b, which was also shown in Part-I, here these many queries happen in the backend or over the Internet or Intranet before the webpage appears in your browser.

Processes involved in end-to-end DNS resolution
The DNS resolution should happen before the page can load so that the browser will know how and with whom to build a TCP connection to make a HTTP request.
Once we enter a webpage in the web browser for example: www.networkcnl.com the browser asks the operating system (OS) for this specific page.
Processes involved in end-to-end DNS resolution
The DNS resolution should happen before the page can load so that the browser will know how and with whom to build a TCP connection to make a HTTP request.
Once we enter a webpage in the web browser for example: www.networkcnl.com the browser asks the operating system (OS) for this specific page.
- OS Recursive Query to DNS resolver
If the OS does not have the IP address of the website in its cache, it now queries a DNS resolver. The query that the OS makes here to the DNS resolver has a flag that tells it is a recursive query. This means that the DNS resolver must complete the recursion and the response must be either an IP address or an error. The DNS server will be the ISP (Internet Service Provider) or a server hosted in an organization and maintained by the same organization or any third-party organization. - DNS Resolver Iterative Query to the Root Server
The DNS resolver starts the querying for www.networkcnl.com to any or one of the root servers. It is not going to set the recursive flag on this time that will only mean it is a iterative query to the root server which in return should either provide the IP address of the webpage or the location of the web-server or an error. The root is defined here by the trailing dot (.) at the end of the address. Refer figure-c.

The root server will return a response with the address of the TLD location such as .com or .in or .edu and so on. The root does not has the IP address of the FQDN (Fully Qualified Domain Name) of www.networkcnl.com but it at least knows how to reach .com and thinks that .com might be knowing how to reach the requested domain.
- DNS Resolver Iterative Query Next to TLD (Top Level Domain):
The DNS resolver sends another iterative query to the TLD which in our case is .com name servers and ask for the location of the domain networkcnl.com. Now the TLD this query will be got to will be of type gTLD (generic TLD).
Now the TLD will send a response to the DNS resolver for the location of the name server that hosts networkcnl.com (this is not FQDN in our case this is only domain name).
A point to note, each TLD server holds a list of all the authoritative name servers for each domain in the TLD. The .com gTLD server does not have the IP addresses for networkcnl.com but it knows the location of networkcnl.com name server (NS). The .com responds with the whole list of ratnavo.com NS records.
For example: it will look like this ns1.networkcnl.com - DNS Resolver Iterative Query to the networkcnl.com NS
The NS for networkcnl.com gets an iterative query from the DNS resolver as where is www.networkcnl.com
The NS replies with a response with the IP address of the website as it has a host file that has information of the www.networkcnl.com with A record and AAAA record, TTL as well as it checks its zone file for location of www page i.e., it checks for the hostname too. The NS will handover the information only with what is being requested for.
- The DNS Resolved Replies to OS:
Finally, the DNS resolver replies to the OS with the IP address of the www.networkcnl.com.
The OS will cache the information in its local so that it knows the next time where to take the query if ever they need to talk to www.networkcnl.com but the cache entry does has its own limit, meaning, it will not stay there forever. It will be there as long as TTL is set.
After this DNS resolution process is completed then there will be a TCP handshake followed by TLS handshake and then HTTP request (all this information will be shared in our upcoming blog page).
Some information on BIND
Well BIND stands for Berkely Internet Name Domain and it is a program that can be downloaded from www.bind.org and can be installed in a Linux or Unix System that gives the ability to become a DNS server for a LAN or over public network. In other words, it means that it performs both the DNS server roles, acting as an authoritative name server for DNS zones and as a recursive resolver in the network.
Leave a Reply