La Gran Descentralización (III): todo lo que no sabes sobre DNS

En un lugar de la 192.168.1.Mancha, de cuyo nombre no quiero acordarme, no ha mucho tiempo que vivía una red inhóspita donde todo estaba indicado por números en vez de por nombres.

Nos sumergimos en las complejidades del Sistema de Nombres de Dominio (DNS), desde el punto de vista de la seguridad, la privacidad y su hipotética descentralización completa.

Exploramos los conceptos básicos del DNS, desglosando cómo funciona para traducir los nombres de dominio en direcciones IP, y cómo este proceso es esencial para la navegación web y la comunicación en línea.

También explicamos los diferentes elementos técnicos del DNS, desde los registros básicos hasta la jerarquía de servidores DNS, los servidores autoritativos y otros componentes colaboran para garantizar un uso seguro de Internet.

• Sistema de nombres de dominio - Wikipedia, la enciclopedia libre
• Blog de Akamai | ¿Qué es DNSSEC y cómo funciona?
• Server Name Indication - Wikipedia, la enciclopedia libre
• Understand Encrypted Client Hello (ECH) | Firefox Help
• Anexo:Tipos de registros DNS - Wikipedia, la enciclopedia libre
• DNSCurve - Wikipedia, la enciclopedia libre
• NAPTR record - Wikipedia
• Unstoppable Domains — web3 domains for everyone
• certificados raiz - Buscar con Google
• 1030 - ¿Qué es y para qué sirve un Certificado Raíz? - Sede
• Certificado raíz - Wikipedia, la enciclopedia libre
• Ataques DNS | ¿Cómo funcionan? | Cloudflare

Don Tomás es un programa está presentado por Ramón Medrano (SRE de Google en Zurich) y Álex Barredo (creador de mixx.io)

En cada episodio explican con detalle los protocolos, estándares, plataformas y programas que hacen funcionar al mundo.

Para suscribirte y escuchar más episodios, visita https://cuonda.com/don-tomas

---

Síguenos en https://ublog.tech/@r y https://mastodon.social/@barredo 

Puedes contactar por correo en alex@barredo.es o m3drano@gmail.com 

Bienvenidos a un nuevo episodio de Don Tomás, el podcast en el que hablamos de descentralización del Internet que todos queremos y de muchísimas más cosas que la verdad que son muy interesantes. Mi nombre es Álex Barredo, puedes llamarme aquí siempre don Alejandro, y conmigo está Ramón Medrano, alias don Ramón. ¿Qué tal estás?

Muy bien, muy bien, gracias. Aquí grabando de

nuevo. Cuéntame, ¿qué nos vas a explicar en este episodio? Porque tengo muchas ganas, la verdad.

A ver, bueno, vamos a ir hablando, comentando los dos de, en el episodio pasado hablamos de BGP, digamos que sería la cómo se centraliza la el direccionamiento y el enrutado, y hoy vamos a hablar de algo que es muy conocido por todos, que es el DNS, es el servicio de nombres de dominio

Bueno, conocido en el sentido de que nos suena el nombre. Luego ya, ¿cómo funciona?

Los que hacemos sistemas y tal siempre decimos una cosa que es que no es el DNS, puede que sea el DNS, es siempre el DNS lo que falla cuando cuando hay algún algún tema. DNS es claramente un protocolo de aplicación, la red funciona sin DNS, sin ningún problema, es protocolo para los humanos, digamos, ¿no? Entonces, hay gente que lo confunde porque en el sentido de que es esencial, nadie se va a poner a utilizar la web

Numerito a numerito.

No quiero decir a a a pelo, ¿no? O sea, con los direcciones IP DNS habilita muchas funcionalidades encima de lo que sería la capa de red para aplicaciones que utilicen, ¿no? Por ejemplo, tienes temas como el DNS dinámico, el DNS Multicast, historias de estas Sí. Que al y algunas de las configuraciones, incluso, de la capa de red, se distribuyen por DNS en alguno de los casos.

Has comentado una cosa que me interesa muchísimo, que es todas las funciones, digamos, no sé si decir, dinámicas o extra, o que no son las que solemos pensar cuando hablamos de DNS, porque por ponerlo de una forma resumida y que sirva de básico para aquellos que, pues, no estéis mucho en este mundillo y que vamos a adentrarnos de una forma mucho más técnica en unos minutos, DNS es un sistema de parejas de sinónimos, es decir, Pepito punto com igual a esta dirección IP. Bien, IP cuatro tradicionalmente, o en el futuro IP seis, y muchas más cosas, pero en principio es, como decíamos, un sistema mnemotécnico, ¿no? Una que creo que una vez me lo explicaron así, es como, mira, tu ordenador sabe que esto es para acceder a esto, es como un acceso directo.

Bueno, antes de DNS, DNS es un sistema dinámico, en el sentido de que las es una base de datos distribuida, es un key value store que se llama, o sea, tú tienes una clave y obtienes un valor y ya está. Es un sistema dinámico porque depende de dónde lo consultes, quién lo escriba y tal, puedes tener distintas respuestas para la misma clave. Es un sistema distribuido, como hemos visto, antes de DNS, simplemente es una base de datos descentralizada, bueno semi descentralizada, se utilizaban ficheros. Había un fichero host para cuando la RAID era más pequeña, en el que hacía lo mismo, es un key value store, tenías una columna que eran todas las claves y un value que eran todas las direcciones IP, porque además eran estatus ¿Y se lo

iban copiando por ahí en un disquete en las universidades o qué?

