Medidas de Performance y Estadísticas de Servidores Recursivos de DNS

Transcripción

1 Medidas de Performance y Estadísticas de Servidores Recursivos de DNS Trabajo final del curso de Posgrado Performance en Redes de Telecomunicaciones. Alvaro Valdés (valdes@fing.edu.uy) Abstract: El Sistema de Nombre de Dominio (DNS) es una parte esencial de la infraestructura actual de Internet. El servicio de DNS recursivo forma parte de la Infraestructura habitual que posee un Internet Service Provider (ISP) y es servicio siempre presente en los accesos de asignación dinámica de dirección IP. En la actualidad el aumento de ancho de banda de acceso de usuarios junto con el diseño incorrecto de aplicaciones, la constante aparición de virus y gusanos, las exigencias de seguridad de verificación de reversos y la utilización de herramientas de lucha contra el SPAM basadas en DNS; son parte de las tareas cotidianas que debe afrontar un sistema de DNS de recursivos. El presente trabajo esta enfocado a definir y realizar medidas de indicadores de performance del sistema, en particular la generación de herramientas para tal fin. conjunto de etiquetas separadas y (opcionalmente) finalizadas por el delimitador punto.. Por ejemplo: Las etiquetas se encuentra formadas por caracteres: letras (ASCII), números y "-". Una etiqueta debe comenzar siempre con una letra, y cada etiqueta puede llevar hasta 63 caracteres. El nombre de dominio en total puede tener hasta 255. Y puede haber hasta 127 niveles. El DNS realiza una ordenación jerárquica de nombres de dominio, implementada como una base de datos distribuida. Todos los dominios posibles forman una estructura jerárquica en forma árbol conocida como espacio de nombres. El espacio de nombres es un árbol invertido donde los nodos son etiquetas. A la raíz se llama root y tiene etiqueta.. Un nombre de dominio se lee en forma ascendente, ver figura 1 para anglo.edu.uy. 1. Introducción El DNS es uno de los protocolos indispensables en la actualidad para poder acceder a Internet. Su importancia radica en que todas las aplicaciones que se conectan a Internet hacen uso del mismo para su funcionamiento. La función más básica del DNS es la de traducir nombres en direcciones IP. También provee información adicional sobre dominios o hosts, permite realizar traducciones inversas de direcciones IP a nombres, informa sobre los equipos que puede recibir correos para un determinado dominio, etc. El DNS surge como respuesta al hecho natural de que a las personas les es mas sencillo recordar nombres que direcciones IP. vs Figura 1. Estructura Jerárquica del espacio de Nombres La raíz se administra de forma centralizada, y esta compuesta por trece servidores bien conocidos (formalmente trece direcciones IP diferentes) y distribuidos en el mundo. Un dominio es un subárbol del espacio de nombres de dominios. La mayoría de las aplicaciones de usuario utilizan el DNS, por ejemplo un browser HTTP, clientes de correo electrónico, Telnet, SSH, FTP, etc. La finalidad del DNS es facilitar la comunicación con los equipos ubicados en la red; haciendo referencia por nombre en vez de direcciones numéricas (direcciones IP). Permitiendo de esta manera realizar una organización lógica y flexible sobre una organización numérica mas rígida. 2. Descripción del Funcionamiento del DNS La especificación original del DNS es esta dada en las RFC 1034 y RFC 1035, a modo de resumen el DNS es un Figura 2. Delegación para el dominio fing.edu.uy. Medidas de Performance en Servidores Recursivos de DNS hoja 1 de 9

