Domain Name System
| Domain Name System (DNS) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Family: | Internet protocol family | ||||||||||||||||||||||||
| Operation area: | Name resolution | ||||||||||||||||||||||||
| Ports: |
53 / UDP |
||||||||||||||||||||||||
|
|||||||||||||||||||||||||
| Standards: |
RFC 1034 (1987) RFC 1035 (1987) |
||||||||||||||||||||||||
The Domain Name System ( DNS ) is one of the most important services in many IP -based networks . Its main task is to answer requests for name resolution .
DNS works in a similar way to directory inquiries. The user knows the domain (the name of a computer on the Internet that people can remember) - for example example.org. It sends this as a request on the Internet. The domain is then converted by the DNS into the associated IP address (the "connection number" on the Internet) - for example an IPv4 address of the form 192.0.2.42or an IPv6 address such as 2001:db8:85a3:8d3:1319:8a2e:370:7347- and thus leads to the correct computer.
overview
The DNS is a hierarchical directory service distributed on thousands of servers worldwide that manages the namespace of the Internet. This namespace is divided into so-called zones , for which independent administrators are responsible. For local requirements - for example within a company network - it is also possible to operate a DNS that is independent of the Internet.
The DNS is mainly used to convert domain names into IP addresses ( forward lookup ). This can be compared to a telephone book, which breaks down the names of the participants into their telephone numbers. The DNA thus offers a simplification, because people can remember names much better than strings of numbers. This makes it easier to remember a domain name such as example.org than the associated IP address 192.0.32.10. This point becomes even more important in the course of the introduction of IPv6 , because then IPv4 and IPv6 addresses are assigned to a name. For example, the name www.kame.net breaks down into the IPv4 address 203.178.141.194and the IPv6 address 2001:200:dff:fff1:216:3eff:feb1:44d7.
Another advantage is that IP addresses - for example from web servers - can be changed with relatively little risk. Since Internet users only address the (unchanged) DNS name, changes to the subordinate IP level are largely hidden from them. Since several IP addresses can be assigned to one name, even a simple load distribution can be implemented via DNS ( load balancing ).
With the DNS, a reverse resolution of IP addresses in names ( reverse lookup ) is also possible. In analogy to the telephone book, this corresponds to a search for the name of a subscriber for a known phone number, which is known within the telecommunications industry as an inverse search .
The DNS was designed by Paul Mockapetris in 1983 and described in RFC 882 and RFC 883 (RFC = Request for Comments ). Both have since been replaced by RFC 1034 and RFC 1035 and supplemented by numerous other standards. The original task was to replace the local hosts files, which had previously been responsible for name resolution and which could no longer cope with the enormously increasing number of new entries. Due to the proven high reliability and flexibility, additional data sets were gradually integrated into the DNS and thus made available to Internet users (see below: Extension of the DNS ).
DNS is characterized by:
- decentralized administration,
- hierarchical structuring of the namespace in tree form,
- Uniqueness of names,
- Expandability.
Components
Domain namespace
The domain namespace has a tree-shaped structure. The leaves and nodes of the tree are called labels. A complete domain name of an object consists of the concatenation of all labels of a path.
Labels are character strings that are at least one byte and a maximum of 63 bytes long ( RFC 2181 , section “11. Name syntax”). Individual labels are separated from one another by dots. A domain name ends with a period (the last period is usually left out, but is formally part of a complete domain name). Thus, a correct, complete domain name (also called fully qualified domain name (FQDN) ) is for example www.example.com. and may be a maximum of 255 bytes long including all dots.
A domain name is always delegated and resolved from right to left, i.e. the further to the right a label is, the higher it is in the tree. The point at the right end of a domain name separates the label for the first level of the hierarchy from the root (English root ). This first level is also known as the top-level domain (TLD). The DNS objects of a domain (for example the computer names) are usually kept as a set of resource records in a zone file that is available on one or more authoritative name servers. The more general term zone is usually used instead of zone file .
Name server
A name server is a server that offers name resolution . Name resolution is the process that enables the names of computers or services to be resolved into an address that can be processed by the computer (e.g. www.wikipedia.org in 91.198.174.192 ).
Most name servers are part of the domain system that is also used on the Internet .
On the one hand, name servers are programs that answer inquiries about the domain name space on the basis of a DNS database . A distinction is made between authoritative and non-authoritative name servers.
An authoritative name server is responsible for a zone. His information about this zone is therefore considered secure . There is at least one authoritative server for each zone, the primary name server. This is listed in the SOA resource record of a zone file . For redundancy and load balancing reasons, authoritative name servers are almost always as a server - Cluster realized, wherein the zone data are identical to one or more secondary name servers. The synchronization between primary and secondary name servers is carried out by zone transfer .
A non-authoritative name server gets its information about a zone from other name servers from second or third hand, so to speak. His information is not considered secure . Since DNS data usually only change very rarely, non-authoritative name servers save the information requested by a resolver in the local RAM so that it is available more quickly when a new request is made. This technique is known as caching . Each of these entries has its own expiration date ( TTL time to live ), after which the entry is deleted from the cache. The TTL is determined by an authoritative name server for this entry and is determined according to the probability of the entry being changed (DNS data that changes frequently are given a low TTL). Under certain circumstances, this can mean that the name server provides incorrect information during this time if the data has changed in the meantime.
The caching-only name server is a special case. In this case, the name server is not responsible for any zone and must resolve all incoming requests via other name servers (forwarders). Various strategies are available for this:
- Cooperation between the individual name servers
In order for a non-authoritative name server to find information about other parts of the namespace, it uses the following strategies:
- Delegation
- Parts of the namespace of a domain are often outsourced to subdomains with their own responsible name servers. A name server in a domain knows the name server responsible for these subdomains from its zone file and delegates requests for this subordinate namespace to one of these name servers.
- Forwarding
- If the requested namespace is outside the own domain, the request is forwarded to a permanently configured name server.
- Resolution via the root name server
- If no forwarding server has been configured or if it does not respond, the root name servers are queried. For this purpose, the names and IP addresses of the root servers are stored in the form of a static file. There are 13 root servers (servers A to M). The root servers only answer iterative queries. Otherwise you would simply be overloaded with the number of requests.
Differently designed name resolutions by servers, such as the NetWare Name Service or the Windows Internet Naming Service , are mostly limited to local area networks and are increasingly being replaced by the Internet protocol family .
Resolver
Resolvers are simply structured software modules that are installed on the computer of a DNS participant and can call up information from name servers. They form the interface between the application and the name server. The resolver accepts the request from an application, supplements it, if necessary, to an FQDN and transmits it to a normally permanently assigned name server. A resolver works either recursively or iteratively.
In recursive mode, the resolver sends a recursive request to the name server assigned to it. If he does not have the desired information in his own database, the name server contacts other servers until he either receives a positive answer or until he receives a negative answer from an authoritative server. Resolvers that work recursively leave the work for the complete resolution to their name server.
In the case of an iterative query, the resolver either receives the desired resource record or a reference to other name servers that it asks next. The resolver works its way from name server to name server until it receives a binding response from one of them.
The resolver transfers the answer obtained in this way to the program that requested the data, for example to the web browser . Usual client resolvers only work recursively, they are then also referred to as stub resolvers. Name servers usually have their own resolver. These usually work iteratively .
Well-known programs for checking the name resolution are nslookup , host and dig .
protocol
DNS requests are usually sent to the name server via UDP port 53. The DNS standard also requires TCP to be supported for questions whose answers are too large for UDP transmissions. If no Extended DNS is used (EDNS), the maximum permissible length of the DNS-UDP packet is 512 bytes . Overly long answers are therefore transmitted truncated. The requesting client is informed of this fact by setting the truncated flag. He then has to decide whether the answer is enough for him or not. If necessary, it will repeat the request via TCP port 53.
Zone transfers are always carried out via port 53 TCP. The triggering of zone transfers is usually done via UDP.
Structure of the DNS database
The Domain Name System can be viewed as a distributed database with a tree structure. With Internet DNS, the data is stored on a large number of servers scattered around the world, which are linked to one another via references - called delegations in DNS terminology .
In each participating name server there are one or more files - the so-called zone files - which contain all the relevant data. These files are lists of resource records . Seven record types are of great importance:
- With the SOA resource record , parameters of the zone , such as B. Period of validity or serial number.
- The links ( delegations ) between the servers are implemented with the NS Resource Record .
- The actual data is defined with the following record types:
- An A resource record assigns an IPv4 address to a name .
- An AAAA resource record assigns an IPv6 address to a name .
- A CNAME resource record references one name to another.
- An MX resource record assigns a name to a mail server . It is special because it relates to a special service on the Internet, namely e-mail delivery using SMTP . All other services use CNAME , A and AAAA resource records for name resolution.
- A PTR resource record assigns a name to an IP address ( reverse lookup ) and is used equally for IPv4 and IPv6, only for IPv4 under the domain "IN-ADDR.ARPA." And for IPv6 under "IP6.ARPA." .
- A TXT resource record can assign a freely definable text to a name. One possible use here is the defense against spam .
In the course of time new types were defined with which extensions of the DNS were realized. This process is still ongoing. A comprehensive list can be found under Resource Record .
Examples:
The following NS Resource Record is defined in the zone file of the domain “org.”: The zone file for the domain “example.org.” Is on the server “ns0.example.org.”. The point at the end is important because it makes it clear that no relative name is meant, so there is nothing to add after "org". "IN" means that the entry has the class "Internet" and the number in front of it means the Time To Live (TTL) in seconds, it says how long this information could be temporarily stored in a cache before it should be requested again. With dynamic IP addresses, this number is usually between 20 and 300 seconds.
example 86400 IN NS ns0.example.org.
The following CNAME resource record is defined in the zone file of the domain “example.org.”: The name “de.example.org.” Refers to the name “rr.example.net.”.
de 3600 IN CNAME rr.example.net.
Define the following resource records in the zone file of the domain "example.net": The name "rr.example.net." Refers to the name "rr.esams.example.net." And this in turn is assigned the IPv4 address 203.0.113.232.
rr 600 IN CNAME rr.esams rr.esams 3600 IN A 203.0.113.232
Ultimately, all computers that want to connect to “de.example.org.” Have to 203.0.113.232send IPv4 packets to the IP address .
Resolution of a DNS request
Assume that a computer X wants to establish a connection to “de.wikipedia.org.” (Computer Y ). To do this, he needs its IP address. The following steps describe how this could be done. If the computer X is IPv6-capable, the process runs first for IPv6 (query from AAAA resource record ) and immediately afterwards for IPv4 (query from A resource record ). A request for an IPv6 address can be sent to an IPv4 DNS server using IPv4 transmission. If at the end an IPv6 and an IPv4 address are determined for computer Y , communication between X and Y via IPv6 is usually preferred according to the Default Policy Table in RFC 6724 , unless in the operating system or in the applications used, such as the web browser , this behavior has been set differently.
- Computer X searches in its hosts file to see whether the IP address for "de.wikipedia.org" is stored there. If this is not the case, he asks the DNS server. This is either permanently entered or was automatically assigned via DHCP or DHCPv6 and has the form nameserver 192.0.2.23 or nameserver 2001: db8 :: 23: cafe: affe: 42 .
- If the DNS server of computer X has cached an IP address for the requested name, it answers with it and the request comes to an end (see last point). Otherwise it asks one of the 13 root name servers for "de.wikipedia.org.".
- The root name server finds out that the resolution of this name continues in the "org." Zone and sends the names and IP addresses of the "org." Nameservers ( NS Resource Records and their AAAA or A Resource Records ) to the DNS server of the computer X .
- Now the DNS server of computer X asks one of the name servers for “org.” Domains for “de.wikipedia.org.”.
- The "org." Name server sends him the names of the name servers (and their IP addresses, provided they belong to the same top-level domain) for the zone "wikipedia.org.".
- The DNS server of computer X then asks a “wikipedia.org.” Name server such as the IP address of the name “de.wikipedia.org.”.
- This address is used to reply to the DNS server of computer X and the ...
- ... sends them to computer X , which can now, for example, send its HTTP requests to the IP address of “de.wikipedia.org.”.
Example name resolution
In the following example with comments, the IPv4 address is determined for the name "www.heise.de." With the help of the resolver tool dig . " +trace" Means that the individual responses to iterative queries to the name server hierarchy are given, " +additional" ensures that it is also shown that the name servers not only manage NS resource records for delegations , but also their IP addresses in the form of some Knowing about A or AAAA resource records and delivering them with them, " -t A" finally asks for the A resource record , ie the IPv4 address. It turns out that four name servers have to be queried one after the other to get the answer:
$ dig +trace +additional -t A www.heise.de.
; <<>> DiG 9.5.1-P3 <<>> +trace +additional -t A www.heise.de. ;; global options: printcmd . 6086 IN NS B.ROOT-SERVERS.NET. . 6086 IN NS D.ROOT-SERVERS.NET. . 6086 IN NS J.ROOT-SERVERS.NET. . 6086 IN NS G.ROOT-SERVERS.NET. . 6086 IN NS K.ROOT-SERVERS.NET. . 6086 IN NS C.ROOT-SERVERS.NET. . 6086 IN NS M.ROOT-SERVERS.NET. . 6086 IN NS I.ROOT-SERVERS.NET. . 6086 IN NS H.ROOT-SERVERS.NET. . 6086 IN NS E.ROOT-SERVERS.NET. . 6086 IN NS F.ROOT-SERVERS.NET. . 6086 IN NS A.ROOT-SERVERS.NET. . 6086 IN NS L.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 6644 IN A 128.8.10.90 J.ROOT-SERVERS.NET. 10421 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 1289 IN AAAA 2001:503:c27::2:30 G.ROOT-SERVERS.NET. 10940 IN A 192.112.36.4 K.ROOT-SERVERS.NET. 4208 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 7277 IN AAAA 2001:7fd::1 C.ROOT-SERVERS.NET. 6126 IN A 192.33.4.12 M.ROOT-SERVERS.NET. 3274 IN A 202.12.27.33 M.ROOT-SERVERS.NET. 7183 IN AAAA 2001:dc3::35 I.ROOT-SERVERS.NET. 9788 IN A 192.36.148.17 H.ROOT-SERVERS.NET. 10421 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 13739 IN AAAA 2001:500:1::803f:235 E.ROOT-SERVERS.NET. 11125 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 9973 IN A 192.5.5.241 ;; Received 500 bytes from 192.168.2.1#53(192.168.2.1) in 50 ms
192.168.2.1(see last line) is the registered name server of the querying computer, which refers to the root name server , all of which can be queried via IPv4, some also via IPv6. The root name servers manage the root zone (zone containing the name servers for .org, .de, .com and other top level domains) of name resolution, represented by a point. The IP addresses of the root name servers change very seldom and must be known to all name servers if they answer inquiries relating to the Internet. (These IP addresses can be supplied, for example, in a text file called "Root Hints".)
de. 172800 IN NS F.NIC.de. de. 172800 IN NS L.DE.NET. de. 172800 IN NS S.DE.NET. de. 172800 IN NS Z.NIC.de. de. 172800 IN NS A.NIC.de. de. 172800 IN NS C.DE.NET. A.NIC.de. 172800 IN A 194.0.0.53 C.DE.NET. 172800 IN A 208.48.81.43 F.NIC.de. 172800 IN A 81.91.164.5 F.NIC.de. 172800 IN AAAA 2001:608:6:6::10 L.DE.NET. 172800 IN A 89.213.253.189 S.DE.NET. 172800 IN A 195.243.137.26 Z.NIC.de. 172800 IN A 194.246.96.1 Z.NIC.de. 172800 IN AAAA 2001:628:453:4905::53 ;; Received 288 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in 58 ms
“I.ROOT-SERVERS.NET.” Was randomly selected from the 13 named root name servers to ask him the question about “www.heise.de.”. He replied with six name servers to choose from, which are responsible for the zone “de.”. Here, too, query using IPv6 is possible with two servers.
heise.de. 86400 IN NS ns.plusline.de. heise.de. 86400 IN NS ns.heise.de. heise.de. 86400 IN NS ns2.pop-hannover.net. heise.de. 86400 IN NS ns.pop-hannover.de. heise.de. 86400 IN NS ns.s.plusline.de. ns.s.plusline.de. 86400 IN A 212.19.40.14 ns.heise.de. 86400 IN A 193.99.145.37 ns.plusline.de. 86400 IN A 212.19.48.14 ns.pop-hannover.de. 86400 IN A 193.98.1.200 ;; Received 220 bytes from 81.91.164.5#53(F.NIC.de) in 52 ms
“F.NIC.de.” was randomly selected from the six named servers in order to find out more about “www.heise.de.”. He answered the question with five possible delegations. Among other things, with a delegation to the server "ns.heise.de.". This information would without the corresponding A resource record , on 193.99.145.37showing, not help on the same server, because the name is in the zone "heise.de." That it manages itself. One speaks in this type of information also glue records (of English. Glue , glue). If the server "ns2.pop-hannover.net." Is selected for the next step, its IP address would first have to be determined in a separate name resolution, as this was not sent here.
www.heise.de. 86400 IN A 193.99.144.85 heise.de. 86400 IN NS ns.pop-hannover.de. heise.de. 86400 IN NS ns.plusline.de. heise.de. 86400 IN NS ns2.pop-hannover.net. heise.de. 86400 IN NS ns.s.plusline.de. heise.de. 86400 IN NS ns.heise.de. ns.heise.de. 86400 IN A 193.99.145.37 ns.pop-hannover.de. 10800 IN A 193.98.1.200 ns2.pop-hannover.net. 86400 IN A 62.48.67.66 ;; Received 220 bytes from 193.98.1.200#53(ns.pop-hannover.de) in 4457 ms
From the five named servers, “ns.pop-hannover.de.” Was randomly used to answer the question about “www.heise.de.”. The answer is 193.99.144.85. The request has now reached its destination. Again, the same name servers are named as responsible for “heise.de.” Without referring to other name servers.
Example reverse lookup
For the reverse lookup , i.e. finding a name for an IP address, the IP address is first formally converted into a name, for which the DNS is then asked for a PTR resource record . Since the hierarchy for IP addresses is more specific from left to right (see subnet ), but for DNS it is from right to left, the first step is to reverse the order of the numbers and the IPv4 address 193.99.144.85becomes e.g. As the name of " 85.144.99.193.in-addr.arpa." as well as the IPv6 address 2a02:2e0:3fe:100::6, the name " 6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.e.f.3.0.0.e.2.0.2.0.a.2.ip6.arpa." generated. (This name is long, because the implicit zeros must now be mentioned again explicitly.)
The PTR resource record for the converted IPv4 address can be determined in the same way as in the previous example:
$ dig +trace +additional -t PTR 85.144.99.193.in-addr.arpa.
; <<>> DiG 9.5.1-P3 <<>> +trace +additional -t ptr 85.144.99.193.in-addr.arpa. ;; global options: printcmd . 2643 IN NS M.ROOT-SERVERS.NET. . 2643 IN NS A.ROOT-SERVERS.NET. . 2643 IN NS B.ROOT-SERVERS.NET. . 2643 IN NS C.ROOT-SERVERS.NET. . 2643 IN NS D.ROOT-SERVERS.NET. . 2643 IN NS E.ROOT-SERVERS.NET. . 2643 IN NS F.ROOT-SERVERS.NET. . 2643 IN NS G.ROOT-SERVERS.NET. . 2643 IN NS H.ROOT-SERVERS.NET. . 2643 IN NS I.ROOT-SERVERS.NET. . 2643 IN NS J.ROOT-SERVERS.NET. . 2643 IN NS K.ROOT-SERVERS.NET. . 2643 IN NS L.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 10978 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 2470 IN AAAA 2001:503:ba3e::2:30 C.ROOT-SERVERS.NET. 387 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 2747 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 7183 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 14225 IN AAAA 2001:500:2f::f H.ROOT-SERVERS.NET. 7950 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 13245 IN AAAA 2001:500:1::803f:235 I.ROOT-SERVERS.NET. 6172 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 7168 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 13860 IN AAAA 2001:503:c27::2:30 K.ROOT-SERVERS.NET. 3541 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 9369 IN AAAA 2001:7fd::1 L.ROOT-SERVERS.NET. 3523 IN A 199.7.83.42 ;; Received 512 bytes from 192.168.2.1#53(192.168.2.1) in 50 ms
193.in-addr.arpa. 86400 IN NS ns3.nic.fr. 193.in-addr.arpa. 86400 IN NS sec1.apnic.net. 193.in-addr.arpa. 86400 IN NS sec3.apnic.net. 193.in-addr.arpa. 86400 IN NS sunic.sunet.se. 193.in-addr.arpa. 86400 IN NS ns-pri.ripe.net. 193.in-addr.arpa. 86400 IN NS sns-pb.isc.org. 193.in-addr.arpa. 86400 IN NS tinnie.arin.net. ;; Received 239 bytes from 199.7.83.42#53(L.ROOT-SERVERS.NET) in 170 ms
99.193.in-addr.arpa. 172800 IN NS auth50.ns.de.uu.net. 99.193.in-addr.arpa. 172800 IN NS ns.ripe.net. 99.193.in-addr.arpa. 172800 IN NS auth00.ns.de.uu.net. ;; Received 120 bytes from 202.12.28.140#53(sec3.apnic.net) in 339 ms
144.99.193.in-addr.arpa. 86400 IN NS ns.heise.de. 144.99.193.in-addr.arpa. 86400 IN NS ns.s.plusline.de. 144.99.193.in-addr.arpa. 86400 IN NS ns.plusline.de. ;; Received 114 bytes from 194.128.171.99#53(auth50.ns.de.uu.net) in 2456 ms
85.144.99.193.in-addr.arpa. 86400 IN PTR www.heise.de. 144.99.193.in-addr.arpa. 86400 IN NS ns.heise.de. 144.99.193.in-addr.arpa. 86400 IN NS ns.s.plusline.de. 144.99.193.in-addr.arpa. 86400 IN NS ns.plusline.de. ns.heise.de. 86400 IN A 193.99.145.37 ;; Received 148 bytes from 193.99.145.37#53(ns.heise.de) in 4482 ms
The answer is "www.heise.de." However, it is not necessary that a name is assigned to each IP address, nor do the forward and reverse resolutions have to correspond to one another. The resolution begins again with the reference to the root name server and the delegations obviously take place at the boundaries between the numbers marked by dots. However, you can also see in the example that not every point has to be delegated in a name.
Extensions
Because DNS has proven reliable and flexible, several major enhancements have been introduced over the years. There is no end in sight to this trend.
Dynamic DNS
In classic DNS, it is time-consuming to assign a name to a new IP address. The associated zone file must be changed (usually manually) and the name server reloaded. Time delays of up to several days are common. With dynamic DNS , changes can be made by sending an update request with a short time delay.
Dynamic DNS is considered a security risk, since anyone can delete or change DNS entries without special precautions. Dynamic DNS is almost absolutely necessary in connection with DHCP , as new IP addresses are often assigned to a user. The DHCP server sends a corresponding message to the name server every time the address changes.
internationalization
Previously, the labels were limited to alphanumeric characters and the '-' character. '_' Is also possible for subdomains, but not in compliance with the standard. This limited set of characters is mainly due to the fact that DNS (like the Internet originally) was developed in the USA . As a result, characters commonly used in many countries (in the German-speaking area, for example the umlauts ä, ö and ü as well as ß) or characters from completely different writing systems (for example Chinese) were originally not possible in domain names.
A meanwhile established approach to increasing the character set is the internationalization of domain names (IDNA) introduced in 2003 in RFC 3490 and updated in 2010 with RFC 5890 . In order to keep the new system compatible with the previous one, the extended character sets are encoded with the characters permitted up to now. The extended character sets are first normalized in order to map uppercase letters to lowercase letters, among other things, and then mapped to an ASCII-compatible string using Punycode . IDNA requires an adaptation of the network applications ( e.g. web browser ), but the name server infrastructure (server, resolver) does not need to be changed. Since March 2004, German, Liechtenstein, Austrian and Swiss domains (.de, .li, .at and .ch) with umlauts can be registered and used in German-speaking countries. Internationalized domain names can also be used for other top-level domains , especially in Asia.
Extended DNS
In 1999 Paul Vixie described some smaller, downward compatible extensions to the Domain Name System in RFC 2671 , which are referred to as Extended DNS Version 0. By using a pseudo record as a header extension, the requesting party can set additional options. In particular, it can convey that it can receive UDP responses larger than 512 bytes. DNSSEC capable servers and resolvers must be able to use EDNS.
Management of telephone numbers
ENUM ( RFC 2916 ) is another current extension of the DNS . This application enables the addressing of Internet services via telephone numbers, ie the "dialing" of devices that can be accessed via the Internet with the numbering scheme known from the telephone network. From the wide range of possible uses, the use for Voice over IP services is particularly suitable .
RFID support
With RFID , IDs stored on special RFID labels - so-called electronic product codes or EPCs - can be read without contact. The DNS can be used to determine the server for an ID that contains data about the associated object. The Object Naming Service ONS converts the EPC into a DNS name and asks for one or more Naming Authority Pointers NAPTR via standard DNS.
Spam prevention
To filter spam mail, many mail servers routinely check the DNS entry of the sending mail server using the reverse DNS lookup. This must not only resolve correctly forwards and point to the IP address of the sending system ( forward-confirmed reverse DNS ), but must also correspond to the HELO host name of the sending system specified in the SMTP protocol.
An attempt is made to prevent falsified senders from being sent by third parties using the Sender Policy Framework . For each mail domain, a special SPF resource record is used to explicitly list the servers and IP networks from which e-mails for this domain can be expected. However, SPF has come under fire for numerous technical difficulties, such as redirects.
The DomainKeys (DKIM) anti-spam mechanism also uses entries in the DNS, as sending mail servers publish their public key in DNS TXT records, which can be used to verify the signature of their outgoing emails.
Others
In addition to the IP addresses, DNS names can also be assigned to ISDN numbers, X.25 addresses, ATM addresses, public keys , text lines, etc. In practice, however, such applications are the exception.
DNS in the local network
DNS isn't limited to the Internet. It is easily possible and compatible with the definition to set up separate zones in the name server for the resolution of local names and to enter the corresponding addresses there. The one-time installation effort is also worthwhile for relatively small networks, since all addresses in the network can then be managed centrally.
In larger companies or organizations, a mixed system consisting of local and Internet DNS (split DNS) can often be found. The internal users access the local DNS and the external users access the Internet. In practice, this can lead to very complicated constellations.
The DNS server BIND can also work with DHCP and thus enable name resolution for every client in the network.
Under Windows there is another name resolution service - WINS , which provides a similar function, but uses a different protocol.
DNS server network
It is possible to connect several DNS servers. The servers called masters are responsible for one or more domains. The slaves update the data themselves after a change, the master does not distribute this data automatically. The data are collected via a zone transfer .
For example, a company with several locations can operate a master for its internal DNS at one place, which supplies the servers in the branch offices. The zone transfer with BIND is done via TCP (by default port 53) and requires authentication. The slaves update themselves if the serial number for a zone file changes or if they receive a corresponding message from the master. The release for the transfer port should be linked to the IP address of the master via a firewall. With other software packages, the data may be synchronized in other ways, for example through LDAP replication, rsync, or other mechanisms.
safety
The DNS is a central component of a networked IT infrastructure. Malfunction can result in significant costs and corruption of DNS data can be the starting point for attacks.
Forms of attack
The main goal of DNS attacks is to manipulate DNS participants to direct them to false websites in order to subsequently obtain passwords, PINs, credit card numbers, etc. In rare cases, attempts are made to completely switch off the Internet DNS through denial-of-service attacks and thus paralyze the Internet. The DNS can also be used to intensify targeted attacks on individuals or companies.
DDoS attack on name servers
In a distributed denial of service attack, name servers are overloaded by a high data stream of DNS queries, so that legitimate queries can no longer be answered. There is currently no defense against DDoS attacks on name servers. As a preventive measure, an attempt can only be made to dimension the name servers accordingly or to install a distributed network with as many servers as possible. In order to generate a large number of DNS queries, botnets are used in such attacks .
A DDoS attack can unintentionally affect a DNS server and cause it to fail if the domain name of the attack target is repeatedly resolved without being cached. The effect on DNS servers is prevented if the DDoS malware uses DNS caching .
DNS amplification attack
The DNS amplification attack is a denial-of-service attack in which the actual target is not the DNS server itself, but a third party. The fact that a DNS server sometimes sends back very long responses to short requests is exploited. A fake sender address sends them to the victim's IP address. An attacker can use this to substantially increase the data flow coming from him and thus disrupt the Internet access of his target.
DNS spoofing
With DNS spoofing , a requesting client receives an incorrect IP address as a response in order to lead it to a false or fake website (e.g. for the purpose of Internet censorship or phishing ).
Cache poisoning
With cache poisoning , a requesting client is sent manipulated data in addition to the correct response, which the latter takes over in its cache and later used, possibly unchecked.
Open DNS server
Anyone who operates an authoritative DNS server for their own domains must of course be open to requests from any IP address. In order to prevent Internet users from using this server as a general name server (e.g. for attacks on root servers), BIND allows the responses to be restricted to one's own domains. For example, the option causes allow-recursion {127.0.0.1; 172.16.1.4;};recursive queries, i.e. H. Queries to other domains, exclusively for the local host (localhost) as well as 172.16.1.4 are answered. All other IP addresses only receive an answer to inquiries about their own domains.
An open DNS server can also be a trap if it returns fake IP addresses, see Pharming .
Security enhancements
More than ten years after the original specification, security functions were added to DNS. The following procedures are available:
TSIG
TSIG (Transaction Signatures) is a simple procedure based on symmetric keys with which the data traffic between DNS servers and updates from clients can be secured.
DNSSEC
With DNSSEC (DNS Security) use is made of an asymmetric cryptosystem . In addition to server-server communication, client-server communication can also be secured. This is supposed to make it difficult to manipulate the answers.
DNS over TLS (DoT)
With DNS over TLS , DDoS attacks, the manipulation of responses and spying on the data sent are to be prevented. For this purpose, the DNS queries are secured using Transport Layer Security (TLS).
DNS over HTTPS (DoH)
DNS over HTTPS fundamentally changes the DNS system. Inquiries are made here at the application level. Applications such as the web browser query the DNS server directly instead of forwarding the query to the operating system. As a result, DNS requests look like normal Internet traffic and cannot be specifically intercepted or blocked.
Cloudflare and Google offer public DoH web servers. Mozilla Firefox has supported DoH as an experimental function since version 60. Mozilla, in cooperation with Cloudflare, provides a DoH server that must meet strict privacy requirements.
Domain registration
In order to make DNS names known on the Internet, the owner must register the domain that contains this name. Registration ensures that certain formal rules are adhered to and that domain names are unique worldwide. Domain registrations are carried out by organizations (registries, e.g. Verisign or Afilias) that have been authorized by IANA or ICANN . Registrations are (with a few exceptions) fee-based. DENIC is responsible for domains under .de . In the vast majority of cases, domains can only be registered with the registries via intermediaries, so-called registrars such as Godaddy or 1 & 1 Internet SE, who have concluded corresponding contracts with the registries.
Bonjour or Zeroconf
When developing macOS, Apple made several extensions to the DNS, which should enable the comprehensive self-configuration of services in LANs. On the one hand, Multicast DNS ("mDNS") was introduced, which allows name resolutions in a LAN without a dedicated name server. In addition, DNS-SD (for “DNS Service Discovery”) was introduced, which enables the search (“browsing”) for network services in the DNS or mDNS. So far, mDNS and DNS-SD are not official RFCs of the IETF , but are still available in various (also free) implementations. Together with a number of other technologies, Apple combines DNS-SD and mDNS under the name “ Zeroconf ”, as part of OS X also as “Rendezvous” or “ Bonjour ”. Most Linux distributions support this extension e.g. B. with the avahi implementation of Zeroconf.
Censorship and Alternate DNS
Since the debates about the blocking of Internet content in Germany and censorship on the Internet in general, there have been a number of alternative DNS providers who say they do not censor domains. Examples are Open Root Server Network , Cesidian ROOT , OpenNIC and projects from German associations such as the Chaos Computer Club , digitalcourage and the German Privacy Foundation , as well as commercial providers such as OpenDNS .
Namecoin
Namecoin is the first fork of Bitcoin from 2011 and is used as a cryptocurrency and as a key value store for domain names and identities. As an alternative, distributed Domain Name System (DNS) outside the ICANN namespace, transactions for registering, updating and transferring domains are recorded on the blockchain . A browser plug-in or a local Namecoin DNS server is required to resolve the .bit addresses. Just like Bitcoin, Namecoin is a decentralized peer-to-peer system that is not subject to censorship. The software is open source and is hosted on GitHub .
According to a Trend Micro report, .bit domains have also been used increasingly by cyber criminals since 2013 . Mainly for this reason, the OpenNIC project stopped its DNS resolution of .bit domains in summer 2019.
Name server software
Selection of well-known software for name resolution.
- BIND (Berkeley Internet Name Domain) is the most widely used name server software and is the reference implementation of most RFCs for DNS. The first version of BIND was the first publicly available name server implementation.
- At djbdns , the author Daniel J. Bernstein has advertised a bonus for finding security problems. Bernstein no longer develops Djbdns because he sees it as finished.
- Dnsmasq is a name server and DHCP server with limited functionality. The names from the local network are resolved according to / etc / hosts. Dnsmasq does not have a full resolver: unknown name requests are forwarded and cached.
- Knot DNS is an authoritative name server developed by CZ.NIC , the operator of .cz .
- Microsoft Windows DNS is one of the few commercial name server implementations as part of the Microsoft Windows Server line of products . The name server supports dynamic updates, zone transfers and notification. Zone data can be saved and replicated in the current versions in the Active Directory or in zone files.
- Name Server Daemon is an authoritative name server that was developed for use as a top-level domain and root name server . NSD statically precompiles responses to optimize server performance. Dynamic zone content or round robin are not supported.
- PowerDNS is a name server that can read zones from SQL databases, LDAP directories and other backends. PowerDNS began as a commercial implementation and has been licensed under the GPL since 2002 .
- Unbound is a DNS resolver that supports DNSSEC validation and caching. Unbound can be integrated into applications as a software library.
Web links
- RFCs
- Multicast DNS
- Functionality and management of the DNS as a poster
- Contributions from the Chaos Computer Club
- DNS server censorship: DNS Howto
- Podcast on DNS: Chaosradio Express 099 - Domain Name System
Individual evidence
- ↑ RFC 7766 - DNS Transport over TCP - Implementation Requirements. Internet Engineering Task Force (IETF), p. 3 (Status: March 2010) “ This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. [...] It should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) will probably result in resolution failure and / or application-level timeouts. ”
- ↑ a b RFC 6724 - Default Address Selection for Internet Protocol Version 6 (IPv6). Network Working Group of the IETF, p. 7 (September 2012) “ Another effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available. ”
- ↑ a b c Carsten Strotmann, Jürgen Schmidt: DNS with privacy and security before the breakthrough. Retrieved July 25, 2018 .
- ↑ Patrick McManus: Improving DNS Privacy in Firefox. Retrieved July 26, 2018 .
- ↑ Christian Sickendieck: OpenDNS and other free DNS servers. April 17, 2009, accessed March 13, 2017 .
- ↑ Kevin Helms: How to Obtain and Use .Bit Privacy Domains. In: Bitcoin News. March 7, 2017, accessed March 19, 2020 .
- ^ Namecoin. Accessed March 6, 2020 (English, project website).
- ↑ .bit - The next Generation of Bulletproof Hosting. In: abuse.ch. September 25, 2017, accessed March 19, 2020 .
- ↑ Catalin Cimpanu: OpenNIC drops support for .bit domain names after rampant malware abuse. In: ZDNet. July 17, 2019, accessed March 19, 2020 .