Partager via


Vue d’ensemble de DNSSEC (préversion)

Cet article fournit une vue d’ensemble des extensions de sécurité du système de noms de domaine (DNSSEC) et inclut une introduction à la terminologie DNSSEC. Les avantages de la signature de zone DNSSEC sont décrits et des exemples sont fournis pour afficher les enregistrements de ressources associés à DNSSEC. Lorsque vous êtes prêt à signer votre zone DNS public Azure, consultez les guides pratiques suivants :

Remarque

La signature de zone DNSSEC est actuellement en préversion.
Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

Qu’est-ce que le DNSSEC ?

DNSSEC est une suite d’extensions qui renforcent la sécurité du protocole DNS en permettant la validation des réponses DNS comme authentiques. DNSSEC fournit l’autorité d’origine, l’intégrité des données et le déni d’existence authentifié. Avec DNSSEC, le protocole DNS est beaucoup moins vulnérable à certains types d’attaques, notamment aux tentatives d’usurpation DNS.

Les extensions DNSSEC de base sont spécifiées dans les documents RFC (Request For Comments) suivants :

  • RFC 4033: Introduction et exigences pour la sécurité du DNS
  • RFC 4034: Enregistrements de ressource pour les extensions de sécurité DNS
  • RFC 4035: Modifications du protocole pour les extensions de sécurité DNS

Pour obtenir un résumé des RFC DNSSEC, consultez RFC9364 : extensions de sécurité DNS (DNSSEC).

Fonctionnement de DNSSEC

Les zones DNS sont sécurisées avec DNSSEC à l’aide d’un processus appelé signature de zone. Signer une zone avec DNSSEC ajoute la prise en charge de la validation sans modifier le mécanisme de base d’une requête DNS et de sa réponse. Pour signer une zone avec DNSSEC, le serveur DNS faisant autorité de la zone doit prendre en charge DNSSEC.

Les signatures d’enregistrement de ressources (RRSIG) et d’autres enregistrements de chiffrement sont ajoutés à la zone lorsqu’elle est signée. Le graphique suivant montre les enregistrements de ressource DNS dans la zone contoso.com avant et après la signature de zone.

Diagramme montrant comment les enregistrements RRSIG sont ajoutés à une zone lorsqu'elle est signée avec DNSSEC.

La validation DNSSEC des réponses DNS se produit en utilisant ces signatures numériques avec une chaîne d’approbation ininterrompue.

Remarque

Les enregistrements de ressources liés à DNSSEC ne sont pas affichés dans le portail Azure. Pour plus d’informations, consultez Afficher les enregistrements de ressources liés à DNSSEC.

Pourquoi signer une zone avec DNSSEC ?

La signature d’une zone avec DNSSEC est requise pour la conformité à certaines instructions de sécurité, telles que SC-20 : Service de résolution de noms/adresses sécurisé.

La validation DNSSEC des réponses DNS peut empêcher les types courants d’attaques de détournement DNS, également appelés redirection DNS. Le détournement DNS se produit lorsqu’un appareil client est redirigé vers un serveur malveillant à l’aide de réponses DNS incorrectes (falsifiées). L’empoisonnement du cache DNS est une méthode courante utilisée pour usurper les réponses DNS.

Un exemple de fonctionnement du détournement DNS est illustré dans la figure suivante.

Diagramme montrant le fonctionnement du détournement DNS.

Résolution DNS normale :

  1. Un appareil client envoie une requête DNS pour contoso.com à un serveur DNS.
  2. Le serveur DNS répond avec un enregistrement de ressource DNS pour contoso.com.
  3. L’appareil client demande une réponse de contoso.com.
  4. L’application contoso.com ou le serveur web retourne une réponse au client.

Détournement de DNS

  1. Un appareil client envoie une requête DNS pour contoso.com à un serveur DNS détourné.
  2. Le serveur DNS répond avec un enregistrement de ressource DNS invalide (falsifié) pour contoso.com.
  3. L’appareil client demande une réponse pour contoso.com à partir d’un serveur malveillant.
  4. Le serveur malveillant retourne une réponse falsifiée au client.

Le type d'enregistrement de ressource DNS falsifié dépend du type d'attaque de détournement DNS. Un enregistrement MX peut être falsifié pour rediriger les e-mails du client, ou un enregistrement A usurpé peut envoyer des clients vers un serveur web malveillant.

DNSSEC permet d'éviter le détournement DNS en effectuant une validation sur les réponses DNS. Dans le scénario de détournement DNS illustré ici, l’appareil client peut rejeter les réponses DNS non validées si le domaine contoso.com est signé avec DNSSEC. Pour rejeter les réponses DNS non validées, l’appareil client doit appliquer la validation DNSSEC pour contoso.com.

