El sistema de nombre de dominios de Internet explicado para los no expertos. Memorando de Internet Society n.º 16 por Daniel Karrenberg*

Transcripción

1 El sistema de nombre de dominios de Internet explicado para los no expertos. Memorando de Internet Society n.º 16 por Daniel Karrenberg* El sistema de nombres de dominios de Internet explicado para los no expertos Estimados no expertos: Esta introducción se ha creado pensando en ustedes, que siempre quisieron o necesitaron saber cómo funcionan los nombres de Internet. El sistema de nombres de dominio (DNS) de Internet es una tecnología fascinante; casi todas las aplicaciones de Internet la usan. Cuando haya leído esta introducción, no se convertirá en un experto de DNS de repente, pero entenderá como funciona DNS y podrá distinguir entre expertos en DNS e impostores. Estimados expertos: Este documento no es para ustedes. Aquí generalizaremos a menudo para explicar mejor los principios hasta el punto en el que algunas explicaciones no sean correctas, estrictamente hablando, hasta el último detalle. Podrán encontrar una descripción más detallada en los estándares de Internet correspondientes. El objetivo de DNS El objetivo de DNS es permitir que las aplicaciones de Internet y sus usuarios den un nombre a cosas que no tienen un nombre global único. El beneficio más claro es el uso de nombres de fácil memorización para cosas como páginas Web y cuentas de correo electrónico, más que memorizar números largos o códigos. El beneficio menos obvio, pero de igual importancia, es la separación del nombre de algo de su ubicación. Las cosas se pueden mudar a una ubicación completamente diferente en la red, de manera transparente, sin cambiar el nombre. puede estar en un ordenador de Virginia hoy y en otro ordenador de Ginebra mañana sin que nadie se dé cuenta. Para conseguir esta separación, los nombres se tienen que traducir en otros identificadores que las aplicaciones usan para comunicarse a través de los protocolos apropiados de Internet. Veamos qué pasa cuando me envía un mensaje de correo electrónico a Daniel.karrenger@ripe.net! Un servidor de correo, que intenta entregar el mensaje, tiene que encontrar dónde se tiene que enviar el correo de los buzones de ripe.net. Es en este momento

2 cuando DNS entra en juego. El servidor de correo transmite esta pregunta, llamada consulta en la terminología DNS, al DNS. Y recibe rápidamente la siguiente respuesta: ripe.net IN MX 100 postman.ripe.net. ripe.net IN MX 150 postboy.ripe.net. Los correos de ripe.net deberían enviarse primero al ordenador llamado postman.ripe.net. Si postman.ripe.net no está disponible, prueba postboy.ripe.net. El servidor hará una conexión con postman.ripe.net. Para hacerlo, necesita saber la dirección numérica de Internet de postman.ripe.net. Esta dirección numérica es suficiente para enviar paquetes de Internet al ordenador llamado postman.ripe.net desde cualquier parte de Internet. Se vuelve a consultar a DNS y este contesta postman.ripe.net IN A A partir de este momento, el servidor de correo que entrega su mensaje puede comunicarse directamente con el servidor de correo que recibe y almacena mi correo para que yo lo pueda leer más adelante. Es obvio que la información que hemos obtenido antes, para el ejemplo, no proviene de una lista central que está en algún sitio. Esta lista sería demasiado larga, cambiaría demasiadas veces y su repositorio se vería abrumado rápidamente por el número de consultas. Así que, cómo funciona? Sigamos a la consulta DNS que se inicia en su ordenador! Su ordenador conoce la dirección de un servidor de almacenamiento en caché de DNS que está cerca y enviará la consulta al mismo. Los servidores de almacenamiento en caché normalmente ofrecidos por aquellos que le proveen del servicio de conexión de Internet. Puede tratarse de su proveedor de servicios de Internet (ISP) en una configuración residencial o su departamento empresarial de TI en un entorno de oficina. Su ordenador aprenderá la dirección de los servidores de almacenamiento en caché disponibles de forma automática cuando se conecte a la red o su administrador de redes la configurará de manera estática. Cuando la consulta llegue al servidor de almacenamiento en caché existe la posibilidad de que este servidor sepa la respuesta porque la recuerda, la tiene en caché en terminología de DNS, de una transacción anterior. De modo que si alguien que usa el mismo servidor de almacenamiento en caché ha enviado un correo a ripe.net recientemente, la información necesaria ya estará disponible, y todo lo que el servidor de almacenamiento en caché tiene que hacer es enviar las respuestas guardadas a su ordenador. Ahora ya entiende cómo el almacenamiento en caché acelera, de manera considerable, el tiempo de respuesta para consultas de nombres populares. Otro efecto importante del almacenamiento en caché es la reducción de la carga en DNS, ya que muchas consultas no pasan de los servidores de almacenamiento en caché. Detalle: jerarquías de caché Los servidores de almacenamiento en caché también se pueden organizar en una jerarquía. Esta operación tiene sentido en casos en los que la capacidad de la red esté limitada o la latencia de la red entre el servidor DNS y el resto de Internet sea alta. Cuando conecta un portátil a Internet a través de una conexión de acceso telefónico lenta, tiene sentido ejecutar un 2

