UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN UNA EMULACIÓN PARA ANYCAST TESIS PARA OPTAR AL GRADO DE MAGISTER EN CIENCIAS MENCION COMPUTACION SEBASTIÁN ENRIQUE CASTRO ÁVILA PROFESOR GUÍA: JOSÉ MIGUEL PIQUER GARDNER MIEMBROS DE LA COMISION: JUAN MAURICIO MARIN CAIHUAN JAVIER BUSTOS JIMENEZ FEDERICO MEZA MONTOYA SANTIAGO DE CHILE AGOSTO DE 2009

RESUMEN En los tiempos modernos no existe una tecnología que haya creado tanto impacto en tan poco tiempo como Internet. Físicamente es un conjunto de hardware y software que comunica sistemas, pero es la base para servicios que afectan positivamente la vida de las personas en el mundo. Dos de los pilares de software fundamentales para que el sistema opere son el Border Gateway Protocol o BGP (que permite que la comunicación entre puntos distantes encuentre su camino) y el Domain Name System o DNS, mecanismo que permite la utilización de nombres para recordar recursos. En el año 2002 la raíz del DNS enfrentó un masivo ataque de denegación de servicios, que trajo como consecuencia la búsqueda de medidas que redujeran los efectos de un nuevo ataque. Debido a restricciones en el número de servidores de la raíz, se optó por desplegar una tecnología llamada anycast que proveía una manera relativamente simple de replicar un servidor. Anycast ha sido estudiado por operadores e investigadores principalmente mediante el análisis de datos recolectados pasivamente en sistemas en producción. CAIDA y NIC Chile realizaron en Abril de 2007 un novedoso experimento que incluía la desactivación de un nodo anycast en funcionamiento. Aunque valiosa, la experiencia fue insuficiente para entender la percepción de falla de los clientes, lo que motivó la construcción de un emulador de anycast, donde el experimento pudiera ser replicado y donde se pudieran hacer variaciones que en el mundo real son imposibles. Esta tesis consiste en diseñar e implementar una metodología de emulación de redes de mediana escala, basada en la hipótesis que una emulación puede entregar resultados válidos en el mundo real. Para la creación del emulador fue necesario el estudio de los RFC que definen el DNS, los que definen BGP y varios papers que analizan las características topológicas de Internet, de modo de replicar su funcionamiento a nivel macroscópico con el mayor detalle posible y descubrir las limitaciones que nuestra hipótesis podría enfrentar. Implementado sobre servidores Linux con virtualización Xen y la estructura topológica de la Internet chilena observada en Abril de 2007, incorporando prácticas de ruteo BGP utilizadas por los proveedores nacionales y datos provístos por otros investigadores, fue posible replicar en el laboratorio el experimento original, probar la adición de un nodo anycast y explorar dos escenarios extremos, generando resultados similares a lo observado en la realidad. Los resultados obtenidos con la emulación fueron alentadores, dada la información pública disponible y lo complejo que en general resulta modelar un sistema como Internet. Las ideas surgidas de este trabajo pueden servir como base para la creación de un simulador automático basado otra implementación, que pueda servir a otros investigadores y operadores para extender el entendimiento de anycast o probar potenciales instalaciones de anycast.

AGRADECIMIENTOS A KC Claffy, directora de CAIDA por darme la oportunidad de trabajar con su grupo, asignarme tiempo para terminar mi tesis y guiarme en el proceso de convertirme en un científico. A Marina Fomenkov, mi supervisora en CAI- DA, por su constante presión para mantenerme en foco y haciendo progresos. A Duane Wessels, director de OARC, por permitirme usar su laboratorio para este experimento y asistirme en los primeros pasos. A mis colegas de CAIDA Young Hyun y Ken Keys por su ayuda con las herramientas de análisis, Brad Huffaker por compartir su experiencia estudiando la topología de Internet y Emile Aben por su perspectiva científica para analizar los problemas. A mis colegas de NIC Chile Mauricio Vergara y Marco Díaz, por contestar mis preguntas y permitirme utilizar la infrastructura anycast de NIC Chile para recolectar datos. A mi hermana, padre y madre por mantener siempre un ojo en mí y no dejarme bajar los brazos. A mis hijos Sergio y Florencia, por darme un motivo para ir siempre más allá, no dejar de superarme, para entregarles nuevas oportunidades y herramientas para el futuro. Finalmente, a mi esposa Maribel, que me alentó a dejar Chile para enfrentar nuevos desafíos, quien fue mi refugio en los días de tempestad, mi sombra en los días de agobiante sol.