DNSSEC inclut également Next Secure 3 (NSEC3) pour empêcher l’énumération de zone. L’énumération de zone, également appelée consultation de zone, est une attaque par laquelle l’attaquant établit une liste de tous les noms d’une zone, y compris les zones enfants.

Avant de signer une zone avec DNSSEC, veillez à comprendre le fonctionnement de DNSSEC. Lorsque vous êtes prêt à signer une zone, consultez Comment signer votre zone DNS public Azure avec DNSSEC.

Validation DNSSEC

Si un serveur DNS prend en compte DNSSEC, il peut définir l’indicateur DNSSEC OK (DO) dans une requête DNS sur une valeur de 1. Cette valeur indique au serveur DNS qui répond d’inclure des enregistrements de ressources liés à DNSSEC avec la réponse. Ces enregistrements DNSSEC sont des enregistrements de signatures d'enregistrement de ressources (RRSIG) utilisés pour valider que la réponse DNS est authentique.

Un serveur DNS récursif (non autoritaire) effectue la validation DNSSEC des enregistrements RRSIG en utilisant une ancre d’approbation (DNSKEY). Le serveur utilise une clé DNS pour déchiffrer les signatures numériques dans les enregistrements RRSIG (et d’autres enregistrements liés à DNSSEC), puis calcule et compare les valeurs de hachage. Si les valeurs de hachage sont identiques, le serveur DNS récursif fournit une réponse au client DNS avec les données DNS qu’il a demandées, tels qu’un enregistrement d’adresse hôte (A). Consultez le diagramme suivant :

Diagramme montrant le fonctionnement de la validation DNSSEC.

Si les valeurs de hachage ne sont pas identiques, le serveur DNS récursif répond avec un message SERVFAIL. Ainsi, les serveurs DNS de résolution (ou de transfert) prenant en charge DNSSEC et avec une ancre d'approbation valide installée peuvent se protéger contre le détournement DNS dans le chemin entre le serveur récursif et le serveur faisant autorité. Cette protection ne nécessite pas que les appareils clients DNS soient compatibles DNSSEC ou appliquent la validation des réponses DNS, à condition que le serveur DNS récursif local (dernier saut) soit lui-même sécurisé contre le détournement.

Les appareils clients Windows 10 et Windows 11 sont des résolveurs intermédiaires sensibles à la sécurité non validants. Ces appareils clients ne font pas de validation, mais peuvent appliquer la validation DNSSEC via la stratégie de groupe. Le NRPT peut être utilisé pour créer et appliquer une stratégie de validation DNSSEC basée sur l’espace de noms.

Ancres d’approbation et validation DNSSEC

Remarque

La validation de la réponse DNSSEC n’est pas effectuée par le programme de résolution fourni par Azure par défaut. Les informations de cette section sont utiles si vous configurez vos propres serveurs DNS récursifs pour la validation DNSSEC ou la résolution des problèmes de validation.

Les ancres d’approbation fonctionnent en fonction de la hiérarchie d’espaces de noms DNS. Un serveur DNS récursif peut avoir n’importe quel nombre d’ancres d’approbation ou pas d’ancres d’approbation. Les ancres d’approbation peuvent être ajoutées pour une seule zone DNS enfant ou toute zone parente. Si un serveur DNS récursif a une ancre d’approbation racine (.), il peut effectuer la validation DNSSEC sur n’importe quelle zone DNS. Pour plus d’informations, consultez Informations sur l’opérateur de zone racine.

Le processus de validation DNSSEC fonctionne avec des ancres d’approbation comme suit :

  • Si un serveur DNS récursif n’a pas d’ancre d’approbation DNSSEC pour une zone ou l’espace de noms hiérarchique parent de la zone, il n’effectue pas de validation DNSSEC sur cette zone.
  • Si un serveur DNS récursif a une ancre d’approbation DNSSEC pour l’espace de noms parent d’une zone et qu’il reçoit une requête pour la zone enfant, il vérifie si un enregistrement DS pour les zones enfants est présent dans la zone parente.
    • Si l’enregistrement DS est trouvé, le serveur DNS récursif effectue la validation DNSSEC.
    • Si le serveur DNS récursif détermine que la zone parente n’a pas d’enregistrement DS pour la zone enfant, elle suppose que la zone enfant est non sécurisée et n’effectue pas de validation DNSSEC.
  • Si plusieurs serveurs DNS récursifs sont impliqués dans une réponse DNS (y compris les redirecteurs), chaque serveur doit être en mesure d’effectuer la validation DNSSEC sur la réponse afin qu’il existe une chaîne d’approbation non chiffrée.
  • Les serveurs récursifs dont la validation DNSSEC est désactivée ou qui ne prennent pas en compte DNSSEC n’effectuent pas de validation.