3 servidor de almacenamiento en caché desde el portátil. De esa forma, cada vez que hace clic en un hiperenlace en el mismo sitio Web, no tendrá problemas de tráfico de DNS con el enlace de acceso telefónico. Ese tipo de servidor de almacenamiento en caché se configura a menudo para enviar todas las consultas para las que no tiene respuestas en caché al servidor de almacenamiento en caché del ISP. En ocasiones, las redes empresariales cuentan con servidores de almacenamiento en caché locales que en su lugar enviarán consultas a servidores de almacenamiento en caché empresariales antes de enviar la información a Internet. De este modo, el servidor de almacenamiento en caché empresarial puede crear una caché más amplia basándose en todas las consultas de la empresa. Más allá de la caché Si el servidor de almacenamiento en caché no encuentra la respuesta a la consulta en su caché, tiene que encontrar otro servidor de DNS que tenga la respuesta. En nuestro ejemplo, buscará un servidor que tenga las respuestas para los nombres que terminen en ripe.net. En terminología de DNS, tal servidor se considera autoritativo para el dominio de ripe.net. En muchos casos, el servidor de almacenamiento en caché ya conoce la dirección del servidor autorizado de ripe.net. Si alguien que ha usado el mismo servidor de almacenamiento en caché ha navegado recientemente por el servidor de almacenamiento en caché buscó y encontró el servidor autoritativo para ripe.net en ese momento, y como es un servidor de almacenamiento en caché, evidentemente guardó la dirección del servidor autorizado. De modo que el servidor de almacenamiento en caché enviará la consulta sobre el servidor de correo ripe.net al servidor autorizado de ripe.net, recibirá una respuesta, enviará una respuesta a través de su ordenador y guardará la respuesta en la caché. Tenga en cuenta que hasta el momento solo el servidor de almacenamiento en caché y el servidor autorizado de ripe.net han respondido a esta consulta. Redundancia: muchos servidores con las mismas respuestas Pero, qué pasaría si no encuentra el servidor de almacenamiento en caché local o el servidor autorizado de ripe.net? Obviamente, su servidor de correo no obtendría una respuesta y no podría entregar su mensaje de inmediato. Pondría su mensaje en la cola y volvería a intentarlo después. Sin embargo, si su navegador web necesitase encontrar la dirección cuando hizo clic en un hiperenlace de ese sitio, la respuesta sería diferente. El navegador parecería estar parado mientras espera a que se resuelva la consulta de a una dirección numérica puesto que no podría ponerse en contacto con el servidor web sin conocer esa dirección numérica. En ese caso, o se aburriría de esperar y haría otra cosa, o su navegador le daría un mensaje de error cuando hubiese pasado el tiempo de espera para la consulta DNS. Esto no sucede a menudo porque hay mucho potencial para la redundancia en la arquitectura de Internet, en especial de DNS. Para asegurar una gran disponibilidad, DNS tiene múltiples servidores con los mismos datos. Para resolver el problema de falta de disponibilidad del servidor de almacenamiento en caché local, su ordenador normalmente tiene varios configurados entre los que puede elegir uno. De ese modo, nos aseguramos de que siempre haya un servidor de almacenamiento en caché disponible. Pero, qué ocurre con los servidores autorizados? 3

