Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les enregistrements de ressources DNSSEC sont utilisés pour valider et sécuriser les réponses DNS. Les zones DNS sont sécurisées avec DNSSEC via la signature de zone. La signature d’une zone ajoute la prise en charge de la validation sans modifier le mécanisme de base d’une requête et d’une réponse DNS. Pour une présentation de DNSSEC pour le serveur DNS dans Windows Server, consultez Vue d’ensemble de DNSSEC.
Les signatures numériques sont incluses avec les réponses DNS pour fournir une validation. Ces signatures numériques sont contenues dans des enregistrements de ressources liés à DNSSEC qui sont générés et ajoutés à la zone lors de la signature de la zone.
DNS récursif
Lorsqu’un serveur DNS récursif ou de transfert prenant en charge DNSSEC reçoit une requête d’un client DNS pour une zone signée DNSSEC, il demande au serveur DNS faisant autorité d’envoyer également des enregistrements DNSSEC pour valider la réponse DNSS. Un serveur DNS récursif ou de transfert reconnaît que la zone prend en charge DNSSEC s’il dispose d’une clé DNSKEY, également appelée ancre de confiance, pour cette zone.
Important
Un serveur DNS ne faisant pas autorité peut utiliser la récursivité ou le transfert pour résoudre une requête DNS. Cette rubrique fait référence au serveur ne faisant pas autorité en tant que serveur DNS récursif ; si le serveur utilise le transfert, le processus utilisé pour la validation DNSSEC des réponses DNS est le même.
DNSKEY
Un serveur DNS récursif utilise l’enregistrement de ressource DNSKEY pour valider les réponses du serveur DNS faisant autorité. Pour valider les réponses, le serveur DNS déchiffre les signatures numériques contenues dans les enregistrements de ressources liés à DNSSEC et compare les valeurs de hachage. Si les valeurs de hachage sont identiques, il fournit une réponse au client DNS avec les données DNS qu’il a demandées, telles qu’un enregistrement de ressource d’hôte (A). Si les valeurs de hachage ne correspondent pas, il répond par un SERVFAIL message. De cette façon, un serveur DNS capable de résoudre DNSSEC avec une ancre de confiance valide installée protège contre les attaques d’usurpation DNS, que les clients DNS soient ou non compatibles DNSSEC.
Si votre client DNS prend en charge DNSSEC, il peut être configuré pour exiger que le serveur DNS effectue une validation DNSSEC.
La figure suivante illustre le processus de validation.
Les DNSKEY sont utilisées pour calculer les valeurs de hachage et déchiffrer les enregistrements RRSIG. La figure n’affiche pas tous les processus de validation effectués. Une validation supplémentaire est également effectuée pour s’assurer que les DNSKEY sont valides et que les enregistrements DS sont valides, s’ils existent (non montré dans la capture d’écran).
Processus de requête et de réponse DNS
Un exemple simple illustre comment vous pouvez incorporer DNSSEC dans le processus de requête et de réponse DNS pour fournir une validation.
Dans l’exemple suivant, un ordinateur client DNS interroge un serveur DNS récursif (mise en cache), qui à son tour interroge les serveurs DNS faisant autorité avant de renvoyer une réponse. Cet exemple suppose que les données DNS ne sont pas encore mises en cache sur le client ou le serveur. Les données DNSSEC valident l’authenticité des réponses DNS uniquement lorsqu’une zone est signée et que vous utilisez des serveurs et des clients compatibles DNSSEC.
La figure suivante illustre le processus de requête DNS récursive.
Le tableau suivant présente les étapes d’une requête et d’une réponse DNS avec des données DNSSEC facultatives.
| Étape | Requête-réponse | Données DNSSEC facultatives |
|---|---|---|
| 1 | Un client DNS envoie une requête DNS à un serveur DNS récursif. | Le client DNS peut indiquer qu’il prend en charge DNSSEC (DO=1). |
| 2 | Le serveur DNS récursif envoie une requête DNS aux serveurs DNS racine et TLD (First Level Domain). | Le serveur DNS récursif peut indiquer qu’il prend en charge DNSSEC (DO=1). |
| 3 | Les serveurs racine et TLD renvoient une réponse DNS au serveur DNS récursif fournissant l’adresse IP du serveur DNS faisant autorité pour la zone. | Les serveurs faisant autorité pour la zone parent peuvent indiquer que la zone enfant est signée à l’aide de DNSSEC et inclut une délégation sécurisée (enregistrement DS). |
| 4 | Le serveur DNS récursif envoie une requête DNS au serveur DNS faisant autorité pour la zone. | Le serveur DNS récursif peut indiquer qu’il prend en charge DNSSEC (DO=1) et qu’il est capable de valider les enregistrements de ressources signés (CD=1) à envoyer dans la réponse. |
| 5 | Le serveur DNS faisant autorité renvoie une réponse DNS au serveur DNS récursif, fournissant les données d’enregistrement de ressource. | Le serveur DNS faisant autorité peut inclure des signatures DNSSEC sous la forme d’enregistrements RRSIG dans la réponse DNS, à utiliser dans la validation. |
| 6 | Le serveur DNS récursif renvoie une réponse DNS au client DNS, fournissant les données d’enregistrement de ressource. | Le serveur DNS récursif peut indiquer si la réponse DNS a été validéeAD=1 () à l’aide de DNSSEC. |
Y compris les données DNSSEC
Les indicateurs liés à DNSSEC (bits) sont utilisés dans une requête et une réponse DNS pour déterminer si les données DNSSEC sont incluses et si la validation a été effectuée. Ces indicateurs sont définis en activant ou en désactivant les bits de données étendus dans l’en-tête du paquet DNS. Lorsque ces indicateurs sont activés, on parle de « réglage » du bit (la valeur est définie sur 1). La désactivation d’un indicateur est appelée « effacement » du bit (la valeur est définie sur 0).
-
DO : Le bit DO est inclus dans une requête DNS et est l’abréviation de « DNSSEC OK ». Si le bit DO est défini (
DO=1), le client prend en charge DNSSEC et le serveur DNS peut renvoyer des données DNSSEC en toute sécurité dans une réponse. Si le bit DO n’est pas défini (DO=0), le client ne prend pas en charge DNSSEC et le serveur DNS ne peut pas inclure de données DNSSEC dans une réponse DNS. Les clients DNS peuvent toujours être protégés à l’aide de DNSSEC, même s’ils ne sont pas compatibles avec DNSSEC. Dans ce contexte, un client DNS est un ordinateur qui envoie une requête DNS. Lorsqu’un serveur DNS récursif envoie une requête au serveur DNS faisant autorité, le serveur DNS récursif doit indiquer qu’il prend en charge DNSSEC afin que le serveur DNS faisant autorité envoie des données DNSSEC dans la réponse. -
AD : Le bit AD est inclus dans une réponse DNS et est l’abréviation de « données authentifiées ». Si le bit AD est défini (
AD=1), cela signifie que la réponse DNS est authentique car elle a été validée à l’aide de DNSSEC. Un ordinateur non validant prenant en charge DNSSEC, tel qu’un ordinateur exécutant Windows 8, n’effectue pas de validation DNSSEC, mais peut être configuré pour exiger que les réponses DNS soient authentiques. Si le bit AD n’est pas défini (AD=0), la réponse DNS n’a pas été validée. Le bit AD n’est peut-être pas défini, soit parce que la validation n’a pas été tentée, soit parce que la validation a échoué. -
CD : Le bit CD est inclus dans une requête DNS et est l’abréviation de « checking disabled ». Si le bit CD est défini (
CD=1) dans une requête, cela signifie qu’une réponse DNS doit être envoyée, que la validation ait été effectuée avec succès ou non. Si le bit CD n’est pas défini (CD=0), aucune réponse DNS n’est envoyée si la validation était requise et a échoué. Si le bit CD est vide (CD=0), cela signifie que la vérification est activée et que la validation DNSSEC peut avoir lieu. Le bit CD peut être défini (CD=1) dans une requête, car l’hôte est capable d’effectuer la validation DNSSEC et ne nécessite pas de validation en amont, comme un serveur DNS récursif exécutant Windows Server 2012 ou version ultérieure. Un résolveur de stub non validant, tel qu’un ordinateur exécutant un client DNS Windows, émet des requêtes avec le bit de CD effacé.CD=0Pour plus d’informations, voir RFC4035, section 3.2.2.
Un quatrième indicateur important (bit) qui peut être présent dans un en-tête de paquet DNS est le bit AA. Cet indicateur n’est pas nouveau avec DNSSEC, mais il peut être utilisé lorsque DNSSEC est déployé :
-
AA : Le bit AA est inclus dans une réponse DNS et est l’abréviation de « réponse faisant autorité ». Si le bit AA est défini, cela signifie que la réponse DNS est authentique car elle provient directement d’un serveur DNS faisant autorité. Un client qui nécessite une validation DNSSEC (
AD=1) accepte le bit AA à la place (AA=1,AD=0). Si le client interroge directement un serveur faisant autorité, car les réponses faisant autorité n’ont pas besoin d’être validées. Il serait redondant pour un serveur faisant autorité de valider sa propre réponse.
Exemples de requêtes DNS
Les exemples suivants affichent les résultats d’une requête DNS exécutée à partir d’un ordinateur client DNS exécutant Windows 8.1 à l’aide de l’applet de commande Resolve-DnsName . L’applet de commande Resolve-DnsName a été introduite dans Windows Server 2012 et Windows 8 et peut être utilisée pour afficher des requêtes DNS qui incluent des données DNSSEC.
Important
N’utilisez pas l’outil en ligne de commande pour tester la nslookup.exe prise en charge de DNSSEC pour une zone. L’outil nslookup.exe utilise un client DNS interne qui n’est pas compatible DNSSEC.
Exemple 1 : Dans l’exemple suivant, une requête est envoyée à un serveur DNS récursif pour un enregistrement d’adresse (A) dans la zone signée secure.contoso.com avec DO=0.
Resolve-DnsName finance.secure.contoso.com –type A -server dns1.contoso.com
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
finance.secure.contoso.com A 2848 Answer 192.168.0.200
Le bit DO n’est pas défini car le paramètre dnssecok n’a pas été inclus.
Exemple 2 : Dans l’exemple suivant, l’indicateur DO=1 est défini en ajoutant le paramètre dnssecok .
Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com -dnssecok
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
finance.secure.contoso.com A 2848 Answer 192.168.0.200
Name : finance.secure.contoso.com
QueryType : RRSIG
TTL : 2848
Section : Answer
TypeCovered : A
Algorithm : 8
LabelCount : 4
OriginalTtl : 3600
Expiration : 10/18/2013 8:23:41 PM
Signed : 10/8/2013 7:23:41 PM
Signer : secure.contoso.com
Signature : {86, 229, 217, 39...}
Name : .
QueryType : OPT
TTL : 32768
Section : Additional
Data : {}
Lorsque DO=0, le serveur DNS n’envoie pas de données DNSSEC dans la réponse DNS. Lorsque DO=1, le client indique qu’il est en mesure de recevoir des données DNSSEC si elles sont disponibles. Étant donné que la secure.contoso.com zone est signée, un enregistrement de ressource RRSIG a été inclus dans la réponse DNS lorsque DO=1.
Dans l’exemple 1 et l’exemple 2, la validation n’est pas requise pour la secure.contoso.com zone, car la table de stratégie de résolution de noms (NRPT) n’est pas configurée pour exiger la validation.
Vous pouvez utiliser l’applet de commande Get-DnsClientNrptPolicy pour afficher les règles NRPT actuelles. Pour plus d’informations, consultez Get-DnsClientNrptPolicy.
Exemple 3 : Dans l’exemple suivant, une règle NRPT s’affiche pour secure.contoso.com.
Get-DnsClientNrptPolicy
Namespace : .secure.contoso.com
QueryPolicy :
SecureNameQueryFallback :
DirectAccessIPsecCARestriction :
DirectAccessProxyName :
DirectAccessDnsServers :
DirectAccessEnabled :
DirectAccessProxyType : NoProxy
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired : False
NameServers :
DnsSecIPsecCARestriction :
DnsSecQueryIPsecEncryption :
DnsSecQueryIPsecRequired : False
DnsSecValidationRequired : False
NameEncoding : Utf8WithoutMapping
Dans cet exemple, la valeur de DnsSecValidationRequired est False. Lorsque la valeur est false, la validation DNSSEC n’est pas requise.
Exemple 4 : Lorsque la validation DNSSEC est activée pour secure.contoso.com, le NRPT affiche True pour DnsSecValidationRequired. Cet exemple affiche uniquement l’espace de secure.contoso.com noms et le paramètre DnsSecValidationRequired .
(Get-DnsClientNrptPolicy -NameSpace secure.contoso.com).DnsSecValidationRequired
True
Si la valeur de DnsSecValidationRequired est True , les ordinateurs clients prenant en charge DNSSEC envoient toujours des requêtes avec DO=1, même si le paramètre dnssecok n’est pas inclus.
Exemple 5 : Lorsque la validation DNSSEC est requise dans la table de politique de résolution de noms (NRPT), le bit OK DNSSEC est automatiquement défini (DO=1) pour les clients prenant en charge DNSSEC.
Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
finance.secure.contoso.com A 2848 Answer 192.168.0.200
Name : finance.secure.contoso.com
QueryType : RRSIG
TTL : 2848
Section : Answer
TypeCovered : A
Algorithm : 8
LabelCount : 4
OriginalTtl : 3600
Expiration : 10/18/2013 8:23:41 PM
Signed : 10/8/2013 7:23:41 PM
Signer : secure.contoso.com
Signature : {86, 229, 217, 39...}
Name : .
QueryType : OPT
TTL : 32768
Section : Additional
Data : {}
Dans cet exemple, un enregistrement RRSIG est envoyé dans la réponse DNS afin de remplir les conditions de validation pour secure.contoso.com. Une ancre de confiance valide est également configurée sur le serveur dns1.contoso.comDNS récursif.
Si un client DNS n’est pas compatible DNSSEC, la règle NRPT ne s’applique pas et les requêtes sont envoyées avec DO=0, même s’il existe une règle NRPT qui nécessite une validation DNSSEC.
Exemple 6 : Dans l’exemple suivant, la même requête est exécutée que dans l’exemple 5, mais sans ancre de confiance valide configurée sur dns1.contoso.com.
Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com
Resolve-DnsName : finance.secure.contoso.com : Unsecured DNS packet
At line:1 char:1
+ Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.co ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (finance.secure.contoso.com:String) [Resolve-DnsName], Win32Excepti
on
+ FullyQualifiedErrorId : DNS\_ERROR\_UNSECURE\_PACKET,Microsoft.DnsClient.Commands.ResolveDnsName
Dans cet exemple, la résolution DNS échoue avec le message DNS_ERROR_UNSECURE_PACKET. La résolution échoue car la validation est requise dans le NRPT mais ne peut pas être effectuée en raison de l’absence d’une ancre de confiance valide pour la zone secure.contoso.com. L’applet de commande Resolve-DnsName fournit des résultats détaillés pour le type de défaillance rencontrée. Si le client DNS tente de résoudre le problème finance.secure.contoso.com afin de se connecter à cet hôte, celui-ci échoue.
Scénarios DNSSEC
DNSSEC peut être déployé dans de nombreux environnements différents avec des paramètres de serveur et de client uniques, il est important de comprendre comment les requêtes et les réponses DNS sont affectées.
Considérez les quatre instructions suivantes liées à DNSSEC. Chaque instruction affecte le fonctionnement de DNSSEC dans un scénario donné :
- L’enregistrement
finance.secure.contoso.comde la ressource est correctement signé avec DNSSEC. - Un serveur DNS récursif est capable de valider les réponses à une requête pour
finance.secure.contoso.com. - Un client DNS prend en charge DNSSEC.
- Un client DNS est configuré pour exiger la validation de toutes les requêtes dans l’espace de
secure.contoso.comnoms.
Examinons chacune de ces quatre affirmations plus en détail.
Statut de signature DNSSEC : DNSSEC signe tous les enregistrements de la zone, cette condition fait référence à l’état de la
secure.contoso.comzone, et pas seulement à l’enregistrement de ressourcefinance.secure.contoso.com. Vous ne pouvez pas signer certains enregistrements et ne pas en signer d’autres. Par conséquent, l’état DNSSEC definance.secure.contoso.comdépend de l’état DNSSEC desecure.contoso.com.Signée correctement : La
secure.contoso.comzone peut être signée de manière valide, ce qui permetfinance.secure.contoso.comd’être validée comme authentique. Pour être valide, la zone doit être signée avec des clés valides et non expirées, et tous les enregistrements de ressources requis liés à DNSSEC doivent être présents.Non signé : la
secure.contoso.comzone n’est peut-être pas signée, auquel cas aucun enregistrement RRSIG n’est associé àfinance.secure.contoso.comet les réponses DNS aux requêtes nefinance.secure.contoso.compeuvent pas être validées. Si un client nécessite une validation, une requête DNS envoyée à un serveur DNS récursif échoue, car le client DNS n’accepte pas une réponse non validée. Si un client interroge directement un serveur faisant autorité, il n’échoue pas à la validation, car la réponse est déjà considérée comme authentique.Non signé correctement : la
secure.contoso.comzone peut être signée, mais pas de manière valide. Par exemple, une ou plusieurs clés de signature DNSSEC peuvent avoir expiré. Une fois que vous avez initialement signé une zone, celle-ci doit être régulièrement resignée avec de nouvelles clés avant l’expiration de la période de validité de la clé de signature, afin de maintenir un état opérationnel DNSSEC sécurisé. La période de validité des clés de signature DNSSEC doit être suffisamment courte pour maintenir la sécurité, mais suffisamment longue pour permettre une administration facile. DNSSEC dans Windows Server 2012 et Windows Server 2012 R2 prend en charge le remplacement automatique des clés, ce qui offre à la fois sécurité et facilité d’administration pour vos zones signées DNSSEC.
État de validation : un serveur DNS récursif avec une ancre de confiance valide (clé cryptographique publique) pour la
secure.contoso.comzone est capable de valider une réponse DNS pour l’enregistrement de ressourcefinance.secure.contoso.com. Un serveur DNS récursif doit également prendre en charge les normes et les algorithmes DNSSEC utilisés pour signer la zone.Peut valider : si le serveur DNS récursif prend en charge tous les algorithmes de chiffrement utilisés pour signer la
secure.contoso.comzone et qu’il dispose d’une ancre de confiance valide qu’il peut utiliser pour déchiffrer la signature DNSSEC associée à l’enregistrement de ressource signé, il peut valider l’authenticité de l’enregistrement de ressourcefinance.secure.contoso.com.Impossible de valider : un serveur DNS non compatible DNSSEC n’est pas capable de validation. De même, un serveur DNS qui n’a pas actuellement d’ancre de confiance valide pour la zone
secure.contoso.com, il n’est pas capable de valider une réponse DNS pourfinance.secure.contoso.com. Les ancres d’approbation doivent être mises à jour lorsqu’une zone est resignée, par exemple, lors du basculement de clé. DNSSEC dans Windows Server 2012 et Windows Server 2012 R2 prend en charge la mise à jour automatique des ancres de confiance lors du remplacement de clé conformément à la RFC 5011, « Mises à jour automatisées des ancres de confiance de sécurité DNS (DNSSEC) ».
État compatible DNSSEC : l’état compatible DNSSEC d’un client DNS dépend du système d’exploitation qu’il exécute. Le service client DNS Windows dans Windows 7 ou Windows Server 2008 R2 et les systèmes d’exploitation ultérieurs sont des résolveurs de stub non validants prenant en charge DNSSEC. Les systèmes d’exploitation Windows précédents ne prennent pas en charge DNSSEC. Le client DNS informe un serveur DNS s’il prend en charge DNSSEC ou non lorsqu’il envoie une requête DNS.
Le client et le serveur prennent en charge DNSSEC : si le client et le serveur sont tous deux compatibles DNSSEC, la réponse DNS du serveur au client inclut l’indicateur de données authentifiées DNSSEC (AD). Si la réponse DNS est validée avec DNSSEC, alors
AD=1elle est envoyée. Si la réponse DNS n’a pas été validée, elleAD=0est envoyée.Le serveur DNS n’est pas compatible DNSSEC : si le serveur DNS ne prend pas en charge DNSSEC, aucune validation n’est effectuée et l’indicateur AD n’est pas défini (
AD=0), que le client DNS prenne en charge DNSSEC ou non.Le client DNS n’est pas compatible DNSSEC : si le client DNS ne prend pas en charge DNSSEC, le serveur DNS ne définit pas l’indicateur AD dans sa réponse au client, même s’il comprend DNSSEC. Toutefois, si le serveur DNS prend en charge DNSSEC et qu’il dispose d’une ancre d’approbation pour la zone, le serveur tente de valider la réponse du serveur faisant autorité. Si la validation échoue, elle renvoie une défaillance du serveur DNS au client DNS. Si la validation réussit, elle renvoie les résultats de la requête au client. De cette façon, un serveur DNS récursif compatible DNSSEC peut protéger les clients DNS non compatibles DNSSEC. Dans ce scénario, si la zone n’est pas signée, aucune validation n’est tentée et la réponse est renvoyée normalement au client.
Exigence de validation : ce paramètre détermine l’exigence d’un client DNS compatible DNSSEC pour les données DNSSEC (l’indicateur AD) dans une réponse d’un serveur DNS. Pour que le client DNS nécessite une validation, il doit être compatible DNSSEC. Les clients DNS non compatibles DNSSEC ne peuvent pas être forcés à exiger une validation DNSSEC. Si le client DNS interroge directement un serveur DNS faisant autorité, la réponse est validée, même si la zone n’est pas signée. En effet, les serveurs DNS faisant autorité renvoient toujours des réponses authentiques.
La validation est requise : si la validation est requise, le client doit recevoir
AD=1(validation réussie) ou il rejette la réponse DNS. Si la validation a échoué ou n’a pas été tentée (AD=0), la résolution DNS échoue. Cela est vrai même si la zone n’est pas signée. Cela ne s’applique qu’aux requêtes sur un serveur DNS récursif et ne faisant pas autorité.La validation n’est pas requise : si la validation n’est pas requise, le client accepte une réponse d’un serveur DNS récursif non compatible DNSSEC. Toutefois, si le serveur DNS récursif prend en charge DNSSEC et que la validation échoue, il renvoie un basculement de serveur au client, même si celui-ci ne nécessite pas de validation.
Étapes suivantes
Voici quelques articles pour en savoir plus sur DNSSEC pour le serveur DNS.