DNS Protocol Analysis

DNS Messages

We know that the core function of name resolution is carried out by two different messages.

• Query: Sent by the client
• Response: Sent by the server

Each exchange of these messages is referred to as a transaction, and it is assigned a transaction ID by DNS.

• Thanks to the Transaction ID, if a client sends three different name requests to three different servers, we can easily find out which query initiated which response.
• This is an extremely useful feature that can be used when troubleshooting DNS issues or when conducting a forensic network analysis.

As a layer seven application, DNS must rely on a transport protocol layer four to transfer DNS messages from client to server and vice versa.
Most network protocols residing at the application layer usually rely on either TCP or UDP.
But DNS is interestingly one of the few protocols they use both depending on the operation taking place.

• For name resolution, where speed is of the essence, UDP is used as a transport protocol to carry both requests and responses, since UDP does not offer a reliable method of delivering messages. It is up to the client to keep track of the request sent so that if a response is not received at a specific time interval, the corresponding request can be retransmitted. In the interest of preventing excessive DNS traffic on the network, retransmissions are usually sent at an interval ranging from 2 to 5 seconds.
• TCP, on the other hand, is used when data must be delivered reliably, as is the case in scenarios such as zone transfers or when a DNS response requires more than 512 bytes of space.

In terms of size, all UDP DNS messages are limited to a payload of 512 bytes, though if a response message is larger than that, the message is then truncated and a special pin in the header is sent to indicate this outcome.
In such an event, the client would then be expected to retry the query over TCP instead, which doesn't have the same size limitation as UDP.
Transactions taking place over TCP remain a very small fraction of overall DNS traffic, regardless of which transport protocol is used.
The standard port of the server listens on by default is 53, while the port used by the client will always be an ephemeral one.

Other types of DNS messages outside the area of name resolution are:

• Notify: Allows master server to inform slave servers when the zone has changed code over UDP
• Update: Used to add or delete resource records or resource record sets from a specified zone, and it can be carried over either UDP or TCP depending on the size of the request.

DNS Response Codes (RCODES)

In an ideal world, we would like to see every single query that we make to result in a successful translation. Sometimes, however, we're not lucky, and DNS requests can fail to resolve for several reasons.
Whenever that happens, we want to get a first hint behind the failure encountered so that we can troubleshoot the problem effectively, identify the root cause of the issue and eventually fix it.
That's where rcodes come in.
Rcodes indicate whether a narrow condition exists in the response, and each code corresponds to a numeric value.

Most common RCODES that can be found in response messages:

• 0 NoError – No Error
• 1 FormErr – Format Error - which means that the name server was unable to interpret the query.
• 2 ServFail – Server Failure - means that the name server was unable to process this query due to a problem with the name server.
• 3 NXDomain – Non-Existent Domain - which signifies other domain name reference in the query does not exist.
• 4 NotImp – Not Implemented – which means is that the name server does not support the request, that kind of query.
• 5 Refused – Query Refused - which means that the query was refused since the nameserver refused to perform the specified operation for policy reasons.

The full list of RCODES can be found on the flip charts.
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6

DNS Header

The DNS header consists of a series of field, and we are going to inspect each one in turn.

• The first field in the DNS header is the transaction ID field that we talked about earlier on, in the section once again. Its purpose is to associate DNS queries with their corresponding responses.
• Then we have several flags, starting with a:
• QR bit, which indicates whether the header is for a query represented by a zero or a response represented by one.
• OPCODE - Specify. the query type, each DNS OPCODE is assigned a name.
• AA stands for authoritative answer, and it is valid in responses. Its specifies that the responding nameserver is an authority for the domain name being requested.
• TC stands for truncation, which is said when a message is truncated due to its length being greater. than the maximum size, which is 512 bytes.
• RD stands for Recursion Desired, which is a bait that is said in the query upon the client sending a recursive request to the DNS resolver.
• RA stands for Recursion Available, which denotes whether the name server that is responding. Indeed, supports recursive queries.
• Z reserved for future use, and it must be zero in all queries and responses.
• AD stands for authentic data, while CD stands for checking disabled, both flags are relevant to the DNS mechanism.
• Response codes abbreviated as RCODES. And like we've discussed earlier; they indicate whether an error condition exists in the response.
• Then we have an unsigned integer field:
•  query count that represents the number of questions.
• Then we have the answer count field that represents the number of answers
• NSCount or upcount, which represents the number of authoritative resources records
• ARCOUNT which represents the number of additional records.