4 Para mejorar la disponibilidad de los servidores autorizados de nombres siempre se cuenta con varios para cada dominio. En nuestro ejemplo de ripe.net, existen cinco servidores, tres en Europa, uno en Norteamérica y uno en Australia. ripe.net IN NS ns.ripe.net. ripe.net IN NS ns2.nic.fr. ripe.net IN NS sunic.sunet.se. ripe.net IN NS auth03.ns.uu.net. ripe.net IN NS munnari.oz.au. Nuestro servidor de almacenamiento en caché no cuenta únicamente con un lugar para buscar información autorizada sobre los nombres de ripe.net sino con cinco, todos ellos con el mismo nivel de autorización. Puede elegir libremente cualquiera de ellos, dependiendo de sus preferencias, ya que todos tienen la misma información. La elección puede ser aleatoria o basada en los tiempos de respuesta de esos servidores. Es importante recordar que cualquier elección es válida. Este mecanismo ofrece el potencial de una redundancia muy fuerte que cubre al servidor y a los problemas de conexión, puesto que los servidores pueden estar ubicados en cualquier lugar de Internet. Está claro que el nivel de redundancia real depende del diseño y la ubicación de los servidores. Una empresa bastante grande descubrió este hecho hace unos años cuando dos de sus servidores autorizados de dominio que estaban en la misma sala de ordenadores no podían encontrarse desde Internet debido a un problema de redes que no podía ser. Introducir información en los DNS Se escribe información en DNS cambiando las bases de datos que los servidores autorizados de dominio usan para responder a las consultas. Cómo se mantienen esas bases de datos y cómo se transmiten a los servidores es una implementación local, completamente transparente para los clientes de DNS y fuera del alcance de esta descripción. Para los dominios más pequeños, a menudo se cambia un archivo de texto local en uno de los servidores autorizados y luego se transfiere el cambio al resto. En este caso, el servidor autorizado en el que se mantiene el archivo principal se considera el principal y el resto de los servidores autorizados los servidores secundarios. Sin embargo, esta distinción es invisible para el resto de DNS puesto que todos los servidores se consideran iguales en términos de autorización. Subir en la jerarquía Ahora pensemos en la siguiente situación: cuando el servidor de almacenamiento en caché acaba de iniciarse y tiene una caché vacía. Por consiguiente, no conoce la respuesta a su consulta ni sabe dónde están los servidores autorizados de ripe.net. Sin embargo, sabe que es posible hacer preguntas sobre ripe.net a un servidor autorizado de net ya que los puntos separan las diferentes partes de un nombre de dominio. Este conocimiento forma misma del protocolo de DNS, que implica: en caso de desconocer los servidores autorizados de un servidor, elimine la parte izquierda del nombre incluyendo el primer punto y envíe la consulta original a un servidor autorizado para encontrar el nombre. En nuestro ejemplo, el servidor autorizado de net no conoce la respuesta a la consulta something.ripe.net, ya que solo los servidores ripe.net tienen esa información, pero sabe cuáles son los servidores autorizados para las consultas ripe.net. De modo, que en lugar de responder 4

