Domain name system

The Domain Name System (Domain Name System or DNS) is a hierarchical naming system decentralized for devices connected to IP networks such as the Internet or a private network. This system associates various information with domain names assigned to each of the participants. Its most important function is to "translate" human-intelligible names into binary identifiers associated with the equipment connected to the network, with the purpose of being able to locate and address these equipment worldwide.

The DNS server uses a distributed, hierarchical database that stores information associated with domain names on networks such as the Internet. Although as a database the DNS is capable of associating different types of information to each name, the most common uses are the assignment of domain names to IP addresses and the location of the email servers for each domain.

Mapping names to IP addresses is certainly the best known function of the DNS protocols. For example, if the IP address of the Google site is 216.58.210.163, most people reach this computer by specifying www.google.com and not the IP address. In addition to being easier to remember, the name is more reliable. The numerical address could change for many reasons, without you having to change the name of the website. Even in the event that a web page uses a content distribution network (Content delivery network or CDN) through DNS, the user will receive the IP address from the closest server according to your geographic location (each CDN in turn has its own DNS servers).

History

Mostly, DNS was born out of the need to easily remember the names of all servers connected to the Internet. Originally, SRI (now SRI International) hosted a file called HOSTS that contained all known domain names.

The explosive growth of the network made the centralized naming system in the hosts file impractical and in November 1983 Jon Postel published the blueprint in RFC 881 and later with Paul Mockapetris published RFC 882 and RFC 883 that same year. In October 1984, and after long discussions, they issued RFC 920, defining what today has evolved into the modern DNS (these RFC 882 and 883 were replaced in 1987 with RFC 1034 and RFC 1035).

If DNS servers did not exist, users would have to type the IP address of the website instead of typing its URL, which would cause confusion and make browsing the Internet very complicated for users.

At this stage, the best way to provide "continuity" was to have multiple servers answering multiple queries. One server was the master and the others were slaves. Each of the slaves had to periodically check with the master that the data had not changed.

About 10 years later, some major adjustments were made to the DNS protocol. This was a more dynamic way of keeping servers up to date, using NOTIFY and incremental zone transfers (IXFR).

NOTIFY was a key change. Instead of waiting for a slave to check out, the master could send NOTIFY messages to the slaves, urging them to acquire the new data. For its part, IXFR meant a change in the way data was communicated. If you changed just one out of hundreds of records, the original specification would send hundreds of messages. IXFR changed the system, allowing only records that changed to be sent.

The next evolution of DNS came when dynamic changes were defined in RFC 2136. This allowed server administrators to better make changes to records. Later, RFC 2671 defined Extension Mechanisms for DNS (EDNS) which further modernized the system.

Interest in expanding possible domain names to include characters from other languages was reflected in internationalized domain names as defined in RFC 5890 and RFC 5891 in 2010.

Components

For the practical operation of the DNS system, three main components are used:

Phase 1 customers

A DNS client program running on the user's computer and generating DNS name resolution requests to a DNS server (For example: What IP address corresponds to name.domain?)

DNS servers

They answer the customer's requests. Recursive servers have the ability to forward the request to another server if they do not have the requested address.

Areas of authority

It is a part of the domain name space on which a DNS server is responsible, which may have authority over several areas. (For example: subdomain.Wikipedia.ORG, subdomain.COM, etc.)

Understanding the parts of a domain name

A domain name usually consists of two or more parts (technically "tags"), separated by periods when written as text. For example, www.example.com or en.wikipedia.org

• The label located more to the right is called the "higher level domain" (in English) top level domain). Like,com» in www.ejemplo.com u «org» in is.wikipedia.org
• Each label on the left specifies a subdivision or “subdomain”. Note that "subdomain" expresses relative dependence, not absolute dependence. In theory, this subdivision may have up to 127 levels, and each label may contain up to 63 characters, but restricted to the fact that the total length of the domain name does not exceed 255 characters, although in practice the domains are almost always much shorter.
• Finally, the most left-hand side of the domain usually expresses the name of the machine (in English hostname). The rest of the domain name simply specifies how to create a logical route to the required information. For example, the domain is.wikipedia.org would have the name of the machine “is”, although in this case it does not refer to a particular physical machine.

