Root name server
Root name server (abbreviated root servers ) are server for name resolution to the root ( root ) of the domain name system on the Internet. The root zone comprises the names and IP addresses of the name servers of all top-level domains (TLD).
Practically every computer connected to the Internet is assigned a name server that can translate names such as “de.wikipedia.org” into technical numbers (IP addresses). If the name server has no information about the requested TLD (in this case "org"), it turns to the root server. The name servers responsible for "org" are queried there. In the case of the org name servers, the name servers responsible for “wikipedia.org” are queried and finally the IP address of “de.wikipedia.org”. So that the name server does not have to go through this chain every time, it saves the answers for a certain time.
Root servers are operated by various institutions. The Internet Corporation for Assigned Names and Numbers (ICANN) coordinates the operation.
Root server
There are 13 root name servers, which are consecutively named according to the scheme <letter> .root-servers.net . Each root name server can be reached under an IPv4 address and an IPv6 address. All root name servers use anycast to distribute the load so that the 13 addresses are actually served by several hundred servers in different parts of the world.
Letter | old name | IPv4 address | IPv6 address | operator |
---|---|---|---|---|
A. | ns.internic.net | 198.41.0.4 | 2001: 503: ba3e :: 2: 30 | VeriSign |
B. | ns1.isi.edu | 199.9.14.201 | 2001: 500: 200 :: b | USC - ISI |
C. | c.psi.net | 192.33.4.12 | 2001: 500: 2 :: c | Cogent Communications |
D. | terp.umd.edu | 199.7.91.13 | 2001: 500: 2d :: d | University of Maryland |
E. | ns.nasa.gov | 192.203.230.10 | 2001: 500: a8 :: e | NASA |
F. | ns.isc.org | 192.5.5.241 | 2001: 500: 2f :: f | ISC |
G | ns.nic.ddn.mil | 192.112.36.4 | 2001: 500: 12 :: d0d | US DoD NIC |
H | aos.arl.army.mil | 198.97.190.53 | 2001: 500: 1 :: 53 | US Army Research Lab |
I. | nic.nordu.net | 192.36.148.17 | 2001: 7fe :: 53 | Netnod |
J | - | 192.58.128.30 | 2001: 503: c27 :: 2:30 | VeriSign |
K | - | 193.0.14.129 | 2001: 7fd :: 1 | RIPE NCC |
L. | - | 199.7.83.42 | 2001: 500: 9f :: 42 | ICANN |
M. | - | 202.12.27.33 | 2001: dc3 :: 35 | WIDE Project |
At sight
Historically, the supervision of the administration of the root zone and other IANA tasks lay with the US government. The telecommunications authority NTIA , which is subordinate to the US Department of Commerce , commissioned ICANN with the IANA tasks. Critics viewed the US government's say as problematic. In addition to the contractual commitment, it was also criticized that ICANN, as a Californian organization, is exposed to the risk of political influence.
ICANN has been responsible since 2016, as NTIA has waived its supervisory role. ICANN handed over the IANA tasks to its newly founded subsidiary Public Technical Identifiers (PTI) in order to separate technical and strategic functions organizationally.
Change requests to the root zone are first received by the PTI, checked for technical and formal correctness and then forwarded to Verisign . Verisign makes the change, signs the changed root zone with DNSSEC and distributes the new zone file to the root server operators via dedicated distribution servers. Until 2002, the distribution was done directly via zone transfers from the A root server, which was abandoned for security reasons.
Resilience and attacks
The root servers process a very large number of requests, a large number of which are caused by faulty software or network configuration. There is no filtering at the DNS level because, due to the simplicity of a DNS request, this would use more resources than answering all requests.
According to RFC 2870 , every root server must be able to deal with the three-fold peak of the most heavily loaded root server. This means that a root server may only use a third of its capacity in normal operation. If two thirds of the root servers fail, the third that is still operational should be able to answer the queries.
The attack with the greatest impact on the root servers took place on October 21, 2002. A DDoS took place for 75 minutes at a total of 900 Mbit / s (1.8 Mpkts / s) on all 13 root servers. All root servers remained operational, since the upstream firewalls rejected the attack traffic, but around nine root servers were difficult or impossible to reach due to the flooded lines. Root server lookups were significantly delayed as a result, but the caching resulted in hardly any interference with users. Triggered by the DDoS attack, the implementation of anycast was accelerated.
Another attack took place on February 15, 2006, a few days after the name servers of a top-level domain not mentioned by ICANN were attacked. This DDoS attack was carried out as a DNS amplification attack , which multiplied the volume of data that was generated. Two of the only three attacked root servers were unavailable for 15 minutes.
On February 6, 2007, another DDoS attack took place on the root server and at the same time on some TLD name servers. Two root servers could not be reached.
Alternative DNS roots
In addition to the ICANN root servers, there are alternative root server networks that have arisen for political or commercial reasons. As a rule, the providers aim to be autonomous from the established root server network. Occasionally domains are sold below their own top-level domains. These TLDs are only accessible to users of the respective provider, as they are not available in the ICANN root zone. With the introduction of new top-level domains, there is a risk of collisions for users of alternative root servers.
Active providers:
- OpenNIC is a DNS root that, according to its own statement, is operated by volunteers with no commercial interests. In addition to ICANN's top-level domains, OpenNIC is also eliminating some of its own TLDs.
- Yeti DNS is an open testbed for carrying out technical experiments on a DNS root.
Former providers:
- The Open Root Server Network (ORSN) existed until 2019 in order to reduce the influence of ICANN on the Domain Name System.
- Public-Root was a provider that saw itself as an independent non-profit alternative. The website has not been maintained since 2011 and the DNS servers are out of order.
- Cesidian ROOT
- Open Root Server Confederation
- Enhanced Domain Name Service (eDNS) offered the additional top-level domains .biz, .corp, .fam, .k12, .npo, .per and .web until it was decommissioned in 1998.
from history
Historically, the number of servers was limited to 13:
- The maximum size ( MTU ) of a data packet that can reliably pass the Internet was assumed conservatively (gross 576 bytes, minus administrative data).
- Since connectionless UDP is the preferred transport protocol for DNS queries for performance reasons, the response only had to be accommodated in one packet.
- The maximum size of a DNS response was set to 512 bytes so that information could be transmitted via a maximum of 13 servers.
- Current software can handle larger DNS data packets.
Before anycast was used, 10 of the 13 root servers were in the United States . This was criticized with regard to the reliability, since a geographical centering runs counter to the decentralization idea of the Internet.
Web links
- root-servers.org
- iana.org - Root Zone Management
- Internet in Germany gets its own DNS root server . heise online
- The Internet Domain Name System Explained for Non-Experts by Daniel Karrenberg . (English)
Individual evidence
- ↑ root-servers.org . Root Server Technical Operations Assn. Retrieved October 9, 2016.
- ^ ICANN Strategy Committee . ICANNWatch
- ^ IANA: Root Zone Change Request Process
- ↑ https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf
- ↑ https://www.gao.gov/assets/680/679691.pdf , page 6
- ↑ News Release. University of California, San Diego, External Relations: News & Information
- ↑ icann.org (PDF)
- ↑ Major attack on DNS root server . hot networks
- ↑ RFC 8483
- ↑ https://yeti-dns.org/documents.html
- ↑ dns extension mechanism for enum (English)
- ↑ RFC 3226 - DNSSEC, IPv6 requirements (English)