5 a la consulta, el servidor net responderá con una lista de los servidores autorizados de ripe.net, una referencia en terminología DNS. El servidor de almacenamiento en caché recibirá la referencia de los servidores ripe.net. Al igual que en los ejemplos anteriores, luego hará la pregunta a uno de los servidores autorizados de ripe.net, obtendrá la respuesta y la reenviará al cliente que mandó la consulta. Además, como es un servidor caché, guardará la respuesta y la lista de servidores autorizados de ripe.net para usarlos en el futuro. Sencillo. Pero, un momento, hemos asumido que la caché estaba vacía, de modo, que, cómo sabe el servidor de almacenamiento en caché dónde están los servidores autorizados de net? En otras palabras, qué pasa cuando hemos quitado todas las partes del nombre de dominio y aún no sabemos dónde buscar la respuesta? Para este caso, existe un conjunto especial de servidores autorizados, los servidores raíz de DNS. Estos servidores conocen las direcciones de todos los servidores autorizados de los nombres que no tienen un punto detrás, los dominios de nivel superior (TLD) como org, com, ch, uk. Los servidores raíz son los únicos servidores DNS que se tienen que encontrar sin necesidad de información en la caché. Para resolver este problema de arranque, todos los servidores de almacenamiento en caché tienen una lista preconfigurada de las direcciones numéricas de todos los servidores raíz. Cuando se inicia, un servidor de almacenamiento en caché enviará consultas a la lista actual de servidores raíz para obtener cada una de esas direcciones y en su lugar obtendrá una respuesta. Una vez que ha obtenido la lista, sabe dónde puede enviar consultas para nombres que no tienen puntos. Esto suena a algo innecesariamente complicado, pero asegura que el servidor de almacenamiento en caché seguirá funcionando aún cuando las direcciones de los servidores raíz cambian pero la lista preconfigurada no se ha actualizado. Estas direcciones cambian poco, pero lo hacen de cuando en cuando. Un servidor de almacenamiento en caché podrá usar todos los servidores raíz siempre y cuando pueda alcanzar una de las direcciones preconfiguradas. Nombre de dominio Los puntos dividen los dominios en diferentes partes. Esta división divide todos los nombres en diferentes dominios en los que la misma parte de un nombre se puede volver a usar, por ejemplo, ripe.net no es lo mismo que ripe.org. Lo más importante, estos dominios pueden tener un administrador completamente diferente. El administrador de los nombres net no tiene por qué saber nada de los dominios org. El dominio org es independiente del dominio net. Debido a la naturaleza jerárquica de esta estructura, los administradores de subdominios de un dominio pueden ser independientes, por ejemplo isoc.org no tiene que coordinarse con nanog.org, ni siquiera conocerlo. Un último ejemplo Una vez más, observe qué pasa cuando un servidor de almacenamiento en caché que acaba de iniciarse recibe una consulta para la dirección Después de iniciarse, el servidor obtuvo la lista de los servidores raíz y sus direcciones. Cuando la consulta llegue, no encontrará la respuesta para en la caché, tampoco tendrá la dirección del dominio autorizado isoc.org, ni la dirección del servidor autorizado de org. Como no tendrá otra elección, le pedirá al servidor raíz la dirección de El servidor raíz contestará con una referencia de la lista de los servidores autorizados de org. Nuestro servidor caché enviará la consulta de a uno de ellos y obtendrá otra lista de referencia de todos los servidores 5

6 autorizados de isoc.org. Cuando envíe la consulta a uno de esos servidores, recibirá la respuesta. Todo ello sucede típicamente en menos de un segundo. A partir de ese momento, el servidor de almacenamiento en caché puede responder a la misma consulta una y otra vez, desde la caché sin tener que consultar a otro servidor. También puede enviar cualquier consulta something.isoc.org directamente a un servidor isoc.org y enviar una pregunta directamente a un servidor autorizado de org sobre una consulta.org. Solo cuando la consulta termine en algo que no sea.org tendrá que volver a buscar en el servidor raíz. La caché pronto tendrá listas de los servidores autorizados de los dominios más populares, en especial de los TLD populares; Normalmente el servidor de almacenamiento en caché no tendrá que volver a consultar esta información durante varios días. Este diseño nos asegura que solo una pequeña fracción de todas las consultas las procesan los servidores raíz o los servidores autorizados de TLD. 6

