Skip to main content
Resources

Mise à jour des résolveurs de validation du DNS selon l'ancre de confiance la plus récente

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-updating-latest-trust-anchor

Cette page est destinée aux administrateurs des résolveurs du DNS (parfois appelé « résolveurs récursifs »). L'information ici est utile si :

  • les opérateurs de ces résolveurs découvrent qu'ils n'ont pas les nouveaux KSK installés ou
  • les résolveurs donnent des erreurs pour toutes les requêtes DNS après le roulement KSK

Ces instructions mèneront probablement à utiliser l'ancre de confiance la plus récente pour validation du DNSSEC.

Il existe un document d'accompagnement qui explique comment vérifier si vous utilisez la version la plus récente de l'ancre de confiance ; vous pouvez le trouver ici. Plus d'informations sur le roulement du KSK peuvent être trouvées ici.

Pour déterminer si oui ou non le résolveur que vous opérez fait la validation du DNSSEC, vous pouvez utiliser le domaine spécial « dnssec-failed.org » qui est exploité à titre de service public par Comcast. Ce domaine spécial entraînera à dessein une absence de réponse lors de la validation des résolveurs. Saisissez la commande suivante sur une ligne de commande shell :

dig @ADDRESS dnssec-failed.org a +dnssec

Dans cette commande, remplacez la chaîneADDRESSavec l'adresse IPv4 ou IPv6 du résolveur que vous faîtes fonctionner.

Si la réponse comprend les éléments suivants :

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

Alors le résolveur effectue une validation du DNSSEC. (L'indication ici de l'état de SERVFAIL indique l'échec de validation, ce qui signifie qu'en fait la validation se produit.)

Si au contraire la réponse comprend les éléments suivants :

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

Le résolveur n'effectue pas la validation du DNSSEC.

Le reste de cette page répertorie les différentes mises en œuvre de résolveurs et les instructions nécessaires pour les mettre à jour.


BIND

Les versions 9.9, 9.10, et 9.11 de BIND soutiennent la validation du DNSSEC en utilisant la mise à jour automatique RFC 5011. Les dernières sous-versions de ces versions sont livrées avec KSK2017 dans le cadre des ancres de confiance.

Vérifiez d'abord que la validation du DNSSEC est définie dans votre fichier de configuration. Vous devriez voir une ligne dans la section options qui indique soit dnssec-validation auto; soit dnssec-validation yes;. Si vous avez dnssec-validation réglé sur auto, vous n'avez pas besoin de mettre à jour votre logiciel ou configuration. Il vous suffit de redémarrer votre logiciel, en utilisant la commande que vous utilisez normalement pour arrêter et démarrer BIND ; cela apportera les dernières ancres de confiance pour dnssec-validation auto.

Si votre configuration indique dnssec-validation yes;, vous devez la modifier sur dnssec-validation auto; et redémarrez votre serveur avant de procéder aux étapes ci-dessous.

Si vous pouvez mettre à jour votre logiciel :

  1. Mettez-la à jour à la dernière sous-version de BIND 9.9, BIND 9.10 ou BIND 9.11 à l'aide de la méthode, quelle qu'elle soit, que vous avez utilisée pour installer le logiciel. Si vous utilisez BIND 9.8, ce logiciel n'est plus pris en charge, et vous devez le mettre à jour pour BIND 9.9 ou version ultérieure. Vous voulez une sous-version d'au moins :
    • BIND 9.9.10
    • BIND 9.10.5
    • BIND 9.11.1
  2. Dans votre fichier de configuration, assurez-vous que la section options a une ligne qui dit dnssec-validation auto;.
  3. Arrêtez l'ancienne version de BIND et démarrez la nouvelle version, en utilisant la commande que vous utilisez normalement pour arrêter et démarrer BIND.

