Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Konfigurieren der DNSSEC-Signatur in Amazon Route 53 DNSSEC-Signatur (Domain Name System Security Extensions) ermöglicht DNS-Resolvern zu überprüfen, ob eine DNS-Antwort von Amazon Route 53 stammt und nicht manipuliert wurde. Wenn Sie die DNSSEC-Signatur verwenden, wird jede Antwort für eine gehostete Zone mithilfe der Kryptografie mit öffentlichen Schlüsseln signiert. Einen Überblick über DNSSEC finden Sie im Abschnitt DNSSEC von [AWS re:Invent 2021 — Amazon Route 53](https://www.youtube.com/watch?v=77V23phAaAE): Ein Jahr im Rückblick. In diesem Kapitel erklären wir, wie Sie die DNSSEC-Signatur für Route 53 aktivieren, wie Sie mit Schlüsselsignaturschlüsseln () arbeiten und wie Sie Probleme beheben können. KSKs Sie können mit der DNSSEC-Signatur in der oder programmgesteuert mit der AWS-Managementkonsole API arbeiten. Weitere Informationen zur Verwendung der CLI oder SDKs zur Arbeit mit Route 53 finden Sie unter[Amazon Route 53 einrichten](setting-up-route-53.md). Bevor Sie DNSSEC-Signatur aktivieren, beachten Sie Folgendes: + Um einen Zonenausfall zu verhindern und Probleme mit der Nichtverfügbarkeit Ihrer Domäne zu vermeiden, müssen Sie DNSSEC-Fehler schnell beheben und beheben. Es wird dringend empfohlen, einen CloudWatch Alarm einzurichten, der Sie benachrichtigt, wenn ein `DNSSECInternalFailure` `DNSSECKeySigningKeysNeedingAction` Oder-Fehler erkannt wird. Weitere Informationen finden Sie unter [Überwachung von Hosting-Zonen mit Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). + Es gibt zwei Arten von Schlüsseln in DNSSEC: einen Schlüssel-Signaturschlüssel (KSK) und einen Zonen-Signaturschlüssel (ZSK). Bei der DNSSEC-Signierung von Route 53 basiert jede KSK auf einem[Asymmetrische kundenverwaltete Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept)in AWS KMS dass Sie besitzen. Sie sind für das Management von KSK verantwortlich, was bei Bedarf auch das Drehen beinhaltet. Das ZSK-Management wird von der Route 53 durchgeführt. + Wenn Sie DNSSEC-Signierung für eine gehostete Zone aktivieren, begrenzt Route 53 die TTL auf eine Woche. Wenn Sie eine TTL von mehr als einer Woche für Datensätze in der gehosteten Zone festlegen, wird keine Fehlermeldung angezeigt. Route 53 erzwingt jedoch eine TTL von einer Woche für die Datensätze. Datensätze mit einer TTL von weniger als einer Woche und Datensätze in anderen gehosteten Zonen, für die keine DNSSEC-Signatur aktiviert ist, sind nicht betroffen. + Wenn Sie DNSSEC-Signatur verwenden, werden Konfigurationen verschiedener Anbieter nicht unterstützt. Wenn Sie White-Label-Nameserver (auch bekannt als Vanity-Nameserver oder Private-Nameserver) konfiguriert haben, stellen Sie sicher, dass diese Nameserver von einem einzigen DNS-Anbieter bereitgestellt werden. + Einige DNS-Anbieter unterstützen keine Delegation Signer (DS) -Einträge in ihrem autorisierenden DNS. Wenn Ihre übergeordnete Zone von einem DNS-Anbieter gehostet wird, der keine DS-Abfragen unterstützt (kein AA-Flag in der DS-Abfrageantwort setzt), kann die untergeordnete Zone nicht mehr aufgelöst werden, wenn Sie DNSSEC in seiner untergeordneten Zone aktivieren. Stellen Sie sicher, dass Ihr DNS-Anbieter DS-Einträge unterstützt. + Es kann hilfreich sein, IAM-Berechtigungen einzurichten, damit ein anderer Benutzer neben dem Zonenbesitzer Datensätze in der Zone hinzufügen oder entfernen kann. Ein Zonenbesitzer kann beispielsweise eine KSK hinzufügen und die Signatur aktivieren und möglicherweise auch für die Schlüsselrotation verantwortlich sein. Möglicherweise ist eine andere Person jedoch für die Arbeit mit anderen Datensätzen für die gehostete Zone verantwortlich. Eine IAM-Beispielrichtlinie finden Sie unter [Beispielberechtigungen für einen Domänendatensatzbesitzer](access-control-managing-permissions.md#example-permissions-record-owner). + Informationen darüber, ob die TLD DNSSEC-Unterstützung bietet, finden Sie unter. [Domains, die Sie mit Amazon Route 53 registrieren können](registrar-tld-list.md) **Topics** + [Aktivieren der DNSSEC-Signierung und Aufbau einer Vertrauenskette](dns-configuring-dnssec-enable-signing.md) + [Deaktivieren der DNSSEC-Signatur](dns-configuring-dnssec-disable.md) + [Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC](dns-configuring-dnssec-cmk-requirements.md) + [Arbeiten mit Schlüsseln zur Schlüsselsignierung () KSKs](dns-configuring-dnssec-ksk.md) + [KMS-Schlüssel- und ZSK-Verwaltung in Route 53](dns-configuring-dnssec-zsk-management.md) + [DNSSEC-Nachweise für Nichtvorhandensein in Route 53](dns-configuring-dnssec-proof-of-nonexistence.md) + [Fehlerbehebung für DNSSEC](dns-configuring-dnssec-troubleshoot.md) # Aktivieren der DNSSEC-Signierung und Aufbau einer Vertrauenskette **** Die inkrementellen Schritte gelten für den Besitzer der gehosteten Zone und den übergeordneten Zonenbetreuer. Dies kann dieselbe Person sein, aber falls nicht, sollte der Zonenbesitzer den übergeordneten Zonenbetreuer benachrichtigen und mit ihm arbeiten. Wir empfehlen, die Schritte in diesem Artikel zu befolgen, damit Ihre Zone signiert und in die Vertrauenskette aufgenommen wird. Die folgenden Schritte minimieren das Risiko des Onboardings auf DNSSEC. **Anmerkung** Stellen Sie sicher, dass Sie die Voraussetzungen lesen, bevor Sie in [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md) beginnen. Es müssen drei Schritte durchgeführt werden, um die DNSSEC-Signatur zu aktivieren, indem Sie wie in den folgenden Abschnitten beschrieben vorgehen. **Topics** + [Schritt 1: Vorbereiten der Aktivierung der DNSSEC-Signatur](#dns-configuring-dnssec-enable-signing-step-1) + [Schritt 2: Aktivieren der DNSSEC-Signatur und Erstellen einer KSK](#dns-configuring-dnssec-enable) + [Schritt 3: Erstellen einer Vertrauenskette](#dns-configuring-dnssec-chain-of-trust) ## Schritt 1: Vorbereiten der Aktivierung der DNSSEC-Signatur Die Vorbereitungsschritte helfen Ihnen, das Risiko eines Onboardings bei DNSSEC zu minimieren, indem Sie die Zonenverfügbarkeit überwachen und die Wartezeiten zwischen dem Aktivieren der Signierung und dem Einfügen des Delegation Signer (DS)-Datensatzes senken. **So bereiten Sie sich auf das Aktivieren der DNSSEC-Signierung vor** 1. Überwachen Sie die Verfügbarkeit der Zone. Sie können die Zone auf die Verfügbarkeit Ihrer Domänennamen überwachen. Dies kann Ihnen helfen, alle Probleme zu beheben, die einen Schritt zurücksetzen könnten, nachdem Sie die DNSSEC-Signatur aktiviert haben. Sie können Ihre Domänennamen mit dem größten Datenverkehr überwachen, indem Sie die Abfrageprotokollierung verwenden. Für weitere Informationen zum Einrichten einer Abfrage-Protokollierung siehe [Amazon Route 53 überwachen](monitoring-overview.md). Die Überwachung kann über ein Shell-Skript oder über einen Drittanbieterdienst erfolgen. Dies sollte jedoch nicht das einzige Signal sein, um festzustellen, ob ein Rollback erforderlich ist. Möglicherweise erhalten Sie auch Feedback von Ihren Kunden, da eine Domäne nicht verfügbar ist. 1. Senken Sie die maximale TTL der Zone. Die maximale TTL der Zone ist der längste TTL-Datensatz in der Zone. In der folgenden Beispielzone beträgt die maximale TTL der Zone 1 Tag (86 400 Sekunden). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) Die Senkung der maximalen TTL der Zone trägt dazu bei, die Wartezeit zwischen dem Aktivieren der Signatur und dem Einfügen des Delegation Signer (DS)-Datensatzes zu verkürzen. Wir empfehlen, die maximale TTL der Zone auf eine Stunde (3 600 Sekunden) zu senken. Auf diese Weise können Sie sie nach nur einer Stunde zurücksetzen, wenn ein Resolver Probleme beim Zwischenspeichern signierter Datensätze hat. **Rollback:** Machen Sie die TTL-Änderungen rückgängig. 1. Senken Sie das SOA-TTL- und SOA-Mindestfeld. Das SOA-Mindestfeld ist das letzte Feld in den SOA-Datensatzdaten. Im folgenden SOA-Beispieldatensatz hat das Mindestfeld den Wert 5 Minuten (300 Sekunden). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) Das SOA-TTL- und SOA-Mindestfeld bestimmt, wie lange Resolver sich an negative Antworten erinnern. Nachdem Sie die Signierung aktiviert haben, geben die Nameserver der Route 53 NSEC-Datensätze für negative Antworten zurück. Die NSEC enthält Informationen, die Resolver verwenden könnten, um eine negative Antwort zu synthetisieren. Wenn Sie ein Rollback durchführen müssen, weil die NSEC-Informationen dazu geführt haben, dass ein Resolver eine negative Antwort für einen Namen annimmt, müssen Sie nur auf das Maximum des SOA-TTL- und SOA-Mindestfeldes warten, damit der Resolver die Annahme stoppt. **Rollback:** Machen Sie die SOA-Änderungen rückgängig. 1. Stellen Sie sicher, dass die Änderungen an den Mindestfeldern TTL und SOA wirksam sind. Verwenden Sie diese [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)Option, um sicherzustellen, dass Ihre bisherigen Änderungen an alle Route 53-DNS-Server weitergegeben wurden. ## Schritt 2: Aktivieren der DNSSEC-Signatur und Erstellen einer KSK Sie können die DNSSEC-Signatur aktivieren und einen Schlüsselsignierungsschlüssel (KSK) erstellen, indem Sie AWS CLI oder die Route 53-Konsole verwenden. + [CLI](#dnssec_CLI) + [Konsole](#dnssec_console) Wenn Sie einen KMS-Schlüssel bereitstellen oder erstellen, gibt es mehrere Anforderungen. Weitere Informationen finden Sie unter [Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC](dns-configuring-dnssec-cmk-requirements.md). ------ #### [ CLI ] Sie können einen Schlüssel verwenden, den Sie bereits zur Verfügung haben, oder Sie erstellen einen, indem Sie einen AWS CLI -Befehl wie den folgenden mit eigenen Werten für `hostedzone_id`, `cmk_arn`, `ksk_name`, und `unique_string` (um die Anfrage eindeutig zu machen) verwenden: ``` aws --region us-east-1 route53 create-key-signing-key \ --hosted-zone-id $hostedzone_id \ --key-management-service-arn $cmk_arn --name $ksk_name \ --status ACTIVE \ --caller-reference $unique_string ``` Weitere Informationen zu den vom Kunden verwalteten Schlüsseln finden Sie unter [Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC](dns-configuring-dnssec-cmk-requirements.md). Siehe auch [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html). Um die DNSSEC-Signatur zu aktivieren, führen Sie einen AWS CLI Befehl wie den folgenden aus und verwenden Sie dabei Ihren eigenen Wert für: `hostedzone_id` ``` aws --region us-east-1 route53 enable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id ``` [Weitere Informationen finden Sie unter [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html)und EnableHostedZone DNSSEC.](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) ------ #### [ Console ] **So aktivieren Sie die DNSSEC-Signatur und erstellen eine KSK** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Wählen Sie im Navigationsbereich**Gehostete Zonen**Wählen Sie dann eine gehostete Zone aus, für die Sie die DNSSEC-Signatur aktivieren möchten. 1. Klicken Sie auf der**DNSSEC**Wählen Sie auf der Registerkarte**DNSSEC-Signatur aktivieren**aus. **Anmerkung** Wenn die Option in diesem Abschnitt**DNSSEC-Signatur deaktivieren**Der erste Schritt zur Aktivierung der DNSSEC-Signatur ist bereits abgeschlossen. Stellen Sie sicher, dass Sie eine Vertrauenskette für die gehostete Zone für DNSSEC einrichten oder bereits vorhanden sind, und Sie sind fertig. Weitere Informationen finden Sie unter [Schritt 3: Erstellen einer Vertrauenskette](#dns-configuring-dnssec-chain-of-trust). 1. Wählen Sie im Abschnitt **Schlüsselsignaturschlüsselerstellung (KSK)** **Create new KSK** (Neuen KSK erstellen), aus und geben Sie unter **Provide KSK name** (KSK-Namen angeben) einen Namen für den KSK ein, den Route 53 für Sie erstellen wird. Namen können nur Buchstaben, Zahlen und Unterstriche enthalten. Dieser Wert muss eindeutig sein. 1. UNDER**Kundenverwalteter CMK**den vom Kunden verwalteten Schlüssel für Route 53 aus, der beim Erstellen des KSK für Sie verwendet werden soll. Sie können einen vorhandenen vom Kunden verwalteten Schlüssel verwenden, der für die DNSSEC-Signatur gilt, oder einen neuen, vom Kunden verwalteten Schlüssel erstellen. Wenn Sie einen vom Kunden verwalteten Schlüssel bereitstellen oder erstellen, gibt es mehrere Anforderungen. Weitere Informationen finden Sie unter [Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC](dns-configuring-dnssec-cmk-requirements.md). 1. Geben Sie den Alias für einen vorhandenen, vom Kunden verwalteten Schlüssel ein. Wenn Sie einen neuen vom Kunden verwalteten Schlüssel verwenden möchten, geben Sie einen Alias für einen vom Kunden verwalteten Schlüssel ein, und Route 53 erstellt einen für Sie. **Anmerkung** Wenn Sie sich dafür entscheiden, dass Route 53 einen vom Kunden verwalteten Schlüssel erstellt, beachten Sie, dass für jeden vom Kunden verwalteten Schlüssel separate Gebühren anfallen. Weitere Informationen finden Sie unter [AWS Key Management Service – Preise](https://aws.amazon.com/kms/pricing/). 1. Klicken Sie auf **DNSSEC-Signatur aktivieren**. ------ **Führen Sie nach dem Aktivieren der Zonensignierung die folgenden Schritte aus** (egal, ob Sie die Konsole oder CLI verwendet haben): 1. Stellen Sie sicher, dass die Zonensignatur effektiv ist. Falls Sie dies getan haben AWS CLI, können Sie die Vorgangs-ID aus der Ausgabe des `EnableHostedZoneDNSSEC()` Aufrufs verwenden, um [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) auszuführen oder [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)um sicherzustellen, dass alle Route 53-DNS-Server Antworten signieren (Status =`INSYNC`). 1. Warten Sie mindestens auf die maximale TTL der vorherigen Zone. Warten Sie, bis Resolver alle nicht signierten Datensätze aus ihrem Cache leeren. Um dies zu erreichen, sollten Sie mindestens auf die maximale TTL der vorherigen Zone warten. In der `example.com`-Zone oben beträgt Wartezeit 1 Tag. 1. Überwachen Sie Berichte über Kundenprobleme. Nachdem Sie die Zonensignierung aktiviert haben, sehen Ihre Kunden möglicherweise Probleme im Zusammenhang mit Netzwerkgeräten und Resolvern. Der empfohlene Überwachungszeitraum beträgt 2 Wochen. Im Folgenden finden Sie Beispiele für Probleme, die möglicherweise auftreten: + Einige Netzwerkgeräte können die DNS-Antwortgröße auf unter 512 Byte beschränken, was für einige signierte Antworten zu klein ist. Diese Netzwerkgeräte sollten neu konfiguriert werden, um größere DNS-Antwortgrößen zu ermöglichen. + Einige Netzwerkgeräte führen eine gründliche Untersuchung der DNS-Antworten durch und entfernen bestimmte Datensätze, die sie nicht verstehen, wie die für DNSSEC verwendeten. Diese Geräte sollten neu konfiguriert werden. + Die Resolver einiger Kunden behaupten, dass sie eine größere UDP-Antwort akzeptieren können, als ihr Netzwerk unterstützt. Sie können Ihre Netzwerkfähigkeit testen und Ihre Resolver entsprechend konfigurieren. Weitere Informationen finden Sie unter [DNS-Antwortgröße-Testserver](https://www.dns-oarc.net/oarc/services/replysizetest/). **Rollback:** Rufen Sie [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) auf und führen Sie dann ein Rollback der Schritte unter durch. [Schritt 1: Vorbereiten der Aktivierung der DNSSEC-Signatur](#dns-configuring-dnssec-enable-signing-step-1) ## Schritt 3: Erstellen einer Vertrauenskette Nachdem Sie die DNSSEC-Signatur für eine gehostete Zone in Route 53 aktiviert haben, richten Sie eine Vertrauenskette für die gehostete Zone ein, um die DNSSEC-Signatureinrichtung abzuschließen. Dazu erstellen Sie einen Delegation Signer (DS) -Datensatz im*parent*-gehostete Zone für Ihre gehostete Zone mit den Informationen, die Route 53 zur Verfügung stellt. Je nachdem, wo Ihre Domain registriert ist, fügen Sie den Datensatz der übergeordneten gehosteten Zone in Route 53 oder bei einer anderen Domänenregistrierungsstelle hinzu. **So richten Sie eine Vertrauenskette für die DNSSEC-Signatur ein** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Wählen Sie im Navigationsbereich**Gehostete Zonen**, und wählen Sie dann eine gehostete Zone aus, für die Sie eine DNSSEC-Vertrauenskette einrichten möchten. *Sie müssen zuerst die DNSSEC-Signatur aktivieren.* 1. Klicken Sie auf der **DNSSEC** unter **DNSSEC**, wählen Sie **Anzeigen von Informationen zum Erstellen von DS-Datensätzen** aus. **Anmerkung** Wenn Sie nicht sehen**Anzeigen von Informationen zum Erstellen von DS-Datensätzen**in diesem Abschnitt müssen Sie die DNSSEC-Signatur aktivieren, bevor Sie die Vertrauenskette einrichten. Wählen Sie **Enable DNSSEC signing** (DNSSEC-Signatur aktivieren) aus, führen Sie die unter beschriebenen Schritte in [Schritt 2: Aktivieren der DNSSEC-Signatur und Erstellen einer KSK](#dns-configuring-dnssec-enable) aus und kehren Sie dann zu diesen Schritten zurück, um die Vertrauenskette einzurichten. 1. UNDER**Erstellen einer Vertrauenskette**, wählen Sie entweder**Registrant Route 53**oder**Eine andere Domänenvergabestelle**, je nachdem, wo Ihre Domain registriert ist. 1. Verwenden Sie die bereitgestellten Werte ab Schritt 3 , um einen DS-Datensatz für die übergeordnete gehostete Zone in Route 53 zu erstellen. Wenn Ihre Domäne nicht bei Route 53 gehostet wird, verwenden Sie die bereitgestellten Werte, um einen DS-Datensatz auf der Website Ihres Domänen-Registrars zu erstellen. Richten Sie eine Vertrauenskette für die übergeordnete Zone ein: + Wenn Ihre Domain über Route 53 verwaltet wird, gehen Sie wie folgt vor: Stellen Sie sicher, dass Sie den richtigen Signierungsalgorithmus (ECDSAP256SHA256 und Typ 13) und den richtigen Digest-Algorithmus (SHA-256 und Typ 2) konfigurieren. Wenn Route 53 Ihr Registrar ist, gehen Sie in der Route-53-Konsole wie folgt vor: 1. Beachten Sie die**Schlüsseltyp**,**Signaturalgorithmus**, und**Der öffentliche Schlüssel**-Werte. Klicken Sie im Navigationsbereich auf **Registered domains (Registrierte Domänen)**. 1. **Wählen Sie eine Domain aus und klicken Sie dann auf der Registerkarte **DNSSEC-Schlüssel auf Schlüssel hinzufügen**.** 1. Wählen Sie im Dialogfeld **Manage DNSSEC keys** (DNSSEC-Schlüssel verwalten) den entsprechenden **Key type** (Schlüsseltyp) und **Algorithm** (Algorithmus) für **Route 53 registrar** (Route-53-Registrar) aus den Dropdown-Menüs aus. 1. Kopieren Sie die**Der öffentliche Schlüssel**für den Registrar der Route 53. Wählen Sie in **Manage DNSSEC keys** (DNSSEC-Schlüssel verwalten) den Wert in dem Feld **Public key** (Öffentlicher Schlüssel) aus. 1. Wählen Sie **Hinzufügen** aus. Route 53 fügt den DS-Datensatz der übergeordneten Zone aus dem öffentlichen Schlüssel hinzu. Beispiel: Wenn Ihre Domäne lautet`example.com`Der DS-Eintrag wird der DNS-Zone .com hinzugefügt. + Wenn Ihre Domain in einer anderen Registry verwaltet wird, folgen Sie den Anweisungen im Abschnitt **Ein anderer Domain-Registrar**. Um sicherzustellen, dass die folgenden Schritte reibungslos verlaufen, führen Sie eine niedrige DS-TTL in die übergeordnete Zone ein. Wir empfehlen, den DS TTL auf 5 Minuten (300 Sekunden) für eine schnellere Wiederherstellung einzustellen, wenn Sie Ihre Änderungen zurücksetzen müssen. + Richten Sie eine Vertrauenskette für die untergeordnete Zone ein: Wenn Ihre übergeordnete Zone von einer anderen Registrierung verwaltet wird, kontaktieren Sie Ihren Registrar, um den DS-Datensatz für Ihre Zone einzuführen. In der Regel können Sie die TTL des DS-Datensatzes nicht anpassen. + Wenn Ihre übergeordnete Zone auf Route 53 gehostet wird, kontaktieren Sie den Besitzer der übergeordneten Zone, um den DS-Datensatz für Ihre Zone einzuführen. Geben Sie die `$ds_record_value` für den Besitzer der übergeordneten Zone an. Sie können sie abrufen, indem Sie in der Konsole auf **Informationen anzeigen klicken, um einen DS-Eintrag zu erstellen**, und das **DS-Datensatzfeld** kopieren, oder indem Sie die [GetDNSSec-API aufrufen](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) und den Wert des Felds '' abrufen: DSRecord ``` aws --region us-east-1 route53 get-dnssec --hosted-zone-id $hostedzone_id ``` Der Besitzer der übergeordneten Zone kann den Datensatz über die Route-53-Konsole oder CLI einfügen. + Um den DS-Eintrag mithilfe von einzufügen AWS CLI, erstellt und benennt der Besitzer der übergeordneten Zone eine JSON-Datei, die dem folgenden Beispiel ähnelt. Der Besitzer der übergeordneten Zone kann die Datei wie folgt benennen: `inserting_ds.json`. ``` { "HostedZoneId": "$parent_zone_id", "ChangeBatch": { "Comment": "Inserting DS for zone $zone_name", "Changes": [ { "Action": "UPSERT", "ResourceRecordSet": { "Name": "$zone_name", "Type": "DS", "TTL": 300, "ResourceRecords": [ { "Value": "$ds_record_value" } ] } } ] } } ``` Führen Sie anschließend den folgenden Befehl aus: ``` aws --region us-east-1 route53 change-resource-record-sets --cli-input-json file://inserting_ds.json ``` + Um den DS-Datensatz über die Konsole einzufügen, Öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). Wählen Sie im Navigationsbereich **Hosted zones** (Gehostete Zonen) und dann Name Ihrer gehosteten Zone und dann die Schaltfäche **Create record** (Datensatz erstellen) aus. Stellen Sie sicher, dass Sie Einfaches Routing für die **Routing policy** (Routing-Richtlinie) auswählen. Geben Sie im Feld **Datensatzname** denselben Namen wie der ein`$zone_name`, wählen Sie DS aus der Dropdownliste **Datensatztyp** aus, geben Sie den Wert von `$ds_record_value` in das Feld **Wert** ein und wählen Sie **Datensätze erstellen** aus. **Rollback:** entfernen Sie das DS aus der übergeordneten Zone, warten Sie auf die DS-TTL und setzen Sie dann die Schritte zum Aufbau von Vertrauen zurück. Wenn die übergeordnete Zone auf Route 53 gehostet wird, kann der Besitzer der übergeordneten Zone die `Action` von `UPSERT` zu `DELETE` in der JSON-Datei ändern und die obige Beispiel-CLI erneut ausführen. 1. Warten Sie, bis die Aktualisierungen basierend auf der TTL für Ihre Domänendatensätze weitergegeben werden. Wenn sich die übergeordnete Zone auf dem Route 53-DNS-Dienst befindet, kann der Besitzer der übergeordneten Zone die vollständige Weitergabe über die [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API bestätigen. Andernfalls können Sie die übergeordnete Zone regelmäßig auf den DS-Datensatz untersuchen und danach weitere 10 Minuten warten, um die Wahrscheinlichkeit zu erhöhen, dass die Einfügung des DS-Datensatzes vollständig propagiert wird. Beachten Sie, dass einige Registraren beispielsweise einmal täglich die DS-Einfügung geplant haben. Wenn Sie den Delegation Signer (DS)-Datensatz in der übergeordneten Zone einführen, starten die validierten Resolver, die den DS aufgenommen haben, mit der Validierung der Antworten aus der Zone. Um sicherzustellen, dass die Schritte zur Vertrauensbildung reibungslos verlaufen, führen Sie Folgendes aus: 1. Finden Sie das maximale NS TTL. Es gibt 2 Sätze von NS-Datensätzen, die Ihren Zonen zugeordnet sind: + Der NS-Datensatz der Delegation – dies ist der NS-Datensatz für Ihre Zone, die von der übergeordneten Zone gehalten wird. Sie können dies finden, indem Sie die folgenden Unix-Befehle ausführen (wenn Ihre Zone beispiel.com ist, ist die übergeordnete Zone com): `dig -t NS com` Wählen Sie einen der NS-Datensätze aus und führen Sie dann Folgendes aus: `dig @one of the NS records of your parent zone -t NS example.com` Zum Beispiel: `dig @b.gtld-servers.net. -t NS example.com` + Der NS-Datensatz in der Zone – dies ist der NS-Datensatz in Ihrer Zone. Sie können dies suchen, indem Sie den folgenden Unix-Befehl ausführen: `dig @one of the NS records of your zone -t NS example.com` Zum Beispiel: `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` Beachten Sie die maximale TTL für beide Zonen. 1. Warten Sie auf den maximalen NS TTL. Vor der DS-Einfügung erhalten Resolver eine signierte Antwort, validieren die Signatur jedoch nicht. Wenn der DS-Datensatz eingefügt wird, sehen Resolver ihn erst, wenn der NS-Datensatz für die Zone abläuft. Wenn Resolver den NS-Datensatz erneut abrufen, wird der DS-Datensatz dann ebenfalls zurückgegeben. Wenn Ihr Kunde einen Resolver auf einem Host mit einer nicht synchronisierten Uhr ausführt, stellen Sie sicher, dass sich die Uhr innerhalb 1 Stunde nach der richtigen Zeit befindet. Nach Abschluss dieses Schritts validieren alle DNSSEC-fähigen Resolver Ihre Zone. 1. Beachten Sie die Namensauflösung. Sie sollten beachten, dass es keine Probleme mit Resolvern gibt, die Ihre Zone validieren. Stellen Sie sicher, dass Sie auch die Zeit berücksichtigen, die Ihre Kunden benötigen, um Ihnen Probleme zu melden. Wir empfehlen eine Überwachung für bis zu 2 Wochen. 1. (Optional) Verlängern Sie DS und NS TTLs. Wenn Sie mit der Einrichtung zufrieden sind, können Sie die von Ihnen vorgenommenen TTL- und SOA-Änderungen speichern. Beachten Sie, dass Route 53 die TTL für signierte Zonen auf 1 Woche beschränkt. Weitere Informationen finden Sie unter [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md). Wenn Sie die DS TTL ändern können, empfehlen wir, dass Sie es auf 1 Stunde einstellen. # Deaktivieren der DNSSEC-Signatur Die Schritte zum Deaktivieren der DNSSEC-Signierung in Route 53 variieren je nach Vertrauenskette, zu der Ihre gehostete Zone gehört. Beispielsweise kann Ihre gehostete Zone eine übergeordnete Zone mit einem DS-Datensatz (Delegation Signer) als Teil einer Vertrauenskette aufweisen. Ihre gehostete Zone kann auch selbst eine übergeordnete Zone für untergeordnete Zonen sein, die die DNSSEC-Signatur aktiviert haben. Dies ist ein weiterer Teil der Vertrauenskette. Untersuchen und ermitteln Sie die vollständige Vertrauenskette für Ihre gehostete Zone, bevor Sie die DNSSEC-Signatur deaktivieren. Die Vertrauenskette für Ihre gehostete Zone, die die DNSSEC-Signatur aktiviert, muss beim Deaktivieren der Signatur sorgfältig rückgängig gemacht werden. Um die gehostete Zone aus der Vertrauenskette zu entfernen, entfernen Sie alle DS-Datensätze, die für die Vertrauenskette vorhanden sind, die diese gehostete Zone enthält. Dies bedeutet, dass Sie Folgendes tun müssen, um: 1. Entfernen Sie alle DS-Datensätze, die diese gehostete Zone für untergeordnete Zonen enthält, die Teil einer Vertrauenskette sind. 1. Entfernen Sie den DS-Datensatz aus der übergeordneten Zone. Überspringen Sie diesen Schritt, wennn Sie über eine Vertrauensinsel verfügen (es gibt keine DS-Datensätze in der übergeordneten Zone und keine DS-Datensätze für untergeordnete Zonen in dieser Zone). 1. Wenn Sie DS-Datensätze nicht entfernen können, entfernen Sie NS-Datensätze aus der übergeordneten Zone, um die Zone aus der Vertrauenskette zu entfernen. Weitere Informationen finden Sie unter [Hinzufügen oder Ändern der Nameserver und Glue-Datensätze in einer Domäne](domain-name-servers-glue-records.md). Mit den folgenden inkrementellen Schritten können Sie die Effektivität der einzelnen Schritte überwachen, um Probleme mit der DNS-Verfügbarkeit in Ihrer Zone zu vermeiden. **So deaktivieren Sie die DNSSEC-Signatur** 1. Überwachen Sie die Verfügbarkeit der Zone. Sie können die Zone auf die Verfügbarkeit Ihrer Domänennamen überwachen. Dies kann Ihnen helfen, alle Probleme zu beheben, die einen Schritt zurücksetzen könnten, nachdem Sie die DNSSEC-Signatur aktiviert haben. Sie können Ihre Domänennamen mit dem größten Datenverkehr überwachen, indem Sie die Abfrageprotokollierung verwenden. Für weitere Informationen zum Einrichten einer Abfrage-Protokollierung siehe [Amazon Route 53 überwachen](monitoring-overview.md). Die Überwachung kann über ein Shell-Skript oder über einen kostenpflichtigen Dienst erfolgen. Dies sollte jedoch nicht das einzige Signal sein, um festzustellen, ob ein Rollback erforderlich ist. Möglicherweise erhalten Sie auch Feedback von Ihren Kunden, da eine Domäne nicht verfügbar ist. 1. Suchen Sie die aktuelle DS TTL. Sie können die DS TTL finden, indem Sie den folgenden Unix-Befehl ausführen: `dig -t DS example.com example.com` 1. Suchen Sie die maximale NS TTL. Es gibt 2 Sätze von NS-Datensätzen, die Ihren Zonen zugeordnet sind: + Der NS-Datensatz der Delegation – dies ist der NS-Datensatz für Ihre Zone, die von der übergeordneten Zone gehalten wird. Sie können dies suchen, indem Sie den folgenden Unix-Befehl ausführen: Suchen Sie zuerst den NS Ihrer übergeordneten Zone (wenn Ihre Zone beispiel.com ist, ist die übergeordnete Zone com): `dig -t NS com` Wählen Sie einen der NS-Datensätze aus und führen Sie dann Folgendes aus: `dig @one of the NS records of your parent zone -t NS example.com` Zum Beispiel: `dig @b.gtld-servers.net. -t NS example.com` + Der NS-Datensatz in der Zone – dies ist der NS-Datensatz in Ihrer Zone. Sie können dies suchen, indem Sie den folgenden Unix-Befehl ausführen: `dig @one of the NS records of your zone -t NS example.com` Zum Beispiel: `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` Beachten Sie die maximale TTL für beide Zonen. 1. Entfernen Sie den DS-Eintrag aus der übergeordneten Zone. Kontaktieren Sie den Besitzer der übergeordneten Zone, um den DS-Datensatz zu entfernen. **Rollback:** Fügen Sie den DS-Datensatz erneut ein, bestätigen Sie, dass die DS-Einfügung wirksam ist, und warten Sie für die maximale TTL von NS (nicht DS). Danach starten alle Resolver wieder mit der Validierung. 1. Bestätigen Sie, dass die DS-Entfernung wirksam ist. Wenn sich die übergeordnete Zone auf dem Route 53-DNS-Dienst befindet, kann der Besitzer der übergeordneten Zone die vollständige Weitergabe über die [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API bestätigen. Andernfalls können Sie die übergeordnete Zone regelmäßig auf den DS-Datensatz untersuchen und danach weitere 10 Minuten warten, um die Wahrscheinlichkeit zu erhöhen, dass die Entfernung des DS-Datensatzes vollständig verbreitet wird. Beachten Sie, dass einige Registraren die DS-Entfernung geplant haben, z. B. einmal am Tag. 1. Warten Sie auf die DS TTL. Warten Sie, bis alle Resolver den DS-Datensatz aus ihren Caches abgelaufen sind. 1. Deaktivieren Sie die DNSSEC-Signatur und deaktivieren Sie den Schlüsselsignierungsschlüssel (KSK). + [CLI](#CLI_dnssec_disable) + [Konsole](#console_dnssec_disable) ------ #### [ CLI ] Rufen Sie [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) und auf. [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) APIs Beispiel: ``` aws --region us-east-1 route53 disable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id aws --region us-east-1 route53 deactivate-key-signing-key \ --hosted-zone-id $hostedzone_id --name $ksk_name ``` ------ #### [ Console ] **So deaktivieren Sie die DNSSEC-Signatur** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Wählen Sie im Navigationsbereich**Gehostete Zonen**Wählen Sie dann eine gehostete Zone aus, für die Sie die DNSSEC-Signatur deaktivieren möchten. 1. Klicken Sie auf der**DNSSEC**Wählen Sie auf der Registerkarte**DNSSEC-Signatur deaktivieren**aus. 1. Klicken Sie auf der**DNSSEC-Signatur deaktivieren**Wählen Sie je nach Szenario für die Zone, für die Sie die DNSSEC-Signatur deaktivieren, eine der folgenden Optionen aus. + **Nur übergeordnete Zone**— Diese Zone hat eine übergeordnete Zone mit einem DS-Eintrag. In diesem Szenario müssen Sie den DS-Eintrag der übergeordneten Zone entfernen. + **Nur untergeordnete Zonen**— Diese Zone verfügt über einen DS-Eintrag für eine Vertrauenskette mit einer oder mehreren untergeordneten Zonen. In diesem Szenario müssen Sie die DS-Einträge der Zone entfernen. + **Übergeordnet und untergeordnet**— Diese Zone verfügt über einen DS-Datensatz für eine Vertrauenskette mit einer oder mehreren untergeordneten Zonen*und*eine übergeordnete Zone mit einem DS-Datensatz. Führen Sie für dieses Szenario die folgenden Schritte in aus: 1. Entfernen Sie die DS-Einträge der Zone. 1. Entfernen Sie den DS-Eintrag der übergeordneten Zone. Wenn Sie eine Insel des Vertrauens haben, können Sie diesen Schritt überspringen. 1. Bestimmen Sie die TTL für jeden DS-Datensatz, den Sie in Schritt 4 entfernen. Stellen Sie sicher, dass der längste TTL-Zeitraum abgelaufen ist. 1. Wählen Sie das Kontrollkästchen, um zu bestätigen, dass Sie die Schritte der Reihe nach befolgt haben. 1. GebenSie *disable* wie gezeigt in das Feld und wählen Sie **Deaktivieren** aus. **So deaktivieren Sie den Schlüsselsignierungschlüssel (KSK)** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. Wählen Sie im Navigationsbereich **Hosted Zones** (Gehostete Zonen) und wählen Sie dann eine gehostete Zone aus, für die Sie den Schlüsselsignierungsschlüssel (KSK) deaktivieren möchten. 1. **Wählen Sie im Abschnitt **Schlüssel zur Schlüsselsignierung (KSKs)** das KSK aus, das Sie deaktivieren möchten, und wählen Sie unter **Aktionen** die Option KSK **bearbeiten aus, setzen Sie den KSK-Status** **auf **Inaktiv** und wählen Sie dann KSK** speichern aus.** ------ **[Rollback: Anruf und DNSSEC. [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)EnableHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)** APIs Beispiel: ``` aws --region us-east-1 route53 activate-key-signing-key \ --hosted-zone-id $hostedzone_id --name $ksk_name aws --region us-east-1 route53 enable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id ``` 1. Bestätigen Sie, dass das Deaktivieren der Zonensignierung wirksam ist. Vergewissern Sie sich anhand der ID aus dem `EnableHostedZoneDNSSEC()` Anruf [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html), dass alle Route 53-DNS-Server keine Antworten mehr signieren (Status =). `INSYNC` 1. Beachten Sie die Namensauflösung. Sie sollten beachten, dass es keine Probleme gibt, die dazu führen, dass Resolver Ihre Zone validieren. Planen Sie 1-2 Wochen ein, um auch die Zeit zu berücksichtigen, die Ihre Kunden benötigen, um Ihnen Probleme zu melden. 1. (Optional) Bereinigen. Wenn Sie das Signieren nicht wieder aktivieren möchten, können Sie den KSKs durchgehenden Schlüssel bereinigen [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)und den entsprechenden vom Kunden verwalteten Schlüssel löschen, um Kosten zu sparen. # Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC Wenn Sie die DNSSEC-Signierung in Amazon Route 53 aktivieren, erstellt Route 53 einen Schlüssel-Signaturschlüssel (KSK). Um ein KSK zu erstellen, muss Route 53 einen vom Kunden verwalteten Schlüssel verwenden AWS Key Management Service , der DNSSEC unterstützt. In diesem Abschnitt werden die Details und Anforderungen für den vom Kunden verwalteten Schlüssel beschrieben, die bei der Arbeit mit DNSSEC hilfreich sind. Beachten Sie Folgendes, wenn Sie mit kundenverwalteten Schlüsselverwaltete Schlüssel für DNSSEC arbeiten: + Der kundenverwaltete Schlüssel, den Sie mit der DNSSEC-Signatur verwenden, muss sich in der Region USA Ost (Nord-Virginia) befinden. + Der vom Kunden verwaltete Schlüssel muss ein [Asymmetrische kundenverwaltete Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks) mit einem [Schlüsselspezifikation ECC\$1NIST\$1P256](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc) sein. Diese kundenverwalteten Schlüssel werden nur zur Signatur und Verifizierung verwendet. Hilfe bei der Erstellung eines asymmetrischen kundenverwalteten Schlüssels finden Sie unter [Asymmetrische, vom Kunden verwaltete Schlüssel erstellen](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk) im Entwicklerhandbuch. AWS Key Management Service Hilfe bei der Suche nach der kryptografischen Konfiguration eines vorhandenen, vom Kunden verwalteten Schlüssels finden Sie im [Entwicklerhandbuch unter Kryptografiekonfiguration von kundenverwalteten Schlüsseln anzeigen](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html). AWS Key Management Service + Wenn Sie einen vom Kunden verwalteten Schlüssel für die Verwendung mit DNSSEC in Route 53 selbst erstellen, müssen Sie bestimmte Schlüsselrichtlinienanweisungen einschließen, die Route 53 die erforderlichen Berechtigungen erteilen. Route 53 muss auf Ihren vom Kunden verwalteten Schlüssel zugreifen können, damit er eine KSK für Sie erstellen kann. Weitere Informationen finden Sie unter [Route 53 vom Kunden verwaltete Schlüsselberechtigungen für DNSSEC-Signierung erforderlich](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC). + Route 53 kann einen vom Kunden verwalteten Schlüssel für Sie erstellen, den Sie mit der AWS KMS DNSSEC-Signatur ohne zusätzliche Berechtigungen verwenden können. AWS KMS Sie müssen jedoch über bestimmte Berechtigungen verfügen, wenn Sie den Schlüssel nach der Erstellung bearbeiten möchten. Die spezifischen Berechtigungen, die Sie haben müssen, sind die folgenden:`kms:UpdateKeyDescription`,`kms:UpdateAlias`, und `kms:PutKeyPolicy`. + Beachten Sie, dass für jeden Kunden verwalteten Schlüssel, den Sie haben, separate Gebühren anfallen, unabhängig davon, ob Sie den vom Kunden verwalteten Schlüssel erstellen oder Route 53 ihn für Sie erstellt. Weitere Informationen finden Sie unter [AWS Key Management Service Preise](https://aws.amazon.com/kms/pricing/). # Arbeiten mit Schlüsseln zur Schlüsselsignierung () KSKs Wenn Sie DNSSEC-Signaturschlüssel aktivieren, erstellt Route 53 einen Schlüssel-Signaturschlüssel (KSK). In Route 53 können Sie bis zu zwei KSKs pro gehosteter Zone haben. Nachdem Sie die DNSSEC-Signatur aktiviert haben, können Sie Ihre hinzufügen, entfernen oder bearbeiten. KSKs Beachten Sie Folgendes, wenn Sie mit Ihrem arbeiten: KSKs + Bevor Sie eine KSK löschen können, müssen Sie die KSK bearbeiten, um ihren Status auf **Inaktiv** einzustellen. + Wenn DNSSEC-Signatur für eine gehostete Zone aktiviert ist, begrenzt Route 53 die TTL auf eine Woche. Wenn Sie eine TTL für Datensätze in der gehosteten Zone auf mehr als eine Woche festlegen, erhalten Sie keinen Fehler, aber Route 53 erzwingt eine TTL von einer Woche. + Um einen Zonenausfall zu verhindern und Probleme mit der Nichtverfügbarkeit Ihrer Domäne zu vermeiden, müssen Sie DNSSEC-Fehler schnell beheben und beheben. Wir empfehlen Ihnen dringend, einen CloudWatch Alarm einzurichten, der Sie benachrichtigt, wenn ein `DNSSECInternalFailure` `DNSSECKeySigningKeysNeedingAction` Oder-Fehler erkannt wird. Weitere Informationen finden Sie unter [Überwachung von Hosting-Zonen mit Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). + Die in diesem Abschnitt beschriebenen KSK-Operationen ermöglichen es Ihnen, Ihre Zonen zu wechseln. KSKs Weitere Informationen und ein step-by-step Beispiel finden Sie unter *DNSSEC-Schlüsselrotation* im Blogbeitrag [Konfiguration der DNSSEC-Signierung und -Validierung mit](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/) Amazon Route 53. Folgen Sie den Anweisungen KSKs in den folgenden AWS-Managementkonsole Abschnitten, um damit zu arbeiten. ## Hinzufügen eines Schlüsselsignaturschlüssels Wenn Sie DNSSEC-Signatur aktivieren, erstellt Route 53 eine Schlüsselsignierung (KSK) für Sie. Sie können es auch KSKs separat hinzufügen. In Route 53 können Sie bis zu zwei KSKs pro gehosteter Zone haben. Wenn Sie ein KSK erstellen, müssen Sie Route 53 angeben oder anfordern, um einen vom Kunden verwalteten Schlüssel zur Verwendung mit dem KSK zu erstellen. Wenn Sie einen vom Kunden verwalteten Schlüssel bereitstellen oder erstellen, gibt es mehrere Anforderungen. Weitere Informationen finden Sie unter [Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC](dns-configuring-dnssec-cmk-requirements.md). Gehen Sie folgendermaßen vor, um eine KSK in der AWS-Managementkonsole hinzuzufügen. **So fügen Sie eine KSK hinzu** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Wählen Sie im Navigationsbereich**Gehostete Zonen**, und wählen Sie dann eine gehostete Zone aus. 1. **Wählen Sie auf der Registerkarte **DNSSEC-Signierung unter **Schlüssel zur Schlüsselsignierung (KSKs)** die Option **Zur erweiterten Ansicht wechseln** und dann unter **Aktionen** die Option KSK** hinzufügen aus.** 1. UNDER**KSK**einen Namen für die KSK ein, die Route 53 für Sie erstellt. Namen können nur Buchstaben, Zahlen und Unterstriche enthalten. Dieser Wert muss eindeutig sein. 1. Geben Sie den Alias für einen vom Kunden verwalteten Schlüssel ein, der für die DNSSEC-Signatur gilt, oder geben Sie einen Alias für einen neuen kundenverwalteten Schlüssel ein, den Route 53 für Sie erstellt. **Anmerkung** Wenn Sie sich dafür entscheiden, dass Route 53 einen vom Kunden verwalteten Schlüssel erstellt, beachten Sie, dass für jeden vom Kunden verwalteten Schlüssel separate Gebühren anfallen. Weitere Informationen finden Sie unter [AWS Key Management Service Preise](https://aws.amazon.com/kms/pricing/). 1. Wählen Sie **Create stack (Stack erstellen)** aus. ## Bearbeiten eines Schlüsselsignaturschlüssels Sie können den Status eines KSK so bearbeiten, dass**Aktiv**oder**Inaktiv** ist. Wenn ein KSK aktiv ist, verwendet Route 53 diese KSK für die DNSSEC-Signatur. Bevor Sie eine KSK löschen können, müssen Sie die KSK bearbeiten, um ihren Status auf **Inaktiv**einzustellen. Gehen Sie folgendermaßen vor, um eine KSK im AWS-Managementkonsole zu editieren. **So bearbeiten Sie ein Tag** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Wählen Sie im Navigationsbereich**Gehostete Zonen**, und wählen Sie dann eine gehostete Zone aus. 1. **Wählen Sie auf der Registerkarte **DNSSEC-Signierung unter **Schlüssel zur Schlüsselsignierung (KSKs)** die Option **Zur erweiterten Ansicht wechseln** und dann unter **Aktionen** die Option KSK** bearbeiten aus.** 1. Nehmen Sie die gewünschten Aktualisierungen an der KSK vor und wählen Sie**Save**aus. ## Löschen eines Schlüsselsignaturschlüssels Bevor Sie eine KSK löschen können, müssen Sie die KSK bearbeiten, um ihren Status auf**Inaktiv**einzustellen. Ein Grund, warum Sie eine KSK löschen können, ist als Teil der Routine Schlüsselrotation. Es ist eine bewährte Methode, kryptografische Schlüssel regelmäßig zu drehen. Ihre Organisation verfügt möglicherweise über Standardanweisungen für das Drehen von Schlüsseln. Befolgen Sie diese Schritte, um die AWS-Managementkonsole-Tabelle zu löschen. **So löschen Sie eine VPC** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) 1. Wählen Sie im Navigationsbereich**Gehostete Zonen**, und wählen Sie dann eine gehostete Zone aus. 1. **Wählen Sie auf der Registerkarte **DNSSEC-Signierung unter **Schlüssel zur Schlüsselsignierung (KSKs)** die Option **Zur erweiterten Ansicht wechseln** und dann unter **Aktionen** die Option KSK** löschen aus.** 1. Folgen Sie den Anweisungen, um das Löschen des KSK zu bestätigen. # KMS-Schlüssel- und ZSK-Verwaltung in Route 53 In diesem Abschnitt wird die aktuelle Vorgehensweise beschrieben, die Route 53 für Ihre Zonen mit aktivierter DNSSEC-Signatur verwendet. **Anmerkung** Route 53 verwendet die folgende Regel, die sich ändern könnte. Alle zukünftigen Änderungen werden die Sicherheitslage Ihrer Zone oder die von Route 53 nicht beeinträchtigen. **Wie verwendet Route 53 die mit Ihrem KSK verknüpften AWS KMS ** In DNSSEC wird der KSK verwendet, um die Ressourceneintragssignatur (RRSIG) für den DNSKEY-Ressourcendatensatz zu generieren. Alle `ACTIVE` KSKs werden in der RRSIG-Generation verwendet. Route 53 generiert eine RRSIG, indem sie die `Sign` AWS KMS API für den zugehörigen KMS-Schlüssel aufruft. Weitere Informationen finden Sie unter [Signieren](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html) im *AWS KMS -API-Handbuch*. Diese werden RRSIGs nicht auf das in der Zone festgelegte Limit für Ressourceneinträge angerechnet. Ein RRSIG läuft ab. Um zu verhindern, dass sie ablaufen, RRSIGs werden sie regelmäßig aktualisiert, indem sie alle ein bis sieben Tage erneuert werden. RRSIGs Sie RRSIGs werden außerdem jedes Mal aktualisiert, wenn Sie einen der folgenden Befehle aufrufen: APIs + [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html) + [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html) + [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) + [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html) + [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) + [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) Jedes Mal, wenn Route 53 eine Aktualisierung durchführt, generieren wir 15 für die nächsten Tage, falls RRSIGs auf den zugehörigen KMS-Schlüssel nicht mehr zugegriffen werden kann. Für die Schätzung der KMS-Schlüsselkosten können Sie von einer regulären Aktualisierung am Tag ausgehen. Ein KMS-Schlüssel könnte durch versehentliche Änderungen der KMS-Schlüsselrichtlinie unzugänglich werden. Der unzugängliche KMS-Schlüssel setzt den Status des zugehörigen KSK auf `ACTION_NEEDED`. Es wird dringend empfohlen, diesen Zustand zu überwachen, indem Sie bei jedem erkannten `DNSSECKeySigningKeysNeedingAction` Fehler einen CloudWatch Alarm einrichten, da bei validierenden Resolvern die Suche nach Ablauf der letzten RRSIG fehlschlägt. Weitere Informationen finden Sie unter [Überwachung von Hosting-Zonen mit Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). **Wie Route 53 den ZSK Ihrer Zone verwaltet** Jede neue gehostete Zone mit aktivierter DNSSEC-Signatur hat einen `ACTIVE` Zonensignaturschlüssel (ZSK). Der ZSK wird für jede gehostete Zone separat generiert und gehört Route 53. Der aktuelle Schlüsselalgorithmus ist. ECDSAP256 SHA256 Wir werden innerhalb von sieben bis 30 Tagen nach Beginn der Signatur eine regelmäßige ZSK-Rotation in der Zone durchführen. Derzeit verwendet Route 53 die Methode „Schlüssel-Rollover vor der Veröffentlichung“. Weitere Informationen finden Sie unter [Zonensignaturschlüssel-Rollover vor der Veröffentlichung](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1). Diese Methode führt einen anderen ZSK in die Zone ein. Die Rotation wird alle sieben bis 30 Tage wiederholt. Route 53 unterbricht die ZSK-Rotation, wenn sich ein KSK der Zone im `ACTION_NEEDED` Status befindet, weil Route 53 nicht in der Lage sein wird, die Ressourcendatensätze RRSIGs für DNSKEY neu zu generieren, um den Änderungen im ZSK der Zone Rechnung zu tragen. Die ZSK-Rotation wird automatisch fortgesetzt, nachdem die Bedingung gelöscht wurde. # DNSSEC-Nachweise für Nichtvorhandensein in Route 53 **Anmerkung** Route 53 verwendet die folgende Regel, die sich ändern könnte. Alle zukünftigen Änderungen werden die Sicherheitslage Ihrer Zone oder die von Route 53 nicht beeinträchtigen. Es gibt drei Arten von Nachweisen für das Nichtvorhandensein in DNSSEC: + Nachweis des Nichtvorhandenseins eines Datensatzes, der mit dem Abfragenamen übereinstimmt. + Nachweis des Nichtvorhandenseins eines Typs, der mit dem Abfragetyp übereinstimmt. + Nachweis des Vorhandenseins eines Platzhalterdatensatzes, der zur Erzeugung des Datensatzes als Antwort verwendet wird. Route 53 implementiert den Nachweis des Nichtvorhandenseins eines Datensatzes, der mit dem Abfragenamen übereinstimmt, mithilfe der BL-Methode. Weitere Informationen finden Sie unter [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00). Bei dieser Methode wird eine kompakte Darstellung des Nachweises erzeugt und das Zone Walking verhindert. In Fällen, in denen es einen Datensatz gibt, der dem Abfragenamen, aber nicht dem Abfragetyp entspricht (z. B. bei der Abfrage nach web.example). com/AAAA but there is only web.example.com/Apresent) geben wir einen minimalen NSEC-Datensatz (Next Secure) zurück, der alle unterstützten Ressourcendatensatztypen enthält. Wenn Route 53 eine Antwort aus einem Platzhalterdatensatz synthetisiert, umfasst die Antwort keinen nächsten sicheren Datensatz, oder NSEC-Datensatz, für den Platzhalter. Ein solcher NSEC-Datensatz wird in einigen Implementierungen verwendet, für gewöhnlich jenen, die Offline-Signaturen ausführen, um zu verhindern, dass die Ressourceneeintragssignaturen (RRSIG) in der Antwort wiederverwendet werden, um eine andere Antwort zu fälschen. Route 53 verwendet Online-Signierung für Datensätze, die nicht zu DNSKEY gehören, um RRSIGs spezifische Einträge für die Antwort zu generieren, die nicht für eine andere Antwort wiederverwendet werden können. # Fehlerbehebung für DNSSEC Die Informationen in diesem Abschnitt können Ihnen helfen, Probleme mit der DNSSEC-Signatur zu lösen, einschließlich der Aktivierung und Deaktivierung sowie mit Ihren Key-Signing-Schlüsseln (). KSKs Aktivieren der DNSSEC Stellen Sie sicher, dass Sie die Voraussetzungen in [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md) gelesen haben, bevor Sie mit der Aktivierung der DNSSEC-Signierung beginnen. Deaktivieren der DNSSEC Um DNSSEC sicher zu deaktivieren, überprüft Route 53, ob sich die Zielzone in der Vertrauenskette befindet. Es überprüft, ob das übergeordnete Element der Zielzone über NS-Datensätze der Zielzone und DS-Datensätze der Zielzone verfügt. Wenn die Zielzone nicht öffentlich auflösbar ist, z. B. wenn beim Abfragen nach NS und DS eine SERVFAIL-Antwort erhalten wird, kann Route 53 nicht feststellen, ob DNSSEC sicher deaktiviert werden kann. Sie können sich an Ihre übergeordnete Zone wenden, um diese Probleme zu beheben, und später erneut versuchen, DNSSEC zu deaktivieren. KSK-Status lautet**Aktion erforderlich** Ein KSK kann seinen Status in **Aktion erforderlich** (oder `ACTION_NEEDED` in einen [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)Status) ändern, wenn Route 53 DNSSEC den Zugriff auf ein entsprechendes Objekt verliert AWS KMS key (aufgrund einer Änderung der Berechtigungen oder Löschung). AWS KMS key Wenn der Status eines KSK **Action needed** (Aktion erforderlich) ist, bedeutet dies, dass es schließlich zu einem Zonenausfall für Clients kommt, die DNSSEC-validierende Resolver verwenden, und Sie müssen schnell handeln, um zu verhindern, dass eine Produktionszone nicht mehr aufgelöst werden kann. Um das Problem zu beheben, stellen Sie sicher, dass der vom Kunden verwaltete Schlüssel, auf dem Ihre KSK basiert, aktiviert ist und über die richtigen Berechtigungen verfügt. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter [Route 53 vom Kunden verwaltete Schlüsselberechtigungen für DNSSEC-Signierung erforderlich](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC). Nachdem Sie das KSK repariert haben, aktivieren Sie es erneut mithilfe der Konsole oder der AWS CLI, wie unter beschrieben. [Schritt 2: Aktivieren der DNSSEC-Signatur und Erstellen einer KSK](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable) Um dieses Problem in future zu vermeiden, sollten Sie erwägen, eine Amazon CloudWatch Metrik hinzuzufügen, um den Status des KSK nachzuverfolgen, wie unter vorgeschlagen. [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md) KSK-Status lautet**Internal failure (Interner Fehler)** Wenn ein KSK den Status **Interner Fehler** (oder `INTERNAL_FAILURE` einen [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)Status) hat, können Sie nicht mit anderen DNSSEC-Entitäten arbeiten, bis das Problem behoben ist. Sie müssen Maßnahmen ergreifen, bevor Sie mit der DNSSEC-Signatur arbeiten können, einschließlich der Arbeit mit dieser KSK oder Ihrer anderen KSK. Um das Problem zu beheben, versuchen Sie erneut, KSK zu aktivieren oder zu deaktivieren. [Um das Problem bei der Arbeit mit dem zu beheben APIs, versuchen Sie, das Signieren zu aktivieren ([EnableHostedZoneDNSSEC) oder das Signieren zu deaktivieren (DNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)). DisableHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) Es ist wichtig, dass Sie**Internal failure (Interner Fehler)**umgehend Probleme. Sie können keine weiteren Änderungen an der gehosteten Zone vornehmen, bis Sie das Problem behoben haben, mit Ausnahme der Vorgänge zum Beheben des **Internal failure (Interner Fehler)**.