Freigeben über

Übersicht über DNSSEC (Vorschau)

  • Artikel

Dieser Artikel bietet eine Übersicht über Domain Name System Security Extensions (DNSSEC) und enthält eine Einführung in die DNSSEC-Terminologie. Die Vorteile der DNSSEC-Zonensignierung werden beschrieben, und Sie erhalten Beispiele zum Anzeigen von DNSSEC-bezogenen Ressourceneinträgen. Wenn Sie bereit sind, Ihre Azure Public DNS-Zone zu signieren, lesen Sie die folgenden Schrittanleitungen:

Hinweis

Die DNSSEC-Zonensignierung befindet sich derzeit in der VORSCHAU.
Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

Was ist DNSSEC?

DNSSEC ist eine Sammlung von Erweiterungen, die die Sicherheit des Domain Name System (DNS)-Protokolls erhöhen, indem sie das Überprüfen der Echtheit von DNS-Antworten ermöglichen. DNSSEC stellt Ursprungsautorität, Datenintegrität und authentifizierte Bestätigung der Abwesenheit bereit. Mit DNSSEC ist das DNS-Protokoll weniger anfällig für bestimmte Angriffsformen, insbesondere DNS-Spoofingangriffe.

Die wichtigsten DNSSEC-Erweiterungen werden in den folgenden RFCs (Request for Comments) erläutert:

  • RFC 4033: DNS-Sicherheit – Einführung und Anforderungen
  • RFC 4034: Ressourceneinträge für die DNS-Sicherheitserweiterungen
  • RFC 4035: Protokolländerungen für die DNS-Sicherheitserweiterungen

Eine Zusammenfassung der DNSSEC-RFCs finden Sie unter RFC9364: DNS Security Extensions (DNSSEC).

Funktionsweise von DNSSEC

DNSSEC schützt DNS-Zonen mit einem als Zonensignierung bezeichneten Prozess. Durch das Signieren einer Zone mit DNSSEC wird eine Validierungsunterstützung hinzugefügt, ohne den grundlegenden Mechanismus von DNS-Abfragen und -Antworten zu ändern. Um eine Zone mit DNSSEC zu signieren, muss der primäre autoritative DNS-Server der Zone DNSSEC unterstützen.

Beim Signieren werden der Zone Ressourcendatensatzsignaturen (Resource Record Signatures, RRSIGs) und andere kryptografische Datensätze hinzugefügt. Die folgende Abbildung zeigt die DNS-Ressourceneinträge in der Zone „contoso.com“ vor und nach dem Signieren der Zone.

Diagramm: Hinzufügung von RRSIG-Einträgen zu einer Zone beim Signieren mit DNSSEC

Zur DNSSEC-Überprüfung von DNS-Antworten werden diese digitalen Signaturen in einer lückenlosen Vertrauenskette verwendet.

Hinweis

DNSSEC-bezogene Ressourceneinträge werden nicht im Azure-Portal angezeigt. Weitere Informationen finden Sie unter Anzeigen DNSSEC-bezogener Ressourceneinträge.

Warum sollte eine Zone mit DNSSEC signiert werden?

Die Signierung einer Zone mit DNSSEC ist zur Einhaltung einiger Sicherheitsrichtlinien erforderlich, z. B. SC-20: Sicherer Namens- und Adressauflösungsdienst.

Die DNSSEC-Überprüfung von DNS-Antworten kann gängige Arten von DNS-Hijacking-Angriffen (auch bekannt als DNS-Umleitung) verhindern. DNS-Hijacking liegt vor, wenn ein Clientgerät mithilfe falscher (gespoofter) DNS-Antworten zu einem böswilligen Server umgeleitet wird. DNS-Cachepoisoning ist eine gängige Methode zum Spoofen (Fälschen) von DNS-Antworten.

Ein Beispiel dafür, wie DNS-Hijacking funktioniert, ist in der folgenden Abbildung dargestellt.

Diagramm: Funktionsweise von DNS-Hijacking