DNS Data Storage

Early in the course, we talked about name resolution and how it resolved can find the authoritative answer to a query via a series of iterative requests against servers down for domain name hierarchy.
Obviously, those servers must store that kind of information somewhere to be able to respond to the DNS queries.
And so, in this section, we will study the way the DNS data is stored and organized in name servers.
Again and again throughout the course, we have been referring to the DNS as a globally distributed. collection of databases.
This principle extends to DNA storage as well, since the DNS data is stored in a database that is known as a Zone.

There are two types of zones:

• Forward Lookup Zone: Used for resolving names to IP addresses, and it's the zone where most of the DNS data is stored.
• Reverse Lookup Zone: The reverse lookup Zone, on the other hand, mainly stores information used for reverse name resolution.

Each of these zones is a collection of what we called as Resource records (RRs), and just like the records of any database, various sets of fields organized in rows.
There are many types of resource records and DNS, and each resource record type contains a specific set of data.

Common RR Format

• Name of the Record
• Type of the Record
• Class of the Record
• TTL value
• Resource data length
• Resource data

Types of Resource Record

State of Authority (SOA)

• The SOA record indicates the beginning of his own, and it should be the first resource record specified in any zone file.
• There can be only one Start of authority record per zone.

Format

The format of the set of authority record is as follows.

<domain name> <TTL> <class> SOA <m-name> <r-name> (
                         <serial number>
                         <refresh interval>
                         <retry interval>
                         <expire interval>
                         <minimum>
)

• We have the domain name, followed by a time to live value, followed by the resource record class, which, should be in standing for internet in 99 percent of cases.
• Then we've got the resource record type start up authority in this case, then we have the m-name field, which is the name of the primary authoritative name server for the zone.
• And it is this name server that secondary DNS servers receive updates from in relation to the zone.
• I know we haven't talked about primary and secondary name servers yet, as those are concepts, we will explore in the configuration section.
• For now, just make a note of the m-name field represents the primary name server for the zone.
• Next, we have the r-name field, which signifies the email address of the administrator responsible for the zone.
• Although the value represents an email address, you will be surprised to learn that there is no @ sign in it, as far as the start of Authority rack is concerned in this case.
• Info.example.com is the same thing as info@example.com 
• And then within a pair of brackets, we have the serial number, which is the version number of the zone, and it is incremented by one, every time a change is made to the zone file.
• Then the refresh interval, the retry interval and the expire interval have to do with primary and secondary name service.
• And finally, we have the minimum field. 
• The historical purpose of this parameter was to hold the default TTL value for records without an explicit time to live value defined.
• But nowadays, the minimum parameter represents the TTL value for negative caching.
• If you remember back in our section on caching, we said that negative answers are cached with a different TTL, and that different kind of TTL is no other than this very parameter.

To query the start of authority record, we can use a tool like Dig (for Linux machine) and nslookup (for window machine).
On window machine on command prompt:

nslookup -type=soa <hostname/IP address>

Name Server (NS) Record

• The NS records point to the authoritative name server of his own, and it is these name servers that hold the actual DNS information for a domain so that domain can be accessible to internet users.
• If a domain, such as example.com doesn't have any NS records configured in its zone.
• There wouldn't be any references to that domain name servers, which means that mean the .com TLD server contacted would not be able to return a list of name server, for example .com which in turn means that nobody would be able to browse to that domain.
• In other words, it is the NS records that ensure the availability of a domain.
• Because of that reason, every zone must have at least two NS records, of which each one points to a different name server for redundancy.
• That way, if one name server goes down or becomes unavailable, DNS queries can go to a different name server.
• To that end, name servers also typically reside in topological separate networks for further resiliency.