2 Cada etiqueta ocupa un determinado nivel en el árbol:...tercer_nivel.segundo_nivel.primer_nivel. Por ejemplo fing.edu.uy. uy dominio de primer nivel. edu.uy dominio de segundo nivel. fing.edu.uy dominio de tercer nivel. Se dice que fing es hijo de.edu.uy. Se dice que.edu.uy. es padre de fing. Los distintos dominios son administrados por distintas instituciones. Por ejemplo ICANN es el encargado del dominio root, mientras que el SeCIU del dominio.uy.(y también de.edu.uy.) y la Facultad de Ingeniería del.fing.edu.uy. Cada entidad administrativa cuenta con sus propios servidores de nombres, alojando la porción de la base de datos que le corresponde. De esta forma cuando una nueva consulta se realiza sobre el sistema, cada entidad responde por sus propios dominios. La estructura jerárquica se administra delegando los subárboles. Delegar es asignar responsabilidades de administración de un subdominio a otra organización. Una organización es autoritativa de un dominio si la organización de nivel superior se lo delegó. Quien administra un dominio es responsable por los subdominios (y a su vez puede delegarlos). La delegación determina como se distribuyen los datos en la base de datos distribuida. Los servidores de nombres guardan la información de los dominios en zonas. Un domino se divide en zonas para posibilitar su administración independiente. Mientras que un dominio es todo el subárbol del espacio de nombres una zona es la parte de un dominio administrada por un solo organismo. Un servidor de nombres es autoritativo solo para los dominios que se encuentran en las zonas que administra. Los datos asociados a un dominio se guardan en registros de recursos o resource records (RRs) dentro de cada zona. Los dos RR mas importantes son el registro A (Address o Dirección) y el registro NS (Name Server o Servidor de Nombres). Un registro A especifica una dirección IP asociada a un nombre y el registro NS especifica el nombre del servidor de nombres autoritativo de un dominio. Los registro NS son utilizados para realizar las delegaciones de autoridad. Un RR es un conjunto de cinco valores: nombre de dominio, TTL (time to live), tipo, clase(generalmente IN) y valor. Existen otros tipos de RR: MX, PTR, SOA, TXT, HINFO, AAA, etc. Cada vez que un host en Internet requiere realizar una conexión se enfrenta al problema de tener que encontrar la dirección IP dado un nombre de dominio. Para que no sea necesario que todas las aplicaciones cuenten con su propio cliente que consulte el sistema de DNS, una parte del sistema operativo, llamada resolver, se encarga de realizar esta tarea para todas las aplicaciones del cliente. Un resolver normalmente posee una lista de servidores DNS recursivos preconfigurada ya sea manualmente o negociada de alguna manera(ppp o DHCP). Cada vez que una aplicación necesita resolver un nombre de dominio para poder iniciar una conexión, esta le traslada la pregunta al resolver y este a su vez dirige a uno de sus servidores recursivos la consulta. Los servidores recursivos se encargan de realizar la búsqueda en profundidad en el árbol de servidores autoritativos y devolver la respuesta al resolver. A estas búsquedas dirigidas a los servidores de nombres recursivos se las llama consultas recursivas. Un servidor que acepta que se le realicen consultas recursivas se denomina servidor recursivo. Como contraposición cuando un servidor de nombres solo responde por los registros sobre los cuales tiene autoridad, se denomina servidor autoritativo. Un servidor de nombres recursivo recorre el espacio de nombres realizando consultas de forma iterativa hasta obtener el resultado, para luego poder responderle a un cliente. Este tipo de consultas recibe el nombre de consultas iterativas. En los diagramas se muestra la secuencia de los mensajes intercambiados en ambos casos cuando un usuario intenta bajar una página del sitio recibe como respuesta la dirección IP de la cual le permite establecer una conexión TCP al puerto 80 para poder bajar el contenido de la página. La característica de servidor que acepta consultas recursivas o no recursivas puede aparecer en cualquier servidor de los involucrados (es posible que existan servidores que sean autoritativos de algunos registros y que realicen consultas recursivas para los restantes registros). Los servidores root nunca aceptan consultas recursivas DNS local (recursivo) 1 10 Cliente ( 2 3 root uy com.uy Servidor DNS autoritativo del adinet.com.uy Figura 3. Secuencia de consultas y respuestas de DNS desencadenadas para obtener el registro A de nombre en el caso de que solamente el servidor local acepte consultas recursivas. Las consultas se realizan de acuerdo al numeral que aparece en cada una de las flechas, a nivel del protocolo IP, la IP de destino es la IP de servidor que apunta la flecha y la IP de origen es la IP del servidor que esta al otro extremo de la flecha. Los numerales 1, 2, 4, 6 y 8 son consultas y los numerales 3, 5, 7, 9 y 10 son respuestas. Las consultas 1, 2, 4, 6 y 8 son iguales y se consulta por el registro A de las respuestas 3, 5 y 7 www Medidas de Performance en Servidores Recursivos de DNS hoja 2 de 9

3 permiten avanzar sobre el espacio de nombres; la respuesta 9 la realiza el servidor de nombres autoritativo de adinet.com.uy, la respuesta 10 es la respuesta al usuario. Solamente el servidor DNS local esta permitiendo consultas recursivas, el resto solo permite consultas no recursivas. Esto último no quita que se intente realizar todas las consultas recursivas por parte del servidor de DNS local, y que este no tenga éxito y termine por iterar para obtener el resultado. Los servidores root nunca aceptan consultas recursivas DNS local (recursivo) 1 10 Cliente ( root 9 uy 8 5 com.uy 7 6 Servidor DNS autoritativo del adinet.com.uy Figura 4. Secuencia de consultas y respuestas de DNS desencadenadas para obtener el registro A de nombre en el caso de que alguno de los servidores intermedios acepten consultas recursivas. En este caso los servidores uy, com.uy y DNS local están permitiendo consultas recursivas, mientras el servidor root no esta permitiendo la consulta recursiva. La consulta a un servicio DNS intenta siempre ser recursiva: para qué voy a buscar si alguien lo puede hacer por mi? Si el servidor interrogado responde recursivamente va a devolver el resultado pedido en la pregunta se o no autoritativo del registro solicitado. Si no responde recursivamente devolverá la dirección IP de otro servidor DNS a quien preguntar para seguir avanzando en la consulta. La utilización de servidores recursivos aísla al resolver de la complejidad del sistema DNS, presentándole la información de forma consolidada al cliente final. El proceso de búsqueda en la jerarquía es relativamente costoso en recursos de comunicación y tiempo. Considerando que un servidor recursivo responde a muchos resolvers es lógico pensar en reutilizar consultas realizadas anteriormente, por tanto los servidores recursivos, para entregar las respuestas a las consultas que reciben, se basan en la información que poseen o en la que aprenden en el proceso de búsqueda de la respuesta. La información que un servidor recursivo aprenden, se almacena durante cierto tiempo y se conoce como cache. Cabe notar que probablemente un servidor recursivo no tenga todas las posibles respuestas a nombres de dominio en su cache, lo que si es factible de esperar es que posea los servidores autoritativos de los dominios de primer nivel, segundo nivel, tercer www nivel, etc., en su cache, acortando el mecanismo de búsqueda iterativa a probablemente una única consulta al servidor autoritativo de registro solicitado. Este mecanismo baja la latencia o demora percibida por un usuario (mediante el resolver) frente a sus consultas, claramente esto tiene como suposición de que una importante porción de los registros que se modifican poco. Cada resource record posee un valor de expiración llamado Time To Live (TTL), el mismo es asignado por los servidores de nombres autoritativos de dicho registro y utilizado por los servidores recursivos como indicador de validez del mismo. Un servidor de nombres recursivos inicialmente ingresa a su cache el registro obtenido junto con el valor TTL del mismo (inicialmente validez = TTL), a medida que transcurre el tiempo se decrementa este contador de validez, si se recibe una nueva consulta por el mismo registro y el contador es diferente de cero, no se inicia una nueva búsqueda y se responde con la información existente en su cache, pero con el valor de TTL el valor de validez que posee el contador en ese instante. En caso de que el contador llegue a cero, se elimina el registro del cache y frente a una nueva consulta sobre el registro se deberá comenzar una búsqueda iterativa (posiblemente recortada). El servicio DNS se encuentra en la capa de aplicación, es un programa que implementa las especificaciones del protocolo de capa de aplicación DNS (formato, semántica y sintaxis de los mensajes intercambiados), normalmente corre en un servidor de propósito general sobre un sistema operativo también de propósito general. Las consultas DNS (resolvers) normalmente se realizan utilizando UDP como protocolo de capa de transporte, aunque también es permitido utilizar TCP, siempre utilizando como puerto destino el 53 (puerto donde atiende la aplicación). 3. Descripción del problema: Ahora que ya realizamos una introducción al funcionamiento del DNS, debemos volver a puntualizar la importancia que tiene el mismo para el funcionamiento de Internet. El DNS no forma parte de la especificación inicial del protocolo TCP/IP, tampoco es un requerimiento del mismo para poder transferir datos. Su utilización es debida a un hecho tan simple cómo el de que para seres humanos es mas fácil recordar nombres a direcciones IP, el DNS también permite manejar una estructura lógica independiente a la estructura mas rígida que pueda tener la asignación de direcciones IP (pensemos en una empresa que cambia de proveedor y desea conservar en nombre de su dominio), además permite desacoplar el nombre a la dirección IP. Por lo tanto se ha vuelto una aplicación necesaria y fundamental para el correcto funcionamiento de las aplicaciones en Internet, esto último impone requerimientos de confiabilidad, escalabilidad y performance sobre el DNS. Medidas de Performance en Servidores Recursivos de DNS hoja 3 de 9

4 Es claro frente a la falla de un servidor de nombre autoritativos, como por ejemplo el servidor de nombres autoritativo de edu.uy, nos vemos incapacitados de poder resolver cualquier registro bajo el dominio o subdominios del mismo, por lo tanto nos veríamos incapacitado de poder iniciar una conexión web o un envío de correo electrónico para hosts en dicho dominio. Esto ocurre independientemente de que exista conectividad a nivel de capa de red y que el servicio en el servidor remoto este aceptado peticiones HTPP o SMTP. Normalmente un usuario inexperto no es capaz de distinguir donde se encuentra el problema, el mismo simplemente lo percibe como un problema de conectividad. Entre los servicios que proporciona un ISP a sus clientes, en particular a sus clientes de conexiones dinámicas (o no permanentes), se encuentre el de proporcionarles uno(o mas) servidor(es) de DNS recursivo(s). Esto además de ocultar la complejidad del DNS a los usuarios finales; les ahorra tiempo, CPU y RAM. Posee la virtud de que en enlaces de baja velocidad como el acceso por Modem analógicos, disminuye el ancho de banda que se utiliza dado que realizamos solamente una consulta (en vez de varias como seria el caso de tener que hacer las consultas iterativas). Quizás ahora resulte mas claro que para los usuarios que utilizan servidores recursivos, dependen de que los mismos cumplan con su función, para poder acceder a los servicios en Internet. Para estos usuarios la falta de respuesta a sus consultas por parte de los servidores recursivos es percibida como una imposibilidad de conectarse a Internet. Esto último obliga a un ISP a prestar atención en el desempeño de sus servidores recursivos. El objetivo del presente trabajo es el estudio del desempeño de servidores recursivos de DNS, entre las dificultades que presenta este desafió se encuentran la definición de indicadores de desempeño, como obtenerlos en base a la información que es posible recolectar, como registrarlos, como almacenarlos y como interpretarlos. 4. Performance en Servidores Recursivo de DNS. La primer pregunta que nos debemos hacer es, Qué es la performance en este caso? La respuesta no es inmediata, un correcto funcionamiento del servicio de recursivo DNS debe considerar la existencia de los clientes y del servidor. Desde el punto de vista de quien provee el servicio de DNS recursivo, podemos utilizar como concepto de performance a atender la mayor cantidad de consultas recursivas posibles en el menor tiempo posible. Desde el punto de vista de un usuario, quien utiliza el servicio, vamos a utilizar como concepto de performance a obtener respuestas a sus consultas en el menor intervalo de tiempo posible. Estas definiciones son cualitativas, debemos encontrar parámetros que nos permitan cuantificar los conceptos antes mencionados. Root 5. Descripción de la red de pruebas. Internet Autoritativo.com Test Server Usuarios ISP - Sistema Autonomo NS A Figura 5. Descripciones generales de la red de prueba. NS B En la figura 5 observamos un esquema general de la red sobre la cual se realizaran las medidas, se puede observar en la figura ejemplos de los elementos normalmente involucrados en los procesos de consultas de DNS. La descripción es general y se adecua a una gran diversidad de ISP. Los servidores sobre los cuales realizamos las medidas, NS A y NS B manejan un volumen de clientes diferentes superior a en un día (un cliente es diferente si su dirección IP es diferente). 6. Parámetros a medir desde el punto de vista de un servidor de DNS recursivo. 6.1 Queries per Second (QPS): El primer parámetro que nos pareció de interés medir es la cantidad de consultas que recibe un servidor, sin hacer distinción entre si son consultas que a posteriori se contestan con información desde el cache o si son consultas que impliquen realizar consultas iterativas para obtener la información. Se analizaron dos metodologías: utilizar Queryperf o obtener la información de los archivos de log Queryperf: Es una herramienta distribuida gratuitamente junto con el Servidor de Nombres BIND versión 9 [1]. Funciona enviando consultas estándar de DNS (proporcionadas mediante un archivo de consultas a realizar) durante un cierto intervalo de tiempo, recepciona las respuestas y al finalizar el período de prueba realiza un resumen de los resultados obtenidos. Principalmente la cantidad de consultas realizadas, la cantidad de respuestas obtenidas, la cantidad de consultas sin respuesta (formalmente no llego respuesta en un lapso de 5 segundos), el intervalo de medida y por último las qps percibidas (cociente de respuestas obtenidas sobre el intervalo de medida). Si bien somos concientes de que esta herramienta fue pensada para analizar la performance de servidores autoritativos, cuantas qps puede atender, y que la tarea de un recur- Medidas de Performance en Servidores Recursivos de DNS hoja 4 de 9

5 sivo es muy diferente a la de un servidor autoritativo, fue un buen punto de partida para poder comenzar a entender la problemática. Entre las dificultades encontradas para utilizar esta herramienta estuvieron, la correcta elección de las consultas a realizar (archivo de configuración), si siempre pregunto por los mismo registros en realidad no estoy comprobando que el servidor recursivo realice varias consultas iterativas, solamente la primera consulta se realiza iterativamente y se ingresa al cache, las sucesivas consultas por el mismo registro se responderían directamente con el contenido del cache. Otra dificultad que nos enfrentamos es poder realizar varias consultas en simultaneo desde un mismo equipo de prueba debido a los problemas de context switching entre diferentes procesos. Luego de varias pruebas, los valores de qps obtenidos fuera de producción (sin clientes) era del orden de 3500 a 4000 qps y diferían muy poco los valores entre los servidores de prueba, INTEL Pentium III y Sun Sparc IIi. Estas pruebas sirvieron de puntapié inicial, si bien asumimos que el parámetro qps en producción podría ser inferior al obtenido, sirve como comparativo entre ambas arquitecturas QPS desde los logs: El primer problema a resolver fue como obtener información de las qps, nuestro interés estaba en poder realizar medidas pasivas para no alterar la performance apreciada por los usuarios. Se opto por utilizar una facilidad de la implementación de software que permite almacenar (logear) en archivos las consultas que se están realizando al servidor. Un segundo problema fue como obtener la cantidad de qps en cada instante. Un tercer problema fue una vez obtenido este parámetro como registrarlo y visualizarlo. La metodología empleada fue almacenar (logear) en archivos las consultas que se están realizando al servidor. Para la estimación de las qps, se ejecuta un script una vez por minuto, este en base al contenido de los archivos que registran cada consulta, calcula para el minuto previo (al actual así tengo toda la información) la cantidad de consultas que hubo en cada segundo. Luego dada la imposibilidad de poder registrar los qps en cada segundo del día, se opta por elegir como salida al script el segundo con mas qps del minuto monitoreado. Por último este resultado se escribe a un archivo, el cual una máquina remota se conecta (una vez por minuto) para recolectar la información. Formalmente son dos scripts, uno calcula las qps y el otro script recolecta remotamente la información. El segundo script es utilizado para ir cargando una base de datos RRD[2] de forma periódica en un CACTI[3] para poder realizar una presentación gráfica del resultado. La elección de separar en dos scripts fue tomada para evitar los problemas de sincronización de la información obtenida y del proceso de carga de la base RRD, resulta preferible repetir una medida a que la falta de esta se tomo como un cero y genere variaciones importantes en los gráficos generados. La justificación a la elección de utilizar una base de datos RRD para el almacenamiento de la información es que la misma posee un tamaño fijo, a costa de ir promediando la información histórica. Es claro que esta metodología puede ocultar o enmascarar picos de carga ya que la información que nos proporciona es promediada, como contrapartida esto resulta ventajoso cuando deseamos ver las tendencias y evaluamos el volumen de información a almacenar y procesar. Figura 6. Qps en los servidores recursivos. Es claro que el logear las consultas que están realizando y correr scripts nos aleja del objetivo de obtener medidas pasivas. Si bien esto es cierto se realizaron estimaciones del costo en termino computacionales y resulto bajo utilizando archivos de logs de 20MB. 6.2 Performance de un servidor de propósito general. No hay que perder de vista que el DNS es un servicio corriendo sobre un hardware de propósito general, con restricciones de RAM, CPU, nivel de utilización y paquetes IP unicast por segundo. Por este motivo se utiliza SNMP y las MIB estándar para monitorear estas variables. Figura 7. Porcentaje de uso de CPU en un servidor recursivo. Figura 8. Utilización de memoria en un servidor recursivo. Medidas de Performance en Servidores Recursivos de DNS hoja 5 de 9

6 realizar un port mirror en el puerto del switch de los servidores recursivos o utilizar un software de código libre y modificarlo a tales fines Port Mirror, sniffiar el tráfico y analizar las trazas. Figura 9. Gráfica de carga de un servidor recursivo. Entre las variables que podemos obtener realizando consultas SNMP se encuentra el obtener la cantidad de paquetes IP unicast de la placa de red de servicio. Bajo la hipótesis de que la mayor parte del tráfico es debido al DNS, UDP port 53, un pedido o request y una respuesta o response tanto realizando consultas iterativas como respondiendo las recursivas. Es probable que las qps medidas coincidan con la cantidad de paquetes por segundo obtenidos y que coincidan la cantidad de paquetes entrantes y salientes. Figura 10. Cantidad de paquetes unicast entrantes y salientes en uno de los servidores recursivos. Figura 11. Cantidad de bit por segundo entrantes y salientes en uno de los servidores recursivos. Aquí nuevamente nos aparatamos de nuestro objetivo inicial de utilizar medidas pasivas, en el entendido de que una medida pasiva es aquella en la cual no vamos a inyectar trafico y además no vamos a aumentar significativamente los parámetros a medir sobre el sistema. 6.3 Performance del cache de DNS. Una de las medidas que nos parece de interés es conocer de alguna manera la cantidad de consultas que se responden desde el cache y cuantas se debe salir a obtener la respuesta. Esta medida presenta la dificultad de que generalmente es imposible acceder a esta información directamente, existen 3 estrategias posibles: realizar una estimación primaria utilizando información de hit de Acces List en un firewall previo a acceder al servidor recursivo, Este enfoque fue utilizado por Pablo Rodríguez en [4], una vez consultado el autor de la tesis nos facilito el script con el que realizo sus estimaciones y lo corrimos sobre una traza obtenida en nuestros servidores, obteniéndose resultados de cotas inferiores de eficiencia superiores al 90%. Estas estimaciones analizan si dada una determinada consulta al recursivo esta provoca tener que salir a realizar consultas iterativas o no. La eficiencia se define como el cociente entre las consultas recursivas respondidas con información desde el cache sobre el total de consultas recursivas realizadas Realizar una estimación primaria utilizando ACL. El procedimiento a seguir es crear entradas en las Access List (ACL) de un firewall en donde quedara evidenciado que son consultas iterativas al servidor (IP destino el servidor, puerto destino 53) y las realizadas por el servidor (IP destino el servidor, puerto origen 53). Posteriormente se realizo un script que consulte la cantidad de match que tiene cada entrada en la ACL y se almaceno la información en un archivo de texto. Definimos dos parámetros: Cuando se realiza una consulta a un recursivo, la dirección IP de destino es la dirección IP de uno de los servidores y el puerto destino es el puerto 53 que es donde atiende el servicio. Llamaremos a este contador UDP_IN (asumiendo que UDP es mayoritario respecto a TCP). Cuando un recursivo realiza consultas a servidores autoritativos a consecuencia de que no tiene la respuesta a la consulta en el cache, la misma se caracteriza por tener la dirección IP de origen la de uno de los servidores y el puerto destino el puerto 53. Llamaremos a este contador UDP_OUT (*). Mediante el uso de ACL nos permitió también realizar otras medidas, entre ellas poder medir la relación entre las consultas realizadas utilizando TCP como protocolo de transporte y las consultas que utilizan UDP como protocolo de capa de transporte. Se obtuvieron los siguiente resultados: Total de las consultas entrantes dirigidas al servidor recursivo utilizando TCP < 3 % sobre el total de consultas. Total de las consultas salientes realizadas por un servidor recursivo utilizando TCP < 0,03 % sobre el total de consultas. Medidas de Performance en Servidores Recursivos de DNS hoja 6 de 9

7 Estas medidas se obtuvieron tomando muestras cada 5 minutos, a lo largo de un día. Se verifico posteriormente que estas relaciones no variaban sustancialmente aumentando el largo de la muestra o eligiendo otro día. Para intervalos inferiores a un día, los valores dependen del momento del día que se elige para la muestra, por este motivo se opto por elegir cotas a los valores. Estas cotas superiores de consultas utilizando TCP respecto al resto nos permite asegurar que el cociente de UDP_OUT / UDP_IN es una muy buena aproximación al cociente entre las consultas que recibe el servidor y las que debe realizar. Podemos utilizar como performance del cache el siguiente UDP _ OUT indicador eff = 1 es un indicador de UDP _ IN cuantas consultas nos ahorramos realizar porque el resultado ya esta en el cache. Por argumentos similares a las adquisiciones anteriores se opta por encontrar una cota inferior a este parámetro. La eficiencia observada en intervalos mayores a 3 horas dio como cota inferior 70 %, intervalos inferiores a 3 horas presentas alta variabilidad, ya que, entre otras cosas, hay que asegurarse de que no incluya medidas de cuando el servidor acaba de iniciarse ya que virtualmente todo hay que salir a obtenerlo. De la comparación de las metodologías utilizadas en y 6.3.2, surge naturalmente la pregunta de Porqué difieren tanto los valores? A primera vista parece mas confiable el resultado expuesto en dado que busca reconstruir el contenido del cache que posee el servidor. Un análisis mas detallado nos brindo una posible explicación, normalmente si un RR no se encuentra en el cache, es probable que haya que realizar mas de una consulta iterativa para poder responder. En se mide la taza de respuestas desde el cache y en se mide la taza de dado que un RR no esta en cache, la cantidad de consultas que necesito para poder obtenerlos. Esto ultimo también se puede ver como la cantidad de RR intermedios que tuve que obtener para obtener la respuesta. Teniendo esto en cuenta es razonable que el valor en sea inferior a el de Antes de terminar con estas comparaciones vale la pena recalcar que es una cota mínima y que la naturaleza de la metodología de obtención permite poder obtenerla online (al menos luego de los siguientes 5 minutos se puede volver a recalcular) Performance del cache utilizando un software de código libre modificado[1]. No va a ser de nuestro interés por dos motivos, el primero es que modificar el código puede implicar alterar la performance del software original, el segundo es la falta de tiempo para afrontar las modificaciones y los testing adecuados. 6.4 Utilización de rndc tools Otras medidas útiles en cuanto a estimaciones de perfomance se pueden obtener utilizando herramientas que brindan información estadística del servidor. Por ejemplo el bind 9 posee una herramienta llamada rndc tool que permite obtener información muy resumida de algunos eventos en el servidor de nombres. Estos eventos son: SUCESS cantidad de respuestas exitosas a pedidos recursivos. REFERRAL cantidad de consultas cuya respuesta haya sido un referr, debería ser cero ya que esto solo ocurre en servidores de nombres autoritativos. NXRRSET respuestas sin error pero sin información. NXDOMAIN cantidad de respuestas a las cuales no existe el registro que se esta consultando. RECURSION cantidad de consultas recursivas que requieren realizar una o mas consultas iterativas. FAILURE cantidad de consultas en las cuales se obtuvo como respuesta errores diferentes a NXDO- MAIN. Figura 12. Gráfica de salida de parámetros obtenido mediante rndc tool cada 5 minutos. Es posible estimar algunos valores antes analizados utilizando las rndc tools. En nuestro caso es utilizado para guardar información histórica y prestar atención a las modificaciones en el comportamiento. Por ejemplo un aumento de la cantidad de NXDomain puede ser debida a ataques al servidor de nombres. 7. Parámetros a medir desde el punto de vista de un cliente del servicio. Hasta ahora los conceptos parámetros de performance descriptos están enfocados al servidor y no a lo que el usuario percibe. Este es un punto importante a no descuidar, en especial la demora que percibe un usuario en la obtención de contenidos utilizando HTTP incluye la demora o latencia introducida por el DNS recursivo en la obtención de los registros A que se estén utilizando[6]. Para poder realizar estimaciones de estos valores no nos queda otra opción que realizar medidas activas en nuestros servidores. Se elije un servidor del cual podamos iniciar varias consultas a los nuestros servidores recursivos, resulta claro que la cantidad de consultas no debería ser superior al 1% del total ya que no queremos que se degrade Medidas de Performance en Servidores Recursivos de DNS hoja 7 de 9

8 la performance por estas medidas. A tales efectos se implemento un script que corre en el Test Server de la figura 5, una vez por minuto y realiza una batería de al menos 60 consultas por minuto a los servidores de nombres recursivos. Esta batería de consultas esta dividida en tres partes: la primera es resultado de un acceso aleatorio a un archivo generado a partir de los logs de consultas recursivas de los servidores previo a la utilización de estas medidas y preguntando por los registros que obtenga; la segunda parte es una generación de consultas de registros A aleatorios; por último, dado que las consultas inversas han aumentado en la actualidad y que la estructura de esta rama se gestiona diferente a los directos, se generan búsquedas inversas por direcciones IP aleatorias. De esta batería de consultas, vamos a obtener 4 parámetros: tiempo promedio de respuestas (latencia), tiempo máximo observado en las respuestas, por último cuantas respuestas se obtuvieron antes de los 2 segundos (timeout estándar de un resolver) y cuantas consultas no obtuvieron respuestas (formalmente antes de los 5 segundos que es el timeout utilizado en nuestro script). Para poder recolectar y almacenar esta información nuevamente optamos por utilizar las bases de datos RRD. Figura 13. Promedio de latencia de la batería de consultas realizadas desde el servidor de test hacia los servidores recursivos. Figura 14. Latencia máxima perciba por el servidor de test utilizando la batería de consultas realizadas hacia los servidores recursivos. En la figura 15 se observa claramente los efectos de enmascaramientos de pico en las medidas, los valores que realmente se obtienen pertenecen son números naturales mayores o iguales a cero. De todas formas cuando ocurren dificultades son claramente perceptibles en las graficas. La falta de respuestas se puede justificar en muchas ocasiones por la diferencia entre el timeout del resolver (usuario) y el timeout del recursivo. Nos esta faltando aún una estimación del porcentaje total de consultas no respondidas. Se procedió a tomar mediante un sniffer una traza para poder realizar una estimación de las consultas que no son respondidas por servidor. Se utiliza como valor de timeout 5 segundos, toda respuesta que demore mas de 5 segundo en llegar se asume que nunca fue respondida. Los valores obtenidos es que las perdidas son < 2 %. Al igual que algunos parámetros anteriores se intento realizar comparaciones con otros servidores, nos encontramos en las referencias sobre el tema con un primer paper [6] que estudia la performance de los root server y un segundo paper [7] que estudia la performance de servidores recursivos locales de DNS en varios puntos. El primer paper maneja que la pérdida observada en un root server era < 12 % y el segundo paper menciona que las pérdidas son < 0,65 al 10% dependiendo del servidor analizado. Para poder realizar alguna verificación de resultados de latencia, se utilizo la misma traza que para la estimación de las pérdidas. Analizando las diferencias de tiempos entre que se observa la consulta y se observa la respuesta se puede estimar cuanto tiempo lleva responder al servidor. Encontramos que el servidor responde en tiempos < 5 ms. Hay que precisar que no hicimos distinción entre las respuestas realizadas utilizando el contenido del cache y las respuestas que requirieron iniciar búsquedas iterativas. También debemos precisar de que esta estimación es muy dependiente de la carga del sistema. De todas formas no resulta extraño los valores observados, de los 25 ms promedio que demora una consulta desde el servidor de test, tenemos que lleva 5 ms al servidor contestar, entre 3 a 5 ms es el RTT (obtenido mediante pings) en condiciones normales entre el servidor de test y los servidores recursivos. Están restando 15 ms para realizar el procesamiento en el servidor de test. Estos resultados se mantienen en condiciones de operación normales, pudiendo ser mayores en casos de alta carga como es el caso de cuando se acaba de subir el servicio, en donde el cache esta vacío y debemos salir a obtener todas las respuestas. 8. Conclusiones: Figura 15. Cantidad de consultas que no llegaron antes de 5 segundos (no_answer) y cantidad de consultas que demoraron más de 2 segundos y menos de 5 segundos (out_time). No resulta sencillo a priori a cual de todos los parámetros asignarle mayor peso en un intento de caracterizar la performance global del sistema con un solo parámetro. Las medidas propuestas prestan atención a diferentes aspectos de un mismo problema. Todo el conjunto de medidas son una buena herramienta de monitoreo, algunas de ellas es poco costoso registrarlas en el tiempo, generando de esta manera una base histórica de información que Medidas de Performance en Servidores Recursivos de DNS hoja 8 de 9

9 permite realizar planificaciones y análisis problemas puntuales. Únicamente fue posible asignarle mayor importancia a uno de los parámetros basado en la observación periódica del sistema, normalmente el valor de latencia experimentado por el servidor de test suele ser un fuerte indicador de fallas relacionadas a velocidad de respuesta resultando en un buen termómetro de la performance percibida por el resto de los usuarios. Si bien parece un exceso de medidas, no hay que olvidarse que las mismas fueron realizadas en un sistema en producción, en donde además de poder estimar la performance se debe poder actuar proactivamente y activamente sobre el mismo para su correcto funcionamiento. También resulto útil el disponer de varias metodologías de medida para poder realizar verificación y validación de los resultados. Para finalizar, una última conclusión sobre nuestras medidas en los indicadores de respuestas desde el cache, las mismas refuerzan el motivo sus existencia disminuyendo la latencia percibida por los clientes finales. Entre las referencias podemos encontrar un paper analizando la eficiencia del mismo [9]. de los mecanismos de descubrimiento de contenido, diciembre [5] Md. Ahsan Habib and Marc Abrams, Analysis of Sources of Latency in Downloading Web Pages. [6] Nevil Brownlee, Kc Claffy and Evi Nemeth, DNS Root/gTLD Perfomance Measurements. [7] Chris J. Brandhosrt and Aiko Pras, DNS: a statistical analysis of name server traffic at local network-to-internet connections. [8] Richard Liston, Sridhar Srinivasan and Ellen Zagura, Diversity in DNS Performance Measures. [9] Jaeyeon Jung, Emil Sit, Hari Balakrishnan and Robert Morris, DNS Performance and the Effectiveness of Caching. [10] Jaeyeon Jung, Arthur W. Berger and Hari Balakrishnan, Modeling TTL-base Internet Caches [11] Cricket Liu, DNS & BIND Cookbook editorial O'Reilly, ISBN Trabajo futuro: Consideramos que el trabajo futuro debería dirigirse a mejorar las metodologías de obtención de la información con la finalidad de aumentar el caudal de conocimiento y hacer la obtención mas eficiente y continua, esto de por si solo ya es un desafió importante. Otro desafío podría estar en el proceso de validación de modelos de funcionamiento de algunos componentes de DNS, muchos de ellos solo contrastados contra resultados obtenidos en simulaciones. Por último es posible generar nuevos modelos de funcionamiento y realizar propuestas de mejoras en los mismos. 10. Referencias [1] BIND (Berkeley Internet Name Domain) es una implementación de referencia de los componentes principales del protocolo de capa de aplicación DNS. Se distribuye de forma gratuita bajo las condiciones de BSD License. Sitio de referencia [2] RRD es el acrónimo para Round Robin Database (estructura de datos cíclica). RRD es un sistema que almacena y despliega secuencias de datos indexadas en el tiempo. La información es almacenada de una forma compacta (se promedia) y acota el espacio necesario para su almacenamiento. [3] Cacti - Herramienta integral basada en bases RRD, permite realizar consultas mediante diferentes métodos de adquisición como por ejemplo script y consultas SNMP periódicas. Una vez obtenida la información el cacti permite visualizar de forma grafica la información almacenada. Sitio de referencia [4] Pablo Rodriguez-Bocca, Tesis de Maestría, Redes de Contenido: Taxonomía y Modelos de evaluación y diseño Medidas de Performance en Servidores Recursivos de DNS hoja 9 de 9