NIS2 et DNS — Ce que les operateurs UE regules doivent savoir

La directive NIS2 (directive (UE) 2022/2555) est la reglementation phare de l'UE en matiere de cybersecurite. Elle elargit et durcit la directive NIS originale, releve les exigences minimales en cybersecurite a travers l'Union, et fait entrer des dizaines de milliers de nouvelles entites dans son perimetre. Pour quiconque exploite DNS dans ou pour l'UE, NIS2 n'est plus optionnelle — c'est le plancher legal.

Ce guide couvre ce que NIS2 signifie specifiquement pour le DNS : quelles entites sont dans le perimetre, a quoi ressemblent les mesures de gestion des risques de l'article 21 dans les operations DNS, les delais de notification d'incidents qu'un fournisseur DNS doit respecter, et une liste de controle cote acheteur pour evaluer si votre fournisseur DNS est pret pour NIS2.

Qu'est-ce que NIS2 et pourquoi existe-t-elle

NIS2 a ete adoptee en decembre 2022 et les Etats membres avaient jusqu'au 17 octobre 2024 pour la transposer dans leur droit national. Elle remplace la directive NIS de 2016 (NIS1), largement critiquee pour une application incoherente, une couverture sectorielle etroite et des pouvoirs de supervision faibles.

L'objectif declare de la directive est d'etablir un niveau commun eleve de cybersecurite a travers l'Union. Elle le fait en :

1. Elargissant la liste des secteurs couverts, dont infrastructure numerique, administration publique, production alimentaire et gestion des dechets.
2. Abaissant les seuils de taille — la plupart des organisations de taille moyenne (>=50 employes ou >=10 M EUR) sont maintenant dans le perimetre.
3. Imposant deux niveaux de supervision : entites essentielles (supervision proactive, obligations les plus elevees) et entites importantes (supervision reactive, exigences un peu allegees).
4. Relevant les amendes : jusqu'a 10 M EUR ou 2 % du chiffre d'affaires annuel mondial pour les entites essentielles, 7 M EUR ou 1,4 % pour les entites importantes.
5. Introduisant la responsabilite personnelle des organes de direction qui n'honorent pas leurs obligations de cybersecurite.
6. Harmonisant les delais et le contenu de notification d'incidents a travers l'UE.

Si votre organisation est dans le perimetre, NIS2 n'est pas un regime de conformite souple. Les regulateurs nationaux (BSI en Allemagne, ANSSI en France, NCSC-NL aux Pays-Bas, etc.) ont desormais des pouvoirs explicites d'inspection, d'audit et de sanction.

Ou se situe le DNS dans NIS2

L'annexe I de NIS2 liste les secteurs hautement critiques. Sous l'intitule "infrastructure numerique", les acteurs suivants sont nommes explicitement comme entites essentielles :

