7. Authoritative Server Considerations (Hinweise für autoritative Server)

7.1. Zone Signing (Zonensignierung)

Zonen mit NSEC3 müssen folgende Eigenschaften erfüllen:

Jeder Owner-Name innerhalb der Zone, der autorisierende RRSets besitzt, MUSS einen entsprechenden NSEC3 RR haben. Owner-Namen, die unsignierten Delegationen entsprechen, KÖNNEN einen entsprechenden NSEC3 RR haben. Gibt es jedoch keinen entsprechenden NSEC3 RR, MUSS ein Opt-Out-NSEC3 RR existieren, das den „next closer“-Namen zur Delegation abdeckt. Andere nicht autorisierende RRs werden nicht durch NSEC3 RRs dargestellt.
Jeder leere Nicht-Endknoten (empty non-terminal) MUSS einen entsprechenden NSEC3 RR haben, es sei denn, der leere Nicht-Endknoten stammt ausschließlich von einer unsicheren Delegation, die von einem Opt-Out-NSEC3 RR abgedeckt wird.
Der TTL-Wert jedes NSEC3 RR SOLLTE derselbe sein wie der Minimum-TTL-Wert im SOA RR der Zone.
Das Feld Type Bit Maps jedes NSEC3 RR in einer signierten Zone MUSS das Vorhandensein aller Typen am ursprünglichen Owner-Namen anzeigen, außer Typen, die ausschließlich durch den NSEC3 RR selbst beigesteuert werden. Das bedeutet, der NSEC3-Typ selbst wird niemals in den Type Bit Maps erscheinen.

Die folgenden Schritte beschreiben eine Methode zur korrekten Konstruktion von NSEC3 RRs. Es ist nicht die einzig mögliche Methode.

Wählen Sie den Hash-Algorithmus (hash algorithm) sowie Werte für Salt und Iterationen (iterations).
Für jeden eindeutigen ursprünglichen Owner-Namen in der Zone fügen Sie einen NSEC3 RR hinzu.
- Wird Opt-Out verwendet, KÖNNEN Owner-Namen unsignierter Delegationen ausgelassen werden.
- Der Owner-Name des NSEC3 RR ist der Hash des ursprünglichen Owner-Namens, als einzelnes Label (label) dem Zonennamen vorangestellt.
- Das Feld Next Hashed Owner Name bleibt vorerst leer.
- Wird Opt-Out verwendet, setzen Sie das Opt-Out-Bit auf 1.
- Optional: Speichern Sie zur Kollisionserkennung (collision detection) den ursprünglichen Owner-Namen zusammen mit dem NSEC3 RR.
- Optional: Erzeugen Sie zur Kollisionserkennung einen zusätzlichen NSEC3 RR für den ursprünglichen Owner-Namen mit vorangestelltem Stern-Label (als ob eine Wildcard als Kind dieses Owner-Namens existierte) und verfolgen Sie diesen ursprünglichen Owner-Namen. Markieren Sie diesen NSEC3 RR als temporär (temporary).
Für jedes RRSet am ursprünglichen Owner-Namen setzen Sie die entsprechenden Bits im Type-Bitmap-Feld.
Ist die Differenz der Labelanzahl zwischen Zonenapex (apex) und ursprünglichem Owner-Namen größer als 1, sind zusätzliche NSEC3 RRs für jeden leeren Nicht-Endknoten zwischen Apex und ursprünglichem Owner-Namen erforderlich. Dies kann NSEC3 RRs mit doppelt vorkommenden gehashten Owner-Namen erzeugen. Optional: Verfolgen Sie zur Kollisionserkennung die ursprünglichen Owner-Namen dieser NSEC3 RRs und erzeugen Sie wie in Schritt 1 temporäre NSEC3 RRs für Wildcard-Kollisionen.
Sortieren Sie die Menge der NSEC3 RRs in Hash-Reihenfolge (hash order).
Kombinieren Sie NSEC3 RRs mit demselben gehashten Owner-Namen zu einem einzelnen NSEC3 RR, dessen Type-Bitmap-Feld die Vereinigung der durch die NSEC3-RR-Menge dargestellten Typen ist. Wurden ursprüngliche Owner-Namen verfolgt, können bei der Kombination Kollisionen erkannt werden, da alle passenden NSEC3 RRs denselben ursprünglichen Owner-Namen haben sollten. Verwerfen Sie alle temporären NSEC3 RRs.
Tragen Sie in jedem NSEC3 RR den nächsten gehashten Owner-Namen ein, indem Sie den Wert des nächsten NSEC3 RR in Hash-Reihenfolge verwenden. Der nächste gehashte Owner-Name im letzten NSEC3 RR der Zone enthält den Wert des gehashten Owner-Namens des ersten NSEC3 RR der Zone in Hash-Reihenfolge.
Fügen Sie schließlich am Zonenapex einen NSEC3PARAM RR mit denselben Feldern Hash Algorithm, Iterations und Salt hinzu.

