4. Resolving (Auflösung)
Dieser Abschnitt beschreibt das Verhalten von Entitäten, die sicherheitsbewusste Resolver-Funktionen enthalten. In vielen Fällen werden solche Funktionen Teil eines sicherheitsbewussten rekursiven Nameservers sein.
4.1. EDNS Support (EDNS-Unterstützung)
Die Implementierungen sicherheitsbewusster Resolver müssen (MUST) die EDNS0-Nachrichtengrößenerweiterung unterstützen, müssen (MUST) eine Nachrichtengröße von mindestens 1220 Oktetten unterstützen und sollten (SHOULD) eine Nachrichtengröße von 4000 Oktetten unterstützen.
4.2. Signature Verification Support (Signaturverifizierungsunterstützung)
Ein sicherheitsbewusster Resolver muss (MUST) die in Abschnitt 5 beschriebenen Signaturverifizierungsmechanismen unterstützen und muss (MUST) sie auf jede empfangene Antwort anwenden, außer wenn:
- Der sicherheitsbewusste Resolver Teil eines sicherheitsbewussten rekursiven Nameservers ist und die Antwort das Ergebnis einer Rekursion im Namen einer Abfrage ist, die mit gesetztem CD-Bit empfangen wurde
- Die Antwort das Ergebnis einer Abfrage ist, die direkt über eine Form von Anwendungsschnittstelle generiert wurde, die den sicherheitsbewussten Resolver angewiesen hat, für diese Abfrage keine Validierung durchzuführen
- Die Validierung für diese Abfrage durch lokale Richtlinien deaktiviert wurde
Die Signaturverifizierungsunterstützung eines sicherheitsbewussten Resolvers muss (MUST) die Unterstützung der Verifizierung von Wildcard-Besitzernamen (Wildcard Owner Names) einschließen.
Sicherheitsbewusste Resolver können (MAY) für fehlende Sicherheits-RRs abfragen, um zu versuchen, die Validierung durchzuführen. Beim Versuch, fehlende NSEC-RRs abzurufen, die auf der elterlichen Seite eines Zonenschnitts residieren, muss (MUST) ein sicherheitsbewusster Resolver im iterativen Modus die Nameserver für die Elternzone abfragen, nicht die Kindzone.
Beim Versuch, einen fehlenden DS abzurufen, muss (MUST) ein sicherheitsbewusster Resolver im iterativen Modus die Nameserver für die Elternzone abfragen, nicht die Kindzone.
4.3. Determining Security Status of Data (Bestimmung des Sicherheitsstatus von Daten)
Ein sicherheitsbewusster Resolver muss (MUST) in der Lage sein zu bestimmen, ob er erwarten sollte, dass ein bestimmtes RRset signiert ist. Ein sicherheitsbewusster Resolver muss in der Lage sein, vier Fälle zu unterscheiden:
Secure (Sicher): Ein RRset, für das der Resolver in der Lage ist, eine Kette signierter DNSKEY- und DS-RRs von einem vertrauenswürdigen Sicherheitsanker zum RRset aufzubauen. In diesem Fall sollte das RRset signiert sein und unterliegt der Signaturvalidierung.
Insecure (Unsicher): Ein RRset, für das der Resolver weiß, dass er keine Kette signierter DNSKEY- und DS-RRs von einem vertrauenswürdigen Ausgangspunkt zum RRset hat. Dies kann auftreten, wenn das Ziel-RRset in einer unsignierten Zone oder in einem Nachfahren einer unsignierten Zone liegt. In diesem Fall kann das RRset signiert sein oder nicht, aber der Resolver wird nicht in der Lage sein, die Signatur zu verifizieren.
Bogus (Fehlerhaft): Ein RRset, für das der Resolver glaubt, dass er in der Lage sein sollte, eine Vertrauenskette zu etablieren, für das er dies jedoch nicht kann, entweder aufgrund von Signaturen, die aus irgendeinem Grund nicht validiert werden, oder aufgrund fehlender Daten, die laut den relevanten DNSSEC-RRs vorhanden sein sollten. Dieser Fall kann auf einen Angriff hinweisen, kann aber auch auf einen Konfigurationsfehler oder eine Form der Datenbeschädigung hinweisen.
Indeterminate (Unbestimmt): Ein RRset, für das der Resolver nicht in der Lage ist zu bestimmen, ob das RRset signiert sein sollte, da der Resolver nicht in der Lage ist, die notwendigen DNSSEC-RRs zu erhalten. Dies kann auftreten, wenn der sicherheitsbewusste Resolver nicht in der Lage ist, sicherheitsbewusste Nameserver für die relevanten Zonen zu kontaktieren.
4.4. Configured Trust Anchors (Konfigurierte Vertrauensanker)
Ein sicherheitsbewusster Resolver muss (MUST) in der Lage sein, mit mindestens einem vertrauenswürdigen öffentlichen Schlüssel oder DS-RR konfiguriert zu werden, und sollte (SHOULD) in der Lage sein, mit mehreren vertrauenswürdigen öffentlichen Schlüsseln oder DS-RRs konfiguriert zu werden.
Da ein sicherheitsbewusster Resolver ohne einen solchen konfigurierten Vertrauensanker nicht in der Lage sein wird, Signaturen zu validieren, sollte (SHOULD) der Resolver über einen einigermaßen robusten Mechanismus verfügen, um solche Schlüssel beim Booten zu erhalten.
4.5. Response Caching (Antwort-Caching)
Ein sicherheitsbewusster Resolver sollte (SHOULD) jede Antwort als einen einzigen atomaren Eintrag cachen, der die gesamte Antwort enthält, einschließlich des benannten RRsets und aller zugehörigen RRSIG-RRs und NSEC-RRs, unabhängig vom Sicherheitsstatus der Antwort.
Ein sicherheitsbewusster Resolver darf nicht (MUST NOT) RRSIG-RRs unabhängig von den RRsets cachen, die sie signieren, da dies einem Angreifer ermöglichen könnte, alte RRSIGs mit neuen Daten zu wiederholen.
4.6. Handling of the CD and AD Bits (Behandlung der CD- und AD-Bits)
Das CD-Bit steuert, ob ein sicherheitsbewusster Resolver die Validierung für eine bestimmte Abfrage durchführt. Ein sicherheitsbewusster Resolver muss (MUST) das AD-Bit in einer Antwort genau dann setzen, wenn der Resolver alle RRsets in den Answer- und Authority-Abschnitten der Antwort als authentisch betrachtet.
Ein Resolver, der nicht sicherheitsbewusst ist, darf nicht (MUST NOT) das AD-Bit in einer Antwort setzen. Ein sicherheitsbewusster Resolver darf nicht (MUST NOT) das AD-Bit setzen, es sei denn, er hat die Daten gemäß den in dieser Spezifikation beschriebenen Regeln validiert.
4.7. Caching BAD Data (Caching fehlerhafter Daten)
Ein Resolver kann (MAY) Daten mit einem „fehlerhaften" Sicherheitsstatus anders cachen als Daten mit einem „guten" Sicherheitsstatus. Ein Resolver darf jedoch nicht (MUST NOT) gecachte Daten mit einem fehlerhaften Sicherheitsstatus verwenden, es sei denn:
- Der Resolver antwortet auf eine Abfrage mit gesetztem CD-Bit
- Die fehlerhaften Daten waren das Ergebnis einer Abfrage mit gesetztem CD-Bit
- Die lokale Richtlinie autorisiert explizit die Verwendung fehlerhafter Daten
4.8. Synthesized CNAMEs (Synthetisierte CNAMEs)
Ein sicherheitsbewusster Resolver muss (MUST) spezielle Verarbeitungsregeln anwenden, wenn er synthetisierte CNAME-RRs behandelt, wie in [RFC2672] beschrieben. Der Resolver darf nicht (MUST NOT) erwarten, dass ein synthetisierter CNAME signiert ist, muss aber (MUST) den DNAME-RR validieren, aus dem der CNAME synthetisiert wurde.
4.9. Stub Resolvers (Stub-Resolver)
Ein sicherheitsbewusster Stub-Resolver ist eine Entität, die als DNS-Resolver fungiert und die Fähigkeit zur Signaturvalidierung besitzt, aber nicht als vollständiger sicherheitsbewusster rekursiver Nameserver fungiert. Stub-Resolver verlassen sich typischerweise auf einen rekursiven Nameserver, um die meisten DNS-Operationen in ihrem Namen durchzuführen.
4.9.1. Handling of the DO Bit (Behandlung des DO-Bits)
Ein sicherheitsbewusster Stub-Resolver sollte (SHOULD) das DO-Bit in Abfragen setzen, um anzuzeigen, dass er DNSSEC-RRs in der Antwort erhalten möchte.
4.9.2. Handling of the CD Bit (Behandlung des CD-Bits)
Ein sicherheitsbewusster Stub-Resolver kann (MAY) das CD-Bit in Abfragen setzen, um anzuzeigen, dass er bereit ist, die Validierung selbst durchzuführen, anstatt sich darauf zu verlassen, dass der Nameserver, an den er die Abfrage sendet, die Validierung in seinem Namen durchführt.
4.9.3. Handling of the AD Bit (Behandlung des AD-Bits)
Ein sicherheitsbewusster Stub-Resolver kann (MAY) die Einstellung des AD-Bits in einer Antwort verwenden, um anzuzeigen, ob der Nameserver, der die Antwort gesendet hat, die Daten im Namen des Stub-Resolvers validiert hat.
Ein sicherheitsbewusster Stub-Resolver, der das CD-Bit in einer Abfrage setzt, muss (MUST) das AD-Bit in der Antwort ignorieren, da der Nameserver explizit angewiesen wurde, keine Validierung im Namen des Stub-Resolvers durchzuführen.