3. Nameserver Predelegation Check DNSSEC

3.1 Technischer Hintergrund

Um für die Validierung bei DNSSEC eine Vertrauenskette (chain of trust) aufbauen zu können, sieht das DNSSEC-Protokoll vor, in der delegierenden Zone einen Hinweis auf den oder die Schlüssel der delegierten Zone zu hinterlegen. Die Vertrauenskette folgt damit dem Delegationspfad.

Der entscheidende Schlüssel ist der Key Signing Key der delegierten Zone, der in der Regel als Secure Entry Point (SEP) markiert ist. Diese Information liegt in einem DNSKEY-RR in der delegierten Zone vor und ist dort (mindestens) von diesem DNSKEY selbst unterschrieben. In der delegierenden Zone wird diese Information aus Platzgründen nicht exakt wiederholt. Statt des eigentlichen Schlüssels wird dort ein entsprechender Fingerprint in einem DS-RR (Delegation Signer) abgelegt.

Für die Provisionierung des Schlüsselmaterials wird der DNSKEY-RR verwendet. Bis zu fünf DNSKEY-RRs können pro Domain registriert werden. Im Rahmen der

Zonengenerierung werden die entsprechenden DS-Records erzeugt (derzeit genau ein DS-RR pro mitgeteiltem Trust Anchor), signiert und mit der Zone verteilt.

3.2 Aufbau des Dnskey-Records

Das Format des Dnskey-Records ist in Kapitel 2 von RFC 4034 beschrieben:

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Public Key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unter den Flags findet sich je ein Eintrag für das Feld Zone Key und Secure Entry Point. Zusätzliche Erweiterungen für den automatisierten Wechsel eines Trust Anchors sind in RFC 5011 beschrieben. Im Feld Algorithm wird der verwendete Public-Key-Algorithmus spezifiziert, der dann auch die innere Struktur und die Größe der eigentlichen Schlüsseldaten bestimmt. Zusätzlich wird dieses Feld genutzt, um mit Hilfe von AliasMechanismen die Verwendung von NSEC3 zu signalisieren.

3.3 Trennung von KSK und ZSK

Mit der erstmaligen Einführung des DS-RR in RFC 3658 wurde auch die Unterscheidung des Zone Signing Keys (ZSK) und des Key Signing Keys (KSK) begonnen. Während der erste die eigentlichen Daten (RRSets) in der Zone signiert, dient der zweite, als der KSK, ausschließlich zur Authentisierung des ZSK. Mit dieser Trennung wurde den unterschiedlichen Anforderungen an die Schlüssel Rechnung getragen.

Eine Änderung des KSK erfordert eine Interaktion mit der delegierenden Zone, sollte darum moderat häufig vorkommen und erfordert somit einen längerlebigen (daraus folgt meist: längeren) Schlüssel. Der ZSK kann einfacher gewechselt werden und wird darum in der Regel kürzer gewählt, was zumindest für das RSA-Verfahren zu kürzeren Signaturen und damit zu kleineren Zonendateien und zu kleineren Antwortpaketen führt. Hinweise zu Schlüssellängen und -wechseln finden sich in unter anderem in RFC 4641.

Während die Trennung eine Erleichterung hinsichtlich der Parameterwahl darstellt, erhöht sie andererseits die Komplexität ds Protokolls. Allerdings ist sie nicht zwingend. Die Verwendung nur eines Schlüssels anstelle eines KSK/ZSK-Paares unter Inkaufnahme der oben beschriebenen Nachteile ist protokollkonform und kommt in der Praxis gelegentlich vor. Theoretisch wäre es auch möglich, weitere Indirektionen in die Schlüsselbeziehungen einzuführen. Da allerdings eine Signatur ein RRSet immer vollständig erfasst, muss jede Signatur über dem DNSKEY-RRSet zwangsläufig alle dort enthaltenen Schlüssel authentisieren. Es reicht also, die Fälle ZSK+KSK und ZSK=KSK zu berücksichtigen.

3.4 Nutzung und Veröffentlichung von Schlüsseln

Ein zur Registrierung übergebener DNSKEY-RR ist sichtbar, wenn er im DNSKEY-RRSet einer Zone enthalten ist.

3.5 Konzept der Proof of Possession

