DNS server BIND (theory)
The main goal of DNS is to map domain names to IP addresses and vice versa - IP to DNS. In this article I will look at the work of the BIND DNS server (Berkeley Internet Name Domain, earlier: Berkeley Internet Name Daemon), as with (I’m not afraid of this word) common. BIND is included with any UNIX distribution. The basis of BIND is the named daemon, which uses UDP / 53 for its work and for some TCP / 53 requests.
Historically, before the appearance of the domain name system, the role of the resolver of symbolic names in IP was performed by the / etc / hosts file, which still plays a significant role in this case. But with the growing number of hosts in the global network, it became unrealistically difficult to monitor and maintain the database of names on all hosts. As a result, they invented a DNS, which is a hierarchical, distributed system of domain zones. Let's look at the structure of the Domain Name System in the illustration:
The DNS domain structure is a tree-like hierarchy consisting of nodes, zones, domains, subdomains, and other elements, which will be discussed below. The “top” of the domain structure is the root zone. Root zone settings are located on multiple servers / mirrors located around the world and contain information about all root zone servers, as well as responsible for the first-level domains (ru, net, org, etc.). Root zone server information is located at this root server site . Root zone settings are always available here . Root zone servers process and respond to requests, giving information only about first-level domains (that is, responding to any requests as non-recursive)! So, the word zone has been repeated many times. It's time to explain this term.
A zone is any part of the domain name system tree that is hosted as a single unit on a DNS server . For greater understanding, the zone can be called the “zone of responsibility” . The purpose of separating a part of a tree into a separate zone is the transfer of responsibility ( delegation ) for this branch to another person or organization. In the illustration, zone examples are highlighted with a blue gradient ( name zone, k-max.name zone with all subordinate resources, www.openoffice.org with all subordinate subdomains and resources). Not all zones are highlighted in the illustrations, but only some for general understanding and presentation. Each zone has at least one authoritative DNS server that stores ALL of the information about the zone for which it is responsible.
')
A domain is a named branch or subtree in the DNS name tree, that is, it is a specific node that includes all subordinate nodes. The following quote from the Linux Network Administrators Guide clarifies the picture of the difference between a zone and a domain:
Each node in the DNS hierarchy is separated from its parent by a dot. If we draw an analogy with the Linux file system, the domain name system has a similar structure, except that the separator in the file system is a slash , and in the DNS it is a period . As well as the DNS address is read from right to left (from the root domain to the host name) in contrast to the path in the Linux file system. The domain name begins with a point (the root domain ) and passes through the domains of the first, second and, if necessary, the third, etc. levels and ends with the host name. So domain name fully reflects the structure of the DNS hierarchy . Often (I would say always in everyday life), the last dot (designation of the root domain) in the domain name is omitted (that is, in the browser we enter not k-max.nam e. , But k-max.nam e ). So, having analyzed the structure of the domain name, we imperceptibly approached the concept of FQDN .
FQDN (English Fully Qualifed Domain Name , Fully Qualified Domain Name ) is a domain name that uniquely identifies a domain name and includes the names of all the parent domains of the DNS hierarchy , including the root one . A peculiar analogue of the absolute path in the file system. Let's analyze the above using the domain name mail.k-max.name as an example:
The difference between the FQDN and the usual domain ( non-FQDN ) name appears when naming the domains of the second, third (and so on) level. To obtain a FQDN, it is necessary to specify higher level domains in the domain name (for example, mail is a domain name, but the FQDN name looks like mail.k-max.name.). The maximum FQDN size is 255 bytes, with a limit of 63 bytes for each domain name.
Subdomains , in short, are subordinate domains . By and large, all domains on the Internet are subordinate with the exception of the root. For example, the k-max domain is a subdomain of the name domain, and name, in turn, is a subdomain of the root domain.
So, in the diagram above, we looked at the root domain , the next in the hierarchy are the first / top level domains , they are also TLDs , they are also the Top-Level Domain . These domains include national domains ( ru. , Ua. , Etc.) and common domains ( com. , Net. , And others). There are also specialized domains that are not published in the DNS system, but are used by programs (the .onion domain is used by the anonymous Tor network to intercept and then route calls to the hidden services of this network). There is still a so-called. Reserved domain names defined in RFC 2606 ( Reserved Top Level DNS Names ) defines the domain names that should be used as examples (for example, in documentation), as well as for testing. Such names include, for example, example.com, example.org and example.net, as well as test, invalid, and others. Lower in the hierarchy, as you can see, there are third-level domains, etc. The domain hierarchy ends with host names , which are defined by the corresponding resource records or host records .
A resource record is that, for the sake of which, ultimately, DNS exists. A resource record is a unit for storing and transferring information in DNS. Each such record contains information on the correspondence of some name and service information in the DNS, for example, the correspondence of a domain name to an IP address.
In this case, it is possible to use the following symbols:
The entire set of resource records can be found in wikipedia . The most commonly used resource records are as follows (hereinafter, we will definitely consider them in practice):
Let's take a look at what Delegation is . Delegation (more correctly, delegation of responsibility ) is the operation of transferring responsibility for a part of the domain name tree (zone) to another person or organization. Through delegation, the DNS provides for the administration and storage of zones. Technically, delegation consists in allocating any part of the tree to a separate zone, and placing this zone on a DNS server owned by another person or organization. At the same time, the “gluing” resource records (NS and A) containing pointers to the authoritative DNS servers of the child zone are included in the parent zone, and all other information relating to the child zone is already stored on the DNS servers of the child zone. For example, in the illustration, the root domain delegates authority to the servers responsible for the TLD, while the TLD in turn delegates the authority to manage the zones — second-level servers; sometimes the chain ends there, but it happens that delegation extends to 4 or even 5 levels.
For more understanding, I will give an example. Delegating the management of the k-max.name subdomain to another person (in my case, the hoster) leads to the creation of a new zone that is administered independently of the rest of the namespace (regardless of the parent name.). The zone k-max.name after delegation of authority is now independent of name. and may contain all (or rather, any names I want) domain names that end in * .k-max.name. On the other hand, the name zone. contains only domain names ending in * .name. but not included in delegated to this zone, such as, for example, k-max.name or a-lab.name or any other. K-max.name can be divided into subdomains with names like mail.k-max.name , ftp.k-max.name and some of these subdomains can be allocated to separate zones, and responsibility for these zones can also be delegated . If ftp.k-max.name is a separate zone, then k-max.name zone will not contain domain records that end in * .ftp.k-max.name.
So after delegation of responsibility, the information stored by the delegating zone no longer includes information on the delegated subdomain and its resource records of hosts, but stores information about name servers that are authoritative for the delegated subdomain. These are the “gluing” records, which I have already mentioned above. In this case, if the DNS server of the parent domain requests information about the address belonging to the delegated subdomain, a list of DNS servers that have the appropriate information is provided in response.
Above, when considering the types of resource records, I mentioned the primary and secondary server. In addition to these types, there is another type - caching .
The main DNS server (it’s primary , it’s master , it’s primary ) is the authoritative server (sometimes called authoritarian, I don’t know how to call it right), which stores the master copy of the zone data file , followed by the system administrator.
The secondary server is also authoritative , but it copies the master zone file from the primary server . The only difference between the main and secondary is that the main loads its information from the zone configuration files, and the secondary one loads (receives) zone settings from the main server. A secondary DNS can receive its data from another secondary server. Any request for a host within the zone for which the authoritative server is responsible will eventually be transmitted to one of these servers (the main or secondary). Secondary servers can be as many as you like. Depending on the settings, the main server can send a signal to the secondary to change the zone, while the secondary , receiving the signal, makes a copy. This action is called zone transfer. There are two mechanisms for copying a zone : full copy (AXFR) and incremental (incremental) copy of a zone (IXFR) .
Caching servers are NOT AUTHORITY , these servers are stored in memory (cache), replies to previous requests, if this server received a request, it first looks at the information in the cache, and if the necessary answer is not found in the cache, then sends the request to a higher-level DNS server.
It is also possible to configure DNS in stels mode (so-called invisible), information about this server cannot be obtained using direct queries. This can be useful for organizing a primary server in a secure environment and thus protect the zone from attacks on the zone.
How do the programs on the end machines know where and in what form to send DNS queries? They don't know that. For resolving names and IP addresses by client applications, the Resolver library is used. This is not a special application, it is the functionality of the system (kernel). So applications send system calls gethostbyname (2) and gethostbyaddr (2), and the kernel already determines the path to which to proceed further, based on the settings in the /etc/nsswitch.conf file. This file determines which services (whether it is the / etc / hosts or DNS file ) and in what order to use. In earlier versions of the Linux library, libc , the /etc/host.conf file was used . Here is a fragment of the file that interests us:
Two lines of this fragment tell the kernel to convert host names to IP ( hosts: files dns string), first from the hosts file , then by DNS , and also network names to IP (networking : files string) using the / etc / network file. There are also options for nis or nisplu , which determine to use the Network Information System (NIS) to find the address. The order in which the services are listed determines the order in which they are polled.
If, according to /etc/nsswitch.conf, the DNS request is sent, then the settings from the /etc/resolv.conf file are used, which determines which DNS servers to use. Here is a typical example of the /etc/resolv.conf file:
The nameserver directive specifies the address of the domain name server that will perform recursive resolver queries. In this file, it is indicated to use the name north first 192.168.1.1 then, if the first could not process the request, 192.168.1.2. It is recommended not to use more than 3 nameserver parameters . If the nameserver option is not specified, the resolver will attempt to connect to the server on the local host. The domain parameter specifies the default domain name that will be substituted when DNS cannot find the host name. There is also a search option that specifies additional domains in which the host name must be searched for and resolved. The search and domain options cannot be shared.
In addition to the cache on the DNS server , there are caches for Internet browsers , resolver caches . A pretty transparent picture is provided by Wikipedia:
The following types of queries are available in DNS: iterative (it is also direct ), reverse, and recursive .
An iterative ( direct , non-recursive ) request sends the domain name to the DNS server and asks for the return of either the IP address of this domain or the name of the DNS server authoritative for this domain. However, the DNS server does not poll other servers for a response. This is how root and TLD servers work.
A recursive query sends a domain name to the DNS server and asks to return the IP address of the requested domain. At the same time, the server can access other DNS servers.
The return request sends the IP and requests to return the domain name.
Any DNS server must respond to iterative queries . It is possible to configure the DNS to respond to recursive requests . If DNS is not configured to respond to recursive queries, it treats them as iterative .
Usually,provider issues the local network has a DNS server that processes recursive requests, and most likely it is configured to cache requests, which saves traffic and reduces the load on the network. The client and DNS server interaction scheme can be represented as follows:
Let's look at what is drawn in steps:
Usually, the number of steps is reduced to a minimum, because On the way to query flow, there is a caching server that stores the necessary information in the cache. In this scheme, the question may arise: how does the local DNS server that received the recursive request from the resolver choose a DNS server from the authoritative list? There are many root DNS servers on the Internet, which of our root servers will our DNS server send a request to?
To address this issue, BIND DNS servers use a metric called response time ( roundtrip time , or RTT ) to select among authoritative DNS servers of the same zone. RTT determines the delay with which the response to requests from the remote server comes. Each time a request is sent to a remote server, the BIND DNS server starts an internal timer. The timer stops when a response is received, and the metric is fixed by the local server. If you have to choose one of several authoritative servers, the choice falls on the server with the lowest RTT.
Before BIND first sent a request to a server and received a response from it, a remote RTT value is assigned to the remote server, which is less than all the others received on the basis of measurements. Thus, DNS BIND is guaranteed to poll all authoritative servers for a particular zone randomly, before it starts to choose the preferred one based on the metric.
DNS responses are of the following type:
The DNS response usually contains the following information:
The above is clearly confirmed by the dig utility:
DNS is used primarily to convert domain names to IP addresses, but it can also perform a reverse process, called reverse name translation or reverse mapping . Because records in the direct DNS database are hierarchically structured by domain names; DNS cannot effectively search by IP address in such a database. For the reverse conversion to the DNS, the special domain in-addr.arpa is used. Resource records in this domain in the Name field contain IP-addresses, in the Type field - PTR , and in the Data field - FQDN-name corresponding to this IP.
The diagram shows the structure of the arpa domain. I think that everything is pretty clear here. Domain arpa. It has 2 sub - domains in-addr and ip6 , responsible for IPv4 and IPv6 addresses, respectively. Domain in-addr.arpa. has from * .0.in-addr.arpa. to * .255.in-addr.arpa. subdomains, each of which also has 256 subdomains.
In order to reduce the amount of unwanted correspondence (spam), many mail servers can check for PTR records for the host from which they are sent. In this case, the PTR record for the IP address must match the name of the sending mail server, which it represents during the SMTP session.
Visually presented scheme can be represented by commands:
In this case, the dig -x 194.87.0.50 command would be more correctly represented as dig 50.0.87.194.in-addr.arpa., That is, entries in the subdomains * .in-addr.arpa. presented in the so-called reverse notation (or reverse form), that is, a PTR record with the FQDN 50.0.87.194.in-addr.arpa., which in turn indicates the www.ru domain, would correspond to a host with IP 194.87.0.50, which in turn indicates the www.ru domain . Note that most often the Internet provider is responsible for the reverse zone and its editing.
As promised, I describe the PTR resource record in the IN-ADDR.ARPA domain, corresponding to the above A record for the www.ru. will look like this:
The name 50.0.87.194 does not end with a period and therefore is relative. Question: relative to what? In no case is relative to " www.ru ". In order for this entry to be a FQDN, the default domain must be called “IN-ADDR.ARPA.”. This can be achieved either by placing the PTR records in a separate file, in which the default domain name of the zone is IN-ADDR.ARPA. (specified in the bootstrap daemon of the named daemon), or by changing this domain using the $ ORIGIN directive. If the default domain is defined as 0.87.194.IN-ADDR.ARPA., Then the record can be represented as follows:
In a nutshell, I would like to raise the issue of domain name registration .
Domain registration is the action by which the client informs the registrar which DNS servers to delegate the subdomain to, and also provides the registrar with contact and payment information. The registrar sends the information to the appropriate registry. Most often, this is the process of registering the first level zone (that is, in the TLD of the ru, com, or other zones) with the record of a new domain name.
A domain name registrar is an organization that has the authority to create (register) new domain names and extend the validity of already existing domain names in the domain for which mandatory registration is established.
Domain levels for which mandatory registration of the person responsible for the domain is necessary are as follows:
The registrar for the root domain is the ICANN organization . To become a domain registrar in second-level zones (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs ...), you need to get ICANN accreditation.
Registration rules in international (gTLD - com., Org, etc.) domains are established by ICANN. Registration rules in national (ccTLD - ru, us, etc.) domains are set by their registrars and / or authorities of the respective countries, for example, uniform rules for all registrars in .ru, and .rf domains are set by the Coordination Center of the national Internet domain. For many domains (including ru), the registrar is not the only one. If there are several registrars, all of them should use a single (centralized or distributed) database to eliminate conflicts and ensure the uniqueness of the domain name.
In most cases, the domain registration service is paid, the registrar determines the price and terms of registration. To register a domain, you must select a free name and send an application for registration with one of the registrars (for example, nic.ru), pay for the provision of services. After registration is confirmed, it is necessary to determine (delegate) the server dns in the registrar's interface, most likely it will be your hoster’s DNS.
At the end of the article I want to note the same about such marketing nuance that sometimes second-level domains are called domain names of the FIRST level, thereby “omitting” the root domain value and taking it as the root domain - TLD domains.
I also want to note that the domain address and IP address are not identical - a single IP address can have multiple names, which allows you to maintain multiple websites on one computer (this is called virtual hosting). The reverse is also true — multiple IP addresses can be mapped to a single name: this allows you to create load balancing.
So, in today's article I tried to describe the work of the domain name system as clearly as possible. I hope I did it. We reviewed the hierarchical structure of the DNS database, as well as the processes of interaction between clients and DNS servers, as well as types of DNS servers. In the next article I will discuss the practical issues of installing and configuring the BIND DNS server on Linux. I will be glad to your comments.
man (5) resolver: http://www.opennet.ru/man.shtml?topic=resolver&category=5&russian=0
man (3) gethostbyname: http://www.opennet.ru/cgi-bin/opennet/man .cgi? topic = gethostbyname & category = 3
Linux Network Administrators Guide v2 Russian: download .
RFC882, 1035, 1183
Placed with the permission of mcsim85 , which does not yet have a full-fledged account on Habré, but which for such high-quality articles definitely deserves it! Just in case the link to the original.
Domain Name System Concepts
Historically, before the appearance of the domain name system, the role of the resolver of symbolic names in IP was performed by the / etc / hosts file, which still plays a significant role in this case. But with the growing number of hosts in the global network, it became unrealistically difficult to monitor and maintain the database of names on all hosts. As a result, they invented a DNS, which is a hierarchical, distributed system of domain zones. Let's look at the structure of the Domain Name System in the illustration:
The DNS domain structure is a tree-like hierarchy consisting of nodes, zones, domains, subdomains, and other elements, which will be discussed below. The “top” of the domain structure is the root zone. Root zone settings are located on multiple servers / mirrors located around the world and contain information about all root zone servers, as well as responsible for the first-level domains (ru, net, org, etc.). Root zone server information is located at this root server site . Root zone settings are always available here . Root zone servers process and respond to requests, giving information only about first-level domains (that is, responding to any requests as non-recursive)! So, the word zone has been repeated many times. It's time to explain this term.
A zone is any part of the domain name system tree that is hosted as a single unit on a DNS server . For greater understanding, the zone can be called the “zone of responsibility” . The purpose of separating a part of a tree into a separate zone is the transfer of responsibility ( delegation ) for this branch to another person or organization. In the illustration, zone examples are highlighted with a blue gradient ( name zone, k-max.name zone with all subordinate resources, www.openoffice.org with all subordinate subdomains and resources). Not all zones are highlighted in the illustrations, but only some for general understanding and presentation. Each zone has at least one authoritative DNS server that stores ALL of the information about the zone for which it is responsible.
')
A domain is a named branch or subtree in the DNS name tree, that is, it is a specific node that includes all subordinate nodes. The following quote from the Linux Network Administrators Guide clarifies the picture of the difference between a zone and a domain:
Thus, the namespace is fragmented into zones (zones), each of which is controlled by its own domain. Note the difference between zone (zone) and domain (domain): the groucho.edu domain affects all the machines at Groucho Marx University, while the groucho.edu zone only includes hosts that work directly in the computer center, for example, in the department of mathematics . The host in the physics department belongs to another zone, namely physics.groucho.edu.
Each node in the DNS hierarchy is separated from its parent by a dot. If we draw an analogy with the Linux file system, the domain name system has a similar structure, except that the separator in the file system is a slash , and in the DNS it is a period . As well as the DNS address is read from right to left (from the root domain to the host name) in contrast to the path in the Linux file system. The domain name begins with a point (the root domain ) and passes through the domains of the first, second and, if necessary, the third, etc. levels and ends with the host name. So domain name fully reflects the structure of the DNS hierarchy . Often (I would say always in everyday life), the last dot (designation of the root domain) in the domain name is omitted (that is, in the browser we enter not k-max.nam e. , But k-max.nam e ). So, having analyzed the structure of the domain name, we imperceptibly approached the concept of FQDN .
FQDN (English Fully Qualifed Domain Name , Fully Qualified Domain Name ) is a domain name that uniquely identifies a domain name and includes the names of all the parent domains of the DNS hierarchy , including the root one . A peculiar analogue of the absolute path in the file system. Let's analyze the above using the domain name mail.k-max.name as an example:
mail.k-max.name. | | | | | | | | | + root domain | | | + --- first level domain | | + ------ dot separating domains / parts of FQDN | + --------- second level domain + --------------- subdomain / third level domain, possibly - hostname
The difference between the FQDN and the usual domain ( non-FQDN ) name appears when naming the domains of the second, third (and so on) level. To obtain a FQDN, it is necessary to specify higher level domains in the domain name (for example, mail is a domain name, but the FQDN name looks like mail.k-max.name.). The maximum FQDN size is 255 bytes, with a limit of 63 bytes for each domain name.
Subdomains , in short, are subordinate domains . By and large, all domains on the Internet are subordinate with the exception of the root. For example, the k-max domain is a subdomain of the name domain, and name, in turn, is a subdomain of the root domain.
So, in the diagram above, we looked at the root domain , the next in the hierarchy are the first / top level domains , they are also TLDs , they are also the Top-Level Domain . These domains include national domains ( ru. , Ua. , Etc.) and common domains ( com. , Net. , And others). There are also specialized domains that are not published in the DNS system, but are used by programs (the .onion domain is used by the anonymous Tor network to intercept and then route calls to the hidden services of this network). There is still a so-called. Reserved domain names defined in RFC 2606 ( Reserved Top Level DNS Names ) defines the domain names that should be used as examples (for example, in documentation), as well as for testing. Such names include, for example, example.com, example.org and example.net, as well as test, invalid, and others. Lower in the hierarchy, as you can see, there are third-level domains, etc. The domain hierarchy ends with host names , which are defined by the corresponding resource records or host records .
Resource records
A resource record is that, for the sake of which, ultimately, DNS exists. A resource record is a unit for storing and transferring information in DNS. Each such record contains information on the correspondence of some name and service information in the DNS, for example, the correspondence of a domain name to an IP address.
A resource record consists of the following fields:
- Name (NAME) - the domain name to which this resource record is attached or “belongs”, or an IP address. In the absence of this field, the resource record is inherited from the previous record.
- Time To Live ( TTL) - literally the “lifetime” of the record, the record storage time in the DNS cache (after the specified time the record is deleted), this field may not be indicated in the individual resource records, but then it should be indicated at the beginning of the zone file and will be be inherited by all entries.
- class (CLASS) - defines the type of network, (in 99.99% of cases, IN is used (which means - Internet). This field was created under the assumption that DNS can work in other types of networks besides TCP / IP)
- type (TYPE) - record type syntax and record assignment
- data (DATA) - various information, the format and syntax of which is determined by the type.
In this case, it is possible to use the following symbols:
- ; - enter comment
- # - Also introduces comments (only in BIND 4.9 version)
- @ - Current domain name
- () - Allow data to span multiple lines
- * - Metacharacter (name field only)
The entire set of resource records can be found in wikipedia . The most commonly used resource records are as follows (hereinafter, we will definitely consider them in practice):
- A - ( address record / address record ) maps the host name (domain name) to an IPv4 address. For each network interface of the machine, one A-record must be made. For example, the following entry displays the domain name k-max.name. in IPv4, the host address is 81.177.139.65 (the NAME field is k-max.name. , the TTL field is 86400 , the CLASS - IN field, the DATA field is 81.177.139.65 ):
k-max.name. 86400 IN A 81.177.139.65
- AAAA ( IPv6 address record ) is similar to A, but for IPv6.
- CNAME ( canonical name record / canonical name record (alias) ) - displays an alias for the real name (to be redirected to another name), for example, the following record defines the ftp alias for the host www.k-max.name .:
ftp 86400 IN CNAME www.k-max.name.
- MX ( mail exchange ) - specifies the hosts for the delivery of mail addressed to the domain. In this case, the NAME field indicates the destination domain, the TTL field , CLASS field is the standard value, the TYPE field is set to MX , and the DATA field indicates the priority and, after a space, the domain name of the host responsible for receiving mail . For example, the following entry shows that for the k-max.name domain, send mail first to mx.k-max.name, then to mx2.k-max.name, if any problems occurred with mx.k-max.name . At the same time, for both MX hosts there must be corresponding A-records:
k-max.name. 17790 IN MX 10 mx.k-max.name. k-max.name. 17790 IN MX 20 mx2.k-max.name.
- NS ( name server / name server ) points to the DNS server serving the domain. Rather, to say - indicate the server to which this domain is delegated. If NS records refer to name servers for the current zone, the domain name system practically does not use them. They simply explain how the zone is organized and which machines play a key role in providing the name service. For example, the name zone. Served by the following NS:
name. 5772 IN NS l6.nstld.com. name. 5772 IN NS m6.nstld.com. name. 5772 IN NS c6.nstld.com. name. 5772 IN NS j6.nstld.com. ......
Zone k-max.name service:
k-max.name. 1577 IN NS ns2.jino.ru. k-max.name. 1577 IN NS ns1.jino.ru.
- PTR ( pointer ) - displays the IP address in the domain name (we will talk about this type of record below in the reverse name resolution section).
- SOA ( Start of Authority / zone entry ) - describes the basic / initial zone settings, it can be said, determines the zone of responsibility of this server . Only one SOA record should exist for each zone and it should be the first one. The Name field contains the domain / zone name , the TTL, CLASS fields are the standard value, the TYPE field is set to SOA , and the DATA field consists of several values ​​separated by spaces: the name of the primary DNS (Primary Name Server) , the address of the zone administrator , then in brackets Serial number of the zone file (Serial number) . Each time you make changes to a zone file, this value needs to be increased, this indicates to the secondary servers that the zone has been changed and that they need to update the zone themselves. Next - timer values ( Refresh - indicates how often the secondary servers should poll the primary to see if the serial number of the zone has increased, Retry - the waiting time after a failed polling attempt, Expire - the maximum time during which the secondary server can use information about received zone, Minimum TTL - the minimum time during which data remains in the cache of the secondary server). The example below shows 2 identical SOA records (although the second is written in several lines), but they are the same in meaning and the format of the second record is more understandable due to its structuredness:
k-max.name. 86400 IN SOA ns1.jino.ru. hostmaster.jino.ru. 2011032003 28800 7200 604800 86400 k-max.name. 86400 IN SOA ns1.jino.ru. hostmaster.jino.ru. ( 2011032003; serial (serial number) 28,800; refresh (refresh) 7200; retry (retry) 604800; expire (expiration date) 86400); minimum TTL (minimum) - SRV ( server selection ) - point to the servers providing the work of certain services in this domain (for example, Jabber and Active Directory).
Let's take a look at what Delegation is . Delegation (more correctly, delegation of responsibility ) is the operation of transferring responsibility for a part of the domain name tree (zone) to another person or organization. Through delegation, the DNS provides for the administration and storage of zones. Technically, delegation consists in allocating any part of the tree to a separate zone, and placing this zone on a DNS server owned by another person or organization. At the same time, the “gluing” resource records (NS and A) containing pointers to the authoritative DNS servers of the child zone are included in the parent zone, and all other information relating to the child zone is already stored on the DNS servers of the child zone. For example, in the illustration, the root domain delegates authority to the servers responsible for the TLD, while the TLD in turn delegates the authority to manage the zones — second-level servers; sometimes the chain ends there, but it happens that delegation extends to 4 or even 5 levels.
For more understanding, I will give an example. Delegating the management of the k-max.name subdomain to another person (in my case, the hoster) leads to the creation of a new zone that is administered independently of the rest of the namespace (regardless of the parent name.). The zone k-max.name after delegation of authority is now independent of name. and may contain all (or rather, any names I want) domain names that end in * .k-max.name. On the other hand, the name zone. contains only domain names ending in * .name. but not included in delegated to this zone, such as, for example, k-max.name or a-lab.name or any other. K-max.name can be divided into subdomains with names like mail.k-max.name , ftp.k-max.name and some of these subdomains can be allocated to separate zones, and responsibility for these zones can also be delegated . If ftp.k-max.name is a separate zone, then k-max.name zone will not contain domain records that end in * .ftp.k-max.name.
So after delegation of responsibility, the information stored by the delegating zone no longer includes information on the delegated subdomain and its resource records of hosts, but stores information about name servers that are authoritative for the delegated subdomain. These are the “gluing” records, which I have already mentioned above. In this case, if the DNS server of the parent domain requests information about the address belonging to the delegated subdomain, a list of DNS servers that have the appropriate information is provided in response.
DNS servers
Above, when considering the types of resource records, I mentioned the primary and secondary server. In addition to these types, there is another type - caching .
The main DNS server (it’s primary , it’s master , it’s primary ) is the authoritative server (sometimes called authoritarian, I don’t know how to call it right), which stores the master copy of the zone data file , followed by the system administrator.
The secondary server is also authoritative , but it copies the master zone file from the primary server . The only difference between the main and secondary is that the main loads its information from the zone configuration files, and the secondary one loads (receives) zone settings from the main server. A secondary DNS can receive its data from another secondary server. Any request for a host within the zone for which the authoritative server is responsible will eventually be transmitted to one of these servers (the main or secondary). Secondary servers can be as many as you like. Depending on the settings, the main server can send a signal to the secondary to change the zone, while the secondary , receiving the signal, makes a copy. This action is called zone transfer. There are two mechanisms for copying a zone : full copy (AXFR) and incremental (incremental) copy of a zone (IXFR) .
Caching servers are NOT AUTHORITY , these servers are stored in memory (cache), replies to previous requests, if this server received a request, it first looks at the information in the cache, and if the necessary answer is not found in the cache, then sends the request to a higher-level DNS server.
It is also possible to configure DNS in stels mode (so-called invisible), information about this server cannot be obtained using direct queries. This can be useful for organizing a primary server in a secure environment and thus protect the zone from attacks on the zone.
DNS clients (resolver)
How do the programs on the end machines know where and in what form to send DNS queries? They don't know that. For resolving names and IP addresses by client applications, the Resolver library is used. This is not a special application, it is the functionality of the system (kernel). So applications send system calls gethostbyname (2) and gethostbyaddr (2), and the kernel already determines the path to which to proceed further, based on the settings in the /etc/nsswitch.conf file. This file determines which services (whether it is the / etc / hosts or DNS file ) and in what order to use. In earlier versions of the Linux library, libc , the /etc/host.conf file was used . Here is a fragment of the file that interests us:
root @ DNS: ~ # cat /etc/nsswitch.conf ...... hosts: files dns networks: files
Two lines of this fragment tell the kernel to convert host names to IP ( hosts: files dns string), first from the hosts file , then by DNS , and also network names to IP (networking : files string) using the / etc / network file. There are also options for nis or nisplu , which determine to use the Network Information System (NIS) to find the address. The order in which the services are listed determines the order in which they are polled.
If, according to /etc/nsswitch.conf, the DNS request is sent, then the settings from the /etc/resolv.conf file are used, which determines which DNS servers to use. Here is a typical example of the /etc/resolv.conf file:
root @ DNS: ~ # cat /etc/resolv.conf nameserver 192.168.1.1 nameserver 192.168.1.2 domain examle.com
The nameserver directive specifies the address of the domain name server that will perform recursive resolver queries. In this file, it is indicated to use the name north first 192.168.1.1 then, if the first could not process the request, 192.168.1.2. It is recommended not to use more than 3 nameserver parameters . If the nameserver option is not specified, the resolver will attempt to connect to the server on the local host. The domain parameter specifies the default domain name that will be substituted when DNS cannot find the host name. There is also a search option that specifies additional domains in which the host name must be searched for and resolved. The search and domain options cannot be shared.
In addition to the cache on the DNS server , there are caches for Internet browsers , resolver caches . A pretty transparent picture is provided by Wikipedia:
DNS queries
The following types of queries are available in DNS: iterative (it is also direct ), reverse, and recursive .
An iterative ( direct , non-recursive ) request sends the domain name to the DNS server and asks for the return of either the IP address of this domain or the name of the DNS server authoritative for this domain. However, the DNS server does not poll other servers for a response. This is how root and TLD servers work.
A recursive query sends a domain name to the DNS server and asks to return the IP address of the requested domain. At the same time, the server can access other DNS servers.
The return request sends the IP and requests to return the domain name.
Any DNS server must respond to iterative queries . It is possible to configure the DNS to respond to recursive requests . If DNS is not configured to respond to recursive queries, it treats them as iterative .
Usually,
Let's look at what is drawn in steps:
- The client (browser, email program, or any other application) sends a request to the resolver , the resolver determines the address of the configured name server based on the specified configs.
- Resolver sends a request to the specified name server .
- The name server accepts this recursive query and, because has no information about the domain, or perhaps even about the name zone., sends a recursive (or non-recursive depending on the settings) request to the server responsible for the root zone .
- The root zone server does not process recursive requests, as a result, it processes this request as iterative and returns the name and address of the server that is authoritative for the name zone.
- The server continues to poll the authoritative servers for the subsequent zones, in descending order of the level of the zones in the name
- until you get a satisfactory answer, these steps may be longer, depending on the length of the domain name
- and “nesting” of domain names.
- As a result, the server receives the necessary response from the name server storing the necessary resource record of the host.
- Server
providerthe local network returns to the client resolver the requested data.
Usually, the number of steps is reduced to a minimum, because On the way to query flow, there is a caching server that stores the necessary information in the cache. In this scheme, the question may arise: how does the local DNS server that received the recursive request from the resolver choose a DNS server from the authoritative list? There are many root DNS servers on the Internet, which of our root servers will our DNS server send a request to?
To address this issue, BIND DNS servers use a metric called response time ( roundtrip time , or RTT ) to select among authoritative DNS servers of the same zone. RTT determines the delay with which the response to requests from the remote server comes. Each time a request is sent to a remote server, the BIND DNS server starts an internal timer. The timer stops when a response is received, and the metric is fixed by the local server. If you have to choose one of several authoritative servers, the choice falls on the server with the lowest RTT.
Before BIND first sent a request to a server and received a response from it, a remote RTT value is assigned to the remote server, which is less than all the others received on the basis of measurements. Thus, DNS BIND is guaranteed to poll all authoritative servers for a particular zone randomly, before it starts to choose the preferred one based on the metric.
DNS server responses
DNS responses are of the following type:
- The authoritative response comes from the servers that are responsible for the zone.
- A non-authoritative response (non-authoritative response) comes from servers that are not responsible for the zone (from caching).
The DNS response usually contains the following information:
- Header record - service information about the request.
- Record request - repeats the sent request.
- Record the answer - actually, the answer itself.
- Records of reputable servers - information about reputable servers that store information on the current request.
- Additional information - additional entries, for example addresses of NS-servers.
The above is clearly confirmed by the dig utility:
root @ DNS: ~ # dig ya.ru ; << >> DiG 9.7.3 << >> ya.ru (heading section) ;; global options: + cmd ;; Got answer: ;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 53499 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: (query section) ; ya.ru. IN A ;; ANSWER SECTION: (response section) ya.ru. 4813 IN A 87.250.250.203 ya.ru. 4813 IN A 87.250.251.3 ya.ru. 4813 IN A 93.158.134.3 ya.ru. 4813 IN A 93.158.134.203 ya.ru. 4813 IN A 213.180.204.3 ya.ru. 4813 IN A 77.88.21.3 ya.ru. 4813 IN A 87.250.250.3 ;; AUTHORITY SECTION: (authoritative servers) ya.ru. 4813 IN NS ns1.yandex.ru. ya.ru. 4813 IN NS ns5.yandex.ru. ;; ADDITIONAL SECTION: (additional information - addresses of authoritative name servers) ns5.yandex.ru. 345565 IN A 213.180.204.1 ns1.yandex.ru. 345565 IN A 213.180.193.1 ns1.yandex.ru. 3565 IN AAAA 2a02: 6b8 :: 1 ;; Query time: 7 msec ;; SERVER: 192.168.1.1 # 53 (192.168.1.1) ;; WHEN: Sat Jul 2 23:02:45 2011 ;; MSG SIZE rcvd: 238
Inverse name resolution
DNS is used primarily to convert domain names to IP addresses, but it can also perform a reverse process, called reverse name translation or reverse mapping . Because records in the direct DNS database are hierarchically structured by domain names; DNS cannot effectively search by IP address in such a database. For the reverse conversion to the DNS, the special domain in-addr.arpa is used. Resource records in this domain in the Name field contain IP-addresses, in the Type field - PTR , and in the Data field - FQDN-name corresponding to this IP.
The diagram shows the structure of the arpa domain. I think that everything is pretty clear here. Domain arpa. It has 2 sub - domains in-addr and ip6 , responsible for IPv4 and IPv6 addresses, respectively. Domain in-addr.arpa. has from * .0.in-addr.arpa. to * .255.in-addr.arpa. subdomains, each of which also has 256 subdomains.
In order to reduce the amount of unwanted correspondence (spam), many mail servers can check for PTR records for the host from which they are sent. In this case, the PTR record for the IP address must match the name of the sending mail server, which it represents during the SMTP session.
Visually presented scheme can be represented by commands:
[root @ DNS ~] # dig www.ru ... ;; QUESTION SECTION: ; www.ru IN A ;; ANSWER SECTION: www.ru 52119 IN A 194.87.0.50 ... [root @ DNS ~] # dig -x 194.87.0.50 ... ;; QUESTION SECTION: ; 50.0.87.194.in-addr.arpa. IN PTR ;; ANSWER SECTION: 50.0.87.194.in-addr.arpa. 30385 IN PTR www.ru ....
In this case, the dig -x 194.87.0.50 command would be more correctly represented as dig 50.0.87.194.in-addr.arpa., That is, entries in the subdomains * .in-addr.arpa. presented in the so-called reverse notation (or reverse form), that is, a PTR record with the FQDN 50.0.87.194.in-addr.arpa., which in turn indicates the www.ru domain, would correspond to a host with IP 194.87.0.50, which in turn indicates the www.ru domain . Note that most often the Internet provider is responsible for the reverse zone and its editing.
As promised, I describe the PTR resource record in the IN-ADDR.ARPA domain, corresponding to the above A record for the www.ru. will look like this:
50.0.87.194 IN PTR www.ru
The name 50.0.87.194 does not end with a period and therefore is relative. Question: relative to what? In no case is relative to " www.ru ". In order for this entry to be a FQDN, the default domain must be called “IN-ADDR.ARPA.”. This can be achieved either by placing the PTR records in a separate file, in which the default domain name of the zone is IN-ADDR.ARPA. (specified in the bootstrap daemon of the named daemon), or by changing this domain using the $ ORIGIN directive. If the default domain is defined as 0.87.194.IN-ADDR.ARPA., Then the record can be represented as follows:
80 IN PTR www.ru
Domain Name Registration
In a nutshell, I would like to raise the issue of domain name registration .
Domain registration is the action by which the client informs the registrar which DNS servers to delegate the subdomain to, and also provides the registrar with contact and payment information. The registrar sends the information to the appropriate registry. Most often, this is the process of registering the first level zone (that is, in the TLD of the ru, com, or other zones) with the record of a new domain name.
A domain name registrar is an organization that has the authority to create (register) new domain names and extend the validity of already existing domain names in the domain for which mandatory registration is established.
Domain levels for which mandatory registration of the person responsible for the domain is necessary are as follows:
- root domain
- all first level domains (tld)
- some second-level domains (for example, com.ru or co.uk)
The registrar for the root domain is the ICANN organization . To become a domain registrar in second-level zones (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs ...), you need to get ICANN accreditation.
Registration rules in international (gTLD - com., Org, etc.) domains are established by ICANN. Registration rules in national (ccTLD - ru, us, etc.) domains are set by their registrars and / or authorities of the respective countries, for example, uniform rules for all registrars in .ru, and .rf domains are set by the Coordination Center of the national Internet domain. For many domains (including ru), the registrar is not the only one. If there are several registrars, all of them should use a single (centralized or distributed) database to eliminate conflicts and ensure the uniqueness of the domain name.
In most cases, the domain registration service is paid, the registrar determines the price and terms of registration. To register a domain, you must select a free name and send an application for registration with one of the registrars (for example, nic.ru), pay for the provision of services. After registration is confirmed, it is necessary to determine (delegate) the server dns in the registrar's interface, most likely it will be your hoster’s DNS.
At the end of the article I want to note the same about such marketing nuance that sometimes second-level domains are called domain names of the FIRST level, thereby “omitting” the root domain value and taking it as the root domain - TLD domains.
I also want to note that the domain address and IP address are not identical - a single IP address can have multiple names, which allows you to maintain multiple websites on one computer (this is called virtual hosting). The reverse is also true — multiple IP addresses can be mapped to a single name: this allows you to create load balancing.
Summary
So, in today's article I tried to describe the work of the domain name system as clearly as possible. I hope I did it. We reviewed the hierarchical structure of the DNS database, as well as the processes of interaction between clients and DNS servers, as well as types of DNS servers. In the next article I will discuss the practical issues of installing and configuring the BIND DNS server on Linux. I will be glad to your comments.
What else to read:
man (5) resolver: http://www.opennet.ru/man.shtml?topic=resolver&category=5&russian=0
man (3) gethostbyname: http://www.opennet.ru/cgi-bin/opennet/man .cgi? topic = gethostbyname & category = 3
Linux Network Administrators Guide v2 Russian: download .
RFC882, 1035, 1183
Placed with the permission of mcsim85 , which does not yet have a full-fledged account on Habré, but which for such high-quality articles definitely deserves it! Just in case the link to the original.
Source: https://habr.com/ru/post/137587/
All Articles