Al principio sí, luego por FTP y tal, hasta que bueno, la cosa claro ya no escalaba porque no solo la base de datos era bastante grande, sino que además las mutaciones que necesitaba no las no escalaban, entonces se inventó el sistema este de DNS, pero en esencia es eso, es yo quiero tener texto que me dé una serie de de valores. Pueden ser originalmente y el más consultado es el registro de de direcciones IP, pero hay muchos más. DNS, por ejemplo, es un componente fundamental en la lucha contra el spam, en el email. Hay una serie de registros criptográficos que que se, según, bueno, los veremos ahora, que se almacenan en DNS. Entonces, bueno, efectivamente, es un protocolo de la capa de aplicación, pero digamos que es un protocolo de la capa baja de aplicación, vamos a decirlo así.

Porque muchas otras aplicaciones sin DNS no podrían no podrían funcionar. Entonces, ya no es, digamos que ya no es opcional, como como antes.

Una cosa que para que no se me olvide es a ver si después de las explicaciones técnicas podemos adentrarnos un poco en el tema de quién decide, quién gestiona lo que son los dominios de mayor nivel, ¿no? Estos TLDs, estos top level domains, que ahora son tan variados y que hay tantos, y cómo se gestiona esto. Si no nos da tiempo, pues ya quizás en otro episodio, porque ese también es el primer punto de la descentralización de estas DMS, es decir, Pepito punto com es técnicamente un subdominio de COM.

Sí, va, creo que vamos a entrar en este melón, porque es interesante para entender cómo funciona el DNS. O sea, DNS, como tú has dicho, es un sistema distribuido o semidistribuido, y ahí es donde voy, porque es un sistema jerárquico, ¿vale? Los dominios, todos sabemos que los dominios son, yo que sé, Google punto com, Mix punto Io, todos cada vez que tienes un punto tienes una serie de de estás describiendo la jerarquía en un área, ¿no? Entonces, el tope de la jerarquía serían los dominios traiz, vamos a decirlo así, o los dominios top level domain, que serían lo que llaman PLD. Hay dos tipos de dominio, los PLD clásicos, que serían los geográficos, que es punto es, punto u k, punto comta, y luego tiene los dominios genéricos.

Los dominios genéricos son los que sería punto org, punto com. Originalmente estos dominios, los teleds genéricos, había unos pocos, pero ahora se han expandido muchísimo, ahora tienes punto app, punto social, punto no sé qué, tienes un montón de ellos.

¿Cómo funciona esta serie de decisiones de cómo se habilitan? Porque sí que hay un proceso que se creó hace unos años, ¿no? De que se pueden crear nuevas versiones, ¿no? Está el punto Madrid, hay tantas cosas, la verdad, que es es es una locura.

Hay una organización centralizada en los Estados Unidos, es la parte que le da la semidescentralización a DMS, que es la que se encarga de definir los top level domates. Tienen unos servidores raíz, unos servidores root, DNS, que son los que en el último caso tú consultas para empezar a ir atravesando ahora cuando veremos la resolución, la jerarquía, pero ellos son los que definen cuáles son los top level domains que hay. Tienen un proceso, bueno, la ICAN es la organización que hace esto, que significa, a ver si lo traduzco al español bien, la corporación de Internet para la asignación de nombres y números, ¿vale? Entonces, esta el ICAN lo que hace es gestiona los dominios de nivel superior y luego gestiona también los bloques de direcciones IP. Claro, los los bloques de direcciones IP los va asignando.

Hay un proceso que se llama el new tl d o new generity tl d o algo así, entonces, se mandan una propuesta de yo quiero el dominio punto caca. Entonces, igual te dicen que no porque, pues, bueno, es feo, yo qué sé, o igual lo aprueban. Y luego tienes que, para tú ser el propietario de eso, pues tienes que pagar, digamos, unas cuotas o unos fees o lo que fuese. Entonces, dependiendo de lo que sea, son más caros o más baratas.

Y luego tú ya decides Reventerlo. Exacto. ¿Cómo lo distribuyes? Es decir, si cuesta más, cuesta menos, si está más abierto, menos abierto, si te lo quedas para ti. Por ejemplo, un dominio que también es muy popular ahora es el punto app.

Otro que ha causado un poco de polémica es el punto zip, porque, claro, ahora decían, no, es que va a empezar a romper cosas porque elementos de software se van a pensar que eso es un fichero y van a intentar tratarlo como un fichero más que como una URL, ¿no?

Sí, ahora mismo hay, la última vez que yo lo miré había, de este tipo de dominios genéricos, hay más de mil quinientos ya.

Es una Hay muchos, y

al final lo que te permiten hacer es, en muchos casos, hay dominios que son muy populares ahora, por ejemplo, el punto PEAI o el punto OYO. Entonces, hay países pequeños que viven de vender dominios de su de su localización, y luego hay otros que, pues, sirven muchos casos para hacer nombres, digamos, de marcas y

y Eso es.

Pues, bueno, esto, tú cuando no eres el propietario de un TLCD, puedes revenderlo como Registrart o puedes utilizarlo para ti. Hacer tú, digamos, que solo lo revendes a ti, entonces, la la jerarquía que la defines tú y es para ti sola, yo qué sé. Hubo polémica con el dominio punto Amazon, me parece, hace unos años

Claro.

Lo compró la empresa Amazon y parece ser que Brasil lo quería, pues, para las cosas del Amazon.

Y al final eso no me no recuerdo en qué quedó, me acuerdo de comentar la noticia, pero es muy chulo, es muy chulo. Por ejemplo, en Google tenéis Google. Entonces, el blog de Google es blog punto Google, que es increíble, o sea, es súper chulo. Pero claro, si a lo mejor yo voy un navegador antiguo o a un ordenador antiguo, y y le pongo esa dirección, no está programado para que todo lo que le ponga en la barra de direcciones o todas las peticiones que haga las interprete como dominios, porque seguro que tiene como una serie de dominios específicos que en esa época estaban escritos en el software a mano, ¿no? Es decir, una especie de regex de, bueno, si esto acaba en punto com, esto es un dominio.

