Suche

DNSSEC – Domain Name System Security Extensions

Enhanced Security on the Internet

The Internet and its many applications and communication services are indispensable today, both in business and private life. Internet users generally assume that data transfer on the Internet is reliable and that the data is not forged. The majority of all Internet services and processes relies on data transfer to be effected by the Domain Name System (DNS) through well functioning and accurate mapping of easily understandable domain names to IP addresses. However, the DNS protocol as such, which is used for this purpose, does not provide any content protection. In particular, data are not secured against manipulation during transport or in the servers and caches they pass on their way. Thus, forged data can neither be identified nor avoided.

This is where Domain Name System Security Extensions (DNSSEC) comes into play: DNSSEC are standardised extensions of the DNS protocol that are used for source authentication, i.e. for securing the path between the DNS servers and the validating DNS client, including the intermediate resolvers and their caches. DNSSEC helps to ensure that no other but the IP address stored for a looked-up domain name is returned to the enquirer. For example: If you enter into the browser the domain name of your online-banking portal, DNSSEC can guarantee that the computer establishes a connection to the IP address stored and published by the bank for the legitimate web server of the online-banking portal. DNSSEC renders it impossible for any third party to insert a forged IP address which might be a bogus address of the online-banking portal. Such type of IP address falsification is called cache poisoning, and DNSSEC is an effective protection against it.

However, DNSSEC does not tell anything about the accuracy of the initially provided data: This is to say, DNSSEC is not able to find out whether the originally entered data is correct and/or harmless.

How Does DNSSEC work

DNSSEC adds cryptographically secured signatures to data and thus verifies it. These signatures are computed from the DNS data to be protected and are transferred to the client together with the DNS data. The added signature shows if the data was actually generated by an authoritative source. Additionally, the signature makes it possible to verify if the data was corrupted during transfer.

To be able to generate a digital signature, a key pair consisting of a private and a public key must be created. The private key is confidential, only the key owner knows it. The public key is published in the DNS. It can be used to verify and validate a signature that was signed by the private key. People must have trust in the public key to use this process. To build this trust, a so-called chain of trust based on a specific key hierarchy is applied. It is needed to enable verification of all signatures by one single public key. A zone located as high as possible in the DNS tree contains the public keys of its delegated sub-zones and digitally signs these keys. The sub-zones in turn may contain the signed public keys of the zones subordinated to them etc. If you apply such a chain of trust, the only key the resolver of a central name server needs to know is the public key of the uppermost zone.

DNS Query without DNSSEC

DNS Query with DNSSEC

DNSSEC for .de

As regards the Top Level Domain .de, DNSSEC has been active and is offered as an optional security feature.

To benefit from DNSSEC as an Internet user, one needs a validating resolver. This resolver validates the keys and signatures and suppresses corrupted DNS replies. Validating resolvers may be operated directly on the clients' end systems (PC, laptop etc.). They may also be provided by Internet providers or IT departments. With the spreading of the validating resolvers, the advantages of DNSSEC will become more and more obvious.

If you want to use DNSSEC for your own domain(s), you must sign them and store the public key material with DENIC. Any provider can do that for you via an automated interface. Please contact your provider if you intend to use DNSSEC.

You can change the provider for a DNSSEC-signed domain as easily as for an unsigned domain. The provider change of a DNNSEC-signed domain follows a standardised procedure, which includes clear rules for the name server operator with regard to the Operator Change and the transfer of key management. We have compiled answers to the most important questions for you in our DNSSEC FAQs section.

What is DNSSEC?

DNSSEC is a protocol extension adding data origin authentication to the Domain Name System (DNS). This means that by using public key technology one can ensure that the response of the DNS corresponds precisely to the data the respective zone administrator in charge has entered into the system. DNSSEC addresses above all the risks of the DNS protocol as described in RFC3833. IETF had worked on the development of DNSSEC for more than ten years until it finally published the three RFCs RFC4033, RFC4034 and RFC4035 in March 2005. This trilogy is also known as "DNSSECbis".

A serious problem of DNSSECbis was the so-called "zone walking": This side effect makes it possible to list all zone contents, thus providing not only a key to the registration data but also to all changes that are made to the zone contents. DENIC as well as some other registries - mainly but not only European ones - consider this side effect not compatible with data privacy obligations. The IETF pursues two approaches to solve the problem. In the meantime, both were published as "Proposed Standards". The documents RFC4470 and RFC4471 describe a method how to dynamically generate NSEC records and their signatures. However, since the method requires the DNSSEC keys to be available on all name servers, it is used only in exceptional cases. Thus, no corresponding implementations exist until today. The second solution, NSEC3 (which is described in RFC5155), cleverly disguises data and thus makes the results of potential zone walking worthless and useless. This procedure has been implemented in common name server and resolver implementations. In both cases, DENIC was involved in the development.