Wird eine Hash-Kollision erkannt, MUSS ein neues Salt gewählt und der Signiervorgang neu gestartet werden.

7.2. Zone Serving (Zonenauslieferung)

Diese Spezifikation ändert von autoritativen Servern erzeugte DNS-Antworten mit aktiviertem DNSSEC. Insbesondere ersetzt sie die Verwendung von NSEC RRs in solchen Antworten durch NSEC3 RRs.

In den folgenden Antwortfällen werden die in DNSSEC [RFC4035] vorgeschriebenen NSEC RRs durch NSEC3 RRs ersetzt, die dieselben Fakten beweisen. Diese Spezifikation ändert Antworten ohne NSEC RRs nicht.

Werden Antworten mit mehreren NSEC3 RRs zurückgegeben, MÜSSEN alle NSEC3 RRs denselben Hash-Algorithmus, dieselben Iterationen und dasselbe Salt verwenden. Der Wert des Feldes Flags MUSS null oder eins sein.

7.2.1. Closest Encloser Proof (Beweis des nächsten einschließenden Vorfahren)

Für viele NSEC3-Antworten ist ein Beweis des nächsten einschließenden Vorfahren (closest encloser) erforderlich. Dies beweist, dass ein Vorfahr des QNAME der nächste einschließende Vorfahr des QNAME ist.

Der Beweis besteht aus (höchstens) zwei verschiedenen NSEC3 RRs:

einem NSEC3 RR, der zum nächsten (beweisbaren) einschließenden Vorfahren passt;
einem NSEC3 RR, der den „next closer“-Namen zum nächsten einschließenden Vorfahren abdeckt.

Der erste NSEC3 RR schlägt im Wesentlichen einen möglichen nächsten einschließenden Vorfahren vor und beweist, dass dieser Vorfahr tatsächlich existiert. Der zweite NSEC3 RR beweist, dass der mögliche nächste einschließende Vorfahr der nächste ist, und beweist, dass der QNAME (und alle Vorfahren zwischen QNAME und nächstem einschließenden Vorfahren) nicht existiert.

In den folgenden Beschreibungen werden diese NSEC3 RRs zusammenfassend als „Closest Encloser Proof“ bezeichnet.

Beispiel: Ein Closest-Encloser-Beweis für den nicht existierenden Owner-Namen „alpha.beta.gamma.example.“ kann beweisen, dass „gamma.example.“ der nächste einschließende Vorfahr ist. Die Antwort enthält einen zum „gamma.example.“ passenden NSEC3 RR sowie einen NSEC3 RR, der „beta.gamma.example.“ (den „next closer“-Namen) abdeckt.

Bei Verwendung von Opt-Out (Abschnitt 6) kann der tatsächliche nächste einschließende Vorfahr nicht beweisbar sein, weil er Teil einer unsicheren Delegation ist, die von einer Opt-Out-Spanne abgedeckt wird. In diesem Fall wird der nächste beweisbare einschließende Vorfahr (closest provable encloser) verwendet statt des tatsächlichen nächsten einschließenden Vorfahrens, d. h. der nächste autorisierende geschlossene Name. Die für diesen Beweis verwendete Menge von NSEC3 RRs heißt dann „Closest Provable Encloser Proof“.

7.2.2. Name Error Responses (Namensfehler-Antworten)

Um die Nichtexistenz des QNAME zu beweisen, MUSS die Antwort den Closest-Encloser-Beweis und einen NSEC3 RR enthalten, der die (nicht existierende) Wildcard-RR am nächsten einschließenden Vorfahren abdeckt. Diese Menge von (höchstens) drei NSEC3 RRs beweist sowohl, dass der QNAME nicht existiert, als auch, dass kein den QNAME treffender Wildcard-Name existiert.

Beispiel: Ist „gamma.example.“ der nächste beweisbare einschließende Vorfahr zum QNAME, enthält der Authority-Abschnitt der Antwort einen NSEC3 RR, der „*.gamma.example.“ abdeckt.

7.2.3. No Data Responses, QTYPE is not DS (No-Data-Antworten, QTYPE ist nicht DS)

Der Server MUSS einen zum QNAME passenden NSEC3 RR einschließen. In diesem NSEC3 RR DÜRFEN im Feld Type Bit Maps die Bits für QTYPE oder CNAME NICHT gesetzt sein.

7.2.4. No Data Responses, QTYPE is DS (No-Data-Antworten, QTYPE ist DS)