Chaîne d’approbation

Une chaîne d’approbation se produit lorsque tous les serveurs DNS impliqués dans l’envoi d’une réponse pour une requête DNS peuvent vérifier que la réponse n’a pas été modifiée pendant le transit. Pour que la validation DNSSEC fonctionne de bout en bout, la chaîne d’approbation doit être ininterrompue. Cette chaîne d’approbation s’applique aux serveurs faisant autorité et non autoritaires (récursifs).

Serveurs faisant autorité

Les serveurs DNS faisant autorité gèrent une chaîne d’approbation par le biais de l’utilisation d’enregistrements de signataire de délégation (DS). Les enregistrements DS sont utilisés pour vérifier l’authenticité des zones enfants dans la hiérarchie DNS.

  • Pour que la validation DNSSEC se produise sur une zone signée, le parent de la zone signée doit également être signé. La zone parente doit également avoir un enregistrement DS pour la zone enfant.
  • Pendant le processus de validation, le parent d’une zone est interrogé pour l’enregistrement DS. Si l’enregistrement DS n’est pas présent ou si les données d’enregistrement DS dans le parent ne correspondent pas aux données DNSKEY dans la zone enfant, la chaîne d’approbation est rompue et la validation échoue.

Serveurs récursifs

Les serveurs DNS récursifs (également appelés serveurs DNS de résolution ou de mise en cache) gèrent une chaîne d’approbation par le biais de l’utilisation d’ancres d’approbation DNSSEC.

  • L’ancre d’approbation est un enregistrement DNSKEY ou un enregistrement DS contenant un hachage d’un enregistrement DNSKEY. L'enregistrement DNSKEY est créé sur un serveur faisant autorité lorsque la zone est signée et est supprimé de la zone si celle-ci est dé-signée.
  • Les ancres d’approbation doivent être installées manuellement sur des serveurs DNS récursifs.
  • Si une ancre d’approbation pour une zone parente est présente, un serveur récursif peut valider toutes les zones enfants dans l’espace de noms hiérarchique. Cela inclut les requêtes transférées. Pour prendre en charge la validation DNSSEC de toutes les zones DNS signées DNSSEC, vous pouvez installer une ancre d’approbation pour la zone racine (.).

Substitution de clé

La clé de signature de zone (ZSK) dans une zone signée DNSSEC est régulièrement renouvelée (remplacée) automatiquement par Azure. Il ne doit pas être nécessaire de remplacer votre clé KSK, mais cette option est disponible en contactant le support Microsoft. Le remplacement de KSK nécessite que vous mettiez également à jour votre enregistrement DS dans la zone parente.

Algorithme de signature de zone

Les zones sont signées par DNSSEC en utilisant l'algorithme Elliptic Curve Digital Signature Algorithm (ECDSAP256SHA256).

Le tableau suivant fournit une brève description des enregistrements liés à DNSSEC. Pour plus d’informations, consultez RFC 4034 : Enregistrements de ressource pour les extensions de sécurité DNS et RFC 7344 : Automatisation de la maintenance de l’approbation de délégation DNSSEC.

Enregistrer Description
Signature d’enregistrement de ressource (RRSIG) Type d’enregistrement de ressource DNSSEC utilisé pour contenir une signature, qui couvre un ensemble d’enregistrements DNS pour un nom et un type particuliers.
DNSKEY Type d’enregistrement de ressource DNSSEC utilisé pour stocker une clé publique.
Signataire de délégation (DS) Type d’enregistrement de ressource DNSSEC utilisé pour sécuriser une délégation.
Next Secure (NSEC) Type d’enregistrement de ressource DNSSEC utilisé pour prouver qu’il n’existe pas de nom DNS.
Next Secure 3 (NSEC3) Enregistrement de ressource NSEC3 qui fournit un déni d’existence authentifié et haché pour les jeux d’enregistrements de ressources DNS.
Paramètres sécurisés suivants 3 (NSEC3PARAM) Spécifie les paramètres des enregistrements NSEC3.
Signataire de délégation enfant (CDS) Cet enregistrement est facultatif. S’il est présent, l’enregistrement CDS peut être utilisé par une zone enfant pour spécifier le contenu souhaité de l’enregistrement DS dans une zone parente.
DNSKEY enfant (CDNSKEY) Cet enregistrement est facultatif. Si l’enregistrement CDNSKEY est présent dans une zone enfant, il peut être utilisé pour générer un enregistrement DS à partir d’un enregistrement DNSKEY.

