DNS Server

What is DNS server and how it works?

A DNS server is a type of name server that manages, maintains and processes Internet domain names and their associated records. In other words, a DNS server is the primary component that implements the DNS (Domain Name System) protocol and provisions domain name resolution services to Web hosts and clients on an IP-based network.

 What is DNS?

The Domain Name Systems (DNS) is the phonebook of the Internet. Humans access information online through domain names, like nytimes.com or espn.com. Web browsers interact through Internet Protocol (IP) addresses. DN S translates domain names to IP Address so browsers can load Internet resources.

Each device connected to the Internet has a unique IP address which other machines use to find the device. DNS servers eliminate the need for humans to memorize IP addresses such as 192.168.1.1 (in IPv4), or more complex newer alphanumeric IP addresses such as 2400:cb00:2048:1::c629:d7a2 (in IPv6).

How does DNS work?

The process of DNS resolution involves converting a hostname (such as www.example.com) into a computer-friendly IP address (such as 192.168.1.1). An IP address is given to each device on the Internet, and that address is necessary to find the appropriate Internet device – like a street address is used to find a particular home. When a user wants to load a webpage, a translation must occur between what a user types into their web browser (example.com) and the machine-friendly address necessary to locate the example.com webpage.

In order to understand the process behind the DNS resolution, it’s important to learn about the different hardware components a DNS query must pass between. For the web browser, the DNS lookup occurs “ behind the scenes” and requires no interaction from the user’s computer apart from the initial request.

There are 4 DNS servers involved in loading a webpage:

DNS recursor – The recursor can be thought of as a librarian who is asked to go find a particular book somewhere in a library. The DNS recursor is a server designed to receive queries from client machines through applications such as web browsers. Typically the recursor is then responsible for making additional requests in order to satisfy the client’s DNS query.

Root nameserver – The root server is the first step in translating (resolving) human readable host names into IP addresses. It can be thought of like an index in a library that points to different racks of books – typically it serves as a reference to other more specific locations.

TLD nameserver – The top level domain server (TLD) can be thought of as a specific rack of books in a library. This nameserver is the next step in the search for a specific IP address, and it hosts the last portion of a hostname (In example.com, the TLD server is “com”).

Authoritative nameserver – This final nameserver can be thought of as a dictionary on a rack of books, in which a specific name can be translated into its definition. The authoritative nameserver is the last stop in the nameserver query. If the authoritative name server has access to the requested record, it will return the IP address for the requested hostname back to the DNS Recursor (the librarian) that made the initial request.

What’s the difference between an authoritative DNS server and a recursive DNS resolver?

Both concepts refer to servers (groups of servers) that are integral to the DNS infrastructure, but each performs a different role and lives in different locations inside the pipeline of a DNS query. One way to think about the difference is the recursive resolver is at the beginning of the DNS query and the authoritative nameserver is at the end.

Recursive DNS resolver

The recursive resolver is the computer that responds to a recursive request from a client and takes the time to track down the DNS record. It does this by making a series of requests until it reaches the authoritative DNS nameserver for the requested record (or times out or returns an error if no record is found). Luckily, recursive DNS resolvers do not always need to make multiple requests in order to track down the records needed to respond to a client; caching is a data persistence process that helps short-circuit the necessary requests by serving the requested resource record earlier in the DNS lookup.

Authoritative DNS server

Put simply, an authoritative DNS server is a server that actually holds, and is responsible for, DNS resource records. This is the server at the bottom of the DNS lookup chain that will respond with the queried resource record, ultimately allowing the web browser making the request to reach the IP address needed to access a website or other web resources. An authoritative nameserver can satisfy queries from its own data without needing to query another source, as it is the final source of truth for certain DNS records.

It’s worth mentioning that in instances where the query is for a subdomain such as foo.example.com or blog.digitalduniya.com, an additional nameserver will be added to the sequence after the authoritative nameserver, which is responsible for storing the subdomain’s CNAME record.

There is a key difference between many DNS services and the one that Cloudflare provides. Different DNS recursive resolvers such as Google DNS, OpenDNS, and providers like Comcast all maintain data center installations of DNS recursive resolvers. These resolvers allow for quick and easy queries through optimized clusters of DNS-optimized computer systems, but they are fundamentally different than the nameservers

What are the steps in a DNS lookup?

For most situations, DNS is concerned with a domain name being translated into the appropriate IP address. To learn how this process works, it helps to follow the path of a DNS lookup as it travels from a web browser, through the DNS lookup process, and back again. Let’s take a look at the steps.