Vamos para adelante, ¿no?

Sí, muchas veces lo que haces, te pones una barra al final para forzar esto es una URL y te y te va. Eso pasa, por ejemplo, si utilizas dominios el Ethereum, tiene un sistema de dominios, lo creo

El punto es DHC.

Sí, eso es un sistema de dominios que es completamente descentralizado y en vez de resolverlo con los la jerarquía clásica de de DNS, envían peticiones a la a la a la red de de ethereum. Tú tienes que forzarlo para que el Resuelve vaya para allá. Entonces, muchas veces le pones la barra y ya y ya Y

ya lo entiende, ¿no? Sí, porque si no, claro, muchos navegadores han adoptado esta doctrina de, si pongo algo en la barra que no reconozco, es una búsqueda, y te voy al botón de búsqueda predeterminado que tengas a buscar esto, pero bueno. En fin, sigamos con el tema de DNS, cuéntame más cositas, a ver, porque tengo muchas dudas y según me las vayas contando, seguramente te dé la matraca.

A ver, luego habíamos dicho que era jerárquico, y ahí es donde empieza la descentralización, o sea, la clave del DNS, una vez te te apartas del ICAN y tienes la los, digamos, los top level domains y los servidores root, que sería la el axioma, ¿no? Estos son públicos, son fijos, ¿no? Entonces, cuando tú quieres resolver una petición, si no tienes la diez cacheada o no sabes cuál es el los top level domains es la raíz y luego tienes, si miramos el punto com, tienes muchísimos dominios punto com, hay millones de dominios punto com. Cada uno de los dominios punto com es lo que se llama una zona, una zona del DNS. Entonces, tú compras un dominio, tú quieres comprar, por ejemplo, Don Ramón punto com, sería un gran nombre para vino barato, y lo que haces es, al comprar el dominio, tú te registras en el registrar, que es el propietario del del double del domain punto com, y ellos establecen unos registros.

Entonces, le dicen, cuando alguien venga a resolver el dominio don Ramón punto com, lo que les voy a responder es que esto es una zona que tiene que resolver otro servidor DNS aparte, es lo que se llama los Glue Records. Entonces, eso es lo que hace es, digamos que mantiene todo pegado, entonces lo que lo que ocurre que cuando yo voy a punto com y le digo quiero que me digas cuál es la zona donde está definido don Ramón punto com, te va a dar otros servidores que son los que ya tienen los autorizativos se llama, autorizados, ¿no? Son los que son el el el source of truth para esa zona. Lo que ellos te respondan es la verdad, ¿no? Luego puede haber muchos cachés y muchas cosas, pero si tú no tienes ningún caché por el medio de de la resolución que se ha hecho, al final tienes que ir a los dominios autorizativo, esa palabra no existe, pero vamos a usarla.

Y entonces lo que puede pasar es que tengas que repetir esto varias veces, ¿vale? Porque tú puedes tener un dominio que sea www punto don Ramón punto com, y que el www sea otra zona que tienes definida aparte, ¿no? Y y puedes concatenar tantos como tú

quieras. Al final, lo del w w w es una herencia que seguimos arrastrando, porque ya cada vez se usan menos, pero, claro, normalmente era el subdominio donde estaba disponible la web de esa cosa. Porque, claro, luego estaban los correos, luego estaban los FTPs, cada uno en sus diferentes subdominio. Pero bueno, ahí tenemos que seguir y yo cada vez que registro un dominio tengo que volver a hacer lo mismo, es decir, el tres subes dobles redirige al dominio principal, porque realmente no lo quiero utilizar, lo quiero tener un poco ahí oculto que no vale para nada.

Bueno, es que ha cambiado un poco la semántica. Originalmente, el don Ramón punto com definía una zona, un dominio, por eso se llama un dominio, porque y luego vas vas a tener muchas cosas dentro. El w w w, o sea, uno de los componentes, uno de los servicios, pero luego podías tener miles de cosas. Ahora se utiliza más el dominio como una especie de marca, más que el una colección de todos los servicios que hay en una en una parte de la subred, ¿no? Lo que decías de la redirección, creo que es un setway fantástico para entrar en los qué cosas podemos almacenar en DNS.

La resolución al final funciona como eso, tú tienes que ir navegando un árbol hasta que llegas al servidor que tiene el registro en sí. Y, claro, los registros, todos conocemos el registro A de address, que es simplemente, pues, para don Ramón punto com, la dirección es ciento noventa y cuatro doscientos veinticinco, ta, pero hay muchas más cosas que se pueden almacenar en el DNS que son muy importantes. Tienes la versión a y cuatro a a a, que es simplemente la la dirección IPv seis.

Anda, mira, lo he pronunciado sin mayor historia, pero nunca lo sabía. Yo veía cuando, pues eso, los doscientos mil dominios que tenemos todos comprados y que no usamos, o que hemos tenido en el pasado, etcétera, y cuando nos estás editando ves el a y los tipos que ahora encontrarás, y el y yo no sabía que era esa. Pensaba que era como de más importancia, digo, este es el ese es el principal.

No, son cuatro Aes porque la dirección de IPB four es de treinta y dos bits, la dirección de IPB six es de ciento veintiocho, son cuatro veces treinta y dos, y entonces no se les ocurrió más que decir, bueno, pues vamos a poner cuatro Aes. Esto ha dado mucha polémica a está bien diseñado o no, es decir, debería ser las direcciones IP phone y IPs v six iguales y estar dentro del dominio A, o sí o no. Yo creo que esta ayuda porque siempre puedes priorizar, ¿no? Si quieres priorizar el tráfico IPB six en tu red o para redes, por ejemplo, que tengan solo IPD six, creo que que es el caso ya, puedes hacer una solicitud al dominio a a cuatro Aes, incluso puedes hacer NAT utilizando esos esos registros.

