Erweitertes DNSSEC

Es gibt mehrere erweiterte DNSSEC-Konfigurationsoptionen, die Sie verwenden können, wenn Sie DNSSEC für Ihre verwalteten Zonen aktivieren. Diese reichen von verschiedenen Signaturalgorithmen und dem Bestätigen der Abwesenheit bis hin zur Fähigkeit der Verwendung von Datensatztypen, für deren Verwendung DNSSEC erforderlich ist oder empfohlen wird. Sie werden im Folgenden beschrieben. Hinweis: Ein Großteil der in diesem Dokument verlinkten Seiten steht nur auf Englisch zur Verfügung.

DNSSEC-signierte Subdomains delegieren

Sobald Sie DNSSEC für Ihre primäre Domain aktiviert haben, besteht die Möglichkeit, DNSSEC für delegierte Subdomains zu aktivieren. Erstellen Sie zuerst einen DS-Eintrag in einer Cloud DNS-Zone, um DNSSEC für delegierte Subdomains zu aktivieren. Außerdem müssen Sie einen oder mehrere NS-Einträge erstellen. Eine Anleitung zum Erstellen von NS-Einträgen finden Sie unter Eintrag hinzufügen oder entfernen.

Console

Um DS-Einträge für delegierte Subdomains zu erstellen, müssen Sie den DS-Eintrag für die Zone abrufen. Wenn die delegierte Zone auch in Cloud DNS gehostet wird, können Sie den DS-Eintrag von der Cloud Console abrufen.

  1. Rufen Sie die verwaltete Zone auf.
  2. Um den DS-Eintrag für die Zone anzuzeigen, klicken Sie auf den Link Registrar Setup oben rechts auf der Seite Zone details.
  3. Nachdem Sie die DS-Eintragsinformationen erfasst haben, fahren Sie mit Schritt 2 des Tabs gcloud fort.

Pop-up-Fenster für die Registratoreinrichtung