Índice general 1. Introducción 1 1.1. Antecedentes Generales................................ 1 1.2. Justificación...................................... 2 1.3. Objetivos....................................... 3 1.3.1. Generales................................... 3 1.3.2. Específicos.................................. 3 1.4. Alcances........................................ 4 2. DNS: Descripción General 5 2.1. Introducción...................................... 5 2.2. Historia........................................ 6 I

2.2.1. Metas del Diseño del DNS.......................... 6 2.3. Descripción General................................. 7 2.3.1. Espacio de nombres............................. 8 2.3.2. Delegación.................................. 11 2.3.3. Mensajes................................... 12 2.3.4. Consultas (Queries).............................. 14 2.3.5. Respuestas.................................. 15 2.3.6. Servidores de Nombre y Zona........................ 16 2.3.7. Resolvers................................... 18 2.4. Resolución de nombres................................ 19 2.4.1. Los servidores de la raíz........................... 19 2.4.2. Tipos de consultas.............................. 20 2.4.3. Cómo se elije el servidor de nombres a consultar.............. 21 2.4.4. Caching.................................... 22 2.4.5. Time To Live (TTL)............................. 22 II

3. BGP: Descripción general 23 3.1. Introducción...................................... 23 3.1.1. Sistemas Autónomos............................. 24 3.2. Funcionamiento de BGP............................... 25 3.2.1. Protocolo................................... 25 3.2.2. Propagación de rutas BGP.......................... 26 3.2.3. Atributos................................... 27 3.2.4. Algoritmo de selección............................ 28 3.2.5. Otros conceptos................................ 30 4. Anycast 31 4.1. Introducción...................................... 31 4.2. Terminología..................................... 33 4.3. Anycast y el DNS................................... 34 5. Experimento Inicial 36 5.1. Introducción...................................... 36 III

5.2. Sobre la nube anycast de.cl............................. 36 5.3. Características generales del tráfico observado.................... 37 5.4. Ejecución....................................... 39 5.5. Resultados....................................... 40 5.5.1. La desactivación............................... 42 5.5.2. La reactivación................................ 42 5.6. Conclusiones..................................... 43 6. Emulación 44 6.1. Estudio previo..................................... 44 6.2. Introducción...................................... 45 6.3. Preparación previa.................................. 46 6.4. Construcción de la topología............................. 47 6.5. Implementación de la topología............................ 49 6.5.1. Implementación de la política de BGP.................... 53 6.5.2. Selección de los prefijos........................... 55 IV

6.5.3. Validación de la implementación....................... 55 6.6. Ejecución del experimento original.......................... 58 7. Emulación con DNS 62 7.1. Adicionando dosis de realidad............................ 62 7.2. Emulación 1: el experimento original......................... 63 7.3. Emulación 2: Adición de un nodo anycast...................... 65 7.3.1. Resultados.................................. 65 7.4. Emulación 3: Caída catastrófica del servidor unicast................. 68 7.4.1. Resultados.................................. 70 7.5. Emulación 4: Caída catastrófica de la nube anycast................. 70 7.5.1. Resultados.................................. 70 7.5.2. Discusión................................... 71 8. Conclusiones 72 8.1. Trabajo Futuro.................................... 74 9. Anexos 75 V

9.1. Definiciones y acrónimos............................... 75 9.2. Programas de apoyo.................................. 76 9.2.1. Mapeo de direcciones a AS.......................... 76 9.2.2. Generador de direcciones para túneles IP-IP................. 77 9.2.3. Generador de configuración BGP...................... 79 9.2.4. Plantilla para configuración BGP....................... 89 VI

Índice de figuras 2.1. Estructura jerárquica del espacio de nombres.................... 7 2.2. Estructura de un mensaje DNS............................ 12 2.3. Estructura de una consulta DNS........................... 15 2.4. Estructura de una respuesta DNS........................... 16 2.5. Ejemplo de un archivo de zona............................ 18 2.6. Descripción general del algoritmo de resolución................... 20 3.1. Ejemplo de los tipos de AS.............................. 24 3.2. Propagación de rutas................................. 27 3.3. Proceso de decisión de BGP............................. 29 4.1. Diferentes tipos de ruteo............................... 32 VII