When it comes to registering a domain, many DNS service providers by default provisioning sets of 4 name servers, and they will be listed as:

• ns1.example.com
• ns2.example.com
• ns3.example.com
• ns4.example.com

Format

<domain name> <TTL> <class> NS <nameserver’s hostname>

• Its syntax consists of a domain name such as example.com, a TTL value and resource record class, which in 99 percent of cases should be in for internet.
• And then resource record type, in these case NS record and finally the name servers hostname such as ns1.example.com

Querying the NS record with a tool like Dig or Nslookup
On a Windows machine.

nslookup -type=ns <hostname/IP address>

Address Records (A)

• A resource record that stores the association between a domain name and IP address is the address or A record.
• A record is that primary record in DNS and it is queried in forward looking requests.

Format

<domain name> <TTL> <class> A <IPv4 address>

It simply contains a domain name, TTL value, a resource record class, a resource record type, which in this case is A and an IPv4 address.

Querying the A record on a Windows machine.

nslookup -type=a <hostname/IP address>

Quad-A Record (AAAA)

• The cousin of the A record is a Quad-A record, which stores a domain name and a IPv6 address.
• The reason why it's represented by 4A is to signify that the value stored in it is four times as big as the one stored in the A record.
• Considering that an IPv4 address has 32 bits and, IPv6 address has 128 bits.

Format

<domain name> <TTL> <class> AAAA <IPv6 address>

Its format is very similar to that of the A record, as it consists of a domain name, a TTL value, resource record class, resource record type, which in this case is AAAA and finally, an IPv6 address.
It is important to note that it is perfectly possible for A record and AAAA record to point at the same domain, in cases where dual stack is required.

Querying the AAAA record on a Windows machine.

nslookup -type=aaaa <hostname/IP address>

Pointer Record (PTR)

• As we know from previous section, however, DNS also supports reverse resolution for situations where we have an IP address and want to resolve it to its associated name.
• There is also record that allowed this to happen is a Pointer record, i.e., PTR. which points an IP address to a host name.

Format

<reverse domain name> <class> PTR <domain name>

The formats of the point of record features, a reverse domain name which release the IP address we have in reverse format, followed by the .in-addr.arpa which, if you remember from our section on reverse name resolution, is a special domain representing the numerical hierarchy of DNS that covers the entire IPv4 address space.
Then we have a resource record class, a resource record type, which is PTR, pointer record in this case.
And finally, the FQDN of the domain name that the IP address points to.

• The same principles apply to PTR records storing IPv6 address as well, with the main difference is being that the domain appended to the reverse IPv6 address is not .in-addr.arpa but .IP6.arpa which is a different namespace under the dot arpa TLD.
• As they are designed to facilitate reverse name solution, pointer record is placed inside the revers lookup zone, which is something we're going to see in more detail in the configuration section.

Querying the PTR record on a Windows machine.

nslookup -type=PTR <hostname/IP address>

Canonical Name Record (CNAME)

• We are going to discuss yet another resource record type, which makes a frequent appearance in DNS configuration, troubleshooting and name resolution, and it is the CNAME record.
• C name stands for canonical name, which is a real name of an object referenced by an alias. In other words, this record basically maps one domain name to another.

Format

<alias> <class> CNAME <TTL> <canonical name>

It consists of an alias such as www.example.com, a resource record class which is in for internet in 99 percent of cases.
A resource record type, CNAME in this case, a TTL value and a canonical name or the real name that www.example.com points to, which is example.com.

Querying the CNAME record on a Windows machine.

nslookup -type=cname <alias>

Use Cases of CNAME

