Wie kann ich DNSSEC-Konfigurationsprobleme in Route 53 identifizieren und beheben?

Lesedauer: 5 Minute
0

Die DNS-Auflösung für Resolver, die DNSSEC unterstützen (z. B. 8.8.8.8 oder 1.1.1.1), gibt aufgrund einer DNSSEC-Fehlkonfiguration SERVFAIL-Antworten in Amazon Route 53 zurück.

Lösung

Schritt 1: Bestätigen, dass die DNSSEC-Konfiguration den DNS-Auflösungsfehler verursacht

1.Führen Sie den Befehl dig aus, um die Abfrage über den Google DNS-Resolver 8.8.8.8 zu erzwingen. Der Google DNS-Resolver unterstützt DNSSEC und gibt eine SERVFAIL-Antwort zurück, wenn DNSSEC falsch konfiguriert ist. Ersetzen Sie im folgenden Beispielbefehl dnssec.example.live durch Ihre Domain.

$ dig dnssec.example.live @8.8.8.8

Die Ausgabe der vorherigen Befehle zeigt eine SERVFAIL-Antwort:

;  <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2  <<>> dnssec.example.live @8.8.8.8
;; global options: +cmd
;; Got answer:
;; -->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30778
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dnssec.example.live.    IN    A

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Apr 21 18:13:57 UTC 2022
;; MSG SIZE  rcvd: 52

2.Führen Sie den Befehl dig erneut aus und setzen Sie das Flag cd. Das Flag cd löst die Abfrage auf, ohne nach DNSSEC zu suchen. Ersetzen Sie im folgenden Beispielbefehl dnssec.example.live durch Ihre Domain.

$ dig dnssec.example.live @8.8.8.8 +cd

Das folgende Ausgabebeispiel bestätigt, dass eine DNSSEC-Fehlkonfiguration die SERVFAIL-Antwort verursacht hat:

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> dnssec.example.live @8.8.8.8 +cd

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30235
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dnssec.example.live.    IN    A

;; ANSWER SECTION:
dnssec.example.live. 300    IN    A    10.10.10.10

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Apr 21 18:15:51 UTC 2022
;; MSG SIZE  rcvd: 68

Schritt 2: Identifizieren des DS-Datensatzes, der in der übergeordneten Zone erstellt wurde

**Hinweis:**Der Registrar fügt den DS-Datensatz für die TLD hinzu. Die übergeordnete Zone für die Domain 'example.com' ist also die '.com'-Zone. In diesem Beispiel ist die übergeordnete Zone für 'dnssec.example.live' 'example.live'.

1.Führen Sie den Befehl dig +trace aus, um die vollständigen Delegierungs- und Nameserver für die übergeordnete Zone anzuzeigen:

dig +trace dnssec.example.live

>>truncated for convenience

example.live.    3600    IN    NS    ns-xxx.awsdns-xx.net.
example.live.    3600    IN    NS    ns-xxxx.awsdns-xx.org.
example.live.    3600    IN    NS    ns-xxxx.awsdns-xx.co.uk.
example.live.    3600    IN    NS    ns-xxx.awsdns-xx.com.
example.live.    3600    IN    DS    28927 13 2 133329D78FFCD003D39BAB9386FC18A49807584CD42042B3F53E1293 8F63C5A7
example.live.    3600    IN    RRSIG    DS 8 2 3600 20220508154435 20220417144435 32325 live. HzdzyWb8+8G1vbzMWR/7usqN5GihWpuToRKnWv3NSXPnzzYaAFrkuYlU pX8izzvnXk/uyiCOcMShQPKfybgviNkm+yfyTwm3rOso8amJDz0Jz8ml lz7jhgH0k04gLbbT7i8Ez8k8qPLB9MVb1jtVz7rjl6k4Y4m38aHUMy0D lxk=
;; Received 404 bytes from 65.22.22.1#53(v0n2.nic.live) in 1 ms

dnssec.example.live. 10    IN    NS    ns-xxxx.awsdns-xx.org.
dnssec.example.live. 10    IN    NS    ns-xxx.awsdns-xx.com.
dnssec.example.live. 10    IN    NS    ns-xxxx.awsdns-xx.co.uk.
dnssec.example.live. 10    IN    NS    ns-xxx.awsdns-xx.net.
dnssec.example.live. 300    IN    DS    41670 13 2 DE085966266F92FA81BBE2829AD9CD8C2C7FC8109D748F49B5A99D2F A1893581
dnssec.example.live. 300    IN    RRSIG    DS 13 3 300 20220421192820 20220421172320 53547 example.live. xdwGnGasWO2sbZQoAfYdZK2bAMcpYOjMR+mg2ilt00XDIwrPc/Qac1k2 Lc2NpAcFpgb3KbhzFxpd3Z7qXjPsvw==
;; Received 352 bytes from 205.251.197.102#53(ns-xxxx.awsdns-xx.org) in 6 ms