5.1. Infraestructura anycast de.cl administrada por NIC Chile............. 37 5.2. Tráfico DNS durante el experimento......................... 40 5.3. Distribución de la carga generada por los Top 5 ASes entre los servidores de.cl durante el 18 de Abril de 2007............................ 41 5.4. Detalle de las consultas vistas para dos clientes al momento de la desactivación.. 43 6.1. Porcentaje acumulado de consultas por AS de origen................ 46 6.2. Extracto de la salida del comando show ip bgp................... 47 6.3. Topología derivada de la figura 6.2.......................... 48 6.4. Estimación del delay dentro de un AS de gran tamaño................ 52 6.5. Topología Física de la red utilizada para emulación................. 56 6.6. Volumen de consultas en el ambiente simulado................... 59 6.7. Distribución de consultas por nodo anycast..................... 59 6.8. Otras métricas observadas en el ambiente emulado................. 60 7.1. Distribución de consultas por nodo anycast durante la ejecución del experimento original en el ambiente emulado........................... 64 7.2. Distribución de consultas por nodo anycast en la activación de LAX........ 66 VIII

7.3. Variación del RTT observado para a.nic.cl después de la inclusión del nodo LAX. 67 7.4. Resultados de la emulación de caída catastrófica del servidor unicast (ns)..... 69 7.5. Resultados de la emulación de caída catastrófica de la nube anycast......... 69 IX

Capítulo 1 Introducción 1.1. Antecedentes Generales El Domain Name System (o DNS por sus siglas en Inglés) es una pieza clave para el funcionamiento de Internet, que a su vez es una pieza clave de la economía mundial en los tiempos modernos. El DNS provee una función simple pero transcendental: permitir la traducción de los nombres utilizados por las personas a números que los computadores entienden. Estos nombres pueden corresponder a una dirección de un sitio web, una dirección de correo o simplemente un nombre para un computador remoto. La utilización de nombres provee una manera natural de recordar un recurso. Por otro lado, los computadores conectados a Internet se identifican únicamente mediante la utilización de las direcciones IP, identificadores de 32 bits en el caso de la versión 4 del protocolo (128 bits para la versión 6), que cada computador contiene para ser alcanzada por otros computadores. Dada la estructura jerárquica del DNS, organizado como un árbol invertido, su raíz constituye un punto clave para su funcionamiento. Fueron los operadores de los servidores a cargo de la raíz del DNS los primeros en implantar anycast como una solución para proveer mayor capacidad, mejor tiempo de respuesta y adaptabilidad ante eventos catastróficos. A partir de ahí diversos dominios 1

de primer nivel empezaron a adoptar la tecnología, dentro de los cuales se encuentra NIC Chile. Anycast, para su funcionamiento a nivel global en Internet, depende de BGP 1. Este protocolo tiene una importancia fundamental, pues permite el intercambio de información de ruteo a nivel global, creando conectividad entre puntos distantes de modo escalable. Por tanto, esta tecnología plantea la interacción de dos de los protocolos que forman la base misma de Internet en su funcionamiento. El objetivo de esta tesis es proveer mayor conocimiento acerca de como anycast opera y proveer un mecanismo para simular cambios de configuración en una topología pequeña, de modo de entender con antelación los beneficios y desventajas de un cambio en la infraestructura que sirve a.cl 1.2. Justificación Las interacciones entre el DNS y la utilización de anycast han sido poco estudiadas, existiendo sólo un número reducido de organizaciones que han trabajado en el tema y que han explorado su funcionamiento conjunto. La percepción general de la comunidad es que es una buena solución, pero no existe conocimiento cabal de cómo funcionaría el sistema bajo ciertas condiciones de borde. La realización de simulaciones que repliquen el funcionamiento de Internet y las dinámicas de los protocolos de ruteo sufren de desafíos mayores: crear una topología real del tamaño de Internet no es factible por un problema de escala y porque hay detalles que no se pueden obtener; recrear una topología sintética va a respetar ciertos parámetros pero no replicar la situación real. 1 Border Gateway Protocol 2

