Zum Hauptinhalt springen

3. Serving (Bereitstellung)

Dieser Abschnitt beschreibt das Verhalten von Entitäten, die sicherheitsbewusste Nameserver-Funktionen enthalten. In vielen Fällen werden solche Funktionen Teil eines sicherheitsbewussten rekursiven Nameservers sein, aber ein sicherheitsbewusster autoritativer Nameserver hat einige der gleichen Anforderungen.

Ein sicherheitsbewusster Nameserver muss (MUST) die EDNS0 ([RFC2671]) Nachrichtengrößenerweiterung unterstützen, muss (MUST) eine Nachrichtengröße von mindestens 1220 Oktetten unterstützen und sollte (SHOULD) eine Nachrichtengröße von 4000 Oktetten unterstützen.

Ein sicherheitsbewusster Nameserver, der eine DNS-Abfrage erhält, die den EDNS OPT Pseudo-RR nicht enthält oder bei dem das DO-Bit gelöscht ist, muss (MUST) die RRSIG-, DNSKEY- und NSEC-RRs wie jedes andere RRset behandeln und darf nicht (MUST NOT) die unten beschriebene zusätzliche Verarbeitung durchführen.

DNSSEC weist zwei neue Bits im DNS-Nachrichtenkopf zu:

  • CD-Bit (Checking Disabled): Wird von Resolvern gesteuert
  • AD-Bit (Authentic Data): Wird von Nameservern gesteuert

Ein sicherheitsbewusster Nameserver muss (MUST) das CD-Bit aus einer Abfrage in die entsprechende Antwort kopieren. Ein sicherheitsbewusster Nameserver muss (MUST) die Einstellung des AD-Bits in Abfragen ignorieren.

3.1. Authoritative Name Servers (Autoritative Nameserver)​

Beim Empfang einer relevanten Abfrage, bei der das DO-Bit des EDNS OPT Pseudo-RR gesetzt ist, muss (MUST) ein sicherheitsbewusster autoritativer Nameserver für eine signierte Zone zusätzliche RRSIG-, NSEC- und DS-RRs gemäß den folgenden Regeln einschließen:

  • RRSIG-RRs, die zur Authentifizierung einer Antwort verwendet werden können, müssen (MUST) gemäß den Regeln in Abschnitt 3.1.1 in die Antwort aufgenommen werden
  • NSEC-RRs, die verwendet werden können, um eine authentifizierte Nichtexistenz bereitzustellen, müssen (MUST) automatisch gemäß den Regeln in Abschnitt 3.1.3 in die Antwort aufgenommen werden
  • Entweder ein DS-RRset oder ein NSEC-RR, das beweist, dass keine DS-RRs existieren, muss (MUST) automatisch gemäß den Regeln in Abschnitt 3.1.4 in Delegierungen aufgenommen werden

3.1.1. Including RRSIG RRs in a Response (Einbeziehung von RRSIG-RRs in eine Antwort)​

Bei der Beantwortung einer Abfrage, bei der das DO-Bit gesetzt ist, sollte (SHOULD) ein sicherheitsbewusster autoritativer Nameserver versuchen, RRSIG-RRs zu senden, die ein sicherheitsbewusster Resolver verwenden kann, um die RRsets in der Antwort zu authentifizieren.

Regeln:

  • Beim Platzieren eines signierten RRsets im Answer-Abschnitt muss (MUST) der Nameserver auch seine RRSIG-RRs im Answer-Abschnitt platzieren
  • Beim Platzieren eines signierten RRsets im Authority-Abschnitt muss (MUST) der Nameserver auch seine RRSIG-RRs im Authority-Abschnitt platzieren
  • Beim Platzieren eines signierten RRsets im Additional-Abschnitt muss (MUST) der Nameserver auch seine RRSIG-RRs im Additional-Abschnitt platzieren
  • Wenn der Platz die Einbeziehung von RRSIG-RRs in den Answer- oder Authority-Abschnitten nicht erlaubt, muss (MUST) der Nameserver das TC-Bit setzen

3.1.2. Including DNSKEY RRs in a Response (Einbeziehung von DNSKEY-RRs in eine Antwort)​

