Domain Name System

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 respond to requests for name resolution.

The DNS works like a telephone information. The user knows the domain ( the noticeable for humans name of a computer on the Internet) - example.org for example. This it sends a request to the Internet. The URL is then converted there by the DNS into the corresponding IP address (the " Port Number" on the Internet) - for example, an IPv4 address of the form 192.0.2.42 or an IPv6 address as 2001: db8: 85a3: 8D3: 1319: 8a2e: 370:7347, and thus leads to the correct computer.

  • 4.1 Example of name resolution
  • 4.2 Example of Reverse Lookup
  • 5.1 Dynamic DNS
  • 5.2 internationalization
  • 5.3 Extended DNS
  • 5.4 Management of phone numbers
  • 5.5 RFID support
  • 5.6 anti-spam
  • 5.7 Miscellaneous
  • 8.1 forms of attack 8.1.1 DDOS attack on nameservers
  • 8.1.2 DNS Amplification Attack
  • 8.1.3 DNS spoofing
  • 8.1.4 Cache Poisoning
  • 8.1.5 Open DNS server

Overview

The DNS is a world on thousands of servers distributed hierarchical directory service that manages the name space of the Internet. This name space is divided into so-called zones, are responsible for each independent administrators. For local requirements - such as within a company network - it is also possible, independent from the Internet DNS to operate.

Mainly the DNS is designed to convert domain names into IP addresses ( "forward lookup" ) used. This is similar to a telephone directory, which resolves the names of the participants in their phone number. The DNS offers thus a simplification, because people can remember names much better than columns of numbers. So you can buy a domain name as example.org usually easier to remember than the associated IP address 192.0.32.10. This point becomes increasingly important with the introduction of IPv6 even more important, because then a name are each assigned IPv4 and IPv6 addresses. This is the solution for example the name www.kame.net in the IPv4 address and the IPv6 address 203 178 141 194 2001:200:0:8002:203:47 ff: fea5: 3085 on.

Another advantage is that IP addresses - can be changed relatively risk - such as web servers. As Internet users, only claim the (unchanged) DNS name, they change the child IP level remain largely hidden. As a name of several IP addresses can be assigned to a simple load balancing by DNS ( load balancing) can even be realized.

With the DNS, a reverse resolution of IP addresses to names ( "reverse lookup" ) is possible. In analogy to the phone book, this corresponds to a search for the name of a party to a known number, which is known within the telecommunications industry under the name inverse search.

The DNS was designed in 1983 by Paul Mockapetris and described in RFC 882 and RFC 883 ( RFC Request for Comments ). Both have now been superseded by RFC 1034 and RFC 1035 and supplemented by numerous other standards. Original task was to replace the local hosts files that were responsible for name resolution up to then and the enormous increase in the number of new entries were no longer grown. Due to the proven reliability and flexibility were (see below: Enhancement of DNA) gradually integrated more data sets in the DNS, and so made ​​available to Internet users.

DNS is characterized by:

  • Decentralized management,
  • Hierarchical structure of the namespace in tree form,
  • Uniqueness of names,
  • Extensibility.

Components

Domain name space

The domain name space has a tree-like structure. The leaves and nodes of the tree are referred to as labels. A complete domain name of an object consists of the concatenation of all labels of a path.

Labels are strings that are each at least one character and a maximum of 63 characters (RFC 2181, section " 11 name syntax" ). Individual labels are separated by dots. A domain name is terminated with a period ( the last point is usually omitted, belongs purely formal but to a full domain name to it ). Thus is a correct, complete domain name (also Fully Qualified Domain Name ( FQDN) called ), for example, www.example.com. and can not be longer than 255 characters, including all points.

A domain name is always delegated and resolved from right to left, that is, the farther 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 referred to as a top -level domain (TLD ). The DNS objects of a domain ( for example, the computer name ) to be kept as a set of resource records mostly in a zone file that is present on one or more authoritative name servers. Instead of zone file the more general term zone is mostly used.

Name Server

Most name servers are part of the Domain Name System, which is also used on the Internet.

Name servers are programs on the one hand, the answer based on a DNS database requests to the domain name space, however, are in the language of the computers on which these programs are used, referred to as name servers. A distinction between authoritative and non- authoritative name servers.

An authoritative name server is responsible for a zone. His information about this zone are therefore considered reliable. Exists at least one authoritative server, the primary name server for each zone. This is listed in the SOA resource record to a zone file. Authoritative name servers are almost always implemented as a server cluster for redundancy and load balancing reasons, the zone data are identical to one or more secondary name servers. The synchronization between the primary and secondary name servers per zone transfer.