Específicos. Luego ahí suelo ver yo también, obviamente, los MX, los CNAMES, los o los NAMES en general, los TXT, yo creo que son, y quizás lo más interesantes. Cuéntame cuál es que el siguiente que dirías tú.

A ver, lo que dijiste, el MX y el TXT, y el el CNAME son registros que utilizan mucho para dos cosas, el DMX es, dame los servidores que pueden recibir email, los servidores SNTP para un dominio. Entonces, yo qué sé, si tienes Gmail punto com, no manda, tú no te conectas al servidor de correo Gmail punto com, tú lo que haces es el el agente de de usuario va a decir, bueno, esto es una dirección de Gmail punto com, conecta al DNS y le dice, dame, buscas el registro MX que te dice cuáles son las máquinas concretas que son las que se encargan del correo de ese dominio.

Sí, que entiendo yo que es de mail exchanges, ¿no? De intercambio de correos. Imagino que, en el futuro, si seguimos con esta temática, quizás, en el futuro veamos un social punto, ¿no? Un un un tipo, ¿no? A los MX o de intercambio social, un SX.

Sea donde se resuelve un servidor, un x, llamémoslo x, con las funciones que haya para para las interacciones que hagamos en el futuro. Podría estar chulo la verdad.

Sí, eso se utiliza ahora mismo en los registros TXT y el protocolo, el AT Proto, que ha hablado hace unos capítulos anteriores, utiliza el registro TXT para establecer una clave, ¿no? Entonces, el registro TXT es el registro text, que es el registro Manolo, pon lo que te dé la gana aquí, que da lo mismo. ¿Cuál es el problema? Es un registro sin tipo de forma, es decir, simplemente tiene líneas de texto, y hay muchas aplicaciones que están utilizando eso y las tienen que interpretar. Hablábamos de IT Proto, tú cuando vas a Blue Sky quieres quiero cambiar mi handle y que tenga una URL para validar que el propietario de la URL eres tú, te dan una un blog con una firma digital que tú tienes que poner en tu dominio un registro TXT, que es el subrayado AT AT, me parece.

Ah, yo lo hice en su día y y lo dejas ahí y ya está. Entonces, lo que pasa es que, claro, el Blue Sky, de vez en cuando, yo en los logos del DNS veo que de vez en cuando valida que eso sigue siendo

vigente, ¿no?

Exacto. Entonces, bueno, simplemente es una firma digital, ellos te dan una una firma con clave pública, tú la pones y ellos verifican que es un un, digamos, ejemplo, mira, yo estoy mirando en mi servidor de DNS y yo tengo cosas como el un registro TXT que se utiliza para el el spam. Entonces, en el control de spam de email hay un sistema que se llama Dmark, que lo que haces es firmar digitalmente tu dominio para probar que no es un dominio de de spam. Entonces, el registro TXT tienes que poner una clave de autenticación para que cuando tú envíes email, o sea, esto es muy útil, por ejemplo, si envías email en bulk, tienes un servicio, yo creo que mailchint y mandas miles de millones de emails

Eso es.

Al estar autentificado, no te lo catalogan, por ejemplo, como spam. Por ejemplo, yo tengo aquí la clave, o sea, es una clave de firma, y luego tienes un segundo dominio, un perdón, un segundo registro, que lo que incorpora es dónde está tu política de SPF, ¿vale? Que es una política, pues, ¿qué pasa si, no sé, te dice, pues, una serie de propiedades para control de spam, no? Para que, digamos, el el servidor que lo recibe va a consultar tu dominio, ver si tienes una política que te diga, por ejemplo, si es un mensaje que va sin firmar, pues lo tienes que tirar o lo tienes que aceptar o lo tienes que devolver, esta serie de cosas. Entonces, digamos que configuras tu dominio para que los receptores de email provenientes de tu dominio sepan qué tienen que hacer y que es auténtico.

Ahora ya están poniéndose más en serio con esto, ¿no? Pero tradicionalmente ha sido algo un poco más, venga, viva la vida, ¿no? Puedes enviarme un email diciendo que eres Barredo punto es, aunque venga de una máquina que no aparece en ningún momento identificada en estos registros, ¿no?

Sí. Luego hay más dominios que son específicos para configurar cosas, por ejemplo, tienes los dominios pointer, los ptr sirven para hacer la resolución contraria, y esto se usa también en email. Es decir, hay una forma de establecer como nombre de dominio una dirección IP que se pone al revés, es decir, si tú tienes la dirección IP diez punto once punto doce punto trece, lo vas a resolver al revés. Entonces, pones el dominio trece punto doce punto once punto diez punto arpa, arpa no sé qué sé cuánto, y entonces eso debería haber un dominio pointer que resuelva a la máquina, o sea, que que que case.

¿Y eso para qué se suele utilizar?

Se suele utilizar para que la no haya high jacking de las de las direcciones de DNS. Entonces, si yo tengo un servidor de email, por ejemplo, que está en una dirección IT Sí. Y tiene asociado un dominio, ¿vale? Va a haber una serie de políticas que hablábamos y tal, pero yo puedo, si tengo acceso al servidor de DNS de ese dominio, porque, ¿sabes? Accedo y lo quiero hacer, y quiero poner un servidor de email que genere spam bajo ese nombre, si yo cambio el registro mx, automáticamente yo soy el propietario de ese email.

Entonces, el registro pointer lo que te hace es, cuando eso se valida, eso va a seguir apuntando con el nombre anterior. O sea,

es como una segunda capa de seguridad o de copia, de respaldo.