1.3. Objetivos 1.3.1. Generales Demostrar que se puede desarrollar una metodología de emulación de Internet a nivel macroscópico que entregue resultados similares a la realidad. 1.3.2. Específicos Los objetivos que se deben lograr con esta tesis son: Investigar el funcionamiento del DNS a nivel del protocolo y sus implementaciones más comunes. Investigar el funcionamiento de BGP como protocolo de ruteo, detalles y mayores implementaciones en uso. Investigar herramientas y datos necesarios para la creación de un ambiente de simulación que se acerque a lo que se encontraría en el mundo real. Emular el comportamiento de una red con decenas de Sistemas Autónomos. Replicar situaciones reales en una emulación, validando que entrega los mismos resultados. Proveer una metodología que permita verificar con anterioridad el comportamiento del sistema anycast que sirve a.cl ante la adición de un nodo o falla de un nodo. Probar la interacción del mecanismo de selección basado en el RTT implementado por algunos resolvers con la convergencia de BGP durante la falla/adición de un nodo anycast. Emular situaciones críticas para generar escenarios posibles y obtener resultados. Generar recomendaciones concretas para la configuración de servidores de NIC Chile en base a estos experimentos. 3

1.4. Alcances Esta tesis abarca el estudio de BGP como protocolo de ruteo para proveer conectividad, pero no se extiende en otros usos que se encuentran en la realidad, como la ingeniería de tráfico o la habilitación de enlaces de respaldos. También se realizan algunas simplificaciones aceptables pero que reducen la riqueza en detalles que Internet tiene. La simulación de BGP está basada en información pública que puede contener errores u omisiones o en supuestos razonables en base a lo observado. Dado lo heterogéneo de Internet en cuanto a las implementaciones en operación, ese factor no es incluído en el trabajo. Los análisis sólo se realizaron en base a la infraestructura de NIC Chile para su implementación de anycast, debido al acceso privilegiado a detalles que no tendríamos de otro operador, y debido a que la escala de operación, servidores y conectividad corresponde al tamaño que pretendemos lograr emular. Eso no descarta el uso de las ideas y herramientas presentadas en esta tesis para otros operadores que tengan la información necesaria. 4

Capítulo 2 DNS: Descripción General 2.1. Introducción Luego de entender de manera básica la importancia del DNS, es necesario conocer un poco más a fondo su historia, sus principales componentes, su funcionamiento y el desempeño actual que tiene este importante servicio, temas de los que trata este capítulo. Con el simple fin de notar lo crítico del DNS, podemos contar una falla operativa que sufrió Microsoft en el año 2001. Debido a un error humano, todos los servidores de DNS responsables por dominios altamente reconocibles como microsoft.com y hotmail.com estuvieron inalcanzables por alrededor de 20 horas. Aunque sus servicios Web estaban en operación, los clientes no podían alcanzarlos por una falla en el DNS, generando pérdidas por millones de dólares. Este evento constituyó una lección para ellos y para otras organizaciones sobre la importancia del DNS y su adecuada administración [35, 43]. 5

2.2. Historia Los orígenes del DNS están fuertemente ligados a los orígenes de Internet. ARPAnet fue una red creada a fines de los años sesenta, financiada por el Departamento de Defensa del gobierno de los Estados Unidos, que se convertiría en lo que es ahora Internet. Para los años 70, ARPAnet era una comunidad pequeña y amistosa de unos cuantos cientos de nodos. Un sólo archivo, HOSTS.TXT, contenía las asociaciones entre nombres y direcciones para cada nodo conectado a la red. El archivo HOSTS.TXT era mantenido por el Stanford Research Institure (SRI) y distribuido desde una única fuente, el nodo SRI-NIC. Los cambios se recibían por correo electrónico, se compilaban y se publicaban dos veces por semana. En la medida que ARPAnet creció, este proceso se volvió inmanejable: la cantidad de tráfico, la colisión de nombres y problemas de consistencia dieron muestras de que el sistema no escalaba. 2.2.1. Metas del Diseño del DNS Una nueva alternativa se necesitaba para ARPAnet, que con su éxito había sobrepasado a su primitivo sistema de nombres. El objetivo era crear un sistema que resolviera los problemas inherentes a una tabla única. El nuevo sistema debería permitir una administración local, pero visibilidad global. La descentralización resolvería los problemas de cuellos de botella en un servidor y la administración local se encargaría de mantener la información actualizada. La utilización de un espacio de nombres jerárquico para asignar nombres para las máquinas aseguraba unicidad. El diseño original fue propuesto en 1984 y documentado en el RFC 882 y 883. Éstos fueron actualizados por el RFC 1034 y 1035, que permanecen siendo la especificación más actual y que sólo ha sufrido mejoras descritas en otros RFC posteriores. Su autor, Paul Mockapetris, trabajaba en ese entonces para ISI (Information Science Institute), dependiente de la USC (University of Southern California). 6