Im Betrieb von Certification Authorities (CAs) ist das Konzept der Proof of Possession von Bedeutung. Man versteht darunter die Bedingung, dass eine Zertifikatsanforderung von einem Nachweis begleitet ist, dass der Anfordernde Zugriff auf das private Pendant des öffentlichen Schlüssels besitzt, für den das Zertifikat angefordert wird. Aus Sicherheitsgründen ist eine Übernahme dieser Praxis in den DNSSEC-Betrieb empfehlenswert (siehe auch 3.6.3 Einsatz der DNSKEY-Records).

3.6 Technische Voraussetzungen und Prüfungen

Zur Übernahme in die Datenbank und zur korrekten Weiterverarbeitung sowie zur Sicherstellung eines ordentlichen Betriebs wird das Schlüsselmaterial einer mehrstufigen Prüfung unterzogen. Zunächst werden die übergebenen Daten an sich untersucht, im folgenden dann Tests unter Einbeziehung der im DNS abrufbaren Information angestellt.

3.6.1 Parameter der übergebenen DNSKEY-Records

Die zur Registrierung übergebenen Schlüssel müssen eindeutig sein, müssen sich also in mindestens einem Feld unterscheiden [sonst Ausgabe von ERROR]. Es kann vorkommen, dass Schlüssel (Public Key) mit unterschiedlichen Flags mehrfach übergeben wird. KeyTags werden nicht auf Eindeutigkeit geprüft [sonst Ausgabe von ERROR].

3.6.1.1 DNSKEY: Flags

Im Feld Flags dürfen ausschließlich Bits gesetzt sein, die in der IANA-Registry als zugewiesen markiert sind [sonst Ausgabe von ERROR]. Das Feld wird ausschließlich als numerischer Wert (0 - 65535) übergeben.

1. Bit 7 (ZONE) muss gesetzt sein [sonst Ausgabe von ERROR].

Vorgeschrieben in RFC 4034, Kapitel 2.1.1.

2. Bit 8 (REVOKE) darf nicht gesetzt sein [sonst Ausgabe von ERROR].

Folgt aus Kapitel 2.1 von RFC 5011. Ein Zurückgerufener Schlüssel kann nicht als Trust Anchor fungieren.

3. Bit 15 (SEP) sollte gesetzt sein [sonst Ausgabe von WARNING].

Dieses Feld soll den KSK im DNSKEY-RRSet identifizieren. Es entspricht guter Praxis, es für KSKs bzw. Trust Anchor zu setzen, auch wenn Validatoren es nicht auswerten sollen.

Derzeit mögliche Werte sind also 256 (ZONE) und 257 (ZONE, SEP), wobei nur letzterer ohne Warnung akzeptiert wird.

3.6.1.2 DNSKEY: Protocol

Das Feld Protocol muss den Wert "3" haben. Dieser Wert ist in Abschnitt 2.1.2 von RFC 4034 zwingend vorgeschrieben.

3.6.1.3 DNSKEY: Algorithm

Im Feld Algorithm dürfen die Werte vorkommen, die in der IANA-Registry enthalten, dort als nutzbar markiert und nicht für private Zwecke reserviert sind. Derzeit werden folgende Werte unterstützt: 3, 5, 6, 7, 8, 10, 12, 13 und 14. Als kryptographische Algorithmen sind dabei RSA, DSA, ECDSA und GOST mit verschiedenen Hashverfahren definiert.

Die in der IANA-Registry enthaltenen Algorithmen 15 (ED25519) und 16 (ED448) werden zurzeit nicht unterstützt.

3.6.1.4 DNSKEY: Public Key

Das Feld Public Key enthält den öffentlichen Schlüssel in Base64-Codierung. Die interne Struktur hängt vom verwendeten Algorithmus ab, so entsprechend auch deren Prüfung:

RSA (Relevant für die Werte 5, 7, 8, 10)

1. Der Modulus muss zwischen 512 und 4096 Bit (jeweils einschließlich) lang sein [sonst Ausgabe von ERROR].

2. Der Exponent darf maximal 128 Bit lang sein [sonst Ausgabe von ERROR].

Die Grenzen folgen aus RFC 3110 und für den Exponenten zusätzlich aus der Begrenzung der Zeilenlänge bei der Provisionierung.

