Public DENIC mailinglist

[DENIC Presse <presse AT denic.de>]

Sehr geehrte Damen und Herren,

ab heute, Freitag, 20. Mai 2011, werden wir unsere 16 Nameserverstandorte 
nach und nach mit einer signierten .de-Zone versorgen. Dazu setzen wir ein 
Verfahren ein, dass sich für die Rootzone und andere TLDs bereits bewährt 
hat: die "Deliberately Unvalidatable DE Zone".

Dabei handelt es sich um eine mit DNSSEC signierte Zone, die sich 
allerdings bewusst nicht zur Validierung einsetzen lässt. Konkret: die 
Signaturen in den RRSIG-Records werden mit dem richtigen Schlüssel 
erzeugt, dieser wird aber in der Zone durch einen anderen ersetzt:

de.     7200    IN      DNSKEY  257  3  8 (
                        AwEAAYbcAAAAAGw/++++++++++++++++++++
                        ++++++++++++++++++++++++++++++++++++
                        THIS/IS/AN/INVALID/KEY/THAT/WILL/NOT
                        /VALIDATE/++++++++++++++++++++++++++
                        ++++++++++++++++++++++++++++++++++++
                        CONTACT/DNSSEC/AT/DENIC/DOT/DE/FOR/M
                        ORE/INFORMATION/OR/VISIT/THIS/URL+++
                        http+//www+denic+de/dnssec/+++++++++
                        ++++++++++++++++++++++++++++++++++++
                        ++++++++++++++++++++++8=
                        ) ; Key ID = 24220

Muss ich an meinen Clients oder meinem (rekursiven) Nameserver die 
Konfiguration anpassen?
DNSSEC ist eine abwärtskompatible Ergänzung des DNS-Protokolls. Änderungen 
an Nameserver- oder Resolver-Konfigurationen sind derzeit nicht 
erforderlich. Viele Nameserver fragen bereits in der voreingestellten 
Konfiguration die DNSSEC-Informationen ab. Um DNSSEC zur Validierung 
(s.u.) nutzen zu können, muss ein sogenannter "Trust Anchor" konfiguriert 
werden. Dieser Schritt ist jedoch optional. Es besteht derzeit kein Anlass 
zu Konfigurationsanpassungen.

Gibt es wirklich keine Nebenwirkungen?
In der Vergangenheit kam es vereinzelt vor, dass "Middleware", also 
insbesondere Firewalls, NAT-Systeme oder Heimanschlussgeräte (CPE, 
"DSL-Router" etc.) mit den vergrößerten Antworten nicht protokollkonform 
umgehen bis hin zur Unterdrückung dieser Daten. Da DNSSEC aber bereits 
sowohl in der Rootzone als auch in anderen Top Level Domains eingesetzt 
wird, sind die meisten dieser Systeme inzwischen bereinigt. Daher sind 
durch die DNSSEC-Einführung für .de keine neuen Probleme zu erwarten.
 
Was bedeutet das für meine Nameserver bzw. Resolver?
Ist Ihr Nameserver bzw. der Ihres Internet Service Providers jüngeren 
Datums, werden die zusätzlichen DNSSEC-Information automatisch mit 
abgefragt und Sie erhalten die um die Signaturen erweiterten 
DNS-Antworten. Ohne einen "Trust Anchor" werden diese Informationen jedoch 
nicht weiterverarbeitet. Ältere, nicht DNSSEC-fähige Software wird keine 
Veränderung feststellen.
 
Was ist ein "Trust Anchor"?
Ein DNSSEC Trust Anchor ist ein Key Signing Key (bzw. ein Hash oder 
"Fingerabdruck" dieses Schlüssels), der dem validierenden Resolver als 
authentisch übergeben wird. Die Vertrauenskette in DNSSEC (Signaturen über 
Daten, Schlüssel und die Delegation (DS-Record) in der übergeordneten 
Zone) wird immer auf einen oder mehrere Trust Anchor zurückgeführt. Seit 
Signierung der Rootzone im vergangenen Jahr bietet sich der entsprechende 
Schlüssel als "der" Trust Anchor an. Für die Top Level Domains (TLDs) sind 
entsprechende Einträge in der Rootzone hinterlegt, die die Konfiguration 
separater Trust Anchor für die einzelne TLD nicht erforderlich machen.

