L’Union europ\u00e9enne \u00e9labore actuellement sa deuxi\u00e8me directive sur la s\u00e9curit\u00e9 des r\u00e9seaux et de l’information (NIS2) et je suis pr\u00e9occup\u00e9 par le langage utilis\u00e9 pour d\u00e9crire le syst\u00e8me de noms de domaine (DNS) ainsi que par les effets n\u00e9gatifs que la l\u00e9gislation aura sur la s\u00e9curit\u00e9 et la r\u00e9silience du DNS.<\/p>\n\n\n\n
\u00c0 l’heure actuelle, trois projets diff\u00e9rents de NIS2 sont en circulation. Le Parlement europ\u00e9en vient d’approuver un projet qui sera ensuite compar\u00e9 aux versions \u00e9labor\u00e9es par le Conseil europ\u00e9en (\u00c9tats membres de l’Union europ\u00e9enne) et la Commission europ\u00e9enne (branche ex\u00e9cutive de l’UE \u00e0 Bruxelles) en vue d’\u00eatre n\u00e9goci\u00e9 jusqu’\u00e0 ce que les parties s’accordent sur un texte unique.<\/p>\n\n\n\n
Nous avons d\u00e9j\u00e0 parl\u00e9 du NIS2<\/a>. J’aimerais maintenant que l’on se concentre sur le projet du Conseil europ\u00e9en et sur un aspect sp\u00e9cifique du DNS, pour montrer \u00e0 quel point la r\u00e9alit\u00e9 technique diff\u00e8re de l’intention r\u00e9glementaire.<\/p>\n\n\n\n L’objectif du NIS2 est de s’assurer que l’infrastructure sur laquelle l’Europe s’appuie pour son activit\u00e9 \u00e9conomique est s\u00fbre et fiable. C’est un objectif louable. \u00c0 vrai dire, l’Internet Society estime que toute infrastructure Internet sur laquelle les gens doivent compter pour leur activit\u00e9 sociale et \u00e9conomique se doit d’\u00eatre s\u00fbre et digne de confiance, quel que soit l’endroit o\u00f9 ils vivent.<\/p>\n\n\n\n Afin d’atteindre cet objectif de s\u00e9curit\u00e9, le NIS2 veut r\u00e9glementer le syst\u00e8me des noms de domaine (DNS). Le consid\u00e9rant 15 de la version du Conseil europ\u00e9en du projet NIS2 se lit d\u00e9sormais comme suit :<\/p>\n\n\n\n \u201cTherefore, this Directive should apply to all providers of DNS services along the DNS provisioning and<\/strong> resolution chain that are of importance for the internal market<\/strong>, (Ce passage est tir\u00e9 du document 12019\/2\/21 Rev2 d.d. du 25 octobre 2021, qui n’est pas accessible au public, les textes barr\u00e9s et les caract\u00e8res gras indiquant les modifications r\u00e9centes apport\u00e9es au projet de texte).<\/p>\n\n\n\n L’annexe de la version du Conseil se lit d\u00e9sormais comme suit : \u00ab\u00a0Les fournisseurs de services DNS, notamment les op\u00e9rateurs de serveurs de noms racine ayant une empreinte significative dans l’UE (plus de 10 sites dans l’UE).\u00a0\u00bb<\/p>\n\n\n\n Si nous examinons ce langage \u00e0 travers le prisme des piliers de s\u00e9curit\u00e9 de l’infrastructure des serveurs DNS, le langage du Conseil n’ajoute aucune mesure de s\u00e9curit\u00e9 ni fiabilit\u00e9. Ci-dessous, nous examinons d’abord l’int\u00e9grit\u00e9 et l’authenticit\u00e9, puis la disponibilit\u00e9 [1]<\/a>.<\/p>\n\n\n\n Au sujet de la s\u00e9curit\u00e9 et la fiabilit\u00e9, nous devons d’abord consid\u00e9rer la question de l’int\u00e9grit\u00e9 des informations fournies par le DNS. Les informations sur un domaine que l’utilisateur re\u00e7oit d’un r\u00e9solveur DNS sont-elles les informations correctes et pr\u00e9cises que l’op\u00e9rateur du domaine a introduites dans le DNS ? L’int\u00e9grit\u00e9 est garantie par les extensions de s\u00e9curit\u00e9 du DNS (DNSSEC). Avec DNSSEC, les informations fournies ont \u00e9t\u00e9 sign\u00e9es cryptographiquement par l’\u00e9diteur de l’information. Quel que soit le mode de r\u00e9ception de ces informations, les utilisateurs peuvent v\u00e9rifier de mani\u00e8re cryptographique que les r\u00e9ponses sont exactement les m\u00eames que celles publi\u00e9es par le propri\u00e9taire du domaine. Peu importe l’endroit o\u00f9 se trouve le serveur de noms, ou m\u00eame son degr\u00e9 de s\u00e9curit\u00e9, les informations sont sign\u00e9es et ne peuvent donc pas \u00eatre modifi\u00e9es. L’int\u00e9grit\u00e9 est donc pr\u00e9serv\u00e9e. Gr\u00e2ce aux propri\u00e9t\u00e9s cryptographiques des signatures, nous savons quelle entit\u00e9 a publi\u00e9 une information DNS particuli\u00e8re, ce qui garantit \u00e9galement l’authenticit\u00e9.<\/p>\n\n\n\n Ind\u00e9pendamment de la taille de l'\u00a0\u00bbempreinte\u00a0\u00bb, le fait d’avoir plus ou moins de serveurs de noms n’a pas d’impact sur l’authenticit\u00e9 et l’int\u00e9grit\u00e9 des informations DNS. Le fait d’avoir des DNSSEC en a. Heureusement, l’\u00e9tat du d\u00e9ploiement des DNSSEC au niveau national dans l’UE est assez avanc\u00e9 (voir ici nos cartes de d\u00e9ploiement<\/a>).<\/p>\n\n\n\n En ce qui concerne l’int\u00e9grit\u00e9 et l’authenticit\u00e9 du DNS, les dispositions de NIS2 concernant les serveurs de noms ne feront aucune diff\u00e9rence. <\/strong>Elles peuvent avoir un impact sur la fourniture des informations DNS elles-m\u00eames (par l’interm\u00e9diaire des bureaux d’enregistrement et des registres) mais pas sur la mani\u00e8re dont ces informations sont mises \u00e0 disposition sur Internet.<\/p>\n\n\n\n L’authenticit\u00e9 et l’int\u00e9grit\u00e9 n’\u00e9tant pas affect\u00e9es par les dispositions relatives aux serveurs de noms de NIS2, est-on certain que NIS2 am\u00e9liorera au moins la disponibilit\u00e9, et donc la fiabilit\u00e9 et la s\u00e9curit\u00e9 ?<\/p>\n\n\n\n Pour comprendre cela, examinons la disponibilit\u00e9 depuis la perspective de l’utilisateur. Lorsque l’utilisateur saisit un nom de domaine dans un navigateur Web, par exemple, ce nom de domaine est envoy\u00e9 \u00e0 un r\u00e9solveur r\u00e9cursif DNS local pour rechercher une adresse IP. Le r\u00e9solveur r\u00e9cursif interroge ensuite les serveurs de noms faisant autorit\u00e9, tels que les serveurs racine, pour obtenir une r\u00e9ponse au nom de l’utilisateur.<\/p>\n\n\n\n Au cours de ce processus, le r\u00e9solveur r\u00e9cursif \u00e9tablit une liste interne de toutes les adresses IP des serveurs de noms faisant autorit\u00e9 sur lesquels des informations sur un certain nom de domaine sont disponibles.<\/p>\n\n\n\n Le r\u00e9solveur r\u00e9cursif choisit ensuite au hasard<\/em> l’une des adresses IP des serveurs de noms faisant autorit\u00e9 pour demander une r\u00e9ponse. L’endroit<\/em> o\u00f9 se trouve ce serveur faisant autorit\u00e9 n’a aucune importance pour le r\u00e9solveur r\u00e9cursif. Au moins une impl\u00e9mentation courante des r\u00e9solveurs r\u00e9cursifs ne se soucie pas de savoir sur quel continent ou dans quelle r\u00e9gion \u00e9conomique se trouve l’adresse IP, elle choisit au hasard dans le monde entier[2]<\/a>.<\/p>\n\n\n\n (Soit dit en passant, la raison pour laquelle il fait cela est d’emp\u00eacher l’attaque dite de Kaminsky \u00e0 laquelle le DNS est vuln\u00e9rable en l’absence de DNSSEC, voir https:\/\/www.nlnetlabs.nl\/documentation\/unbound\/patch-announce102<\/a>\/ et https:\/\/www.nlnetlabs.nl\/documentation\/unbound\/info-timeout\/).<\/p>\n\n\n\n Pour am\u00e9liorer la r\u00e9silience, la disponibilit\u00e9 et les performances du syst\u00e8me DNS, les op\u00e9rateurs de services DNS ont largement utilis\u00e9 une technique appel\u00e9e \u00ab\u00a0anycast\u00a0\u00bb. L’id\u00e9e est que des copies exactes d’un serveur DNS, incluant son adresse IP, sont d\u00e9ploy\u00e9es \u00e0 de nombreux endroits dans l’infrastructure du r\u00e9seau. Ces serveurs sont appel\u00e9s \u00ab\u00a0instances\u00a0\u00bb (et non sites, comme dans l’annexe) et s’il existe plusieurs instances sur Internet, chacune attirera le trafic qui lui est proche en termes de topologie du r\u00e9seau. Ce sont des aimants \u00e0 trafic.<\/p>\n\n\n\n Cr\u00e9er plus d’instances d’un serveur de noms vous permet de r\u00e9aliser deux choses. Premi\u00e8rement, si la s\u00e9lection al\u00e9atoire choisit l’adresse IP du serveur de noms, le fait de disposer d’une instance proche dans la topologie du r\u00e9seau vous permettra d’obtenir une r\u00e9ponse plus rapide. Deuxi\u00e8mement, une instance attirera tout le trafic local. Ainsi, si l’IP d’un serveur de noms fait l’objet d’une attaque par d\u00e9ni de service (DOS) de grande ampleur, ces instances attireront le trafic d’attaque local, permettant aux op\u00e9rateurs de r\u00e9seau de mieux identifier les attaquants et d’y r\u00e9pondre. Un plus grand nombre d’instances signifie une plus grande capacit\u00e9 \u00e0 faire face aux attaques DOS, ce qui signifie \u00e0 son tour que les r\u00e9sultats seront moins d\u00e9bilitants. Plus le nombre d’instances est \u00e9lev\u00e9, moins les citoyens europ\u00e9ens<\/strong> sont touch\u00e9s par les attaques DOS de grande envergure.<\/p>\n\n\n\n Par cons\u00e9quent, plus il y a d’instances de serveurs de noms sur le r\u00e9seau, plus celui-ci est s\u00e9curis\u00e9. Id\u00e9alement, pour la racine, il faudrait que tous les op\u00e9rateurs d\u00e9ploient plusieurs instances de serveurs de noms sur le sol europ\u00e9en. De cette fa\u00e7on, vous pouvez \u00eatre s\u00fbr que l’algorithme al\u00e9atoire r\u00e9pondra toujours rapidement. La r\u00e9silience et les performances s’en trouvent am\u00e9lior\u00e9es.<\/p>\n\n\n\n Cependant, NIS2 incitera-t-il \u00e0 la cr\u00e9ation de plus de serveurs de noms ? En particulier des serveurs racine ?<\/p>\n\n\n\n Je ne pense pas que ce sera le cas. En fait, les op\u00e9rateurs de serveurs de noms risquent d’envisager de r\u00e9duire le nombre de serveurs de noms \u00e0 moins de 10 afin d’\u00e9chapper au champ d’application de la r\u00e9glementation. Par cons\u00e9quent, en l’\u00e9tat, la directive incite \u00e0 r\u00e9duire la r\u00e9silience et la disponibilit\u00e9.<\/strong><\/p>\n\n\n\n Plus g\u00e9n\u00e9ralement, si l’on regarde la derni\u00e8re phrase du consid\u00e9rant 15. <\/p>\n\n\n\n \u00ab\u00a0les entit\u00e9s fournissant des services d’enregistrement de noms de domaine, les op\u00e9rateurs de<\/strong> serveurs de noms faisant autorit\u00e9 pour les noms de domaine et les op\u00e9rateurs<\/strong> de r\u00e9solveurs r\u00e9cursifs.\u00a0\u00bb<\/p>\n\n\n\n Les op\u00e9rateurs de r\u00e9solveurs r\u00e9cursifs font partie de la cha\u00eene d’approvisionnement des entreprises et des fournisseurs de services Internet (ISP) qui choisissent de les utiliser. De m\u00eame, les serveurs de noms faisant autorit\u00e9 font partie d’une cha\u00eene d’approvisionnement dont le d\u00e9tenteur du domaine est responsable en dernier ressort. De m\u00eame, les serveurs de noms faisant autorit\u00e9 font partie d’une cha\u00eene d’approvisionnement dont le d\u00e9tenteur du domaine est responsable en dernier ressort. En d\u00e9finitive, ceux qui mettent \u00e0 disposition un service reposant sur un nom de domaine sont responsables de la disponibilit\u00e9 de ce service. Cette responsabilit\u00e9 se r\u00e9percute sur les contrats et cr\u00e9e ainsi une culture de la s\u00e9curit\u00e9. La responsabilit\u00e9 est garantie de bas en haut, et non de haut en bas.<\/p>\n\n\n\n Si le Conseil europ\u00e9en et la Commission europ\u00e9enne entendent pr\u00e9venir les risques d’une approche descendante de la r\u00e9glementation du DNS qui pourrait s\u00e9rieusement fragmenter l’Internet et r\u00e9duire la s\u00e9curit\u00e9 en ligne, ils devraient s’inspirer de la version du Parlement europ\u00e9en du texte NIS2, qui a exclu les serveurs de noms racine du champ d’application. En fait, il faudrait aller plus loin et exclure le syst\u00e8me de serveurs racine dans son ensemble, \u00e0 la fois en raison des arguments techniques ci-dessus, mais aussi parce qu’il est d\u00e9j\u00e0 r\u00e9gi par les meilleures pratiques dans un processus ouvert et multipartite.<\/p>\n\n\n\nthe entities providing domain name registration services, the<\/s> including operators of root name servers with a significant footprint in the EU<\/strong>, top-level-domain (TLD) name registries<\/strong> servers<\/s>, the entities providing domain name registration services,operators of<\/strong> authoritative name servers for domain names and operators of<\/strong> recursive resolvers\u201d<\/p>\n\n\n\nInt\u00e9grit\u00e9 et authenticit\u00e9<\/h2>\n\n\n\n
Disponibilit\u00e9<\/h2>\n\n\n\n
Responsabilit\u00e9<\/h2>\n\n\n\n
\n\n\n\n
![cartes de d\u00e9ploiement<\/a>).<\/p>\n\n\n\nEn ce qui concerne l’int\u00e9grit\u00e9 et l’authenticit\u00e9 du DNS, les dispositions de NIS2 concernant les serveurs de noms ne feront aucune diff\u00e9rence. <\/strong>Elles peuvent avoir un impact sur la fourniture des informations DNS elles-m\u00eames (par l’interm\u00e9diaire des bureaux d’enregistrement et des registres) mais pas sur la mani\u00e8re dont ces informations sont mises \u00e0 disposition sur Internet.<\/p>\n\n\n\nDisponibilit\u00e9<\/h2>\n\n\n\nL’authenticit\u00e9 et l’int\u00e9grit\u00e9 n’\u00e9tant pas affect\u00e9es par les dispositions relatives aux serveurs de noms de NIS2, est-on certain que NIS2 am\u00e9liorera au moins la disponibilit\u00e9, et donc la fiabilit\u00e9 et la s\u00e9curit\u00e9 ?<\/p>\n\n\n\nPour comprendre cela, examinons la disponibilit\u00e9 depuis la perspective de l’utilisateur. Lorsque l’utilisateur saisit un nom de domaine dans un navigateur Web, par exemple, ce nom de domaine est envoy\u00e9 \u00e0 un r\u00e9solveur r\u00e9cursif DNS local pour rechercher une adresse IP. Le r\u00e9solveur r\u00e9cursif interroge ensuite les serveurs de noms faisant autorit\u00e9, tels que les serveurs racine, pour obtenir une r\u00e9ponse au nom de l’utilisateur.<\/p>\n\n\n\nAu cours de ce processus, le r\u00e9solveur r\u00e9cursif \u00e9tablit une liste interne de toutes les adresses IP des serveurs de noms faisant autorit\u00e9 sur lesquels des informations sur un certain nom de domaine sont disponibles.<\/p>\n\n\n\nLe r\u00e9solveur r\u00e9cursif choisit ensuite au hasard<\/em> l’une des adresses IP des serveurs de noms faisant autorit\u00e9 pour demander une r\u00e9ponse. L’endroit<\/em> o\u00f9 se trouve ce serveur faisant autorit\u00e9 n’a aucune importance pour le r\u00e9solveur r\u00e9cursif. Au moins une impl\u00e9mentation courante des r\u00e9solveurs r\u00e9cursifs ne se soucie pas de savoir sur quel continent ou dans quelle r\u00e9gion \u00e9conomique se trouve l’adresse IP, elle choisit au hasard dans le monde entier[2]<\/a>.<\/p>\n\n\n\n(Soit dit en passant, la raison pour laquelle il fait cela est d’emp\u00eacher l’attaque dite de Kaminsky \u00e0 laquelle le DNS est vuln\u00e9rable en l’absence de DNSSEC, voir https:\/\/www.nlnetlabs.nl\/documentation\/unbound\/patch-announce102<\/a>\/ et https:\/\/www.nlnetlabs.nl\/documentation\/unbound\/info-timeout\/).<\/p>\n\n\n\nPour am\u00e9liorer la r\u00e9silience, la disponibilit\u00e9 et les performances du syst\u00e8me DNS, les op\u00e9rateurs de services DNS ont largement utilis\u00e9 une technique appel\u00e9e \u00ab\u00a0anycast\u00a0\u00bb. L’id\u00e9e est que des copies exactes d’un serveur DNS, incluant son adresse IP, sont d\u00e9ploy\u00e9es \u00e0 de nombreux endroits dans l’infrastructure du r\u00e9seau. Ces serveurs sont appel\u00e9s \u00ab\u00a0instances\u00a0\u00bb (et non sites, comme dans l’annexe) et s’il existe plusieurs instances sur Internet, chacune attirera le trafic qui lui est proche en termes de topologie du r\u00e9seau. Ce sont des aimants \u00e0 trafic.<\/p>\n\n\n\nCr\u00e9er plus d’instances d’un serveur de noms vous permet de r\u00e9aliser deux choses. Premi\u00e8rement, si la s\u00e9lection al\u00e9atoire choisit l’adresse IP du serveur de noms, le fait de disposer d’une instance proche dans la topologie du r\u00e9seau vous permettra d’obtenir une r\u00e9ponse plus rapide. Deuxi\u00e8mement, une instance attirera tout le trafic local. Ainsi, si l’IP d’un serveur de noms fait l’objet d’une attaque par d\u00e9ni de service (DOS) de grande ampleur, ces instances attireront le trafic d’attaque local, permettant aux op\u00e9rateurs de r\u00e9seau de mieux identifier les attaquants et d’y r\u00e9pondre. Un plus grand nombre d’instances signifie une plus grande capacit\u00e9 \u00e0 faire face aux attaques DOS, ce qui signifie \u00e0 son tour que les r\u00e9sultats seront moins d\u00e9bilitants. Plus le nombre d’instances est \u00e9lev\u00e9, moins les citoyens europ\u00e9ens<\/strong> sont touch\u00e9s par les attaques DOS de grande envergure.<\/p>\n\n\n\nPar cons\u00e9quent, plus il y a d’instances de serveurs de noms sur le r\u00e9seau, plus celui-ci est s\u00e9curis\u00e9. Id\u00e9alement, pour la racine, il faudrait que tous les op\u00e9rateurs d\u00e9ploient plusieurs instances de serveurs de noms sur le sol europ\u00e9en. De cette fa\u00e7on, vous pouvez \u00eatre s\u00fbr que l’algorithme al\u00e9atoire r\u00e9pondra toujours rapidement. La r\u00e9silience et les performances s’en trouvent am\u00e9lior\u00e9es.<\/p>\n\n\n\nCependant, NIS2 incitera-t-il \u00e0 la cr\u00e9ation de plus de serveurs de noms ? En particulier des serveurs racine ?<\/p>\n\n\n\nJe ne pense pas que ce sera le cas. En fait, les op\u00e9rateurs de serveurs de noms risquent d’envisager de r\u00e9duire le nombre de serveurs de noms \u00e0 moins de 10 afin d’\u00e9chapper au champ d’application de la r\u00e9glementation. Par cons\u00e9quent, en l’\u00e9tat, la directive incite \u00e0 r\u00e9duire la r\u00e9silience et la disponibilit\u00e9.<\/strong><\/p>\n\n\n\nResponsabilit\u00e9<\/h2>\n\n\n\nPlus g\u00e9n\u00e9ralement, si l’on regarde la derni\u00e8re phrase du consid\u00e9rant 15. <\/p>\n\n\n\n\u00ab\u00a0les entit\u00e9s fournissant des services d’enregistrement de noms de domaine, les op\u00e9rateurs de<\/strong> serveurs de noms faisant autorit\u00e9 pour les noms de domaine et les op\u00e9rateurs<\/strong> de r\u00e9solveurs r\u00e9cursifs.\u00a0\u00bb<\/p>\n\n\n\nLes op\u00e9rateurs de r\u00e9solveurs r\u00e9cursifs font partie de la cha\u00eene d’approvisionnement des entreprises et des fournisseurs de services Internet (ISP) qui choisissent de les utiliser. De m\u00eame, les serveurs de noms faisant autorit\u00e9 font partie d’une cha\u00eene d’approvisionnement dont le d\u00e9tenteur du domaine est responsable en dernier ressort. De m\u00eame, les serveurs de noms faisant autorit\u00e9 font partie d’une cha\u00eene d’approvisionnement dont le d\u00e9tenteur du domaine est responsable en dernier ressort. En d\u00e9finitive, ceux qui mettent \u00e0 disposition un service reposant sur un nom de domaine sont responsables de la disponibilit\u00e9 de ce service. Cette responsabilit\u00e9 se r\u00e9percute sur les contrats et cr\u00e9e ainsi une culture de la s\u00e9curit\u00e9. La responsabilit\u00e9 est garantie de bas en haut, et non de haut en bas.<\/p>\n\n\n\nSi le Conseil europ\u00e9en et la Commission europ\u00e9enne entendent pr\u00e9venir les risques d’une approche descendante de la r\u00e9glementation du DNS qui pourrait s\u00e9rieusement fragmenter l’Internet et r\u00e9duire la s\u00e9curit\u00e9 en ligne, ils devraient s’inspirer de la version du Parlement europ\u00e9en du texte NIS2, qui a exclu les serveurs de noms racine du champ d’application. En fait, il faudrait aller plus loin et exclure le syst\u00e8me de serveurs racine dans son ensemble, \u00e0 la fois en raison des arguments techniques ci-dessus, mais aussi parce qu’il est d\u00e9j\u00e0 r\u00e9gi par les meilleures pratiques dans un processus ouvert et multipartite.<\/p>\n\n\n\n\n\n\n\n[1]<\/a> Les piliers de la s\u00e9curit\u00e9 sont la confidentialit\u00e9, l’int\u00e9grit\u00e9, l’authenticit\u00e9 et la disponibilit\u00e9. Nous ne discutons pas de la confidentialit\u00e9, car bien qu’il s’agisse d’un \u00e9l\u00e9ment important pour rendre le DNS plus s\u00fbr et digne de confiance, elle ne joue aucun r\u00f4le dans le projet de texte.<\/p>\n\n\n\n[2]<\/a> Je d\u00e9cris le comportement du serveur de noms r\u00e9cursif Unbound, \u00e0 la conception duquel j’ai particip\u00e9. Ce serveur traite tous les serveurs qui sont \u00e0 moins de 400 ms de temps aller-retour (n’importe o\u00f9 dans le monde) comme des serveurs analogues.<\/p>\n","protected":false},"excerpt":{"rendered":"L’Union europ\u00e9enne \u00e9labore actuellement sa deuxi\u00e8me directive sur la s\u00e9curit\u00e9 des r\u00e9seaux et de l’information (NIS2) et je suis pr\u00e9occup\u00e9 par le langage utilis\u00e9 pour d\u00e9crire le syst\u00e8me de noms de domaine (DNS) ainsi que par les effets n\u00e9gatifs que la l\u00e9gislation aura sur la s\u00e9curit\u00e9 et la r\u00e9silience du DNS. \u00c0 l’heure actuelle, trois […]<\/p>\n","protected":false},"author":866,"featured_media":129095,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_uag_custom_page_level_css":"","footnotes":""},"categories":[4903,4898],"tags":[5834],"region_news_regions":[35],"content_category":[6101],"ppma_author":[4140],"class_list":["post-158806","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-le-mode-de-fonctionnement-du-reseau-internet","category-strong-internet","tag-presentations-de-limpact-sur-internet","region_news_regions-europe","content_category-blog-type"],"acf":[],"uagb_featured_image_src":{"full":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building.jpg",1280,550,false],"thumbnail":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building-150x150.jpg",150,150,true],"medium":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building-450x193.jpg",450,193,true],"medium_large":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building-768x330.jpg",768,330,true],"large":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building-1024x440.jpg",1024,440,true],"1536x1536":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building.jpg",1280,550,false],"2048x2048":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building.jpg",1280,550,false],"post-thumbnail":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building-250x107.jpg",250,107,true],"square":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building-600x550.jpg",600,550,true],"gform-image-choice-sm":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building.jpg",300,129,false],"gform-image-choice-md":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building.jpg",400,172,false],"gform-image-choice-lg":["https:\/\/www.internetsociety.org\/wp-content\/uploads\/2020\/12\/european-commission-berlaymont-building.jpg",600,258,false]},"uagb_author_info":{"display_name":"Olaf Kolkman","author_link":"https:\/\/www.internetsociety.org\/fr\/author\/kolkman\/"},"uagb_comment_info":0,"uagb_excerpt":"L’Union europ\u00e9enne \u00e9labore actuellement sa deuxi\u00e8me directive sur la s\u00e9curit\u00e9 des r\u00e9seaux et de l’information (NIS2) et je suis pr\u00e9occup\u00e9 par le langage utilis\u00e9 pour d\u00e9crire le syst\u00e8me de noms de domaine (DNS) ainsi que par les effets n\u00e9gatifs que la l\u00e9gislation aura sur la s\u00e9curit\u00e9 et la r\u00e9silience du DNS. \u00c0 l’heure actuelle, trois\u2026","authors":[{"term_id":4140,"user_id":866,"is_guest":0,"slug":"kolkman","display_name":"Olaf Kolkman","avatar_url":{"url":"https:\/\/www.internetsociety.org\/wp-content\/uploads\/2022\/06\/Olaf-Kolkman.jpg","url2x":"https:\/\/www.internetsociety.org\/wp-content\/uploads\/2022\/06\/Olaf-Kolkman.jpg"},"0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/posts\/158806","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/users\/866"}],"replies":[{"embeddable":true,"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/comments?post=158806"}],"version-history":[{"count":0,"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/posts\/158806\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/media\/129095"}],"wp:attachment":[{"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/media?parent=158806"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/categories?post=158806"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/tags?post=158806"},{"taxonomy":"region_news_regions","embeddable":true,"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/region_news_regions?post=158806"},{"taxonomy":"content_category","embeddable":true,"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/content_category?post=158806"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.internetsociety.org\/fr\/wp-json\/wp\/v2\/ppma_author?post=158806"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}](\"https:\/\/www.internetsociety.org\/wp-content\/uploads\/2021\/06\/2021-06-14-2021-06-14EUR.png\"){kind=link}