DNS consists of a hierarchical set of DNS servers. Each domain or subdomain has one or more "authority zones" that publish information about the domain and the service names of any included domains. The hierarchy of the zones of authority coincides with the hierarchy of the domains. At the top of that hierarchy are the root servers: the servers that respond when seeking to resolve a first- and second-level domain.

DNS in the real world

Users generally do not communicate directly with the DNS server: name resolution is done transparently by client applications (for example, browsers, mail clients, and other applications that use the Internet). When making a request that requires a DNS lookup, the request is sent to the operating system's local DNS server. The operating system, before establishing any communication, checks if the response is in the cache. In the event that it is not found, the request will be sent to one or more DNS servers, the user can use the servers of his ISP, he can use a free domain resolution service or contract an advanced payment service that for In general, they are services contracted by companies for their speed and the security that they offer.

Most home users use the DNS server provided by the Internet service provider except those who customize their equipment or routers for certain public servers. The address of these servers can be configured manually or automatically through DHCP (dynamic IP). In other cases, network administrators have configured their own DNS servers.

In any case, the DNS servers that receive the request first look to see if they have the response in the cache. If so, they serve the answer; otherwise, they would start the search recursively. Once the response is found, the DNS server will store the result in its cache for future use and return the result.

Typically the DNS protocol transports requests and responses between client and server using the UDP protocol, since it is much faster. The occasions where the TCP protocol is used are: when it is necessary to transport responses greater than 512 bytes in length (for example when using DNSSEC) and when information is exchanged between servers (for example when doing a zone transfer), for reliability reasons.

DNS Hierarchy

DNS tree

The domain name space has a tree structure. The leaves and tree nodes are used as tags for the media. A fully qualified domain name of an object consists of the concatenation of all the labels of a path. Tags are alphanumeric strings (with "-" as the only symbol allowed), must be at least one character and no more than 63 characters long, and must begin with a letter (and not "-"). Tags Individuals are separated by dots. A domain name ends with a period (although this last period is usually omitted, since it is purely formal). A correctly formed domain name (FQDN, for its acronym in English), is for example this: www.example.com. (including the period at the end).

A domain name must include all periods and has a maximum length of 255 characters.

A domain name is always written from right to left. The dot on the far right of a domain name separates the root label of the hierarchy. This first level is also known as a top-level domain (TLD).

Objects in a DNS domain (for example, the computer name) are registered in a zone file, located on one or more name servers.

Types of DNS servers

These are the types of servers according to their function:

Primary or teachers

they save the data from a namespace in their files.

Secondary or slaves

obtain data from primary servers through a zone transfer.

Local or cache

they work with the same software, but they do not contain the database for the resolution of names. When they are consulted, they in turn consult the corresponding DNS servers, storing the response in their database to expedite the repetition of these requests in the continuous or free future.

Types of domain name resolution

A DNS server can resolve a domain name "recursively" or "iteratively". In an "iterative" query, a client requests a DNS server to retrieve the complete response itself (i.e., given the domain my.domain.com, the client expects to receive the corresponding IP address). On the other hand, given a "recursive" query, the DNS server does not provide a complete response: in the case of my.domain.com, the first server to which the query is made (a server root), returns the IP addresses of the top-level servers (TDL) responsible for the domain .com. In this way, the client must now perform a new query to one of these servers, which takes note of the suffix .domain.com and responds with the IP of the corresponding DNS server, for example dns.domain.com. Finally, the client sends a new query to dns.domain.com to get the IP address of my.domain.com.

In practice, a host's query of a local DNS is recursive, while queries made by the local DNS are iterative. Furthermore, recursive queries are only performed in case the local DNS server does not have the corresponding data in cache (or in case it has expired). In summary, the normal resolution process is carried out as follows:

1. The local DNS server receives a recursive consultation from resolve from the client host.
2. The local DNS conducts the iterative queries to the corresponding servers.
3. The local DNS server delivers the resolution to the host that requested the information.
4. The resolve the client host gives the answer to the corresponding application.

Security Issues

Originally, security concerns were not major design considerations in DNS software or any other software for deployment on the early Internet, since the network was not open to participation by the general public. However, the expansion of the Internet in the commercial sector in the 1990s changed the requirements for security measures to protect data integrity and user authentication.

Many vulnerability issues were discovered and exploited by malicious users. One such issue is DNS cache poisoning, in which data is distributed to cache resolvers under the guise of being an origin authority server, thus contaminating the data store with potentially false information and long expiration times. (time-to-live). Subsequently, legitimate application requests can be redirected to network equipment operated with malicious content.

DNS responses were traditionally not cryptographically signed, allowing many attack possibilities; DNS Security Extensions (DNSSEC) modify DNS to add the ability to have cryptographically signed responses. DNSCurve has been proposed as an alternative to DNSSEC. Other extensions, such as TSIG, add support for cryptographic authentication between trusted peers and are commonly used to authorize zone transfers or dynamic update operations.

Some domain names can be used for deception purposes. For example, paypal.com and paypa1.com are different names, but users may not be able to tell the difference depending on the font they are using. In many typefaces the letter l and the numeral 1 look very similar or even identical. This problem is serious in systems that allow internationalized domain names, since many characters in ISO 10646 can appear identical on typical computer screens. This vulnerability is occasionally exploited in phishing.

Techniques such as reverse FDNS with forward commit can also be used to validate DNS results.

Resource records

The Domain Name System specifies a database of information elements for network resources. Information item types are categorized and organized with a list of DNS record types: Resource Records (RRs). Each record has a type (name and number), an expiration time (time to live), a class, and type-specific data. Resource records of the same type are described as a resource record set (RRset) and have no specific order. DNS resolvers return the full set upon query, but servers may implement round-robin ordering to achieve load balancing. By contrast, Domain Name System Security Extensions (DNSSEC) work on the full set of resource records in canonical order.

When sent over an Internet Protocol network, all records use the common format specified in RFC 1035:

NAME is the fully qualified domain name of the node in the tree. During the connection, the name can be shortened using label compression where the ends of the domain names mentioned above in the packet can be replaced with the end of the current domain name. An independent @ is used to denote the current origin.

TYPE is the record type. It indicates the format of the data and gives an idea of the intended use. For example, the A record is used to translate from a domain name to an IPv4 address, the NS record lists which name servers can answer queries in a DNS zone, and the MX record specifies the mail server used to handle mail from a domain specified in a dns layered email address.

RDATA is data of a specific type of relevance, such as IP address for address records, or priority and hostname for MX records. Known record types can use label compression on the RDATA field, except for "unknown" (RFC 3597).

CLASS is the record class set to IN (Internet) for common DNS records involving hostnames, servers, or IP addresses. In addition, there are the classes Chaos (CH) and Hesiod (HS). Each class is a separate namespace with potentially different delegations of DNS zones.

In addition to the resource records defined in a zone file, the domain name system also defines various request types that are used only in communication with other DNS nodes (on the connection), such as when performing transfers for zone (AXFR / IXFR) or for EDNS (OPTAR).

Wildcard DNS Records

The domain name system supports wildcard DNS records, which specify names beginning with the asterisk tag "*", eg *.example. DNS records pertaining to wildcard domain names specify rules for generating resource records within a single DNS zone by replacing labels with matching components of the name, including any specified descendants. For example, in the following configuration, the DNS zone x.example specifies that all subdomains, including subdomains of subdomains, of x.example use the mail exchanger (MX) a.x.example. The A record for a.x.example is required to specify the IP address of the mail exchanger. Since this results in excluding this domain name and its subdomains from wildcard matches, an additional MX record must also be defined for the a.x.example subdomain, as well as a wildcard MX record for all its subdomains in the DNS zone.