Note: Often DNS lookup information will be cached either locally inside the querying computer or remotely in the DNS infrastructure. There are typically 8 steps in a DNS lookup. When DNS information is cached, steps are skipped from the DNS lookup process which makes it quicker. The example below outlines all 8 steps when nothing is cached.

The 8 steps in a DNS lookup:

A user types ‘example.com’ into a web browser and the query travels into the Internet and is received by a DNS recursive resolver.

The resolver then queries a DNS root nameserver (.).

The root server then responds to the resolver with the address of a Top Level Domain (TLD) DNS server (such as .com or .NET), which stores the information for its domains. When searching for example.com, our request is pointed toward the .com TLD.

The resolver then makes a request to the .com TLD.

The TLD server then responds with the IP address of the domain’s nameserver, example.com.

Lastly, the recursive resolver sends a query to the domain’s nameserver.

The IP address for example.com is then returned to the resolver from the nameserver.

The DNS resolver then responds to the web browser with the IP address of the domain requested initially.

Once the 8 steps of the DNS lookup have returned the IP address for example.com, the browser is able to make the request for the web page:

The browser makes a HTTP request to the IP address.

The server at that IP returns the webpage to be rendered in the browser (step 10).

What is a DNS resolver?

The DNS resolver is the first stop in the DNS lookup, and it is responsible for dealing with the client that made the initial request. The resolver starts the sequence of queries that ultimately leads to a URL being translated into the necessary IP address.

Note: A typical uncached DNS lookup will involve both recursive and iterative queries.

It’s important to differentiate between a recursive DNS query and a recursive DNS resolver. The query refers to the request made to a DNS resolver requiring the resolution of the query. A DNS recursive resolver is the computer that accepts a recursive query and processes the response by making the necessary requests.

What are the types of DNS Queries?

In a typical DNS lookup three types of queries occur. By using a combination of these queries, an optimized process for DNS resolution can result in a reduction of distance traveled. In an ideal situation cached record data will be available, allowing a DNS name server to return a non-recursive query.

3 Types of DNS queries:

Recursive query – In a recursive query, a DNS client requires that a DNS server (typically a DNS recursive resolver) will respond to the client with either the requested resource record or an error message if the resolver can’t find the record.

Iterative query – in this situation the DNS client will allow a DNS server to return the best answer it can. If the queried DNS server does not have a match for the query name, it will return a referral to a DNS server authoritative for a lower level of the domain namespace. The DNS client will then make a query to the referral address. This process continues with additional DNS servers down the query chain until either an error or timeout occurs.

Non-recursive query – typically this will occur when a DNS resolver client queries a DNS server for a record that it has access to either because it’s authoritative for the record or the record exists inside of its cache. Typically, a DNS server will cache DNS records to prevent additional bandwidth consumption and load on upstream servers.

What is DNS caching? Where does DNS caching occur?

The purpose of caching is to temporarily stored data in a location that results in improvements in performance and reliability for data requests. DNS caching involves storing data closer to the requesting client so that the DNS query can be resolved earlier and additional queries further down the DNS lookup chain can be avoided, thereby improving load times and reducing bandwidth/CPU consumption. DNS data can be cached in a variety of locations, each of which will store DNS records for a set amount of time determined by a time-to-live (TTL).

Browser DNS caching

Modern web browsers are designed by default to cache DNS records for a set amount of time. the purpose here is obvious; the closer the DNS caching occurs to the web browser, the fewer processing steps must be taken in order to check the cache and make the correct requests to an IP address. When a request is made for a DNS record, the browser cache is the first location checked for the requested record.

In chrome, you can see the status of your DNS cache by going to chrome://net-internals/#dns.

Operating system (OS) level DNS caching

The operating system level DNS resolver is the second and last local stop before a DNS query leaves your machine. The process inside your operating system that is designed to handle this query is commonly called a “stub resolver” or DNS client. When a stub resolver gets a request from an application, it first checks its own cache to see if it has the record. If it does not, it then sends a DNS query (with a recursive flag set), outside the local network to a DNS recursive resolver inside the Internet service provider (ISP).

When the recursive resolver inside the ISP receives a DNS query, like all previous steps, it will also check to see if the requested host-to-IP-address translation is already stored inside its local persistence layer.

The recursive resolver also has additional functionality depending on the types of records it has in its cache:

If the resolver does not have the A records, but does have the NS records for the authoritative nameservers, it will query those name servers directly, bypassing several steps in the DNS query. This shortcut prevents lookups from the root and .com nameservers (in our search for example.com) and helps the resolution of the DNS query occur more quickly.

If the resolver does not have the NS records, it will send a query to the TLD servers (.com in our case), skipping the root server.

In the unlikely event that the resolver does not have records pointing to the TLD servers, it will then query the root servers. This event typically occurs after a DNS cache has been purged.

