10. Special Considerations (Besondere Hinweise)

10.1. Domain Name Length Restrictions (Längenbeschränkungen für Domainnamen)

Durch diese Spezifikation signierte Zonen unterliegen zusätzlichen Längenbeschränkungen für Domainnamen. Insbesondere können Zonen, deren Namen bei Umwandlung in gehashte Owner-Namen die in [RFC1035] festgelegte Grenze von 255 Oktetten überschreiden würden, diese Spezifikation nicht verwenden.

Die tatsächliche maximale Namenslänge in einer bestimmten Zone hängt von der Länge des Zonennamens (relativ zum vollständigen Domainnamen) und der verwendeten Hash-Funktion ab.

Beispiel: SHA-1 erzeugt einen 160-Bit-Hash. Base-32-Kodierung (encoding) von 160 Bit ergibt 32 Zeichen. Diese 32 Zeichen werden als einzelnes Label dem Zonennamen vorangestellt, einschließlich eines Oktetts Längenfeld. Bei SHA-1 beträgt die maximale Länge des Zonennamens 222 Oktetten (255 − 33).

10.2. DNAME at the Zone Apex (DNAME am Zonenapex)

Die DNAME-Spezifikation in Abschnitt 3 von [RFC2672] hat eine „keine Nachfahren“-Beschränkung (no-descendants limitation). Existiert an einem Knoten N ein DNAME RR, DÜRFEN an keinem Nachfahren von N Daten stehen.

Ist N der Zonenapex, existieren an Nachfahren von N die Typen NSEC3 und RRSIG. Diese Spezifikation aktualisiert die DNAME-Spezifikation, sodass an Nachfahren des Apex die Typen NSEC3 und RRSIG erlaubt sind, unabhängig davon, ob am Apex ein DNAME existiert.

10.3. Iterations (Iterationen)

Die gewählte Anzahl von Iterationen erlaubt dem Zoneninhaber, die Kosten der Hash-Berechnung und damit die Kosten der Wörterbucherzeugung (dictionary) zu steuern. Dies unterscheidet sich von der Wirkung des Salts (salt), das ein einzelnes vorberechnetes Wörterbuch für alle Zeiten verhindert.

Offensichtlich beeinflussen Iterationen auch die Kosten für Signierung und Auslieferung der Zone sowie die Kosten der Validierung durch Validatoren. Daher setzen wir eine Obergrenze für Iterationen, basierend auf der ungefähren Kostengröße der RRSet-Verifikation.

Die Grenze basiert auf der Größe des kleinsten Zonensignaturschlüssels (zone signing key), aufgerundet auf den nächsten Tabellenwert (ist der Schlüssel größer als der größte Tabellenwert, wird abgerundet).

Für eine gegebene Schlüsselgröße DARF der Zoneninhaber keinen höheren Iterationswert verwenden als in der folgenden Tabelle angegeben. Nachdem der Validator die Signatur auf dem NSEC3 RR korrekt verifiziert hat, KANN ein Resolver Antworten mit höheren Werten als unsicher (insecure) behandeln.

Key Size (Schlüsselgröße)	Iterations (Iterationen)
1024	150
2048	500
4096	2.500

Die Tabelle basiert auf Näherungsverhältnissen zwischen SHA-1-Rechenkosten und RSA-Verifikationskosten für 1024-Bit-Schlüssel (150:1), 2048-Bit (500:1) und 4096-Bit (2500:1).

Das Verhältnis zwischen SHA-1 und DSA-Verifikation ist höher (für 1024-Bit-Schlüssel etwa 1500:1). Höhere Iterationszähler verschlechtern die Leistung, während DSA-Verifikation bei gleicher Schlüsselgröße bereits teurer ist als RSA. Die Tabellenwerte MÜSSEN daher unabhängig vom Schlüsselalgorithmus verwendet werden.

10.4. Transitioning a Signed Zone from NSEC to NSEC3 (Übergang einer signierten Zone von NSEC zu NSEC3)

Beim Übergang einer bereits signierten und vertrauenswürdigen Zone zu dieser Spezifikation ist Vorsicht geboten, um Validierungsfehler bei Clients zu vermeiden.

Der grundlegende Ablauf:

Stellen Sie alle DNSKEY auf DNSKEY mit den in Abschnitt 2 beschriebenen Algorithmus-Aliasen (algorithm aliases) um. Konkrete Verfahren zum sicheren und zuverlässigen Ändern des DNSKEY-RRSets der Zone liegen außerhalb dieser Spezifikation. Das Endergebnis MUSS sein, dass alle DS RRs in der Elternzone die angegebenen Algorithmus-Aliase verwenden.

Nach Abschluss dieses Übergangs behandeln alle NSEC3-unkundigen Clients die Zone als unsicher. Zu diesem Zeitpunkt liefern autoritative Server weiterhin negative und Wildcard-Antworten mit NSEC RRs.
Fügen Sie signierte NSEC3 RRs zur Zone hinzu, inkrementell oder auf einmal. Wird inkrementell vorgegangen, MUSS das zuletzt hinzugefügte RRSet das NSEC3PARAM-RRSet sein.
Nach Hinzufügen des NSEC3PARAM-RRSets wechseln die Server gemäß dieser Spezifikation zur Auslieferung negativer und Wildcard-Antworten mit NSEC3 RRs.
Entfernen Sie NSEC RRs inkrementell oder auf einmal.

10.5. Transitioning a Signed Zone from NSEC3 to NSEC (Übergang einer signierten Zone von NSEC3 zu NSEC)

Für einen sicheren Rückweg zu DNSSEC [RFC4035]-signierten Zonen kehren Sie den obigen Ablauf um:

Fügen Sie NSEC RRs inkrementell oder auf einmal hinzu.
Entfernen Sie das NSEC3PARAM-RRSet. Dadurch signalisieren Sie dem Server, NSEC RRs für negative und Wildcard-Antworten zu verwenden.
Entfernen Sie NSEC3 RRs inkrementell oder auf einmal.
Stellen Sie alle DNSKEY auf die DNSSEC-Algorithmus-Identifikatoren um. Nach Abschluss behandeln alle NSEC3-unkundigen Clients die Zone wieder als sicher.