Skip to main content
Resources

Vérification des ancres de confiance actuelles des résolveurs de validation du DNS

Cette page est disponible en:

Ce document a été traduit dans plusieurs langues dans un but purement informatif. Le texte original faisant foi (en anglais) peut être consulté sur : https://www.icann.org/dns-resolvers-checking-current-trust-anchors

La présente page est destinée aux administrateurs des résolveurs du DNS (parfois appelés « résolveurs récursifs ») qui souhaitent s'assurer de bien utiliser la dernière ancre de confiance pour la validation des DNSSEC. Si vous utilisez un tel résolveur et que vous n'êtes pas sûr que votre résolveur soit prêt pour le roulement de la KSK, vous pouvez suivre les instructions indiquées ici afin de vous assurer de disposer de la dernière ancre de confiance.

Un document connexe décrit la façon de mettre à jour les dernières ancres de confiance ; ce document est disponible ici. De plus amples informations relatives au roulement de la KSK sont disponibles ici.

Les présentes informations ne sont nécessaires que si votre résolveur de DNS procède à la validation des DNSSEC. L'ICANN encourage la validation des DNSSEC dès qu'il est judicieux d'y procéder, mais si vous ne procédez pas encore à la validation des DNSSEC, les présentes informations ne vous sont pas utiles.

Afin de savoir si le résolveur que vous utilisez procède ou non à la validation des DNSSEC, vous pouvez utiliser le domaine spécial « dnssec-failed.org » qui est exploité en tant que service public par Comcast. Ce domaine spécial fera en sorte que les résolveurs de validation ne puissent pas, délibérément, donner une réponse. Utilisez la commande suivante au niveau d'une ligne de commande nominale :

dig @ADDRESS dnssec-failed.org a +dnssec

Dans cette commande, remplacez la chaîne ADDRESS par l'adresse IPv4 ou IPv6 du résolveur que vous utilisez.

Si la réponse inclut ce qui suit :

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

alors le résolveur procède à la validation des DNSSEC. (Le statut SERVFAIL indique ici que la validation a échoué, ce qui signifie que le résolveur procède bien à la validation.)

Si au contraire la réponse inclut ce qui suit :

;; ->>HEADER<<- opcode: QUERY, status: NOERROR

alors le résolveur ne procède pas à la validation des DNSSEC.

Le reste de cette page indique plusieurs mises en œuvre de résolveur ainsi que les instructions nécessaires afin de vérifier les ancres de confiance sur ces dernières.


BIND

Les versions 9.9, 9.10 et 9.11 de BIND prennent en charge la validation des DNSSEC à l'aide de la mise à jour automatique RFC 5011. Les dernières sous-versions de ces versions contiennent KSK2017 en tant que partie intégrante des ancres de confiance.

Vérifiez d'abord que la validation des DNSSEC est établie dans votre fichier de configuration. Vous devez voir une ligne dans la section optionsindiquant soit dnssec-validation auto; soit dnssec-validation yes;. Si votre configuration indique dnssec-validation yes;, vous devez la modifier afin qu'elle indique dnssec-validation auto; et redémarrer votre serveur afin de suivre les étapes indiquées ci-dessous.

Afin de générer un fichier contenant les ancres de confiance utilisées, utilisez la commande

rndc secroots

Cette commande crée un fichier appelé named.secroots dans le même annuaire où sont créés d'autres fichiers de BIND. Ce fichier doit contenir deux lignes, l'une d'entre elles indiquant ./RSASHA256/20326 et l'autre ./RSASHA256/19036. S'il ne dispose pas de ces deux clés, vous devez mettre à jour vos ancres de confiance tel qu'indiqué ici.

ISC, les créateurs de BIND, dispose d'informations supplémentaires relatives aux ancres de confiance des DNSSEC pour BIND sur https://kb.isc.org/article/AA-01529/169/KSK-2010-Rollover.html [kb.isc.org].


Unbound

Recherchez le fichier root.key dans l'annuaire de configuration d'Unbound, qui est normalement /etc/unbound. Il doit y avoir des enregistrements DNSKEY, un avec le texte id = 20326 et un autre avec le texte id = 19036 ; ces deux enregistrements doivent également indiquer ;;state=2 [ VALID ].

Si vous utilisez la version 1.6.2 d'Unbound ou une version ultérieure, vous pouvez également obtenir la liste des clés de confiance en demandant au résolveur le nom trustanchor.unbound dans la classe CH pour le type de ressource TXT, comme pour une commande :

dig @address trustanchor.unbound -c CH -t TXT

Si le fichier n'a aucune de ces clés, ou si le statut de l'une de ces clés n'indique pas ;;state=2 [ VALID ], ou si la demande n'indique pas les deux clés, vous devez mettre à jour vos ancres de confiance tel qu'indiqué ici.


Récurseur PowerDNS

La version 4 du récurseur PowerDNS prend en charge la validation des DNSSEC mais ne prend pas encore en charge la validation des DNSSEC à l'aide de la mise à jour automatique RFC 5011. Cela signifie que pour le récurseur PowerDNS, vous devez obtenir un nouvel ensemble d'ancres de confiance à chaque fois que les ancres de confiance changent. La version 4.0.5 ainsi que les versions ultérieures du récurseur PowerDNS contiennent KSK2017 en tant que partie intégrante des ancres de confiance installées.

Dans l'interface commande-ligne, utilisez la commande :

rec_control get-tas

Doivent apparaître une ligne qui comprend le texte . 20326 et une autre qui comprend le texte . 19036. En cas d'absence de ces deux clés, vous devez mettre à jour vos ancres de confiance tel qu'indiqué ici.


Résolveur Knot

Le résolveur Knot prend en charge la validation des DNSSEC à l'aide de la mise à jour automatique RFC 5011 dans toutes ses versions.