Normale DNS-Auflösung:

  1. Ein Clientgerät sendet eine DNS-Abfrage für contoso.com an einen DNS-Server.
  2. Der DNS-Server antwortet mit einem DNS-Ressourceneintrag für contoso.com.
  3. Das Clientgerät fordert eine Antwort von contoso.com an.
  4. Die contoso.com-App oder der Webserver gibt eine Antwort an den Client zurück.

DNS-Hijacking

  1. Ein Clientgerät sendet eine DNS-Abfrage für contoso.com an einen DNS-Server, der Opfer eines Hijacking-Angriffs geworden ist.
  2. Der DNS-Server antwortet mit einem ungültigen (gespooften) DNS-Ressourceneintrag für contoso.com.
  3. Das Clientgerät fordert eine Antwort für contoso.com vom böswilligen Server an.
  4. Der böswillige Server gibt eine gespoofte Antwort an den Client zurück.

Der Typ des gespooften DNS-Ressourceneintrags hängt von der Art des DNS-Hijacking-Angriffs ab. Ein MX-Eintrag könnte gespooft werden, um Client-E-Mails umzuleiten, oder ein gespoofter Adresseintrag (A-Eintrag) könnte Clients an einen böswilligen Webserver weiterleiten.

DNSSEC verhindert DNS-Hijacking durch die Überprüfung von DNS-Antworten. Im hier dargestellten DNS-Hijacking-Szenario kann das Clientgerät nicht überprüfte DNS-Antworten ablehnen, wenn die Domäne „contoso.com“ mit DNSSEC signiert ist. Um nicht überprüfte DNS-Antworten abzulehnen, muss das Clientgerät die DNSSEC-Überprüfung für „contoso.com“ erzwingen.

DNSSEC enthält auch Next Secure 3 (NSEC3), um die Zonenenumeration zu verhindern. Die Zonenenumeration, auch als Zone Walking bezeichnet, ist ein Angriff, bei dem der Angreifer eine Liste aller Namen in einer Zone erstellt (einschließlich untergeordneter Zonen).

Machen Sie sich mit der Funktionsweise von DNSSEC vertraut, bevor Sie eine Zone mit DNSSEC signieren. Lesen Sie Signieren Ihrer Azure Public DNS-Zone mit DNSSEC, wenn Sie bereit sind, eine Zone zu signieren.

DNSSEC-Überprüfung

Ein DNSSEC-fähiger DNS-Server kann das DNSSEC OK (DO)-Flag in einer DNS-Abfrage auf den Wert 1 festlegen. Dieser Wert weist den antwortenden DNS-Server an, DNSSEC-bezogene Ressourceneinträge in die Antwort einzuschließen. Bei diesen DNSSEC-Einträgen handelt es sich um RRSIG-Einträge, die verwendet werden, um die Echtheit der DNS-Antwort zu überprüfen.

Ein rekursiver (nicht autoritativer) DNS-Server führt die DNSSEC-Überprüfung von RRSIG-Einträgen mithilfe eines Vertrauensankers (DNSKEY) durch. Der Server verwendet einen DNSKEY zum Entschlüsseln der digitalen Signaturen in RRSIG-Einträgen (und anderen DNSSEC-bezogenen Einträgen) und berechnet und vergleicht dann Hashwerte. Wenn die Hashwerte identisch sind, sendet er eine Antwort mit den angeforderten DNS-Daten an den DNS-Client, z. B. einen Hostressourceneintrag (A-Datensatz). Sehen Sie sich die folgende Abbildung an:

Diagramm: Funktionsweise der DNSSEC-Überprüfung

Wenn die Hashwerte nicht identisch sind, antwortet der rekursive DNS-Server mit einer SERVFAIL-Nachricht. Auf diese Weise können DNSSEC-fähige auflösende (oder weiterleitende) DNS-Server, auf denen ein gültiger Vertrauensanker installiert ist, DNS-Hijacking auf dem Pfad zwischen dem rekursiven Server und dem autoritativen Server verhindern. Dieser Schutz erfordert nicht, dass DNS-Clientgeräte DNSSEC-fähig sind oder die DNS-Antwortüberprüfung erzwingen, sofern der lokale rekursive DNS-Server (letzter Hop) selbst vor Hijacking geschützt ist.

