Remarque
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 obtenir une présentation de DNSSEC pour le serveur DNS dans Windows Server, consultez Vue d’ensemble de DNSSEC.
Les signatures numériques sont incluses dans les réponses DNS pour assurer la validation. Ces signatures numériques sont contenues dans les enregistrements de ressources liés à DNSSEC qui sont générés et ajoutés à la zone durant la signature de 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 par DNSSEC, il demande que le serveur DNS faisant autorité envoie également des enregistrements DNSSEC pour valider la réponse DNS. Un serveur DNS récursif ou de transfert reconnaît que la zone prend en charge la technologie DNSSEC si elle possède un DNSKEY, également appelé « ancre d’approbation », 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. Dans cette rubrique, le serveur ne faisant pas autorité est considéré comme un 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 adresse une réponse au client DNS avec les données DNS qu’il a demandées, telles qu’un enregistrement de ressource (A) hôte. Si les valeurs de hachage ne correspondent pas, il répond par un message SERVFAIL. De cette façon, un serveur DNS de résolution compatible avec la technologie DNSSEC et sur lequel une ancre d’approbation valide est installée vous protège contre les usurpation DNS, que les clients DNS prennent en charge la technologie DNSSEC ou non.
Si votre client DNS prend en charge DNSSEC, il peut être configuré pour exiger du serveur DNS qu’il effectue une validation DNSSEC.
Le graphique suivant illustre le processus de validation.
Les DNSKEY sont utilisées pour calculer les valeurs de hachage et déchiffrer les enregistrements RRSIG. La figure ne présente pas tous les processus de validation effectués. Une validation supplémentaire est également effectuée pour garantir la validité des DNSKEY et des enregistrements DS, le cas échéant (ne figurent pas 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 assurer la validation.
Dans l’exemple suivant, un ordinateur client DNS interroge un serveur DNS (avec mise en cache) récursif, qui, à son tour, interroge les serveurs DNS faisant autorité avant de renvoyer une réponse. Cet exemple considère que les données DNS ne sont pas encore mises en cache sur le client ou le serveur. Les données DNSSEC ne valident l’authenticité des réponses DNS que lorsqu’une zone est signée et que vous utilisez des serveurs et des clients prenant en charge DNSSEC.
Le graphique suivant illustre le processus de requête DNS récursive.
Le tableau suivant indique les étapes d’une requête et d’une réponse DNS avec des données DNSSEC facultatives.
| Step | Query-response | Données DNSSEC facultatives |
|---|---|---|
| 1 | Un client DNS envoie une requête DNS vers 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 vers les serveurs DNS de la racine et du domaine de premier niveau (TLD). | 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 vers le serveur DNS récursif en fournissant l’adresse IP du serveur DNS faisant autorité pour la zone. | Les serveurs faisant autorité pour la zone parente peuvent indiquer que la zone enfant est signée à l’aide de DNSSEC et qu’elle comprend une délégation sécurisée (enregistrement DS). |
| 4 | Le serveur DNS récursif envoie une requête DNS vers le 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 peut 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 vers le serveur DNS récursif, en 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 pour les utiliser dans la validation. |
| 6 | Le serveur DNS récursif renvoie une réponse DNS vers le client DNS, en fournissant les données d’enregistrement de ressource. | Le serveur DNS récursif peut indiquer si la réponse DNS a été validée (AD=1) en utilisant DNSSEC. |
Inclusion de données DNSSEC
Des indicateurs (bits) liés à DNSSEC sont utilisés dans une requête et une réponse DNS pour déterminer si des données DNSSEC sont incluses, et si la validation a été effectuée. Ces indicateurs sont définis par l’activation ou la désactivation de bits de données étendus dans l’en-tête de paquet DNS. Lorsque ces indicateurs sont activés, on parle de « définition » du bit (la valeur est définie sur 1). L’action qui consiste à désactiver 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 une 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 retourner des données DNSSEC dans une réponse sans aucun risque. Si le bit DO n’est pas défini (DO=0), le client ne prend pas en charge DNSSEC, et le serveur DNS ne doit pas inclure de données DNSSEC dans une réponse DNS. Les clients DNS peuvent toujours être protégés avec DNSSEC, même s’ils ne prennent pas en charge DNSSEC. Dans ce contexte, un client DNS est un ordinateur qui envoie une requête DNS. Quand un serveur DNS récursif envoie une requête au serveur DNS faisant autorité, il 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 une abréviation pour les « 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 avec DNSSEC. Un ordinateur prenant en charge DNSSEC sans validation, comme un ordinateur exécutant Windows 8, n’effectue pas de validation DNSSEC mais peut être configuré pour exiger des réponses DNS authentiques. Si le bit AD n’est pas défini (AD=0), cela signifie que la réponse DNS n’a pas été validée. Cela peut être dû au fait que la validation n’a pas été tentée ou qu’elle a échoué. -
CD : le bit CD est inclus dans une requête DNS et est une abréviation de « vérification désactivée ». 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 abouti 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 est effacé (CD=0), cela signifie que la vérification est activée et que la validation DNSSEC peut se produire. 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 une 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=0. Pour plus d’informations, consultez RFC4035, section 3.2.2.
Un quatrième indicateur important (bit) pouvant appartenir à un en-tête de paquet DNS est le bit AA. Cet indicateur n’est pas nouveau pour DNSSEC, mais il peut être utilisé lorsque DNSSEC est déployé :
-
AA : Le bit AA est inclus dans une réponse DNS et est une abréviation de « réponse faisant autorité ». Si le bit AA est défini, cela signifie que la réponse DNS est authentifiée, car elle provient directement d’un serveur DNS faisant autorité. Un client qui exige une validation DNSSEC (
AD=1) accepte le bit AA (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 de requête DNS exécutés à 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 nslookup.exe pour tester la prise en charge de la technologie DNSSEC pour une zone. L’outil nslookup.exe utilise un client DNS interne qui ne prend pas en charge 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 peut recevoir des données DNSSEC le cas échéant. Comme la zone secure.contoso.com est signée, un enregistrement de ressource RRSIG a été inclus dans la réponse DNS lorsque DO=1.
Dans les exemples 1 et 2, la validation n’est pas exigée pour la zone secure.contoso.com, car la table de stratégie de résolution de noms (NRPT) n’est pas configurée pour exiger une 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 exigée.
Exemple 4 : Avec la validation DNSSEC activée pour secure.contoso.com, le NRPT affiche True pour DnsSecValidationRequired. Cet exemple affiche uniquement l’espace secure.contoso.com de 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 stratégie de résolution de noms (NRPT), le bit DNSSEC OK 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 répondre aux exigences de validation de secure.contoso.com. Une ancre d’approbation valide est également configurée sur le serveur DNS récursif dns1.contoso.com.
Si un client DNS ne prend pas en charge DNSSEC, la règle NRPT ne s’applique pas et les requêtes sont envoyées avec DO=0, même si une règle NRPT existante exige une validation DNSSEC.
Exemple 6 : Dans l’exemple suivant, la même requête est effectuée comme 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 exigée dans la table NRPT ne peut pas être effectuée en raison de l’absence d’une ancre d’approbation valide pour la zone secure.contoso.com. L’applet de commande Resolve-DnsName signale des résultats détaillés pour le type d’échec rencontré. Si le client DNS tente de résoudre finance.secure.contoso.com afin de se connecter à cet hôte, il échoue.
Scénarios DNSSEC
DNSSEC pouvant être déployé dans divers environnements avec des paramètres de client et serveur uniques, il est important de comprendre comment les requêtes et les réponses DNS sont affectées.
Examinez les quatre instructions suivantes liées à DNSSEC. Chaque instruction affecte le fonctionnement de la technologie DNSSEC dans un scénario donné :
- L’enregistrement de ressource
finance.secure.contoso.comest 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 la technologie DNSSEC.
- Un client DNS est configuré pour exiger une validation pour toutes les requêtes dans l’espace de noms
secure.contoso.com.
Examinons de plus près chacune de ces quatre instructions.
Statut de signature DNSSEC : DNSSEC signe tous les enregistrements de la zone. Cette condition fait référence à l’état de la zone
secure.contoso.com, 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é 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 n’ayant pas expirés et tous les enregistrements de ressource DNSSEC liées doivent être présents.Non signé : la
secure.contoso.comzone peut ne pas être signée, auquel cas aucun enregistrement RRSIG n’est associéfinance.secure.contoso.com, et les réponses DNS aux requêtes pourfinance.secure.contoso.comlesquelles vous ne pouvez pas être validées. Si un client exige une validation, une requête DNS envoyée à un serveur DNS récursif échoue, car le client DNS n’accepte pas de réponse non validée. Si un client interroge directement un serveur faisant autorité, la validation n’échoue pas, car la réponse est déjà considérée comme authentique.Signature incorrecte : la zone
secure.contoso.comest peut-être signée, mais pas de manière valide. Par exemple, une ou plusieurs clés de signature DNSSEC peuvent avoir expiré. Après la signature initiale d’une zone, celle-ci doit être resignée de façon régulière avec de nouvelles clés avant que la période de validité de la clé de signature n’arrive à expiration, ceci afin de maintenir un état DNSSEC opérationnel 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 faciliter l’administration. Dans Windows Server 2012 et Windows Server 2012 R2, DNSSEC prend en charge la substitution de clé automatique, ce qui favorise la sécurité et facilite l’administration de vos zones signées par DNSSEC.
État de validation : un serveur DNS récursif avec une ancre d’approbation valide (clé de chiffrement 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 DNSSEC et les algorithmes 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 d’approbation valide qu’il peut utiliser pour déchiffrer la signature DNSSEC associée à l’enregistrement de ressource signé, elle peut valider l’enregistrementfinance.secure.contoso.comde ressource comme authentique.Impossible de valider : un serveur DNS NE prenant pas en compte DNSSEC n’est pas capable de la validation. De la même façon, un serveur DNS qui ne dispose pas d’une ancre de validation valide pour la zone
secure.contoso.comn’a pas les moyens de valider une réponse DNS pourfinance.secure.contoso.com. Les ancres d’approbation doivent être mises à jour lors d’une nouvelle signature de zone, par exemple, au cours de la substitution de clé d’approbation. DNSSEC dans Windows Server 2012 et Windows Server 2012 R2 prend en charge la mise à jour automatique des ancres d’approbation sur la substitution de clé par RFC 5011, « Mises à jour automatisées des ancres de confiance DNS (DNSSEC) ».
État prenant en compte DNSSEC : l’état de prise en compte DNSSEC d’un client DNS dépend du système d’exploitation qu’il exécute. Le service Client DNS Windows de Windows 7 ou de Windows Server 2008 R2 et les systèmes d’exploitation ultérieurs sont des résolveurs de stub sans validation qui prennent en charge DNSSEC. Les systèmes d’exploitation Windows précédents ne sont pas compatibles avec la technologie DNSSEC. Le client DNS informe un serveur DNS qu’il prend en charge ou non DNSSEC au moment d’envoyer une requête DNS.
Le client et le serveur sont tous deux compatibles 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,
AD=1est envoyé. Si la réponse DNS n’est pas validée,AD=0est envoyé.Le serveur DNS n’est pas compatible DNSSEC : si le serveur DNS n’est pas compatible DNSSEC, aucune validation n’est effectuée et l’indicateur AD n’est pas défini (
AD=0), que le client DNS soit compatible DNSSEC ou non.Le client DNS n’est pas compatible DNSSEC : si le client DNS n’est pas compatible DNSSEC, le serveur DNS ne définit pas l’indicateur AD dans sa réponse au client, même s’il comprend DNSSEC. En revanche, si le serveur DNS prend en charge DNSSEC et dispose d’une ancre d’approbation pour la zone, il tente de valider la réponse du serveur faisant autorité. Si la validation échoue, il retourne une erreur de serveur DNS au client DNS. Si la validation réussit, il retourne les résultats de la requête au client. Ainsi, un serveur DNS récursif prenant en charge la technologie DNSSEC peut protéger des clients DNS qui ne la prennent pas en charge. Dans ce scénario, si la zone n’est pas signée, aucune validation n’est tentée et la réponse est retournée normalement au client.
Condition de validation : ce paramètre détermine l’exigence d’un client DNSSEC prenant en charge DNS POUR les données DNSSEC (l’indicateur AD) dans une réponse d’un serveur DNS. Pour que le client DNS requière une validation, il doit prendre en charge la technologie DNSSEC. Les clients DNS qui ne prennent pas en charge DNSSEC ne peuvent pas être contraints d’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. Ceci est dû au fait que les serveurs DNS faisant autorité renvoient toujours les réponses authentifiées.
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 s’applique uniquement aux requêtes adressées à un serveur DNS récursif ne faisant pas autorité.La validation n’est pas requise : si la validation n’est pas requise, le client accepte une réponse provenant d’un serveur DNS récursif non compatible DNSSEC. En revanche, si le serveur DNS récursif prend en charge DNSSEC et que la validation échoue, il retourne un basculement de serveur au client, même si le client n’exige pas de validation.
Étapes suivantes
Voici quelques articles pour en savoir plus sur DNSSEC pour serveur DNS.