Warum der DUdeZ-Zwischenschritt?
Eine unvalidierbar signierte Zone ermöglicht es, sämtliche Einflüsse der 
DNSSEC-Information in den DNS-Antworten auf die gesamte DNS-Infrastruktur 
zu beobachten und zu analysieren und dabei die Option zur Rückkehr zur 
unsignierten Zone jederzeit offenzuhalten. Gleichzeitig signalisiert der 
verschleierte Key Signing Key (KS), dass sein Einsatz als Trust Anchor 
fehlschlagen wird und eine Validierung für den Einführungszeitraum weder 
möglich noch erwünscht ist.

Ab wann kann DNSSEC für .de mit Validierung eingesetzt werden?
Nach dem Abschluss der DUdeZ-Phase soll zum 31. Mai 2011 der verschleierte 
Schlüssel durch den Originalschlüssel ersetzt werden. Es wird dann noch 
einige Tage dauern, bis der DS-Record für .de in der Rootzone sichtbar 
wird. Erst dann ist die Validierung signierter .de-Domains mit dem Root 
Trust Anchor möglich. Eine Nutzung des ab dem 31. Mai 2011 sichtbaren KSK 
der .de-Zone als Trust Anchor ist nicht empfehlenswert, da mit einer 
solchen Konfiguration etwaige spätere Schlüsselwechsel unbemerkt bleiben 
könnten. Dies hätte dann Validierungsfehler und Ausfälle zur Folge. Im 
Gegensatz zum Testbed wird es für die produktive .de-Zone keinen separaten 
gesicherten Publikationskanal für den KSK geben - außer dem bereits 
erwähnten DS-Record in der Rootzone. Mit dessen Verfügbarkeit rechnen wir 
gegen Mitte Juni 2011.

Was geschieht mit dem DNSSEC-Testbed?
Das DNSSEC-Testbed wird mit seiner separaten Infrastruktur und eigenem 
Trust Anchor bis Ende Juli 2011 weiterbetrieben.

Sollten Sie Fragen zum Thema DNSSEC haben, wenden Sie sich gerne an 
dnssec AT denic.de.

Weitere Informationen – auch zum aktuellen Stand der DNSSEC-Einführung - 
finden Sie unter http://www.denic.de/dnssec
____________________________________________

Dear Sir or Madam,

Starting today, Friday, 20 May 2011, we will gradually provide all our 16 
name server locations with a signed .de zone. We will use a procedure 
which has already proven successful in the root zone and other TLDs: the 
so-called "Deliberately Unvalidatable DE Zone".

This is a zone which is signed with DNSSEC but which deliberately cannot 
be used for validating. To be precise: The signatures in the RRSIG records 
are created with the correct key, but in the zone this key is replaced by 
another:

de.     7200    IN      DNSKEY  257  3  8 (
                        AwEAAYbcAAAAAGw/++++++++++++++++++++
                        ++++++++++++++++++++++++++++++++++++
                        THIS/IS/AN/INVALID/KEY/THAT/WILL/NOT
                        /VALIDATE/++++++++++++++++++++++++++
                        ++++++++++++++++++++++++++++++++++++
                        CONTACT/DNSSEC/AT/DENIC/DOT/DE/FOR/M
                        ORE/INFORMATION/OR/VISIT/THIS/URL+++
                        http+//www+denic+de/dnssec/+++++++++
                        ++++++++++++++++++++++++++++++++++++
                        ++++++++++++++++++++++8=
                        ) ; Key ID = 24220