• Map subdomains to their apex domain such as www.example.com to example.com
• Redirect multiple TLDs to the same second level domain.
• For example, if you have mydomain.com.au and mydomain.com.nz, they both can be directed to mydomain.com
• Validate ownership or control of a domain.

Restrictions

• A CNAME record must always point to another domain name and never directly to an IP address.
• A CNAME record cannot point to an NS or MX record.
• A CNAME record cannot co-exist with another record for the same name.

Best Practice

• A CNAME can point to another CNAME, a mechanism that is known as CNAME chaining. However, this is not recommended as it requires multiple DNS lookups before the internet domain can be loaded, which slows down the name resolution process and in turn, impacts user experience. It is considered best practice, therefore, not to use the CNAME chaining, and point CNAME records directly to canonical names.

Text Record (TXT)

The DNS ‘text’ (TXT) record lets a domain administrator enter text into the Domain Name System (DNS). The TXT record was originally intended as a place for human-readable notes. However, now it is also possible to put some machine-readable data into TXT records. One domain can have many TXT records.

Example of a TXT record:

example.com	record type:	value:	TTL
@	TXT	This is an awesome domain! Not spammy.	32600

Format

<domain name> <class> TXT <TTL> <textual data>

Format of the text record is probably the easiest one to remember, as it consists of a domain name, a resource record class, a resource record type, which in these cases is TXT, and time to live value and some textual information.

• Interestingly, even though the official format for storing data in a record theoretically involves using attribute value pairs limited by an equal sign and enclosed by quotation marks.
• Domain administrators are still able to use their own formats, which is a testament to the flexibility of the text record.
• The data that can be placed inside its value could be any text that the administrator wants to associate with their domain.
• Though the value of this record was originally intended as a place for human readable notes, it is now possible to put machine readable data as well.
• It is also perfectly possible for one domain to be associated with many TXT records.

Querying the TXT record on a Windows machine.

nslookup -type=txt <domain name>

Use Cases

• Associating domains with textual data
• Proving domain ownership
• Strengthening email security

Mail Exchange Record (MX)

• We're going to have a look at yet another very common record in DNS, which is known as mail exchange record (MX).
• Just like every other record in the DNS database, the MX record, too, serves as a mapping between two values.
• More specifically, the MX record maps a domain to an email server.
• Email has always been heavily reliant on DNS, perhaps more so than any other TCP IP based application, and MX records provide the necessary infrastructure for it to work.

Format

<domain name> <class> MX <TTL> <preference-value> <email-server>

It consists of a domain name, a resource record class, a resource record type which obviously is MX, the time to live value, the preference value, and the hostname of an email server.

• The first question that comes to mind when inspecting the format of the MX record is why does it not feature the @ symbol?
• Shouldn’t it be primaryemail@www.example.com instead of primaryemail.www.example.com
• Well, as e-mail clients, whenever we send an email to any recipient, we use the @ sign as a means to separate the mail server from the domain it is meant to receive emails for.
• For instance, support@example.com.
• As well as the name servers are concerned. the names of mail servers inside their MX records are configured with dots and not @.
• Another interesting part of the MX record is the preference value.
• The preference value allows a DNS administrator to specify multiple e-mail service so that if the first server specified is down, emails will be forwarded to the backup email server, thus achieving redundancy. 
• The lower the preference value of the email server, the higher the priority of that server will be. It is also possible to specify multiple backup email servers too.
• Finally, somebody might say, okay, that is all well and good, but how can the authoritative name server know of the email server’s location?
• Shouldn't there be an additional record that in turn maps the hostname of that server to an IP address? And the answer is yes.
• A record would indeed need to be defined alongside the mixed record so that the name server can forward email to the correct endpoint.
• Additionally, A records would typically be created for as many email server the domain is associated with.

Querying the MX record on a Windows machine.

nslookup -type=mx <domain name>

Domain Name Registration

Hierarchy

