ANCI ICANN | Charla buenas prácticas DNSSCEC

Name: ANCI ICANN | Charla buenas prácticas DNSSCEC
Uploaded: 2026-04-09 16:47:05.806802
Description: Análisis y extracción de conocimiento del video 'ANCI ICANN | Charla buenas prácticas DNSSCEC'

Muy buenos días a todos y a todas. Eh, mi nombre es Rodrigo Saucedo. Soy director de relacionamiento de partes interesadas para la región andina y de iniciativas estratégicas para América Latina y el Caribe en la ICÁ. Eh, esta es la segunda sesión que tenemos. El día de hoy vamos a hablar sobre eh un protocolo de seguridad del DNS, más conocido como DNC. Y para eso lo tenemos a Nicolás Antonielo, que es mi colega en ICAN, él es de Uruguay, él es eh gerente de relacionamiento técnico para la región de América Latina y el Caribe y los dejo en muy buenas manos. Lo único que les eh les pido por favor es eh apagar sus dispositivos, mantenerlos en silencio y si tienen alguna pregunta eh levanten la mano y les vamos a ceder la palabra. Intentemos hacerlo eh que sea lo más interactivo posible y con eso no les quito más tiempo. Le cedo la palabra a Nicolás. Adelante, Nico. Hola, buenas, buenos, buenos días a todos, a todas. ¿Se se escucha bien el audio, Rodrigo? Perfecto. Eh, bueno, como dice Rodrigo, hoy el objetivo de hoy es revisar el protocolo de NSC. lo que vamos a lo que vamos a hacer es eh bueno, basándonos un poco lo que en lo que vimos en la en la sesión anterior sobre DNS y vamos a vamos a hablar este de esta de esta extensión de seguridad eh que se llama que recibe el nombre de de DNCSC. Vamos a hablar de un poco de de cómo funciona y cómo funciona en general el el mecanismo que que utiliza DNS y bueno, cómo se aplica eso en en en el DNS y y al final vamos a ver algunas algunas consideraciones y algunas estadísticas eh de DNCSC que que que puse ahí en la presentación para para el caso de Chile, sobre todo para la parte de los de los de los resolver, de los de los servidores recursivos de DNS a modo de repaso. El la vez anterior cuando vimos cuando repasamos el tema de DNS, eh simplemente recordar el DNS es tiene esa estructura de árbol invertido donde la raíz está arriba del todo, en la parte más alta de la jerarquía y a partir de ahí se va armando todo el todo lo que llamamos el árbol del sistema de nombres de dominio del DNS. Recuerdan que en el caso del primer nivel por debajo de la raíz, ¿sí? Lo que se llaman justamente dominios de primer nivel o dominios este de nivel superior, habíamos eh hacemos énfasis en dos en en dos de de dos tipos de de dominios de de primer nivel, los que llamamos dominios genéricos de primer nivel y los dominios asociados a códigos de país. ¿Sí? Y bueno, por debajo de cada uno de esos a su vez pueden haber sus dominios y así sucesivamente se va armando todo el el árbol de DS. Recordar también la forma en la que se almacena la información, ¿sí? La forma en la que almacenamos información en ese en ese en ese en ese sistema en el sistema de nombres de dominio es a través de la utilización de lo que llamamos registros. ¿Sí? Entonces, recuerden que teníamos un registro diferente para cada tipo distinto de información que se puede almacenar en DNS. Es así que teníamos un registro para almacenar la dirección IP versión 4 asociado a un nombre de dominio, un registro para almacenar la dirección IP versión 6 asociado a un nombre de dominio, un registro para almacenar el el nombre del servidor de correo electrónico, etcétera, etcétera. ¿Sí? Entonces, cada registro es un tipo de información que yo almaceno en el DNS. Y quien administra una parte del DNS, quien administra una zona del DNS, sí, va a administrar todas las la los registros asociados a un determinado nombre de dominio, ¿sí? O o a un conjunto de nombres de dominio. Entonces, esa esa información se va a colocar en en lo que se llama archivo de zona, digamos, ¿sí? que básicamente es toda la la especificación de toda la información almacenada referente a ese a ese a ese nombre de dominio. ¿Sí? Bien, hasta ahí había había un repaso muy muy rápido de de de lo que habíamos visto la vez pasada. ¿Por qué hago este repaso? Porque bueno, DNC vamos a ver que agrega algunos algunos registros, agrega algunos tipos de datos que también hay que almacenar en el sistema de nombres de dominio para poder este cumplir con con la especificación y con lo y con lo que con con las funcionalidad del del protocolo. Entonces, voy a compartir la presentación. Bien, se ve correctamente la presentación, Rodrigo. Perfecto. Bien, entonces eh antes de comenzar y para hacer el comentario general, recuerden que en cualquier momento pueden enviar un una consulta, un comentario, lo pueden hacer en el en el en el chat y ahí, Rodrigo, en ese caso, te voy a pedir si si tú podés este monitorear el chat porque yo no no lo voy a no lo veo tan fácilmente cuando estoy presentando. Y y bueno, si no también pueden este activar el micrófono y hacer uso de la de la palabra para para justamente para hacer las consultas o comentarios. Si no no esperen al final de la presentación, como siempre, la idea es hacerlo es hacerlo dinámico, así que en cualquier momento pueden pueden este eh intervenir. Bien, perfecto. Entonces, empecemos. Vamos a a empezar con el con el repaso este de de de y explicación de cómo funciona el protocolo de NC. Entonces, a veces cuando se habla de del protocolo de NS y de los protocolos de internet en general, si se dice que la seguridad no era algo que se que se consideraba al principio. Eh, estamos hablando de la década de 1980, cuando surge todo este tema de internet y cuando surge el sistema de hombres dominio, etcétera. Eso no es no es del todo correcto, digamos. No, no, no, no es que no se considerara la seguridad en en las versiones originales de los protocolos. Eh, la seguridad se considera siempre, solamente que eh los requerimientos de seguridad han ido cambiando a lo largo del del del tiempo, ¿no?, de la historia de vida de internet, ¿sí? En estos, no sé, 40, 50 años que que que existe internet. Al principio las consideraciones de seguridad eran eran bastante laxas, no había mucha preocupación por la seguridad porque internet eran unos pocos dispositivos. Eh eh al principio era exclusivamente o casi exclusivamente a nivel académico, después eso fue creciendo y bueno, los requerimientos de seguridad fueron cambiando, fueron incrementándose los requerimientos de seguridad, fueron surgiendo otros otros otros requerimientos y y otras este vulnerabilidades en materia de confidencialidad, por ejemplo. Eso se vio, el tema de confidencialidad, por ejemplo, se vio bastante acrecentado con con el surgimiento de la normativa a nivel de la de la Unión Europea de GDPR. Eh, entonces ahí hubo que que revisar un montón de de funcionalidades eh en materia de de almacenamiento y y y disponibilidad pública de de información que fue considerada o es considerada datos personales y no debe ser accesible públicamente, etcétera, etcétera. ¿Sí? Entonces, en materia de de seguridad, en materia de de privacidad, fueron cambiando los requerimientos. Eh, también en materia de lo que llamamos disponibilidad, ¿sí? En en la la disponibilidad es, digamos, la la la el la capacidad de acceder a un determinado servicio, ¿sí? Eh, a medida que que se va volviendo más importante o más este estratégico que determinado servicio permanezca siempre disponible, ¿sí? Se van agregando o se van diseñando mecanismos y protocolos para aumentar esa esa disponibilidad. Sí. En el caso del sistema de de nombres de dominio, es un sistema que tiene altísima disponibilidad, digamos, y bueno, tiene un montón de de de mecanismos y de protocolos, como decía, este, que están diseñados específicamente para eso. Entonces, mirando un poco esta esta estas tres áreas de de vulnerabilidades que que pusimos acá, lo que sería confidencialidad, lo que sería disponibilidad y lo que sería integridad, vamos a explicar brevemente cada cada una de ellas y y y ver en cuál es que que que vamos a estar posicionados hoy en día. O sea, sobre cuál de estas actúa DNSC. Cuando hablamos de confidencialidad en general, como como recién estamos mencionando, hablamos de bueno de del del se visto desde el lado de la vulnerabilidad, digamos, vulnerar la confidencialidad sería acceder en forma no deseada a determinada información de tercero, ¿sí? Por ejemplo, un sistema de información que está destinado para uso interno de una organización, si se vulnera ese sistema y y y una un una tercer persona, un atacante logra acceder a esa información, ahí se estaría vulnerando la confidencialidad. Esto tiene que ver también con la privacidad. Hay muchísimas formas de de de asegurar la confidencialidad de los de los de los sistemas. En general, cuando estamos hablando de envío de información a través de de internet, uno de los mecanismos por excelencia utilizado para preservar la la confidencialidad o la privacidad es la encriptación. Sí, generar un canal encriptado en el cual la información entre origen y destino viaja encriptada. Entonces, si alguien captura los datos, no tiene posibilidad de decodificar o de desencriptar esa información, de visualizar la la la información a menos que conozca el mecanismo para desencriptarla, o sea, tenga las credenciales para desencriptarla o el algoritmo que yo utilice, el mecanismo que yo utilice para encriptar, eh se se vulnere. Y bueno, ahí este eso en general se se se refiere a que se rompe el el mecanismo de de encriptación y bueno, ahí se puede acceder a la información, digamos, ¿no? Este, después el tema de la disponibilidad es eso, la disponibilidad, si visto de nuevo desde el lado de la vulnerabilidad sería perder la capacidad de acceso o la o la la la capacidad de utilizar o de acceder a un determinado servicio o un determinado sistema o mecanismo. ¿Sí? Y por último, la integridad sería evitar, si se quiere, la modificación o destrucción no deseada de información. Sí. De estas tres áreas, DNCSC no actúa sobre la confidencialidad. Esto es algo que a veces eh genera confusión, digamos. DNCSC no encripta la información. La información de DNS sigue viajando en texto, lo que llama texto claro, digamos, cualquiera que capture tanto la consulta de NS como las respuestas de NS a cualquier nivel entre entre el cliente y el servidor recursivo, entre el servidor recursivo y los servidores autoritativos, en cualquier momento las todo el tráfico de de información de DNS es visible por cualquiera que logre capturar ese tráfico. ¿Sí? Entonces, DNSC, esta extensión de seguridad, la que vamos a a ver hoy, no agrega en materia de confidencialidad. Sí, tampoco agrega en materia de disponibilidad. No hace el desplegar de NSC, no hace que el sistema de nombres de dominio sea más tolerante a a a fallos de disponibilidad. Sí, lo hace, por supuesto, más tolerante a a a ataques, pero eso lo lo vamos a ver enseguida. Pero no aumenta la disponibilidad del sistema de nombre de dominio par. ¿Sí? ¿Dónde actúa DNCSC? Entonces, actúa en materia de integridad. Sí, DNSC justamente está diseñado para evitar la modificación o destrucción de información de DNS sin que sea sin que sea evidente, o sea, digamos evitar la modificación o destrucción de información de DNS, sobre todo la modificación de información de DNS y que eso pase desapercibido. ¿Sí? Entonces, de nuevo, DNSC actúa en materia de de eh integridad. Acá hay un hay un un este este slide, digamos, lo que trata de mostrar es un un el caso de cómo funcionaría el cómo funciona el sistema DNS, como vimos este la sesión anterior sin DNSC. Sí, recuerden que tenemos un un cliente, un dispositivo que que realiza una consulta de que tiene que resolver, por ejemplo, cuál es la dirección IP asociada a un determinado nombre de dominio. Envía la consulta a un servidor recursivo. Sí. a los estos buscadores. Sí. Luego el servidor recursivo va a empezar a buscar la respuesta consultando sucesivamente servidores autoeditativos. Si no tienen ninguna información acerca de la consulta que le hicieron, va a comenzar preguntándole a la raíz y después va a ir como navegando el árbol hacia abajo, empezando por la raíz, hasta encontrar el servidor autoritativo que tiene la respuesta que está buscando. Una vez que ese servidor autoritativo le envía la respuesta al servidor recursivo, el servidor recursivo le envía la respuesta al cliente y ahí termina la parte de de resolución de DNS o consulta y y y respuesta de DNS. Recuerden también que habíamos mencionado en la sesión anterior que los servidores recursivos, sí, a su vez cada vez que reciben información de cualquier servidor autoritativo, ya sea durante la búsqueda de de la de la respuesta o o o la información correspondiente a la respuesta final, en cualquier caso, el servidor recursivo siempre guarda esa información que recibe en memoria. O sea, todo lo que aprende el servidor recursivo de los servidores autoritativos lo guarda en esa que llamamos memoria calé del servidor recursivo. ¿Para qué? Para acelerar las búsquedas, para no tener que salir a buscar cada vez que le preguntan lo mismo. Sí, si alguien le pregunta lo mismo, como lo tiene almacenado en memoria, va a poder responder más rápido sin necesidad de volver a salir a buscar la información. Y recordemos también que esa información que se almacena en la memoria del servidor recursivo, no no se almacena para siempre, sino que se almacena por un tiempo y pasado ese tiempo se elimina. Si alguien quiere de nuevo vuelve a a hacer la misma consulta, bueno, ahí como la información ya se se no está en la memoria, va a tener que volver a recursivo, va a tener que volver a realizar este toda la búsqueda de información en el en el árbol de de DNS. ¿Sí? Bien. ¿Dónde actúa principalmente DNCSC? Primero dijimos que DNCS entonces actúa en materia de integridad. Sí. En qué parte de de todo el de todo el de todo el el intercambio de información de NS actúa, bueno, principalmente actúa en el intercambio de información entre los recursivos y los autoritativos. O sea, actúa cuando el servidor recursivo intercambia información con los servidores autoritativos. Sí, acá hay una especie de resumen entonces de qué es lo que lo que hace DNSC y qué no hace DNSC. ¿Qué hace DNSC? DSC mediante la utilización de criptografía que que se llama de clave pública y clave privada. Ahora vamos a ver qué es eso de clave pública, criptografía de clave pública y firmas digitales. Utiliza criptografía de clave pública y firmas digitales para proporcionar básicamente dos cosas. Lo que se llama lo que llamamos autenticación de origen, ¿sí? Y lo que llamamos integridad de los datos. Autenticación de origen es poder asegurarse de que la de que quien está enviando, quien origina la información sí sea la autoridad para esa información y no sea alguien que se está haciendo pasar por la autoridad para la información. O sea, que la información provenga de una fuente verdadera y no sea información falsificada. Eso es autenticar el origen de la información. Y la integridad de los datos es que significa que cuando la información se está enviando, cuando está este transitando entre el origen y el destino, ¿sí? evitar que esa información sea modificada y eso pase desapercibido. Es decir, dense proporciona un mecanismo para autenticar el origen de los datos y además proporciona un mecanismo para que si alguien intercepta la información y la modifica, cuando el servidor recursivo recibe la información, esto es información que el servidor autoritativo está enviando al servidor recursivo. ¿Sí? Si alguien intercepta esa información y la modifica, el servidor recursivo tiene un mecanismo provisto por DNSCS, que ahora vamos a ver enseguida, que le permite eh darse cuenta o o o verificar si la información fue alterada o no. Y en caso de que la información haya sido alterada, obviamente la va a descartar y no la va a utilizar porque se trata de información incorrecta o falsificada. ¿Sí? Entonces, autenticación de origen, integridad de los datos. Básicamente, DNS entonces ofrece protección contra la falsificación de datos de DNS, ya sea en el origen o interceptando la información mientras viaja de autoritativo a recursivo. ¿Qué no hace DNS? Bueno, lo que dijimos, no provee confidencialidad en el intercambio de datos DNS, o sea, no encripta los datos de DNS. Sí, los datos siguen siendo visibles y tampoco evita todos los ataques posibles de DNS. O sea, el el el espectro de de ataques de NS es muy grande. Lo vamos a ver en en en futuras sesiones. Eh, DNS SEC sí evita algunos tipos de ataque y permite mitigar otros tipos de ataque, pero no es la solución a todos. Por ejemplo, este que se menciona acá de lo que se llama ataque de de neegación de servicio, ya sea este concentrado o distribuido. Eh, DNCS, por ejemplo, no es no proporciona ningún tipo de protección ni solución ante un ataque distribuido o concentrado de denegación de servicio. Sí, pero si proporciona, por ejemplo, eh una protección 100% eficiente o eficaz, digamos, 100% eficaz para el un tipo de ataque que se conoce como envenenamiento de cé. El envenenamiento de calé es a nivel de servidor recursivo inyectar en la memoria del servidor recursivo una entrada falsa. Por ejemplo, asociar un nombre de dominio a una dirección IP de un atacante en lugar de la dirección IP original eh que está en el sistema de nombres de dominio. Entonces, si yo logro que un servidor recursivo memorice esa información falsa, cuando alguien le haga una consulta de NS al servidor recursivo, el servidor recursivo no va a salir a buscar la respuesta porque ya la tiene en memoria, pero lo que tiene en memoria es incorrecto porque alguien logró inyectar una entrada falsa en la memoria del servidor DNS. Entonces, contaminar la memoria del servidor recursivo es lo que se llama envenenar la memoria del servidor recursivo. Y ahí de ahí viene el nombre de ataque de envenenamiento de calle del servidor recursivo. DNSC evita ese tipo de ataque. O sea, si los registros de DNS en cuestión están eh tienen implementado DNSC, no es posible realizar para esos registros de DNS, no es posible realizar un ataque de envenenamiento de calle. Sí, ahora vamos a ver por qué y cómo funciona y por qué porque esto es así. De hecho, el este tipo de ataque fue el la principal motivación para para el por la cual se diseñó y se inventó el protocolo de NSSC. es para DNS surge como un protocolo este estandarizado por la ITF como consecuencia como respuesta a este a a a este tipo de de ataque que se descubrió y no se descubrió hace hace mucho tiempo. Digamos DNC eh está operativo desde el año 2010. Sí, previo a esa previo a esa a esa fecha, eh los ataques de de de envenenamiento de calle y algunos otros ataques eran eran este mucho más mucho más fáciles de de de realizar, digamos. Sí. Bien, ¿cómo funciona DNSC? Entonces, para explicar cómo funciona DCS, antes vamos a explicar cómo funciona, en qué consiste una firma digital. Sí, vamos a explicar cómo funcionan el dos dos mecanismos eh matemáticos, dos algoritmos de de encriptación, uno que se llama función de hash y el otro que es el justamente la encriptación esté basada en clave pública y clave privada. ¿Sí? Eh, entonces veamos primero el mecanismo de de hash. ¿Qué es una función de hash? Sí, una función de hash es un algoritmo criptográfico, una una función matemática, digamos, una operación, una serie de operaciones matemáticas, un procedimiento matemático que en en nuestro caso va a tomar un texto, ¿sí?, una secuencia de caracteres, un texto origen, ¿sí? que al aplicarle la función de hash a ese texto, el resultado sí es una cadena de caracteres que representa ese texto encriptado. Sí, lo que hace es encriptar un determinado texto con algunas características muy particulares. Y vamos a a mencionar tres de esas de esas características particulares. La primera característica es que sin importar el tamaño del volumen de texto original que yo tenga, una vez que yo defino la función de hash que voy a utilizar, ¿sí? Eh, en el ejemplo que está en la pantalla, la función de hash que yo utilicé para encriptar todos estos estos tres textos que están acá, ¿sí? Es una que se conoce como MD5, que es la probablemente la función de hash más utilizada, ¿sí? Que es la que utiliza además el protocolo de NSCS. y es la que utilizan otro montón de protocolos. Prácticamente todos los generadores de de de firmas electrónicas utilizan esta función eh de hash MD5, ¿sí? Entonces, esta función de hash de nuevo toma un texto y lo encripta, ¿sí? Una vez que yo fijo la función de hash digo, "Bueno, voy a usar MD5." El resultado de esa encriptación, ¿sí? La longitud del resultado siempre es la misma. No importa si yo tengo dos caracteres o tengo un millón de páginas de texto y las estoy les estoy aplicando la función de hash. Si le aplico una función de hash a dos caracteres o le aplico la misma función de hash a un millón de páginas de texto, el la longitud del resultado es siempre la misma. Está eso es una de las características que tiene el hash. La longitud del resultado, la cadena de caracteres o la secuencia de caracteres encriptada siempre tiene la misma longitud. Sí. La segunda característica importante es que no es reversible. ¿Qué quiere decir que no es reversible? Quiere decir que una vez que yo tengo el texto, le aplico la función de hash y obtengo la cadena encriptada, si yo les digo, usé el la función de hash md5 para obtener esta cadena de caracteres, no existe mecanismo por el cual ustedes puedan volver partiendo de la cadena de caracteres, conociendo la función de hash. No se puede volver atrás, no se puede volver a obtener el texto original, no es es lo que se llama irreversible. Es un proceso irreversible. Una vez que yo encripté, no se puede desencriptar más, no hay forma de desencriptarlo, no hay no hay mecanismo matemático estadístico que permita desencriptar una función de hash. ¿Sí? O sea, que es en un solo sentido. Solo puedo encriptar y alguien dirá, "Bueno, pero para qué sirve si yo encripto algo y nunca más lo puedo desencriptar. Está difícil o a veces es un poco difícil ver la utilidad. La vamos a ver enseguida." Está, recuerden eso. La longitud es constante para un para un algoritmo de gas definido y no es reversible. ¿Sí? Y la otra característica que tiene es que cualquier cosa que yo modifique en el texto, agregar caracteres, agregar palabras, agregar espacios, borrar caracteres, o sea, cualquier modificación en el texto original produce un resultado encriptado. Sí. Totalmente distinto. Sí. Y acá, por ejemplo, yo puse tres ejemplos. Ustedes pueden buscar después ahí en en internet, este, hay muchos eh eh sitios que uno pone algoritmo de hash MD5 y te permiten escribir un una secuencia de caracteres y y y generar el hash. Si ustedes eh escriben este esta secuencia one ring to rule de mold y está escrito en inglés, pero bueno, este escriben estas tres secuencias van a tener estos tres resultados diferentes. Si se fijan, este, entre la primera y la segunda hay solo una letra de diferencia. Una dice ring y otra dice ping. Sí, una R y una P. Es la única diferencia entre las dos primeras. Sí, a las dos se le aplicó el mismo mecanismo de hash MD5. Y fíjense el resultado. Las dos tienen la misma longitud, ¿sí? Pero son totalmente distintos los los cadena de caracteres encriptada. ¿Sí? Entonces, cualquier cosa que cambie en la secuencia original me modifica totalmente este el resultado. ¿Sí? Y el último ejemplo es una secuencia mucho más corta, son solamente dos palabras y también es totalmente distinto a los a los anteriores, pero de nuevo la longitud es siempre la misma. Perfecto. Te interrumpo. Hay un comentario, tal vez vale la pena leerlo. Adelante. MD5 es muy vulnerable. No está contemplado usar una función de hash como AS256. ¿Es una modificación del protocolo? Pregunta. Sí. A ver, el el el mecanismo de de en el caso de MD5 lo codifica en una en una en una secuencia de, o sea, utiliza una una encriptación de 128 bits, digamos. Eh, el MD5 es vulnerable, pero no tan no tan rápidamente, digamos. lo lo que lo que lo que importa acá este en en en este caso es cuál es en promedio el tiempo que se insume para romper este eh en general utilizando un mecanismo que se llama fuerza bruta para romper el el el la codificación, digamos, o sea, para que alguien este lo logre revertir, digamos, ¿no? Esto es irreversible, entonces si alguien lo logra revertir, quiere decir que rompió el el algoritmo de codificación. La forma de de de romperlo en el caso de de hash no es revirtiéndolo porque de nuevo no es reversible, no es matemáticamente reversible, digamos. Lo que se hace es se empieza a generar secuencias de caracteres y y a encriptar secuencias de caracteres hasta que se obtiene la misma cadena. Si yo encripto dos secuencias de caracteres y obtengo la misma cadena, quiere decir que las dos secuencias de caracteres son iguales. ¿Sí? Entonces empieza a probar encriptar este, pero hay que tener una idea de qué es lo que estoy encriptando para de la longitud original del de la secuencia para para poder este romperlo. Sí, es relativamente vulnerable, pero en en ahora vamos a ver cómo se utiliza y lo importante acá es que en en los tiempos en que se insume eh eh para vulnerar esto, en realidad ya como que el la información no es no es importante, no es relevante. Entonces, toda lación se basa en general en eso, ¿no? en que no en que sea infalible, sino en que se demore muchísimo tiempo en vulnerarla. Normalmente la idea es que sea muchísimo más tiempo que la utilidad de la información. Sí, que yo quiero el tiempo durante el cual yo quiero ocultar información. No sé, para un para un como mencionaron por ahí, para un mecanismo de encriptación basado en SHA 256, el promedio con las computadoras que hay hoy en día, con la capacidad de cómputo de hoy en día para para romper un una encriptación de SHA 256 probablemente miles o millones de años, digamos. Entonces, probablemente en miles de años esa información ya no sea útil, digamos. Y en eso se basa la la encriptación. SHA1, por ejemplo, ya está más que este roto el el el algoritmo, entonces se demoran unos pocos minutos o menos en romper una una codificación SH1, pero por eso es que no se utiliza más, digamos, ¿no? Por eso se recomienda utilizar ese HA256 o algo todavía más difícil de de vulnerar. Sí, de nuevo se pueden utilizar otros mecanismos de hash que no sean de 128 bits, que sean de más de más resistentes, digamos, este, y sí, cuanto más resistente es mejor. En general, NCS utiliza eh MD5, pero no es el único que utiliza. También utiliza ención de clave pública y clave privada, que es así. Este es muchísimo más complicada de resolver. Utilizo una combinación de las dos. Ahora vamos a ver. Sí. Bien, muchas gracias por la pregunta. Pues es es superinesante. Tampoco este nos vamos a poner a ver en detalle cómo funciona todo el tema de de encriptación porque sería un poco un poco complicado. No sé si responde la pregunta o si alguien tiene alguna otra otra pregunta o comentario adicional. No, creo que se le habilitó el micrófono. Ahí está. Ya le pusimos. Nico, sin querer queriendo te puse mute a ti. Perdón. Estás on te tienes que habilitar tu micrófono. Yo lo puse sin querer por Ahí está. Ahora me escuchan. Perdón, perdón. Ahora sí. No pasa nada. Me está saboteando la la prestación, Rodrigo, pero no pasa nada, no hay problema. Cosas que pasan. Así le damos un poco más de tono jocoso a esto. Está perfecto. Bueno, entonces así funciona el mecanismo de hash. Guardemos eso en la memoria por un momento y vamos a hablar un poco de esto de encriptación este de clave pública. Sí. ¿Cómo funciona la encriptación de clave pública? ¿Qué es y cómo funciona? cuando cuando hablamos de de encriptación en general, eh podríamos hacer esta esta distinción en dos grandes grupos, ¿no? Lo que lo que llamamos encriptación simétrica y lo que llamamos encriptación asimétrica. Cuando hablamos de encriptación simétrica, ¿sí? Sin importar el mecanismo de encriptación que utilicemos, cuando es simétrica, las mismas credenciales que se usan para encriptar se usan para desencriptar. O sea, yo encripto utilizando una clave, por ejemplo, sí envío la información encriptada a a alguien que quiero que la pueda leer, que pueda visualizar o tener la información de nuevo. O sea, lo que lo que tiene que hacer esa esa persona ese e el que recibe la información que está encriptada es desencriptarla. Como esa encriptación, como estamos hablando encriptación simétrica, ¿sí? Lo que necesita es la misma clave que yo usé para encriptar. La misma clave con la que encripto, desencripto. Por eso es simétrico. Entonces, yo tengo que comunicar la clave que usé para encriptar. Sí, cualquiera que tenga la clave puede encriptar y desencriptar indistintamente. ¿Sí? Por otro lado, hay otro tipo deción sería la inclinación asimétrica. En lación asimétrica, en vez de generar una única clave, se generan dos claves. Sí, se pueden generar más. No vamos a entrar en detalles, pero el caso más simple de incripitación asimétrica es con dos claves. ¿Sí? Entonces, ¿qué sucede? Esas dos claves que se generan, ¿sí? Una se utiliza para encriptar y la otra se utiliza para desencriptar. ¿Cuál uso para hacer qué? No importa, cualquiera de las dos la puedo utilizar para encriptar. Lo que lo que lo que hay que siempre recordar es que si estamos hablando de encriptación asimétrica con un par de claves, si yo elijo cualquiera de ellas y la utilizo para encriptar, la única forma de desencriptar es utilizando la otra. Es decir, si utilizo la misma clave que usé para encriptar, no puedo desencriptar. Solo la puede desencriptar la otra. No importa cuál de las dos utilice. Lo que una encripta, solo la otra lo desencripta. Así no más. Lo que una encripta, solo la otra lo desencripta. Okay. Bien. Por eso se llama asimétrica. ¿Por qué se le llama a veces a esto en critación de clave pública y clave privada? Bueno, de esas dos claves que se generan enitación asimétrica, a una de ellas se le asigna el nombre de clave privada. De nuevo, ¿a cuál? No importa, cualquiera de las dos. Cualquiera de las dos voy a decir, "Bueno, esta es la clave privada. ¿Por qué se le llama privada?" Porque la clave privada solo la voy a conocer yo, quien quiero que pueda encriptar. Y la clave privada solo se va a utilizar para encriptar. En este caso, ¿cómo hago para desencriptar las cosas que encripto con la clave privada? Necesito la otra clave. A la otra clave se le llama clave pública. ¿Por qué se le llama clave pública? Porque se le se le da, sí, la tengo que suministrar a todo aquel que quiero que pueda desencriptar la información. Es decir, encripto con la clave privada, desencripto con la clave pública. La clave privada la conozco solo yo, o sea, que solo yo puedo encriptar. Y la clave pública se la doy a todo el mundo, por eso llama público. Así todos pueden desencriptar lo que yo encripto. Y de nuevo alguien acá se puede preguntar, "Bueno, pero ¿por qué le darías la clave pública a todo el mundo si lo que querés es encriptar?" Si vos encriptas algo y después le das la clave a todo el mundo, cualquiera lo puedes encriptar. Entonces, ¿qué sentido tiene encriptar? Bueno, de nuevo, recordemos que la utilización acá de de estos mecanismos de encriptación no es para proveer privacidad, no es para que no se pueda acceder al contenido encriptado, sino que es para generar lo que llamamos una firma digital. Entonces, ahora vamos a ver cómo utilizando este mecanismo, combinando el hash con el mecanismo de clave pública y clave privada utilizado de esa manera, se obtiene una firma digital. Sí. Y esto aplica a cualquier firma digital, no solo a DNCS, digamos. Sí. Entonces, tengo un texto, ¿sí? Lo encripto con la clave pública, obtengo el texto encriptado. Sí, si yo desencripto ese texto con la clave privada, ¿qué obtengo? Obtengo el texto original. O sea, que texto original, encripto con la clave pública. Ahora está encriptado, desencripto con la clave privada y vuelvo a obtener el texto original. Acá sí es reversible, solamente que es reversible utilizando la otra clave que no es la que se usó para encriptar. Una enrita la otra es encrpita. Okay. Bien. Vamos a ver entonces cómo se cómo se construye una firma una firma una firma digital y por qué es una firma digital combinando hash con encriptación de clave pública y clave privada. El objetivo acá es firmar un texto, igual que como firmamos un contrato, igual que como firmamos un cheque. Cuando yo firmo un cheque, ¿sí?, ¿qué es lo que hace el el receptor, el banco que recibe el cheque? Es verificar la firma, ¿verdad? Antes de de de pagar el cheque o de hacer algo con ese cheque, tiene que verificarse la firma. Sí, lo mismo para un contrato. Yo firmo un contrato. Antes de de revisar el contrato o ver la valiz del contrato, hay que verificar la firma. Entonces, ¿cómo se verifica una firma caligráfica, digamos, una firma escrita a mano? Bueno, una firma escrita a mano, hay hay unas técnicas y hay eh en Uruguay se le llaman peritos calígrafos eh a las personas que verifican eh firmas este caligráficas de de de manera de manera visual, digamos, este y comparándola con con la firma con un registro de firmas. Si. Entonces yo para verificar una firma de una firma manual de un cheque, bueno, tengo un registro de firmas donde dice firmar a la persona, no sé, cinco veces, ¿sí? Entonces, cuando firma el cheque, comparo la firma que está en el cheque con ese registro. Sí. Y si hay determinado tipo de coincidencias, este, que yo desconozco porque no soy experto en eso, este, bueno, la firma se da por válida. Sí. Este, claro, una firma caligráfica es bastante fácil, bastante fácil o relativamente fácil de falsificar. Sí, porque, bueno, solo toca hacerla lo más parecido posible y a a la a la a las al registro de firmas como para que pase la prueba y listo. Una firma digital ya es si no se rompieron los algoritmos es prácticamente imposible de falsificar, digamos, ¿no? Entonces, ¿cómo funciona? Tengo tengo el texto que quiero firmar. Sí, lo primero que se le hace al texto, como está acá, lo primero que se le hace al texto es aplicarle el hash. Sí, recuerden que cuando al texto le aplicamos el hash utilizando, por ejemplo, MD5, obtenemos esa cadena de caracteres de longitud fija, pero que cualquier cosa que cambie en el texto original produce un hash totalmente distinto. ¿Sí? ¿Por qué se aplica el hash? Sí. y no directamente generar la firma eh con el texto original. Bueno, acá lo que lo que entra en juego es la longitud fija del resultado de hash. Imagínense que ustedes tienen tres palabras, le aplican un hash obtienen un una secuencia de caracteres, no sé, de de de 30 caracteres y después tienen un texto de 10,000 páginas de texto, le aplican el mismo hash. Obtienen una secuencia totalmente distinta, pero también de 30 caracteres. Sí. Entonces, sin importar el tamaño del texto original, el resultado siempre es el mismo en longitud. Eso lo que me hace es que yo tenga certeza del volumen de información que voy a manejar. Porque si yo manejara este texto original, ¿sí? No es lo mismo tener que transferir dos o tres palabras que tener que transferir un millón de páginas. Transferir un millón de páginas ocuparía muchísimo ancho de banda. transferir dos o tres palabras ocuparía muy poco. Entonces, el ancho de banda dependería de la cantidad de información que yo quiero transferir. Si yo le hago el hash y lo que transfiero es el hash, ya me separo, me olvido de la cantidad de información que yo tengo originalmente, porque lo que voy a transferir es más o menos siempre lo mismo, porque la longitud es siempre la misma del resultado, ¿se entiende? Igual va a ser una especie de huella digital de lo original. ¿Por qué? Porque el hash si cambia algo en el texto original cambia totalmente la secuencia. Sí. Entonces, con eso lo que se hace es se acota el ancho de banda que se utiliza para enviar la información de la firma, ¿está? Entonces, texto original que yo quiero firmar, le aplico el hash y luego encripto el hash con mi llave privada. Sí. El resultado de encriptar el hash de un texto con la llave privada es lo que se llama firma digital de ese texto. Eso es una firma digital. ¿Por qué es una firma digital? Si yo encripté algo con mi llave privada, ¿quién es el único que lo puede desencriptar? El que tenga la llave pública, ¿verdad? Dijimos que la llave pública se la damos a todo el mundo, entonces todo el mundo lo puede desencriptar. Entonces, el punto de vista de encriptación no tiene mucho sentido porque cualquiera puede abrir la información. Pero des el punto de vista de firma, fíjense lo siguiente. Si yo tengo algo que pude desencriptar con la llave pública, ¿qué quiere decir respecto a el el el texto original que yo encripté? Bueno, quiere decir que si yo puedo desencriptar algo con la llave pública, ¿sí? ¿Quién es el único que lo pudo haber encriptado? el que tiene la llave privada, porque la llave pública solo desencripta lo que la llave privada encriptó. Entonces, si yo logro desencriptar algo, sí, el único que pudo haberlo encriptado es el que tiene la llave privada. Y eso es una firma. ¿Por qué? Porque solamente yo tengo la llave privada. Entonces, si ustedes logran desencriptar algo que yo envié, pueden estar seguros de que no es falso, de que lo envié yo. Y yo tampoco voy a poder decir, "No, yo no lo envié." Sí lo enviaste vos, porque el único que tiene la llave privada sos vos. y yo acabo de desencriptar algo que vos encriptaste, ¿se entiende? Entonces, por eso es que el mecanismo de llave pública y llave privada utilizado de esta manera es un mecanismo para firmar digitalmente algo, digamos. Sí, ¿qué es lo que estamos firmando digitalmente acá? Lo que estamos firmando digitalmente acá es un hash porque estamos encriptando el hash. ¿Okay? Entonces, ¿cómo se verifica la firma digital del texto original? Si yo encripté el hash Bueno, se hace de la siguiente manera. Yo lo que tengo que hacerle llegar al al al al a la otra parte, digamos, es el texto original. Lo que estoy transfiriendo es un es información firmada. Entonces, además de enviarle la información, yo le voy a enviar la firma. Y además de enviarle la firma, ¿qué necesito enviar? La clave pública también. O sea, que el que recibe necesita la información, obviamente, que es lo que le interesa, la firma de esa información y la clave pública, ¿no? Y además conocer los algoritmos que se utilizaron para para hacer el hash y para encriptar. Si yo si yo tengo toda esa información, si recibo toda esa información, tengo por un lado el texto original, que es lo que quiero, por otro lado, la firma con la clave pública y los algoritmos. Yo antes de mirar que hay en el texto, lo que voy a hacer es validar la firma, tratar de validar la firma. Si la firma valida, perfecto. Si la firma no valida, descarto todo, porque quiere decir que algo falso. O la firma es falsa, o el texto está modificado o el texto es falso, hay algo mal. Está. ¿Cómo verifico la firma? Bueno, tengo la firma y la clave pública. Con la clave pública puedo desencriptar la firma. ¿Qué obtengo? El hash. Correcto. Tengo el hash. Ahora, el hash que obtuve de desencriptar la firma. Por otro lado, tengo el texto original. Le aplico el hash al texto original porque yo ese hash no es reversible, no puedo deshacer el hash y comparar los textos originales. Entonces, desencripto la firma, tengo el hash. Agarro el texto original, le aplico el hash y comparo los dos hash. Si los dos hash coinciden, son exactamente iguales, quiere decir que esa firma corresponde a ese texto. Si hay alguna diferencia entre los hash, quiere decir que la firma es falsa, el texto fue modificado o algo pasó, pero definitivamente esa firma no corresponde a ese texto. Si ese no fue el texto firmado que corresponde a esta firma, por lo cual descarto la información. ¿Sí? Entonces, de nuevo, ¿cómo se verifica la firma digital? Se desencripta la firma con la llave pública, se obtiene un hash y se compara con el hash del texto y ahí si coinciden bien y si no descarto la información. ¿Okay? De de esta manera se se puede fácilmente verificar una una firma una firma digital y es el mecanismo de verificación que utilizan casi todos los mecanismos de firma de firma digital. Sí. Por eso le decía hoy en día que tampoco es tan crítico el tema de la reversibilidad del hash. Si acá lo que es crítico es que lo que lo que tiene que ser bien sólido es el el el mecanismo de encriptación de clave pública y clave privada. Sí, el hash es más que nada para no depender del tamaño del texto original y enviar siempre información con una longitud fija para acotar el ancho de banda. Sí, pero perfectamente podría olvidarme del algoritmo de hash y encriptar directamente el texto. Ahí desencripto la firma y tengo el texto y comparo los textos. Lo que pasa que también una cosa es comparar 30 caracteres, un hash con otro hash y otra cosa es comparar 10,000 páginas de texto con 10,000 páginas de texto buscando a ver si hay alguna diferencia. Demoro, en un caso demoro unos pocos milisegundos o menos y en el otro puedo demorar días comparando página de texto, digamos, aunque sea en forma computacional, digamos. Entonces, esa es la razón por la que se se comparan y se se utilizan los hash y no directamente eh los textos tal cual están, digamos. Pero no es el la finalidad no es solo no es meramente la de encriptar, eso es lo de menos, digamos. O sea, que el hecho de que se vulnere, incluso si se vulnerara, si se rompiera totalmente y fuera bien fácil revertir un el MD5 en este caso, la firma sería totalmente seguiría siendo totalmente válida porque de nuevo es un mecanismo para acotar el ancho de banda y no para para proteger información. Está. Lo que protege la información es el algoritmo que que genera la firma, que es la encriptación con la con la clave pública y clave privada. ¿Sí? Bien. ¿Qué tiene que ver todo esto con el DNS y cómo se aplica a DNSC? Sí. Bien. Entonces, ¿cómo cómo se aplica ADNCSC? Bueno, dijimos que eh esto opera en el diálogo entre servidor recursivo y los servidores autoritativos. Cuando el servidor recursivo empieza a consultar los servidores autoritativos para obtener la respuesta. Entonces cada vez que un servidor autoritativo le envía una respuesta al servidor recursivo, cuando yo no tengo DNCs, va, viene la respuesta. El servidor recursivo no tiene otra opción que confiar en lo que le llegó. Si lo que le llegó está mal, chao, perdimos. Si alguien lo modificó, si alguien logró acceder al servidor autoritativo y modificar la información el servidor autoritativo, si hizo un ataque de lo que se llama persona en el medio, digamos, de de interceptar la información, modificarla, cosa de que lo que sale del servidor autoritativo es diferente a lo que llega al servidor recursivo, cualquier tipo de de ataque. Si yo no tengo un mecanismo de verificación de la información, no tengo DNCS implementado, el el servidor recursivo va a confiar en la información. Si la información es falsa, va a dar información falsa. Si tengo DNCS implementado, cuando el servidor autoritativo envía la información al servidor recursivo, además, ¿qué le va a hacer? Le va a enviar la firma de esa información. O sea, DNCSC no es otra cosa que firmar la información a nivel de servidor autoritativo para enviar la información firmada al servidor recursivo. Entonces, ahora el servidor recursivo, ¿sí? Si el servidor autoditativo tiene DNCS implementado, envía la información al servidor recursivo, le envía la firma al servidor recursivo, le envía la clave pública al servidor recursivo y le dice cuáles son los algoritmos que utilizó para el hash y para encryptar. Ya. Entonces ahora tengo la información igual que como tenía sin DNSC sumado a la firma, la clave pública y los datos de los algoritmos utilizados. Sí, el servidor recursivo recibe todo eso. ¿Qué hace? Tiene la información y tiene la firma y tiene la clave pública. Agarra la clave pública, desencrita la firma, tiene el hash. Agarra la información, le aplica el hash y compara los dos hash. Si los dos hash coinciden, perfecto, la información viene de quien dice, de quien tiene la autoridad para esa información. Y además no hay forma de que haya sido modificada en el medio, porque si alguien cambia la información la firma no va a verificar. Sí. Entonces, el servidor recursivo tiene un mecanismo para verificar esa firma eh digital que generó y envió el servidor autoritativo. Esa esa acción de verificar una firma digital por parte del servidor recursivo se llama validación. Validación de DNSC. La validación de DNSC ocurre a nivel de servidor recursivo. La firma de la información ocurre en los servidores autoritativos. Entonces, para que DS funciona es una tarea de dos. A nivel de servidor autoritativo, cada registro que yo tenía en mi archivo de zona, cuando yo despiego de NSSC, lo voy a firmar y va a quedar firmado, o sea, va a haber una firma para cada uno de los registros que yo tenía en el archivo de Sony del lado del servidor recursivo, hay que habilitar validación de NCSC de forma que el servidor recursivo cuando recibe la información, la firma, la clave pública y los datos pueda verificar esa firma. Sí, tiene que ser una cosa de de los dos lados. Sí, de nuevo, servidor autoritativo, firmar los registros. Servidores recursivos, habilitar validación. Por supuesto que la habilitación de la validación y la acción de validación es muchísimo más simple que mantener un esquema de firmas y administrar un servidor autoritativo con DNCS. No es superclicado administrar un servidor autoritativo con TSC, pero sí es más complejo, bastante más complejo que solamente habilitar validación a nivel de servidor recursivo. Sí. Eh, bien, preguntas hasta acá, comentarios. Nos está faltando un pedacito que es el más complicado de todos. Entonces, ahora ajústense los cinturones porque va a ser un poquito movido esto. Eh, hay una pregunta, Yuri. Sí, adelante. Hola, buen día. Eh, Nicolás, en este caso, eh, para la región, los servidores autoritativos ya lo tienen implementado o están en un proceso en esto? Muy buena pregunta. Eh, los eso depende, obviamente depende de los administradores de los autoritativos que tengan o no firmados sus registros. Sí, a veces se dice firmar la zona. En realidad lo que se firma no es la zona, lo que se firma es cada registro que está dentro de la zona. O sea, hay una firma para cada uno de los registros que están dentro de la zona. No es una única firma para todo. Eso depende del administrador de de de la zona. Hay DSSC todavía todavía hay un largo camino por recorrer para que esté ampliamente este desplegado, digamos. Sí. Si bien uno dice, "Ah, pero me dijiste que desde el 2010 está funcionando, hace 15 años que está operando y todavía falta mucho para que todo esté todo tenga todos los servidores de NS tengan desplegado en SE." Sí, falta bastante, digamos. Por eso hacemos estos estos esfuerzos. Eh, si lo comparamos con el despliegue IP versión 6, por ejemplo, no tiene nada que ver con el DNS, pero pero también este IP versión 6 tiene no tiene 15, tiene 30 años eh operando y y y todavía falta muchísimo para que todas las redes soporten IP versión 6, ¿no? Este porque todo en internet, todos los cambios este son lentos, digamos, ¿no? En general, este, por desgracia, mucha gente reacciona, digamos, implementa estas cosas después de que le pasa algo malo, digamos, en el caso de NCSC, después de que reciben y son objetos de algún tipo de ataque que DNCS resuelve, dicen, "Uy, está, sí, deberíamos este implementar DNCs, sí deberías haberlo implementado antes para prevenir el ataque, pero bueno, nada, si sirve este si sirve de incentivo el el el justamente ser objeto de de alguna vulnerabilidad y por eso reaccionar, implementarlo, fantástico, digamos. Sí, lo que sucede en la realidad es que muchas organizaciones no visualizan eh correctamente las ventajas de implementar estas cosas, digamos, porque tienen costos operativos, porque hay que formar a la gente, capacitar a la gente. Si estoy firmando este un servidor autoritativo, tengo que administrar clave pública y clave privada, tengo que tener un mecanismo para mantener secreta y segura la clave privada, tengo que mantener un mecanismo para para utilizarla y firmar cada cada vez que hay un cambio en la en la zona. Todo eso es automatizable. Hoy en día existe montones de software que lo hacen totalmente automatizado, digamos. Sí. Este, pero bueno, de nuevo, muchas organizaciones no visualizan las ventajas de de de tenerlo. Es como el seguro médico, ¿no? Dice, "Bueno, ¿para qué voy a pagar miles de pesos todos los meses para toda mi familia por un seguro médico que utilizo una vez por año, no?" Y bueno, pero el seguro médico en realidad no es la forma de evaluar un seguro médico, a mi criterio, no es cada cuánto lo utilizo, es lo mejor que te puede pasar es pagar miles de pesos por un seguro médico y no utilizarlo nunca en tu vida, digamos, ¿no? Pero el día que lo tengas que utilizar, si no lo tenés, ahí estamos en problema. Esto es igual. La seguridad en general es igual. Es decir, uno hace una inversión y lo mejor que le puede pasar es que nunca pase nada. Sí, pero no es un no es tirar dinero, no es un gasto, es una inversión. porque uno está invirtiendo en justamente en si alguna vez me pasa algo, bueno, tengo este mecanismo que lo va a mitigar o me lo va a evitar, digamos. Entonces, y además es muy difícil medir lo los ataques que uno dejó de de tener porque tenía las medidas de seguridad, ¿no? Es decir, ¿cuántos ataques evitó el firewall que tenés instalado en tu organización? No lo sé. Yo puedo medir más o menos los ataques que son grandes y puedo decir, "Bueno, este firewall eh retuvo mitigó este, no sé, 10 ataques en el último mes. En realidad no mitigó 10. Si te detectó 10, mitigó 5,000 ataques. Entonces, si vos no lo tenés, justamente lo que estás dejando de es mitigar, está dejando de mitigar 5,000 ataques y si lo tenés, de repente solamente reconocés 10 de esos 5,000. No, esto es igual. Entonces, de nuevo, el esfuerzo que hacemos es justamente tratar de generar esta esta conciencia de, bueno, esto en realidad el es preventivo, es justamente es el el el digamos si vos sos objeto de un ataque y tu servicio de DNS deja de funcionar, es muy probable que todos tus servicios digitales o todos tus servicios en internet dejen de funcionar. Entonces, el lucro cesante que tenés, el impacto sobre la imagen que tenés, ¿no? Si sos un banco y te atacan y te ganan acceso a todas las cuentas porque alguien te secuestró un servidor de NS o te logró meter información falsa y la gente fue a un servidor de un atacante pensando que era el servidor del banco y le reveló las credenciales para acceder a la cuenta bancaria y después el atacante le vació la cuenta bancaria a dos personas de 1 millón de personas de un banco. el banco pierde un montón de de de dinero que no es fácil de medir, digamos, porque la pérdida de imagen no es fácil de medir. Sí. Entonces, de nuevo, a veces es difícil de visualizar, pero bueno, está en nosotros el en los técnicos, digamos, el transmitir a las jerarquías, este, ¿por qué es necesario desplegar esto? ¿Por qué es necesario capacitarse? Y por qué es necesario invertir en estas medidas de seguridad, digamos. Sí. Entonces, eh un poco un poco viene viene por por por por ese lado. Sí, todavía hay un largo camino por recor para que tengan una idea, el el dominio comom, el GTLD, el dominio de primer nivel com es el el dominio por lejos que tiene más subdominios en todo en todo el sistema de nombre de dominio. El COM es el que tiene más su dominio, o sea, la mayoría, dicho de otra manera, la mayoría de los nombres de dominio terminan en punto comom. Sí, solamente un cco menos de un 5% de los servidores de NS eh de segundo nivel por debajo del del COM este tienen su registro firmado, o sea, tienen desplegado DNSC. dicho de otra manera, o sea, el COM sí soporta DSC, pero por abajo del punto comom, los dominios, no sé, nicolas.com o lo que sea, comom, solamente un 5% de todos esos, menos un 5% realmente más cerca del 4,5% hoy en día está con DNS SEC desplegado y ese es el que tiene más subdominio. Imagínense que falta todavía un un un largo camino por recorrer, pero desde otro de lado positivo, por ejemplo, en el caso de Latinoamérica y el Caribe, sí hay un montón de eh de de CCTDs, de nombres de dominios de de primer nivel asociados a código de país que ya soportan DNS, digamos. Sí. Este, eso quiere decir que cualquiera que registre un dominio por abajo del dominio de código de país ya puede implementar en ese seco. Sí, porque ahora vamos a ver justamente esto que está faltando ver ahora es lo que no lo que nos va a decir que para que un administrador, un servidor de nombres de dominio autoritativo pueda desplegar de NCSC, toda la cadena que está por encima hasta la raíz tiene que tener desplegado de NCS. O sea, si si si mi padre o madre no tiene el DNS no tiene desplegado DSC, yo no puedo desplegar DNSC. Sí, la raíz tiene implementado DNSC desde el año 2010, que fue cuando empezó el protocolo, cuando se implementó por primera vez el protocolo en el año 2010. los este los eh nombres de dominios genéricos de primer nivel, el COM, el ORG, el EDU, todos los de primer nivel genéricos, eh tienen obligación contractual por el contrato que tienen con ICAN de desplegar DNC, o sea, que todos tienen DNCSC implementado, todos soportan DNSC, los de código de país no tienen obligaciones contractuales. Entonces, bueno, hay muchos de ellos que lo tienen implementado, otros que todavía no tienen implementado DCSC deberían implementarlo. Eso es algo que que ustedes como parte de de las organizaciones del Estado, digamos, pueden incentivar decir, bueno, el el el en el caso de Chile eh ya está desplegado a nivel del punto cl, pero no es el caso de todos los países de Latinoamérica y del Caribe. Entonces, bueno, ahí este la la las los usuarios y también los gobiernos pueden invitar a justamente a tener desplegado DNC en el en el en el dominio de de código de país, porque si no, por ejemplo, un dominio, no sé, ehgob.cl no puede eh desplegar DNSC hasta que CL no tenga desplegado DC. De nuevo, Chile es un caso particular porque el los administradores del punto CL te lo hacen muy bien y es uno de los pioneros en muchas cosas en nuestra región. O sea, que no es un ejemplo bueno para poner ejemplos malos, digamos, sino que todo lo contrario. Pero sí hay muchos países que no son este buen ejemplo y que ni siquiera tienen desplegado todavía de NCS en su en su en su dominio de nivel superior asociado al código país. Está un poco por ahí va la respuesta. resumen de nuevo, todavía hay un largo camino por recorrer, pero bueno, justamente es importante visualizar la necesidad de que de que todos desplieguen este de NSC, porque además este hay como un temor ahí, sobre todo la parte de administrar este de NCS a nivel de un servidor autoativo y y el 99% de los errores como consecuencia de desplegar de sex son humanos. son por procedimientos mal hechos, mal escritos o no o carente procedimiento. Por ejemplo, despliego de NCSC, pero no escribo bien los procedimientos para hacer la operación de eso. Entonces, cuando uno no escribe los procedimientos y tiene un grupo de operaciones que tiene muchas personas, bueno, ahí es fácil que uno conozca todo bien, pero que el otro no tenga ni idea de lo que estoy hablando. Entonces, con una mala operación o con una mala este respuesta o procedimiento se puede cometer un error. La mayoría de los problemas con DC son consecuencia de errores humanos y no de fallas de protocolo, ni siquiera fallas de hardware ni de software. Es la mayoría son problemas humanos, errores de operación. Sí. Eh, porque es fácil cometer error de operación cuando uno no tiene las cosas bien procedimentadas. Sí, aunque parezca mentira. y ocurren a todos los niveles. No importa si estamos hablando de una organización pequeña o de una organización monstruosamente grande. Hay ejemplos, muchísimos ejemplos de todos los casos, digamos. Sí. Bien, ¿qué es lo que está faltando todo esto? Cuando el servidor autoritativo envía al servidor recursivo la respuesta de de DNS firmada, le envía la clave pública, dijimos, envía todo y el servidor recursivo puede agarrar y verificar esa firma. Lo que no estamos diciendo acá es, bueno, si el servidor autoritativo le envía la clave pública con la información y la firma, hay un problema, ¿no? Porque alguien podría preguntarse, ¿qué pasa si un atacante captura la información, la modifica, modifica también la firma, genera una firma nueva con una clave privada de él y pone su clave pública ahí? Al servidor recursivo le va a llegar la información modificada, le va a llegar la firma modificada que valida con esa información porque la clave pública que puso el atacante es la de él, o sea, que le llega todo y va a validar todo y el servidor va a decir, "Ah, esto valida, perfecto." Y era todo falso. Entonces, no sirve para nada todo lo que dijimos, ¿no? ¿Por qué? Porque acá el problema se reduce a que el servidor recursivo antes de realizar la validación de la firma tiene que estar seguro que la clave pública es la correcta, que la clave pública no fue modificada, que la clave pública es la clave pública que envió en la autoridad para esa información. ¿Cómo se hace la verificación de la clave pública? La verificación de la clave pública la tiene que hacer de nuevo el servidor recursivo antes de validar la firma. Entonces, el video recursivo recibe todo. Recibe la información, la firma, la clave pública. Antes de validar, antes de hacer el procedimiento que que dijimos para verificar la firma, va a agarrar la clave pública y le va a preguntar al padre del dominio que del cual recibió la respuesta. O sea, si el servidor autoritativo que me está enviando la información firmada es el servidor autoritativo de nicolas.com, ¿sí? El servidor recursivo le va a ir a preguntar al padre nicolas.com. ¿Quién es el padre deenicolas.com? El puncom, ¿verdad? El servidor recursivo a preguntar al padre nicolas.com, ¿esta clave pública que me mandó tu hijo es la correcta o o está modificada? ¿Qué hace el padre? El padre le va a contestar, básicamente le va a contestar sí o no y va a firmar la respuesta con su clave privada. Entonces, ahora tengo el padre me envía la respuesta diciéndome, "Sí, esa firma es válida, es la de es la de es la de nicolas.com, la de mi hijo, pero y no y además te la firmo con mi con mi firma electrónica, te mando la respuesta firmada." Está. Entonces, ahora el servidor recursivo recibe una respuesta del padre, ¿sí? Que está firmada por el padre que dice que la firma de del la clave pública del hijo es correcta. Pero, ¿cuál es el problema ahora? El problema es que tengo que confiar en la firma del padre. ¿Cómo sé que no falsificaron también la firma del padre? Sí. Y empieza como una especie de de de cascada o reacción en cadena, digamos, en la cual ahora el servidor recursivo tiene que ir al padre del padre y preguntarle lo mismo. La clave pública del de tu hijo es la correcta. Sí. Y acá va firmada. Entonces sube un nivel más. Y así sube hasta dónde? Hasta que lleggaue a la raíz. Cuando el servidor recursivo llega a la raíz, le va a preguntar la raíz, ¿la firma de del del punto comom es válida? La raíz le va a decir sí es válida y la firma con la clave privada de la raíz. Y ahora recibo una respuesta de la raíz con la clave pública de la raíz y tengo un problema porque cómo verifico la clave pública de la raíz si la raíz no tiene padre. Sí. Entonces voy recorriendo eso, esa cadena hasta llegar a la raíz. Sí, recibiendo respuestas firmadas y validando con los padres las claves públicas hasta que llego a la raíz. Eso se llama cadena de confianza, ¿sí? de de DNCS. Entonces, ahora todo el problema se reduce a estar seguro que la clave pública de la raíz es la correcta, porque la raíz no tiene padre, no tengo a quien preguntarle. Sí, para eso no lo vamos a ver hoy. Para eso se diseñó un protocolo que se llama protocolo de firma de la raíz TDNS, ¿sí? En el cual la clave pública asociada a la firma de la raíz de DNS, ¿sí?, que se generó por primera vez en el año 2010. La clave pública se disponibiliza a toda la comunidad de internet a través de unos de unos servicios, unos servidores especificados para eso. Sí, las todas las ceremonias de firma de la raíz eh se se filman y se hace streaming de eso en tiempo real. O sea, que cualquiera puede este atender remotamente esas ceremonias. También hay lo que se llaman testigos de la comunidad que asisten a esa ceremonia de firma de la raíz, ¿sí?, que se realizan este cuatro veces al año. Este cuatro veces al año se se realizan esas esas ceremonias para para firmar la la raíz de del DNS. Y la clave pública en realidad no se modifica en esa ceremonia. La clave pública es siempre la misma. Se publica y lo que uno debería hacer cuando instala un servidor este recursivo por primera vez, ¿sí? el servidor recursivo, eh, cuando cuando uno lo lo pone en funcionamiento, digamos, sí, va a acceder a estos servidores y se va a descargar la clave pública de la raíz de DNS, ya esa clave pública de la raíz D que se que se descarga el servidor recursivo, hay que verificarla una sola vez. En realidad, lo mínimo es una sola vez cuando se instala el servidor. ¿Por qué hay que verificarla? Porque si justo alguien logró hacer un ataque en ese momento y logró inyectarme una firma falsa de la raíz de DNS, todo el protocolo de NSC para mí está vulnerado. ¿Sí? Entonces es crítico que la firma, la clave pública de la raíz de DNS que tiene almacenada el servidor recursivo en su memoria sea la correcta. ¿Cómo se hace eso? El administrador cuando instala un servidor recursivo y lo pone en operación agarra la clave pública que que obtuvo de de de la raíz del DNS. y la compara con la clave pública que está publicada en en varios lugares, digamos. Sí, comparas la clave. Si la clave coincide, está puedes estar tranquilo de que es la correcta y de ahí en más el sistema va a funcionar en forma automatizada y no hay que realizar ningún ningún ningún chequeo adicional. O sea, que por lo menos una vez cuando se pone en funcionamiento por primera vez el servidor recursivo, hay que verificar que la clave pública sea la correcta, ¿sí? Para la raíz de DNS. Luego de ahí, como la clave pública para RNC ya está verificada manualmente, todo el resto de la cadena de confianza este está asegurada, digamos. Sí. Entonces, la cadena de confianza de DNS es justamente lo que garantiza la este la la veracidad de la clave pública que recibo de cada uno de los servidores autoritativos. Bien. Entonces, básicamente, ¿cómo se implementa todo esto? Bueno, eh lo que se hace, lo que se hizo cuando se diseñó el protocolo de NSC es se le agregaron a el protocolo de NSSC se agregaron registros de NS, se crearon básicamente tres nuevos registros de DNS, ¿sí? Para poder implementar DNS. Lo que dijimos es que los servidores autoritativos tienen que enviar al servidor recursivo la información como enviaban siempre. Tienen que poder enviar la firma, tienen que poder enviar la clave pública, ¿sí? Y tienen que poder realizar esta este chequeo de cadena de confianza. está. Entonces, la firma está asociada a cada registro. O sea, que para cada registro tiene que haber una firma. ¿Sí? ¿Cómo se coloca la firma en el archivo de zona asociada a cada registro? Bueno, se coloca en un registro nuevo que se crea cuando se crea DNSC que se llama registro RR SIG. El registro RR SIG es el registro que se utiliza para almacenar la firma digital de cualquier otro registro de DNS. Entonces, cuando se firma, cuando se implementa DNSC, que es un servidor autoritativo, a cada uno de los registros DNS que yo tengo en la zona, se le asocia un registro RRSI y en ese registro RSI se coloca la firma de cada uno de esos registros. Esa es la forma de colocar la firma para cada registro en el DNS. ¿Okay? Entonces, registro de RSI es un registro nuevo que agrega DNSC para poder almacenar las firmas. Otro registro, el registro DNS Qy. El registro DNS Q es el registro que se crea para almacenar en el archivo de zona la clave pública. Dijimos que cada vez que se envíe una respuesta hay que enviar también la clave pública. La clave pública se almacena en el archivo de zona en el registro de NSX y por lo menos tiene que haber un registro de NSX por todo para cada archivo de zona. Este no es un registro para cada registro DNS que tenga mi archivo de zona, es uno solo para todo el archivo de zona. Mínimo un registro DNSX aquí con un la clave pública para todo el archivo de zona. Ya. Y por último está el registro DS. El registro DS es el que se llama registro de delegación y es justamente un registro que no se almacena en el archivo de zona que estoy implementando de NSC, sino que es un registro que se crea en el padre. Este registro DS es el registro que se crea en el padre con la clave pública del hijo firmada por el padre y es el registro que consulta el servidor recursivo y que va consultando cada registro de S en secuencia hasta llegar a la raíz. ¿Sí? Entonces, el registro DS se utiliza para eso, para asegurar la cadena de confianza de la clave pública. El registro DNSQ se utiliza para almacenar la clave pública y el registro RRSI para almacenar la firma. Y hay un registro RRS para cada registro DNS que yo tenga en mi archivo de SU. Con esos tres nuevos registros es que se implementa DNSC en un servidor recursivo, en un servidor autoativo, perdón. Sí. Y en el servidor recursivo simplemente hay que habilitar validación de NCS. Y bueno, así es como funciona y implementa este DNSC. preguntas hasta acá, ¿no? Bien, todavía nos quedan unos minutos y les quería mostrar si no hay preguntas o comentarios. Rodrigo, no sé si hay alguna pregunta o comentario en el en el chat. Bien, supongo que no. Quería mostrarles algunas estadísticas que tengo que que les puse acá para Chile. Este este sitio eh que está aquí abajo está stats.labs.net. E épnica es el registro de de direcciones para para la región de de Asia del Pacífico. Es el par de LNIC. LCNIC es el registro de direcciones este para Latinoamérica del Caribe, o sea, cualquier organización que requiera direcciones IP o número de sistema autónomo se los va a solicitar a este registro regional. eh estos registros regionales que son cinco en el mundo, este, básicamente también hacen otras actividades de de de investigación y desarrollo y generan herramientas para la para la comunidad de operadores de de internet, etcétera, etcétera. Sí, en particular esto es una herramienta que que generó que diseñó la gente de de ApNIC para visualizar y llevar una estadística sobre el nivel de despliegue global de validación de NCS a nivel de servidores recursivos. Sí. No a nivel de servidores autoritativos. No es cuántos servidores autoritativos tienen sus zonas firmadas y con DNC desplegado, sino cuántos servidores recursivos tienen habilitado validación. O sea, ¿cuántos servidores recursivos de todos los que hay son capaces de validar una firma de NSC? ¿Sí? Y uno puede navegar este mapa. Si se fijan, si yo acá me paré arriba de Chile y básica este esta foto la tomé hoy, o sea, que hoy en día según esta estadística solamente el 8% de las consultas DNS que resuelven los servidores recursivos que están ubicados en las distintas organizaciones que administran servidores recursivos en Chile, solamente el 8% de esas consultas que que resuelven los servidores recursivos están validadas con DNSC. ¿Sí? O sea, prácticamente no hay validación de NCSC en Chile. Sí, un 8% es casi nada, prácticamente cero. Sí. Y acá acá hay una lista que también se se puede se puede ir navegando a través de este sitio. Si uno pincha arriba del país, obtiene más información más detallada. Esto es un un una gráfica estadística del 2014 al 2025, digamos, de cómo se fue cómo fue variando el despliegue de validación de NCSC en el país. Si se fijan, básicamente se mantuvo casi casi que plano este desde el 2014. Incluso en algunos casos se ve que había alguien que estaba haciendo validación y dejó de hacerla, digamos. Eh, este y y y se puede también navegar más abajo y tienen una lista. Yo acá saqué una foto parcial de toda la lista de unas una una estadística que se hace haciendo unas pruebas con los diferentes operadores en el país. Si se fijan acá la última columna que dice número de muestras, samples, ¿sí? Yo lo ordené de mayor a menor. Cuanto más muestras tiene, quiere decir eso está directamente vinculado con la cuota de mercado. Es decir, cuanto más grande es el operador, cuanto más clientes tiene un operador en un país, más muestras se obtienen. ¿Sí? Entonces, en este caso, aparentemente, Telefónica Chile es el operador más grande de Chile en cantidad de clientes, digamos. Sí. Después le sigue Chile, después le sigue BTR, banda ancha y otros. Sí. Y si se fijan acá en la primer columna que dice DNCS validates, ¿sí? ¿Cuántas de esas consultas que se utilizaron a modo de testing, ¿sí? de 23,225 muestras, ¿sí? Solamente el 1% está validado con NCC. Cuando dice 1%, cuando dice 2%, cuando dice 10%, es lo mismo que no tener validación activado, está es como si fuera cero. Esto, ¿qué quiere decir? que los prácticamente los 1 2 3 4 5 6 los seis primeros los seis este operadores más grandes que que nuclean a más del 99% de todos los clientes eh de con acceso a internet en Chile no tiene no utiliza un servidor recursivo que tenga DNSCS validación de NCS que habilitado. Entonces acá aunque todos los servidores autoritativos tuvieran DNSC implementado, aunque ustedes a nivel de gobierno implementen DNSC en todos los servidores, como los servidores recursivos no hacen validación, nadie está validando DSC. ¿Sí? Entonces es importante justamente trabajar con estos operadores para que implementen validación de NSC, para que activen validación de NSC en sus servidores recursivos. La razón por la que a veces se ven números diferentes a cero, este 4% 1% puede ser porque algunos clientes de esos operadores en vez de utilizar el servidor recursivo del operador utilizan algún servidor recursivo público que tiene habilitado validación. Entonces, hay unos porcentajes pequeños de validación, pero ya les digo, con valores menores al yo diría al 15 o 20% este eh eso quiere decir que no están que no tienen validación encendida en ninguno de sus servidores este eh recursivos. Algunos operadores, en algunos casos sucede que son operadores de móvil y de y de fija, internet fija internet móvil y para para uno de los utilizan por algún motivo diferentes eh servidores recursivos de DNS para resolver consultas de DNS y algunos ha pas se ven casos, por ejemplo, de operadores que tienen para los servicios eh móviles habilitado de NSC y para los servicios fijos no habilitado de NSC, validación de NSC, ¿no? Este es curioso eso y y tiene muchas puede tener muchas explicaciones. Si ustedes instalan hoy cualquier servidor de todos los sabores de servidores de todos los servidores recursivos BNS que ustedes pueden utilizar, cualquiera que ustedes instalen hoy, por defecto tiene encendido validación de NC, o sea, usted no tienen que hacer nada, instalan el servidor y ya empieza a validar con DCS. Es más, si no quieren validar NC, tienen que a propósito deshabilitarlo. O sea, cualquiera que hoy en día sin conocer de NSC instale un servidor recursivo o bien instalado un servidor recursivo en los últimos 7 8 años, tiene validación de NSC automática por defecto. ¿Sí? ¿Por qué todavía hay muchos servidores recursivos que no tienen validación de SEC? Y bueno, porque originalmente cuando empezaron con esto de los servidores recursivos no tenían DNC habilitado, han ido, muchos de ellos han ido actualizando, tienen sus servidores actualizados, pero si uno lo tenía deshabilitado, cuando uno actualiza la versión del servidor, eso no se activa solo, hay que activarlo manualmente, digamos. Entonces, y otros eligen tenerlo por algún motivo que desconozco, eligen tenerlo este desactivado, digamos, sí que pueden ser motivos fundados, digamos, este, pero en realidad hoy a nivel de servidor recursivo, eh la la la potencialidad de problemas que pueden aparecer por tener habilitado este validación de NC es casi cero, digamos, y el costo operativo de implementar validación de NSC es muy muy bajo, digamos. Sí. Y el la prevención de de de ataques es bastante alta porque, por ejemplo, todos esos ataques de eh envenenamiento de calé, todos los ataques de, por ejemplo, todos los fishing esos que que pretenden que uno cambie su su contraseña del banco y y termina uno accediendo a un servidor que no es el original del banco, sino que es el servidor de de un atacante, etcétera, etcétera. Todo eso se puede prevenir si está correctamente desplegado de NS SEC. Entonces, la la la seguridad adicional que provee DSC es supera enorme enormemente los los costos operativos. Y ya les digo, a nivel de validación el costo operativo es muy bajo. A nivel de despliegue de NCC, que en un servidor autoritativo ya tiene un costo operativo un poquito más alto, pero tampoco es algo imposible, digamos, ni mucho menos. es bueno capacitar al personal que lo opera como como en todos los casos como para cualquier operación de cualquier sistema y y luego de este planificar el despliegue, desplegarlo y después mantenerlo operativo. Por supuesto que no es poner las cosas al funcionario olvidarse, hay que hacer monitoreo, pero tampoco es exclusivo de DNS. monitoreo hay que hacer de cualquier sistema que uno esté operando. Hay que hay que hay que hacer análisis de seguridad cada tanto, pero eso también nada nuevo ni nada que sea exclusivo de DNS ni de DNSC. Es algo que hay que hacer con todos los con todos los sistemas. Sí. Y bueno, hasta acá un poco ahí les dejo un una unas direcciones que pueden pueden probar. Este, ustedes escriben, abren un navegador, escriben cualquiera de estas dos y lo que hace es hace una prueba a ver si el servidor recursivo que ustedes están utilizando tiene habilitado o no validación de NSC. Y si lo prueban ahora se van a sorprender, o sea, apuesta que el 90% de de de de ustedes va a obtener una respuesta negativa, que les va a decir, "No, no tienen habilitado validación. El servidor recursivo que están utilizando no tiene habilitados validación de NSC, a menos que justo todos estén en la oficina y toda la red de de la oficina este tenga justo el servidor recursivo que que tiene que tiene validación. Este, es probable que desde sus casas, es casi seguro, según estas estadísticas que están acá, si tienen alguno de estos proveedores, es casi seguro que no que no estén validando validando DNS con el servidor recursivo que están utilizando. Sí. Bueno, un poco hasta acá la presentación. Espero que que les haya servido por lo menos para para entender de qué se trata y cómo funciona de NCSC, digamos. Este es una presentación un poco de alto nivel, pero tampoco tampoco está pensada solamente para para exclusiva para técnicos. Entonces, la idea es un poco que que todos, sin importar técnicos o no técnicos, este comprendan cómo funciona el protocolo y bueno, y sean eh eventualmente más conscientes de por qué la necesidad de desplegar estas estas estas extensiones de seguridad de NSC adicionales a a la operación de cualquier servidor de NES, ya sea recursivo activando validación o en el caso de un autoritativo este firmando los registros de de la zona que que administra. preguntas, comentarios. Hay algunos comentarios en el chat. Si los que A ver si sí si los quieres leer, Rodrigo. O a leo uno acá de Jorge dice, "Si tengo un dominio que tiene DNS internos y DNS público también posee. También cont interno sale por una plataforma y público sale por otra. entiendo que a ver, o, o sea, el lo que estás escribiendo, Jorge, es es está es un caso muy particular y y de relativa complejidad, digamos, eh cómo se pueden prevenir impactos operativos y y qué riesgos puedo prever, o sea, la implementación de DNC SEC a nivel de recursivo, que es básicamente el servicio que que vos vas a vas a utilizar más cuando estás resolviendo nombres de dominio. Sí. Este eh sobre todo cuando utilizas servidores de NS público, servidores de NS interno, etcétera, etcétera, el el impacto es mínimo, digamos. O sea, uno ahí decide este dónde si uno administra el servidor DNS recursivo, por ejemplo, hay muchas organizaciones que internamente para todos los dispositivos internos de la organización le le asignan un servidor recursivo administrado por la misma organización. Sí, muchos sistemas de controladores de seguridad, etcétera, etcétera, ya levantan automáticamente un servidor recursivo para todos los para todos los servicios internos. Por ejemplo, Active Directory de Microsoft es un típico caso de que de que tiene un servidor este bueno, autoritativo para los dominios internos y además este un servidor recursivo este cuando uno utiliza un proxy de de de DNS, por ejemplo, también en general este trata de resolver todos los dominios con un servidor recursivo, un servidor recursivo propio. quiere protegerse este y tener cierto control sobre sobre el tráfico de de DNS, activar validación DNSC ahí es bastante importante y no tiene un impacto operativo, digamos. No hay mayores problemas operativos. Por supuesto, si yo estoy validando DSC y el que firmó, ¿sí? Es un típico típico error operativo de de de DNS. Sí. Alguien agarra a nivel de un servidor autoativo, ¿sí? errores operativos en a nivel de validación de recursivos son muy muy pocos y y no vale la pena ni ni ni ni mencionarlos porque no no tiene un impacto operativo grande a nivel de de seguridad autoritativo. Sí, hay personas, por ejemplo, cuando cuando establecen sus políticas de de de de DNCS y y generan la clave pública y la clave privada, cuando no generan la clave, ¿sí? Muchos de ellos eh le ponen un tiempo de expiración de la clave. O sea, esta clave es válida hasta tal fecha. Sí. No, ese es eh típica reacción de de alguien que administra sistemas de de de seguridad de cualquier tipo, ¿no? El tema de que las contraseñas no son válidas para siempre, sino que expiran, entonces hay que cambiarlas. Está eso que es bueno, relativamente bueno para una contraseña, aunque lo podíamos dejar para otra charla. Este, en el caso de NSC no es bueno. En el caso de NCSC, originalmente se recomendaba este rotar las claves cada tanto, etcétera, etcétera, ponerles fecha de expiración a la a las a la a las claves eh privada y pública. Hoy en día la recomendación es totalmente lo contrario. Es la recomendación y la buena práctica es nunca le pongan fecha de expiración a un par de clave pública y privada. ¿Por qué? Eso quiere decir que nunca la voy a rotar, ¿no? La política de rotación de claves ustedes la pueden definir como ustedes más le satisfaga, ¿sí? Y las claves las pueden rotar, pero ¿por qué no ponerle expiración a una clave? O sea, si yo no la quiero rotar, la clave va a seguir siendo válida para siempre. Eso es importante. ¿Por qué? Porque uno de los errores más comunes, ¿sí? Irónicamente, uno de los errores más comunes es olvidarse de renovar la clave. Los que le ponen fecha de expiración se olvidan de renovar la clave. La clave expira, DNSC deja de funcionar. Los servidores recursivos van a validar, van a tratar seguir validando la lo que reciben, pero lo que reciben, la firma ya no es más válida. Una firma no válida es lo mismo que una firma falsa. Entonces, el servidor recursivo la la identifica como no válida y descarta la información y no resuelve el DNS. No resuelve porque hay un error en el servidor recursivo, no. El servidor recursivo está haciendo bien su trabajo, está validando y no valida. No resuelve porque hay un error en el servidor autoritativo. No, no resuelve porque alguien se olvidó, le puso esta clave a partir de hoy no es más válida y no la renovó, no creó, no generó una nueva. Entonces, el hecho de no ponerle fecha de expiración, si ustedes por algún motivo tienen que posponer el el el la renovación, no pasa nada porque la clave va a seguir siendo válida. Sí, ustedes la renuevan cuando quieran. Si la política de ustedes es renovarla cada 6 meses, perfecto, pero no le pongan fecha de aspiración porque si un día no pueden renovarla, bueno, tienen más tiempo. Sí, eso, por ejemplo, durante la pandemia pasó bastante porque la pandemia hizo difícil o imposible que mucha gente se trasladara y muchos protocolos de rotación de de claves implicaban que la gente fuera físicamente a un data center, a un lugar y generara la nueva clave y y todo eso. Entonces, como las claves tenían vencimiento y no podían ir a a a rotarlas, expiraron y cuando expiraron dejan de funcionar, deja resolver el DNS porque dejan de ser válidos. Entonces, esa es la razón por la cual, por ejemplo, no se recomienda ponerle fecha de expiración a las a las claves. Igual ustedes las pueden rotar cuando quieran, digamos, está esas cosas que parecen este triviales no lo son, digamos, a nivel operativo. Entonces, bueno, este de nuevo, los errores se pueden evitar primero documentando los procedimientos, procedimientos bien establecidos y bien documentados, que todos los conozcan, capacitando a a las personas que van a operar las redes y monitoreando, ¿no? es los servicios no se ponen a operar y se dejan ahí y se sorprenderían de la cantidad de servidores en ese que tienen más de 15 años sin ni siquiera un parche de seguridad. Sí. Bueno, la cantidad de vulnerabilidades que tiene son todas las vulnerabilidades de hace 15 años hasta ahora. Imagínense, son casi todas las que hay. Este, se sorprendería la cantidad de servidores que no son actualizados porque el servicio de DNS, como es algo que uno lo pone a funcionar, funciona y queda ahí, se olvidan. Entonces, monitorear, monitorizar, perdón, este, procedimentar bien y escribir los procedimientos y que todos los conozcan y capacitar capacitar a la al al personal. Con esas tres cosas básicas, este, ya se resuelven el 99% de los problemas, digamos, no solo los de DNS, de todos los problemas operativos, pero porque ahí somos es donde las personas fallamos más, digamos. Sí. Este y bueno, y después sí, después hay problemas que pueden surgir porque las cosas fallan, los hardware, el hardware se rompe o o soy objeto de un ataque que no pude mitigar y bueno y tengo que tengo que actuar en consecuencia y resolverlo, pero bueno, eso la idea es que sean los menos esos casos y cuanto más mecanismo de seguridad como de NSSC tenga yo implementado, más protegido voy a estar contra más cantidad de de tipos de ataque y de vectores de ataque y de vulnerabilidades. Entonces, la la recomendación es siempre desplegar estas estas cosas de nuevo, no es implementarlo y nada más, sino que hay que tener en cuenta todas estas consideraciones. ¿Sí? Y creo que no hay este no hay más este no hay más no hay más preguntas ahí en el en el en el chat. No sé, en el chat creo que no hay más preguntas. Este, bueno, si no hay más preguntas un poco hasta acá era la la presentación. Estamos apenas 2 minutos pasados de la de la de la de la hora estipulada. Espero que les que les haya servido, que les haya parecido interesante, por lo menos. Y y nada, nos vemos en la en la en la próxima en la próxima sesión. Sí, Rodrigo, te devuelvo el la palabra para ser. Eh, no, solamente que muchísimas gracias a todos. Acá les voy a compartir en el chat eh mi correo y cualquier pregunta eh lo que necesitan, estamos a la orden. Muchas gracias a todos y obviamente no no quiero eh terminar sin agradecer eh a ans por hacer posible este tipo de capacitaciones. Gracias y que tengan un buen día. Que tengan un excelente día a todos. Chao. Chao. Gracias. Adiós.

ANCI ICANN | Charla buenas prácticas DNSSCEC

Hacer Pregunta

Respuesta:

Historial de Preguntas

Análisis

RESUMEN

Introducción y Contexto

Vulnerabilidades y el Rol de DNSSCEC

Funcionamiento de DNSSCEC

Implementación de DNSSCEC

Consideraciones y Estadísticas

Recomendaciones

Conclusión

Sabiduría

RESUMEN

IDEAS

INSIGHTS

CITAS

HÁBITOS

HECHOS

REFERENCIAS

CONCLUSIÓN EN UNA FRASE

RECOMENDACIONES

ANCI ICANN | Charla buenas prácticas DNSSCEC

Hacer Pregunta

Respuesta:

Historial de Preguntas

Análisis

RESUMEN

Introducción y Contexto

Vulnerabilidades y el Rol de DNSSCEC

Funcionamiento de DNSSCEC

Implementación de DNSSCEC

Consideraciones y Estadísticas

Recomendaciones

Conclusión

Sabiduría

RESUMEN

IDEAS

INSIGHTS

CITAS

HÁBITOS

HECHOS

REFERENCIAS

CONCLUSIÓN EN UNA FRASE

RECOMENDACIONES

Transcripción

Otros