Domain Name Resolution

The process of DNS requests being resolved to their associated IP addresses.
As we're getting into the name resolution section, it is worth stating that there is not one, but several types of name resolution of which one is Local Name Resolution.

Local Name Resolution

• As the name suggests, local name resolution occurs locally on the end user machine without contacting any external service or systems of any kind.
• This type of resolution operates with a host table, a simple text file consisting of static mappings between IP addresses and host names.
• The host’s table is the predecessor of DNS, and it was one of the earliest named systems ever created in computing.
• Back in the 1970s, when the internet, known as ARPANET at the time, was a small frontal community of a few hundred hosts, the host table was the only way of resolving hostnames.
• Owners of new hosts would send an email to Hosts master at sri-nickarpa, to request an address and a file named hosts.txt would be distributed by the Network Information Control Center and manually installed on each host on the network to provide a mapping between these names and their corresponding network addresses.
• Each machine would load the hosts table into memory upon booting and consulting it whenever a name needed to be resolved.
• No requests, referrals or servers were involved.
• Resolution was entirely local and under the direct control of the local computer’s administrator.
• Due to the dominant role of the host table in this entire process, local name resolution is also known as host table name resolution.

The host table is represented by the hosts file, which can be found under windows.
"C:\Windows\System32\drivers\etc\hosts"
In Linux, the host file can be found under the roots and then the folder,

Host table name resolution is based on the flat name architecture, which, as we know from the previous section and namespace, comes with significant limitations.

• Some of those limitations are:
• Difficulty in scaling
• Difficulty in ensuring name uniqueness
• Difficulty in maintaining consistency over the file across an expanding network.

As a result, the host table and its local name resolution eventually gave way to DNS and its hierarchical name resolution.
So, you might ask if the host table has been replaced by DNS, how come I still have it on my computer? And why do I need to know about it?
Even though the host table has been replaced by DNS, it can still be used in the following scenarios:

• Small Local Networks
• Improving Performance
• Redirecting local domains for various purposes
• Implementing basic URL filtering
• Bootstrapping
• Fallback name system in case DNS fails

Best Practices

• Create as few entries in the hosts file as possible
• Keep the content organized
• Use version control
• Enforce access control so that unauthorized users cannot modify the host’s file
• Always copy the hosts file before making any changes
• Comment out undesired mapping before deleting them
• Implement a mechanism to ensure name uniqueness.

Before talking about the resolution types of the domain name system, we should spend some time on the protocol's component that makes resolution possible in the first place.

DNS Resolver

As we have seen from previous section, name resolution dns uses, a client server model whereby a client sends a query to a server requesting that a specific domain be resolved into its corresponding IP address.

• The first server that receives the client request is the DNS Resolver, which sits between the client and the rest of the DNS ecosystem.
• Upon receiving the request, the resolver first sees if he can answer the request directly and if not, it assumes the role of the client and takes it upon itself to have the query resolved on behalf of the original client by contacting the root servers and progressing the name resolution process.
• After receiving the final answer from the requested domains, authoritative name server, the resolver saves the result query in its cache and forwards it to the original client.

Now you might ask, how does a DNS resolver know about the root servers?

• Well, the resolver has knowledge of the root servers thanks to its root hints file, which is where the root servers are stored.
• If we go back to the root servers, the https://root-servers.org/ website and scroll all the way down to the bottom of the page, we can say the following sentence as:

See also: AS112 | The root hints file (named.cache, root.ca, root.hints, ...) can be obtained via IANA's page for popular links

So long as the resolver, has the information included in this file, it will be able to contact the root servers while trying to resolve a domain name for its client.

• In a small office home office network, your DNS resolver is typically your router, or an IP address provided by your internet service provider.
• DNS resolver companies, on the other hand, usually have their own corporate resolver.
• Well, it is also possible to use an open DNS resolver for your environment, assuming a connection to the internet was established.
• The most well-known resolvers Google's is 8.8.8.8 and 8.8.4.4.
• So, you can, of course, use any other open resolver, such as 9.9.9.9, Cloudflare’s, 1.1.1.1, etc.
• A simple Google search on the available open DNS resolvers should provide you with a more comprehensive list.

Interestingly, though, virtually all the dns resolvers share the same function described so far, not all of them support the same features or operate in the same manner.

Differences between DNS Resolvers

