DNS (Domain Name System)

The Internet works on the basis of the DNS system, which contains domain names and IP addresses. There are 13 root DNS servers with information about top-level domains, such as.com,.ru,.uk, etc. Most of them are located in the USA, several in Europe and Japan, as well as in different countries there are "mirrors" that duplicate the information. DNS servers are managed by the international non-profit organization ICANN, located in the United States.

How the domain name system works in 2022

2021: Rostelecom has banned the use of public DNS servers Google, Cloudflare and the service DoH

On September 13, 2021, it was reported that Rostelecom"" sent an official letter to its divisions prohibiting the use of public DNS servers Google, Cloudflare and the service DoH (doh.opendns.com).

According to the document, Rostelecom units are instructed to "prohibit the use of Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1) and doh.opendns.com services for issuing subscribers with BRAS/DHCP and in technological networks."

According to the Telegram Dwach channel, Rostelecom probably acts according to the instructions Roskomnadzor and thus a blocking is being worked out. RuNet

As previously reported, in September, Roskomnadzor plans to test the blocking of a number of foreign Internet protocols that hide the name of the site, including DoH, which is being implemented by Mozilla and Google. Such protocols can make it difficult to block access to prohibited resources.

Rostelecom decided to block the DNS servers of Google, Cloudflare

In order to maintain the operability of the networks, the agency recommended that companies connect to the DNS services of Russian telecom operators or the National Domain Name System (NSDI) by September 9.

Instead of these servers and DoH, Rostelecom proposed using DNS servers under its own control or the IP addresses of the National Domain Name System.

The press service of the company said that thanks to this, it is planned to increase the reliability and optimization of communication networks. According to the source of the publication in the IT market, Rostelecom wants to unify all DNS servers to which the devices of Russian subscribers are configured.

DNS servers allow you to exchange queries and responses using an encrypted protocol. They can be used to, for example, speed up the download of web pages or bypass blocking in applications.

Roskomsvoboda Technical Director Stanislav Shakirov told RBC that companies transfer customers to other servers in advance in case of possible blocking of public DNS servers Google and Cloudflare. An anonymous source of the publication believes that the main purpose of the restrictions is to stop the operation of the DoH protocol, since on mobile networks there are practically no problems with blocking access to prohibited sites.

Independent expert in the field of information security Alexei Lukatsky believes that blocking public DNS servers is part of the campaign, in which last week some state-owned companies sent a letter to their "daughters," and the Bank of Russia - financial organizations with a request to check whether companies have corporate, technology networks and applications that use encryption protocols that hide the site name (Google DNS servers, Cloudflare and the DoH service). According to Lukatsky, such actions lead to a significant restriction of the public DNS servers Google and Cloudflare in Russia.^[1][2]

2019

ICANN is concerned about security threats to key Internet elements

Key elements of the infrastructure of the world's Internet are threatened by large-scale cyber attacks. This was reported by representatives of ICANN Corporation to the news agency Agence France-Presse (AFP) on February 22^[3]

According to AFP, ICANN held an emergency meeting due to the "continuous high risk" to which key elements of the Internet infrastructure are exposed. According to David Conrad, senior technology director of the corporation, the attackers are interested in the infrastructure that underlies the global network. "In the past, there have already been attacks, but none will compare with these," said Conrad.

The attacks began back in 2017, but they began to cause concern among security researchers only now, in connection with which an emergency meeting was assembled. Attackers attack DNS, which, according to ICANN experts, could potentially allow them to intercept traffic, secretly redirect it to another place and fake critical sites.

According to the senior analyst of FireEye in the field of cyber espionage Ben Read, the attacks under the name DNSpionage began in 2017. Attackers mainly intercept the credentials of domain name registrars and Internet providers in the Middle East. Iranian hackers acting in the interests of the Iranian government are supposedly behind the attacks.

"There is no one tool to solve this problem," Conrad said. In this regard, ICANN calls on specialists to strengthen the security of the Internet infrastructure as a whole.

From February 1, 2019, many sites on the Internet will become unavailable