Si vous ne pouvez pas mettre à jour votre logiciel :

  1. Mettez à jour le fichier bind.keys pour inclure la nouvelle ancre de confiance. Ce fichier bind.keys doit être stocké dans le même répertoire que celui où les autres fichiers BIND sont créés. Alternativement, si votre fichier appelé .conf contient une section managed-keys répertoriant les ancres de confiance, vous pouvez mettre à jour cette section. La section configuration ou fichier révisé devrait contenir les éléments suivants :

    managed-keys { 
    . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF 
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX 
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD 
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz 
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS 
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq 
    QxA+Uk1ihz0="; 
    
    . initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv 
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e 
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd 
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN 
    R1AkUTV74bU="; 
    };
    

Si la configuration a une dnssec-validation réglée sur auto, le contenu du fichier bind.keys sera être combiné avec le le contenu du bloc managed-keys dans la configuration. Plus d'informations sur ceci peuvent être trouvées sur : https://www.isc.org/downloads/bind/bind-keys/.

ISC, les créateurs de BIND, ont plus d'informations sur les ancres de confiance du DNSSEC sur https://kb.isc.org/article/AA-01529/169/KSK-2010-Rollover.html.


Unbound

Toutefois, toutes les versions d'Unbound avant la 1.6.5 ont une limite qui les empêche d'accepter la nouvelle ancre de confiance si la version a démarré pour la première fois 30 jours ou plus avant le roulement.

Si vous utilisez la version 1.6.5 ou ultérieure d'Unbound :

  1. Supprimez les ancres de confiance actuelles avec :

    rm root.key
  2. Obtenez la dernière version des ancres de confiance avec :

    unbound-anchor
  3. Redémarrez Unbound afin qu'il recharge la nouvelle configuration, en utilisant la commande que vous utilisez normalement pour démarrer Unbound.

Si vous utilisez la version 1.6.4 ou précédente d'Unbound, et pouvez mettre à jour votre logiciel :

  1. Mettez à jour pour la version 1.6.5 ou ultérieure d'Unbound.

  2. Supprimez les ancres de confiance actuelles avec :

    rm root.key
  3. Obtenez la dernière version des ancres de confiance avec :

    unbound-anchor
  4. Redémarrez la nouvelle version d'Unbound afin qu'il recharge la nouvelle configuration, en utilisant la commande que vous utilisez normalement pour démarrer Unbound.

Si vous utilisez la version 1.6.4 ou précédente d'Unbound, et que l'une des clés dans le fichier root.key n'est pas répertoriée comme [ VALID ], et que vous ne pouvez pas mettre à jour votre logiciel :

  1. Voir la page https://www.unbound.net/root-11sep-11oct.html pour plus d'informations sur la façon d'obtenir un nouveau fichier root.key de NLnet Labs avec les deux clés sur [ VALID ].
  2. Redémarrez Unbound afin qu'il recharge la nouvelle configuration, en utilisant la commande que vous utilisez normalement pour démarrer Unbound.

PowerDNS Recursor

PowerDNS Recursor version 4 prend en charge la validation du DNSSEC, mais ne prend pas encore en charge la validation du DNSSEC en utilisant la mise à jour automatique RFC 5011. Cela signifie que pour PowerDNS Recursor, vous devez obtenir un nouvel ensemble d'ancres de confiance chaque fois que celles-ci changent. Les versions 4.0.5 et ultérieures de PowerDNS Recursor sont livrées avec KSK2017 dans le cadre des ancres de confiance installées.

Si vous pouvez mettre à jour votre logiciel :

  1. Mettez à jour à la dernière sous-version de PowerDNS Recursor à l'aide de la méthode, quelle qu'elle soit, que vous avez utilisée pour installer le logiciel. Assurez-vous d'avoir récupéré la version 4.0.5 ou ultérieure.
  2. Quittez la version actuelle de PowerDNS Recurso et démarrez la nouvelle, en utilisant la méthode, quelle qu'elle soit, que vous utilisez normalement pour arrêter et démarrer le serveur.