A non- authoritative name server gets its information about a zone from other name servers as it were from second or third hand. Its information is not considered to be secure. Because DNS data usually change very rarely, save non- authoritative name server from the one of a resolver requested information in local RAM, so that they are available more quickly when a new request. This technique is referred to as a caching. Each of these items has its own expiration date (TTL time to live ), after which the entry is deleted from the cache. The TTL is determined by two one authoritative name server for this entry and after the change in probability of entry is determined ( frequently changing DNS data obtained a low TTL). Under certain circumstances also mean that the name server can provide false information at this time, if the data has changed in the meantime.

A special case is the Caching Only Name Server. In this case, the name server for any zone is responsible and must resolve all incoming inquiries about other name servers ( forwarders ). For this, various strategies are available:

In order for a non- authoritative name server can find information about other parts of the name space, he uses the following strategies:

Unlike conceived name resolution by server, 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 constructed software modules that are installed on the computer of a DNS participant and can retrieve the information from name servers. They form the interface between the application and name server. The resolver handles the request an application, she adds, if necessary, to a FQDN and send it to a normally dedicated name server. A resolver works either recursive or iterative.

In recursive mode, the resolver sends a recursive query to its associated name server. Did this not the desired information in our own database, so contact the name server other server, and that until he either a positive response or until it receives a negative response from an authoritative server. Recursive resolver working so leave the work to complete dissolution their name servers.

In an iterative query, the resolver either receives the desired resource record or a reference to other name servers it asks next. The resolver lurches as nameserver to name server until it receives from an authoritative answer.

The response obtained in this way passes the resolver to the program that has requested the data, for example, to the web browser. Usual resolver clients only work recursively, they are then referred to as a stub resolver. Name servers usually have their own resolver. These usually work iteratively.

Known programs to verify the name resolution are nslookup, host and dig.

Protocol

DNS requests are usually sent via UDP port 53 for name servers. However, the DNS standard also support TCP for questions that can be answered are too large for UDP transmission. If no Extended DNS is used ( EDNS ), the maximum permissible length of DNS UDP packet of 512 bytes. Extra-long responses are therefore transmitted truncated. By setting the Truncated flags of the requesting client is aware of this fact. He must then decide whether it forwards the answer or not. If necessary, he will repeat the request via TCP Port 53.

Zone transfers are always carried out via port 53 TCP. The trigger zone transfers are but usually via UDP.

Structure of the DNS database

The Domain Name System can be thought of as a distributed database with a tree-like structure. In the Internet DNS, the data are on a variety of servers scattered around the world, to each other via references - are linked - known in DNS terminology delegations.

Each local name server exist one or more files - the so-called zone files - containing all the relevant data. These files are lists of resource records. Of great importance are seven types of Record:

  • With the SOA resource record are parameters of the zone, such as validity or serial number specified.
  • With the NS resource record links ( delegations ) between servers can be realized.
  • With the following record types the actual data are defined: An A resource record has a name to an IPv4 address.
  • A AAAA resource record has a name to an IPv6 address.
  • A CNAME resource record points from one name to another name.
  • An MX resource record has a name to a mail server. It represents a special feature, since it refers to a specific service in the Internet, namely the e-mail notification via SMTP. All other services use CNAME, A and AAAA resource records for name resolution.
  • A PTR resource record points to an IP address to a name (reverse lookup), and is used both for IPv4 and IPv6, only IPv4 below the domain "IN- ADDR.ARPA. " And for IPv6 under " IP6.ARPA. ".

Over time, new types have been defined, with which extensions of the DNA were carried out. This process is not yet complete. A comprehensive list can be found under the resource record.

Examples:

Resolution of DNS requests

For name resolution

In the following, annotated example, the IPv4 address for the name " www.heise.de. " Determined using the resolver tools dig. " Trace" means that the individual responses to iterative requests to the name server hierarchy are specified, " additional " ensures that is also shown that the name servers for delegation not only NS resource records manage, but in some cases their IP know addresses in the form of A or AAAA resource records and deliver with " -t A" finally asks for the A resource record, which is the IPv4 address. It turns out that four successive name servers need to be interviewed to get to 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:7 fd :: 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 requesting computer, which points to the root name servers, the TLD zone ( zone ... contains the nameservers for. Org,. De, . Com) manage and all via IPv4 can be further questioned, some additionally using IPv6. The root name servers manage the root of the name resolution, represented by a point. The IP addresses of the root name server change very rare and must be known to all name servers, if they answer the question Internet requests. ( These IP addresses, for example, in a text file called " Root Hints" are included. )

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 :: 10 2001:608:6:6 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 From the root name servers above 13 was randomly " I.ROOT - SERVERS.NET. " Chosen to give it the question of " www.heise.de. " To make. He answered with six name servers to choose from, which are responsible for the area " de. ". Again, the query using IPv6 is possible for 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 From the six called name servers was accidentally " F.NIC.de. " chosen to learn 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.37 pointing, no help on the same server, because the name is in the zone " heise.de. " Which he self-administered. One speaks in this type of information by glue records (of English. Glue, glue ). If the server " ns2.pop - hannover.net. " Are selected for the next step, so in a separate name resolution its IP address would first determine, 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 these five name servers " ns.pop -hannover.de. " Was accidentally used to answer the question " www.heise.de. ". The answer is 193.99.144.85. So that the request has arrived at the destination. There are also repeating the same name server named as responsible for " heise.de. ", Ie without referring to other name servers.

Example Reverse Lookup

For the reverse lookup, so finding a name to an IP address, the IP address is first transformed into a formal name in order for it then queries the DNS for a PTR resource record. As the hierarchy of IP addresses specifically from left to right ( see subnet), the DNS but from right to left, you turn on the first step, the order of the integers, and from the IPv4 address 193.99.144.85 is eg the name and from the IPv6 address 2A02 " 85.144.99.193.in - addr.arpa. ": 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. ef3.0.0.e.2.0.2.0.a.2.ip6.arpa. produced ". ( This name is long, because the zeros implied by now must be explicitly called again. )

The PTR resource record for the so -formed IPv4 address can be determined analogously to 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:2 f :: 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:7 fd :: 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 So the answer is " www.heise.de. ". However, it is not necessary that each IP address is assigned a name, nor must return resolution correspond to each other. The resolution begins with the reference to the root name servers and delegations find obvious place at the marked points by boundaries between the numbers. However, one sees in the example, that need not be delegated to any point in a name.

Extensions

Since the DNS has proven to be reliable and flexible, several major enhancements have been introduced over the years. An end to this trend is not foreseeable.

Dynamic DNS

In the classic DNS it is expensive, assign a name to a new IP address. The corresponding zone file must (usually manually ) and changed the name servers to be reloaded. Delays of up to several days are usual. With dynamic DNS changes are possible by sending an update request with low time delay.

The Dynamic DNS is considered a security risk because anyone can edit or delete DNS records without special precautions. In connection with DHCP Dynamic DNS is almost mandatory because a user often new IP addresses are assigned. The DHCP server sends to at every change of address a corresponding message to the name server.

Internationalization

So far, the labels were to alphanumeric characters and the characters - ' restricted. Possible, but not standard, with subdomains is also _ '. This delimiting character set is mainly due to the fact that the DNS (as well as the Internet originally ) was developed in the United States. Thus (for example, the umlauts ä, ö and ü and ß in German speaking countries ) or characters from completely different writing systems (for example, Chinese) were in many countries common characters originally not possible in domain names.

A now well-established approach to increase the character set is introduced in 2003 in RFC 3490 and RFC 2010 updated with 5890 Internationalizing Domain Names ( IDNA ). In order to keep the new system compatible with the previous, the extended character sets with the previously allowable characters are encoded. The extended character sets are first normalized to map uppercase to lowercase, among other things, and then mapped by Punycode on an ASCII -compatible string. IDNA requires adjustment of network applications (eg web browser), the name server infrastructure (servers, resolvers), but need not be changed. In German-speaking countries can be registered and used with umlauts since March 2004 German, Liechtenstein, Austrian and Swiss domains (. De, . Li, . At and. Ch). Even with other top -level domains, particularly in Asia, the use of internationalized domain names is possible.

Extended DNS

1999 Paul Vixie described in RFC 2671 some minor, backward-compatible extensions to the Domain Name System, which are called EDNS version 0. By using a pseudo - Records as header extension of the requestor can set additional options. In particular, he can convey that he can accept UDP responses greater than 512 bytes. DNSSEC -enabled servers and resolvers must master EDNS.

Management of telephone numbers

Another recent extension of the DNS provides ENUM (RFC 2916) dar. This application allows addressing of Internet services through telephone numbers, so the "Select " from the internet accessible devices with the numbering scheme known from the telephone network. From the broad spectrum of possible applications in particular lends itself to the use of Voice over IP Services.

RFID support

The Radio Frequency Identification can stored on special RFID tags IDs - so-called electronic product codes, or EPCs - be read without contact. The DNA can be used to identify an ID to the server, which contains information about the corresponding object. The Object Naming Service ONS converts to the EPC in a DNS name and to ask you for default DNS one or more NAPTR Naming Authority Pointer.

Anti-spam

For filtering of spam many mail servers check the DNS record of the sending mail server routinely using the reverse DNS lookup. This must not only be well forward dissolve properly and the IP address of the sending system show (forward -confirmed reverse DNS ), but must also conform to the specified in the SMTP protocol HELO host name of the sending system.

Using Sender Policy Framework is an attempt to prevent the sending of forged senders by third parties as possible. For each mail domain is explicitly listed on a special SPF resource record, is of which servers and IP networks to reckon with emails sent from this domain. SPF stands, however, due to numerous technical difficulties, such as forwarders in the criticism.

Even the anti -spam mechanism Domain Keys ( DKIM ) relies on entries in the DNS by sending mail servers in DNS TXT Records publish their public key, with the signature of their outgoing e- mails can be verified.

Others

In addition to the IP addresses of DNS name can also ISDN numbers, X.25 addresses, ATM addresses, public keys, text lines, etc. are assigned. In practice, such cases of application, however, are the exception.

DNS on the local network

DNA is not limited to the Internet. It is possible and compatible with the definition readily set up their own zones in the name server for local name resolution and there enter the appropriate addresses. The one-off cost for the installation worthwhile even for relatively small networks, since all addresses in the network can be centrally managed.

For larger companies or organizations from local and Internet DNS existing mixing system (split DNS) is often encountered. The internal users access to the local and external to the Internet DNS. In practice, this may result in very complicated situations.

The DNS server BIND can also cooperate with DHCP and thus allow for each client in the network has a name resolution.

Under Windows, there is another service for name resolution - WINS, which provides a similar function to this, but it uses a different protocol.

DNS server network

It is possible to connect multiple DNS servers. The server designated as the master are responsible for one or more domains. The slaves update after changing the data itself, the master distributes not automated the data. The collection of data is realized via a zone transfer.

For example, operate a Master for their internal DNS a company with multiple locations in a place that supplies the servers in the branch offices. The zone transfer is in BIND on TCP ( by default port 53 ) and recommended legally requires authentication. The slaves update when the serial number for a zone file changes or they will receive a message from the master. The release for the transfer port should be bound to the IP address of the master by firewall. For other software packages, the data are compared under circumstances in other ways, for example by LDAP replication, rsync, or other mechanisms.

Security

The DNS is a central part of a networked IT infrastructure. A malfunction may result in substantial costs and be a corruption of DNS data base of attacks. More than ten years after the original specification has been added to DNS security functions. The following methods are available:

  • For TSIG ( Transaction Signatures ) is a simple system based on symmetric-key method by which the data traffic between DNS servers and updates can be secured from clients.
  • In DNSSEC (DNS Security) use is made of an asymmetric cryptosystem. In addition to the server -server communication, the client-server communications can be secured.

Forms of attack

The main objective of DNS attacks is to draw by manipulating DNS participants to false websites to subsequently obtain passwords, PINs, credit card numbers, etc.. In rare cases, an attempt is made completely turn off the Internet DNS Denial -of- service attacks and paralyze as the Internet. In addition, the DNA can be used to intensify targeted attacks on individuals or companies.

DDOS attack on nameservers

In a distributed denial -of- service attack name servers are overloaded by a high stream of DNS requests so that legitimate requests can not be answered. Against DDOS attacks on DNS servers, there is currently no defense. As a preventive measure may be simply trying to dimension the name server to recognize or install a distributed network with as many servers. In such attacks, botnets and the like are often used.

DNS Amplification Attack

The DNS Amplification Attack is a denial- of-service attack in which not the DNA itself is the real target, but an uninvolved third party. Exploited, that DNS servers in some cases return on short queries very long answers. These will be drawn to the IP address of the victim. An attacker can thus amplify the outgoing data stream from it substantially and so interfere with the Internet access of its attack target.

DNS Spoofing

When DNS spoofing gets a requesting client an incorrect IP address in response to (in order to Internet censorship or phishing for example ) to lead him to a false or fake website.

Cache Poisoning

When cache poisoning a requesting client also be signaled to the correct answer manipulated data, the latter will take over in its cache, and later, possibly unaudited used.

Open DNS server