• Fournisseurs de points d'echange Internet
• Fournisseurs de services DNS (a l'exclusion des operateurs de serveurs racine)
• Registres de noms de TLD
• Fournisseurs de services d'informatique en nuage
• Fournisseurs de services de centres de donnees
• Fournisseurs de reseaux de diffusion de contenu
• Prestataires de services de confiance (eIDAS)
• Fournisseurs de reseaux de communications electroniques publics
• Fournisseurs de services de communications electroniques accessibles au public

L'expression "fournisseurs de services DNS" est large. Elle couvre les fournisseurs DNS autoritaires (entites qui repondent aux requetes sur une zone — DNScale, Cloudflare DNS, Route 53, ClouDNS, DNS Made Easy, Dyn, etc.), les operateurs de resolveurs recursifs publics (Quad9, OpenDNS, Cloudflare 1.1.1.1, Google Public DNS), et les fournisseurs de services DNS d'entreprise / manages. Le DNS interne / prive utilise par une seule organisation n'est generalement pas dans le perimetre en tant que service, bien qu'il puisse l'etre dans le cadre de l'infrastructure plus large de cette organisation.

Les Etats membres peuvent etendre la liste — l'avant-projet allemand NIS2UmsuCG, par exemple, traite certains hebergeurs de maniere plus large que le minimum directif UE.

Article 21 — Les mesures de gestion des risques

L'article 21 est le coeur operationnel de NIS2. Il oblige les entites essentielles et importantes a prendre des "mesures techniques, operationnelles et organisationnelles appropriees et proportionnees" pour gerer les risques de cybersecurite. La directive liste 10 categories de mesures :

1. Analyse des risques et politiques de securite des systemes d'information
2. Gestion des incidents
3. Continuite des operations, dont gestion des sauvegardes et reprise
4. Securite de la chaine d'approvisionnement, dont securite des relations avec les fournisseurs et prestataires directs
5. Securite dans l'acquisition, le developpement et la maintenance des systemes de reseau et d'information, dont gestion et divulgation des vulnerabilites
6. Procedures pour evaluer l'efficacite des mesures de gestion des risques de cybersecurite
7. Pratiques d'hygiene cyber de base et formation a la cybersecurite
8. Politiques et procedures concernant l'usage de la cryptographie et, le cas echeant, du chiffrement
9. Securite des ressources humaines, politiques de controle d'acces et gestion des actifs
10. Usage de l'authentification multi-facteurs ou de solutions d'authentification continue, communications voix/video/texte securisees et systemes de communications d'urgence securises

Pour le DNS specifiquement, cela se traduit en exigences operationnelles concretes :

1. Gestion d'incidents pour pannes et compromissions DNS

Un fournisseur DNS doit avoir des procedures ecrites pour repondre a :

• Pannes autoritaires dans un PoP, une region ou globalement
• Attaques DDoS contre le reseau anycast
• Compromission des donnees de zone (modification non autorisee des enregistrements client)
• Compromission des cles DNSSEC (exposition de cle privee KSK ou ZSK)
• Compromission de comptes operateurs pouvant entrainer des changements d'enregistrements

Les procedures doivent inclure detection, confinement, eradication, retablissement et analyse post-incident. Elles doivent etre testees. Les clients doivent pouvoir attendre un contact securite, un runbook de reponse aux incidents, et un RTO/RPO publie pour le service DNS.

2. Cryptographie le cas echeant

DNSSEC est le controle cryptographique le plus directement pertinent pour le DNS. Au titre de l'article 21(2)(h), un fournisseur DNS qui n'offre pas du tout DNSSEC risque d'etre juge non conforme pour les clients hautement critiques. Fonctionnalites DNSSEC attendues en 2026 :

• Prise en charge d'algorithmes : ECDSA P-256 (algorithme 13) ou Ed25519 (algorithme 15) — RSA-SHA256 (algorithme 8) acceptable mais considere comme heritage.
• Rotation automatisee des cles (KSK et ZSK) sans interruption client.
• Stockage securise des cles — adosse a un HSM ou equivalent.
• Reporting public du DS via API pour automatisation aupres du registrar.

Pour les donnees en transit entre interfaces operateurs et clients, TLS 1.2+ avec suites de chiffrement modernes est le minimum.

3. Securite de la chaine d'approvisionnement — Article 21(2)(d)

Cette disposition fait que NIS2 atteint aussi les clients des fournisseurs DNS. L'article 21(2)(d) oblige chaque entite dans le perimetre a gerer la securite des relations avec les fournisseurs directs. Si votre fournisseur DNS a un incident de securite qui vous touche, les regulateurs attendront que vous ayez fait votre diligence en amont.

Concretement, cela signifie :

• Documentez les fournisseurs de votre chaine DNS (registrar, hote DNS primaire, hote DNS secondaire, resolveur recursif manage le cas echeant).
• Obtenez la preuve de leur posture de securite (certifications, rapports d'audit, politique de securite publique).
• Etablissez des SLA contractuels pour la notification d'incidents et la recuperation.
• Reevaluez selon une cadence documentee (annuelle au minimum).

4. Authentification multi-facteurs

L'article 21(2)(j) exige le MFA pour les interfaces de gestion. Pour le DNS cela signifie :

• MFA sur le tableau de bord client du fournisseur DNS.
• MFA chez le registrar ou les enregistrements NS sont geres (securite de la delegation).
• Gestion des cles d'API avec autorisations restreintes et politique de rotation.
• Pas d'identifiants partages a longue duree de vie ; les comptes de service doivent etre auditables.

5. Continuite des operations et sauvegarde

Continuite specifique au DNS :

• Anycast multi-region pour qu'une panne regionale unique ne mette pas une zone hors ligne.
• DNS multi-fournisseurs pour les zones du palier le plus eleve — voir /learning/multi-provider-dns-deployment.
• Sauvegardes des donnees de zone restorables rapidement chez un autre fournisseur.
• Procedures de retablissement testees avec RTO/RPO documentes.

Article 23 — Delais de notification d'incidents

L'article 23 fixe le calendrier de notification que les fournisseurs DNS doivent respecter. Un "incident important" est un incident qui :

• A cause ou est susceptible de causer une perturbation operationnelle substantielle des services ou une perte financiere
• A affecte ou est susceptible d'affecter d'autres personnes physiques ou morales en causant un dommage materiel ou immateriel considerable

Pour le DNS, cela inclut les pannes autoritaires prolongees, les echecs de validation DNSSEC dus a une erreur du fournisseur, les changements non autorises aux donnees de zone client, ou la compromission des cles privees DNSSEC.

Cadence de notification :

Ces delais s'appliquent au fournisseur DNS en tant qu'entite dans le perimetre. Les clients peuvent avoir des obligations de notification distinctes envers leurs propres regulateurs si l'incident DNS a un impact en aval dans leur propre secteur.

Le delai de 24 heures est court. Un fournisseur DNS doit avoir monitoring, alerting et un declarant designe prets a remonter au CSIRT national ou a l'autorite competente. Ce n'est pas un exercice trimestriel.

Ce que cela signifie pour les clients DNS — une liste de controle pratique

Si votre organisation est dans le perimetre de NIS2 (ou est fournisseur d'une entite couverte), voici une liste de controle pratique pour evaluer votre fournisseur DNS :

Diligence fournisseur

• Le fournisseur est nomme / dispose a confirmer par ecrit s'il est dans le perimetre comme fournisseur de services DNS au titre de NIS2.
• Juridiction principale du fournisseur et autorite competente qui le supervise.
• Posture de securite publique : security.txt, politique de divulgation de vulnerabilites et statut publie pour les signalements de securite chiffres.
• Rapports post-incident publics pour les incidents importants precedents (le cas echeant).
• Procedure documentee de reponse aux incidents et SLA de notification dans votre contrat.

Controles techniques

• Prise en charge DNSSEC avec algorithmes modernes (ECDSA P-256 ou Ed25519).
• Stockage securise des cles adosse a un HSM ou equivalent.
• MFA sur le tableau de bord client.
• Cles d'API granulaires (limitees a la zone, a duree limitee, rotables) — voir /learning/multi-user-accounts.
• Anycast multi-region — voir /learning/anycast-dns-network.
• Journal d'audit de toutes les actions tableau de bord et API, conservees selon votre politique de retention.

Resilience

• RTO/RPO documentes pour le service autoritaire.
• Mecanisme d'export des donnees de zone a la demande pour la portabilite.
• Disponibilite multi-fournisseurs (prise en charge Terraform / DNSControl) — voir /learning/multi-provider-dns-deployment.

Considerations specifiques UE

• Le fournisseur exploite une infrastructure sous juridiction UE si votre secteur exige la residence des donnees.
• Le trafic de requetes DNS peut etre confine aux PoPs UE (par ex. le set de noms de serveur UE de DNScale — voir /learning/dns-delegation-by-region).
• Contrats sous droit de l'UE et resolution des litiges UE.

Ou se situe DNScale

DNScale opere comme fournisseur DNS sous juridiction UE avec un modele d'exploitation conscient de NIS2 :

• Operations UE : infrastructure et operations en UE ; le trafic de requetes peut etre confine aux PoPs UE via le set de noms de serveur UE.
• DNSSEC : ECDSA P-256 par defaut ; rotation automatisee des cles ; stockage adosse a un HSM.
• MFA + cles d'API restreintes : MFA tableau de bord, cles limitees a la zone, journal d'audit complet — voir /learning/multi-factor-authentication-guide et la documentation des cles d'API DNScale.
• Anycast multi-region via /learning/anycast-dns-network et /learning/global-dns-resolution-balancing pour la resilience.
• Pret pour multi-fournisseurs : les providers Terraform et DNSControl sont disponibles aujourd'hui — voir /learning/terraform-provider-guide et /learning/dnscontrol-guide.
• Artefacts de securite publics : security.txt et politique de divulgation de vulnerabilites a l'emplacement standard ; rapports post-incident publies en cas d'incident.

Pour les secteurs ou l'application de NIS2 est la plus active — finance, energie, administration publique, sante — basculer la fourniture DNS vers un fournisseur sous juridiction UE avec controles alignes NIS2 reduit a la fois le risque reglementaire et la charge documentaire de la chaine d'approvisionnement au titre de l'article 21(2)(d).

References

• Directive (UE) 2022/2555 — la directive NIS2
• Guidance ENISA sur la mise en oeuvre de NIS2 — ressources pratiques pour les entites couvertes
• Avant-projet BSI NIS2UmsuCG — transposition allemande
• Guide ANSSI NIS 2 — transposition francaise
• RFC 8945 — TSIG (authentification de transferts de zone, pertinente pour les mesures de cryptographie)
• RFC 4034/4035 — protocole noyau DNSSEC
• RFC 8901 — DNSSEC multi-signataires (pertinent pour deploiements multi-fournisseurs)

Lectures complementaires

• Bonnes pratiques de securite DNS — durcissement operationnel
• Gestion des cles DNSSEC — cryptographie en pratique
• Deploiement DNS multi-fournisseurs — resilience de la chaine d'approvisionnement
• DNScale vs Cloudflare — comparaison sous juridiction UE
• Meilleurs fournisseurs DNS UE — cadre d'evaluation
• Fournisseurs DNS conformes RGPD — cadre reglementaire adjacent