Bei der Beantwortung einer Abfrage, bei der das DO-Bit gesetzt ist und die die SOA- oder NS-RRs am Apex einer signierten Zone anfordert, kann (MAY) ein sicherheitsbewusster autoritativer Nameserver für diese Zone das Zonen-Apex-DNSKEY-RRset im Additional-Abschnitt zurückgeben.

Das DNSKEY-RRset und die zugehörigen RRSIG-RRs haben eine niedrigere Priorität als jede andere Information, die im Additional-Abschnitt platziert werden würde.

3.1.3. Including NSEC RRs in a Response (Einbeziehung von NSEC-RRs in eine Antwort)​

Bei der Beantwortung einer Abfrage, bei der das DO-Bit gesetzt ist, muss (MUST) ein sicherheitsbewusster autoritativer Nameserver für eine signierte Zone NSEC-RRs in jedem der folgenden Fälle einschließen:

No Data (Keine Daten): Die Zone enthält RRsets, die genau mit <SNAME, SCLASS> übereinstimmen, enthält aber keine RRsets, die genau mit <SNAME, SCLASS, STYPE> übereinstimmen.

Name Error (Namensfehler): Die Zone enthält keine RRsets, die mit <SNAME, SCLASS> entweder genau oder über Wildcard-Namenserweiterung übereinstimmen.

Wildcard Answer (Wildcard-Antwort): Die Zone enthält keine RRsets, die genau mit <SNAME, SCLASS> übereinstimmen, enthält aber ein RRset, das über Wildcard-Namenserweiterung mit <SNAME, SCLASS, STYPE> übereinstimmt.

Wildcard No Data (Wildcard ohne Daten): Die Zone enthält keine RRsets, die genau mit <SNAME, SCLASS> übereinstimmen, und enthält ein oder mehrere RRsets, die über Wildcard-Namenserweiterung mit <SNAME, SCLASS> übereinstimmen, enthält aber keine RRsets, die über Wildcard-Namenserweiterung mit <SNAME, SCLASS, STYPE> übereinstimmen.

3.1.3.1. Including NSEC RRs: No Data Response (Einbeziehung von NSEC-RRs: Keine-Daten-Antwort)​

Wenn die Zone RRsets enthält, die mit <SNAME, SCLASS> übereinstimmen, aber kein RRset enthält, das mit <SNAME, SCLASS, STYPE> übereinstimmt, dann muss (MUST) der Nameserver den NSEC-RR für <SNAME, SCLASS> zusammen mit seinen zugehörigen RRSIG-RRs im Authority-Abschnitt einschließen.

3.1.3.2. Including NSEC RRs: Name Error Response (Einbeziehung von NSEC-RRs: Namensfehler-Antwort)​

Wenn die Zone keine RRsets enthält, die mit <SNAME, SCLASS> entweder genau oder über Wildcard-Namenserweiterung übereinstimmen, dann muss (MUST) der Nameserver die folgenden NSEC-RRs im Authority-Abschnitt einschließen:

  • Einen NSEC-RR, der beweist, dass es keine genaue Übereinstimmung für <SNAME, SCLASS> gibt
  • Einen NSEC-RR, der beweist, dass die Zone keine RRsets enthält, die über Wildcard-Namenserweiterung mit <SNAME, SCLASS> übereinstimmen würden

3.1.3.3. Including NSEC RRs: Wildcard Answer Response (Einbeziehung von NSEC-RRs: Wildcard-Antwort-Response)​

Wenn die Zone keine RRsets enthält, die genau mit <SNAME, SCLASS> übereinstimmen, aber ein RRset enthält, das über Wildcard-Namenserweiterung mit <SNAME, SCLASS, STYPE> übereinstimmt, muss (MUST) der Nameserver die Wildcard-erweiterte Antwort und die entsprechenden Wildcard-erweiterten RRSIG-RRs im Answer-Abschnitt einschließen und muss (MUST) im Authority-Abschnitt einen NSEC-RR einschließen, der beweist, dass die Zone keine nähere Übereinstimmung enthält.

3.1.3.4. Including NSEC RRs: Wildcard No Data Response (Einbeziehung von NSEC-RRs: Wildcard-Keine-Daten-Antwort)​