Windows 10- und Windows 11-Clientgeräte sind nicht validierende Stub Resolver mit Sicherheitsunterstützung. Diese Clientgeräte führen keine Überprüfung durch, können aber die DNSSEC-Überprüfung mithilfe von Gruppenrichtlinien erzwingen. Die Richtlinientabelle für die Namensauflösung (Name Resolution Policy Table, NRPT) kann verwendet werden, um namespacebasierte DNSSEC-Überprüfungsrichtlinien zu erstellen und zu erzwingen.

Vertrauensanker und DNSSEC-Überprüfung

Hinweis

Die DNSSEC-Antwortüberprüfung wird nicht vom Standardkonfliktlöser ausgeführt, der von Azure bereitgestellt wird. Die Informationen in diesem Abschnitt sind hilfreich, wenn Sie Ihre eigenen rekursiven DNS-Server für die DNSSEC-Überprüfung einrichten oder Probleme bei der Überprüfung beheben möchten.

Vertrauensanker arbeiten auf der Grundlage der DNS-Namespacehierarchie. Ein rekursiver DNS-Server kann eine beliebige Anzahl von Vertrauensankern oder auch keine Vertrauensanker aufweisen. Vertrauensanker können für eine einzelne untergeordnete DNS-Zone oder eine beliebige übergeordnete Zone hinzugefügt werden. Wenn ein rekursiver DNS-Server über einen Stammvertrauensanker (.) verfügt, kann er die DNSSEC-Überprüfung für jede DNS-Zone durchführen. Weitere Informationen finden Sie unter Root Zone Operator Information (Informationen für Stammzonenoperatoren).

Beim DNSSEC-Überprüfungsprozess werden wie folgt Vertrauensanker verwendet:

  • Wenn ein rekursiver DNS-Server nicht über einen DNSSEC-Vertrauensanker für eine Zone oder den übergeordneten hierarchischen Namespace der Zone verfügt, führt er keine DNSSEC-Überprüfung für diese Zone durch.
  • Wenn ein rekursiver DNS-Server über einen DNSSEC-Vertrauensanker für den übergeordneten Namespace einer Zone verfügt und eine Abfrage für die untergeordnete Zone empfängt, überprüft er, ob ein DS-Eintrag (Delegation Signer, Delegierungssignaturgeber) für die untergeordneten Zonen in der übergeordneten Zone vorhanden ist.
    • Wenn der DS-Eintrag gefunden wird, führt der rekursive DNS-Server die DNSSEC-Überprüfung durch.
    • Wenn der rekursive DNS-Server feststellt, dass die übergeordnete Zone nicht über einen DS-Eintrag für die untergeordnete Zone verfügt, geht er davon aus, dass die untergeordnete Zone unsicher ist, und er führt keine DNSSEC-Überprüfung durch.
  • Wenn mehrere rekursive DNS-Server an einer DNS-Antwort (einschließlich Weiterleitungen) beteiligt sind, muss jeder Server in der Lage sein, die DNSSEC-Überprüfung für die Antwort durchzuführen, damit die Vertrauenskette lückenlos ist.
  • Rekursive Server, auf denen die DNSSEC-Überprüfung deaktiviert ist oder die nicht DNSSEC-fähig sind, führen keine Überprüfung durch.

Vertrauenskette

Eine Vertrauenskette besteht, wenn alle DNS-Server, die am Senden einer Antwort für eine DNS-Abfrage beteiligt sind, validieren können, dass die Antwort während der Übertragung nicht verändert wurde. Damit die DNSSEC-Überprüfung End-to-End funktioniert, muss die Vertrauenskette lückenlos sein. Diese Vertrauenskette gilt sowohl für autoritative als auch nicht autoritative (rekursive) Server.

