Utiliser le protocole DNSSEC avancé

Cette page décrit plusieurs options de configuration avancées du protocole DNSSEC (Domain Name System Security Extensions) que vous pouvez utiliser si vous souhaitez l'activer pour vos zones gérées. Ces options comprennent différents algorithmes de signature et le déni d'existence, ainsi que la possibilité d'utiliser des types d'enregistrements pour lesquels DNSSEC est requis ou recommandé.

Pour obtenir une présentation des concepts liés à DNSSEC, consultez la présentation de DNSSEC.

Déléguer des sous-domaines signés DNSSEC

Vous pouvez activer DNSSEC pour les sous-domaines délégués après l'avoir activé pour votre domaine principal. Pour activer DNSSEC pour les sous-domaines délégués, créez d'abord un enregistrement DS dans une zone Cloud DNS. Vous devez également créer un ou plusieurs enregistrements NS.

Pour créer des enregistrements DS pour des sous-domaines délégués, vous devez obtenir l'enregistrement DS de la zone. Si la zone déléguée est également hébergée dans Cloud DNS, vous pouvez obtenir l'enregistrement DS depuis Google Cloud Console ou la Google Cloud CLI.

Console

1. Dans Google Cloud Console, accédez à la page Cloud DNS.

   Accéder à Cloud DNS

2. Accédez à la zone gérée pour laquelle vous souhaitez consulter l'enregistrement DS.

3. Pour afficher l'enregistrement DS de la zone, cliquez sur Configuration du service d'enregistrement dans l'angle supérieur droit de la page Informations sur la zone.

4. L'enregistrement DS est disponible sur la page Configuration du service d'enregistrement.

5. Pour créer des enregistrements NS, suivez les instructions de la section Ajouter un enregistrement.

gcloud

1. Pour obtenir les informations sur l'enregistrement DS des sous-domaines délégués, exécutez la commande suivante :

   gcloud dns dns-keys list --zone EXAMPLE_ZONE
   

   Remplacez EXAMPLE_ZONE par le nom de la zone DNS du sous-domaine délégué dans votre projet.

   La sortie ressemble à ceci :

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

2. Pour obtenir un enregistrement DS complet et tous les détails de la clé, vous avez besoin de l'ID de la clé KEY_SIGNING (KSK), qui est généralement zéro (0). Exécutez la commande suivante :

   gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \
      --format "value(ds_record())"
   

   Remplacez l'élément suivant :

   • EXAMPLE_ZONE : nom de la zone DNS du sous-domaine délégué dans votre projet
   • KSK_ID : ID de la clé KSK, généralement 0

   La sortie ressemble à ceci :

   44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
   

3. Copiez le résultat de la commande précédente pour l'utiliser lors d'une étape ultérieure.

4. Pour créer les enregistrements DS d'une sous-délégation sécurisée, exécutez la commande suivante pour démarrer la transaction :

   gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
   

   Remplacez EXAMPLE_ZONE par le nom de la zone DNS parente de votre projet dans laquelle vous créez les enregistrements du sous-domaine délégué.

   La sortie ressemble à ceci :

   Transaction started [transaction.yaml].
   

5. Exécutez ensuite la commande suivante pour ajouter un jeu d'enregistrements :

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

   Remplacez l'élément suivant :

   • EXAMPLE_ZONE : nom de la zone DNS parente dans votre projet
   • TIME_TO_LIVE : durée de vie de la zone (en secondes), par exemple 3 600
   • subdomain.example.com : sous-domaine du nom DNS de la zone
   • DS_RECORD_AND_KEY : enregistrement DS et la clé obtenus à l'étape 2, par exemple 44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

   La sortie ressemble à ceci :

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

6. Pour ajouter des enregistrements NS, utilisez la commande suivante :

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

   Remplacez l'élément suivant :

   • EXAMPLE_ZONE : nom de la zone DNS parente dans votre projet
   • TIME_TO_LIVE : durée de vie de la zone (en secondes), par exemple 3 600
   • subdomain.example.com : sous-domaine du nom DNS de la zone

