Erweitertes DNSSEC verwenden

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 Abwesenheitsbestätigungen bis hin zur Verwendung von Eintragstypen, 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

  1. Rufen Sie in der Google Cloud Console die Seite Cloud DNS auf.

    Zu Cloud DNS

  2. Gehen Sie zu der verwalteten Zone, deren DS-Eintrag Sie sehen möchten.

  3. Klicken Sie rechts oben auf der Seite Zonendetails auf Einrichtung des Registrars, um den DS-Eintrag für die Zone aufzurufen.

  4. Der DS-Eintrag ist auf der Seite Einrichtung des Registrars verfügbar.

  5. Folgen Sie der Anleitung unter Einträge hinzufügen, aktualisieren und löschen, um NS-Einträge zu erstellen.

Einrichtungsseite für Registrare

gcloud

  1. Führen Sie den folgenden Befehl aus, um die DS-Eintragsinformationen für delegierte Subdomains abzurufen:

    gcloud dns dns-keys list --zone SUBDOMAIN_ZONE

    Ersetzen Sie SUBDOMAIN_ZONE durch den Namen der delegierten Subdomain-DNS-Zone in Ihrem Projekt.

    Die Ausgabe sieht etwa so aus: 

    ID  KEY_TAG  TYPE          IS_ACTIVE  DESCRIPTION
0   1234     KEY_SIGNING   True
1   12345    ZONE_SIGNING  True

  2. 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 SUBDOMAIN_ZONE KSK_ID \
   --format "value(ds_record())"

    Ersetzen Sie Folgendes:

    • SUBDOMAIN_ZONE: der Name der delegierten Subdomain-DNS-Zone in Ihrem Projekt
    • KSK_ID: die KSK-ID-Nummer, normalerweise 0

    Die Ausgabe sieht dann ungefähr so aus:

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

  3. Kopieren Sie die Ausgabe des vorherigen Befehls, um sie in einem nachfolgenden Schritt zu verwenden.

  4. Führen Sie den folgenden Befehl aus, um die Transaktion zu starten und die DS-Einträge für eine sichere Subdelegation zu erstellen:

    gcloud dns record-sets transaction start --zone PARENT_ZONE

    Ersetzen Sie PARENT_ZONE durch den Namen der übergeordneten DNS-Zone in Ihrem Projekt, in der Sie die Datensätze für die delegierte Subdomain erstellen.

    Die Ausgabe sieht etwa so aus: 

    Transaction started [transaction.yaml].

  5. Führen Sie nun den folgenden Befehl aus, um einen Eintragssatz hinzuzufügen:

    gcloud dns record-sets transaction add --zone PARENT_ZONE \
   --ttl TIME_TO_LIVE \
   --type DS \
   --name subdomain.example.com \
   "DS_RECORD_AND_KEY"

    Ersetzen Sie Folgendes:

    • PARENT_ZONE: Name der übergeordneten DNS-Zone in Ihrem Projekt
    • TIME_TO_LIVE: Gültigkeitsdauer der Zone in Sekunden, z. B. 3600
    • subdomain.example.com: Subdomain des DNS-Namens der Zone
    • DS_RECORD_AND_KEY: DS-Eintrag und -Schlüssel, die Sie in Schritt 2 abgerufen haben, z. B. 44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

    Die Ausgabe sieht etwa so aus: 

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
Record addition appended to transaction at [transaction.yaml].

  6. Verwenden Sie den folgenden Befehl, um NS-Einträge hinzuzufügen:

    gcloud dns record-sets transaction add --zone PARENT_ZONE \
   --ttl TIME_TO_LIVE \
   --type NS \
   --name subdomain.example.com \

    Ersetzen Sie Folgendes:

    • PARENT_ZONE: Name der übergeordneten DNS-Zone in Ihrem Projekt
    • TIME_TO_LIVE: Gültigkeitsdauer der Zone in Sekunden, z. B. 3600
    • subdomain.example.com: Subdomain des DNS-Namens der Zone

  7. 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 etwa so aus: 

    Record addition appended to transaction at [transaction.yaml].

  8. Führen Sie die Transaktion mit dem folgenden Befehl aus:

    gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE

    Ersetzen Sie EXAMPLE_ZONE durch den Namen einer DNS-Zone in Ihrem Projekt.

    Die Ausgabe sieht etwa 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 zum Vornehmen von Änderungen zuerst DNSSEC deaktivieren, 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 vorhandene verwaltete öffentliche Zonen aktivieren.

Dieser Befehl aktiviert DNSSEC mit 256-Bit-ECDSA bzw. -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. Cloud DNS lässt keine anderen Algorithmen oder Parameter zu.

Algorithmus KSK-Längen ZSK-Längen Kommentare
RSASHA256 2.048 1.024, 2.048
RSASHA512 2.048 1.024, 2.048 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 1.024

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 in den Informationen zu Windows).