Autoritative Server

Autoritative DNS-Server erhalten eine Vertrauenskette durch die Verwendung von DS-Einträgen aufrecht. DS-Einträge werden verwendet, um die Echtheit von untergeordneten Zonen in der DNS-Hierarchie zu bestätigen.

  • Damit die DNSSEC-Überprüfung für eine signierte Zone erfolgen kann, muss die übergeordnete Zone ebenfalls signiert sein. Die übergeordnete Zone muss auch über einen DS-Eintrag für die untergeordnete Zone verfügen.
  • Während des Überprüfungsprozesses wird der DS-Eintrag von der übergeordneten Zone abgefragt. Wenn der DS-Eintrag nicht vorhanden ist oder die Daten des DS-Eintrags in der übergeordneten Zone nicht mit den DNSKEY-Daten in der untergeordneten Zone übereinstimmen, ist die Vertrauenskette unterbrochen und die Überprüfung schlägt fehl.

Rekursive Server

Rekursive DNS-Server (auch als auflösende oder zwischenspeichernde DNS-Server bezeichnet) erhalten eine Vertrauenskette mithilfe von DNSSEC-Vertrauensankern aufrecht.

  • Der Vertrauensanker ist ein DNSKEY- oder DS-Eintrag, der einen Hash eines DNSKEY-Eintrags enthält. Der DNSKEY-Eintrag wird auf einem autoritativen Server erstellt, wenn eine Zone signiert wird, und aus der Zone entfernt, wenn die Signatur der Zone aufgehoben wird.
  • Vertrauensanker müssen manuell auf rekursiven DNS-Servern installiert werden.
  • Wenn ein Vertrauensanker für eine übergeordnete Zone vorhanden ist, kann ein rekursiver Server alle untergeordneten Zonen im hierarchischen Namespace überprüfen. Dies umfasst auch weitergeleitete Abfragen. Um die DNSSEC-Überprüfung aller mit DNSSEC signierten DNS-Zonen zu unterstützen, können Sie einen Vertrauensanker für die Stammzone (.) installieren.

Schlüsselrollover

Für den Zonensignaturschlüssel (Zone Signing Key, ZSK) in einer mit DNSSEC signierten Zone führt Azure in regelmäßigen Abständen automatisch ein Rollover aus, d. h. der Schlüssel wird ersetzt. Es sollte nicht erforderlich sein, Ihren Schlüsselsignaturschlüssel (Key Signing Key, KSK) zu ersetzen, diese Option ist jedoch über den Microsoft-Support verfügbar. Das Ersetzen des KSK erfordert, dass Sie auch Ihren DS-Eintrag in der übergeordneten Zone aktualisieren.

Algorithmus für die Zonensignierung

Zonen werden unter Verwendung des Elliptic Curve Digital Signature Algorithm (ECDSAP256SHA256) mit DNSSEC signiert.

Die folgende Tabelle enthält eine kurze Beschreibung der DNSSEC-bezogenen Einträge. Ausführlichere Informationen finden Sie unter RFC 4034: Ressourceneinträge für die DNS-Sicherheitserweiterungen und RFC 7344: Automating DNSSEC Delegation Trust Maintenance (Automatisieren der Vertrauensstellungsverwaltung für die DNSSEC-Delegierung).