As the name suggests Name registration involves the registration of domains.
A domain represents a public identity on the internet, and it's used to identify the IP address of the computer system hosting web content.
To ensure that each domain is unique, Name registration has to be processed within a globally distributed framework designed to enforce a certain set of rules.
That framework is the domain name registration hierarchy.

• At the top of the hierarchy, Rules ICANN, a non-profit, internationally organized corporation that stands for Internet Corporation for Assigned Names and Numbers.
• Its main role is to oversee the huge and complex, interconnected network of unique identifiers that allow computers on the internet to find one another.
• ICANN is responsible for managing generic TLDs or country-code TLDs, managing how root name server systems function, coordinating how IP addresses are supplied to avoid repetition or clashes, and maintaining a central repository of IP addresses.
• Below ICANN are five regional internet registries.
• And each registry is responsible for obtaining IP ranges from ICANN to allocate them to internet service providers across a specific geographic region.
• Subordinate to the registries are the registrars, which are ICANN accredited organizations responsible for processing the registration of domain names.
• Examples of registrars are GoDaddy, Namecheap and Bluehost.
• After registrars come resellers, resellers are third party companies that offer domain name registration services through registrars.
• An example of a well-known reseller is Route 53.
• The dedicated DNS and registration as a service provided by AWS.
• Route 53 is the reseller of two registrars.
• Amazon Registrar for Generic TLD and candy for all other top-level domains.
• And at the bottom of the hierarchy are the registrants, the people or organizations who register domains through a register or a reseller.

Process

The process of registering a domain name consists of the following steps:

• The registrant chooses a domain name and submits a request to registries with a reseller or a ICANN accredited registrar.
• Provided that the domain names available, the registrar registers the name and then creates who is record.
• The who is record contains the registrant’s name and contact information, the name and contact information of the registrar, the registration date, the name servers, the most recent update, and the expiration date.
• Who is records may also provide the administrative and technical contact information of the registrant.
• The registrar will then send your domain name request along with the contact and technical information of the domain name to the appropriate registry.
• And in turn, the registry will file all information provided, and it will add the names on file to the master servers, which will tell other servers on the internet where your website is located.

Considerations when choosing a TLDs

There are currently more than 1500 TLDs to choose from, which include,

• Generic TLDs
• Country-code TLDs
• Infrastructure TLDs
• Sponsor TLDs
• IDNTLDs
• Geographic TLDs

Not all TLDs will suit your requirement, so we have to take consideration, and asked below few questions to choose TLDs

• DNSSEC support? Security related feature to avoid DNS cache poisoning, and many more.
• IDNs support? IDNs mean International Domain Name
• Privacy protection? For protecting the privacy of website information     
• Target audience? Is the organization being regional specific, such as health care provider?
• Relevant field? What the field of business such as .cafe or .coffee
• Local presence requirements?

Choosing a Second-Level Domain

Name Consideration
Do:

• Use keywords that reflect your industry.
• Use localized keywords if applicable.
• Try to keep it short with less than 10 characters.
• Ensure it is easy to spell.
• Ensure it is easy to pronounce.
• Ensure it is easy to remember.

Don’t:

• Use hyphens, numbers, acronyms.

Choosing a Registrar

• First and foremost, pricing and by pricing, we mean the registrar's registration fee, the renewal fee and the other potential charges for things like the domain transfers, for example.
• Most registrars do not charge a fee, but some do.
• Any potential cost benefits, such as bulk pricing options or promotion deals like registering a domain name for several years at a cheap price.
• Add-On services such as Web hosting services, WordPress hosting services, website builders, email hosting services, brokerage services, privacy protection, SSL protection, customer service support.
• Some of the registrar offered 24-7 support. Some others do not.
• Supported TLDs that was a big one, is usually supported. Not all registrars have the license to sell all top-level domains.
• Policies such as the domain transfer.
• What is the registrar policy and the domain transfers? What is that policy on domain expiration?
• Domain names registered for a specific duration and when they expire, some registrars offer a grace period even after the expiration, to allow you to renew your expired domain name.
• Other registrars, on the other hand, can exercise predatory practices, such as buying your expired domain name as soon as it expires, so they can sell it back to you a much higher price.
• Always read customer reviews while carrying out your research on which registrar you should choose.
• Finally, remember there is a best practice.
• It is recommended that you register your domain name on the registrar but hosted on another provider simply because it is usually easier to switch hosting companies if required later on. Provided that a domain name is hosted on a platform different to the one it was registered on.