Do I have to adjust the configurations of my clients or my (recursive) 
name server?
DNSSEC is an extension of the DNS protocol that is backwards compatible. 
Adjustments of the name server or resolver configurations are currently 
not required. Many name servers are already configured by default to query 
the DNSSEC data. To be able to use DNSSEC for validation (see below), you 
have to configure a so-called "trust anchor". However, this is optional. 
At present, there is no need to adjust any configurations.

Are there definitely no side effects?
In the past it happened in rare cases that "middleware", in particular 
firewalls, NAT systems or home connection devices (CPE, "DSL router" 
etc.), did not handle the larger responses in conformity with the protocol 
or even suppressed this data. However, since DNSSEC is already being used 
in the root zone as well as in other Top Level Domains, most of these 
systems have been adjusted accordingly in the meantime. Thus, no novel 
problems for .de are to be expected due to the launch of DNSSEC.
 
What does this mean for my name servers and/or resolvers?
If your name server or that of your Internet service provider is one of 
the more recent generations, the additional DNSSEC data will be queried 
automatically and you will get the DNS replies extended by the signatures. 
However, if there is no "trust anchor", this data will not be further 
processed. Older software that is not DNSSEC-compatible will not notice 
any change.
 
What is a "trust anchor"?
A DNSSEC trust anchor is a Key Signing Key (or hash or "finger print" of 
this key) that is handed over to the validating resolver as the 
authenticating key. The trust chain in DNSSEC (signatures on data, keys 
and the delegation (DS record) in the superordinate zone) is always based 
on one or several trust anchors. Since the root zone was signed last year 
the corresponding key is just the right "trust anchor" to be used. As 
regards the Top Level Domains (TLD), corresponding records have been 
stored in the root zone that render the configuration of separate trust 
anchors for the individual TLDs unnecessary.

Why the intermediate step of the DUdeZ?
An unvalidatable signed zone makes it possible to monitor and analyze all 
influences the DNSSEC data has on the DNS replies throughout the entire 
DNS infrastructure, and to simultaneously maintain the option to switch 
back to the unsigned zone at any time. At the same time the disguised Key 
Signing Key (KSK) signals that it will fail as trust anchor and that 
validation during the launch phase is neither possible nor desired.

When will it be possible to use DNSSEC for .de with validation?
After conclusion of the DUdeZ phase, i.e. as from 31 May 2011, the 
disguised key shall be replaced by the original key. It will then take a 
few days until the DS record for .de becomes visible in the root zone. 
Only then can signed .de domains be validated by means of the root trust 
anchor. It is not recommended to use the KSK of the .de zone visible as of 
31 May 2011 as trust anchor, since such type of configuration might lead 
to potential later key changes to pass unnoticed. This in turn would 
result in validation errors and failures. Contrary to the testbed, there 
will be no separate secure publication channel for the KSK in the 
productive .de zone - except for the already mentioned DS record in the 
root zone.

What will happen to the DNSSEC testbed?
The DNSSEC testbed with its separate infrastructure and separate trust 
anchor will be continued until end of July 2011.

If you have any further questions about DNSSEC, please contact us at 
dnssec AT denic.de. We will be happy to help.

You will find information about the current status of the DNSSEC launch at 
http://www.denic.de/dnssec


Viele Grüße/Kind regards

Beate Schulz
Unternehmenskommunikation / Public Relations
-- 
DENIC eG
Kaiserstraße 75-77
60329 Frankfurt am Main
GERMANY

E-Mail: presse AT denic.de
Fon: +49 69 27235-274 
Fax: +49 69 27235-235
http://www.denic.de

Angaben nach § 25a Absatz 1 GenG:
DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Sabine Dolderer, Helga Krüger, Carsten Schiefner, Dr. Jörg 
Schweiger 
Vorsitzender des Aufsichtsrats: Elmar Knipp
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht 
Frankfurt am Main