Datensatz Beschreibung
Ressourcendatensatzsignatur (RRSIG) Ein DNSSEC-Ressourceneintragstyp, der zum Speichern einer Signatur verwendet wird, die eine Reihe von DNS-Einträgen für einen bestimmten Namen und Typ abdeckt.
DNSKEY Ein DNSSEC-Ressourceneintragstyp, der zum Speichern eines öffentlichen Schlüssels verwendet wird.
Delegierungssignaturgeber (DS) Ein DNSSEC-Ressourceneintragstyp, der zum Schützen einer Delegierung verwendet wird.
Next Secure (NSEC) Ein DNSSEC-Ressourceneintragstyp, der zum Nachweisen des Nichtvorhandenseins eines DNS-Namens verwendet wird.
Next Secure 3 (NSEC3) Der NSEC3-Ressourceneintrag, der einen Hashwert für die authentifizierte Bestätigung der Abwesenheit für DNS-Ressourceneintragssätze bereitstellt.
Next Secure 3-Parameter (NSEC3PARAM) Gibt Parameter für NSEC3-Einträge an.
Untergeordneter Delegierungssignaturgeber (Child Delegation Signer, CDS) Dieser Eintrag ist optional. Wenn er vorhanden ist, kann der CDS-Eintrag von einer untergeordneten Zone verwendet werden, um den gewünschten Inhalt des DS-Eintrags in einer übergeordneten Zone anzugeben.
Untergeordneter DNSKEY (CDNSKEY) Dieser Eintrag ist optional. Wenn der CDNSKEY-Eintrag in einer untergeordneten Zone vorhanden ist, kann er verwendet werden, um einen DS-Eintrag aus einem DNSKEY-Eintrag zu generieren.

DNSSEC-bezogene Einträge werden nicht im Azure-Portal angezeigt. Verwenden Sie Befehlszeilentools wie Resolve-DnsName oder „dig.exe“, um DNSSEC-bezogene Einträge anzuzeigen. Diese Tools sind bei der Verwendung von Cloud Shell oder lokal verfügbar, wenn sie auf Ihrem Gerät installiert sind. Stellen Sie sicher, dass Sie das DO-Flag in Ihrer Abfrage mithilfe der Option -dnssecok in Resolve-DnsName bzw. der Option +dnssec in „dig.exe“ festlegen.

Wichtig

Verwenden Sie nicht das Befehlszeilentool „nslookup.exe“, um DNSSEC-bezogene Einträge abzufragen. Das Tool „nslookup.exe“ verwendet einen internen DNS-Client, der nicht DNSSEC-fähig ist.

Hierzu folgende Beispiele:

PS C:\> resolve-dnsname server1.contoso.com -dnssecok

Name                                      Type   TTL   Section    IPAddress
----                                      ----   ---   -------    ---------
server1.contoso.com                        A     3600  Answer     203.0.113.1

Name        : server1.contoso.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : A
Algorithm   : 13
LabelCount  : 3
OriginalTtl : 3600
Expiration  : 9/20/2024 11:25:54 PM
Signed      : 9/18/2024 9:25:54 PM
Signer      : contoso.com
Signature   : {193, 20, 122, 196…}

C:\>dig server1.contoso.com +dnssec

; <<>> DiG 9.9.2-P1 <<>> server1.contoso.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61065
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;server1.contoso.com.       IN      A

;; ANSWER SECTION:
server1.contoso.com. 3600   IN      A       203.0.113.1
server1.contoso.com. 3600   IN      RRSIG   A 13 3 3600 20240920232359 20240918212359 11530 contoso.com. GmxeQhNk1nJZiep7nuCS2qmOQ+Ffs78Z2eoOgIYP3j417yqwS1DasfA5 e1UZ4HuujDk2G6GIbs0ji3RiM9ZpGQ==

;; Query time: 153 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 15:23:45 2024
;; MSG SIZE  rcvd: 179

PS C:\> resolve-dnsname contoso.com -Type dnskey -dnssecok

Name                                 Type   TTL   Section    Flags  Protocol Algorithm      Key
----                                 ----   ---   -------    -----  -------- ---------      ---
contoso.com                          DNSKEY 3600  Answer     256    DNSSEC   13             {115, 117, 214,
                                                                                                165…}
contoso.com                          DNSKEY 3600  Answer     256    DNSSEC   13             {149, 166, 55, 78…}
contoso.com                          DNSKEY 3600  Answer     257    DNSSEC   13             {45, 176, 217, 2…}