Es como hacer la la el el reverso de la de la resolución. Es como tú traduces de nombre a dirección IP, pero tú puedes traducir de dirección IP a nombre de nuestros dominios. Vale. Con estos registros. Hay otros registros que valen puramente para seguridad, por ejemplo, tienes, si usáis hay unos dominios que son los que tienen las claves de host de la máquina que está detrás de ese de ese nombre.

Entonces, te permite validar o te permite publicar cuáles son las claves de host para una máquina que vas a hacer y el es el cliente puede validarlas a priori antes de conectar a la máquina. Entonces, si hay un spoofing, por ejemplo, de la máquina, lo que va a hacer es que esas claves ya no validan. Entonces, si quieres tener acceso para la máquina, vas a tener que tener acceso a tienes que tener ganar acceso a la máquina para, yo qué sé, cambiarla o poner unas claves para hacer un my thank, lo que quieras, pero también al DNS. Entonces, si están separados, digamos que es más difícil porque tienes que tener acceso a dos A

dos cosas. Es decir, lo que está en la máquina es lo que me suele aparecer cuando yo hago SCH y me dice por primera vez el finger printes, tal, ¿quieres conectarte? Sí, no. Y luego, aparte en DNS también se puede poner, eso yo no lo sabía, lo voy a mirar porque eso es muy importante.

Eso se eso se puede poner, hay que instruir al cliente que los mide y a que te avise, ¿no? Pero sí que sí que se puede poner.

Qué bueno.

Y luego hay otro otros dominios relativos con seguridad que son los de DNS SEC. Hemos visto que esto es una cosa, DNS es una cosa jerárquica, ¿vale? Pero está todo en texto plano. Tú conectas a un resolver con un paquete UDP, si la transferencia UDP falla por lo que sea o es un un nombre muy largo, puedes hacerlo con con TCP, pero no está autenticado, nada. Si tú tienes un servidor de un resolver, que esto lo hacen algunos algunos ISPs, lo que lo puedes responder lo que tú quieras.

Claro.

¿Vale? O sea, si yo tengo un un resolver, digo, bueno, yo quiero resolver el nombre Github punto com. Entonces, yo que sé, mi SP de turno dice, pues, yo quiero que no puedas acceder a Github punto com porque quiero poner un intermediario aquí para ofrecerte una oferta antes de entrar ahí. Yo qué sé, ¿vale? Simplemente interceptas la petición a que que yo voy a hacer y nada, apuntas la al resolver el dominio.

A la máquina que tú quieras. Digamos que en esa subred, ese dominio Github punto com, o esa zona Github dentro del dominio com, que creo que ya voy cogiendo un poco la la jerga, está en esta otra máquina, que al final esto es algo que es muy común a nivel empresarial, ¿vale? Pues, por ejemplo, para las intranets o para bloquear incluso determinados dominios, anulas o dejas vacío esa zona y ya nadie puede estar toda la al día en la oficina viendo YouTube. Como, por ejemplo, pues, como decías tú, para ataques, etcétera, y también muchas personas lo he visto que modifican su fichero interno, hosts, en su ordenador para darse un poco de productividad, ¿no? Es decir, bueno, mira, me van a crear YouTube, Twitter, Facebook, Instagram, y así no me distraigo a lo largo de los días, ¿no?

Claro, entonces, el DNS SEC, al final, lo que es es una forma de firmar digitalmente la procedencia de las resoluciones. Esto suena bastante chungo, pero lo que pasa es lo siguiente, cuando tú tienes un resolver le puedes instruir que valide el DNS, el DNS SEC, perdón. El DNS SEC, para que nos hagamos una idea, se lanzó hace como veinte años y como el uno por ciento de las resoluciones autentican con DNS. O sea, que es minoritario, pero, bueno, es una solución que está bien, tiene algunos problemas de seguridad, como la puedes hacer un ataque de amplificación y tal, pero bueno, en principio, la solución lo que vamos a hacer es firmar digitalmente la respuesta con una clave pública que el resolver puede decir, vamos a ver, la clave pública para este dominio yo sé cuál es, la respuesta me viene firmada, entonces yo sé que esa respuesta viene de la zona original. Ajá.

Porque tú resuelves con tu resolver, normalmente es el que te da el IST, pero podría ser tu propia máquina, puede ser la que lo haga. Entonces, lo que va a hacer es eso, va a hacer una resolución recursiva y luego lo que va a hacer es decir, vale, pues, ahora ya tengo la respuesta a la consulta, está firmada digitalmente, la clave pública está pública, entonces, yo puedo verificar la autenticidad de esa de esa información. ¿Qué qué ocurre? Si el ISP quiere cambiar la respuesta, no va a tener la clave privada para firmarla. Claro.

Entonces, va a haber una una un fallo de verificación del DNS, te van a dar una respuesta que no autentica.

Me encanta porque son como diferentes capas y diferentes niveles de intentar, más o menos, hacer lo mismo. Es decir, tenemos el SSL, que hay como también como un acuerdo, más o menos, ¿no? Este servidor es quien dice ser. Luego está este DNS SEC a nivel de las DNS. Comentabas lo mismo también en los BGP, en el anterior episodio, ¿no?

Que había una forma de certificar que no, que estás siendo tú. De tal forma que si alguien quisiera secuestrar o hacerse con un dominio muy específico, aunque sea de forma camuflada o subrepticia, pues le sea completamente difícil o, al menos, más difícil de lo que debería ser, ¿no? Pues, al final, estamos todos más protegidos. Imagínate que mañana iCloud punto com alguien lo secuestra, viene un ISP o un país o un hacker en una WiFi, etcétera, y hay diferentes capas para que la capa de aplicaciones, ¿no? Sea capaz de discernir si realmente está ocurriendo algo raro y empezar a mostrar errores.