x.example. MX 10 a.x.example.
*.x.example. MX 10 a.x.example.
*.a.x.example. MX 10 a.x.example.
a.x.example. MX 10 a.x.example.
a.x.example. AAAA 2001:db8::1

The role of wildcard records was refined in RFC 4592, because the original definition in RFC 1034 was incomplete and led to misinterpretation by implementers.

Types of DNS records

The most commonly used record types are:

Glue Log

An "A" and "AAAA" record is said to be a "glue record" (in English, glue record) when it defines a domain pointed to by an NS record. A glue record associates a "glue" IP address with the subdomain that you want to use as a DNS server.

For example, suppose we have the domain "yourdomain.com" for which I have the subdomains "ns1.yourdomain.com" and "ns2. yourdomain.com.” Then we could make a configuration like:

yourdomain.com IN NS ns1.yourdomain.com
yourdomain.com IN NS ns2.yourdomain.com
ns1.yourdomain.com IN A 182.18.164.24
ns1.yourdomain.com IN AAAA 2400:3b00:1:2
ns2.yourdomain.com IN A 103.231.77.204
ns2.yourdomain.com IN AAAA 2400:3b00:20:4:d4

The last four records are said to be glue records.

DNS Standards

The following documents define the Domain Name System:

• RFC 881, The Domain Names Plan and Schedule – The Domain Names Plan and its Agenda, formal start of the work planning for conceptualization.
• RFC 920, Domain Requirements – Specifies original top level domains
• RFC 1032, Domain Administrators Guide
• RFC 1033, Domain Administrators Operations Guide
• RFC 1034, Domain Names - Concepts and Facilities
• RFC 1035, Domain Names - Implementation and Specification
• RFC 1101, DNS Encodings of Network Names and Other Types
• RFC 1123, Requirements for Internet Hosts—Application and Support
• RFC 1178, Choosing a Name for Your Computer (FYI 5)
• RFC 1183, New DNS RR Definitions
• RFC 1591, Domain Name System Structure and Delegation (Informational)
• RFC 1912, Common DNS Operational and Configuration Errors
• RFC 1995, Incremental Zone Transfer in DNS
• RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
• RFC 2100, The Naming of Hosts (Informational)
• RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)
• RFC 2181, Clarifications to the DNS Specification
• RFC 2182, Selection and Operation of Secondary DNS Servers
• RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
• RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
• RFC 2671, Extension Mechanisms for DNS (EDNS0)
• RFC 2672, Non-Terminal DNS Name Redirection
• RFC 2845, Secret Key Transaction Authentication for DNS (TSIG)
• RFC 3225, Indicating Resolver Support of DNSSEC
• RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements
• RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
• RFC 3696, Application Techniques for Checking and Transformation of Names (Informational)
• RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification
• RFC 4592, The Role of Wildcards in the Domain Name System
• RFC 4635, HMAC SHA TSIG Algorithm Identifiers
• RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance (Informational)
• RFC 5001, DNS Name Server Identifier (NSID) Option
• RFC 5452, Measures for Making DNS More Resilient against Forged Answers
• RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)
• RFC 5890, Internationalized Domain Names for Applications (IDNA):Definitions and Document Framework
• RFC 5891, Internationalized Domain Names in Applications (IDNA): Protocol
• RFC 5892, The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
• RFC 5893, Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
• RFC 5894, Internationalized Domain Names for Applications (IDNA):Background, Explanation, and Rationale (Information)
• RFC 5895, Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 (Information)
• RFC 5966, DNS Transport over TCP - Implementation requirements
• RFC 6195, Domain Name System (DNS) IANA Considerations (BCP 42)

Security

• RFC 4033, DNS Security Introduction and Requirements
• RFC 4034, Resource Records for the DNS Security Extensions
• RFC 4035, Protocol Modifications for the DNS Security Extensions
• RFC 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records
• RFC 4470, Minimally Covering NSEC Records and DNSSEC On-line Signing
• RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors
• RFC 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• RFC 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
• RFC 5910, Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
• RFC 5933, Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC