FAQs on DNSSEC

Frequently Asked Questions

What can we do for you?

Information on DNSSEC

Kann ich meine von DENICdirect verwaltete Domain mit DNSSEC signieren lassen?

Unser Service DENICdirect bietet aktuell nicht die Möglichkeit, Schlüsselmaterial für Domains mit Nameserver-Einträgen zu hinterlegen. Domains mit "nsentry"-Einträgen werden, da die entsprechenden Records direkt in der .de-Zone vorliegen und dort autoritativ sind, automatisch von DNSSEC erfasst und mit entsprechenden, von DENIC erzeugten Signaturen versehen.

Weitere Informationen finden Sie unter https://www.denic.de/domains/de-domains/registrierung/nameserver-und-nsentry-eintraege/.

Wie erkenne ich, ob eine Domain durch DNSSEC-Signierung geschützt ist?

Wenn Sie selbst einen validierenden Resolver betreiben, sind Sie selbst grundsätzlich in der Lage, Signaturen für DNSSEC-Domains zu validieren. Die Details dazu sind Resolver-spezifisch.

Alternativ setzt Ihr Internet Service Provider einen validierenden Resolver ein. In diesem Falle wird dieser Resolver als gefälscht erkannte Daten unterdrücken können und gar nicht erst an Sie weiterleiten. Da ein validierender Resolver auch Daten von nicht-signierten Domains weiterleitet, ist für den Nutzer nicht erkennbar, ob die Daten von einer signierten oder einer nicht-signierten Domain stammen.  

Wie finde ich einen Provider, der DNSSEC unterstützt?

Setzen Sie sich bitte direkt mit Ihrem Domain-Provider in Verbindung um herauszufinden, ob er DNSSEC unterstützt.

Was passiert mit „nsentry“-Domains?

„nsentry"-Domains werden, da die entsprechenden Records direkt in der .de-Zone vorliegen und dort autoritativ sind, automatisch von DNSSEC erfasst und mit entsprechenden, von DENIC erzeugten Signaturen versehen.

Mit welchen technischen Parametern wird DNSSEC für die .de-Zone eingesetzt?

Neben dem 2048bit "Key Signing Key" kommt ein 1024bit "Zone Signing Key" zum Einsatz, der nach jeweils fünf Wochen mit dem sog. Pre-Publish-Verfahren gewechselt wird. Beide Schlüssel erzeugen Signaturen nach dem standardisierten RSA/SHA256-Verfahren, in Übereinstimmung mit RFC 5702.

Die KSK-Signaturen haben eine 3-wöchige Gültigkeit, die ZSK-Signaturen allerdings nur eine 1-wöchige Gültigkeit. Die Signierung der .de-Zone erfolgt mit Opt-Out unter Verwendung von NSEC3-Records nach RFC 5155.

Was ändert sich durch DNSSEC für mich als Domaininhaber?

Jeder Domaininhaber hat die Möglichkeit, seine Domain durch eine DNSSEC-Signierung zu schützen. Durch die Signierung ist für den Nutzer der Webseite erkennbar, ob die übertragenen Daten tatsächlich den ursprünglich eingepflegten Daten entsprechen.

Die Signierung einer Domain kann über den Internet Service Provider erfolgen oder durch den Domaininhaber selbst. Im Falle der Signierung durch den Provider – Voraussetzung ist, er unterstützt DNSSEC – ist dieser für die Schlüsselerzeugung, Signierung der Zonendaten, Neusignierung vor Ablauf der Signaturgültigkeit sowie den gelegentlich notwendigen Schlüsselwechsel zuständig.

Erfolgt die Signierung durch den Domaininhaber, weil er gleichzeitig die dafür notwendigen Nameserver betreibt, erhält der Provider den öffentlichen Schlüssel des Inhabers, um ihn an die passende Registrierungsstelle (im Falle von .de-Domains an die DENIC eG) weiterzugeben. Bei dieser Variante kennt nur der Domaininhaber den privaten Schlüssel.

Was ändert sich durch DNSSEC für mich als Internetnutzer?

Um von DNSSEC zu profitieren, benötigt man einen validierenden Resolver, der die durch DNSSEC gelieferte Zusatzinformation auswerten kann.

Sofern Sie nicht selbst einen validierenden Resolver betreiben, profitieren Sie daher nur, wenn Ihr Internet Service Provider dies für Sie tut. Beim Aufruf von z.B. Webseiten leitet das auf dem Rechner installierte Betriebssystem automatisch die DNS-Anfragen an die vom jeweiligen Internet Service Provider festgelegten DNS-Server. Damit findet die Überprüfung der signierten DNS-Daten direkt auf dessen Server statt. Nur dann können Manipulationen erkannt und die gefälschten Daten unterdrückt werden.

Was passiert mit einer DNSSEC-signierten Domain, wenn sie in den TRANSIT gegeben wird?

Gibt ein DENIC-Mitglied die Verwaltung einer Domain auf und gibt die Domain in den TRANSIT, wird DENIC eventuell vorhandenes Schlüsselmaterial aus der Registrierungsdatenbank entfernen.

Ohne verwaltendes Mitglied können Änderungen zu den Domaindaten, inkl. Änderungen des Schlüsselmaterials, nicht an DENIC übertragen werden. Damit sind die Voraussetzungen für eine Schlüsselverwaltung nicht mehr gegeben. Zur Vermeidung von Validierungsfehlern wird der DS-Record gestrichen, und die Zone ist damit als unsigniert markiert.

Welchen Schutz bietet DNSSEC?

Für Internetnutzer ist es wichtig, darauf vertrauen zu können, dass z. B. die angezeigte Webseite auch tatsächlich derjenigen entspricht, die er aufrufen wollte (eingegeben Domain).

Dazu ist es notwendig, den Pfad von der Anfrage (Eingabe der Domain) bis zur Antwort (Anzeige der Webseite) abzusichern. Einen Beitrag dazu leistet DNSSEC (Domain Name Security Extensions). Es bietet eine Quellenauthentisierung für das Domain Name System (DNS), das heißt, es sichert den Pfad zwischen DNS-Servern und validierenden DNS-Klienten. Anhand der verwendeten Signatur lässt sich die Echtheit prüfen, d.h. ob die Daten aus der autoritativen Zone stammen. Gleichzeitig schützt die Integritätssicherung davor, dass die DNS-Daten auf dem Transportweg verfälscht werden.

Ob die ursprünglich eingepflegten Daten einer Webseite inhaltlich korrekt oder harmlos sind oder ob die aufgerufene Webseite eine Fälschung ist, die z.B. über einen in einer E-Mail enthaltenen Link erreicht wird (so genanntes Phishing), kann mit DNSSEC nicht erkannt werden. Auch Domain-Hijacking oder Eingriffe in Registrierungsprozesse lassen sich damit nicht feststellen.

Was ist DNSSEC?

Domain Name Security Extensions (DNSSEC) sind eine Erweiterung des DNS (Domain Name System), die darauf abzielt, Sicherheitslücken im Internet – wie Cache-Poisoning, DNS-Umleitungen und DNS-Spoofing – zu schließen.

Im herkömmlichen DNS geht eine Anwendung davon aus, dass die Antwort auf eine DNS-Anfrage unversehrt ist und von der richtigen Quelle stammt. Dieses Vertrauen ist nicht immer berechtigt, denn in der Vergangenheit hat es vereinzelt Fälle gegeben, bei denen gezielt Fehlinformationen in DNS-Caches eingebracht wurde (sog. Cache-Poisoning). Dieser Angriff ist als potenzielles Risiko bereits in den neunziger Jahren erkannt und später in RFC 3833 dokumentiert worden. Die Internet Engineering Task Force (IETF) hat auf diese – zunächst theoretische – Bedrohung reagiert und schließlich im März 2005 die drei RFCs RFC 4033RFC 4034 und RFC 4035 veröffentlicht. Diese Trilogie ist auch unter dem Namen "DNSSECbis" bekannt. Eine wichtige spätere Ergänzung ist das sog. NSEC3 (RFC 5155), mit dem die unerwünschte Aufzählung des Zoneninhaltes - etwa aller registrierten .de-Domains – verhindert werden kann.

Wie funktioniert DNSSEC?

Mittels DNSSEC (Domain Name Security Extensions) werden Daten anhand von kryptografisch gesicherten Signaturen geprüft. Diese werden über die zu schützenden Daten errechnet und zusammen mit den Daten an den Client übertragen.

Die Prüfung der Daten erfolgt im Client oder in dem davor liegenden Resolver gegenüber den zur jeweiligen Zone passenden öffentlichen Schlüsseln. Diese Schlüssel können am einfachsten im Domain Name System (DNS) hinterlegt und abgerufen werden. Dabei ist kein Bruch des Sicherheitsmechanismus möglich, da auch der Transfer der Schlüssel mit Hilfe von DNSSEC abgesichert erfolgt. Lediglich der für den Beginn der Kette notwendige Schlüssel (der Key der Root-Zone) wird im Client fest hinterlegt oder per Konfiguration eingepflegt.

What will change for me, the domain holder, due to DNSSEC?

Every domain holder has the possibility to protect their domain by a DNSSEC signature. The signature enables the user of the website to see if the transferred data actually is identical with the originally entered data.

A domain can be signed either by the Internet service provider or by the domain holder themselves. If the provider assumes responsibility for signing the domain – provided the provider supports DNSSEC – the provider also is responsible for generating the keys, signing the zone data, carrying out re-signing before signature validity expires, and for changing the keys at the required intervals.

If the domain holder carries out the signing because they are operating name servers that meet the obligatory requirements, the provider will obtain the public key of the holder in order to pass it on to the responsible registry (for .de domains this is DENIC). If this variant is used, only the domain holder will know the private key.

Which technical parameters are used for DNSSEC in the .de zone?