Sí, o sea, esto sería la autenticidad, ¿no? La otro problema que tiene DNS es la privacidad. Es decir, si yo puedo cambiar mis resolvers y no utilizar, por ejemplo, yo, suponte que tengo Vodafone en casa, y en vez de utilizar los DNS que me dan, los resuelves que me dan por defecto, digo, yo voy a utilizar CloudFlare, porque me da la gana, ¿no? Entonces, CloudFlare, tú mandas un paquete UDP al uno uno uno uno y eso va en plano. Entonces, Telefónica puede decir, fantástico, coge, intercepta el el paquete UDP

Sí.

Lo redirige a su servidor DNS y te devuelve la respuesta que ellos le dé la gana. Primero, eso podría fallar el la validación de DNS sex si si no lo están firmando o si tú la has la la quieres solicitar, Pero lo que puede pasar también es que, aunque te den la respuesta auténtica y no hagan ningún tipo de intersección del tráfico, es decir, los dejan correr hasta hasta Cloudflare o Google o el Resuelve que tú quieras, lo que pueden hacer simplemente es inspeccionar el paquete, el datagrama y tomar nota de los servidores, las nombres que tú estás resolviendo. Entonces, es un histórico maravilloso de todas las las soluciones que tú estás haciendo.

Sí, y es uno de los vías de, digamos, de pérdida de privacidad o de control de privacidad, mejor dicho, que no se suelen tener en cuenta, y que estamos viendo que la mayoría de las grandes operadoras del mundo, esto lo están monetizando de una forma mayor o menor, con fines publicitarios, con fines pronunciantes, con fines de estadísticos, etcétera, y con mayor o menor colaboración de el estado o los estados donde donde trabajan, ¿no?

A ver, es un ataque, por ejemplo, hay ciertos estados que han bloqueado signal, Telegram, aplicaciones así utilizando mecanismos de DNS. ¿Cómo se resuelve esto? Bueno, pues utilizando una encriptación de tráfico entre el cliente y el resolver. Hay tres protocolos tradicionales, el primero, el más antiguo es DNS CripT, se usa poco ya, y luego tiene los dos más modernos, es DNS sobre TLC y DNS sobre HTTPS. DNS sobre TLC, nada, abre una accesion TLC con el resolver y utiliza TCP para hacer las resoluciones.

DNS sobre HTTPS tiene una ventaja similar en el concepto, tiene una ventaja es que al utilizar HTTPS el tráfico parece que son peticiones well, es decir, el DNS sobre tlS se conecta al puerto ochocientos cincuenta y tres, y se sabe que es una, no vas a poder inspeccionar, a lo mejor, pues, se sabe que es una resolución de tráfico de de del libro, porque por el puerto, por el tráfico, todo. Con órdenes y sobre HTTPS, en principio, a ver, al final lo puedes cazar porque hay cosas como el server main indicator de de TLC y demás, pero, bueno, en principio es simplemente una petición web a un servidor, ¿no? Entonces, es más mucho más difícil de interceptar.

En principio, claro, no sabes si estás pidiendo una gen JPG, si estás pidiendo una web, un HTML, si estás pidiendo recursos, etcétera, o si estás haciendo realmente una petición de ese listado de registros del dominio, claro.

Luego tienes otra cosa que hemos hablado que es interesante, es que DNS se está convirtiendo en una piedra, digamos, central de la seguridad de la red Internet, especialmente de las aplicaciones de la web. Por ejemplo, al utilizar TLC hay un mecanismo que rompe toda la privacidad, o sea, no puedes interceptar lo que es la el tráfico de sesión, pero hay una cosa que se llama el server main indicator, es cuando tú te conectas a un servidor que tiene TLC, eso va en plano. Es decir, si tú tienes un servidor que sirve muchos dominios, tú tienes que decirle quiero conectarme a este servidor, quiero empezar una negociación TLC, y este es el el nombre de de servicio al que quiero conectarme.

Vale.

Eso va en plano. Entonces, esto es, por ejemplo, cómo discriminas si el tráfico es DNS o PHTTPS, es si tienes un nombre común, DNS punto CloudFlare punto com, ¿no? O sea, ya sabes lo que vas a hacer. Ya. Hay otro registro en en DNS, que se llama el registro HTTPS, en un alarde de originalidad, creo que se rompieron la cabeza para encontrar el nombre, que contiene claves públicas del de los servidores web para poder hacer dos cosas, que es primero, abrir las sesiones TLC más rápido, es decir, reduces un round trip la negociación, y segundo, basado en este en este, si tú tienes para tu dominio este registro bien configurado, puedes encriptar el server nameing, el SNI, el server naming indication.

Entonces, la la la comunicación ahí es completamente encriptada, ¿vale? Es decir, tú abres una conexión con el servidor, empiezas a hacer una negociación TLC, establece las claves y ya está. No hay un link de, pues, me estoy conectando a, yo qué sé, a BART punto Google punto com. Es muy típico en servicios de estos grandes que tienes los front ends que sirven todos los dominios, si quieres Gmail Bart, el Calendar, lo que sea. Con la encarnación actual Sí.

Tú sabes que alguien se está conectando al al, yo que sé, al DN al al al cloud de Google, no sabes que el tráfico SEO no lo vas a saber porque está con TLC, ¿vale? Pero sí sabes el el el servicio, digamos, al que se conectando, sí, el el dominio lo indica, ¿no? Entonces, TLC permite implementar el el encripted client hello que se llama en base a otro de estos registros.

Estoy viendo que, bueno, esto del SNI o el SNI encrippado, el ESNI, y todo lo como y el el el nuevo nombre o la nueva adaptación o la nueva versión actual, el eco, CEHO