Si vous ne pouvez pas mettre à jour votre logiciel :

  1. Si vous ne disposez pas déjà d'une ligne lua-config-file dans votre configuration principale PowerDNS, vous devez l'ajouter. La ligne indique un fichier qui contient une configuration PowerDNS supplémentaire. Elle peut être sous la forme :

    lua-config-file=/etc/pdns/luaconf.txt
  2. Dans le fichier indiqué par la ligne lua-config-file, ajoutez les deux lignes suivantes :

    addDS('.', "19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5")
    addDS('.', "20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D")
    
  3. Redémarrez PowerDNS Recursor, en utilisant la méthode, quelle qu'elle soit, que vous utilisez normalement pour arrêter et démarrer le serveur..


Knot Resolver

Knot Resolver prend en charge la validation du DNSSEC en utilisant la mise à jour automatique RFC 5011 dans toutes les versions. Pour obtenir la dernière version des ancres de confiance, vous pouvez supprimer votre version actuelle du fichier avec les clés et redémarrer knot Resolver. Par conséquent, vous n'avez pas besoin de mettre à jour votre version de Knot Resolver ; vous n'avez qu'à obtenir les dernières ancres de confiance et redémarrer le Knot Resolver.

  1. Dans le fichier de configuration, assurez-vous qu'il y a une ligne qui dit :

    trust_anchors.file = 'root.keys'
  2. Si ce fichier ne contient pas de ligne comprenant 19036et20326, arrêtez le serveur en utilisant la méthode, quelle qu'elle soit, que vous utilisez normalement, supprimez le fichier root.keys, puis redémarrez le serveur. Ceci permettra à Knot Resolver de recréer le fichier avec les dernières ancres de confiance auprès de l'IANA.


Windows Server 2012R2 et 2016

Windows Server, tant 2012R2 que 2016, prend en charge la validation du DNSSEC avec RFC 5011 automatique. Pour obtenir la dernière version des ancres de confiance, vous pouvez mettre à jour votre version actuelle du fichier et redémarrez Windows Server. Les commandes ci-dessous utilisent Windows PowerShell.

Les ancres de confiance se mettent à jour normalement automatiquement. Pour vérifier la durée d'actualisation d'une ancre de confiance, utilisez :

Get-DnsServerTrustPoint

Il s'affichera :

TrustPointName   TrustPointState   LastActiveRefreshTime   NextActiveRefreshTime
--------------   ---------------   ---------------------   ---------------------
.                Active            9/11/2017 7:45:03 PM    9/12/2017 7:45:03 PM

Les durées indiquées sont au format UTC. Si l'ancre de confiance ne se réactualise correctement, vous pouvez la remplacer par :

Add-DnsServerTrustAnchor -Root

Après avoir ajouté l'ancre de confiance, vous devriez voir un LastActiveRefreshTime mis à jour dans le résultat de la commande Get-DnsServerTrustPoint.

Remarque : Si Add-DnsServerTrustAnchor -Root échoue, assurez-vous que le protocole DNSSEC est activé sur le serveur. Utilisez les trois commandes :

$a = Get-DnsServerSetting -All 
$a.EnableDnsSec = 1 
$a | Set-DnsServerSetting

Vous pouvez vérifier que RootTrustAnchorsURL indique https://data.iana.org/root-anchors/root-anchors.xml avec la commande :

(Get-DnsServerSetting -All).RootTrustAnchorsURL

Si la commande Add-DnsServerTrustAnchor -Root ne fonctionne toujours pas, alors un pare-feu peut bloquer le transport. Cela peut se produire dans certains environnements hautement sécurisés. Pour ajouter l'ancre de confiance DS manuellement, vous devez savoir le digest, algorithme, et keytag. Pour ajouter une ancre de confiance DNSKEY, vous avez besoin de la DNSKEY publique (base64data). Vous pouvez également importer l'ancre de confiance si vous avez accès au fichier keyset (pour une ancre DNSKEY) ou DSSET (pour une ancre DS). Le digest, algorithme (de type digest) et keytag pour l'ancre de confiance de la racine peut être consulté sur https://data.iana.org/root-anchors/root-anchors.xml.