Name        : contoso.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : DNSKEY
Algorithm   : 13
LabelCount  : 2
OriginalTtl : 3600
Expiration  : 11/17/2024 9:00:15 PM
Signed      : 9/18/2024 9:00:15 PM
Signer      : contoso.com
Signature   : {241, 147, 134, 121…}

C:\>dig contoso.com dnskey

; <<>> DiG 9.9.2-P1 <<>> contoso.com dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46254
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;contoso.com.               IN      DNSKEY

;; ANSWER SECTION:
contoso.com.        3600    IN      DNSKEY  256 3 13 laY3Toc/VTyjupgp/+WgD05N+euB6Qe1iaM/253k7bkaA0Dx+gSDhbH2 5wXTt+uLQgPljL9OusKTneLdhU+1iA==
contoso.com.        3600    IN      DNSKEY  257 3 13 LbDZAtjG8E9Ftih+LC8CqQrSZIJFFJMtP6hmN3qBRqLbtAj4JWtr2cVE ufXM5Pd/yW+Ca36augQDucd5n4SgTg==
contoso.com.        3600    IN      DNSKEY  256 3 13 c3XWpTqZ0q9IO+YqMEtOBHZSzGGeyFKq0+3xzs6tifvD1rey1Obhrkz4 DJlEIxy2m84VsG1Ij9VYdtGxxeVHIQ==

;; Query time: 182 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 16:35:10 2024
;; MSG SIZE  rcvd: 284

DNSSEC-Terminologie

In dieser Liste werden einige der gebräuchlichen Begriffe im Zusammenhang mit DNSSEC erläutert. Siehe auch: DNSSEC-bezogene Ressourceneinträge