EPP Status Codes

Extensible provisioning protocol domain status codes, also known as domain name status codes, indicate the status of a domain name registration.
Every domain has at least one status code, if not more.
Each EPP code provides useful information about a domain that comes in handy for operations such as:

• Troubleshooting domain related issues
• Domain renewals
• Domain transfers between registrars.

There are two different types of EPP status:

• Client codes
• Server codes

Client status codes are set by registrars, and depending on the registrar, they are set upon registering the domain or when requesting it.
Server status codes, on the other hand, are set by registries, and they take precedence of a client code sense.
If you remember from a previous section, registries reside higher up in the domain name registration hierarchy than registrars.

Some examples of Client codes are:

• clientHold: It is a status code that tells your domains registry to not activate your domain in the DNS and therefore, it will not resolve. It is an uncommon status that is usually active during legal disputes, non-payment or when your domain subject deletion.
• clientTransferProhibited: It is a status code that tells your domains registry to reject requests to transfer the domain from your current registrar to another.
• clientUpdateProhibited: It is a status code that tells your domain registry to reject requests to update the domain.

Some examples of server codes are:

• OK: It Is the standard status for a domain, meaning that it has no pending operations or prohibitions
• autoRenewPeriod:It is a grace period provided after a domain name registration period expires and is extended or renewed automatically by the registry. If the registrar deletes the domain name during this period, the registry provides a credit to the registrar for the cost of the renewal.
• serverTransferProhibited: It is a status code that prevents your domain name from being transferred from your current registrar to another. It is an uncommon status that is usually active during legal or other disputes at your request or when a redemption period status is in place.

You can inspect the EPP codes of any domain you're interested in simply by performing a whois lookup against it.
All you need to do is to navigate to an online page: https://lookup.icann.org/

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.

Domain Name Space

What is DNS hierarchy?

The DNS hierarchy, also called the domain name space, is an inverted tree structure. The DNS hierarchy tree has a single domain at the top of the structure called the root domain – indicated by the “.” as we have mentioned. Below the root domain are the top-level domains that divide the DNS hierarchy into segments containing second-level domains, sub-domains, and hosts.

Hence, the DNS hierarchy is comprised of the following five levels:

• Root Level Domain
• Top Level Domains (TLD)
• Second Level Domains (SLD)
• Subdomains
• Hosts

Within the hierarchy, the resolution process starts at the Root Level DNS, the Top-Level DNS, working its way down to the Second Level DNS, then through any number of sub-domains until we get to the actual hostname we want to resolve into an IP address.

DNS Architecture

Domain Name format are examined from right to left because that is the direction that a domain name is interpreted. What I mean by that is contrary to the way we type a domain name into a browser from left to right.
For instance, www.rjsnetworkcloudacademy.com domain names are interpreted by DNS the other way around, from right to left.

• The first component for domain name starting from right to left is the Root represented by a dot.
• After the Root comes, the Top-Level Domain (TLD). We will not go into depth now at this stage, since there's going to be an entire module dedicated to TLD further.
• What follows a Top-level domain is the second level domain, which in this case is rjsnetworkcloudacademy.
• The second level domain, along with a Top-level domain, make the Zone apex otherwise known as Naked domain or Apex domain.
• Finally, the third level domain is usually something like www, which is more of a naming convention rather than a necessity, if it came down to creating a domain name for, say, your website.

The components of a domain name are known as Labels, with a Root being said to have a Label of Null.
Each label is a subdomain of its parent domain.
For instance, www is a subdomain of rjsnetworkcloudacademy.com, while rjsnetworkcloudacademy is a subdomain of the .com top-level domain.