Les enregistrements liés à DNSSEC ne sont pas affichés dans le portail Azure. Pour afficher les enregistrements liés à DNSSEC, utilisez des outils en ligne de commande tels que Resolve-DnsName ou dig.exe. Ces outils sont disponibles à l’aide de Cloud Shell, ou localement s’ils sont installés sur votre appareil. Veillez à définir l’indicateur DO dans votre requête à l’aide de l’option -dnssecok dans Resolve-DnsName ou de l’option +dnssec dans dig.exe.

Important

N’utilisez pas l’outil en ligne de commande nslookup.exe pour rechercher des enregistrements liés à DNSSEC. L’outil nslookup.exe utilise un client DNS interne qui ne prend pas en charge DNSSEC.

Regardez les exemples suivants :

PS C:\> resolve-dnsname server1.contoso.com -dnssecok

Name                                      Type   TTL   Section    IPAddress
----                                      ----   ---   -------    ---------
server1.contoso.com                        A     3600  Answer     203.0.113.1

Name        : server1.contoso.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : A
Algorithm   : 13
LabelCount  : 3
OriginalTtl : 3600
Expiration  : 9/20/2024 11:25:54 PM
Signed      : 9/18/2024 9:25:54 PM
Signer      : contoso.com
Signature   : {193, 20, 122, 196…}
C:\>dig server1.contoso.com +dnssec

; <<>> DiG 9.9.2-P1 <<>> server1.contoso.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61065
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;server1.contoso.com.       IN      A

;; ANSWER SECTION:
server1.contoso.com. 3600   IN      A       203.0.113.1
server1.contoso.com. 3600   IN      RRSIG   A 13 3 3600 20240920232359 20240918212359 11530 contoso.com. GmxeQhNk1nJZiep7nuCS2qmOQ+Ffs78Z2eoOgIYP3j417yqwS1DasfA5 e1UZ4HuujDk2G6GIbs0ji3RiM9ZpGQ==

;; Query time: 153 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 15:23:45 2024
;; MSG SIZE  rcvd: 179
PS C:\> resolve-dnsname contoso.com -Type dnskey -dnssecok

Name                                 Type   TTL   Section    Flags  Protocol Algorithm      Key
----                                 ----   ---   -------    -----  -------- ---------      ---
contoso.com                          DNSKEY 3600  Answer     256    DNSSEC   13             {115, 117, 214,
                                                                                                165…}
contoso.com                          DNSKEY 3600  Answer     256    DNSSEC   13             {149, 166, 55, 78…}
contoso.com                          DNSKEY 3600  Answer     257    DNSSEC   13             {45, 176, 217, 2…}

Name        : contoso.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : DNSKEY
Algorithm   : 13
LabelCount  : 2
OriginalTtl : 3600
Expiration  : 11/17/2024 9:00:15 PM
Signed      : 9/18/2024 9:00:15 PM
Signer      : contoso.com
Signature   : {241, 147, 134, 121…}
C:\>dig contoso.com dnskey

; <<>> DiG 9.9.2-P1 <<>> contoso.com dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46254
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;contoso.com.               IN      DNSKEY

;; ANSWER SECTION:
contoso.com.        3600    IN      DNSKEY  256 3 13 laY3Toc/VTyjupgp/+WgD05N+euB6Qe1iaM/253k7bkaA0Dx+gSDhbH2 5wXTt+uLQgPljL9OusKTneLdhU+1iA==
contoso.com.        3600    IN      DNSKEY  257 3 13 LbDZAtjG8E9Ftih+LC8CqQrSZIJFFJMtP6hmN3qBRqLbtAj4JWtr2cVE ufXM5Pd/yW+Ca36augQDucd5n4SgTg==
contoso.com.        3600    IN      DNSKEY  256 3 13 c3XWpTqZ0q9IO+YqMEtOBHZSzGGeyFKq0+3xzs6tifvD1rey1Obhrkz4 DJlEIxy2m84VsG1Ij9VYdtGxxeVHIQ==

;; Query time: 182 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 16:35:10 2024
;; MSG SIZE  rcvd: 284

Terminologie DNSSEC

Cette liste est fournie pour vous aider à comprendre certains termes courants utilisés lors de la discussion sur DNSSEC. Consultez également : Enregistrements de ressources liés à DNSSEC