Les commandes suivantes montrent un ajout manuel d'une ancre de confiance DS pour la zone racine.

Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 -DigestType SHA256 -KeyTag 19036 -ComputerName localhost -PassThru

Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D -DigestType SHA256 -KeyTag 20326 -ComputerName localhost -PassThru

Il n'est pas nécessaire de redémarrer le service DNS après la mise à jour des ancres de confiance. Cependant, vous pouvez souhaiter effacer le cache du serveur DNS avec la commande :

Clear-DnsServerCache -Force

Plus d'informations de Microsoft peuvent être trouvées sur https://technet.microsoft.com/en-us/itpro/powershell/windows/dnsserver/add-dnsservertrustanchor.


Akamai DNSi Cacheserve

Akamai Cacheserve (versions supérieure ou égale à 7.1.2.3, 7.2.0.3, 7.2.1.2) prend en charge la validation du DNSSEC à l'aide des clés gérées RFC5011. Bien que la possibilité existe également dans les anciennes versions, elle ne doit pas être utilisée parce qu'il y a un problème avec le code de roulement.

Si vous pouvez mettre à jour votre logiciel :

  1. Le moyen le plus facile pour obtenir la dernière clé de la zone racine du DNSSEC est d'utiliser les clés gérées et mettre à jour la version Akamai DNSi Cacheserve :

    • 7.1.2.3
    • 7.2.0.3
    • 7.2.1.2

    Ou une version ultérieure sur les trains respectifs, qui comprennent déjà une nouvelle clé racine en fonctionnement.

Si vous ne pouvez pas mettre à jour votre logiciel :

  1. Regardez les informations sur https://support.nominum.com/view-article/965 ou contactez Akamai à https://support.nominum.com/.

Infoblox NIOS

Infobox NIOS prend en charge la validation du DNSSEC, mais ne prend pas encore en charge la validation du DNSSEC par la mise à jour automatique RFC 5011. Cela signifie que pour Infoblox NIOS, vous devez configurer un nouvel ensemble d'ancres de confiance pour chaque changement d'ancres de confiance.

Les étapes pour ajouter la nouvelle clé de signature de la clé de la zone racine comme ancre de confiance dans NIOS sont :

  1. Connectez-vous à l'interface NIOS GUI
  2. Naviguez jusqu'à : gestion des données → DNS
  3. Cliquez sur « Grid DNS Properties » à partir de la barre d'outils
  4. Basculez en « Mode Avancé »
  5. Sélectionnez l'onglet « DNSSEC »
  6. Faites défiler jusqu'aux « Ancres de confiance »
  7. Cliquez sur le bouton « Ajouter » et entrez les détails de la clé. La zone est « . » et l'algorithme « RSA/SHA-256(8) ».
  8. Collez la clé dans la colonne « clé publique ». La clé publique est :
    AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv 
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e 
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd 
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN 
    R1AkUTV74bU=
    

Si l'ajout se fait au niveau du membre :

  1. Connectez-vous à l'interface NIOS GUI
  2. Naviguez jusqu'à : gestion des données → DNS → Membres/serveurs
  3. Sélectionnez le serveur DNS
  4. Cliquez sur « Edit » (Modifier)
  5. Basculez en « Mode Avancé »
  6. Sélectionnez « DNSSEC »
  7. Faites défiler jusqu'aux « Ancres de confiance »
  8. Cliquez sur le bouton « Ajouter » et entrez les détails de la clé. La zone est « . » et l'algorithme « RSA/SHA-256(8) ».
  9. Collez la clé dans la colonne « clé publique ». La clé publique est :
    AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv 
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e 
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd 
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN 
    R1AkUTV74bU=
    
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."