Gibt es einen zum QNAME passenden NSEC3 RR, MUSS der Server ihn in der Antwort zurückgeben. Im Feld Type Bit Maps dieses NSEC3 RR dürfen die Bits für DS und CNAME nicht gesetzt sein.

Gibt es keinen zum QNAME passenden NSEC3 RR, MUSS der Server den Closest-Provable-Encloser-Beweis für den QNAME zurückgeben. Der eingeschlossene NSEC3 RR, der den „next closer“-Namen abdeckt, MUSS das Opt-Out-Bit gesetzt haben (per Definition korrekt – ist das Opt-Out-Bit nicht gesetzt, liegt ein Fehler vor).

Ist der Server für beide Seiten eines Zonenschnitts (zone cut) am QNAME autoritativ, MUSS er den Beweis von der Elternseite des Zonenschnitts zurückgeben.

7.2.5. Wildcard No Data Responses (Wildcard-No-Data-Antworten)

Gibt es eine Wildcard-Übereinstimmung für den QNAME, aber am Namen existiert kein QTYPE, MUSS die Antwort den Closest-Encloser-Beweis für den QNAME enthalten sowie einen zum Wildcard passenden NSEC3 RR. Diese Kombination beweist sowohl, dass der QNAME selbst nicht existiert, als auch, dass eine den QNAME treffende Wildcard tatsächlich existiert. Der nächste einschließende Vorfahr zum QNAME MUSS der direkte Vorfahr der Wildcard-RR sein (andernfalls liegt ein Fehler vor).

7.2.6. Wildcard Answer Responses (Wildcard-Antworten)

Gibt es eine Wildcard-Übereinstimmung für QNAME und QTYPE, MUSS neben dem im Answer-Abschnitt zurückgegebenen expandierten Wildcard-RRSet auch der Beweis geliefert werden, dass die Wildcard-Übereinstimmung gültig war.

Dies geschieht durch den Nachweis, dass der QNAME nicht existiert und der nächste einschließende Vorfahr des QNAME und der direkte Vorfahr der Wildcard identisch sind (d. h. die richtige Wildcard wurde getroffen).

Dazu MUSS ein NSEC3 RR zurückgegeben werden, der den „next closer“-Namen zum direkten Vorfahren der Wildcard abdeckt. Ein zum nächsten einschließenden Vorfahren passender NSEC3 RR ist nicht erforderlich, da die Existenz dieses Vorfahrens durch die im Answer vorhandene expandierte Wildcard bewiesen wird.

7.2.7. Referrals to Unsigned Subzones (Verweise auf unsignierte Unterzonen)

Gibt es einen zum Delegationsnamen passenden NSEC3 RR, MUSS dieser NSEC3 RR in der Antwort enthalten sein. Das DS-Bit in der Type-Bitmap des NSEC3 RR DARF NICHT gesetzt sein.

Ist die Zone Opt-Out, kann es keinen zum Delegationsnamen passenden NSEC3 RR geben. In diesem Fall MUSS die Antwort den Closest-Provable-Encloser-Beweis enthalten. Der eingeschlossene NSEC3 RR, der den „next closer“-Namen der Delegation abdeckt, MUSS das Opt-Out-Flag auf eins setzen (sofern kein Fehler vorliegt, wird dies der Fall sein).

7.2.8. Responding to Queries for NSEC3 Owner Names (Antworten auf Abfragen nach NSEC3-Owner-Namen)

Der Owner-Name eines NSEC3 RR wird anders als andere Owner-Namen nicht in der NSEC3-RR-Kette dargestellt. Folglich wird jeder NSEC3-Owner-Name von einem anderen NSEC3 RR abgedeckt, was faktisch die Existenz des NSEC3 RR verneint. Dies ist ein Paradoxon (paradox), da die Existenz des NSEC3 RR durch sein RRSIG RRSet bewiesen werden kann.

Sind alle folgenden Bedingungen erfüllt:

QNAME ist gleich dem Owner-Namen eines existierenden NSEC3 RR, und
am QNAME existiert kein RR-Typ, und an keinem Nachfahren des QNAME existiert einer,

MUSS die Antwort als Namensfehler-Antwort konstruiert werden (Abschnitt 7.2.2). Mit anderen Worten verhält sich der autoritative Nameserver so, als ob der Owner-Name des NSEC3 RR nicht existierte.

Hinweis: NSEC3 RRs werden als Ergebnis von AXFR- oder IXFR-Abfragen zurückgegeben.

7.2.9. Server Response to a Run-Time Collision (Serverantwort auf eine Laufzeitkollision)