. NivelRaíz Nodo cl com net uchile puc ebay yahoo ripe php Dominiosde PrimerNivel Dominiosde SegundoNivel die dcc noc Dominio Figura 2.1: Estructura jerárquica del espacio de nombres 2.3. Descripción General El DNS es una base de datos distribuída. Esta estructura permite el control local de ciertas partes del sistema completo, aunque los datos de cada parte estan disponibles a lo largo de toda la red a través de un esquema de cliente/servidor. Robustez y adecuado rendimiento son alcanzados mediante replicación y caching. Los servidores de nombre son programas que constituyen la primera mitad de esquema del DNS. Éstos contienen la información acerca de algunos segmentos de la base de datos y la hacen disponible para los clientes, llamados resolvers. Estos resolvers pueden ser simples rutinas de sistema que crean una consulta y la mandan a través de la red (usualmente llamados stub resolvers) o bien un programa que recibe consultas, las reenvía y guarda una copia de lo recibido (llamados cache resolvers). La estructura de la base de datos del DNS está organizada como un árbol invertido (ver Figura 2.1), tal como el sistema de archivos en un sistema Unix. Cada nodo tiene una etiqueta, que lo identifica relativo a su padre. El nodo raíz tiene la etiqueta especial.. 7

Cada nodo es además la raíz de un subárbol, lo que constituye una partición de la base de datos completa y recibe el nombre de dominio. Cada dominio puede ser subdivido en particiones menores, llamadas subdominios. Cada dominio tiene un nombre único, llamado nombre de dominio. Esto permite identificar su posición dentro de la base de datos. Cada nombre de dominio está construído como una secuencia de etiquetas desde la raíz del dominio hasta la raíz del árbol, separado por un punto (.). Como la idea original era la descentralización de la administración, cada dominio puede ser dividido en subdominios y la responsabilidad de cada uno asignada a diferentes organizaciones. Este concepto en el DNS se conoce como delegación y constituye una pieza clave de su escalabilidad. 2.3.1. Espacio de nombres A partir de la figura 2.1 se puede observar la raíz y un conjunto de hijos de esa raíz con sus respectivas etiquetas. Los hijos de la raíz se conocen como dominios de primer nivel que llamaremos de ahora en adelante TLD ( Top Level Domain por su nombre en inglés). Originalmente se definieron dos tipos de TLDs: los genéricos y los códigos de países. Los TLD genéricos descritos originalmente en el RFC 920 [54] incluían restricciones sobre el tipo de organizaciones que podían solicitar un subdominio bajo él. Dichas condiciones fueron eliminadas a partir de 1996. En los comienzos, correspondían a: GOV: Destinado para cualquier organización de gobierno (de los Estados Unidos). EDU: Destinado para cualquier organización educacional. COM: Destinado para cualquier organización comercial. MIL: Destinado para las organizaciones militares (de los Estados Unidos). ORG: Destinado para organizaciones que no calzaran con las condiciones anteriores. 8

