Lors d’une banale conversation DNS et DNSSEC, je m’aperçois que le sujet n’est pas forcément très clair pour tout le monde.
Il en est de même pour le mécanisme de résolution et des flux. Simple ressenti.
Je vais donc essayer de prendre un peu de temps pour reposer tranquillement chaque brique, car il n’y a rien de pire que partir dans tous les sens et de finir sur un ensemble d’approximation.
L’idée est de faire la part des choses entre DNSSEC et la cryptographie (PKI, DoH et DoT).
Ainsi, je vous propose d’explorer les quelques points importants autour du DNSSEC, dans un environnement Microsoft Windows à titre d’exemple.
Définition du DNSSEC
Il s’agit d’une extension DNS relative à la sécurité, donc DNSSEC est intrinsèquement lié au DNS lui-même. Le principe consiste à signer numériquement les zones afin d’éviter les attaques classiques de type MITM, DNS Spooofing, Cache Poisoning.
Cette signature DNSSEC est clairement une partie des concepts cryptographiques, toutefois son fonctionnement est un peu différent de celle de la PKI. C’est un point d’attention important.
Autrement, le protocole DNSSEC ne chiffre pas les transactions entre les clients et le serveur DNS. Le travail de cryptage se fait avec les protocoles DoH (DNS over HTTPS, 443/tcp) ou DoT (DNS over TLS, 853/tcp). DNSSEC permet d’attester l’origine des enregistrements avec toujours l’objectif d’éviter les mêmes attaques.
Enfin, DNSSEC est défini à travers un standard quant à son implémentation. Les références sont les RFC 4033, RFC 4034, RFC 4035 et quelque part le RFC 5011 aussi. Ceci signifie que DNSSEC peut être mis en œuvre sur différentes technologies DNS.
Rappel DNS
Les serveurs DNS offrent des services d’annuaire qui opèrent dans l’ombre (c’est peut-être la raison pour laquelle ils sont souvent négligés 🤔😲 ). Bref, ils interprètent et répondent inlassablement aux demandes de résolution (nom, IP, service et cætera).
Une demande commence toujours par une requête adressée à un résolveur récursif DNS.
Elle est transmise aux serveurs de noms racine (DNS Root) et puis au serveur de nom du premier niveau (TLD). Tel est le cas si aucun serveur DNS n’y répond localement (sous-entendu cache DNS ou serveur DNS faisant autorité sur la zone demandée).
Le serveur DNS faisant autorité est la destination finale de la requête relative à la demande initiale.
Chaque étape intercalaire est donc cruciale, d’où la nécessité d’une bonne identification via un DNSSEC de chaque acteur.
Points remarquables
L’onglet DNSSEC dans la propriété du serveur DNS n’est plus visible depuis Windows Server 2016.
La fonctionnalité DNSSEC est activée by design, toutefois les zones ne sont pas pour autant signées. La signature d’une zone nécessite une action explicite de configuration (cf. tuto rapide un peu plus bas).
Afin de vérifier si le paramètre DNSSEC est activé ou non, vous pouvez lancer la commande PowerShell suivante : (Get-DnsServerSetting).EnableDnsSec
Pour éviter toute forme d’usurpation, la signature DNSSEC est forgée depuis un serveur DNS d’une zone faisant autorité sur le domaine DNS. En conséquence, la signature est initiée depuis un seul et unique NS.
Dans un environnent DNSADI, seul un DNS signe la zone. La réplication de la zone avec DNSSEC reste inchangée entre les différents contrôleurs de domaine (à travers la forêt). La gestion des enregistrements demeure multi-maîtres, toutefois la gestion DNSSEC est mono-maître.
Les DNS portant les jeux de clés DSSET et KEYSET se manipule localement.
Configuration du DNSSEC
Afin de procéder à la configuration de DNSSEC d’une zone, il faut sélectionner la zone en question avec le menu contextuel avec un clic droit, puis DNSSEC et enfin « Sign the zone ».
L’assistant DNSSEC (DNS Security Extension) s’ouvrira, il n’y aura plis qu’à suivre le mode wizard (en quinze étapes) comme suit :
Next > « Customize zone signing parameters » > « The DNS server %dns-server% is the key master » > Next > Next > Add > OK > Next > Next > « Enable the distribution of trust anchors for this zone » et « Enable automatic update of trust anchors key rollover (RFC 5011) » > Next > Next.
Le résumé de la configuration s’affiche et il faut un dernière fois cliquer sur Next et enfin Finish
Ces 15 étapes peuvent être simplifiées avec la cmdlet PowerShell suivante : Set-Dns
En vérifiant la zone (après idéalement un rafraichissement de la console DNS), plusieurs enregistrements s’y sont ajoutés (RRSIG, DNSKEY et NSEC3).
Afin de vérifier si la signature est effective et correcte, il est possible d’exécuter la commande PowerShell suivante : Resolve-DnsName %zone% -Server %dns-server% -DnsSecOk
Gestion des clés DNSSEC dans Windows
Chaque zone avec DNSSEC dispose donc a minima une clé privée et une clé publique.
La clé publique est celle publiée à travers la zone DNS et qui signe chaque entrée de ladite zone.
Quant à la clé privée, elle est à conserver idéalement hors-ligne, la façon la plus sécurisée quoi qu’il en soit.
Il s’agit des fichiers DSSET (ou RRSET, une autre désignation) et KEYSET localisés dans le dossier %windir%\system32\dns 🤔.
Cette mise en sécurité peut se faire à l’aide d’une extraction selon la commande PowerShell ci-après : Export-DnsServerDnsSecPublicKey -ComputerName %dns-server% -ZoneName %zone% -Path %your-unc-path%.
Les fichiers originaux doivent être inchangés et intacts.
Client DNSSEC
Le client DNS comprend à la fois naturellement le DNS et le DNSSEC.
Aussi, il convient donc de paramétrer ce dernier pour n’accepter que le DNSSEC dans le but d’accroitre le niveau de sécurité.
Dans un environnement Microsoft, une pareille configuration reste tout à réalisable sans difficulté à l’aide d’une GPo dans un environnement Active Directory.
Le paramétrage est faisable au niveau de Computer Configuration > Windows Settings > Name Resolution Policy
Validation des signatures DNSSEC
En fonction des situations, le DNSSEC peut ajouter l’un des enregistrements DNS suivants pour la validation des signatures :
- RSSIG : contient une signature DNSSEC cryptographique pour un ensemble d’enregistrements
- DNSKEY : contient une clé de signature publique
- DS : contient le hash d’un enregistrement DNSKEY
- NSEC et NSEC3 : propose un lien vers le nom d’enregistrement suivant dans la zone et énumère également les types d’enregistrements dans le but de prouver la non-existence d’un enregistrement
- CDNSKEY et CDS : transmet l’état DS sollicité depuis la zone enfant vers la zone parente et demande des mises à jour des enregistrements DS dans la zone parente.
Conclusion
Le DNSSEC est à mettre en œuvre afin de former une contre-mesure vis-àvis des attaques DNS (MITM, spoofing et poisoning).
Il est facile à mettre en place, par conséquent, il ne faut pas s’en priver.
Il permet de fournir une première couche basée sur la cryptographie à clé publique dans le but de bien protéger les zones.
Enfin, pour parfaire le niveau de sécurité du DNSSEC, il convient de coffrer les paires de clés ZSK et KSK dans un HSM. En effet, ces clés/fichiers ne sont pas chiffré(e)s à la base.