7 Gestión de cambios Qué pasa cuando la información de los servidores autorizados se ha actualizado pero los servidores de almacenamiento en caché del mundo aún tienen en caché la información antigua y posiblemente incorrecta? Aquí es donde el tiempo de vida (TTL) del DNS entra en juego. Cada parte de la información de DNS se puede guardar en caché por separado y tiene un tiempo de vida asociado. Cuando este tiempo vence, la información en caché se elimina y se tiene que volver a obtener de un servidor autorizado si es necesario. TTL no se configura de manera local en el servidor local, sino en el servidor autorizado y se transmite junto con la información en sí. De esta manera el administrador de un dominio, pude controlar el tiempo que tarda en hacerse conocer un cambio en todo Internet. Al elegir bien los valores, se puede configurar el intercambio entre poder cambiar las cosas con rapidez, por un lado, y minimizar los recursos informáticos y de redes necesarios para los servidores de redes, por otro lado. Si no se espera que la información en particular vaya a cambiar en el futuro, se puede configurar una TTL alta, también se puede configurar una TTL baja para información que cambiará a menudo. La práctica normal es reducir la TTL transmitida con la información que se va a cambiar, de modo que el cambio se haga visible más rápido en todo Internet; Cuando se ha hecho el cambio, TTL vuelve a aumentar. Con esto termina nuestra introducción a DNS para no expertos. Esperamos que la haya disfrutado y haya adquirido un conocimiento básico de uno de los pilares de Internet de hoy en día. Igual está interesado en tener más información sobre temas relacionados para personas no expertas. En estos momentos estamos preparando introducciones similares sobre la actual evolución del sistema de servidores raíz de DNS. 7

8 Una cobertura mayor por parte de Internet Society Artículos detallados, artículos académicos, enlaces y otros recursos disponibles en: RFC relevantes sobre IETF Las RFC básicas que describen DNS son: 1034 Nombres de dominio: conceptos e instalaciones 1035 Nombres de dominio: implementación y especificaciones Estas RFC se han actualizado y ampliado en numerosas RFC incluyendo: RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308, RFC2535, RFC2845, y RFC3425. Acerca del autor Daniel Karrenberg trabaja en RIPE NCC como Director científico. Está interesado en medidas de Internet, el desarrollo de DNS y la evolución de lo que otras personas llaman a menudo la Gobernanza de Internet. En 1990, Daniel lideró la fundación de RIPE NCC, el primero de los Registros Regionales de Internet. Ha ayudado a dar forma a la política de distribución de direcciones de Internet, transfiriendo el desarrollo y la implementación de la política a la región. También trajo a Europa el segundo servidor raíz de nombres DNS en Internet Society Galerie Jean-Malbuisson 15 CH-1204 Ginebra, Suiza Tel: Fax: Wiehle Ave. Suite 201 Reston, VA 20190, EE. UU. Tel.: Fax: Correo electrónico: info@isoc.org En los 80, Daniel ayudó a construir EUnet y lideró la labor de transición a los Protocolos de Internet, lo que convirtió a EUnet en el primer ISP paneuropeo y trajo conexiones de Internet a muchos lugares en y alrededor de Europa. Reconocimientos La serie de documentos informativos para miembros de ISOC es posible gracias a la generosa ayuda de los patrocinadores platino de ISOC: Afilias, APNIC, ARIN, Microsoft, Qualys, Ripe NCC y Agencia sueca de cooperación internacional para el desarrollo. Más información sobre el programa de patrocinio platino: 8