8. Allgemeines DNSSEC

Die meisten DNSSEC-Begriffe sind in [RFC4033], [RFC4034], [RFC4035] und [RFC5155] definiert. Die Begriffe, die in der DNS-Community Verwirrung verursacht haben, werden hier hervorgehoben.

DNSSEC-bewusst und DNSSEC-unbewusst (DNSSEC-aware and DNSSEC-unaware): Diese beiden Begriffe, die in einigen RFCs verwendet werden, wurden nicht formal definiert. Allerdings definiert Abschnitt 2 von [RFC4033] viele Arten von Resolvern und Validatoren, einschließlich "non-validating security-aware stub resolver" (nicht-validierender sicherheitsbewusster Stub-Resolver), "non-validating stub resolver" (nicht-validierender Stub-Resolver), "security-aware name server" (sicherheitsbewusster Nameserver), "security-aware recursive name server" (sicherheitsbewusster rekursiver Nameserver), "security-aware resolver" (sicherheitsbewusster Resolver), "security-aware stub resolver" (sicherheitsbewusster Stub-Resolver) und "security-oblivious 'anything'" (sicherheitsunbewusstes 'alles'). (Beachten Sie, dass der Begriff "validating resolver" (validierender Resolver), der an einigen Stellen in DNSSEC-bezogenen Dokumenten verwendet wird, ebenfalls nicht definiert ist.)

Signierte Zone (Signed zone): "Eine Zone, deren RRsets signiert sind und die ordnungsgemäß konstruierte DNSKEY-, Resource Record Signature (RRSIG)-, Next Secure (NSEC)- und (optional) DS-Records enthält." (Zitiert aus [RFC4033], Abschnitt 2.) Es wurde in anderen Kontexten bemerkt, dass die Zone selbst nicht wirklich signiert ist, aber alle relevanten RRsets in der Zone signiert sind. Nichtsdestotrotz werden, wenn eine Zone, die signiert sein sollte, RRsets enthält, die nicht signiert sind (oder ausgenommen sind), diese RRsets als bogus behandelt, sodass die gesamte Zone auf irgendeine Weise gehandhabt werden muss.

Es sollte auch bemerkt werden, dass seit der Veröffentlichung von [RFC6840] NSEC-Records für signierte Zonen nicht mehr erforderlich sind: eine signierte Zone könnte stattdessen NSEC3-Records enthalten. [RFC7129] bietet zusätzlichen Hintergrundkommentar und etwas Kontext für die NSEC- und NSEC3-Mechanismen, die von DNSSEC verwendet werden, um authentifizierte Denial-of-Existence-Antworten bereitzustellen.

Unsignierte Zone (Unsigned zone): Abschnitt 2 von [RFC4033] definiert dies als "eine Zone, die nicht signiert ist". Abschnitt 2 von [RFC4035] definiert dies als "Eine Zone, die diese Records [ordnungsgemäß konstruierte DNSKEY-, Resource Record Signature (RRSIG)-, Next Secure (NSEC)- und (optional) DS-Records] gemäß den Regeln in diesem Abschnitt nicht enthält". Es gibt eine wichtige Anmerkung am Ende von Abschnitt 5.2 von [RFC4035], die eine zusätzliche Situation definiert, in der eine Zone als unsigniert betrachtet wird: "Wenn der Resolver keinen der in einem authentifizierten DS RRset aufgelisteten Algorithmen unterstützt, wird der Resolver nicht in der Lage sein, den Authentifizierungspfad zur Kind-Zone zu verifizieren. In diesem Fall SOLLTE der Resolver die Kind-Zone behandeln, als wäre sie unsigniert."

NSEC: "Der NSEC-Record ermöglicht es einem sicherheitsbewussten Resolver, eine negative Antwort für entweder Namen- oder Typ-Nichtexistenz mit denselben Mechanismen zu authentifizieren, die zur Authentifizierung anderer DNS-Antworten verwendet werden." (Zitiert aus [RFC4033], Abschnitt 3.2.) Kurz gesagt, ein NSEC-Record bietet authentifiziertes Denial of Existence.

"Der NSEC-Resource-Record listet zwei separate Dinge auf: den nächsten Owner-Namen (in der kanonischen Reihenfolge der Zone), der autoritative Daten oder ein Delegationspunkt-NS RRset enthält, und die Menge der RR-Typen, die am Owner-Namen des NSEC RR vorhanden sind." (Zitiert aus Abschnitt 4 von RFC 4034)

NSEC3: Wie der NSEC-Record bietet auch der NSEC3-Record authentifiziertes Denial of Existence; NSEC3-Records mildern jedoch Zonenenumeration ab und unterstützen Opt-Out. NSEC3-Resource-Records sind in [RFC5155] definiert.

Beachten Sie, dass [RFC6840] sagt, dass [RFC5155] "jetzt als Teil der DNS-Sicherheitsdokumentfamilie betrachtet wird, wie in Abschnitt 10 von [RFC4033] beschrieben". Dies bedeutet, dass einige der Definitionen aus früheren RFCs, die nur über NSEC-Records sprechen, wahrscheinlich als über sowohl NSEC als auch NSEC3 sprechend betrachtet werden sollten.