Terme Description
Bit de données authentifiées (AD) Bit de données qui indique dans une réponse que toutes les données incluses dans les sections de réponse et d’autorité de la réponse ont été authentifiées par le serveur DNS conformément aux stratégies de ce serveur.
Chaîne d’authentification Chaîne d’enregistrements DNS signés et validés qui s’étend d’une ancre d’approbation préconfigurée à une zone enfant dans l’arborescence DNS.
Extension DNS (EDNS0) Enregistrement DNS qui transporte des informations d'en-tête DNS étendues, telles que le bit DO et la taille maximale des paquets UDP.
Extensions de sécurité DNS (DNSSEC) Extensions au service DNS qui fournissent des mécanismes de signature et de résolution sécurisée des données DNS.
Bit DNSSEC OK (DO) Un peu dans la partie EDNS0 d’une requête DNS qui signale que le client prend en charge DNSSEC.
Validation DNSSEC La validation DNSSEC est le processus de vérification de l’origine et de l’intégrité des données DNS à l’aide de clés de chiffrement publiques.
Île de sécurité Zone signée qui n’a pas de chaîne d’authentification à partir de sa zone parente délégante.
Clé de signature de clé (KSK) Clé d’authentification qui correspond à une clé privée utilisée afin de signer une ou plusieurs autres clés de signature pour une zone donnée. En règle générale, la clé privée qui correspond à une clé KSK signe une clé de signature de zone (ZSK), qui à son tour a une clé privée correspondante qui signe d’autres données de zone. La stratégie locale peut exiger que la clé ZSK soit modifiée fréquemment, tandis que la clé KSK peut avoir une période de validité plus longue afin de fournir un point d’entrée plus stable et sécurisé dans la zone. La conception d’une clé d’authentification en tant que KSK est purement un problème opérationnel : la validation DNSSEC ne fait pas la distinction entre les KSK et d’autres clés d’authentification DNSSEC. Il est possible d’utiliser une seule clé comme clé KSK et ZSK.
Résolveur intermédiaire sensible à la sécurité non validant Un résolveur intermédiaire sensible à la sécurité qui fait confiance à un ou plusieurs serveurs DNS sensibles à la sécurité pour effectuer la validation DNSSEC en son nom.
Clé de point d’entrée sécurisé (SEP) Sous-ensemble de clés publiques dans DNSKEY RRSet. Une clé SEP est utilisée pour générer une DS RR ou est distribuée aux résolveurs qui utilisent la clé comme ancre d’approbation.
Serveur DNS prenant en compte la sécurité Serveur DNS qui implémente les extensions de sécurité DNS telles que définies dans les RFC 4033 [5], 4034 [6] et 4035 [7]. En particulier, un serveur DNS prenant en charge la sécurité est une entité qui reçoit des requêtes DNS, envoie des réponses DNS, prend en charge l’extension de taille de message EDNS0 [3] et le bit DO, et prend en charge les types d’enregistrements DNSSEC et les bits d’en-tête de message.
Zone signée Zone dont les enregistrements sont signés comme définis par RFC 4035 [7] Section 2. Une zone signée peut contenir des enregistrements de ressources DNSKEY, NSEC, NSEC3, NSEC3PARAM, RRSIG et DS. Ces enregistrements de ressources permettent de valider les données DNS par les résolveurs.
Ancre d’approbation Clé publique préconfigurée associée à une zone particulière. Une ancre d’approbation permet à un programme de résolution DNS de valider les enregistrements de ressources DNSSEC signés pour cette zone et de créer des chaînes d’authentification dans des zones enfants.
Zone non signée Toute zone DNS qui n’a pas été signée comme défini par RFC 4035 [7] Section 2.
Signature de zone La signature de zone est le processus de création et d’ajout d’enregistrements de ressources liés à DNSSEC à une zone, ce qui le rend compatible avec la validation DNSSEC.
Annulation de la signature de zone L’annulation de la signature de zone est le processus de suppression des enregistrements de ressources liés à DNSSSEC d’une zone, en le rétablissant à un état non signé.
Clé de signature de zone (ZSK) Clé d’authentification qui correspond à une clé privée utilisée pour signer une zone. En règle générale, une clé ZSK fait partie du même DNSKEY RRSet que la clé KSK dont la clé privée correspondante signe ce DNSKEY RRSet, mais la clé ZSK est utilisée à des fins légèrement différentes et peut différer de la clé KSK de différentes façons, comme dans la durée de vie de validité. La conception d’une clé d’authentification en tant que clé ZSK est purement un problème opérationnel. La validation DNSSEC ne fait pas la distinction entre les clés de signature de zone et d’autres clés d’authentification DNSSEC. Il est possible d’utiliser une clé unique comme clé ZSK et clé KSK.

Étapes suivantes