DNSSEC avancé

Si vous activez DNSSEC pour vos zones gérées, vous disposez de plusieurs options de configuration DNSSEC avancées. Ces dernières incluent 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é. Toutes ces options sont décrites ci-dessous.

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

Vous pouvez activer DNSSEC pour les sous-domaines délégués une fois que vous l'avez 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 obtenir des instructions sur la création d'enregistrements NS, consultez la page Ajouter ou supprimer des enregistrements NS.

Console

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 Cloud Console.

  1. Accédez à la zone gérée.
  2. Pour afficher l'enregistrement DS de la zone, cliquez sur le lien Registrar Setup situé dans l'angle supérieur droit de la page Zone details.
  3. Après avoir noté les informations de l'enregistrement DS, poursuivez la procédure à l'étape 2 de l'onglet des commandes gcloud.

Fenêtre pop-up de la configuration du bureau d'enregistrement

gcloud

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

    $ gcloud dns dns-keys list --zone example_zone
    

    Remplacez l'option de commande suivante :

    • example_zone : nom d'une zone DNS 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 les options de commande suivantes :

    • example_zone : nom d'une zone DNS dans votre projet
    • ksk_id : numéro d'ID, généralement 0
  3. Copiez le résultat de la commande précédente pour l'utiliser lors d'une étape ultérieure.

    La sortie ressemble à ceci :

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
    
  4. Pour créer les enregistrements DS pour une sous-délégation sécurisée, démarrez la transaction à l'aide de la commande suivante :

    $ gcloud dns record-sets transaction start -z example_zone
    

    Remplacez les options de commande suivantes :

    • example_zone : nom d'une zone DNS dans votre projet
    • subdomain.example.com : sous-domaine du nom DNS de la zone

    La sortie ressemble à ceci :

    Transaction started [transaction.yaml].
    

  5. Ajoutez ensuite un jeu d'enregistrements à l'aide de la commande suivante :

    $ gcloud dns record-sets transaction add -z example_zone \
     --ttl 3600 --type DS --name subdomain.example.com \
     DS_record-and_key"44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb"
    

    Remplacez les options de commande suivantes :

    • example_zone : nom d'une zone DNS dans votre projet
    • subdomain.example.com : sous-domaine du nom DNS de la zone
    • DS_record-and_key : enregistrement et clé DS que vous avez obtenus à l'étape 2

    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 -z example_zone \
     --ttl 3600 --type NS --name subdomain.example.com \
    

    Remplacez les options de commande suivantes :

    • example_zone : nom d'une zone DNS dans votre projet
    • subdomain.example.com : sous-domaine du nom DNS de la zone
  7. Saisissez les RData suivants :

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

    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 -z example_zone
    

    Remplacez l'option de commande suivante :

    • example_zone : 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
    

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 réactivez-le à l'aide de cette commande (remplacez example_zone par le nom d'une zone DNS dans votre projet) :

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

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

La commande suivante active DNSSEC avec ECDSA 256 bits et NSEC pour les plus petits paquets de réponses signés DNSSEC possibles avec Cloud DNS. Remplacez example_zone par le nom d'une zone DNS dans votre projet :

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

Si vous fournissez des algorithmes KSK ou ZSK ou des longueurs de clé, vous devez spécifier tous les éléments (--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length) dans la commande, ainsi que leurs arguments. Vous pouvez spécifier le déni d'existence en tant qu'enregistrements 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, qui précise également les valeurs par défaut et les valeurs vulnérables uniquement disponibles sur demande.

Algorithme Longueurs KSK Longueurs ZSK Commentaires
RSASHA1 1 024, 2 048 1 024, 2 048 Signature SHA-1 considérée comme vulnérable
RSASHA256 1 024, 2 048 1 024, 2 048
RSASHA512 1 024, 2 048 1 024, 2 048 Pas largement accepté
ECDSAP256SHA256 256 256 Peut ne pas être accepté
ECDSAP384SHA384 384 384 Pas largement accepté