Begriff Beschreibung
AD-Bit (Bit für authentifizierte Daten) Ein Datenbit in einer Antwort, das anzeigt, dass der DNS-Server alle Daten in den Answer- und Authority-Abschnitten der Antwort gemäß seinen Richtlinien überprüft hat.
Authentifizierungskette Eine Kette signierter und überprüfter DNS-Einträge, die von einem vorkonfigurierten Vertrauensanker bis zu einer untergeordneten Zone in der DNS-Struktur reicht.
DNS-Erweiterung (EDNS0) Ein DNS-Eintrag, der erweiterte DNS-Headerinformationen enthält, z. B. das DO-Bit und die maximale UDP-Paketgröße.
DNS Security Extensions (DNSSEC) Erweiterungen des DNS-Diensts, die Mechanismen zum Signieren und sicheren Auflösen von DNS-Daten bereitstellen.
DNSSEC OK (DO)-Bit Ein Bit im EDNS0-Teil einer DNS-Anforderung, das anzeigt, dass der Client DNSSEC-fähig ist.
DNSSEC-Überprüfung Bei der DNSSEC-Überprüfung werden der Ursprung und die Integrität von DNS-Daten mithilfe öffentlicher Kryptografieschlüssel überprüft.
Sicherheitsinsel (Island of Security) Eine signierte Zone, die nicht über eine Authentifizierungskette von der delegierenden übergeordneten Zone verfügt.
Schlüsselsignaturschlüssel (KSK) Ein Authentifizierungsschlüssel, der einem privaten Schlüssel entspricht, der zum Signieren von mindestens einem anderen Signaturschlüssel für eine bestimmte Zone verwendet wird. Normalerweise signiert der private Schlüssel, der einem KSK entspricht, einen Zonensignaturschlüssel (ZSK), der wiederum über einen entsprechenden privaten Schlüssel zum Signieren anderer Zonendaten verfügt. Lokale Richtlinien können erfordern, dass der ZSK häufig geändert wird, während der KSK eine längere Gültigkeitsdauer haben kann, um einen stabileren, sicheren Einstiegspunkt für die Zone bereitzustellen. Das Zuweisen eines Authentifizierungsschlüssels als KSK ist eine rein operative Frage: Die DNSSEC-Überprüfung unterscheidet nicht zwischen KSKs und anderen DNSSEC-Authentifizierungsschlüsseln. Es ist möglich, einen einzelnen Schlüssel sowohl als KSK als auch als ZSK zu verwenden.
Nicht validierender Stub Resolver mit Sicherheitsunterstützung Ein Stub Resolver mit Sicherheitsunterstützung, der einem oder mehreren DNS-Servern mit Sicherheitsunterstützung vertraut, die die DNSSEC-Überprüfung in seinem Namen durchführen.
Schlüssel für einen sicheren Einstiegspunkt (Secure Entry Point, SEP) Eine Teilmenge öffentlicher Schlüssel im DNSKEY-Ressourceneintragssatz (Resource Record Set, RRSet). Ein SEP-Schlüssel wird entweder zum Generieren eines DS-Ressourceneintrags verwendet, oder er wird an Konfliktlöser verteilt, die den Schlüssel als Vertrauensanker verwenden.
DNS-Server mit Sicherheitsunterstützung Ein DNS-Server, der die in den RFCs 4033 [5], 4034 [6] und 4035 [7] definierten DNS-Sicherheitserweiterungen implementiert. Insbesondere ist ein DNS-Server mit Sicherheitsunterstützung eine Entität, die DNS-Abfragen empfängt und DNS-Antworten sendet sowie die EDNS0 [3]-Nachrichtengrößenerweiterung, das DO-Bit und die DNSSEC-Eintragstypen und -Nachrichtenkopfbits unterstützt.
Signierte Zone Eine Zone, deren Einträge gemäß RFC 4035 [7] Abschnitt 2 signiert sind. Eine signierte Zone kann DNSKEY-, NSEC-, NSEC3-, NSEC3PARAM-, RRSIG- und DS-Ressourceneinträge enthalten. Anhand dieser Ressourceneinträge können DNS-Daten von Konfliktlösern überprüft werden.
Vertrauensanker Ein vorkonfigurierter öffentlicher Schlüssel, der einer bestimmten Zone zugeordnet ist. Ein Vertrauensanker ermöglicht es einem DNS-Konfliktlöser, signierte DNSSEC-Ressourceneinträge für diese Zone zu überprüfen und Authentifizierungsketten für untergeordnete Zonen zu erstellen.
Nicht signierte Zone Eine beliebige DNS-Zone, die nicht gemäß RFC 4035 [7] Abschnitt 2 signiert wurde.
Zonensignierung Bei der Zonensignierung werden DNSSEC-bezogene Ressourceneinträge erstellt und einer Zone hinzugefügt, damit diese mit der DNSSEC-Überprüfung kompatibel ist.
Aufheben der Zonensignatur Beim Aufheben der Signatur einer Zone werden DNSSSEC-bezogene Ressourceneinträge aus einer Zone entfernt, sodass sie wieder den Status „Unsigniert“ aufweist.
Zonensignaturschlüssel (ZSK) Ein Authentifizierungsschlüssel, der einem privaten Schlüssel entspricht, der zum Signieren einer Zone verwendet wird. In der Regel ist ein Zonensignaturschlüssel Teil desselben DNSKEY-Ressourceneintrags wie der Schlüsselsignaturschlüssel, dessen entsprechender privater Schlüssel den DNSKEY-Ressourceneintrag signiert. Der Zonensignaturschlüssel wird jedoch für andere Zwecke verwendet und kann sich auf andere Weise vom Schlüsselsignaturschlüssel unterscheiden, z. B. hinsichtlich der Gültigkeitsdauer. Das Zuweisen eines Authentifizierungsschlüssels als Zonensignaturschlüssel ist eine rein operative Frage: Die DNSSEC-Überprüfung unterscheidet nicht zwischen Zonensignaturschlüsseln und anderen DNSSEC-Authentifizierungsschlüsseln. Es ist möglich, einen einzelnen Schlüssel sowohl als Schlüsselsignaturschlüssel als auch als Zonensignaturschlüssel zu verwenden.

Nächste Schritte