In addition to the 2048bit Key Signing Key, a 1024bit Zone Signing Key will be used, which will be rolled over every five weeks by the so-called pre-publish procedure. Both keys generate signatures in accordance with the standardized RSA/SHA256 procedure as specified in RFC5702. Validity of the KSK signatures is three weeks, ZSK signatures, in contrast, are valid for one week only. The .de zone is signed with opt-out, using NSEC3 records according to RFC5155.

What happens to "nsentry" domains?

quot;nsentry" domains - their records being stored and being authoritative directly in the .de zone - will be recorded automatically by DNSSEC and provided with the corresponding signatures generated by DENIC.

How do I recognize if a domain is protected by a DNSSEC signature?

If you operate a validating resolver yourself, you are principally able to validate signatures for DNSSEC domains. The details depend on the resolver.

Alternatively, your ISP operates a validating resolver for you. In that case, this resolver will be able to suppress data it has identified as manipulated and will not transfer such data to you at all. It will however not be possible for you to see whether the data originates from a signed or non-signed domain.

How do I find a provider who supports DNSSEC?

Please contact your domain provider directly to find out if they support DNSSEC.

Which type of protection does DNSSEC provide?

For Internet users it is essential that they can rely on the integrity of the information they have called on. It must be guaranteed, for instance, that the contents of a website they see on their screen is identical with the data of the website they wanted to access. To achieve this, the path from the query sent to a website up to the response received must be secured. Domain Name Security Extensions (DNSSEC) render a contribution to this security. They authenticate the origin of data for the Domain Name System (DNS), i.e. they secure the path between the DNS servers and the validating DNS clients. The signature applied reveals if the data is authentic, i.e. if it originates from the authoritative zone. At the same time, securing data integrity protects against DNS data that was manipulated on the way.

However, DNSSEC does not warrant the correctness of the initially stored data of a website nor does it prove that the data is harmless. Neither will DNSSEC recognize if a website you call on, and which you have possibly accessed via a link received in an e-mail, is forged (so-called phishing), nor is it able to protect against domain hijacking or manipulations during the registration process.

What happens to a DNSSEC-signed domain when it is placed in TRANSIT?

If a DENIC member stops to administer a domain and places the domain in TRANSIT, DENIC will remove from the registration database any key material possibly existing for the domain. No DENIC member being responsible for the administration of the domain, there is nobody who can transmit domain data changes, including changes to the keys, to DENIC. Thus, the conditions required for key administration are no longer met. To avoid validation errors, the DS record is deleted and thus flagged as unsigned in the zone.

What about DNSSEC and my domains administered by DENICdirect? Can they be signed with DNSSEC?

At present, our DENICdirect service does not provide for a possibility to store key material for domains with name server entries. Domains with "nsentry" records - their records being stored and being authoritative directly in the .de zone - will be recorded automatically by DNSSEC and provided with the corresponding signatures generated by DENIC.

Additional information can be found at https://www.denic.de/en/domains/de-domains/registration/nameserver-and-nsentry-data/.

What will change for me, the Internet user, due to DNSSEC?

To be able to benefit from DNSSEC you need a validating resolver that is capable to interpret the additional information supplied by DNSSEC.

If you do not operate a validating resolver yourself, you will only benefit if your Internet service provider operates such a resolver for you. When you call a website, for example, the operating system installed on the computer automatically transfers the DNS query to the DNS server defined by the respective Internet service provider. This way, the signed DNS data is verified on the provider's server and manipulations can be identified and forged data be supressed.

How does DNSSEC work?

Domain Name Security Extensions (DNSSEC) are used to verify data by means of cryptographically secured signatures. These signatures are computed from the data to be protected and are transferred to the client together with the data. Data verification is executed in the client or in the upstream resolver and includes the check against the public keys valid for the respective zone. The easiest solution for these keys, in turn, is to store and call on them in the Domain Name System (DNS). This procedure ensures that the security mechanism cannot be interrupted, since even the key transfer is secured by DNSSEC; only the key required to start the security chain (i.e. the key of the root zone) is permanently stored in the client or incorporated through configuration.

What does DNSSEC mean?

Domain Name Security Extensions (DNSSEC) are extensions of the DNS (Domain Name System) which have the purpose to close security holes in the Internet, such as cache poisoning, DNS redirection and DNS spoofing.

In the conventional DNS an application expects the answer to a DNS query to be intact and to originate from the right source. However, you cannot always be confident about that. In the past, there have been rare cases when non-authentic data were deliberately introduced in DNS caches (the so-called cache poisoning). Already in the nineties this attack was identified as a potential threat and documented later in the RFC 3833. The Internet Engineering Task Force (IETF) reacted to this - initially theoretical - threat and finally published the three RFCs RFC 4033RFC 4034 and RFC4035 .in March 2005. This RFC trilogy is also known as "DNSSECbis". Later, the so-called NSEC3 (RFC 5155), was added as an important supplement. NSEC3 helps to avoid unwanted listing of the zone content (such as all registered DE domains).