En estos momentos, la Uni\u00f3n Europea est\u00e1 elaborando su segunda directiva sobre seguridad de las redes y de la informaci\u00f3n (NIS2) y me preocupa el lenguaje utilizado para describir el sistema de nombres de dominio (DNS, por sus siglas en ingl\u00e9s) y los efectos negativos que la legislaci\u00f3n tendr\u00e1 sobre la seguridad y la resistencia del DNS.<\/p>\n\n\n\n
En la actualidad, hay tres borradores diferentes del NIS2 en circulaci\u00f3n. El Parlamento Europeo acaba de aprobar un borrador que luego ser\u00e1 comparado con los borradores elaborados por el Consejo Europeo (Estados miembros de la Uni\u00f3n Europea) y la Comisi\u00f3n Europea (rama ejecutiva de la UE en Bruselas) para ser negociado hasta que las partes se pongan de acuerdo en un texto \u00fanico.<\/p>\n\n\n\n
Ya hemos escrito antes sobre el NIS2<\/a>. Ahora me gustar\u00eda profundizar en el borrador del Consejo Europeo y en un aspecto concreto del DNS, indicando hasta qu\u00e9 punto la realidad t\u00e9cnica se aleja de la intenci\u00f3n normativa.<\/p>\n\n\n\n La intenci\u00f3n del NIS2 es garantizar que la infraestructura de la que depende Europa para su actividad econ\u00f3mica sea segura y digna de confianza. Es un objetivo loable. De hecho, Internet Society cree que cualquier infraestructura de Internet en la que las personas tengan que confiar para su actividad social y econ\u00f3mica debe ser segura y digna de confianza, independientemente de d\u00f3nde vivan.<\/p>\n\n\n\n Para alcanzar este objetivo de seguridad, NIS2 quiere regular el sistema de nombres de dominio (DNS). El considerando 15 del borrador del Consejo Europeo del proyecto de NIS2 dice ahora:<\/p>\n\n\n\n \u201cPor lo tanto, la presente Directiva debe aplicarse a todos los proveedores de servicios de DNS a lo largo de la cadena de suministro y<\/strong> resoluci\u00f3n del DNS que sean de importancia para el mercado interior<\/strong>, (Esto procede del documento 12019\/2\/21 Rev2 con fecha del 25 de octubre de 2021, no disponible para el p\u00fablico, por lo que los tachados y la negrita indican cambios recientes en el texto del proyecto).<\/p>\n\n\n\n El anexo de la versi\u00f3n del Consejo dice ahora \u201cproveedores de servicios DNS, incluidos los operadores de servidores de nombres ra\u00edz con una huella significativa en la UE (m\u00e1s de 10 sitios en la UE)\u201d.<\/p>\n\n\n\n Si miramos este lenguaje a trav\u00e9s de la lente de los pilares de la seguridad a la infraestructura del servidor DNS, el lenguaje del Consejo no a\u00f1ade ninguna seguridad o confianza. A continuaci\u00f3n, examinamos primero la integridad y la autenticidad y, posteriormente, la disponibilidad[1]<\/a>.<\/p>\n\n\n\n Cuando se trata de la seguridad y la fiabilidad, debemos considerar en primer lugar la cuesti\u00f3n de la integridad de la informaci\u00f3n que proporciona el DNS. \u00bfLa informaci\u00f3n sobre un dominio que el usuario recibe de un resolvedor de DNS es la informaci\u00f3n correcta y exacta que el operador del dominio introdujo en el DNS? La integridad est\u00e1 garantizada por las extensiones de seguridad del DNS (DNSSEC, por sus siglas en ingl\u00e9s). Con DNSSEC, la informaci\u00f3n proporcionada ha sido firmada criptogr\u00e1ficamente por el editor de la informaci\u00f3n. No importa c\u00f3mo se reciba esa informaci\u00f3n, los usuarios pueden verificar criptogr\u00e1ficamente que las respuestas son exactamente las mismas que las publicadas por el propietario del dominio. No importa d\u00f3nde se encuentre el servidor de nombres, ni siquiera lo seguro que sea: la informaci\u00f3n est\u00e1 firmada y, por tanto, no puede ser modificada, por lo que tenemos integridad. Debido a las propiedades criptogr\u00e1ficas de las firmas, sabemos qu\u00e9 entidad public\u00f3 una informaci\u00f3n DNS concreta, por lo que tambi\u00e9n tenemos autenticidad.<\/p>\n\n\n\n Independientemente del tama\u00f1o de la \u201chuella\u201d, tener m\u00e1s o menos servidores de nombres no afecta a la autenticidad e integridad de la informaci\u00f3n DNS. Tener DNSSEC s\u00ed lo hace. Y, afortunadamente, el estado de la adopci\u00f3n de DNSSEC a nivel nacional en la UE es bastante avanzado (mira aqu\u00ed nuestros mapas de adopci\u00f3n<\/a>).<\/p>\n\n\n\n En cuanto a la integridad y autenticidad del DNS, las disposiciones de NIS2 sobre los servidores de nombres no van a suponer ninguna diferencia. <\/strong>Pueden afectar a la provisi\u00f3n de la informaci\u00f3n del DNS en s\u00ed (a trav\u00e9s de los registradores y registros), pero no a la forma en que esa informaci\u00f3n se pone a disposici\u00f3n en Internet.<\/p>\n\n\n\n Dado que la autenticidad y la integridad no se ven afectadas por las disposiciones del servidor de nombres de NIS2, seguramente NIS2 mejorar\u00e1 al menos la disponibilidad y, por lo tanto, la fiabilidad y la seguridad, \u00bfverdad?<\/p>\n\n\n\n Para entender esto, veamos la disponibilidad desde la perspectiva del usuario. Cuando el usuario introduce un nombre de dominio en un navegador web, por ejemplo, ese nombre de dominio se env\u00eda a un resolvedor recursivo DNS local para buscar una direcci\u00f3n IP. A continuaci\u00f3n, el resolvedor recursivo consulta a los servidores de nombres autorizados, como los servidores ra\u00edz, para obtener una respuesta en nombre del usuario.<\/p>\n\n\n\n En este proceso, el resolvedor recursivo crear\u00e1 una lista interna de todas las direcciones IP de los servidores de nombres autorizados en los que est\u00e1 disponible la informaci\u00f3n sobre un determinado nombre de dominio.<\/p>\n\n\n\n El resolvedor recursivo elegir\u00e1 entonces al azar<\/em> una de las direcciones IP del servidor de nombres autorizados para buscar una respuesta. Al resolvedor recursivo no le importa d\u00f3nde<\/em> se encuentra ese servidor autorizado. Al menos una implementaci\u00f3n popular de resolvedores recursivos no se preocupa de en qu\u00e9 continente o regi\u00f3n econ\u00f3mica se encuentra la IP, sino que elegir\u00e1 al azar de todo el mundo[2]<\/a>.<\/p>\n\n\n\n (Por otra parte, la raz\u00f3n por la que hace esto es para prevenir el llamado ataque Kaminsky al que el DNS es vulnerable en ausencia de DNSSEC, v\u00e9ase https:\/\/www.nlnetlabs.nl\/documentation\/unbound\/patch-announce102\/<\/a> y https:\/\/www.nlnetlabs.nl\/documentation\/unbound\/info-timeout\/).<\/p>\n\n\n\n Para mejorar la resistencia, la disponibilidad y el rendimiento del sistema DNS, los operadores de servicios DNS han utilizado ampliamente una t\u00e9cnica llamada \u201canycast\u201d. La idea es que copias exactas de un servidor DNS, incluyendo su direcci\u00f3n IP, se despliegan en muchos lugares de la infraestructura de red. Esos servidores se llaman \u201cinstancias\u201d (no sitios, como en el anexo) y si hay varias instancias en Internet, cada una atraer\u00e1 el tr\u00e1fico que est\u00e9 cerca de ella en t\u00e9rminos de topolog\u00eda de red. Son imanes de tr\u00e1fico.<\/p>\n\n\n\n Al crear m\u00e1s instancias de un servidor de nombres se consiguen dos cosas. En primer lugar, si la selecci\u00f3n aleatoria elige la IP del servidor de nombres, tener una instancia cercana en la topolog\u00eda de la red te permitir\u00e1 obtener una respuesta m\u00e1s r\u00e1pida. Segundo, una instancia atraer\u00e1 todo el tr\u00e1fico local. As\u00ed que si la IP de un servidor de nombres est\u00e1 bajo un ataque de denegaci\u00f3n de servicio (DOS, por sus siglas en ingl\u00e9s) de gran volumen, estas atraer\u00e1n el tr\u00e1fico de ataque local, permitiendo a los operadores de red identificar y responder mejor a los atacantes. M\u00e1s instancias significa m\u00e1s capacidad para hacer frente a los ataques de DOS, lo que a su vez significa que habr\u00e1 menos resultados debilitantes. Y cuantas m\u00e1s instancias, menos ciudadanos de la UE<\/strong> se ver\u00e1n afectados durante los ataques DOS de gran volumen.<\/p>\n\n\n\n Por lo tanto, cuantas m\u00e1s instancias de servidores de nombres haya en la red, m\u00e1s segura ser\u00e1. Lo ideal ser\u00eda que todos los operadores desplegaran varias instancias de servidores de nombres en territorio europeo. De este modo, se puede estar seguro de que el algoritmo aleatorio siempre responder\u00e1 con prontitud. Simplemente se obtiene m\u00e1s resistencia y mejor rendimiento.<\/p>\n\n\n\n Pero \u00bfincentivar\u00e1 NIS2 la creaci\u00f3n de m\u00e1s servidores de nombres? \u00bfEn particular, servidores ra\u00edz?<\/p>\n\n\n\n No creo que lo haga. De hecho, puede hacer que los operadores de servidores de nombres se planteen reducir la cantidad de servidores de nombres a menos de 10 para quedar fuera del \u00e1mbito de la normativa. Por lo tanto, tal y como est\u00e1 la directiva, incentiva la reducci\u00f3n de la resistencia y la disponibilidad.<\/strong><\/p>\n\n\n\n De forma m\u00e1s general, si se observa la \u00faltima frase del considerando 15. <\/p>\n\n\n\n \u201clas entidades que prestan servicios de registro de nombres de dominio, los operadores de <\/strong>servidores de nombres autorizados para nombres de dominio y los operadores de<\/strong> resolvedores recursivos\u201d.<\/p>\n\n\n\n Los operadores de resolvedores recursivos forman parte de la cadena de suministro de las empresas y los proveedores de servicios de Internet (ISP, por sus siglas en ingl\u00e9s) que deciden utilizarlos. Del mismo modo, los servidores de nombres autorizados forman parte de una cadena de suministro de la que, en \u00faltima instancia, es responsable el titular del dominio. La entidad que pone a disposici\u00f3n sus servicios a trav\u00e9s de, por ejemplo, un dominio de la UE, garantizar\u00eda la disponibilidad de su servicio mediante acuerdos de nivel de servicio en la cadena de suministro. En \u00faltima instancia, quienes ponen a disposici\u00f3n un servicio que depende de un nombre de dominio son responsables de la disponibilidad de ese servicio. Esta responsabilidad se transmite a trav\u00e9s de los contratos y, de este modo, se crea una cultura de la seguridad. La responsabilidad se garantiza de abajo arriba, en lugar de arriba abajo.<\/p>\n\n\n\n Si el Consejo Europeo y la Comisi\u00f3n Europea quieren evitar los riesgos de un enfoque descendente de la regulaci\u00f3n del DNS que podr\u00eda fragmentar gravemente Internet y reducir la seguridad en l\u00ednea, deber\u00eda seguir el ejemplo de la versi\u00f3n del Parlamento Europeo del texto NIS2, que ha excluido a los servidores de nombres ra\u00edz del \u00e1mbito de aplicaci\u00f3n. De hecho, deber\u00eda ir un paso m\u00e1s all\u00e1 y excluir el sistema de servidores ra\u00edz en su conjunto, tanto por los argumentos t\u00e9cnicos mencionados anteriormente como porque ya se rige por las buenas pr\u00e1cticas en un proceso abierto de m\u00faltiples partes interesadas.<\/p>\n\n\n\nlas entidades que prestan servicios de registro de nombres de dominio,<\/s> incluidos los operadores de servidores de nombres ra\u00edz con una huella significativa en la UE<\/strong>, los servidores de registros de nombres de dominio<\/strong> de primer<\/s> nivel (TLD), las entidades que prestan servicios de registro de nombres de dominio, los operadores de<\/strong> servidores de nombres autorizados para nombres de dominio y los operadores de<\/strong> resolvedores recursivos\u201d<\/p>\n\n\n\nIntegridad y autenticidad<\/h2>\n\n\n\n
Disponibilidad<\/h2>\n\n\n\n
Responsabilidad<\/h2>\n\n\n\n
\n\n\n\n
![mapas de adopci\u00f3n<\/a>).<\/p>\n\n\n\nEn cuanto a la integridad y autenticidad del DNS, las disposiciones de NIS2 sobre los servidores de nombres no van a suponer ninguna diferencia. <\/strong>Pueden afectar a la provisi\u00f3n de la informaci\u00f3n del DNS en s\u00ed (a trav\u00e9s de los registradores y registros), pero no a la forma en que esa informaci\u00f3n se pone a disposici\u00f3n en Internet.<\/p>\n\n\n\nDisponibilidad<\/h2>\n\n\n\nDado que la autenticidad y la integridad no se ven afectadas por las disposiciones del servidor de nombres de NIS2, seguramente NIS2 mejorar\u00e1 al menos la disponibilidad y, por lo tanto, la fiabilidad y la seguridad, \u00bfverdad?<\/p>\n\n\n\nPara entender esto, veamos la disponibilidad desde la perspectiva del usuario. Cuando el usuario introduce un nombre de dominio en un navegador web, por ejemplo, ese nombre de dominio se env\u00eda a un resolvedor recursivo DNS local para buscar una direcci\u00f3n IP. A continuaci\u00f3n, el resolvedor recursivo consulta a los servidores de nombres autorizados, como los servidores ra\u00edz, para obtener una respuesta en nombre del usuario.<\/p>\n\n\n\nEn este proceso, el resolvedor recursivo crear\u00e1 una lista interna de todas las direcciones IP de los servidores de nombres autorizados en los que est\u00e1 disponible la informaci\u00f3n sobre un determinado nombre de dominio.<\/p>\n\n\n\nEl resolvedor recursivo elegir\u00e1 entonces al azar<\/em> una de las direcciones IP del servidor de nombres autorizados para buscar una respuesta. Al resolvedor recursivo no le importa d\u00f3nde<\/em> se encuentra ese servidor autorizado. Al menos una implementaci\u00f3n popular de resolvedores recursivos no se preocupa de en qu\u00e9 continente o regi\u00f3n econ\u00f3mica se encuentra la IP, sino que elegir\u00e1 al azar de todo el mundo[2]<\/a>.<\/p>\n\n\n\n(Por otra parte, la raz\u00f3n por la que hace esto es para prevenir el llamado ataque Kaminsky al que el DNS es vulnerable en ausencia de DNSSEC, v\u00e9ase https:\/\/www.nlnetlabs.nl\/documentation\/unbound\/patch-announce102\/<\/a> y https:\/\/www.nlnetlabs.nl\/documentation\/unbound\/info-timeout\/).<\/p>\n\n\n\nPara mejorar la resistencia, la disponibilidad y el rendimiento del sistema DNS, los operadores de servicios DNS han utilizado ampliamente una t\u00e9cnica llamada \u201canycast\u201d. La idea es que copias exactas de un servidor DNS, incluyendo su direcci\u00f3n IP, se despliegan en muchos lugares de la infraestructura de red. Esos servidores se llaman \u201cinstancias\u201d (no sitios, como en el anexo) y si hay varias instancias en Internet, cada una atraer\u00e1 el tr\u00e1fico que est\u00e9 cerca de ella en t\u00e9rminos de topolog\u00eda de red. Son imanes de tr\u00e1fico.<\/p>\n\n\n\nAl crear m\u00e1s instancias de un servidor de nombres se consiguen dos cosas. En primer lugar, si la selecci\u00f3n aleatoria elige la IP del servidor de nombres, tener una instancia cercana en la topolog\u00eda de la red te permitir\u00e1 obtener una respuesta m\u00e1s r\u00e1pida. Segundo, una instancia atraer\u00e1 todo el tr\u00e1fico local. As\u00ed que si la IP de un servidor de nombres est\u00e1 bajo un ataque de denegaci\u00f3n de servicio (DOS, por sus siglas en ingl\u00e9s) de gran volumen, estas atraer\u00e1n el tr\u00e1fico de ataque local, permitiendo a los operadores de red identificar y responder mejor a los atacantes. M\u00e1s instancias significa m\u00e1s capacidad para hacer frente a los ataques de DOS, lo que a su vez significa que habr\u00e1 menos resultados debilitantes. Y cuantas m\u00e1s instancias, menos ciudadanos de la UE<\/strong> se ver\u00e1n afectados durante los ataques DOS de gran volumen.<\/p>\n\n\n\nPor lo tanto, cuantas m\u00e1s instancias de servidores de nombres haya en la red, m\u00e1s segura ser\u00e1. Lo ideal ser\u00eda que todos los operadores desplegaran varias instancias de servidores de nombres en territorio europeo. De este modo, se puede estar seguro de que el algoritmo aleatorio siempre responder\u00e1 con prontitud. Simplemente se obtiene m\u00e1s resistencia y mejor rendimiento.<\/p>\n\n\n\nPero \u00bfincentivar\u00e1 NIS2 la creaci\u00f3n de m\u00e1s servidores de nombres? \u00bfEn particular, servidores ra\u00edz?<\/p>\n\n\n\nNo creo que lo haga. De hecho, puede hacer que los operadores de servidores de nombres se planteen reducir la cantidad de servidores de nombres a menos de 10 para quedar fuera del \u00e1mbito de la normativa. Por lo tanto, tal y como est\u00e1 la directiva, incentiva la reducci\u00f3n de la resistencia y la disponibilidad.<\/strong><\/p>\n\n\n\nResponsabilidad<\/h2>\n\n\n\nDe forma m\u00e1s general, si se observa la \u00faltima frase del considerando 15. <\/p>\n\n\n\n\u201clas entidades que prestan servicios de registro de nombres de dominio, los operadores de <\/strong>servidores de nombres autorizados para nombres de dominio y los operadores de<\/strong> resolvedores recursivos\u201d.<\/p>\n\n\n\nLos operadores de resolvedores recursivos forman parte de la cadena de suministro de las empresas y los proveedores de servicios de Internet (ISP, por sus siglas en ingl\u00e9s) que deciden utilizarlos. Del mismo modo, los servidores de nombres autorizados forman parte de una cadena de suministro de la que, en \u00faltima instancia, es responsable el titular del dominio. La entidad que pone a disposici\u00f3n sus servicios a trav\u00e9s de, por ejemplo, un dominio de la UE, garantizar\u00eda la disponibilidad de su servicio mediante acuerdos de nivel de servicio en la cadena de suministro. En \u00faltima instancia, quienes ponen a disposici\u00f3n un servicio que depende de un nombre de dominio son responsables de la disponibilidad de ese servicio. Esta responsabilidad se transmite a trav\u00e9s de los contratos y, de este modo, se crea una cultura de la seguridad. La responsabilidad se garantiza de abajo arriba, en lugar de arriba abajo.<\/p>\n\n\n\nSi el Consejo Europeo y la Comisi\u00f3n Europea quieren evitar los riesgos de un enfoque descendente de la regulaci\u00f3n del DNS que podr\u00eda fragmentar gravemente Internet y reducir la seguridad en l\u00ednea, deber\u00eda seguir el ejemplo de la versi\u00f3n del Parlamento Europeo del texto NIS2, que ha excluido a los servidores de nombres ra\u00edz del \u00e1mbito de aplicaci\u00f3n. De hecho, deber\u00eda ir un paso m\u00e1s all\u00e1 y excluir el sistema de servidores ra\u00edz en su conjunto, tanto por los argumentos t\u00e9cnicos mencionados anteriormente como porque ya se rige por las buenas pr\u00e1cticas en un proceso abierto de m\u00faltiples partes interesadas.<\/p>\n\n\n\n\n\n\n\n[1]<\/a> Los pilares de la seguridad son la confidencialidad, la integridad, la autenticidad y la disponibilidad. No hablamos de la confidencialidad, ya que, aunque es un componente importante para hacer que el DNS sea m\u00e1s seguro y digno de confianza, no desempe\u00f1a ning\u00fan papel en el texto del borrador.<\/p>\n\n\n\n[2]<\/a> Describo el comportamiento del servidor de nombres recursivo Unbound, uno que ayud\u00e9 a dise\u00f1ar. Ese servidor trata todos los servidores que est\u00e1n a menos de 400 ms de tiempo de ida y vuelta (en cualquier parte del mundo) como similares.<\/p>\n","protected":false},"excerpt":{"rendered":"En estos momentos, la Uni\u00f3n Europea est\u00e1 elaborando su segunda directiva sobre seguridad de las redes y de la informaci\u00f3n (NIS2) y me preocupa el lenguaje utilizado para describir el sistema de nombres de dominio (DNS, por sus siglas en ingl\u00e9s) y los efectos negativos que la legislaci\u00f3n tendr\u00e1 sobre la seguridad y la resistencia […]<\/p>\n","protected":false},"author":866,"featured_media":129096,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_uag_custom_page_level_css":"","footnotes":""},"categories":[4904,4898],"tags":[5832],"region_news_regions":[35],"content_category":[6102],"ppma_author":[4140],"class_list":["post-158809","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-modo-internet-de-interconectarse","category-strong-internet","tag-informes-de-impacto-a-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\/es\/author\/kolkman\/"},"uagb_comment_info":0,"uagb_excerpt":"En estos momentos, la Uni\u00f3n Europea est\u00e1 elaborando su segunda directiva sobre seguridad de las redes y de la informaci\u00f3n (NIS2) y me preocupa el lenguaje utilizado para describir el sistema de nombres de dominio (DNS, por sus siglas en ingl\u00e9s) y los efectos negativos que la legislaci\u00f3n tendr\u00e1 sobre la seguridad y la resistencia…","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\/es\/wp-json\/wp\/v2\/posts\/158809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/users\/866"}],"replies":[{"embeddable":true,"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/comments?post=158809"}],"version-history":[{"count":0,"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/posts\/158809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/media\/129096"}],"wp:attachment":[{"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/media?parent=158809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/categories?post=158809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/tags?post=158809"},{"taxonomy":"region_news_regions","embeddable":true,"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/region_news_regions?post=158809"},{"taxonomy":"content_category","embeddable":true,"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/content_category?post=158809"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.internetsociety.org\/es\/wp-json\/wp\/v2\/ppma_author?post=158809"}],"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}