A number of DNS services and DNS server manufacturers announced^[4] in January 2019 to hold a day of correct processing of DNS requests or the so-called "Flag Day." On this day, scheduled for February 1, 2019, participants in the initiative will abandon the implementation of workarounds for authoritative DNS servers without support for the EDNS protocol. By this date, each participant in the initiative implements corresponding changes in a certain version of his software^[5].

In the case of BIND 9, workarounds will be closed in BIND 9.14.0, scheduled for release on February 1. The innovation is already available for branch 9.13, but will not be ported to 9.11 or earlier BIND branches, since, according to the company's policy, no changes are made to stable versions with extended support. In the authoritative (primary) BIND DNS server, EDNS support has already been implemented.

Since February 1, domains serving DNS servers incompatible with EDNS may become unavailable. Companies whose DNS zones are served by incompatible servers should understand that their presence on the Internet will begin to decrease significantly and may come to naught, since Internet providers and other organizations will update their DNS resolvers. After you upgrade your resolvers to a version without workarounds, some sites and mail servers may not be available.

It is recommended that authoritative DNS server operators check their systems for compatibility with EDNS on the https://dnsflagday.net/ website. BIND 9 users may not worry because, as mentioned above, the DNS server is already compatible with EDNS.

2018: For the first time in Internet history, encryption keys have been updated to protect DNS