Encriptid clience el auto.

Que lo acaba de implementar Firefox, por ejemplo, hace poco. Entonces, es una cosa relativamente reciente y, bueno, más capas y más intentos de, pues, asegurarnos de que realmente estamos comunicándonos con con con el servidor que realmente queremos.

Sí, o sea, vale para eso, para autentificar que el servidor que tú te vas a conectar es el que tiene que ser, no no hay un hoja jacking del servidor, y luego segundo, la comunicación entre tú y el servidor sea privada. Y eso incluye no solo lo que es el el, digamos, los datos que tú estás transmitiendo en las gestiones que estás haciendo Ajá. ¿No? Pero también la privacidad de que tú te estás conectando a un servicio y nadie tiene tiempo que saber qué servicio es.

Estas partes directamente ciertos gobiernos un poco más autocráticos o ISPs bajo órdenes o o por lo que sea, lo bloquean y hacen nada, todo este tipo de protección. Esto siempre, si detecto que alguien está utilizando SNIS o ECHs o cosas así, fuera, esto no va, ni para arriba ni para abajo ni para bien ni para mal. Y es una forma de, oye, pues como no puedo saber a dónde estás apuntando, corto todo, intercepto todo para nadie.

Bueno, no te tienes que ir a hacer algo tan complicado. Hay industrias que están muy reguladas, por ejemplo, la industria financiera y demás. Las propias empresas tienen que, por ejemplo, ser capaces de ver lo están haciendo los empleados y demás, ¿no? Por ciertas regulaciones. Cuando salió TLC uno punto tres, mejoraba bastante la negociación del de estos asuntos y, precisamente, las industrias financieras se quejaron de que no podían poner, ¿sabes?

Middle boxes que inspeccionaran el contenido del tráfico, y era no porque sean maquinarias del mal, sino porque la regulación les obliga a hacer este tipo de cosas. Entonces, hay siempre un balance de qué es lo que qué es lo que puedes hacer.

Eso sí es cierto. Bueno, imagino que habrá otras formas de hacerlo en local o de tener un registro desde la otra parte del software, ¿no? Desde el cliente que se está utilizando para acceder a eso, pero al final sí que es cierto que es todo todo mucho más complicado, y yo creo que es el motivo de que existan tantas capas y tantos elementos y tantas verificaciones que realmente están haciendo lo mismo, es decir, asegurarnos de que realmente la comunicación es entre las dos máquinas que dicen serlo y de una forma que solo puedan entender realmente lo que se están diciendo ambas máquinas, el destino y el origen, y no las que reenvían los mensajes.

A ver, es que luego, al final, otra de las cosas que que está todo interrelacionado, o sea, en DNS, estamos hablando de DNS, de TLC, y hay que hablar también de la sistema de clave de infraestructura de clave pública, el PIB que hay. Entonces, estas tres cosas no se pueden hablar, digamos, en abstracto o por separado, Porque, por ejemplo, lo que acabas de comentar, otra cosa que se hizo hace muchos años y que se sigue haciendo es lo que llaman lo del Root Kit, que es te instalan un certificado raíz en el navegador que tiene confianza total, y a partir de ahí ya da igual, ¿sabes? Porque puedes tener todo el tema de ESNI, DNSEC, todas estas historias, si tienes un certificado de confianza para una entidad gubernamental, empresarial, lo que sea. No sé qué marca lo hizo hace unos cuantos años, Lenovo o Sony o algo así, instalaron un certificado suyo de a nivel de confianza total. Entonces, claro, cualquier registro que venga firmado con ese o con herederos de ese certificado, pasa todas las checks, le dices, sí, sí DNS, TLC, todo, perfecto, o sea, ¿no?

Tu máquina lo da todo por validado porque se ha confiado. Es que al final esto de los certificados root en los navegadores y cómo se deciden, yo creo que también podría dar para otro episodio toda esa negociación y qué viene instalado, y quién lo decide y quién no lo decide, y si los puedes quitar o no los puedes quitar. Porque hay bastantes jaleos. Al final, tú un navegador te da errores o te deja entrar a determinadas webs y a determinados dominios, etcétera, depende del propio navegador, más que, digamos, es decir, no es tan agnóstico como parece. Hay mucha confianza depositada en que, por ejemplo, pues Mozilla haya dicho, oye, esto que te viene aquí preinstalado, estos son guays y son aceptables.

Bueno, hay todo un proceso alrededor de la validación de todas estas cosas. Por ejemplo, las claves de, si vamos otra vez al DNS, el DNS SEC al final tiene unas claves raíz, es decir, el el top level domain, tú cuando lo registras dices, yo quiero habilitar de NSEC, y te dicen, vale, yo yo que te he registrado el dominio, voy a delegar la zona en ti y, además, te la voy a firmar digitalmente. Tú pagas y te firman y te autentican que eres tú, luego tú puedes crear subzonas y más y vas firmando una de esas de otra. ¿Cuál es el problema? Final, hay una clave raíz, un conjunto de claves raíz.

Por ejemplo, hace poco que se quieren rotar, llevan unos cuantos años más mismas claves privadas, vamos a generar otras nuevas, ¿no? Para que vayan rotando de vez en cuando. Ese fue un chea show de la de dios, o sea, lo tuvieron que hacer un rollback, tuvieron que volver a hacerlo, hubo una ceremonia, digamos, para hacerlo, tal, se rompieron no sé cuántas historias. Entonces, claro, son protocolos que están muy osificados que se llaman, que la gente asume muchas cosas de cómo funcionan y cómo no. Y lo que venías diciendo antes, por ejemplo, los nuevos dominios de top level, que ya no funcionaban en ciertos navegadores y demás, el evolucionar y mantener estos protocolos requiere del acuerdo de muchas de muchas partes, los navegadores, los desarrollos de aplicación, sistemas operativos, el ICAN.