N'utilisez pas RSASHA1, sauf si vous en avez besoin pour des raisons de compatibilité. Son utilisation n'apporte aucun avantage de sécurité avec des longueurs de clé importantes.

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é des clients avec ECDSA est limitée aux systèmes assez récents. Les clients plus anciens qui ne peuvent pas valider les zones signées ECDSA les considèrent comme non signées, ce qui peut compromettre la sécurité si vous utilisez de nouveaux types d'enregistrements qui reposent sur DNSSEC. La compatibilité du service d'enregistrement et du registre avec ECDSA 256 bits est courante, mais pas systématique. ECDSA 384 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 les KSK et les 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 service d'enregistrement de noms de domaine ou votre registre TLD 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 : il est impossible de désactiver NSEC3 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.

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 et peuvent être utilisés par les applications clientes SSH pour valider le serveur 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 des enregistrements SSHFP est le suivant : numéro d'algorithme, numéro du type d'empreinte numérique et 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 :

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

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. Consultez cette page pour obtenir des exemples et des liens supplémentaires.

TLSA et DANE

Les enregistrements TLSA contiennent des informations qui peuvent être utilisées pour valider les certificats X.509 (tels que ceux utilisés par HTTPS) sans que ces derniers n'aient besoin d'être signés par un ensemble préconfiguré d'autorités de certification. Cela vous permet de configurer vos propres autorités de certification et de générer des certificats pour HTTPS, ainsi que de permettre la validation de certificats pour des protocoles tels que SMTP, où il n'existe généralement aucune gestion des applications pour les autorités de certification de confiance pré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 particulièrement 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. (Assurez-vous de tenir compte de ces conseils pour éviter d'utiliser certains formats d'enregistrement TLSA avec des certificats Let's Encrypt.)

Vous trouverez également d'autres conseils intéressants (et un programme de validation de domaine DANE pour HTTPS et SMTP) à l'adresse https://dane.sys4.de/common_mistakes. Le programme de validation "Test your email" vous permet également de vérifier votre déploiement 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. Si Alice publie (dans la zone signée DNSSEC an.example) un enregistrement TXT tel que :

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

et héberge une copie de la clé publique blindée ASCII sur l'URI donné, Bob peut rechercher une clé OpenPGP pour alice@an.example avec une sécurité raisonnable. Cela ne remplace pas la validation Web de confiance, mais rend le chiffrement OpenPGP possible avec des entités précédemment inconnues.

Vous pouvez suivre ces instructions pour générer des enregistrements TXT "PKA Version 1" (tels que désignés dans cette présentation des clés dans DNS). Un autre guide pratique explique également 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)

Il existe trois autres types d'enregistrements TXT qui peuvent être utilisés pour sécuriser vos services de messagerie, et empêcher les spammeurs et les fraudeurs 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) susceptibles d'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 lors de leur transit.
DMARC
Spécifie les règles de domaine et la création de rapports pour la validation et les rapports d'erreurs SPF et DKIM.

Vous pouvez vous servir du programme de validation "Test your email" pour vérifier que la configuration de votre domaine accepte bien ces trois types d'enregistrements. Accédez au site Common Mistakes FAQ pour obtenir des conseils utiles sur la configuration des enregistrements SPF.

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 (autorisation provenant d'autorité de certification) vous permettent de contrôler les autorités de certification publiques qui peuvent générer des certificats TLS ou d'autres 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 pas de certificats pour votre domaine.

Un enregistrement CAA typique présente un format simple, tel que celui-ci : 0 issue "best-ca.example" Dans cet exemple, l'autorité de certification "best-ca.example" (et aucune autre autorité de certification) peut émettre des certificats pour les noms dans le domaine où se trouve le jeu d'enregistrements CAA. Si vous souhaitez autoriser plusieurs autorités de certification à émettre des certificats, créez simplement 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 gestion de DNSSEC pour les zones inversées est moins fréquente que pour les zones de transfert et nécessite un fournisseur d'accès à Internet qui met en œuvre DNSSEC lui-même. Certains fournisseurs sont toutefois compatibles avec DNSSEC pour les délégations de zones inversées.

Notez que la délégation de zones inversées pour les adresses IP externes des VM Google Compute Engine n'est pas encore disponible. Consultez la demande de fonctionnalité pour Google Compute Engine.

Étapes suivantes