Die Resolver-Unterstützung für ECDSA ist auf neuere Systeme beschränkt. Ältere Resolver, die ECDSA-signierte Zonen nicht validieren können, betrachten diese als unsigniert. Das kann unsicher sein, wenn Sie neue Eintragstypen verwenden, die auf DNSSEC beruhen. Registrare und die Registry für 256-Bit-ECDSA werden oft unterstützt, aber nicht immer. Nur wenige Registrys und sogar weniger Registrare 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 besagt, dass sie keinesfalls darauf bestehen dürfen, dass alle Algorithmen im DNSKEY-Ressourcendatensatz funktionieren. 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-Registrar 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 vor „Zone Walkers“, die versuchen, alle 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 einem 64-Bit-Salt-Wert.

NSEC bietet etwas kleinere Antworten, jedoch keinen Schutz gegen „Zone Walker“. Durch die Verwendung von NSEC können außerdem Abfragen von 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 unter RFC 8624.

Neue DNS-Eintragstypen mit DNSSEC-gesicherten Zonen verwenden

Nachdem Ihre Domain vollständig mit DNSSEC gesichert wurde, können Sie beginnen, verschiedene neue DNS-Eintragstypen zu verwenden. Diese nutzen die Authentizitäts- und Integritätsgarantien von DNSSEC-signierten Zonen, 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-Eintrag des Servers. Nur Schlüssel für Server ohne SSHFP-Eintrag werden zur Wiederverwendung gespeichert.

Das Format des SSHFP-Eintrags sieht so aus:

  • Algorithmusnummer
  • Nummer des Fingerabdrucktyps
  • Serverschlüssel-Fingerabdruck

Es gibt folgende Algorithmusnummern für SSH:

  1. RSA
  2. DSA
  3. ECDSA
  4. 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 records: DNS providing public ssh host keys.

TLSA und DANE

TLSA-Einträge enthalten Informationen, die für die Überprüfung von X.509-Zertifikaten (z. B. von HTTPS verwendete Zertifikate) verwendet werden können, ohne dass sie von einer Zertifizierungsstelle aus einer vorkonfigurierten Gruppe von Zertifizierungsstellen signiert werden müssen.

Damit können Sie eigene 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), wie in RFC 6698 und zugehörigen RFCs spezifiziert, verwendet TLSA-Einträge auf eine bestimmte Weise, um zahlreiche Protokolle und Anwendungen zu sichern. Das IETF Journal und die Internet Society bieten einen hilfreichen Einführungsartikel 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 für das Testen einer DANE-Bereitstellung für HTTPS hilfreich.

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 Common Mistakes finden Sie äußerst hilfreiche Hinweise sowie einen DANE-Domain-Validator für HTTPS und SMTP. 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 ebenfalls DANE nutzen. In einem XMPP-Beispiel wird eine DANE-SRV-Konfiguration nach 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-Zertifizierungsstellen 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 Anweisungen verwenden, um diese PKA TXT-Datensätze der Version 1 (wie sie in Publishing Keys in DNS genannt werden) zu erzeugen.

Unter The complete guide to publishing PGP keys in DNS wird erläutert, wie OpenPGP-CERT-Einträge erstellt werden. Cloud DNS unterstützt jedoch keine CERT- oder OPENPGPKEY-Einträge.

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. Nutzer hinter Firewalls, die Port 11371 blockieren, können diese aber möglicherweise nicht erreichen. 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 Test Ihres E-Mail-Validators können Sie prüfen, ob Ihre Domain ordnungsgemäß für die Verwendung dieser drei Eintragstypen konfiguriert ist. Nützliche Tipps zur Konfiguration von SPF-Einträgen finden Sie hier.

Andere durch DNSSEC optimierte Eintragssatztypen verwenden

Neben TXT gibt es einige andere Eintragssatztypen, die von DNSSEC profitieren, auch wenn DNSSEC für sie nicht erforderlich ist.

CAA

Mit CAA-Eintragssätzen (Certification Authority Authorization) können Sie steuern, welche öffentlichen CAs TLS- oder andere Zertifikate für Ihre Domain erzeugen können. Dies ist besonders hilfreich (und wirksam), wenn Sie dafür sorgen möchten, dass eine öffentliche Zertifizierungsstelle, die domainvalidierte bzw. DV-Zertifikate (wie LetsEncrypt.org) ausstellt, keine Zertifikate für Ihre Domain ausstellt.

Ein typischer CAA-Eintragssatz 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-Eintragssatz befindet. Wenn mehrere Zertifizierungsstellen Zertifikate ausstellen sollen, erstellen Sie mehrere CAA-Einträge.

RFC 6844 enthält weitere Details zur Verwendung des CAA-Eintragssatztyps und empfiehlt dringend die Verwendung von DNSSEC.

IPSECKEY

Sie können auch die opportunistische Verschlüsselung über IPSEC-Tunnel aktivieren, indem Sie IPSECKEY-Einträge veröffentlichen. Die IPSEC-VPN-Implementierung StrongSwan enthält ein Plug-in, das IPSECKEY-Einträge verwendet.

Neben der Platzierung der IPSECKEY-Einträge 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-Einträgen 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-Zonendelegierungen unterstützen.

Reverse-Zonen für externe IP-Adressen der Compute Engine-VM unterstützen noch keine Delegierung.

Nächste Schritte