• Some resolvers support EDNS0 (an extension to the DNS protocol we will discuss later) whereas some other do not.
• Many resolvers support negative caching but not all
• Not all resolvers use the same method in choosing which name servers to contact.
• Majority of DNS resolvers use a technique called Smooth Round Trip Time (SRTT) which is based on the lowest latency, while other resolvers select name service at random.

DNS Resolution Type

• Iterative resolution
• Recursive resolution

Iterative resolution

• Let's say we have a client that sends a DNS query to a server requesting information about a specific domain name.
• The queried server looks for the requested information in its own local data, and if it doesn't have the answer there, it returns a referral containing the names and addresses of the name servers closest to the domain name in the request to allow the resolution process to continue.
• It is worth noting that the referral includes all name server listed in its local data, and it's up to the client to choose which one to query next.
• The client must then iterate by sending a new request to this referred server, which again will return either an answer or another referral.
• The process continues until the correct server is found and an authoritative answer is given.
• The queries involved in this process are referred to as iterative, while the service responses are known as referrals.

Solidify your understanding of this topic, I would like you to think of iterative resolution as a series of rude telephone agents who simply answer your call and provide you with another number for you to ring.
Passing you the responsibility of contacting one department in their organization after the other until you are given the information you're looking for.

Final Point for Iterative resolution, it is a client's responsibility to keep querying servers until the required information is obtained.

Recursive resolution

• We will use a similar scenario featuring a client sending a DNS request to a server asking for the IP address of a domain name.
• In recursive resolution, upon receiving the client's request, the server once again checks if it possesses the information requested, in which case it passes an answer back to the client.
• If it doesn't, however, something special happens.
• Instead of simply replying to the client with a referral to appoint a name server as in the case of its iterative resolution, the server instead assumes the role of the client, and he takes on the responsibility of continuing with the name resolution process by sending a series of iterative requests down the dns tree, starting from the roots until it finds the authoritative answer for the domain name being requested and forwarded to the original client.
• In this type of resolution, the original client gets to send only a single query, which eventually returns information requested.
• That query is said to be a recursive query and recursive queries cannot be replied to with referrals. Instead, recursive queries compel the query server to find the requested information on behalf of the original client

Final Point for recursive resolution, it is the service responsibility to obtain the DNS information requested by the original client.

Caching

The purpose of caching computing is to temporarily store previously acquired data so that future requests for that data can be served faster.

• In the context of DNS, whenever its name is resolved, the resulting DNS information is cached so it can be used for subsequent requests that take place.
• This way, so long as the interesting DNS information remains cached, future requests against the same data which stopped the system that has cached the data in question.
• If we go back to our previous discussion on recursive resolution, we can say that there were quite a few DNS requests involved while the result of a server was trying to find the authoritative answer for the domain name requested by the client.
• It would be pointless and computationally taxing for the resolver to keep repeating the same queries for the same name that has just been resolved.
• What's more, repetitive DNS requests such as these consume network bandwidth and could result in DNS lookup latency.
• Thanks for caching. As soon as the resolver has the authoritative answer, it caches it before forwarding it to the client, which in turn places the result of data in its own cache to.

As a result, assuming that the result domain name is www.rjsnetworkcloudacademy.com for any future requests against that domain, the client will first consult with cache, which includes recently resolved DNS information as well as a mapping in the host table.
If there is no information about www.rjsnetworkcloudacademy.com in the cache, the client will then contact the resolver, which will check its own cache and return the answer to the client, which then cache his information for future reference.

• It is important to note that unsuccessful requests resulting in errors are also cached in what is known as negative caching.
• So, if www.youtube.com returned an error like this, domain doesn't exist. That error is cached in the same way that a successful resolution would have been.
• If the server doesn't have any relevant information in the cache at all, it will then proceed to sending the usual series of its requests until it finds the authoritative answer for www.youtube.com

Caching is, in fact, so important in DNS that dedicated DNS servers exist for the sole purpose of providing this very caching function only without having any authority over any domains.
These servers, unsurprisingly known as cache only DNS servers, and they often present in many network deployments.
We will learn more about cache only DNS servers in the configuration section.

Now, you might ask if caching is so important in DNS, how come there is a limited time for which result names remain cached?
In other words, why isn't resolved DNS information cached forever?