7. Saisissez les RRData suivantes :

   ns-cloud-e1.googledomains.com. \
   ns-cloud-e2.googledomains.com. \
   ns-cloud-e3.googledomains.com. \
   ns-cloud-e4.googledomains.com.
   

   Remarque:Le choix des serveurs de noms pour l'enregistrement NS dépend la partition de serveur de noms à laquelle le sous-domaine délégué a été attribué où il a été créé. Ces informations sont visibles dans Boîte de dialogue Configuration du service d'enregistrement : les enregistrements DS et NS nécessaires les détails s'affichent ensemble.

   La sortie ressemble à ceci :

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

8. Pour exécuter la transaction, utilisez la commande suivante :

   gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
   

   Remplacez EXAMPLE_ZONE par le nom d'une zone DNS dans votre projet :

   La sortie ressemble à ceci :

   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
   

Utiliser les options de signature avancées

Lorsque vous activez DNSSEC pour une zone gérée ou créez une zone gérée avec DNSSEC, vous pouvez sélectionner les algorithmes de signature DNSSEC et le type de déni d'existence.

Vous pouvez modifier les paramètres DNSSEC (par exemple, l'algorithme utilisé pour signer les enregistrements par procédé cryptographique) pour une zone gérée avant d'activer DNSSEC. Si DNSSEC est déjà activé pour une zone gérée, désactivez-le, effectuez les modifications requises, puis exécutez la commande suivante pour réactiver DNSSEC :

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

Remplacez EXAMPLE_ZONE par le nom d'une zone DNS dans votre projet :

Pour plus d'informations, consultez la page Activer DNSSEC pour les zones gérées existantes.

Remarque : Si vous souhaitez résoudre les problèmes liés à votre domaine lorsque DNSSEC est désactivé, vous devez d'abord le désactiver pour votre domaine auprès de votre service d'enregistrement de noms de domaine afin de vous assurer que les résolveurs de validation DNSSEC peuvent toujours résoudre les noms dans la zone. Pour plus d'informations, reportez-vous à la page Désactiver DNSSEC pour les zones gérées.

La commande suivante active DNSSEC avec ECDSA 256 bits et NSEC pour les paquets de réponses signés DNSSEC possibles avec Cloud DNS.

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

Remplacez EXAMPLE_ZONE par le nom d'une zone DNS dans votre projet :

Si vous fournissez des algorithmes KSK ou ZSK ou des longueurs de clé, vous devez tous les spécifier dans la commande, ainsi que leurs arguments.

--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length

Vous pouvez spécifier le déni d'existence en tant que NSEC ou NSEC3 indépendamment des algorithmes.

Les options et les arguments acceptés des algorithmes sont présentés dans le tableau ci-dessous. Cloud DNS n'autorise l'utilisation d'aucun autre algorithme ou paramètre.

Algorithme	Longueurs KSK	Longueurs ZSK	Commentaires
RSASHA256	2 048	1024, 2048
RSASHA512	2 048	1024, 2048	Pas largement accepté
ECDSAP256SHA256	256	256
ECDSAP384SHA384	384	384	Pas largement accepté

Si aucun algorithme n'est spécifié, Cloud DNS utilise les valeurs par défaut suivantes :

Type de clé	Algorithme par défaut	Longueur de clé par défaut
Clé de signature de clé (KSK)	RSASHA256	2 048
Clé de signature de zone (ZSK)	RSASHA256	1 024

Les différences de sécurité et de performances entre les algorithmes RSASHA256 et RSASHA512 sont minimes et les tailles des réponses signées sont identiques. Les longueurs de clés sont importantes : les clés plus longues sont plus lentes et les réponses plus importantes (voir les analyses sur la taille de la réponse pour la zone racine et les domaines de premier niveau, ainsi qu'une analyse des performances côté serveur sous Windows).

La compatibilité du résolveur avec ECDSA est limitée aux systèmes relativement récents. Les résolveurs plus anciens qui ne peuvent pas valider les zones signées ECDSA les considèrent non signées, car elles ne sont pas sécurisées si vous utilisez de nouveaux types d'enregistrements basés sur DNSSEC. La compatibilité du service d'enregistrement et du registre avec ECDSA 256 bits est courante, mais pas systématique. ECDSA 256 bits n'est compatible qu'avec quelques registres et un nombre encore plus limité de services d'enregistrement. L'utilisation d'ECDSA peut être efficace si vous n'avez pas besoin de gérer d'anciens clients, car les signatures sont beaucoup plus petites et plus rapides à calculer.

Évitez d'utiliser des algorithmes différents pour KSK et ZSK dans vos zones gérées, car cela réduit la compatibilité et peut compromettre la sécurité. Certains résolveurs de validation DNSSEC peuvent échouer à valider des zones à l'aide d'algorithmes DNSKEY qui ne sont pas utilisés pour signer tous les enregistrements de la zone, même si le document RFC 6840 indique "ils ne doivent pas insister pour que tous les algorithmes … fonctionnent dans le RRset DNSKEY." Si le problème ne se pose pas (la plupart des résolveurs de validation respectent la norme RFC 6840), vous pouvez utiliser RSAHA256 pour la KSK et ECDSA pour la ZSK si votre bureau d'enregistrement de noms de domaine ou votre registre de domaine de premier niveau n'accepte pas ECDSA et que vous devez réduire la taille de réponse.

NSEC3 est le type de déni d'existence par défaut. il offre une protection limitée contre les visiteurs de zone qui tentent de découvrir tous les enregistrements de votre zone. Les paramètres NSEC3PARAM sont fixes : NSEC3 opt-out est désactivé pour des raisons de sécurité et il existe une itération de hachage supplémentaire (pour un total de deux) avec un salage de 64 bits.

NSEC a des réponses légèrement plus petites, mais n'offre pas de protection contre le parcours de zone. L'utilisation de NSEC peut également réduire le nombre de requêtes pour des domaines inexistants. Le DNS public de Google et plusieurs autres résolveurs de validation DNSSEC sont capables de synthétiser des réponses négatives à partir d'enregistrements NSEC mis en cache sans interroger votre zone Cloud DNS.

Le document RFC 8624 contient des conseils supplémentaires sur la sélection d'algorithmes.

Utiliser de nouveaux types d'enregistrements DNS avec des zones sécurisées DNSSEC

Une fois que votre domaine est entièrement sécurisé par DNSSEC, vous pouvez commencer à utiliser plusieurs nouveaux types d'enregistrements DNS qui exploitent les garanties d'authenticité et d'intégrité des zones signées DNSSEC pour améliorer la sécurité des autres services.

SSHFP

Les enregistrements SSHFP contiennent une empreinte numérique de la clé publique d'un serveur SSH que les applications clientes SSH peuvent utiliser pour valider les serveurs SSH. Les clients SSH requièrent généralement l'intervention des utilisateurs pour confirmer la clé publique du serveur lors de la première connexion et génèrent des avertissements si la clé est modifiée. Un client SSH configuré pour utiliser SSHFP utilise toujours la clé dans l'enregistrement SSHFP d'un serveur pour ce serveur. Seules les clés des serveurs sans enregistrement SSHFP sont enregistrées pour réutilisation.

Le format de l'enregistrement SSHFP se présente comme suit :

• Numéro d'algorithme
• Numéro du type d'empreinte numérique
• Empreinte numérique de la clé du serveur

Les numéros d'algorithme pour SSH sont les suivants :

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

Les types d'empreintes numériques sont les suivants :

• SHA-1 (obsolète, uniquement pour la compatibilité)
• SHA-256

Attention : Une utilisation incorrecte des enregistrements SSHFP peut avoir de graves conséquences pour la sécurité. Respectez les règles suivantes pour éviter de créer des failles de sécurité :

• Ne créez pas d'enregistrements SSHFP dans une zone non sécurisée DNSSEC.
• Ne configurez jamais des clients SSH pour utiliser SSHFP pour un domaine qui n'est pas sécurisé par DNSSEC.
• Ne configurez jamais des clients SSH pour utiliser SSHFP, sauf s'ils valident DNSSEC ou utilisent un résolveur de validation tel que le DNS public de Google.

Le non-respect de ces règles pourrait permettre à des personnes mal intentionnées de créer des enregistrements SSHFP usurpés de vos serveurs et de rendre les connexions SSH non sécurisées et vulnérables aux attaques.

Stack Exchange propose des suggestions pour la création d'enregistrements SSHFP. Des outils permettent de générer ces suggestions en analysant des serveurs, par le biais de fichiers d'hôtes connus existants ou de la gestion des configurations. Pour plus d'exemples et de liens, consultez l'article SSHFP records: DNS providing public ssh host keys.

TLSA et DANE

Les enregistrements TLSA contiennent des informations qui peuvent être utilisées pour valider les certificats X.509 (tels que les certificats utilisés par HTTPS) sans nécessiter la signature de l'une des autorités de certification d'un ensemble préconfiguré.

Cela vous permet de configurer vos propres autorités de certification, de générer des certificats pour HTTPS, et également de valider des certificats pour des protocoles tels que SMTP dans la mesure où il n'existe généralement aucune gestion des applications pour les autorités de certification de confiance préconfigurées.

Attention : Ne créez pas d'enregistrements TLSA dans une zone qui n'est pas sécurisée à l'aide du protocole DNSSEC. La plupart des applications qui utilisent des enregistrements TLSA nécessitent une validation DNSSEC. La création de ces enregistrements n'a donc aucun effet. Toutefois, elle peut entraîner une faille dans des applications mal configurées.

Comme indiqué dans le document RFC 6698 et les RFC connexes, DANE (Domain Authentication of Named Entities) utilise des enregistrements TLSA de manière spécifique pour sécuriser de nombreux protocoles et applications. Un article introductif utile et une présentation de DANE sont disponibles sur les sites du journal de l'IETF et de l'Internet Society.

HTTPS

DANE vous permet de configurer en toute sécurité des serveurs HTTPS en utilisant des certificats générés avec votre propre infrastructure d'autorité de certification basée sur OpenSSL ou CFSSL de Cloudflare.

Le programme de validation DANE pour les serveurs HTTPS de SIDNLabs est utile pour tester un déploiement DANE pour HTTPS.

Validation du certificat TLS SMTP (messagerie)

Le protocole de messagerie SMTP est vulnérable aux attaques par rétrogradation qui désactivent le chiffrement, et DANE fournit un moyen de les empêcher.

L'Internet Society propose un tutoriel en deux parties sur l'utilisation de DANE pour SMTP avec des certificats gratuits et automatisés disponibles auprès de Let's Encrypt, ainsi que des conseils pour éviter d'utiliser certains formats d'enregistrements TLSA avec des certificats Let's Encrypt :

• Partie 1
• Partie 2

Vous trouverez des conseils précieux (et un programme de validation de domaine DANE pour HTTPS et SMTP) sur la page Common Mistakes. Le programme de validation d'e-mails vérifie également les domaines DANE.

Validation du certificat TLS XMPP (chat Jabber)

XMPP (et d'autres services qui utilisent des enregistrements SRV) peuvent également exploiter DANE. Un exemple XMPP utilise la configuration DANE-SRV, comme spécifié dans le document RFC 7673.

Association de clés publiques TXT (OpenPGP/GnuPG)

Vous pouvez utiliser des enregistrements TXT sans DNSSEC, mais l'authenticité de ceux signés DNSSEC est beaucoup plus fiable. Ceci est important pour la publication DNS de clés publiques OpenPGP (GnuPG) qui ne sont pas signées par des entités connues comme les autorités de certification X.509.

Par exemple, si Alice publie un enregistrement TXT semblable à ce qui suit dans la zone an.example signée DNSSEC, et héberge une copie de la clé publique blindée ASCII sur l'URI donné, Bob peut rechercher une clé OpenPGP pour [e-mail] avec une sécurité raisonnable. Cela ne remplace pas la validation Web de confiance, mais rend le chiffrement OpenPGP possible avec des parties précédemment inconnues :

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

Vous pouvez suivre ces instructions pour générer des enregistrements TXT de PKA version 1 (tels que désignés dans la section Publier des clés dans DNS).

Le guide complet sur la publication de clés PGP dans DNS explique comment créer des enregistrements OpenPGP CERT (mais ni les enregistrements CERT ni les enregistrements OPENPGPKEY ne sont compatibles avec Cloud DNS).

Si vous avez enregistré votre clé OpenPGP sur Keybase.io, vous n'avez pas besoin de l'héberger sur votre propre serveur. Il vous suffit d'utiliser une URL telle que https://keybase.io/KEYBASE_USERNAME/key.asc (en remplaçant KEYBASE_USERNAME par votre nom d'utilisateur Keybase.io).

Si vous avez importé votre clé OpenPGP sur un serveur de clés, vous pouvez également utiliser un URI "hkp:" pour ce serveur de clés, tel que hkp://subkeys.pgp.net ou hkp://pgp.mit.edu, bien que les utilisateurs situés derrière des pare-feu bloquant le port 11371 ne puissent pas l'atteindre (certains serveurs de clés fournissent des URL HTTP sur le port 80).

TXT (SPF, DKIM et DMARC)

Voici trois autres types d'enregistrements TXT que vous pouvez utiliser pour sécuriser vos services de messagerie, et empêcher les spammeurs et les escrocs d'envoyer des e-mails qui semblent provenir de votre domaine (même si ce n'est pas le cas) :

• SPF : spécifie les serveurs SMTP (par nom de domaine ou adresse IP) pouvant envoyer des e-mails pour un domaine.

• DKIM : publie un ensemble de clés publiques utilisées pour vérifier que les e-mails sont envoyés à partir d'un domaine et empêche la modification des messages en transit.

• DMARC : spécifie les règles de domaine, les rapports pour la validation et les rapports d'erreurs SPF et DKIM.

Pour vérifier que votre domaine est correctement configuré pour utiliser les trois types d'enregistrements, vous pouvez lancer le programme de validation d'e-mails. Pour obtenir des conseils pratiques sur la configuration d'enregistrements SPF, consultez la section Questions fréquentes sur les erreurs courantes.

Utiliser d'autres types de jeux d'enregistrements améliorés par DNSSEC

Outre TXT, d'autres types de jeux d'enregistrements tirent parti de DNSSEC, même s'ils ne l'exigent pas.

CAA

Les jeux d'enregistrements CAA (Certification Authority Authorization) vous permettent de contrôler les autorités de certification publiques qui peuvent générer des certificats TLS ou d'un autre type pour votre domaine. Ceci est très utile (et efficace) si vous souhaitez vous assurer qu'une autorité de certification publique délivrant des certificats validés par domaine (telle que LetsEncrypt.org) n'émet pasde certificats pour votre domaine.

Un enregistrement CAA typique présente un format simple, tel que 0 issue "best-ca.example", qui permet à l'autorité de certification best-ca.example (et aucune autre autorité de certification) d'émettre des certificats pour les noms du domaine où se trouve le jeu d'enregistrements CAA. Si vous souhaitez autoriser plusieurs autorités de certification à émettre des certificats, créez plusieurs enregistrements CAA.

Le document RFC 6844 fournit des détails supplémentaires sur l'utilisation du type de jeu d'enregistrements CAA et recommande fortement l'utilisation de DNSSEC.

IPSECKEY

Vous pouvez également activer le chiffrement opportuniste via des tunnels IPSEC en publiant des enregistrements IPSECKEY. La mise en œuvre du VPN IPSEC StrongSwan comporte un plug-in utilisant des enregistrements IPSECKEY.

En plus de placer des enregistrements IPSECKEY dans les zones de transfert habituelles, telles que service.example.com, la section 1.2 du document RFC 4025 exige que les passerelles de sécurité recherchent des enregistrements IPSECKEY dans les zones inversées ip6.arpa et in-addr.arpa.

La compatibilité de DNSSEC avec les zones inversées est moins fréquente qu'avec les zones de transfert et nécessite un fournisseur d'accès à Internet (FAI) qui met en œuvre DNSSEC. Cependant, certains FAI sont compatibles avec DNSSEC pour les délégations de zones inversées.

Les zones inversées pour les adresses IP externes des VM Compute Engine ne sont pas encore compatibles avec la délégation.

Étape suivante

• Pour créer, mettre à jour, répertorier et supprimer des zones gérées, consultez la page Gérer les zones.
• Pour trouver des solutions aux problèmes courants que vous pouvez rencontrer lors de l'utilisation de Cloud DNS, consultez la page Dépannage.
• Pour en savoir plus sur Cloud DNS, consultez la page Présentation de Cloud DNS.