Recherchez le fichier root.keys dans l'annuaire de configuration du résolveur Knot (qui change selon la distribution). Il doit y avoir deux lignes, une comprenant le texte 0101030803010001A80020A95566BA42E886BB804CDA84E47EF56DB et une autre comprenant le texte 0101030803010001ACFFB409BCC939F831F7A1E5EC88F7A59255EC5. S'il ne dispose pas de ces deux clés, vous devez mettre à jour vos ancres de confiance tel qu'indiqué ici.


Windows Server 2012R2 et 2016

Windows Server, dans ses versions 2012R2 et 2016, prend en charge la validation des DNSSEC à l'aide de la mise à jour automatique RFC 5011. Les commandes ci-dessous utilisent Windows PowerShell.

Afin de vérifier le contenu des ancres de confiance, utilisez :

Get-DnsServerTrustAnchor -Name.

Vous devez voir s'afficher :

TrustAnchorName   TrustAnchorType   TrustAnchorState   TrustAnchorData
---------------   ---------------   ----------------   ---------------
.                 DNSKEY            Valid              [19036][DnsSec][RsaSha256][AwEAAagAIKlVZrpC6Ia7...
.                 DNSKEY            Valid              [20326][DnsSec][RsaSha256][AwEAAaz/tAm8yTn4Mfeh...

Les étiquettes clés sont affichées sous TrustAnchorData. Pour l'ancre de confiance de la racine, vous devez voir s'afficher deux étiquettes clés : 19036 et 20326. Le statut des deux ancres de confiance doit indiquer « Valide ». Si elle ne dispose pas de ces deux clés, vous devez mettre à jour vos ancres de confiance tel qu'indiqué ici.

Afin de voir tous les points de confiance actuels actifs sur le serveur, utilisez :

Get-DnsServerTrustPoint

S'affichera alors :

TrustPointName   TrustPointState   LastActiveRefreshTime   NextActiveRefreshTime
--------------   ---------------   ---------------------   ---------------------
.                Active            9/11/2017  8:37:02 PM   9/12/2017 8:37:02 PM 

Akamai DNSi Cacheserve

Akamai DNSi Cacheserve (dans ses versions 7.1.2.3, 7.2.0.3, 7.2.1.2 ou ultérieures) prend en charge la validation des DNSSEC à l'aide des clés gérées RFC 5011. Bien que cette fonctionnalité existe également dans des versions plus anciennes, elle ne doit être utilisée en raison d'un problème avec le code de roulement. Afin de vérifier qu'Akamai DNSi Cacheserve procède réellement à la validation, utilisez la commande suivante :

nom-tell cacheserve resolver.mget fields='(trusted-keys managed-keys-state)'

Si des champs trusted-keys ou managed-keys-state apparaissent dans les résultats, Akamai DNSi Cacheserve procède bien à la validation des DNSSEC et vous devez vous assurer que les bonnes clés sont utilisées. Dans managed-keys-state pour la racine, ('.') vous devez voir keyid avec la valeur de 19036 et 20326, les deux avec le state indiquant validet le champ has-validated indiquant True. Pour les clés de confiance, vous devez comparer le matériel de clé actuel. Pour ce faire, ou afin de réparer les clés si elles ne sont pas comme décrites, consultez la description ici.


Infoblox NIOS

Infobox NIOS prend en charge la validation des DNSSEC mais ne prend pas encore en charge la validation des DNSSEC à l'aide de la mise à jour automatique RFC 5011. Cela signifie que pour Infobox NIOS, vous devez configurer un nouvel ensemble d'ancres de confiance à chaque fois que les ancres de confiance changent.

Voici les étapes à suivre afin de vérifier les ancres de confiance actuelles dans NIOS :

  1. Connectez-vous dans l'interface graphique de NIOS
  2. Allez sur Data Management → DNS
  3. Cliquez sur « Grid DNS Properties » dans la barre d'outils
  4. Activez « Advanced Mode »
  5. Sélectionnez l'onglet « DNSSEC »
  6. Faites défiler jusqu'à « Trust Anchors »
  7. Toutes les ancres de confiance configurées apparaîtront dans le tableau « Trust Anchors ». Cherchez une entrée avec « . » dans la colonne « Zone » et une coche dans la colonne « Secure Entry Point ». (S'il n'y a pas une telle ancre de confiance, aucune clé de signature de clé de zone racine n'est configurée.) Pointez le curseur sur la valeur dans la colonne « Public Key » afin de voir la valeur complète.

En cas de vérification au niveau des membres :

  1. Connectez-vous dans l'interface graphique de NIOS
  2. Allez sur Data Management → DNS → Members/Servers
  3. Sélectionnez le serveur du DNS
  4. Cliquez sur « Edit »
  5. Activez « Advanced Mode »
  6. Sélectionnez « DNSSEC »
  7. Faites défiler jusqu'à « Trust Anchors »
  8. Toutes les ancres de confiance configurées apparaîtront dans le tableau « Trust Anchors ». Cherchez une entrée avec « . » dans la colonne « Zone » et une coche dans la colonne « Secure Entry Point ». (S'il n'y a pas une telle ancre de confiance, aucune clé de signature de clé de zone racine n'est configurée.) Pointez le curseur sur la valeur dans la colonne « Public Key » afin de voir la valeur complète.

Afin de distinguer l'ancienne clé de signature de clé de zone racine de la nouvelle, l'ancienne clé de signature de clé de zone racine apparaîtra de la façon suivante :

AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0Ezr
AcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf
5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMj
JPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmR
LKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

La nouvelle (actuelle) clé de signature de clé de la zone racine apparaîtra de la façon suivante :

AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOL
AJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3Eg
VLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWe
L3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555Kr
UB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."