DNS Zones

A DNS Zone is a portion of the DNS namespace that is managed by an organization or administrator. It serves as an administrative space with granular control of DNS components and records, such as authoritative nameservers. There is a common misconception that a DNS zone associates only with a single domain name or a single DNS server. In actuality, a DNS zone can contain multiple domain and subdomains. Multiple zones can also exist on the same server.  Information stored for a DNS zone lives within a text file called a DNS zone file.

 DNS Zone Files

A DNS Zone file is a plain text file stored on a controlling DNS server that contains all the records for every domain within a given zone. Zone files can include many different record types, but must always begin with what is called an SOA record (Start of Authority).

 Types of Records

As mentioned, there are a handful of different types of records used within a DNS Zone, all of which serve a unique purpose. Below are some examples of the most commonly used record types and a brief description of each.

Start of Authority (SOA)

The first record in any zone file is the SOA resource record. This record is an essential part of the DNS zone file. It indicates the domain’s zone and the fundamental properties of the domain name server. Each zone file can contain only one SOA record.

Name Server (NS)

NS records tell recursive name servers which name servers are authoritative for a zone. Recursive name servers look at the authoritative NS records to facilitate which server to ask next when resolving a name.

Note

The only zone file that matters is the one located at the authoritative name server for the domain. You can find which name servers the internet will look at through a who is lookup on the domain.

Mail Exchange (MX)

MX records, usually two, are responsible for specifying which mail server is in charge of receiving email messages on behalf of a site. The email client tries to make an SMTP connection to the primary mail server listed in the zone file. The records are ranked by priority from lowest to highest with the lowest being the primary. If the primary server is not available, the next listed mail server will attempt a routing connection. MX records must point to a domain, not an IP.

Address (A)

The A record is used to find the IP associated with a domain name. This record routes info from the server to the end client’s web browser.

AAAA

The quadruple A record has the same function as the A record but is used specifically for the IPv6 protocol.

Canonical Name (CNAME)

This record will alias one site name to another. The DNS lookup will then route domain name requests the new name that the A record holds. These records must point to a fully qualified domain name (FQDN).

Alias Record (ALIAS)

The ALIAS record is functionally similar to a CNAME record in that it is used to point one name to another. That said, while CNAME records are for subdomains, an ALIAS record is used to lead the apex domain name (example.com) to a subdomain such as host.example.com. The authoritative nameservers for the Apex domain will subsequently resolve the IP of the hostname to direct traffic.

Text (TXT)

TXT records hold the free-form text of any type. Initially, these were for human-readable information about the server such as location or data center. Presently, the most common uses for TXT records today are SPF and Domain_Keys(DKIM).

Service Locator (SRV)

Generalized service location record, used for newer protocols instead of creating protocol-specific records such as MX. This type of record, while helpful, is not commonly used.

Pointer (PTR)

Pointer records point an IP to a canonical name and used explicitly in reverse DNS. It is important to note that a reverse DNS record needs to be set up on the authoritative nameservers for the person that owns the IP, not the person that owns the canonical name.

 Schema Partition and its uses

Partitions in Active Directory

The active directory database is stored in a single NTDS.dit file which is logically separated into the following partitions:

Schema Partition

Configuration Partition

Domain Partition

Application Partition

Schema Partition

There is only one schema partition per forest and it is stored in all DCs of the forest.  It contains the definition of objects and rules for their manipulation and creation in an active directory. It is replicated to all DCs of the forest.

Configuration Partition

Just like schema partition, there is just one master configuration partition per forest and a second one on all DCs in a forest. It contains the forest-wide active directory topology including DCs and sites and services. It is replicated to all DCs in a forest.

Domain Partition

Many domain partitions exist per forest and they are stored on all DCs in a domain. They contain information about users, groups, computers and OUs. It is replicated to all DCs in a given domain.

Application Partition

This partition stores information about applications in an AD. Suppose AD integrated DNS zones information is stored in this partition.

Global Catalog (GC)

 A global catalog is a multi-domain catalog that allows for faster searching of objects without the need for a domain name. It helps in locating an object from any domain by using its partial, read-only replica stored in a domain controller. As it uses only partial information and a set of attributes that are most commonly used for searching, the objects from all domains, even in a large forest, can be represented by a single database of a global catalog server.

A global catalog is created and maintained by the AD DS replication system. The predefined attributes that are copied into a global catalog are known as the Partial Attribute Set (PAS). Users are allowed to add or delete the attributes stored in a global catalog and thus change the database schema.

Some of the common global catalog usage scenarios are as follows:

Forest-wide searches

User logon

Universal group membership caching

Exchange address book lookups