Domain Name Service (DNS)

What is DNS?

The Domain Name System is a distributed system that resolves hostnames into IP addresses using a series of queries and their returned answers. Basically The Domain Name System (DNS) is the phonebook of the Internet. Humans access information online through domain names, like google.com or yahoo.com. Web browsers interact through Internet Protocol (IP) addresses. DNS 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.google.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 (google.com) and the machine-friendly address necessary to locate the google.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.

Let’s take an in-depth look at the process:

Step 1: Request information

The process begins when you ask your computer to resolve a hostname, such as visiting https://google.com. The first place your computer looks for the corresponding IP address is its local DNS cache, which stores information that your computer has recently retrieved.

If your computer doesn’t already know the answer, it needs to perform a DNS query to find out.

Step 2: Ask the recursive DNS servers

If the information is not stored locally, your computer queries (contacts) the recursive DNS servers (resolvers) from your internet service provider (ISP). These specialized computers perform the legwork of a DNS query on your behalf. Resolvers have their own caches, and given that many of the ISP’s customers are using the same resolvers, there is a reasonable chance that popular domains will already be cached. If this is the case for our example, google.com, the process usually ends here and the information is returned to the user.

Just about every ISP runs their own resolvers, yet those aren’t necessarily what you could be using. Some companies and perhaps even technically sophisticated home users could run their own resolvers on site. Additionally, there are several very popular open resolvers available, including Google Public DNS, OpenDNS, Dyn Recursive DNS, and Quad9.

Step 3: Ask the root name servers

If the recursive servers don’t have the answer, they query the root name servers. A name server is a computer that answers questions about domain names, such as IP addresses. These 13 servers act as a kind of telephone switchboard for DNS. They don’t know the answer, but they can direct DNS queries to someone that knows where to find it.

Step 4: Ask the TLD name servers

The root name servers will look at the first part of our request, reading from right to left — www.google.com — and in our case, direct our query to the top-level domain (TLD) name servers for .com. Each TLD, such as those for .com, .org, and .us, has its own set of name servers, which act like a receptionist for each TLD. These servers don’t have the information we need, but they can refer us directly to the servers that do have the information.

Step 5: Ask the authoritative DNS servers

The TLD name servers review the next part of our request — www.google.com — and direct our query to the name servers responsible for this specific domain. These authoritative name servers are responsible for knowing all the information about a specific domain, which is stored in DNS records. There are many types of records, which each contain a different kind of information.

In this example, we want to know the IP address for www.google.com, so we ask the authoritative name server for the address record (A record). Some authoritative name servers have intelligence that can analyze an incoming DNS query and return a response that is more performant for the user that originated the query.

Step 6: Retrieve the record

The recursive server retrieves the A record for google.com from the authoritative name servers and stores the record in its local cache. If anyone else requests the host record for google.com, the recursive server will already have the answer and will not need to go through the lookup process again. All records have a time-to-live value, which is like an expiration date. After a while, the recursive server will need to ask for a new copy of the record to make sure the information doesn’t become out-of-date.

Step 7: Receive the answer

Armed with the answer, recursive server returns the A record back to your computer. Your computer stores the record in its cache, reads the IP address from the record, then passes this information to your browser. The browser then opens a connection to the webserver and receives the website.

This entire process, from start to finish, takes only milliseconds to complete.

Lets talk about How DNS preserve following means of a Distributed System

Fault Tolerant

Techniques are provided for handling failures of DNS to respond to DNS queries. A DNS resolver is configured to resolve domain names, and includes a time-to-live (TTL)-based cache, a negative cache, and a long term store cache. The TTL-based cache is configured to temporarily store domain names with resolved IP addresses. The negative cache is configured to store negative entries that include information indicating domain names that were failed to be resolved. The long term store cache is configured to store domain names with resolved IP address for an indefinite time period. The caches are accessed in a manner that enables fewer DNS query retries to be performed when a DNS server is non-responsive, to reduce delays and network traffic. Furthermore, the DNS resolver may reduce a number of DNS queries performed the longer the DNS server stays non-responsive.

Highly Available

If you list the IP address of 2 load-balancers / reverse-proxies, located at two different locations, each set to balance the load between application servers, again located at at least two different data-centres, if one of the data-centres becomes unreachable, the client’s web-browser will try the next IP address records returned by the DNS server and repeat the process to get the web-site.This kind of load-balancing is called Round Robin DNS load-balancing.

Recoverable

DNS Failover is essentially a two-step process. The first step involves actively monitoring the health of your servers. Monitoring is usually carried out by ping or Internet Control Message Protocol (ICMP) to verify that your HTTP server is functioning. The health of the servers can be assessed every few minutes, and more advanced services allow you to configure your monitoring time settings. In the second step, DNS records are dynamically updated in order to resolve traffic to a backup host in case the primary server is down. Once your primary server is back up and running, traffic is automatically directed towards its original IP address.

DNS Failover is not without limitations. In order for it to work, you need to have backup locations for your site and applications. Even if DNS records are quickly updated once an outage has been detected, ISPs need to update their DNS cache records, which is normally based on TTL (Time to Live). Until that occurs, some users will still be directed to the downed primary server.

Consistent

This test compares the DNS query results from a DNS resolver which is considered to be reliable with one that is tested for tampering.

The domain name system (DNS) is what is responsible for transforming a host name (e.g. google.com) into an IP address (e.g. 38.229.72.16). ISPs, amongst others, run DNS resolvers which map IP addresses to host names. In certain circumstances though, ISPs map the wrong IP addresses to the wrong host names. This is a form of tampering, which OONI can detect by running its DNS consistency test.

This test compares the IP address of a given host name allocated by the Google DNS resolver (which we assume to not be tampered with) with the IP address mapped to that website by a provider. If the two IP addresses of the same website are different, then there is a sign of network interference. When ISPs tamper with DNS answers, users are redirected to other websites or fail to connect to their intended websites.

Scalable

When you set up a DNS infrastructure for your internal network, one big consideration is the namespace. If the DNS will be used only for internal queries, you don’t have to register the domain name.

When your business grows to the point where you want to provide services to users over the Internet as well as those on the internal LAN, you have several choices:

• Use different domain names for your internal and external namespaces
• Use an internal domain that is a subdomain of the external namespace
• Use the same domain name for internal and external namespaces, and configure a split DNS infrastructure. With split DNS, you create two different zones for the same domain.

For scalability, you should plan your DNS namespace in a logical hierarchy so that you can easily add new zones without adversely affecting the extant namespace. It’s best not to extend the namespace more than five levels below the root (Internet or internal) domain.

If your internal network crosses multiple physical locations, the best option may be to use an internal DNS root zone that is authoritative for all the top-level domains on the network and is isolated from the Internet. The DNS namespace can be hosted on multiple DNS servers for scalability. In an enterprise environment, you can create a DNS infrastructure with multiple top level domains.

Secure

Standard DNS queries, which are required for almost all web traffic, create opportunities for DNS exploits such as DNS hijacking and man-in-the-middle attacks. These attacks can redirect a website’s inbound traffic to a fake copy of the site, collecting sensitive user information and exposing businesses to major liability. One of the best known ways to protect against DNS threats is to adopt the DNSSEC protocol.