Anyone who operates an authoritative DNS server for its own domains, of course, must be open to requests from any IP address. To prevent Internet users use this server as the common name of the server ( eg for attacks on root servers ), BIND enables to restrict the answers to their own domains. For example, causes the option allow-recursion { 127.0.0.1; 172.16.1.4 ;}; That recursive queries, ie queries to other domains, exclusively for the local host (localhost ) and 172.16.1.4 will be answered. All other IP addresses get an answer only to inquiries on their own domains.

An open DNS server can also be a trap when he returns fake IP addresses, see pharming.

Spam Protection

In blacklists (also called ' RBL ', short for Realtime Blackhole Lists. ), For example against spammers, DNS is used to query whether a domain name or an IP address is listed: The client sends a DNS request to the rbl server. This responds with '127 .0.0.1 'if the address is not listed, otherwise with '127 .0.0. X ', x > 1 The value of ' x' may contain additional information about the listed address. Since the range is 127.0.0.0 / 8 reserved for localhost, misinterpretations are not possible.

Domain Registration

To make DNS name known on the internet, the owner must have the domain that contains the name, register. By registering, ensure that certain formal rules are adhered to and that domain names are unique worldwide. Domain registrations are made by organizations ( registrars ) that have been authorized to do so by the IANA and ICANN. Registrations are ( with few exceptions ) charges. For domains under. De DENIC is responsible.

Detailed information can be found at domain registration.

Bonjour and Zeroconf

Apple has made ​​several enhancements to the DNS in the development of Mac OS X, which will enable the comprehensive self- configuring services in LANs. For a multicast DNS ( " mDNS " ) was introduced, which allows name resolution on a LAN without a dedicated name server. In addition, even DNS -SD ( for " DNS Service Discovery " ) was introduced, which enables you to search ( " browsing" ) for network services in the DNS or mDNS. mDNS and DNS-SD are so far no official RFCs of the IETF, but are nevertheless already available in various (also free ) implementations. Along with a number of other techniques summarizes Apple DNS-SD and mDNS under the name " Zeroconf " together, as part of Mac OS X, also known as " Rendezvous " or " Bonjour ". Most Linux distributions support this extension, eg with the avahi- implementation of Zeroconf.

Censorship and alternate DNS

Since the debates on closures of Internet content in Germany and censorship on the Internet generally, there are a number of alternative DNS providers do not censor the domains in his own words. Examples are Open Root Server Network, Cesidian ROOT, OpenNIC, projects of German clubs like the Chaos Computer Club, digital and courage of the German Privacy Foundation, as well as commercial providers such as OpenDNS.

Namecoin

Namecoin is an alternative distributed Domain Name System (DNS) on the basis of Bitcoin software. It extended the software in such a way that transactions for registering, updating and transferring domains serve. Just as Bitcoin Namecoin is a peer- to-peer system that can be controlled by assuming an honest majority of participants not by a single country or a company. The software is open source and hosted on GitHub.

Name server software

Selection of known software for name resolution.

  • BIND (Berkeley Internet Name Domain ) is the most widely used name server software and is a reference implementation of most RFCs about DNS. The first version of BIND was the first publicly available name server implementation.
  • In the author Daniel J. Bernstein djbdns has announced a bonus for finding security problems. Djbdns is no longer being developed by Bernstein, because he considered it to have done.
  • Dnsmasq is a name server and DHCP server with limited functionality. The names from the local network according to / etc / hosts resolved. Dnsmasq does not have a full resolver: unknown name requests forwarded and stored in the cache.
  • Knot DNS is an authoritative name server, which is being developed by CZ.NIC, the operator of. Cz.
  • Microsoft Windows DNS is one of the few commercial name server implementation and included in the Microsoft Windows Server product line. The name server supports dynamic updates, zone transfers, and notification. Zone data can be stored and replicated in the current versions in the Active Directory or zone files.
  • NSD ( Name Server Daemon) is an authoritative name server, which is designed for use as a top - level domain and root name servers. NSD compiled responses against static, in order to optimize the server performance. Dynamic zone content or Round Robin are not supported.
  • PowerDNS is a name server zones from SQL databases, LDAP directories, and other back ends can read. PowerDNS began as a commercial implementation and is licensed under the GPL since 2002.
  • Unbound DNS resolver DNSSEC validation and caching is supported. Unbound can be integrated as a software library in applications.
Reverse telephone directory Root-Nameserver Method stub Dig (command) Extension mechanisms for DNS Cache (computing) Umlaut (linguistics) Domain Name System Security Extensions Integrated Services Digital Network Asynchronous Transfer Mode Client (computing) Public-key cryptography Bonjour (software) Avahi (Software) Digitalcourage .cz Integrated Authority File
244514
de