Al mismo tiempo se definió el TLD especial ARPA que cumplió la función de proveer un espacio de nombres para traducir las direcciones IP a nombres; también fueron definidos los dominios para países o cctld (Country Code Top Level Domain) basados en la lista de códigos de dos letras que identifican a los países de acuerdo al estándar ISO-3166-1 [28]. En 1994 mediante el RFC 1591 [39] se documentó la existencia del TLD genérico NET utilizado para identificar a los proveedores de Internet (que curiosamente fue definido junto con los gtlds originales, pero no fue documentado) e INT para organizaciones internacionales creadas por leyes o tratados internacionales, como la OTAN (Organización del Tratado Atlántico Norte nato.int) o la OMPI (Organización Mundial de la Propiedad Intelectual wipo.int). A finales de 2000, ICANN seleccionó siete nuevos TLD genéricos. Tres de ellos corresponden a la categoría de sponsored: AERO, COOP y MUSEUM fueron solicitados por agrupaciones de organizaciones interesados en contar con esos TLD para sus representados. Los otros cuatro (BIZ, INFO, NAME y PRO) no corresponden a esa categoría. En Octubre de 2008, tras un proceso público de discusión, ICANN decidió liberar el proceso de creación de nuevos TLD, aceptando la proposición de nuevos nombres por parte de la comunidad. El efecto de esta medida no es posible aún de predecir, pero puede generar un mayor impacto en el sistema completo del DNS. Todos los dominios deben cumplir con ciertas restricciones definidas en el RFC 1034. Cada etiqueta puede tener un largo entre 1 y 63 caracteres (la raíz es una excepción), un dominio no puede tener más de 127 niveles, más de 255 caracteres de largo (incluyendo los puntos) y el rango de caracteres válidos son los alfanuméricos (minúsculas y mayúsculas son equivalentes) y el guión. En Marzo de 2003 se publicó el RFC 3490 [13] que introduce el concepto de IDNA (Internationalized Domain Names in Applications), permitiendo el uso de los caracteres Unicode en los nombres de dominio. Por ejemplo, una aplicación que soporte IDNA podrá visitar el sitio http://www.ñandú.cl. Con el fin de mantener la compatibilidad a nivel del protocolo, estos nombres con caracteres extendidos son traducidos a una secuencia de caracteres válidos (US AS- CII) utilizando la codificación ACE (ASCII Compatible Encoding). De ese modo, el nombre IDNA mencionado anteriormente se verá a nivel del protocolo DNS como www.xn--and-6ma2c.cl. 9

Registro de Recursos (RRs) La información asociada a los nombres de dominio está contenida en los Resource Records o RR. Los RR están divididos en tres clases: para redes basados en el protocolo Chaosnet existe la clase CH (Chaos); las redes usando el software Hesiod tienen la clase HS y las redes basadas en TCP/IP utilizan la clase IN. Esta última es por lejos la más popular. Dentro de cada clase existen diversos tipos de RR, que corresponden a los diferentes tipos de datos que se pueden almacenar en el espacio de nombre de dominios. Originalmente fueron definidos en el RFC 1034 los siguientes tipos: A (Address) Una dirección de host CNAME (Canonical Name) Especifica el nombre canónico de un alias HINFO (Hardware INFO) Muestra infomación del host, como el Sistema Operativo y CPU MX (Mail exchange) Especifica un servidor de email para el dominio. NS (Name Server) Indica un servidor de nombres autoritativo para el dominio PTR (PoinTeR) Es un puntero a otra parte del espacio de nombres de dominios SOA (Start of Authority) Identifica el inicio de una zona y los parámetros operativos que gobiernan su funcionamiento. Posteriormente se fueron agregando otros tipos, de los cuales mencionaremos los más relevantes: SRV Definido en el RFC 2782 [60] describe la ubicación de los servidores para un protocolo y dominio específico. AAAA Definido originalmente en el RFC 1886 [5] y luego actualizado en el RFC 3596 [14], almacena una dirección IPv6 para un host. 10

A6 Fue definido originalmente en el RFC 2874 [27] con el objetivo de reemplazar los registros AAAA, agregando ciertas características al registro que facilitaría el cambio de numeración de una red. Tras un tiempo de coexistencia y dadas las complicaciones asociadas a su implementación e instalación, se decidió pasar el estándar a estado experimental (RFC3363 [7], RFC3364 [2]), lo que implica en la práctica declararlo como abandonado. DNAME Introducido en el RFC 2672 [26] se utiliza para crear una equivalencia o alias de un nombre de dominio completo y fue creado para facilitar migraciones de organizaciones. NAPTR Definido en el RFC 2915 [44], especifica una regla basada en expresiones regulares que al ser aplicada generara un nuevo nombre de dominio o una URI (Uniform Resource Identifier). 2.3.2. Delegación Como se mencionó anteriormente, la delegación es un concepto fundamental para el DNS, pues permite una administración descentralizada. Una organización a cargo de un dominio puede dividirla en subdominios. Cada subdominio puede ser delegado a otras organizaciones, lo que se traduce en que dicha organización se vuelve responsable de mantener la información para ese subdominio. Puede cambiar su contenido libremente e incluso dividir su subdominio en más sub-subdominios y delegarlos. El dominio padre, por tanto, mantiene punteros a las fuentes de los datos de los subdominios. La delegación no es obligatoria, pero en muchos casos resulta conveniente. Así, por ejemplo, el TLD.CL bajo la administración de NIC Chile delega subdominios a diversas organizaciones y éstas a su vez pueden dividir su subdominio en partes más pequeñas. Un excelente ejemplo de aquello son las universidades: NIC Chile delega el dominio puc.cl a la Pontifica Universidad Católica de Chile, quien a su vez delega el subdominio ing.puc.cl a su Facultad de Ingeniería y el dominio med.puc.cl a la Escuela de Medicina. 11