Der Nameserver muss (MUST) die folgenden NSEC-RRs im Authority-Abschnitt einschließen:

  • Einen NSEC-RR, der beweist, dass es keine RRsets gibt, die mit STYPE am Wildcard-Besitzernamen übereinstimmen
  • Einen NSEC-RR, der beweist, dass es keine RRsets in der Zone gibt, die eine nähere Übereinstimmung gewesen wären

3.1.4. Including DS RRs in a Response (Einbeziehung von DS-RRs in eine Antwort)​

DS-RRs sind nur an Delegationspunkten vorhanden. Der DS-RR an einem Delegationspunkt etabliert die Authentifizierungskette in die Kindzone. Ein sicherheitsbewusster Nameserver, der eine Delegierung zurückgibt, muss (MUST) versuchen, das DS-RRset zusammen mit seinen zugehörigen RRSIG-RRs im Authority-Abschnitt zurückzugeben.

Wenn ein DS-RRset am Delegationspunkt nicht existiert, muss (MUST) der Nameserver einen NSEC-RR zurückgeben, der beweist, dass das DS-RRset nicht existiert.

3.1.5. Responding to Queries for Type AXFR or IXFR (Beantwortung von Abfragen des Typs AXFR oder IXFR)​

DNSSEC ändert das DNS-Zonentransferprotokoll nicht. Ein sicherheitsbewusster autoritativer Nameserver muss (MUST) die entsprechenden DNSSEC-RRs (RRSIG-, NSEC-, DS- und DNSKEY-RRs) in Zonentransfers einschließen.

3.1.6. The AD and CD Bits in an Authoritative Response (Die AD- und CD-Bits in einer autoritativen Antwort)​

Ein sicherheitsbewusster autoritativer Nameserver muss (MUST) das AD-Bit in Antworten löschen, es sei denn, der Nameserver ist sowohl für die Zone, die alle RRsets in den Answer- und Authority-Abschnitten enthält, autoritativ und alle notwendigen RRSIG- und NSEC-RRs sind enthalten.

Ein sicherheitsbewusster autoritativer Nameserver muss (MUST) das CD-Bit von der Abfrage in die Antwort kopieren.

3.2. Recursive Name Servers (Rekursive Nameserver)​

Ein sicherheitsbewusster rekursiver Nameserver ist eine Entität, die als sicherheitsbewusster Resolver (siehe Abschnitt 4) fungiert und auch sicherheitsbewussten Abfragedienst für andere Resolver oder Stub-Resolver bereitstellt.

3.2.1. The DO Bit (Das DO-Bit)​

Ein sicherheitsbewusster rekursiver Nameserver muss (MUST) das DO-Bit in Abfragen setzen, die er an autoritative Nameserver sendet, wenn das DO-Bit in der vom rekursiven Nameserver empfangenen Abfrage gesetzt war.

3.2.2. The CD Bit (Das CD-Bit)​

Das CD-Bit (Checking Disabled) steuert, ob ein sicherheitsbewusster rekursiver Nameserver DNSSEC-Validierung durchführt. Wenn das CD-Bit gesetzt ist, sollte (SHOULD NOT) ein sicherheitsbewusster rekursiver Nameserver keine DNSSEC-Validierung durchführen, sollte (SHOULD) aber dennoch DNSSEC-RRs abrufen.

3.2.3. The AD Bit (Das AD-Bit)​

Das AD-Bit (Authentic Data) zeigt an, ob die Daten in den Answer- und Authority-Abschnitten von einem sicherheitsbewussten Resolver gemäß den Richtlinien der lokalen Sicherheitsrichtlinie dieses Resolvers verifiziert wurden.

Ein sicherheitsbewusster rekursiver Nameserver muss (MUST) das AD-Bit in einer Antwort setzen, wenn:

  • Die RRsets in den Answer- und Authority-Abschnitten erfolgreich validiert wurden
  • Oder die Antwort mit gesetztem AD-Bit von einem vorgeschalteten Server empfangen wurde, dem vertraut wird

3.3. Example DNSSEC Responses (Beispiel-DNSSEC-Antworten)​

Anhang B enthält detaillierte Beispiele für DNSSEC-Antworten für verschiedene Szenarien, einschließlich:

  • Positive Antworten
  • Namensfehler
  • Keine-Daten-Fehler
  • Delegierungen zu signierten und unsignierten Zonen
  • Wildcard-Erweiterungen
Letztes Update am