Diese Seite bietet mehrere erweiterte DNSSEC-Konfigurationsoptionen (Domain Name System Security Extensions), mit denen Sie DNSSEC für Ihre verwalteten Zonen aktivieren können. Diese Optionen reichen von verschiedenen Signaturalgorithmen und dem Vorhandensein von Abwesenheit bis hin zur Verwendung von Datensatztypen, für die DNSSEC benötigt oder empfohlen wird.
Eine konzeptionelle Übersicht über DNSSEC finden Sie in der DNSSEC-Übersicht.
DNSSEC-signierte Subdomains delegieren
Sie können DNSSEC für delegierte Subdomains aktivieren, nachdem Sie DNSSEC für Ihre primäre Domain aktiviert haben. Erstellen Sie zuerst einen DS-Eintrag in einer Cloud DNS-Zone, um DNSSEC für delegierte Subdomains zu aktivieren. Sie müssen auch einen oder mehrere NS-Einträge erstellen.
Zum Erstellen von DS-Einträgen für delegierte Subdomains müssen Sie den DS-Eintrag für die Zone abrufen. Wenn die delegierte Zone ebenfalls in Cloud DNS gehostet wird, können Sie den DS-Eintrag über die Google Cloud Console oder über die Google Cloud CLI abrufen.
Console
Rufen Sie in der Google Cloud Console die Seite Cloud DNS auf.
Gehen Sie zur verwalteten Zone, für die Sie den DS-Eintrag sehen möchten.
Klicken Sie rechts oben auf der Seite Zonendetails auf Einrichtung des Registrators, um den DS-Eintrag für die Zone aufzurufen.
Der DS-Eintrag ist auf der Seite Einrichtung des Registrators verfügbar.
Folgen Sie der Anleitung unter Eintrag hinzufügen, um NS-Einträge zu erstellen.
gcloud
Führen Sie den folgenden Befehl aus, um die DS-Eintragsinformationen für delegierte Subdomains abzurufen:
gcloud dns dns-keys list --zone EXAMPLE_ZONE
Ersetzen Sie
EXAMPLE_ZONEdurch den Namen der delegierten Subdomain-DNS-Zone in Ihrem Projekt.Die Ausgabe sieht so aus:
ID KEY_TAG TYPE IS_ACTIVE DESCRIPTION 0 1234 KEY_SIGNING True 1 12345 ZONE_SIGNING True
Sie benötigen die ID des KEY_SIGNING-Schlüssels (KSK), um einen vollständigen DS-Eintrag und alle Details des Schlüssels abzurufen. Dieser ist normalerweise null (0). Führen Sie folgenden Befehl aus:
gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \ --format "value(ds_record())"
Ersetzen Sie Folgendes:
EXAMPLE_ZONE: Name der delegierten Subdomain-DNS-Zone in Ihrem ProjektKSK_ID: die KSK-ID-Nummer, normalerweise 0
Die Ausgabe sieht dann ungefähr so aus:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
Kopieren Sie die Ausgabe des vorherigen Befehls, um sie in einem nachfolgenden Schritt zu verwenden.
Führen Sie den folgenden Befehl aus, um die Transaktion zu erstellen und die DS-Einträge für eine sichere Subdelegation zu erstellen:
gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
Ersetzen Sie
EXAMPLE_ZONEdurch den Namen der übergeordneten DNS-Zone in Ihrem Projekt, in der Sie die Datensätze für die delegierte Subdomain erstellen.Die Ausgabe sieht so aus:
Transaction started [transaction.yaml].
Führen Sie nun den folgenden Befehl aus, um einen Datensatz hinzuzufügen:
gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \ --ttl TIME_TO_LIVE \ --type DS \ --name subdomain.example.com \ "DS_RECORD_AND_KEY"
Ersetzen Sie Folgendes:
EXAMPLE_ZONE: Name der übergeordneten DNS-Zone in Ihrem ProjektTIME_TO_LIVE: Gültigkeitsdauer der Zone in Sekunden, z. B. 3.600subdomain.example.com: eine Subdomain des DNS-Namens der ZoneDS_RECORD_AND_KEY: DS-Eintrag und -Schlüssel, die Sie in Schritt 2 abgerufen haben, z. B.44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
Die Ausgabe sieht so aus:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb Record addition appended to transaction at [transaction.yaml].
Verwenden Sie den folgenden Befehl, um NS-Einträge hinzuzufügen:
gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \ --ttl TIME_TO_LIVE \ --type NS \ --name subdomain.example.com \
Ersetzen Sie Folgendes:
EXAMPLE_ZONE: Name der übergeordneten DNS-Zone in Ihrem ProjektTIME_TO_LIVE: Gültigkeitsdauer der Zone in Sekunden, z. B. 3.600subdomain.example.com: eine Subdomain des DNS-Namens der Zone
Geben Sie die folgenden RRData-Daten ein:
ns-cloud-e1.googledomains.com. \ ns-cloud-e2.googledomains.com. \ ns-cloud-e3.googledomains.com. \ ns-cloud-e4.googledomains.com.
Die Ausgabe sieht so aus:
Record addition appended to transaction at [transaction.yaml].
Führen Sie die Transaktion mit dem folgenden Befehl aus:
gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
Ersetzen Sie
EXAMPLE_ZONEdurch den Namen einer DNS-Zone in Ihrem Projekt.Die Ausgabe sieht so aus:
Executed transaction [transaction.yaml] for managed-zone [dns-example]. Created [https://dns.googleapis.com/dns/v1/projects/example/managedZones/example_zone/changes/42]. ID START_TIME STATUS 42 2019-08-08T23:12:49.100Z PENDING
Erweiterte Signaturoptionen verwenden
Wenn Sie DNSSEC für eine verwaltete Zone aktivieren oder eine verwaltete Zone mit DNSSEC erstellen, können Sie die DNSSEC-Signaturalgorithmen und den Typ der Abwesenheitsbestätigung auswählen.
Sie können die DNSSEC-Einstellungen für eine verwaltete Zone ändern, bevor Sie DNSSEC aktivieren, z. B. in den Algorithmus, der für das verschlüsselte Signieren von Einträgen verwendet wird. Wenn DNSSEC bereits für eine verwaltete Zone aktiviert ist, müssen Sie zuerst Änderungen an DNSSEC vornehmen, die notwendigen Änderungen vornehmen und anschließend mit dem folgenden Befehl DNSSEC wieder aktivieren:
gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on
Ersetzen Sie EXAMPLE_ZONE durch den Namen einer DNS-Zone in Ihrem Projekt.
Weitere Informationen finden Sie unter DNSSEC für verwaltete Zonen aktivieren.
Der folgende Befehl aktiviert DNSSEC mit 256-Bit-ECDSA und NSEC für die kleinsten DNSSEC-signierten Antwortpakete, die mit Cloud DNS möglich sind:
gcloud dns managed-zones update EXAMPLE_ZONE \ --dnssec-state on \ --ksk-algorithm ECDSAP256SHA256 --ksk-key-length 256 \ --zsk-algorithm ECDSAP256SHA256 --zsk-key-length 256 \ --denial-of-existence NSEC
Ersetzen Sie EXAMPLE_ZONE durch den Namen einer DNS-Zone in Ihrem Projekt.
Wenn Sie KSK- oder ZSK-Algorithmen oder Schlüssellängen festlegen, müssen Sie alle Elemente und ihre Argumente im Befehl angeben.
--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length
Unabhängig von den Algorithmen können Sie die Abwesenheitsbestätigung als NSEC oder NSEC3 angeben.
Die unterstützten Algorithmusoptionen und -argumente sind in der folgenden Tabelle aufgeführt. Die Verwendung anderer Algorithmen oder Parameter ist in Cloud DNS nicht zulässig.
| Algorithmus | KSK-Längen | ZSK-Längen | Kommentare |
|---|---|---|---|
| RSASHA256 | 2.048 | 1024, 2048 | |
| RSASHA512 | 2.048 | 1024, 2048 | Nicht allgemein unterstützt |
| ECDSAP256SHA256 | 256 | 256 | |
| ECDSAP384SHA384 | 384 | 384 | Nicht allgemein unterstützt |
Wenn kein Algorithmus angegeben ist, verwendet Cloud DNS diese Standardeinstellungen:
| Schlüsseltyp | Standardalgorithmus | Standardschlüssellänge |
|---|---|---|
| Schlüsselsignaturschlüssel (KSK) | RSASHA256 | 2.048 |
| Zonensignaturschlüssel (Zone Signing Key, ZSK) | RSASHA256 | 1024 |
Die Sicherheits- und Leistungsunterschiede zwischen RSASHA256 und RSASHA512 sind minimal und die Größen der signierten Antworten identisch. Die Länge der Schlüssel hat konkrete Auswirkungen. Längere Schlüssel sind langsamer und die entsprechenden Antworten umfangreicher (siehe Analysen der Antwortgrößen für die Root-Zone und die Top-Level-Domains (TLDs) sowie eine Analyse der serverseitigen Leistung unter Windows).
Die Resolver-Unterstützung für ECDSA ist auf neuere Systeme beschränkt. Ältere Resolver, die ECDSA-signierte Zonen nicht validieren können, werden als unsigniert angesehen, was unsicher sein kann, wenn Sie neue Eintragstypen verwenden, die auf DNSSEC beruhen. Die Registrierung von Registratoren und der Registrierung für 256-Bit-ECDSA-Erweiterungen sind üblich, aber nicht allgemein. Nur wenige Registrys und sogar weniger Registratoren unterstützen 384 Bit-ECDSA. Die Verwendung von ECDSA kann sinnvoll sein, wenn Sie keine älteren Clients unterstützen müssen. Die Signaturen sind weitaus kleiner und können schneller verarbeitet werden.
Vermeiden Sie in Ihren verwalteten Zonen die Verwendung unterschiedlicher Algorithmen für KSK und ZSK. Die Kompatibilität wird dadurch eingeschränkt und die Sicherheit kann beeinträchtigt werden. Bei einigen DNSSEC-validierenden Resolvern schlägt die Validierung für Zonen mit DNSKEY-Algorithmen fehl, wenn diese nicht zum Signieren aller Einträge in der Zone verwendet werden. Dies gilt, obwohl RFC 6840 sagt, dass keinesfalls erforderlich ist, dass alle Algorithmen im DNSKEY-Rhyset-Vorgang sind. Wenn dies kein Problem ist (die meisten validierenden Resolver befolgen RFC 6840), können Sie RSASHA256 für KSK und ECDSA für ZSK verwenden, wenn Ihr Domain-Registrator oder Ihre TLD-Registry ECDSA nicht unterstützt und Sie geringere Antwortgrößen benötigen.
NSEC3 ist der Standardtyp für die Abwesenheitsbestätigung. Er bietet eingeschränkten Schutz gegen "Zone Walker", die versuchen, die Einträge in Ihrer Zone zu ermitteln.
Die NSEC3PARAM-Einstellungen wurden korrigiert: NSEC3 opt-out ist aus Sicherheitsgründen deaktiviert und es gibt eine zusätzliche Hash-Wiederholung (insgesamt zwei) mit einer 64-Bit-Salt.
NSEC bietet etwas kleinere Antworten, jedoch keinen Schutz gegen "Zone Walker". Durch die Verwendung von NSEC können außerdem Abfragen nach nicht vorhandenen Domains reduziert werden. Google Public DNS und verschiedene andere DNSSEC-validierende Resolver können negative Antworten aus zwischengespeicherten NSEC-Einträgen synthetisieren, ohne Ihre Cloud DNS-Zone abzufragen.
Weitere Informationen zur Auswahl von Algorithmen finden Sie in RFC 8624.
Neue DNS-Datensatztypen mit DNSSEC-gesicherten Zonen verwenden
Nachdem Ihre Domain vollständig mit DNSSEC gesichert wurde, können Sie beginnen, verschiedene neue DNS-Datensatztypen zu verwenden, die die Authentizitäts- und Integritätsgarantien von DNSSEC-signierten Zonen nutzen, um die Sicherheit anderer Dienste zu erhöhen.
SSHFP
SSHFP-Datensätze enthalten einen Fingerabdruck des öffentlichen Schlüssels eines SSH-Servers, mit dem SSH-Clientanwendungen die SSH-Server validieren können. SSH-Clients erfordern in der Regel bei der ersten Verbindung eine Nutzerinteraktion zur Bestätigung des öffentlichen Schlüssels des Servers und geben Warnungen aus, wenn der Schlüssel geändert wird. Ein für die Verwendung von SSHFP konfigurierter SSH-Client verwendet für einen Server immer den Schlüssel im SSHFP-Datensatz des Servers. Nur Schlüssel für Server ohne SSHFP-Datensatz werden zur Wiederverwendung gespeichert.
Das SSHFP-Datensatzformat sieht so aus:
- Algorithmusnummer
- Nummer des Fingerabdrucktyps
- Serverschlüssel-Fingerabdruck
Es gibt folgende Algorithmusnummern für SSH:
- RSA
- DSA
- ECDSA
- ED25519
Es gibt folgende Fingerabdrucktypen:
- SHA-1 (veraltet, nur aus Kompatibilitätsgründen)
- SHA-256
StackExchange bietet Vorschläge zum Erstellen einer SSHFP-Konfiguration. Außerdem enthält es Tools, mit denen SSHFP-Konfigurationen durch das Scannen von Servern, die Verwendung vorhandener bekannter Hostdateien oder die Konfigurationsverwaltung erstellt werden können. Weitere Beispiele und Links finden Sie unter SSHFP-Einträge: DNS für öffentliche SSH-Hostschlüssel.
TLSA und DANE
TLSA-Datensätze enthalten Informationen, die für die Überprüfung von X.509-Zertifikaten (z. B. von HTTPS verwendete Zertifikate) verwendet werden können, ohne dass eine vorkonfigurierte Gruppe von Zertifizierungsstellen signiert ist.
Damit können Sie Ihre eigenen Zertifizierungsstellen einrichten und Zertifikate für HTTPS generieren. Dies ermöglicht auch die Überprüfung von Zertifikaten für Protokolle wie SMTP, wo es in der Regel keine Anwendungsunterstützung für vorkonfigurierte vertrauenswürdige Zertifizierungsstellen gibt.
DANE (Domain Authentication of Named Entities), das in RFC 6698 und zugehörigen RFC spezifiziert ist, verwendet TLSA-Datensätze auf bestimmte Weise, um zahlreiche Protokolle und Anwendungen zu sichern. Das IETF Journal und die Internet Society bieten einen hilfreichen Artikel zur Einführung sowie eine Übersicht über DANE.
HTTPS
DANE ermöglicht die sichere Konfiguration von HTTPS-Servern mithilfe von Zertifikaten, die Sie mit Ihrer eigenen Zertifizierungsinfrastruktur auf Basis von OpenSSL oder CFSSL von Cloudflare erstellt haben.
Der DANE Validator für HTTPS-Server von SIDNLabs ist zum Testen einer DANE-Bereitstellung für HTTPS nützlich.
TLS-Zertifikatsüberprüfung für SMTP (E-Mail)
Das SMTP-E-Mail-Protokoll ist anfällig für Downgrade-Angriffe, die die Verschlüsselung deaktivieren. DANE bietet eine Möglichkeit, diese Angriffe zu verhindern.
Die Internet Society hat ein zweiteiliges Tutorial über die Verwendung von DANE für SMTP mit den kostenlosen und automatisierten Zertifikaten von Let's Encrypt herausgegeben, einschließlich Ratschlägen, bestimmte TLSA-Eintragsformate nicht mit Let's Encrypt-Zertifikaten zu verwenden:
Unter Häufige Fehler finden Sie äußerst hilfreiche Hinweise sowie einen Domain-Validator für HTTPS und SMTP speziell für DANE. Mit dem Test Ihrer E-Mail-Validierung wird DANE ebenfalls überprüft.
TLS-Zertifikatsüberprüfung für XMPP (Jabber-Chat)
XMPP und andere Dienste, die SRV-Einträge verwenden, können DANE ebenfalls nutzen. In einem XMPP-Beispiel wird eine DANE-SRV-Konfiguration gemäß RFC 7673 verwendet.
Public Key Association für TXT (OpenPGP/GnuPG)
TXT-Einträge können ohne DNSSEC verwendet werden, allerdings belegt die DNSSEC-Signatur die Authentizität der TXT-Einträge. Dies ist wichtig für die DNS-basierte Veröffentlichung von öffentlichen OpenPGP-/GnuPG-Schlüsseln, die nicht von bekannten Stellen wie X.509-CAs signiert sind.
Wenn Alice zum Beispiel einen TXT-Eintrag wie den folgenden in der DNSSEC-signierten an.example-Zone veröffentlicht und eine Kopie des ASCII-gepanzerten öffentlichen Schlüssels unter der angegebenen URI hostet, kann Bob mit angemessener Sicherheit einen OpenPGP-Schlüssel für alice@an.example nachschlagen (dies ist kein Ersatz für die Web-of-Trust-Validierung, sondern ermöglicht die OpenPGP-Verschlüsselung mit bisher unbekannten Parteien):
alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"
Sie können diese instructions verwenden, um diese PKA TXT-Datensätze der Version 1 (wie sie in Publishing Keys in DNS genannt werden) zu erzeugen.
Im vollständigen Leitfaden zum Veröffentlichen von PGP-Schlüsseln in DNS wird erläutert, wie OpenPGP-CERT-Einträge erstellt werden. Cloud DNS unterstützt jedoch nicht den Eintrag CERT oder OPENPGPKEY.
Wenn Sie Ihren OpenPGP-Schlüssel unter Keybase.io registriert haben, müssen Sie den Schlüssel nicht auf Ihrem eigenen Server hosten. Stattdessen können Sie eine URL wie https://keybase.io/KEYBASE_USERNAME/key.asc verwenden (ersetzen Sie KEYBASE_USERNAME durch Ihren Keybase.io-Nutzernamen).
Wenn Sie Ihren OpenPGP-Schlüssel auf einen Schlüsselserver hochgeladen haben, können Sie auch einen "hkp: URI" für diesen Schlüsselserver verwenden, z. B. hkp://subkeys.pgp.net oder hkp://pgp.mit.edu. Dies gilt auch, wenn Nutzer hinter Firewalls, die Port 11371 blockieren, diese möglicherweise nicht erreichen können. Einige Schlüsselserver stellen HTTP-URLs für Port 80 bereit.
TXT (SPF, DKIM und DMARC)
Es gibt drei andere Arten von TXT-Einträgen, die Sie verwenden können, um Ihre E-Mail-Dienste zu sichern und um zu verhindern, dass Spammer oder Betrüger E-Mails senden, die scheinbar aus Ihrer Domain stammen.
SPF: Gibt die SMTP-Server (nach Domainname oder IP-Adresse) an, die E-Mails für eine Domain senden können.
DKIM: Veröffentlicht eine Reihe öffentlicher Schlüssel, mit denen verifiziert wird, dass E-Mails von einer Domain gesendet werden, und verhindert, dass Nachrichten während der Übertragung geändert werden.
DMARC Legt Domainrichtlinien und die Berichterstellung für die SPF- und DKIM-Prüfung sowie die Inhalte von Fehlerberichten fest.
Mit dem E-Mail-Validator testen können Sie prüfen, ob Ihre Domain ordnungsgemäß für die Verwendung aller drei dieser Eintragstypen konfiguriert ist. Nützliche Tipps zur Konfiguration von SPF-Einträgen finden Sie unter Häufige Fehler – FAQ.
Andere durch DNSSEC optimierte Datensatztypen
Neben TXT gibt es einige andere Datensatztypen, die von DNSSEC profitieren, auch wenn DNSSEC für sie nicht erforderlich ist.
CAA
Mit CAA-Datensätzen (Certification Authority Authorization) können Sie steuern, welche öffentlichen CAs TLS- oder andere Zertifikate für Ihre Domain erzeugen können. Diese Steuerung ist besonders nützlich (und wirksam), wenn Sie dafür sorgen möchten, dass eine öffentliche Zertifizierungsstelle, die domainvalidierte (DV-) Zertifikate ausstellt (wie LetsEncrypt.org), nicht für Ihre Domain aus.
Ein typischer CAA-Datensatz hat ein einfaches Format wie 0 issue "best-ca.example", sodass die best-ca.example-CA (und keine andere CA) Zertifikate für Namen in der Domain ausstellen kann, in der sich der CAA-Datensatz befindet.
Wenn Sie mehrere Zertifizierungsstellen zulassen möchten, erstellen Sie mehrere CAA-Einträge.
RFC 6844 enthält weitere Details zur Verwendung des CAA-Datensatztyps und empfiehlt dringend die Verwendung von DNSSEC.
IPSECKEY
Sie können auch die opportunistische Verschlüsselung über IPsec-Tunnel aktivieren, indem Sie IPSECKEY-Datensätze veröffentlichen. Die IPsec-VPN-Implementierung strongSwan enthält ein Plug-in, das IPSECKEY-Einträge verwendet.
Neben der Platzierung der IPSECKEY-Datensätzen in den üblichen Forward-Zonen, z. B. service.example.com, verlangt RFC 4025, Abschnitt 1.2, dass Sicherheitsgateways auch in den Reverse-Zonen ip6.arpa und in-addr.arpa nach IPSECKEY-Datensätzen suchen.
Die DNSSEC-Unterstützung ist für Reverse-Zonen weniger verbreitet als für Forward-Zonen und erfordert einen Internetanbieter (ISP), der DNSSEC implementiert. Es gibt jedoch einige Internetanbieter, die DNSSEC für Reverse-Zonendelegationen unterstützen.
Reverse-Zonen für externe IP-Adressen der Compute Engine-VM unterstützen noch keine Delegierung.
Nächste Schritte
- Informationen zum Erstellen, Aktualisieren, Auflisten und Löschen verwalteter Zonen finden Sie unter Zonen verwalten.
- Informationen zu Lösungen für häufige Probleme, die bei der Verwendung von Cloud DNS auftreten können, finden Sie unter Fehlerbehebung.
- Eine Übersicht über Cloud DNS finden Sie in der Cloud DNS-Übersicht.