The entire domain name stretching all the way from the Root down to the third level domain is known as the Fully Qualified Domain Name (FQDN), which is the absolute reference to a domain name.

Finally, it is important to note that the reason why the dots representing the root is colored differently to the other dots is because the first is a special dot, while the other dots serve as the limiters separating the labels of a domain.

A few more things to keep in mind in relation to the syntax of a domain name.

• Each label can be up to 63 characters long.
• The characters allowed and labels can be A-Z uppercase/lowercase, digits from zero all the way to nine and hyphen (-). This rule is known as the LDH rule (Letters, Digits, Hyphen).
• Labels may not start or end with a hyphen.
• An additional rule requires a top-level domain name should not be all numeric.
• There is no maximum limit on the number of subdomains. However, a domain name inside can be up to 255 characters in total, including the dots.

Root Level Domains

The DNS root level is the highest in the DNS hierarchy tree because it is the first step in resolving a domain name. The root DNS server is the DNS for the root zone. It handles requests for records in the root zone and answers other requests by providing lists of authoritative name servers for the appropriate TLD (top-level domain). These are the authoritative nameservers that serve the DNS root zone. These servers contain the global list of the top-level domains. The root zone contains the following:

• Organizational hierarchy – such as .com, .net, .org, .edu.
• Geographic hierarchy – such as .ca, .uk, .fr, .pe.

Currently, there are 13 root name servers specified, with logical names in the form “letter.root-servers.net”, where letter ranges from “A” to “M” and represent companies like Verisign, University of Maryland, NASA, and The Internet Corporation for Assigned Names and Numbers (ICANN). https://root-servers.org/ for more details.

Previously, there were only single servers for each of the 13 IP addresses. Today, there are server clusters for each of them meaning there are hundreds of servers all around the world. They use Anycast DNS routing for load-balancing and better-decentralized performance.

 Top-Level Domains

The next level in the DNS hierarchy is Top-Level Domains or TLDs, for short. There are over 1000 TLDs covering everything from “.abb” to “.zw” and still growing. As we have seen, the TLDs are classified into two subcategories: organizational hierarchy and geographic hierarchy.

• The organizational hierarchy is divided into domains for the likes of commercial enterprises (“.com”), government entities (“.gov”), educational institutions (“.edu”), and nonprofit organizations (“.org”).
• The geographic hierarchy, meanwhile, represents the country where the domain is hosted. Examples include “.ca” for Canada, “.uk” for the United Kingdom, “.au” for Australia, and even “.aq” for Antarctica.

Organizations that want to cater to their local customers can opt for TLDs that use both organizational and geographical hierarchies. Examples would be: “.com.et” for an Ethiopian business, “.org.al” for an organization in Albania, and “.gov.it” for the Italian government.
https://www.iana.org/domains/root/db for more details.

Second-Level Domains

• A domain is a second-level domain if it is contained within a top-level domain. A second-level domain is a label – usually, a name related to the website or the business that owns it – immediately to the left of the top-level domain and separated by a dot.
• In the Domain Name System (DNS) hierarchy, a second-level domain (SLD or 2LD) is a domain that is directly below a top-level domain (TLD). For example, in “rjsnetworkcloudacademy.com”, “rjsnetworkcloudacademy” is the second-level domain of the “.com” TLD.

Subdomains

• A subdomain – sometimes referred to as “third-level domains.” – is related to the root domain and is denoted on the left as a second-level domain. In the URL “blog.rjsnetworkcloudacademy.com” the subdomain address would be “blog.”
• Trivia: the “WWW” in www.rjsnetworkcloudacademy.com is also a sub-domain, although it isn’t always necessary to type it in a domain name.

Hosts

The host part of an FQDN is used to identify an individual device – usually a server. In the FQDN “myserver.example.com” the hostname would be “myserver.”