Opt-out (Ausschluss): "Das Opt-Out-Flag zeigt an, ob dieser NSEC3 RR unsignierte Delegationen abdecken kann." (Zitiert aus [RFC5155], Abschnitt 3.1.2.1.) Opt-out befasst sich mit den hohen Kosten der Sicherung einer Delegation zu einer unsicheren Zone. Bei Verwendung von Opt-Out benötigen Namen, die eine unsichere Delegation sind (und leere Non-Terminals, die nur von unsicheren Delegationen abgeleitet sind), keinen NSEC3-Record oder seine entsprechenden RRSIG-Records. Opt-Out-NSEC3-Records sind nicht in der Lage, die Existenz der unsicheren Delegationen zu beweisen oder zu leugnen. (Adaptiert aus [RFC7129], Abschnitt 5.1)

Zonenenumeration (Zone enumeration): "Die Praxis, den vollständigen Inhalt einer Zone durch aufeinanderfolgende Abfragen zu entdecken." (Zitiert aus [RFC5155], Abschnitt 1.3.) Dies wird auch manchmal "Zone Walking" genannt. Zonenenumeration unterscheidet sich von Zoneninhaltsraten, bei dem der Rater ein großes Wörterbuch möglicher Labels verwendet und aufeinanderfolgende Abfragen für sie sendet oder den Inhalt von NSEC3-Records gegen ein solches Wörterbuch abgleicht.

Key Signing Key (KSK - Schlüsselsignaturschlüssel): DNSSEC-Schlüssel, die "nur das Apex-DNSKEY RRset in einer Zone signieren." (Zitiert aus [RFC6781], Abschnitt 3.1)

Zone Signing Key (ZSK - Zonensignaturschlüssel): "DNSSEC-Schlüssel, die verwendet werden können, um alle RRsets in einer Zone zu signieren, die Signaturen erfordern, außer dem Apex-DNSKEY RRset." (Zitiert aus [RFC6781], Abschnitt 3.1) Beachten Sie, dass die Rollen KSK und ZSK sich nicht gegenseitig ausschließen: ein einzelner Schlüssel kann gleichzeitig sowohl KSK als auch ZSK sein. Beachten Sie auch, dass ein ZSK manchmal verwendet wird, um das Apex-DNSKEY RRset zu signieren.

Combined Signing Key (CSK - Kombinierter Signaturschlüssel): "In Fällen, in denen die Unterscheidung zwischen KSK und ZSK nicht gemacht wird, d.h. wo Schlüssel die Rolle sowohl von KSK als auch von ZSK haben, sprechen wir von einem Single-Type Signing Scheme." (Zitiert aus [RFC6781], Abschnitt 3.1) Dies wird manchmal "Combined Signing Key" oder CSK genannt. Es ist die betriebliche Praxis, nicht das Protokoll, die bestimmt, ob ein bestimmter Schlüssel ein ZSK, ein KSK oder ein CSK ist.

Secure Entry Point (SEP - Sicherer Eingangspunkt): Ein Flag im DNSKEY RDATA, das "verwendet werden kann, um zwischen Schlüsseln zu unterscheiden, die dazu bestimmt sind, als sicherer Eingangspunkt in die Zone beim Aufbau von Vertrauensketten verwendet zu werden, d.h. sie werden (oder werden) durch elterliche DS RRs angezeigt oder als Vertrauensanker konfiguriert. Daher wird vorgeschlagen, dass das SEP-Flag auf Schlüssel gesetzt wird, die als KSKs verwendet werden, und nicht auf Schlüssel, die als ZSKs verwendet werden, während in Fällen, in denen eine Unterscheidung zwischen einem KSK und ZSK nicht gemacht wird (d.h. für ein Single-Type Signing Scheme), vorgeschlagen wird, dass das SEP-Flag auf alle Schlüssel gesetzt wird." (Zitiert aus [RFC6781], Abschnitt 3.2.3.) Beachten Sie, dass das SEP-Flag nur ein Hinweis ist, und seine Anwesenheit oder Abwesenheit darf nicht verwendet werden, um einen gegebenen DNSKEY RR von der Verwendung als KSK oder ZSK während der Validierung zu disqualifizieren.

DNSSEC-Richtlinie (DP - DNSSEC Policy): Eine Erklärung, die "die Sicherheitsanforderungen und Standards festlegt, die für eine DNSSEC-signierte Zone implementiert werden sollen." (Zitiert aus [RFC6841], Abschnitt 2)

DNSSEC-Praxiserklärung (DPS - DNSSEC Practice Statement): "Ein Praxisoffenlegungsdokument, das die DNSSEC-Richtlinie unterstützen und ein ergänzendes Dokument dazu sein kann (falls vorhanden), und es besagt, wie die Verwaltung einer gegebenen Zone Verfahren und Kontrollen auf hoher Ebene implementiert." (Zitiert aus [RFC6841], Abschnitt 2)