dnssec.example.live. 300    IN    A    1.1.1.1
dnssec.example.live. 300    IN    RRSIG    A 13 3 300 20220421192821 20220421172321 51615 dnssec.example.live. sMzXesnw+7pSHK2Mlkossyjml8sK7RhgKyu50J/P3/TEeChPzia8EfDb nbv3fFDxXQcbqPH+M+6KlQ7JrAmBig==
;; Received 187 bytes from 205.251.192.150#53(ns-xxx.awsdns-xx.com) in 14 ms

2.Um den DS-Datensatz in der übergeordneten Zone zu überprüfen, führen Sie die folgende Abfrage über die Nameserver der übergeordneten Zone aus (in diesem Beispiel example.live):

`$ dig DS dnssec.example.live @ns-xxx.awsdns-xx.net. +short `
41670 13 2 DE085966266F92FA81BBE2829AD9CD8C2C7FC8109D748F49B5A99D2F A1893581

Konfigurieren Sie den DS-Datensatz in der übergeordneten Zone. Überprüfen Sie dann den DS-Datensatz mit dem Hash-Wert des öffentlichen KSK der untergeordneten Zone, um sicherzustellen, dass der DS-Datensatz korrekt ist.

Schritt 3: Bestätigen, dass die DNSSEC-Signatur für die gehostete Zone aktiviert ist

Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die DNSSEC-Signatur für die gehostete Zone aktiviert ist:

$ dig DNSKEY dnssec.example.live @ns-xxxx.awsdns-xx.org +noall +answer +multiline

Die folgende Ausgabe bestätigt, dass die DNSSEC-Signatur aktiviert ist, und listet die in der Zone vorhandenen öffentlichen Schlüssel auf.

`; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> DNSKEY dnssec.example.live @ns-xxxx.awsdns-xx.org +noall +answer +multiline`  
`;; global options: +cmd`  
`dnssec.example.live. 3600 IN DNSKEY    256 3 13 (`  
`                4xMqBH+v21Ria6T00Oq08fY8S3FxA9XFp34uDQm0dBpk`  
`                l6MwBNLZxpwpzS35yunxEYKwHkoPnMtu1bckRFauJg==`  
`                ) ; ZSK; alg = ECDSAP256SHA256 ; key id = 51615`  
`dnssec.example.live. 3600 IN DNSKEY    257 3 13 (`  
`                pvoQ+Q2TvJKRuxdv8yuJhLkJhdrYUf/ZA2REWUTAXsfS`  
`                laK0MFDzCurSXXjlQxQoVGauDe5CwGufXl40fVzt/w==`  
`                ) ; KSK; alg = ECDSAP256SHA256 ; key id = 41670`

Wenn der Befehl keine Antwort liefert, ist die DNSSEC-Signatur in der gehosteten Zone nicht aktiviert. Wenn DNSSEC nicht aktiviert ist, entfernen Sie den DS-Datensatz aus dem Registrar.

Schritt 4: Identifizieren, was der richtige DS-Datensatz in der übergeordneten Zone erstellt hat

1.Führen Sie den folgenden Befehl aus, um bind und bind-ultis zu installieren:

$ sudo yum install bind bind-utils -y

2.Führen Sie den folgenden Befehl aus, um den richtigen DS-Datensatz abzurufen, der in der übergeordneten Zone erstellt wurde:

$ dig DNSKEY dnssec.example.live @ns-xxxx.awsdns-xx.org. | dnssec-dsfromkey -2 -f - dnssec.example.live

dnssec.example.live. IN DS 41670 13 2 DE085966266F92FA81BBE2829AD9CD8C2C7FC8109D748F49B5A99D2FA1893580

Schritt 5: Abgleichen des in Schritt 4 erhaltenen DS-Datensatzes mit dem in Schritt 2 erhaltenen DS-Datensatz

Stellen Sie sicher, dass der in der übergeordneten Zone erstellte DS-Datensatz mit dem in Schritt 4 erhaltenen DS-Datensatz übereinstimmt.

Ab Schritt 2:

41670 13 2 DE085966266F92FA81BBE2829AD9CD8C2C7FC8109D748F49B5A99D2F A1893581 << Incorrect string

Ab Schritt 4:

41670 13 2 DE085966266F92FA81BBE2829AD9CD8C2C7FC8109D748F49B5A99D2FA1893580

Im vorherigen Beispiel ist der Hash-Wert des DS-Datensatzes, der in der übergeordneten Zone konfiguriert wurde (aus Schritt 2), falsch. Diese Diskrepanz führt zu Problemen bei der DNS-Auflösung.

Um das Problem zu beheben, erstellen Sie den richtigen DS-Datensatzwert auf der Seite des Registrars (übergeordnete Zone). Verwenden Sie für bei Route 53 registrierte Domains den Befehl get-dnssec, um die richtigen Informationen zum Hinzufügen öffentlicher Schlüssel für Ihre Domain abzurufen.

**Hinweis:**Wenn Sie beim Ausführen von Befehlen der AWS Command Line Interface (AWS CLI) Fehler erhalten, stellen Sie sicher, dass Sie die neueste Version der AWS-CLI verwenden.

$ aws --region us-east-1 route53 get-dnssec --hosted-zone-id $hostedzone_id
AWS OFFICIAL
AWS OFFICIALAktualisiert vor einem Jahr