Eine Bewertung der Schlüsselstärke erfolgt nicht.

DSA (Relevant für die Werte 3, 6)

3. Der Parameter T darf Werte zwischen 0 und 8 (jeweils einschließlich) annehmen [sonst Ausgabe von ERROR].

4. Die Länge muss 213 + T * 24 entsprechen [sonst Ausgabe von ERROR].

Diese Grenzen sind in RFC 2536 festgelegt.

Eine Bewertung der Schlüsselstärke erfolgt nicht.

ECDSA (Relevant für die Werte 13, 14)

5. Für den Algorithmus ECDSAP256SHA256 (13) muss der Schlüssel die Länge 512 Bit haben [sonst Ausgabe von ERROR].

6. Für den Algorithmus ECDSAP384SHA384 (14) muss der Schlüssel die Länge 768 Bit haben [sonst Ausgabe von ERROR].

Diese Werte ergeben sich aus RFC 6605, Abschnitt 4.

GOST (Relevant für den Werte 12)

7. Der Schlüssel muss die Länge 512 Bit haben [sonst Ausgabe von ERROR].

Dieser Wert ergibt sich aus RFC 5933, Abschnitt 2.

3.6.2 Sichtbarkeit und Status der DNSKEY-Records

Das DNSKEY-RRSet muss an allen autoritativen Servern identisch sein [sonst Ausgabe von ERROR].

Mindestens einer der zur Registrierung übergebenen Schlüssel muss sichtbar sein [sonst Ausgabe von ERROR]. Für jeden nicht sichtbaren Schlüssel wird eine WARNING erzeugt. Eventuell im DNSKEY-RRSet zusätzlich vorhandene Schlüssel werden nicht betrachtet. Eine Übereinstimmung der von unterschiedlichen Servern bezogenen Signaturen ist die Regelannahme, wird aber nicht ausdrücklich geprüft oder gefordert. Insbesondere dem DSA- und ECDSA-Verfahren wird so ermöglicht, online zu signieren.

3.6.3 Einsatz der DNSKEY-Records

Mindestens ein sichtbarer zur Registrierung übergebener Schlüssel muss das DNSKEYRRSet gültig signieren [sonst Ausgabe von ERROR].

Diese Anforderung dient der Umsetzung des Proof of Possession.

3.6.4 Validierung mit DNSKEY-Records

Zum SOA-RR der delegierten Zone muss eine aktuell gültige Validierungskette mit mindestens einem sichtbaren zur Registrierung übergebenen Schlüssel existieren [sonst Ausgabe von ERROR].

Ein SOA-RR ist in jeder Zone vorhanden und wird im Rahmen der Predelegationchecks ohnehin abgefragt. Durch die Prüfung der Validierung wird Security Lameness vorgebeugt.

3.6.5 Übergreifende Regeln

Neben den auf die Zonendaten abgestellten Prüfungen ergeben sich durch DNSSEC Anforderungen an die autoritativen Server bzw. die sie umgebende Infrastruktur:

1. Alle autoritativen Server müssen DNSSEC unterstützen, somit auf Anfragen mit dem DOBit signierte, DNSSEC-konforme Antworten liefern [sonst Ausgabe von ERROR].

2. Alle autoritativen Server sollen TCP und EDNS0 mit ausreichender Paketgröße unterstützen [sonst Ausgabe von WARNING].

3. Das DNSKEY-RRSet muss auf mindestens einem dieser Wege (also via TCP oder EDNS0) signiert abrufbar sein [sonst Ausgabe von ERROR].

In den Predelegation-Checks wird bereits geprüft, ob DNS über TCP unterstützt wird. Für DNSSEC kommt hier die Variante EDNS0 hinzu, wobei wie in 2. Nameserver Predelegation Check beschrieben zunächst eine der beiden Methoden unterstützt werden muß, beim Fehlen der zweiten aber wegen der möglichen operativen Konsequenzen und der Verletzung von Kapitel 3 aus RFC 4035 (ehemals RFC 3226) gewarnt wird. Punkt 3 schließlich formuliert explizit, was als Vorbedingung für die davor genannten Prüfungen ohnehin erfült sein muss, nämlich ein Zugriff auf das signierte DNSKEY-RRSet.