2.3.3. Mensajes El protocolo DNS define operaciones que se agrupan en dos clases: consultas y mantención de la zona. Las consultas buscan obtener información almacenada en las zonas, mientras que las operaciones de mantención (dentro de las que se cuentan la transferencia de zona, actualizaciones y notificaciones) fueron diseñadas para facilitar la administración de una zona. Cada operación se traduce en un requerimiento que viaja en un mensaje y que genera una respuesta que será transmitida en uno o más mensajes. Cada mensaje en el DNS tiene una estructura definida: un encabezado, una sección de consulta (QUESTION), una sección de respuesta (ANSWER), una sección de autoridad (AUTHORITY) y una sección para información adicional (ADDITIONAL) (Figura 2.2a). El encabezado de un mensaje DNS tiene un largo fijo de 12 bytes y contiene información relevante para distinguir el tipo de mensaje, el largo del contenido de cada sección y otros parámetros (Figura 2.2b). DNS Message Header Question Section Answer Section Authority Section Additional Section (a) Mensaje DNS Message Header 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ID QR Opcode AA TC RD RA Z RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT (b) Encabezado de un mensaje Figura 2.2: Estructura de un mensaje DNS Los campos incluídos en el encabezado de un mensaje DNS son: ID Campo de 16 bits que representa un entero sin signo (con un rango de valores posibles entre 0 y 65535), se utiliza para hacer calzar una respuesta a su requerimiento de origen. Es asignado por el programa que genera el mensaje. 12

QR Es un campo de un bit que indica si el mensaje de una consulta (QR=0) o una respuesta (QR=1) OPCODE Es un campo de 4 bits (16 valores distintos) que indica que tipo de consulta que trae el mensaje. Los valores válidos en la actualidad incluyen: 0, una consulta (QUERY) 1, una consulta inversa (IQUERY). Este código de operación fue eliminado por el RFC 3425. [49] 2, una solicitud de estado (STATUS) 3, reservado 4, notificación de actualización de zona (NOTIFY) [36] 5, actualización de una zona (UPDATE) [38] 6-15, reservados. AA Authoritative Answer, es un campo de un bit que indica si la respuesta viene de un servidor con autoridad o no. TC Truncation, especifica que el mensaje fue cortado (no contiene toda la información disponible para la consulta) debido a que el largo total excedía lo permitido por el protocolo de transporte (en el caso de UDP, este valor es de 512 bytes). RD Recursion Desired, campo de un bit que se activa en la consulta para indicarle al receptor que la consulta debe contestarse recursivamente (averiguar todo lo posible). Su ausencia indica que la consulta es iterativa (contesta lo que sepa). RA Recursion Available, campo de un bit utilizado por un servidor para indicar que atiende consultas recursivas. Si un servidor que no provee recursión recibe una consulta recursiva, la tratará como si fuera iterativa. Z Tres bits reservados para futuros usos. RCODE Response code, campo de 4 bits que tiene significado solo en las respuestas. Los valores posibles son: 0, sin errores (NOERROR). 1, Format Error (FORMERR). El servidor fue incapaz de interpretar la consulta. 2, Server Failure (SERVFAIL). El servidor fue incapaz de procesar la consulta debido a un problema interno. 3, Name Error (NXDOMAIN). También conocido como Dominio no existente, indica que el nombre consultado no existe. 4, Not Implemented (NOTIMP). El servidor no implementa lo requerido por la consulta. 13