Kollidiert der Hash eines nicht existierenden QNAME mit dem Owner-Namen eines existierenden NSEC3 RR, kann der Server keine Antwort liefern, die die Nichtexistenz des QNAME beweist. In diesem Fall MUSS der Server eine Antwort mit RCODE 2 (Serverfehler, server failure) zurückgeben.

Hinweis: Mit dem in diesem Dokument angegebenen Hash-Algorithmus SHA-1 sind solche Kollisionen extrem unwahrscheinlich.

7.3. Secondary Servers (Sekundärserver)

Sekundärserver (und möglicherweise andere Instanzen) müssen zuverlässig feststellen können, welche NSEC3-Parameter (Hash, Salt und Iterationen) an jedem gehashten Owner-Namen vorliegen, um geeignete NSEC3-RR-Mengen für negative Antworten wählen zu können. Dies wird durch das am Zonenapex vorhandene NSEC3PARAM RR angezeigt.

Gibt es mehrere NSEC3PARAM RRs, existieren mehrere gültige NSEC3-Ketten. Der Server MUSS eine davon wählen, kann aber beliebige Kriterien verwenden.

7.4. Zones Using Unknown Hash Algorithms (Zonen mit unbekannten Hash-Algorithmen)

Zonen, die gemäß dieser Spezifikation signiert sind, aber einen nicht erkennbaren NSEC3-Hash-Algorithmus-Wert verwenden, können nicht sinnvoll bedient werden. Solche Zonen SOLLEN beim Laden abgelehnt werden. Server SOLLEN bei der Verarbeitung von Abfragen, die zu solchen Zonen gehören würden, mit RCODE=2 (Serverfehler) antworten.

7.5. Dynamic Update (dynamische Aktualisierung)

Mit NSEC3 signierte Zonen können dynamische Updates [RFC2136] akzeptieren. NSEC3 führt jedoch besondere Überlegungen für dynamische Updates ein.

Das Hinzufügen und Entfernen von Namen in der Zone MUSS die Erzeugung oder Entfernung leerer Nicht-Endknoten berücksichtigen.

Wird ein Name mit zugehörigem NSEC3 RR entfernt, MÜSSEN alle NSEC3 RRs entfernt werden, die dem durch diesen Namen erzeugten leeren Nicht-Endknoten entsprechen. Mehrere Namen können die Existenz eines bestimmten leeren Nicht-Endknoten behaupten.
Wird ein Name hinzugefügt, der einen NSEC3 RR erfordert, MÜSSEN auch NSEC3 RRs für alle erzeugten leeren Nicht-Endknoten hinzugefügt werden. Existiert kein passender NSEC3 RR für einen leeren Nicht-Endknoten, MUSS er erzeugt und hinzugefügt werden.

Opt-Out in der Zone bedeutet, dass das Hinzufügen bestimmter Namen oder Delegationen keine Änderung der NSEC3 RRs in der Zone erfordert.

Wird ein Delegations-RRSet entfernt und gibt es keinen passenden NSEC3 RR für die Delegation, wurde per Opt-Out ausgeschlossen. In diesem Fall sind keine weiteren Schritte nötig.
Wird ein Delegations-RRSet hinzugefügt und deckt ein bestehender Opt-Out-NSEC3 RR den „next closer“-Namen der Delegation ab, KANN die Delegation ohne Änderung der NSEC3 RRs in der Zone hinzugefügt werden.

Opt-Out in der Zone bedeutet, dass der Wert des Opt-Out-Flags in neuen oder geänderten NSEC3 RRs beim Hinzufügen oder Entfernen von NSEC3 RRs uneindeutig ist. Server SOLLTEN die folgenden Grundregeln anwenden, um die Uneindeutigkeit aufzulösen.

Kernidee: Den Zustand des Opt-Out-Flags abdeckender NSEC3 RRs beibehalten.

Beim Entfernen eines NSEC3 RR soll der Wert des Opt-Out-Flags des vorhergehenden NSEC3 RR (dessen Next-Hashed-Owner-Name geändert wird) nicht geändert werden.
Beim Hinzufügen eines NSEC3 RR wird der Wert des Opt-Out-Flags auf den Wert des Opt-Out-Flags des NSEC3 RR gesetzt, der zuvor den Owner-Namen des neuen NSEC3 RR abgedeckt hat, d. h. des jetzt vorhergehenden NSEC3 RR.

Ist die Zone in der Verwendung des Opt-Out-Flags konsistent (alle NSEC3 RRs haben denselben Wert), bewahren diese Regeln die Konsistenz. Ist die Zone inkonsistent (teilweise Opt-Out-Zone), bewahren die Regeln nicht dasselbe Muster der Flag-Nutzung.

Bei teilweiser Nutzung des Opt-Out-Flags kann ein logisches Muster durch lokale Richtlinie (local policy) auf dem Server aufrechterhalten werden.