DNS

History of DNS

Back in the 70s, people got tired of remembering the IP addresses of the servers they wanted to access. At the same time, the idea came up to use a simpler and more memorable name instead of a numeric host address.

Workers at the Stanford Research Institute came up with a text file HOSTS.TXT , which contained a list of string names and their corresponding numerical addresses of computers on the ARPANET.

Addresses were assigned manually. To request a hostname and address or add a computer to the master file, users contacted Stanford's network information center by phone during business hours.

By the early 1980s, maintaining a single, centralized host table had become slow and cumbersome, and the growing network needed an automatic naming system to deal with technical and personnel issues.

In 1984, four UC Berkeley students wrote the first version of the hierarchical domain name system. It is now widely used, especially on Unix systems, and is still the most widely used DNS software on the Internet.

Introduction to DNS

Domain Name System (DNS) is a distribution system for storing and retrieving information about domains. It is most commonly used to obtain an IP address from a host name (computer or device), obtain mail routing information, and/or serve hosts for protocols in a domain.

The system is organized in the form of a certain hierarchy of DNS servers interacting according to a certain protocol. The basis for understanding DNS is the understanding of the hierarchical structure of the name and zones.

Each server responsible for a domain zone can transfer responsibility for a further part of the domain to another server, which makes it possible to assign responsibility for the relevance of information to the servers of various organizations that are responsible only for "their" part of the domain name.

The DNS system contains a hierarchy of DNS servers corresponding to the zone hierarchy. Each zone is supported by at least one authoritative DNS server that hosts information about the domain.

Important! The name and IP address do not necessarily relate to each other as one to one. One IP address can have many domain names, which allows you to support many websites on one computer (this is called shared hosting ).

It can also be the other way around - many IP addresses can be associated with one domain name: this allows you to create load balancing and is actively used in CDN networks .

To increase the stability of the system, many servers containing identical information are used, and the protocol has means to maintain the synchronism of information located on different servers. There are 13 root servers, their addresses practically do not change.

Interesting! The DNS protocol uses TCP or UDP port 53 to respond to queries. Traditionally, requests and responses are sent as a single UDP datagram. TCP is used when the response data size exceeds 512 bytes.

DNS records

The DNS server stores a set of parameters for each domain name. These are records about the domain name, its IP address, as well as various service information.

There are several dozen such entries in total, so we will consider only the most popular of them:

The most interesting here are:

• The A record allows you to specify an IP address that corresponds to a domain.
• CNAME allows you to set a synonym for the name, for example, www.codegym.cc == codegym.cc.
• The MX record contains information about the mail server: what to do if a letter arrives at xxx@codegym.cc.
• NS - indicates the address of the DNS server, which contains information on this domain. Useful when records are cached and stored on non-native nodes.

IP Address Search

Let's see how the DNS system works.

Let's say you typed api.codegym.cc in your browser. The browser will contact the local DNS service and ask you to give it an IP address for the api.codegym.cc domain. Here's what will happen next...

First, the DNS service looks to see if this domain is in the local hosts file on your computer. If there is, it takes the IP address from it. If not, it sends a request to the DNS server known to it: “What is the IP address of api.codegym.cc?”.

However, the DNS server may know nothing not only about the requested name, but even about the entire codegym.cc domain. In this case, the server contacts the root server - for example, 198.41.0.4. This server says: "I have no information about this address, but I know that 204.74.112.1 is responsible for the ru zone."

Then the DNS server sends its request to 204.74.112.1, but it replies: “I have no information about this server, but I know that 207.142.131.234 is responsible for the codegym.cc zone.”. Finally, the same request is sent to a third DNS server and receives a response - an IP address, which is transmitted to the client, that is, the browser.

In this case, in the process of searching for an IP by name, the following rules worked:

• The browser sent a recursive request to a known DNS server (in response to this type of request, the server must return an IP address, or an empty response and an NXDOMAIN error code).
• The DNS server that received the request from the browser sent non-recursive requests in succession, to which it received responses from other DNS servers, until it received a response from the server responsible for the requested zone.
• The rest of the DNS servers mentioned were processing requests non-recursively (and most likely would not have processed requests recursively, even if such a requirement was in the request).

It is sometimes possible for the requested server to send a recursive query to an "upstream" DNS server and wait for a ready response.

Important! With recursive query processing, all responses go through the DNS server, and it gets the opportunity to cache them. A repeated request for the same domain names usually does not go beyond the server's cache, and calls to other servers do not occur at all.

The allowable cache time for responses comes with the responses (TTL field of the resource record).

hosts file

We noticed that the first search is in the local hosts file. This is the heir to the HOSTS.TXT file, which was invented back in the days of ARPANET. Yes, it still exists and is still in use.

It is located along the path:

• /etc/hosts on Linux.
• %SystemRoot%\system32\drivers\etc\hosts on Windows.
• /system/etc/hosts in android.

Typically, the file includes a location definition for the localhost node:

127.0.0.1   	localhost

Its structure is very simple: first comes the IP address, then the domain name.

Useful

Using the hosts file, it is possible to filter ads by redirecting domain addresses of banners to the address 127.0.0.0, 127.0.0.1 or 0.0.0.0.

The use of 127.0.0.1 is generally not recommended, as it results in a response timeout and associated delays if the server does not exist or is misconfigured. And if you map any advertising domain to the IP address 0.0.0.0, then all requests to it will immediately fall off).

Public DNS servers

You usually get a DNS server along with your internet service when you connect it. But such a free DNS server is not always the best option. Moreover, you might not want to send a query with the domain name every time you visit a site to your ISP's DNS server.

Therefore, many people prefer to switch to public free DNS servers. First, they are very fast and have a large cache of domain names. You will get faster site loading and uptime with a minimal chance of technical problems.

Secondly, safety. Some DNS services can block access to phishing and malicious sites and offer content filtering to protect children from inappropriate content online.

Such DNS servers can even fight scammers. For example, you go to a fake bank website, and the DNS server will give you not the IP address of the scammers, but its security service.

List of such servers