On October 11, 2018, the first in the history of the Internet and the long-awaited replacement of cryptographic keys protecting the domain name system (DNS) took place. This process, as reported in [[Internet Corporation for Assigned Names and Numbers ICANN 'of the Domain Name and IP Address Management Corporation (ICANN)]], has gone smoothly.

Cryptographic keys appeared in 2010 on the initiative of ICANN. They were used in the DNS Security extension (DNSSEC). Initially, DNS servers did not provide authentication of responses that the attackers used: they could intercept the request of the user's computer, which tried to set the IP address of its "destination," and replace it with the wrong one. Thus, the user, ignoring this himself, could connect to the server of fraudsters. To avoid this, a DNSSEC extension was released in 2010, which many large ISPs agreed to install.

Domain Name and IP Address Management Corporation (ICANN) updated encryption keys that protect the domain name system

ICANN planned to change the keys every five years. For the first time, a change of keys was supposed to occur in 2015, but it was postponed due to the low level of readiness of Internet providers.

ICANN warned that a number of Internet users whose network operators or Internet providers will not be ready to change the key may face problems. They can occur when you convert a resource name to a numeric IP address that computers use to connect to each other.

No failures were noticed. We paid special attention to a number of sites where such failures could occur, but no problems arose, "said ICANN spokesman Brad White, adding that the update was successful.

ICANN Vice President of Research Matt Larson is confident that such a cryptographic key update will become commonplace for operators.^[6]

2017: The Ministry of Communications instructed to create an "independent Internet" for the BRICS countries

In November 2017, the Russian Security Council instructed the Ministry of Communications, together with the Russian Foreign Ministry, to work out the issue of creating its own system of root domain name servers, or DNS, in BRICS countries (Brazil, Russia, India, China and South Africa) by August 1, 2018. In other words, RBC writes, the Security Council instructed to make the Internet in these countries independent of international organizations and external influence.

is impossible to achieve independence within the framework of the existing Internet, anyway, information on root servers will diverge from one point - IANA. Thus, the creation of a system of root domain name servers independent of international administrators is equivalent to the creation of an alternative Internet independent of the existing one, "the representative of the Internet Technical Center (TEC), which supports the DNS structure of the Russian network segment, quotes the publication

Thus, the creation of alternative DNS servers will lead to fragmentation of the Internet and the creation of a separate network, observers say.

2014: Transfer of DNS root zone control functions from the U.S. Government

In December 2014, the ICANN Intersectoral Working Group prepared proposals for transferring DNS root zone control functions from the US government to the Internet community. The National Telecommunications and Information Administration (NTIA), part of the US Department of Commerce, took the initiative to transfer these functions this spring. The 119-member intersectoral working group presented two options for the transfer of functions.

One of them is discussed in the most general terms, since it provides for the transfer of control functions directly to ICANN. At the same time, the performance of functions will be monitored through the existing ICANN accountability mechanisms.

Another option involves the creation of a new structure overseeing the activities of ICANN in managing the domain system and managed by representatives of the Internet community. The authors of the proposals emphasize that we are talking about a non-profit structure with a minimum number of employees. Thus, the intersectoral working group seeks, obviously, to avoid what many observers fear - the creation of "another ICANN to oversee ICANN."

The structure, conventionally designated as Contract Co in the document, will take over the NTIA functions of controlling DNS root zone management. The development of the contract with Contract Co and the supervision of its implementation will be entrusted to the Multistakeholder Review Team, formed of delegates from all communities whose interests are represented by ICANN. Mechanisms for the formation of this committee have not yet been identified and are likely to be the subject of heated discussions, since a wide range of groups with often opposing interests will seek maximum representation in it.

A new permanent committee of Customer Standing Panel will also be formed, which will include representatives of registries of general and national top-level domains - as the main "service consumers" of the DNS root zone. He will broadcast to the Multistakeholder Review Team the wishes of the registrars, thus ensuring that ICANN is accountable to them. Finally, the establishment of an independent appeals committee is envisaged, where complaints can be filed about any decisions related to DNS root zone management, including, obviously, decisions on delegation or removal from domain delegation.

Proposals are published on the ICANN website, comments on them are accepted until December 22, 2014. The final proposal to the US government to transfer control over the management of the DNS root zone should be formulated in the summer of 2015.

DNS Key Features

DNS has the following characteristics:

• Distribution of information storage. Each network node must store only those data that are part of its area of responsibility and (possibly) the addresses of the root DNS servers.
• Caching information. A node may store some data outside its area of responsibility to reduce network load.
• A hierarchical structure in which all nodes are merged into a tree, and each node can either independently determine the operation of child nodes, or delegate them to other nodes.
• Reservation. Several servers are (usually) responsible for storing and maintaining their nodes (zones), separated both physically and logically, which ensures the preservation of data and the continuation of work even in the event of a failure of one of the nodes.

DNS is important for the Internet, because it requires information about its IP address to connect to a node, and it is easier for people to remember letter (usually meaningful) addresses than a sequence of digits of an IP address. In some cases, this allows you to use virtual servers, such as HTTP servers, distinguishing them by the name of the request. Initially, conversion between domain and IP addresses was carried out using a special text file HOSTS, which was compiled centrally and updated on each of the network machines manually. With the growth of the Network, there was a need for an efficient, automated mechanism, which became DNS.

DNS was developed by Paul Mokapetris in 1983; the original description of the operating mechanisms is described in RFC 882 and RFC 883. In 1987, the publication of RFC 1034 and RFC 1035 changed the DNS specification and canceled RFC 882 and RFC 883 as obsolete. Some new RFCs have supplemented and expanded the capabilities of basic protocols.

Additional Features

• dynamic update support
• Secure Connections (DAILYsec)
• support for different types of information (SRV records)

Terminology and working principles

The key concepts of DNS are:

• Zone is a logical node in the name tree. The right to administer the zone can be transferred to third parties, due to which the distribution of the database is ensured. At the same time, the person who transferred the right to control in his database stores information only about the existence of the zone (but not the subzone!), information about the person (organization) managing the zone, and the address of the servers that are responsible for the zone. All further information is already stored on the servers responsible for the zone.
• House - the name of the zone in the Internet domain name system (DNS ), allocated to any country, organization or for other purposes. The structure of the domain name reflects the order of zones in a hierarchical form; the domain name is read from left to right from the younger domains to the highest-level domains (in order of increasing significance), the root domain of the entire system is a point ('.'), followed by the first-level domains (geographical or thematic), then - second-level domains, third, etc. (for example, for the address ru.wikipedia.org domain of the first level - org, second wikipedia, third ru). In practice, the point at the end of the name is often omitted, but it is important in cases of separation between relative domains and FQDN (English Fully Qualified Domain Name, a fully defined domain name).
• Subdomain (English subdomain) - the name of the subordinate zone. (for example, wikipedia.org is a subdomain of the org domain, and ru.wikipedia.org is a subdomain of the wikipedia.org domain). Theoretically, such a division can reach a depth of 127 levels, and each mark can contain up to 63 characters until the total length along with the dots reaches 254 characters. But in practice, domain name registrars use stricter restrictions.
• DNS server is a specialized DNS service software. The DNS server may be responsible for some zones and/or may forward requests to upstream servers.
• DNS client is a specialized library (or program) for working with DNS. In some cases, the DNS server acts as a DNS client.
• Authoritative - A sign that the zone is located on the DNS server. DNS server responses can be of two types: responsible (when the server claims to be responsible for the zone itself) and Non-authoritative (when the server processes the request, and returns the response of other servers. In some cases, instead of sending the request further, the DNS server may return the value already known to it (as previously requested) (caching mode).
• DNS query - A query from a client (or server) to a server. The query can be recursive or non-recursive. A non-recursive request either returns data about a zone that is in the area of ​ ​ responsibility of the DNS server (which received the request) or returns the addresses of the root servers (more precisely, the address of any server that has more information about the requested zone than the responding server). In the case of a recursive request, the server polls the servers (in descending order of the zone level in the name) until it finds a response or finds that the domain does not exist. In practice, the search begins with DNS servers closest to the one you are looking for, if the information about them is in the cache and it is not outdated, the server may not ask for DNS servers). Recursive requests require more resources from the server (and create more traffic), so that they are usually received from nodes "known" to the server owner (for example, the provider provides the opportunity to make recursive requests only to its clients, in the corporate network recursive requests are received only from the local segment). Non-recursive queries are usually received from all nodes on the network (and a meaningful response is given only to queries about the zone that is located on the node, DNS queries about other zones usually return the addresses of the root servers).
• Subdomain is an additional Layer 3 domain name in the primary domain. Can point to both root directory documents and any subdirectory of the primary server. For example, if you have a domain of the form mydomain.ru, you can create different subdomains of the form mysite1.mydomain.ru, mysite2.mydomain.ru, etc.

The DNS system contains a hierarchy of DNS servers. Each domain or subdomain is supported by at least one authoritative DNS server (from the English authoritative - authoritative, trustworthy; in Runet, in relation to DNS and name servers, other translation options are often used: authorized, authoritative), on which domain information is located. The DNS server hierarchy is the same as the domain hierarchy.

The name and IP address are not identical - one IP address can have many names, which allows you to maintain many websites on one computer (this is called virtual hosting). The opposite is also true - many IP addresses can be mapped to one name: this allows you to create load balancing.

To increase the stability of the system, many servers are used that contain identical information, and the protocol has tools that allow maintaining the synchronism of information located on different servers. There are 13 root servers, their addresses are practically unchanged.

DNS uses TCP or UDP port 53 to respond to requests. Traditionally, requests and responses are sent as a single UDP datagram. TCP is used for AXFR requests.

Recursion

Consider how the entire system works.

Suppose we typed an address in the browser ru.wikipedia.org. The browser asks the DNS server: "What is the IP address of the ru.wikipedia.org"? However, the DNS server may not know anything not only about the requested name, but even about the entire domain wikipedia.org. In this case, recursion occurs: the server accesses the root server - for example, 198.41.0.4. This server reports - "I have no information about this address, but I know that 204.74.112.1 is authoritative for the org zone." Then the DNS server sends its request by 204.74.112.1, but it replies "I have no information about this server, but I know that 207.142.131.234 is authoritative for the zone wikipedia.org." Finally, the same request is sent to the third DNS server and receives a response - an IP address, which is transmitted to the client - browser.

In this case, when resolving the name, that is, in the process of searching for IP by name:

• the browser sent the so-called recursive request to the DNS server it knows - in response to this type of request, the server is obliged to return the "finished result," that is, the IP address, or report an error;
• The DNS server, having received a request from the client, sequentially sent iterative requests to which it received answers from other DNS servers until it received an authoritative response from the server responsible for the requested zone.

In principle, the requested server could send a recursive request to the "upstream" DNS server and wait for a ready response.

The name definition request usually does not go beyond the DNS cache, which stores responses to queries that passed through it earlier. Along with the answer comes information about how long this record is allowed to be stored in the cache.

Reverse DNS Query

DNS is primarily used to convert character names to IP addresses, but it can also perform a reverse process. To do this, use the existing DNS tools. The fact is that various data can be associated with a DNS record, including a character name. There is a special domain in-addr.arpa in which entries are used to convert IP addresses to character names. For example, to obtain a DNS name for the address 11.22.33.44, you can request a 44.33.22.11.in-addr.arpa record from the DNS server, and he will return the corresponding character name. The reverse order of recording parts of an IP address is explained by the fact that in IP addresses the senior bits are located at the beginning, and in character DNS names the senior (closer to the root) parts are located at the end.

DNS Records

The most important types of DNS records are:

• The address record or address record associates the host name with the IP address. For example, a request for an A-record in the name of referrals.icann.org will return its IP address - 192.0.34.164
• The AAAA (IPv6 address record) record associates the host name with the IPv6 address. For example, a request for an AAAA entry named K.ROOT-SERVERS.NET will return its IPv6 address - 2001: 7fd:: 1
• CNAME record (canonical name record) or canonical name record (alias) is used to redirect to another name
• The MX (mail exchange) entry or mail exchanger indicates the mail exchange server (s) for this domain.
• The NS (name server) record points to the DNS server for this domain.
• A PTR (pointer) entry or pointer entry associates the host IP with its canonical name. A request in the in-addr.arpa domain to the host IP in reverse form will return the name (FQDN) of this host (see Reverse DNS request). For example, (at the time of writing), for IP address 192.0.34.164: PTR entry request 164.34.0.192.in-addr.arpa will return its canonical name referrals.icann.org. To reduce spam, many email servers can check for a PTR record for the host from which it is sent. In this case, the PTR entry for the IP address must match the name of the sending mail server that it is presented to during the SMTP session.
• The SOA (Start of Authority) record or initial zone record indicates on which server the reference information about this domain is stored, contains the contact information of the person responsible for this zone, timings of zone information caching and DNS server interaction.
• The SRV (server selection) entry points to servers for services, particularly for Jabber.

Reserved Domain Names

RFC 2606 (Reserved Top Level DNS Names) specifies the names of the domains to be used as examples (for example, in the documentation), as well as for testing. In addition to example.com, example.org and example.net, this group also includes test, invalid, etc.

International Domain Names

A domain name can only consist of a limited set of ASCII characters, allowing you to dial a domain address regardless of the user's language. ICANN has approved a Punycode-based IDNA system that converts any Unicode string to a valid DNS character set.

DNS Software

Name Servers:

• BIND (Berkeley Internet Name Domain)
• djbdns (Daniel J. Bernstein's DNS)
• MaraDNS
• NSD (Name Server Daemon)
• PowerDNS
• Microsoft DNS Server (in server versions of Windows NT operating systems)
• MyDNS

Attacks on DNS servers

Шаблон:Main 'DNS server attacks

All DNS software solutions require protection. Indeed, if a hacker attacks a DNS server, then users will fall into a trap without even suspecting it.

Firstly, as a result of DNS attacks, the user risks not getting to the desired page. If you enter a site address, the attacked DNS will redirect the request to the front pages.

Secondly, as a result of the user switching to a false IP address, the hacker can access his personal information. At the same time, the user will not even suspect that his information is declassified.

Domain Information

Many top-level domains support the whois service, which allows you to find out who the domain is delegated to, and other technical information.

Domain Registration

Domain registration is a procedure for obtaining a domain name. Creates records that point to a domain administrator in the DNS database. The registration procedure and requirements depend on the domain zone selected. Domain registration can be performed by both the registration organization and a private person, if the rules of the selected domain zone allow this.

Notes