• Whether intentional or accidental changes do take place in the configuration of DNS name servers, and those changes can result in incorrect response to sense of queries due to cached information that is no longer valid.
• For instance, if the IP address of www.example.com changed to an IP address different to the one currently in cache, we would not be able to resolve the domain name anymore and instead we would get back error.
• Because of that reason, resolved names get cached for a finite amount of time, and the duration of that time frame is determined by a parameter known as time to live (TTL).

To view a DNS cache on window machine, open the command prompt and run 
“ipconfig /displaydns”

We can see that the resulting output is quite long, and it consists of every website we have browse.
We can also clear the cache as “ipconfig /flushdns”.

The DNS cache consists of recently resolved DNS information, as well as any mappings configured in the host table.

Few important point

• Most, but not all, DNS resolvers cache recently resolved requests.
• Not all queries are cached. For example, reverse queries are not cached. The same applies to any resolutions returning data perceived as unreliable or corrupted.
• Negative answers are cashed with a different TTL.
• A cache hit refers to whenever the client finds the information it's looking for inside the cache. The opposite of that is known as Cache miss.

DNS Name Resolution Workflow

• The process begins with an end user typing a domain name into their browser, such as www.example.com.
• Assuming the browser does not have any information about that domain in its DNS cache, it asks the client's operating system.
• The operating system checks its cache and hosts table for any data on www.example.com.
• Assuming he doesn't find any, a recursive query is then sent to the DNS resolver, which first checks its own DNS cache.
• If there is no relevant information there, either the DNS resolver consults its root hints file and contacts a root name server.
• The queried root name server sends back a referral containing a list of name servers for the dot com zone, along with their respective IP addresses.
• The DNS resolver then selects one of those named servers and sends iterative query for www.example.com.
• But queried dot com name server responds with a referral containing a list of name servers which are authoritative for the example.com domain.
• The DNS resolver selects one of those named servers and sends it and iterative query for www.example.com.
• The authoritative name server then replies with an authoritative answer containing the IP address of the domain in question.
• The DNS resolver then caches the information and forwards it to the client, that had transmitted the recursive query.
• The operating system declined, then places the same data into its own cache and passes it over to the browser, which would typically put the result name in its own cache too.

And so, this is the famous DNS name resolution process that you are required to know for your own academic knowledge, technical interviews, and daily work.

Reverse Name Resolution

A DNS request that is looking for the IP address of a domain name is known as a forward request. The opposite of a forward request is a reverse request.
In some situations, though, we might want to achieve the reverse outcome as we could have an IP address and wish to find domain name.
Well, the DNS is fully capable of supporting this functionality, to which unsurprisingly is referred to as reverse resolution (rDNS).

• Now, at this point, some of you might say hang on a minute. In the namespace section, we talked about the hierarchical name architecture of DNS and how it is structured so that a particular devices place can be determined by looking at its name.
• You would be 100 percent correct to say so, since the inner servers are arranged by name and not by IP address.
• So, if the DNS server are set up based on names and not IP addresses, how on earth is it possible for us to find a domain name based on an IP address?
• Would we not need a parallel hierarchy based on an IP?
• The answer is a resounding yes.
• That is exactly what we need.

To accommodate reverse resolution, DNS has a special domain called in-addr.arpa

Within that domain is a numerical hierarchy that covers the entire IP address space, and it contains four levels of numerical subdomains structured so that each IP address has its own node, and that node can contain an entry that points to the domain name mapped to that address.

After going to all the four level of numerical, we get the result as:

121.119.177.108.in-addr.arpa

• The in in-addr.arpa reverse name is illusion hierarchy covers the entire IPv4 address space and co-exists with a domain name hierarchy under the same root.
• The reason why we reversed the optics of the IP address contained in the reverse name is because unlike name resolution that proceeds from the list specific to the most specific element going from right to left. IP addresses have the least specific octet on the left and the most specific one on the right.
• In the interest of maintaining consistency with the DNS namespace, the octet are just flipped.
• It is worth noting that theoretically there should be a reverse entry for every IP address for the express reason of accommodating reversed name lookups.
• Reverse name lookups, though useful, are not considered critical for the function of internet so it is not mandatory for organizations to put in place reverse DNS entries for their IP addresses.

Use Cases for Reverse Name Resolution

• Troubleshooting: At times you might have an IP address and you won't find the domain name it is associated with.
• Filtering spam: Look at the IP address of an incoming email, and if no valid domain name is found, the message is blocked.
• Logging software: Reversed name lookups enable logging software to display not only IP addresses and log data, but also the human readable domain names for those IP addresses which are marked too.