gcloud

  1. 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 die folgende Befehlsoption:

    • example_zone: der Name einer 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
    

  2. Sie benötigen die ID des KEY_SIGNING Key (CSK), die normalerweise null (0) ist, um einen vollständigen DS-Eintrag und alle Details des Schlüssels zu erhalten. Verwenden Sie den folgenden Befehl:

    $ gcloud dns dns-keys describe --zone example_zone ksk_id \
     --format "value(ds_record())"
    

    Ersetzen Sie dabei die folgenden Befehlsoptionen:

    • example_zone: der Name einer DNS-Zone in Ihrem Projekt
    • ksk_id: die ID-Nummer, normalerweise 0

    Die Ausgabe sieht so aus:

    1234 7 1 2FD4E1C67A2D28FCED849EE1BB76E7391B93EB12
    
  3. Starten Sie die Transaktion mit dem folgenden Befehl, um die DS-Einträge für eine sichere Subdelegation zu erstellen:

    $ gcloud dns record-sets transaction start -z example_zone
    

    Ersetzen Sie dabei die folgenden Befehlsoptionen:

    • example_zone: der Name einer DNS-Zone in Ihrem Projekt
    • subdomain.example.com: eine Subdomain des DNS-Namens der Zone

    Die Ausgabe sieht so aus:

    Transaction started [transaction.yaml].
    

  4. Fügen Sie anschließend mit dem folgenden Befehl eine Eintragsgruppe hinzu:

    $ gcloud dns record-sets transaction add -z example_zone \
     --ttl 3600 --type DS --name subdomain.example.com \
    

    Ersetzen Sie dabei die folgenden Befehlsoptionen:

    • example_zone: der Name einer DNS-Zone in Ihrem Projekt
    • subdomain.example.com: eine Subdomain des DNS-Namens der Zone

    Die Ausgabe sieht so aus:

    36283 5 1 0173d13977ffdf12716E3A1225B1B0B639B8CB46
    Record addition appended to transaction at [transaction.yaml].
    

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

    $ gcloud dns record-sets transaction add -z example_zone \
     --ttl 3600 --type NS --name subdomain.example.com \
    

    Ersetzen Sie dabei die folgenden Befehlsoptionen:

    • example_zone: der Name einer DNS-Zone in Ihrem Projekt
    • subdomain.example.com: eine Subdomain des DNS-Namens der Zone
  6. Geben Sie die folgenden RData-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].
    

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

    $ gcloud dns record-sets transaction execute -z example_zone
    

    Ersetzen Sie die folgende Befehlsoption:

    • example_zone: der Name einer DNS-Zone in Ihrem Projekt

    Die Ausgabe sieht so aus:

    Executed transaction [transaction.yaml] for managed-zone [dns-example].
    Created     [https://www.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

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, deaktivieren Sie zuerst DNSSEC, nehmen Sie die erforderlichen Änderungen vor und aktivieren Sie DNSSEC dann mit diesem Befehl noch einmal (ersetzen Sie example_zone durch den Namen einer DNS-Zone in Ihrem Projekt):

gcloud dns managed-zones update example_zone --dnssec-state on

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. Ersetzen Sie example_zone durch den Namen einer DNS-Zone in Ihrem Projekt:

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

Wenn Sie KSK- oder ZSK-Algorithmen oder Schlüssellängen festlegen, müssen Sie alle Elemente (--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length) und ihre Argumente im Befehl angeben. Unabhängig von den Algorithmen können Sie die Abwesenheitsbestätigung als NSEC oder NSEC3 festlegen.

In der folgenden Tabelle sind die unterstützten Algorithmusoptionen und -argumente aufgeführt. Es werden die Standardeinstellungen sowie die schwachen Werte angegeben, die nur auf Anfrage verfügbar sind:

Algorithmus KSK-Längen ZSK-Längen Anmerkungen
RSASHA1 1024, 2048 1024, 2048 SHA-1 gilt als schwach
RSASHA256 1024, 2048 1024, 2048
RSASHA512 1024, 2048 1024, 2048 Nicht allgemein unterstützt
ECDSAP256SHA256 256 256 Wird möglicherweise nicht unterstützt
ECDSAP384SHA384 384 384 Nicht allgemein unterstützt

RSASHA1 sollten Sie nur dann verwenden, wenn es für die Kompatibilität erforderlich ist. Die Nutzung längerer Schlüssel erhöht die Sicherheit nicht.

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 Clientunterstützung für ECDSA ist auf neuere Systeme beschränkt. Ältere Clients können ECDSA-signierte Zonen nicht validieren und behandeln sie als unsigniert. Dies kann unsicher sein, wenn Sie neue Datensatztypen verwenden, die auf DNSSEC beruhen. Die Registrator- und Registry-Unterstützung für 256-Bit-ECDSA ist gängig, aber nicht immer vorhanden. 384-Bit-ECDSA wird nur von wenigen Registrys und von noch weniger Registratoren unterstützt. 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 sein. Für einige DNSSEC-validierende Resolver 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 ist der Fall, obwohl in RFC 6840 angegeben ist, dass die Resolver "nicht 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-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: Die Deaktivierung von NSEC3 wurde aus Sicherheitsgründen deaktiviert und es gibt eine zusätzliche Hash-Wiederholung (also insgesamt 2) mit einem 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 die Cloud DNS-Zone abzufragen.

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 und können von SSH-Clientanwendungen zum Überprüfen der SSH-Server verwendet werden. 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 lautet: Algorithmusnummer, Nummer des Fingerabdrucktyps und Fingerabdruck des Serverschlüssels. Es gibt folgende Algorithmusnummern für SSH:

  1. RSA
  2. DSA
  3. ECDSA
  4. ED25519

Es gibt folgende Fingerabdrucktypen:

  1. SHA-1 (veraltet, nur aus Kompatibilitätsgründen)
  2. 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. In diesen Hinweisen finden Sie weitere Beispiele und Links.

TLSA und DANE

TLSA-Datensätze enthalten Informationen, die für die Überprüfung von X.509-Zertifikaten (wie z. B. bei HTTPS) verwendet werden können, ohne dass diese von einer vorkonfigurierten Gruppe von Zertifizierungsstellen signiert sein müssen. Auf diese Weise können Sie Ihre eigenen Zertifizierungsstellen einrichten und Zertifikate für HTTPS erzeugen sowie die Überprüfung von Zertifikaten für Protokolle wie SMTP zulassen, wenn regulär keine Anwendungsunterstützung für vorkonfigurierte vertrauenswürdige Zertifizierungsstellen besteht.

DANE (Domain Authentication of Named Entities), das in RFC 6698 und zugehörigen RFC spezifiziert ist, verwendet TLSA-Datensätze auf eine 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 Zertifizierungsstelle anhand 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 E-Mail-Protokoll SMTP ist besonders anfällig für Downgrade-Angriffe, die die Verschlüsselung deaktivieren. Mit DANE können diese Angriffe verhindert werden. Die Internet Society bietet eine Anleitung in zwei Teilenzur Verwendung von DANE für SMTP mit den kostenlosen und automatisierten Zertifikaten von Let's Encrypt. Folgen Sie den Empfehlungen und verwenden Sie bestimmte TLSA-Datensatzformate nicht mit Zertifikaten von "Let's Encrypt".

Unter https://dane.sys4.de/common_mistakes finden Sie äußerst hilfreiche Hinweise sowie einen Domain-Validator für HTTPS und SMTP speziell für DANE. Sie können DANE auch mit dem Validator "Test your email" prüfen.

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 z. B. Alice in der DNSSEC-signierten Zone an.example einen TXT-Eintrag wie

alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"

veröffentlicht und eine Kopie des öffentlichen Schlüssels im ASCII-Format unter dem angegebenen URI hostet, kann Bob einen OpenPGP-Schlüssel für alice@an.example bei angemessener Sicherheit aufrufen. Diese Methode ist kein Ersatz für die Web-of-Trust-Validierung, ermöglicht aber eine OpenPGP-Verschlüsselung mit zuvor unbekannten Parteien.

Anhand dieser Anleitung können Sie die TXT-Einträge "PKA Version 1", wie sie in der Übersicht über Schlüssel in DNS bezeichnet werden, generieren. In einer weiteren Anleitung wird erläutert, wie OpenPGP-CERT-Datensätze erstellt werden. Allerdings werden weder CERT- noch OPENPGPKEY-Datensätze von Cloud DNS unterstützt.

Wenn Sie Ihren OpenPGP-Schlüssel unter Keybase.io registriert haben, müssen Sie den Schlüssel nicht auf Ihrem eigenen Server hosten und können einfach eine URL wie https://keybase.io/KEYBASE_USERNAME/key.asc verwenden. KEYBASE_USERNAME wird dabei durch Ihren Keybase.io-Nutzernamen ersetzt. 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 verwendet werden 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
Legt die SMTP-Server fest (anhand Domainname oder IP-Adresse), die E-Mail-Nachrichten für eine Domain senden können.
DKIM
Veröffentlicht eine Reihe von öffentlichen Schlüsseln, mit denen geprüft wird, ob eine E-Mail von einer bestimmten Domain gesendet wurde, und verhindert, dass Nachrichten bei der Übertragung verändert werden.
DMARC
Legt Domainrichtlinien und die Berichterstellung für die SPF- und DKIM-Prüfung sowie die Inhalte von Fehlerberichten fest.

Sie können mit dem Validator "Test your email" prüfen, ob Ihre Domain ordnungsgemäß für die Verwendung aller drei dieser Datensatztypen konfiguriert ist. In den FAQ zu häufigen Fehlern finden Sie hilfreiche Hinweise zur Konfiguration von SPF-Einträgen.

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 Zertifizierungsstellen 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-Datensatz hat ein einfaches Format wie 0 issue "best-ca.example". Mit diesem Beispiel wird nur der Zertifizierungsstelle "best-ca.example" erlaubt, Zertifikate für Namen in der Domain auszustellen, in der sich der CAA-Datensatz befindet. Wenn Sie mehreren Zertifizierungsstellen das Ausstellen von Zertifikaten erlauben möchten, erstellen Sie einfach mehrere CAA-Datensätze.

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 und dazu IPSECKEY-Datensätze veröffentlichen. Die IPSEC-VPN-Implementierung StrongSwan enthält ein Plug-in, das IPSECKEY-Datensätze 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, der selbst DNSSEC implementiert. Es gibt jedoch einige Anbieter, die DNSSEC für Reverse-Zonendelegationen unterstützen.

Beachten Sie, dass Reverse-Zonen für externe IPs der Google Compute Engine-VM das Delegieren noch nicht unterstützen. Weitere Informationen finden Sie in den Funktionsanfragen zur Google Compute Engine.

Weitere Informationen