Es todo un un mecanismo y una serie de consorcios, de consorcios, de consorcios bastante complicados. ¿Queda algo más de dentro de este campo de las DNS que sea así superinteresante?

Creo que una cosa de las que tendremos que hablar de las DNS en cuanto a la descentralización Ajá. Es cómo conseguir descentralización completa. Ahora mismo, ves que dependemos siempre de una entidad central, bueno, es una entidad no gubernamental que está en representar mucha gente y demás, entonces, no es algo que sea inherentemente algo que haya que desconfiar, el I can tiene un montón de gentes. Pero, bueno, a fin de cuentas, sí que es un punto único de fallo, ¿no? En el sentido de que el si los servidores raíz desaparecen, si la ICAN, pues, lo que sea, no funciona bien, no tal, son entidades que además están siempre generalmente en Estados Unidos, ¿no?

Que no depende ni de la ONU ni de otro consorcio tal. Ahora mismo, en tendencia, eso no se puede hacer, no hay acuerdo, digamos, para descentralizarlo, se intentó sacar el IKAN afuera de, digamos, hacerle una organización internacional y tal. Parece que no hubo una gran cantidad de progreso. Y luego hubo otras propuestas desde el punto de vista técnico que fueron, por ejemplo, los dominios de Ethernet, que se llaman los and stopable domains, en un alarde de branding.

Cuéntame eso.

Básicamente es, en lugar de tener una organización centralizada, lo que tienes es una aplicación en la red de Ethereum, que es la organización descentralizada que asigna todos estos nombres. Entonces, tú para registrar un dominio tienes que pagar un fee de estos de de gas o de lo que pasa es una comisión en en términos de Ethereum y te registran en un en uno de los bloques Blockchain y demás, y a partir de ahí lo tienes. Ningún navegador sabe resolverlos de forma nativa. Ya. Entonces, es un problema.

Si usas next DNS, por ejemplo, que es una aplicación que es en TBNS y que está muy bien, tiene para bloquear cosas, privacidad, tal, ese resolver sí que los resuelve.

Claro.

Entonces, tú puedes escribir un nombre de dominio de Ethereum y que lo resuelve, como si fuera un dominio normal.

Sí, está bastante guay, y eso es una de las partes de las cadenas de bloques que yo creo que realmente tiene un futuro y y es algo interesante, y me parecería que ya es hora de que los navegadores lo soporten, ¿no? No solo porque es guay, es decir, tener un dominio punto x, por ejemplo, o sea, es que es superchulo el punto ETH, etcétera, pero yo creo que añade esa descentralización definitiva y realmente está ahí de forma pública, que al final es una cadena de bloques, se va actualizando, se va manteniendo, etcétera. No me acaba de gustar el caso de que haya emisor, pero es que realmente creo que ahí es donde está el fin de la descentralización, es decir, tiene que haber una parte, en este caso, el punto com o el punto x, que decíamos aquí, o el punto ETH, de esto es un stop popul domain que dices tú, en el que nos tenemos que poner de acuerdo de alguna forma, porque si no, pues yo diría no, pues el Alex punto x es realmente cualquier cosa.

A ver, tú puedes tener tu propio resolver, tu propia, simplemente dices, ¿esto es un servidor raíz para mí? A partir de ahí, gestionas. Hay muchas empresas que para implementar la intranet, por ejemplo, hacen ese ese truco, ¿no?

Yo creo que es el punto final de la descentralización, es una capa que creo que no sé si ni siquiera tendría sentido descentralizar, porque, entonces, entraríamos en un poco algo más caótico, pero, bueno. A ver,

descentralización total nunca puedes tener, porque en el último de los casos tienes que tener un acuerdo en el protocolo en sí. Tienes que tener un acuerdo en el formato, en cómo se resuelve, en cómo funciona, tal No,

y que al final tu máquina tiene que tener una dirección IP específica que no la puede asumir que la tiene cualquier otra máquina, ¿no?

Claro, por ejemplo, ese tipo de de resoluciones tiene que caber, porque si no es una puerta al spam y al high jacking. Es decir, si cualquiera puede poner, pues yo voy a poner mi dominio, que apunte tu dirección para que el tráfico me venga para

mí y

ya hago yo lo que meta.

Eso es. Como un sistema de matrículas, es decir, o un registro civil, que tu DNI, tu nombre es tal, tal, tal y tal, porque si no, pues cada uno nos diseñaríamos nuestros DNIs y las matrículas de nuestros coches en nuestra casa y cada uno de su forma y cada uno de ese estilo, y sería todo algo algo confuso. Es decir, en ese sentido ya hemos tocado hueso con la descentralización. Bueno, yo he aprendido bastantes cosas, no solo lo del cuádruple A este, sino en general todo lo del eco y todas las las las grandes mejoras y un montón de funcionalidades. Muchas gracias, Ramón.

A ti por la conversación.

Eres una fuente de sabiduría para estas cosas.

Bueno, bueno, aquí estaba yo consultando el bar, que me estaba contando cosas. Sí, porque los los, acordarse de todos los registros que había vendido, y además, muchos más de los que no hemos contado, Es complicado.

De nuevo, suscribíos si no estáis suscritos, si estáis escuchando este podcast por primera vez, si ya lo conocéis, etcétera, y os apetece dejar una reseña, un comentario, una estrellita, una valoración en la plataforma donde lo estáis escuchando perfecto, y como siempre, comentarlo a otras personas, amigos, conocidos, etcétera, vecinos que le pueda interesar este tipo de episodios. Muchísimas gracias, don Ramón.

Don Alejandro.

Y a los oyentes, nos vemos en el próximo episodio de Don Tomás.