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

Tamaño: px
Comenzar la demostración a partir de la página:

Download "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 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 (www.adinet.com.uy) 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 (www.adinet.com.uy) 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

Componentes del servicio de nombres de dominio. Javier Rodríguez Granados

Componentes del servicio de nombres de dominio. Javier Rodríguez Granados Componentes del servicio de nombres de dominio. Javier Rodríguez Granados Complementos principales Los Clientes DNS: Un programa cliente DNS que se ejecuta en el ordenador del usuario y que genera peticiones

Más detalles

Informàtica i Comunicacions Plaça Prnt. Tarradellas, 11 17600 FIGUERES (Girona) Tel. 902 88 92 67 Fax 972 671 962 www.cesigrup.es

Informàtica i Comunicacions Plaça Prnt. Tarradellas, 11 17600 FIGUERES (Girona) Tel. 902 88 92 67 Fax 972 671 962 www.cesigrup.es DNS (Domain Name System)...2 La estructura... 2 Servidores DNS e Internet... 3 Dominios... 3 Servidores de nombres... 3 Servidores de nombres Principal y Secundario... 4 Los archivos del DNS... 4 Registro

Más detalles

CAPA DE APLICACIONES

CAPA DE APLICACIONES CAPA DE APLICACIONES En esta capa se implementan protocolos que ayudan al intercambio de información entre usuarios Protocolos utilizados El sistema de nombres de dominio (DNS) Transferencia de Hipertexto

Más detalles

Luis Villalta Márquez SERVIDORES DE NOMBRES DE DOMINIO (DNS)

Luis Villalta Márquez SERVIDORES DE NOMBRES DE DOMINIO (DNS) Luis Villalta Márquez SERVIDORES DE NOMBRES DE DOMINIO (DNS) Servidores de nombres de dominio (DNS) ZONAS. AUTORIDAD. REGISTRO DE RECURSOS (RR) ZONA DE BÚSQUEDA Zonas Zona de Búsqueda Directa. Las resoluciones

Más detalles

Capítulo 3. Software para el Monitoreo de Redes

Capítulo 3. Software para el Monitoreo de Redes Capítulo 3 Software para el Monitoreo de Redes No basta saber, se debe también aplicar. No es suficiente querer, se debe también hacer. Johann Wolfgang Goethe Software para el Monitoreo de Redes El estilo

Más detalles

El gráfico siguiente muestra un uso básico de DNS, consistente en la búsqueda de la dirección IP de un equipo basada en su nombre.

El gráfico siguiente muestra un uso básico de DNS, consistente en la búsqueda de la dirección IP de un equipo basada en su nombre. Definición de DNS DNS es una abreviatura para Sistema de nombres de dominio (Domain Name System), un sistema para asignar nombres a equipos y servicios de red que se organiza en una jerarquía de dominios.

Más detalles

DOMAIN NAME SYSTEM DNS

DOMAIN NAME SYSTEM DNS DOMAIN NAME SYSTEM DNS Contenido Introducción DNS Definiciones Resolución de Nombres Referencias INTRODUCCIÓN En los 70, ARPANET era una comunidad de unos cientos de máquinas Un solo archivo HOST.TXT contenía

Más detalles

Redes de Datos 1er parcial año 2010

Redes de Datos 1er parcial año 2010 31 de julio de 2010 Redes de Datos 1er parcial año 2010 Las hojas se escriben de un solo lado y preguntas separadas se responden en hojas separadas. Letra clara y legible. Respuesta concisa. Nombre, número

Más detalles

Sistemas de Transportes de Datos (STD) Tema II: IP (Entrega 6) Grupo de Aplicaciones Telemáticas. Grupo de Aplicaciones Telemáticas

Sistemas de Transportes de Datos (STD) Tema II: IP (Entrega 6) Grupo de Aplicaciones Telemáticas. Grupo de Aplicaciones Telemáticas DNS: Domain Name System El Domain Name System (DNS) es una base de datos distribuida que las aplicaciones de Internet utilizan para mapear nombres de máquinas y las direcciones IP correspondientes. Los

Más detalles

DNS Domain Name System Sistema de Nombres de Dominio Administración de Redes de Computadores John Deivis Tabares Tobón Luis Fernando Ramirez

DNS Domain Name System Sistema de Nombres de Dominio Administración de Redes de Computadores John Deivis Tabares Tobón Luis Fernando Ramirez DNS Domain Name System Sistema de Nombres de Dominio Administración de Redes de Computadores John Deivis Tabares Tobón Luis Fernando Ramirez CONFIGURACION DEL SERVIDOR DNS EN WINDOWS SERVER 2008 Domain

Más detalles

La Capa de Aplicación Protocolos de Aplicación Básicos

La Capa de Aplicación Protocolos de Aplicación Básicos La Capa de Aplicación Protocolos de Aplicación Básicos mayo de 2008 DNS DNS (RFC 1034 y 1035) Idea básica: Cada nodo tiene un nombre único asignado a una dirección IP. El Sistema de Nombres de Dominio

Más detalles

Quién es www.udp.cl? www.udp.cl es 200.14.86.4.

Quién es www.udp.cl? www.udp.cl es 200.14.86.4. <img_dns server_usuario query BD dirip> 2.2QueesDNS El Sistema de Nombres de Dominio, también denominado DNS (Domain Name System), corresponde a un sistema diseñado con la finalidad de proveer nombres relacionadosadispositivosorecursosenred,yaseaapequeñaoaltaescala(como

Más detalles

Domain Name Server. Daniel Pecos Martínez. dani@netpecos.org. Castellón, 1 de Diciembre 2003

Domain Name Server. Daniel Pecos Martínez. dani@netpecos.org. Castellón, 1 de Diciembre 2003 Domain Name Server Daniel Pecos Martínez dani@netpecos.org Castellón, 1 de Diciembre 2003 INTRODUCCIÓN En este documento se realiza una breve explicación sobre los conceptos básicos del DNS, poniendo como

Más detalles

Redes de Datos 1er parcial

Redes de Datos 1er parcial Redes de Datos 1er parcial Solución: Esto es un esquema de los puntos fundamentales que debería contener la respuesta correcta y contiene más información que la exigida para obtener el máximo puntaje.

Más detalles

Registros de recursos DNS. Javier Rodríguez Granados

Registros de recursos DNS. Javier Rodríguez Granados Registros de recursos DNS. Javier Rodríguez Granados Registros de Recursos (RR) Para resolver nombres, los servidores consultan sus zonas. Las zonas contienen registros de recursos que constituyen la información

Más detalles

Descripción de las zonas y de la transferencia de zonas 14

Descripción de las zonas y de la transferencia de zonas 14 DNS en W2000-Server ÍNDICE Definición de DNS 1 Nombres de dominio DNS 2 Descripción del espacio de nombres de dominio DNS Cómo se organiza el espacio de nombres de dominio DNS Interpretar un nombre de

Más detalles

Servidores de nombres de dominio (DNS) Jesús Torres Cejudo

Servidores de nombres de dominio (DNS) Jesús Torres Cejudo Zonas Zona de Búsqueda Directa.- Las resoluciones de esta zona devuelven la dirección IP correspondiente al recurso solicitado; este tipo de zona realiza las resoluciones que esperan como respuesta la

Más detalles

DNS: Domain Name System

DNS: Domain Name System DNS: Domain Name System Introducción DNS: Domain Name System Propósito básico: Traducir números IP en nombres textuales más amigables para los usuarios humanos de la red. Propósitos adicionales: Soporte

Más detalles

UNIDAD DIDACTICA 5 CONFIGURACIÓN DEL SERVICIO DNS EN WINDOWS 2003. Eduard Lara

UNIDAD DIDACTICA 5 CONFIGURACIÓN DEL SERVICIO DNS EN WINDOWS 2003. Eduard Lara UNIDAD DIDACTICA 5 CONFIGURACIÓN DEL SERVICIO DNS EN WINDOWS 2003 Eduard Lara 1 1. DOMAIN NAME SYSTEM El sistema de nombres de dominio (DNS) es una base de datos distribuida y jerárquica que almacena información

Más detalles

Dominios de una red informática

Dominios de una red informática 1 Dominios de una red informática Un dominio puede referirse a dos cosas: es un conjunto de ordenadores conectados en una red que confían a uno de los equipos de dicha red la administración de los usuarios

Más detalles

DNS (Domain Name System, Sistema de nombres de dominio). RFC 1034 y RFC 1035. - Resolver envía paquete UDP a un servidor DNS.

DNS (Domain Name System, Sistema de nombres de dominio). RFC 1034 y RFC 1035. - Resolver envía paquete UDP a un servidor DNS. DNS (Domain Name System, Sistema de nombres de dominio). RFC 1034 y RFC 1035 - Realmente no es una aplicación, sino un servicio. Es mas facil recordar nombres que números. - Inicialmente (ARPANET) solo

Más detalles

SISTEMAS DE NOMBRES DE DOMINIO

SISTEMAS DE NOMBRES DE DOMINIO SISTEMAS DE NOMBRES DE DOMINIO La historia del sistema de nombres de dominio, DNS, se remonta a la década de los setenta, donde cada una de las computadoras conectadas a la red tenía asignada una dirección

Más detalles

EL SERVICIO DE DIRECTORIO DNS Alvaro del Castillo San Félix 1998, GNU FDL Publicado en Linux Actual. Introducción

EL SERVICIO DE DIRECTORIO DNS Alvaro del Castillo San Félix 1998, GNU FDL Publicado en Linux Actual. Introducción EL SERVICIO DE DIRECTORIO DNS Alvaro del Castillo San Félix 1998, GNU FDL Publicado en Linux Actual Introducción En el presente artículo se describe el servicio de DNS que permite el acceso de los usuarios

Más detalles

Proyecto Infraestructura Virtual

Proyecto Infraestructura Virtual 2011 Proyecto Infraestructura Virtual Integrates: RevolucionUnattended 01/01/2011 CONTENIDO ESCUELA POLITÉCNICA NACIONAL 1. INTRODUCCION 1.1. Propósito 1.2. Ámbito del Sistema 1.2.1 Descripción 1.2.2 Objetivos

Más detalles

FORMACIÓN Equipos de interconexión y servicios de red

FORMACIÓN Equipos de interconexión y servicios de red FORMACIÓN Equipos de interconexión y servicios de red En un mercado laboral en constante evolución, la formación continua de los profesionales debe ser una de sus prioridades. En Galejobs somos conscientes

Más detalles

Software de Comunicaciones. Práctica 3 - Domain Name System (DNS)

Software de Comunicaciones. Práctica 3 - Domain Name System (DNS) Software de Comunicaciones Práctica 3 - Domain Name System (DNS) Juan Díez-Yanguas Barber Software de Comunicaciones Ingeniería Informática - 5º Curso Jdyb - Marzo 2013 Juan Díez- Yanguas Barber Práctica

Más detalles

DNS: Domain Name System

DNS: Domain Name System 1 DNS: Domain Name System Sistemas Telemáticos I Por qué es necesario el DNS? 2 Por qué es necesario el DNS? Los humanos preferimos nombres a direcciones IP (ej: cacharro.cct.urjc.es frente a 212.128.1.44)

Más detalles

Figura 1: Ciclo de la Administración del desempeño

Figura 1: Ciclo de la Administración del desempeño 1 INTRODUCCIÓN El servicio de acceso a Internet de la Escuela Politécnica Nacional, no cubre las expectativas de los usuarios finales debido a que los tiempos de respuesta, la disponibilidad y la seguridad

Más detalles

LA ARQUITECTURA TCP/IP

LA ARQUITECTURA TCP/IP LA ARQUITECTURA TCP/IP Hemos visto ya como el Modelo de Referencia de Interconexión de Sistemas Abiertos, OSI-RM (Open System Interconection- Reference Model) proporcionó a los fabricantes un conjunto

Más detalles

Proceso de resolución de un nombre de dominio. Javier Rodríguez Granados

Proceso de resolución de un nombre de dominio. Javier Rodríguez Granados Proceso de resolución de un nombre de dominio. Javier Rodríguez Granados Proceso de resolución de un nombre de dominio. La resolución de un nombre de dominio es la traducción de un FQDN a su correspondiente

Más detalles

Por D. Rafael J. Montero González

Por D. Rafael J. Montero González Por D. Rafael J. Montero González Introducción Sistemas de nombres planos vs. jerárquicos Historia de DNS Características y utilidad del servicio DNS Componentes y funcionamiento Espacio de nombres de

Más detalles

Redes de ordenadores DNS

Redes de ordenadores DNS Redes de ordenadores DNS Grupo de sistemas y comunicaciones jjmunoz@gsyc.inf.ucm.es Redes de ordenadores, 1998-1999 Página 1 4.DNS El servicio de nombres permite que los humanos usemos nombres de máquina

Más detalles

Es la capa donde se encuentran las aplicaciones que interactúan con el usuario. Son la razón de ser de las redes de datos

Es la capa donde se encuentran las aplicaciones que interactúan con el usuario. Son la razón de ser de las redes de datos Capa de aplicación Capa de aplicación Es la capa donde se encuentran las aplicaciones que interactúan con el usuario Son la razón de ser de las redes de datos En Internet, son estas aplicaciones el principal

Más detalles

TEMA 6: INSTALACIÓN DE SERVICIOS EN REDES LOCALES

TEMA 6: INSTALACIÓN DE SERVICIOS EN REDES LOCALES TEMA 6: INSTALACIÓN DE SERVICIOS EN REDES LOCALES 1. INTRODUCCIÓN Todas las redes deben ofrecer una serie de servicios a los usuarios. Entre los principales servicios que se pueden ofrecer están: 1) Servicios

Más detalles

Windows Server 2012: Zonas DNS

Windows Server 2012: Zonas DNS Windows Server 2012: Zonas DNS 2 Tabla de Contenidos Objetivos... 5 Zonas DNS... 7 Qué es una zona DNS?... 7 Tipos de zonas DNS... 7 Zona principal... 8 Zona secundaria... 8 Zona de rutas internas... 8

Más detalles

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA)

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) SOLUCIÓN (más completa que el mínimo requerido para obtener los máximos puntajes) Pregunta 1 En el sistema de nombre de dominio (DNS): a)

Más detalles

Servidor DNS. Son servicios que contestan las consultas realizadas por los Clientes DNS. Hay dos tipos de servidores de nombres:

Servidor DNS. Son servicios que contestan las consultas realizadas por los Clientes DNS. Hay dos tipos de servidores de nombres: Servidor DNS DNS (acrónimo de Domain Name System) es una base de datos distribuida y jerárquica que almacena la información necesaria para los nombre de dominio. Sus usos principales son la asignación

Más detalles

DNS: Domain Name System

DNS: Domain Name System DNS: Domain Name System Bibliografía: Redes de Computadores: un enfoque descendente basado en Internet : J.F Kurose y K.W. Ross. Por qué es necesario el DNS? Los humanos preferimos nombres a direcciones

Más detalles

Guia sobre como instalar un servidor DNS en ubuntu

Guia sobre como instalar un servidor DNS en ubuntu Guia sobre como instalar un servidor DNS en ubuntu DNS proviene de Domain Name Service. En internet, el Domain Name Service (DNS) almacena y asocia diversos tipos de información con nombres de dominio;

Más detalles

Colegio Newlands Tecnologías de la Información y de la Comunicación. INTERNET Estructura y Funcionamiento

Colegio Newlands Tecnologías de la Información y de la Comunicación. INTERNET Estructura y Funcionamiento Colegio Newlands Tecnologías de la Información y de la Comunicación INTERNET Estructura y Funcionamiento Qué es Internet? Internet (acrónimo de inter-connected networks) es un método de interconexión descentralizada

Más detalles

PROGRAMA WRSK00: USO DE WIRESHARK EN EL ANÁLISIS DE SEGURIDAD Y PERFORMANCE DE REDES TCP/IP (WRSKTOOL)

PROGRAMA WRSK00: USO DE WIRESHARK EN EL ANÁLISIS DE SEGURIDAD Y PERFORMANCE DE REDES TCP/IP (WRSKTOOL) PROGRAMA WRSK00: USO DE WIRESHARK EN EL ANÁLISIS DE SEGURIDAD Y PERFORMANCE DE REDES TCP/IP (WRSKTOOL) OBJETIVOS: El programa propone el uso de la herramienta Wireshark 1 para lograr los siguientes objetivos:

Más detalles

DNS. Arquitectura Cliente Servidor. Pacheco Martínez Fernando Tovar Balderas Sergio A.

DNS. Arquitectura Cliente Servidor. Pacheco Martínez Fernando Tovar Balderas Sergio A. DNS Arquitectura Cliente Servidor Pacheco Martínez Fernando Tovar Balderas Sergio A. Nombres de dominio DNS El Sistema de nombres de dominio (DNS) se definió originalmente en los RFC 1034 y 1035. Estos

Más detalles

8 Conjunto de protocolos TCP/IP y direccionamiento IP

8 Conjunto de protocolos TCP/IP y direccionamiento IP 8 Conjunto de protocolos TCP/IP y direccionamiento IP 8.1 Introducción a TCP/IP 8.1.1 Historia de TCP/IP El Departamento de Defensa de EE.UU. (DoD) creó el modelo de referencia TCP/IP porque necesitaba

Más detalles

Resolución de nombres de host mediante el Sistema de nombres de dominio (DNS)

Resolución de nombres de host mediante el Sistema de nombres de dominio (DNS) Resolución de nombres de host mediante el Sistema de nombres de dominio (DNS) Introducción al Sistema de nombres de dominio El Sistema de nombres de dominio (DNS) es una base de datos jerárquica y distribuida

Más detalles

Multi Traffic Routing Grapher (MRTG)

Multi Traffic Routing Grapher (MRTG) UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGÍA COORDINACIÓN DE POST-GRADO Maestría en Ciencias de la Computación- Mención Redes de Computadoras Multi Traffic Routing Grapher

Más detalles

Configuración del acceso a Internet en una red

Configuración del acceso a Internet en una red Configuración del acceso a Internet en una red Contenido Descripción general 1 Opciones para conectar una red a Internet 2 Configuración del acceso a Internet utilizando un router 12 Configuración del

Más detalles

Servidor DNS. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia

Servidor DNS. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia Servidor DNS. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia Introducción. Los seres humanos pueden ser identificados de muchas maneras. Los host de Internet tambien!! Un identificador

Más detalles

Hoy vamos a hablar sobre como instalar y configurar un servidor de DNS en un Microsoft Windows Server 2008 R2.

Hoy vamos a hablar sobre como instalar y configurar un servidor de DNS en un Microsoft Windows Server 2008 R2. El Servicio DNS Hoy vamos a hablar sobre como instalar y configurar un servidor de DNS en un Microsoft Windows Server 2008 R2. Quizá, lo primero que haya que hacer es recordar que es un DNS. Un Domain

Más detalles

CAPÍTULO I. INTRODUCCIÓN

CAPÍTULO I. INTRODUCCIÓN CAPÍTULO I. INTRODUCCIÓN 1.1 Estado del arte del monitoreo de redes de computadoras. La palabra monitoreo no tiene una definición exacta, pero en el contexto computacional ha adquirido un auge muy grande,

Más detalles

Redes de área local: Aplicaciones y servicios WINDOWS

Redes de área local: Aplicaciones y servicios WINDOWS Redes de área local: Aplicaciones y servicios WINDOWS 4. Servidor DNS 1 Índice Definición de Servidor DNS... 3 Instalación del Servidor DNS... 5 Configuración del Servidor DNS... 8 2 Definición de Servidor

Más detalles

Redes de área local Aplicaciones y Servicios Linux Servidor DNS

Redes de área local Aplicaciones y Servicios Linux Servidor DNS MINISTERIO DE EDUCACIÓN Y CIENCIA SECRETARÍA GENERAL DE EDUCACIÓN Y FORMACIÓN PROFESIONAL DIRECCIÓN GENERAL DE EDUCACIÓN, FORMACIÓN PROFESIONAL E INNOVACIÓN EDUCATIVA CENTRO NACIONAL DE INFORMACIÓN Y COMUNICACIÓN

Más detalles

Capa de TRANSPORTE. Ing. José Martín Calixto Cely Original: Galo Valencia P.

Capa de TRANSPORTE. Ing. José Martín Calixto Cely Original: Galo Valencia P. Capa de TRANSPORTE Ing. José Martín Calixto Cely Original: Galo Valencia P. Capa de Transporte La Capa 1 crea y transporta las corrientes de bits; La Capa 2 encapsula los paquetes de datos en tramas, y

Más detalles

Fast Flux Service Networks. Carlos Martínez-Cagnazzo LACNIC XII Ciudad de Panamá Mayo de 2009

Fast Flux Service Networks. Carlos Martínez-Cagnazzo LACNIC XII Ciudad de Panamá Mayo de 2009 Fast Flux Service Networks Carlos Martínez-Cagnazzo LACNIC XII Ciudad de Panamá Mayo de 2009 Plan de la Presentación Anatomía de un mensaje de phishing DNS TTL, Round Robin Anatomía de un phishing Fast

Más detalles

Instalación, configuración y administración de servidores DNS

Instalación, configuración y administración de servidores DNS Instalación, configuración y administración de servidores DNS Tabla de Contenidos 1. Instalación, configuración y administración de servidores DNS...2 1.1 Conceptos Generales de DNS... 2 1.2 Servidor DNS

Más detalles

Sistemas Distribuidos - Servicios de Nombres

Sistemas Distribuidos - Servicios de Nombres NOMBRES ESTRUCTURADOS Los nombres planos son buenos para las máquinas, pero por lo general no muy convenientes para el uso de las personas. Como alternativa, los sistemas de nombres con frecuencia soportan

Más detalles

Tecnologías De La Información Y Comunicación I. Firewall Y Proxy. Integrantes: Héctor Duran. Katherine Zumelzu

Tecnologías De La Información Y Comunicación I. Firewall Y Proxy. Integrantes: Héctor Duran. Katherine Zumelzu Firewall Y Proxy Integrantes: Héctor Duran Katherine Zumelzu Fecha: 15/04/2015 Índice Qué es un firewall?... 3 Tipos de Firewall... 4 -Nivel de aplicación de Pasarela:... 4 -Circuito a nivel de Pasarela:...

Más detalles

Gráficos de tráfico y estadísticas usando MRTG

Gráficos de tráfico y estadísticas usando MRTG Gráficos de tráfico y estadísticas usando MRTG La presentación de gráficos estadísticos para evaluar el uso del ancho de banda a Internet se considera una característica opcional de un router; sin embargo,

Más detalles

CCNA 1 v3.0 Módulo 9 Suite de Protocolos TCP/IP y Direccionamiento IP Prof: Mg Robert Antonio, Romero Flores

CCNA 1 v3.0 Módulo 9 Suite de Protocolos TCP/IP y Direccionamiento IP Prof: Mg Robert Antonio, Romero Flores CCNA 1 v3.0 Módulo 9 Suite de Protocolos TCP/IP y Direccionamiento IP Prof: Mg Robert Antonio, Romero Flores 1 Objetivos Los estudiantes que completen este módulo deberán poder: Explicar por qué se desarrolló

Más detalles

UD 3: Instalación y administración de servicios de nombres de dominio. SRI

UD 3: Instalación y administración de servicios de nombres de dominio. SRI Instalación y administración de servicios de nombres de dominio. SRI RESULTADOS DE APRENDIZAJE Administra servicios de resolución de nombres, analizándolos y garantizando la seguridad del servicio. Introducción

Más detalles

TEMA 2: CAPACIDAD: Diseño del Servicio TI Anexo I: DNS

TEMA 2: CAPACIDAD: Diseño del Servicio TI Anexo I: DNS CIMSI Configuración, Implementación y Mantenimiento de Sistemas Informáticos TEMA 2: CAPACIDAD: Diseño del Servicio TI Anexo I: DNS Daniel Cascado Caballero Rosa Yáñez Gómez Mª José Morón Fernández E.T.S.

Más detalles

GPRS: General Packet Radio Service

GPRS: General Packet Radio Service EVALUACION DE LAS PRESTACIONES DE LA RED GPRS PARA APLICACIONES DE MONITOREO REMOTO Mg. Guillermo R. Friedrich (UTN-FRBB) Mg. Jorge R. Ardenghi (UNS-LiSiDi) XII Congreso Argentino de Ciencias de la Computación

Más detalles

Lab: Wireshark - DNS 1

Lab: Wireshark - DNS 1 Departamento Académico de Informática Lab: Wireshark - DNS 1 Ingº Manuel Peñaloza Figueroa Dime y lo olvidaré. Muéstrame y lo recordaré. Involúcrame y lo entenderé Proverbio chino 1. OBJETIVOS: 1.1 Investigar

Más detalles

Metodología para la Implementación de Intranets ANEXO 3 CONFIGURACION DE LA INTRANET REQUERIMIENTOS PARA LA INSTALACION

Metodología para la Implementación de Intranets ANEXO 3 CONFIGURACION DE LA INTRANET REQUERIMIENTOS PARA LA INSTALACION ANEXO 3 CONFIGURACION DE LA INTRANET REQUERIMIENTOS PARA LA INSTALACION Requerimientos Hardware mínimos para una Intranet son: Red TCP / IP Un servidor PII de 350 Mhz 64 Mb de RAM Disco Duro de 6 Gb. Requerimiento

Más detalles

MÓDULO: SERVICIOS E RED. Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio]

MÓDULO: SERVICIOS E RED. Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio] MÓDULO: SERVICIOS E RED Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio] PARTE 1: Responde las siguientes preguntas tipo TEST. Solo hay una respuesta correcta. Dos respuestas incorrectas anulan una

Más detalles

CFGM. Servicios en red. Unidad 1 Servicio de nombres de dominio (DNS) 2º SMR Servicios en Red

CFGM. Servicios en red. Unidad 1 Servicio de nombres de dominio (DNS) 2º SMR Servicios en Red CFGM. Servicios en red Unidad 1 Servicio de nombres de dominio (DNS) 1. El servicio DNS 2. Configuración del cliente DNS CONTENIDOS 3. Base de datos del protocolo DNS 4. Servidores de nombres de dominio

Más detalles

DNS. Domain Name System. Sistema de Nombres de Dominio. Administración de Redes de Computadores. Ficha: 149822.

DNS. Domain Name System. Sistema de Nombres de Dominio. Administración de Redes de Computadores. Ficha: 149822. DNS. Domain Name System. Sistema de Nombres de Dominio. Administración de Redes de Computadores. Ficha: 149822. John Deivis Tabares Tobón. Luis Fernando Ramirez Gallego. Configuracion del servidor DNS

Más detalles

DNS: Domain Name System

DNS: Domain Name System DNS: Domain Name System Bibliografía: Redes de Computadores: un enfoque descendente basado en Internet : J.F Kurose y K.W. Ross. 1 Nombres y direcciones Nombre: forma de identificar una entidad en un sistema

Más detalles

REDES DE ÁREA LOCAL. APLICACIONES Y SERVICIOS EN WINDOWS

REDES DE ÁREA LOCAL. APLICACIONES Y SERVICIOS EN WINDOWS REDES DE ÁREA LOCAL. APLICACIONES Y SERVICIOS EN WINDOWS Servicio DNS - 1 - Servicio DNS...- 3 - Definición... - 3 - Instalación... - 5 - Configuración del Servidor DNS...- 10 - - 2 - Servicio DNS Definición

Más detalles

Por D. Rafael J. Montero González

Por D. Rafael J. Montero González Por D. Rafael J. Montero González Introducción Sistemas de nombres planos vs. jerárquicos Historia de DNS Características y utilidad del servicio DNS Componentes y funcionamiento Espacio de nombres de

Más detalles

FUNDAMENTOS DE REDES CONCEPTOS DE LAS CAPAS SUPERIORES

FUNDAMENTOS DE REDES CONCEPTOS DE LAS CAPAS SUPERIORES FUNDAMENTOS DE REDES CONCEPTOS DE LAS CAPAS SUPERIORES Dolly Gómez Santacruz dollygos@univalle.edu.co CAPA DE SESION Conceptos El propósito principal de la capa de sesión en la pila OSI es minimizar los

Más detalles

Laboratorio 2 Introducción al DNS (Domain Name System)

Laboratorio 2 Introducción al DNS (Domain Name System) Redes de Datos - Laboratorio - Informe Laboratorio 2 Introducción al DNS (Domain Name System) Fecha: Puesto de trabajo: Procedimiento Comandos Unix 1. Escriba cómo utilizar el comando ifconfig para obtener

Más detalles

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores REPORTE OFICIAL OCTUBRE DE 2014 CA Unified Infrastructure Management para servidores 2 Reporte oficial: CA Unified Infrastructure Management para servidores Tabla de contenidos Descripción general de la

Más detalles

Sistemas de Nombres de Dominio DNS. Materia: Técnicas de Programación en Internet. Alumna: Claudia Mariana Coto Huezo. marianacoto@gmail.

Sistemas de Nombres de Dominio DNS. Materia: Técnicas de Programación en Internet. Alumna: Claudia Mariana Coto Huezo. marianacoto@gmail. Universidad Nacional de El Salvador Facultad Multidisciplinaria de Occidente Departamento de Ingeniería Sistemas de Nombres de Dominio DNS Materia: Técnicas de Programación en Internet Alumna: Claudia

Más detalles

Domain Name System. Ing. Carlos A. Barcenilla Ing. Agustín Eijo

Domain Name System. Ing. Carlos A. Barcenilla <c.a.barcenilla@ieee.org> Ing. Agustín Eijo <agu@frlp.utn.edu.ar> Domain Name System Ing. Carlos A. Barcenilla Ing. Agustín Eijo Qué es DNS? DNS es una base de datos distribuida, jerárquica y redundante. La información

Más detalles

Programas de Administración de red

Programas de Administración de red 1 Programas de Administración de red Introducción El propósito de las siguientes prácticas es el de familiarizar al alumno con los distintos programas que se utilizan para chequear y comprobar el estado

Más detalles

Universidad Autónoma de Manizales Departamento de Ciencias Computacionales

Universidad Autónoma de Manizales Departamento de Ciencias Computacionales Universidad Autónoma de Manizales Departamento de Ciencias Computacionales ASIGNATURA Redes LAN CÓDIGO 10126 NÚMERO DE CRÉDITOS Trabajo Presencial PRERREQUISITOS Trabajo dirigido 80 créditos aprobados

Más detalles

Servicios de directorio de Internet

Servicios de directorio de Internet Servicios de directorio de Internet Fernando Gont UTN/FRH, Argentina Congreso Internacional de Ingeniería en Computación 23 al 26 de septiembre de 2008, Ixtlahuaca, Mexico Breve presentación Realizo trabajos

Más detalles

Gestión de energía Solución integrada basada en la Web para el control de aplicaciones de energía convencional distribuida Modelo Em 2 -Server

Gestión de energía Solución integrada basada en la Web para el control de aplicaciones de energía convencional distribuida Modelo Em 2 -Server Gestión de energía Solución integrada basada en la Web para el control de aplicaciones de energía convencional distribuida Modelo Em 2 -Server Solución software con base de datos incorporada y servidor

Más detalles

1.Introducción. 2.Direcciones ip

1.Introducción. 2.Direcciones ip 1.Introducción El papel de la capa IP es averiguar cómo encaminar paquetes o datagramas a su destino final, lo que consigue mediante el protocolo IP. Para hacerlo posible, cada interfaz en la red necesita

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

Redes Tema: Protocolos y funcionalidad de la capa de aplicación. Integrantes: David Alcudia Aguilera Sergio García Moya Mónica Méndez Morales

Redes Tema: Protocolos y funcionalidad de la capa de aplicación. Integrantes: David Alcudia Aguilera Sergio García Moya Mónica Méndez Morales Redes Tema: Protocolos y funcionalidad de la capa de aplicación Integrantes: David Alcudia Aguilera Sergio García Moya Mónica Méndez Morales Modelo OCI y TCP/IP El modelo de referencia de interconexión

Más detalles

Modelado de actividades en redes locales.

Modelado de actividades en redes locales. Modelado de actividades en redes locales. Cristóbal Raúl Santa María smaria@sion.com 1561454636 UNLaM y U. de Morón. Gastón Iemmelo iemello_gaston@redlink.com.ar 4662-1365 U. de Morón. Marcelo Gonzalez

Más detalles

TEMA 2. SERVICIO DNS

TEMA 2. SERVICIO DNS 1 TEMA 2. SERVICIO DNS 1. Definición 2. Espacio de nombres de dominio 3. Zonas y delegación 4. Tipos de servidores DNS 5. Búsqueda de IP: recursiva e iterativa 6. Búsqueda inversa 7. Base de datos DNS.

Más detalles

Problemas sobre DNS y HTTP Sistemas Telemáticos I

Problemas sobre DNS y HTTP Sistemas Telemáticos I Problemas sobre DNS y HTTP Sistemas Telemáticos I Universidad Rey Juan Carlos Mayo de 2005 Problema 1 A las 9 de la mañana, cuando la red aún va rápida (aunque las caches están todas vacías), Juan hace

Más detalles

DOMINIOS DE NIVEL SUPERIOR A NIVEL MUNDIAL.

DOMINIOS DE NIVEL SUPERIOR A NIVEL MUNDIAL. INTRODUCCIÓN. Como detectar un host dentro de una red? Si millones de ellos se encuentran conectados, sabiendo además que éstos pertenecen a organizaciones, grupos, países y zonas geográficas diferentes.

Más detalles

Guía de uso Cloud Server. Guía de uso Cloud Server

Guía de uso Cloud Server. Guía de uso Cloud Server Guía de uso Cloud Server Guía de uso Cloud Server Calle San Rafael, 14 28108 Alcobendas (Madrid) 900 103 293 www.acens.com Introducción acens CLOUD SERVER te ofrece la posibilidad de tener tus servidores

Más detalles

Estudio del estado del DNS en nombres de dominio.cl

Estudio del estado del DNS en nombres de dominio.cl Estudio del estado del DNS en nombres de dominio.cl José Urzúa R. jourzua@dcc.uchile.cl Depto. de Cs. de la Computación, Escuela de Ingeniería y Ciencias Universidad de Chile Blanco Encalada 2120, tercer

Más detalles

CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED

CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED CAPITULO V. IMPLEMENTACIÓN DE UNA HERRAMIENTA INTEGRADA DE RED En el presente capitulo se presenta una aplicación que aborda una herramienta de monitoreo de redes para soportar estudios de disponibilidad.

Más detalles

Arquitecturas cliente/servidor

Arquitecturas cliente/servidor Arquitecturas cliente/servidor Conceptos básicos 1 Conceptos básicos 1. Definición de puerto 2. Sockets 3. Conceptos cliente/servidor 4. Definición de Stream 5. Concurrencia, multiprogramación y multitarea

Más detalles

ARQUITECTURAS CLIENTE/SERVIDOR

ARQUITECTURAS CLIENTE/SERVIDOR Arquitecturas Cliente/Servidor, Sem 2016-1 M.I.Yasmine Macedo Reza 1 ARQUITECTURAS CLIENTE/SERVIDOR Conceptos básicos Arquitecturas Cliente/Servidor, Sem 2016-1 M.I.Yasmine Macedo Reza 2 Conceptos básicos

Más detalles

La Universidad, la Tecnología y el Software Libre

La Universidad, la Tecnología y el Software Libre ESCUELA SUPERIOR POLITECNICA DE CHIMBORAZO La Universidad, la Tecnología y el Software Libre Carlos Volter Buenaño Pesántez DIRECTOR DEPARTAMENTO DE SISTEMAS Y TELEMATICA ESPOCH Mail: cbuenano@live.espoch.edu.ec

Más detalles

Práctica 7: Configuración de un router NAT

Práctica 7: Configuración de un router NAT Práctica 7: Configuración de un router NAT Cuando se contratan los servicios básicos de un ISP, éste nos proporciona una conexión a Internet con un ancho de banda determinado (de acuerdo al contrato elegido)

Más detalles

Beneficios estratégicos para su organización. Beneficios

Beneficios estratégicos para su organización. Beneficios La solución ideal para controlar la totalidad de su infraestructura IT mediante un inventario automatizado, control remoto y Gestión de activos informáticos. Beneficios Características Inventario actualizado

Más detalles

Protocolos y funcionalidad de la capa aplicaciones.

Protocolos y funcionalidad de la capa aplicaciones. Protocolos y funcionalidad de la capa aplicaciones. Transmisión de datos en las redes La transmisión de datos en las redes, puede ser por dos medios: 1.- Terrestres: Son limitados y transmiten la señal

Más detalles

IPv6 Servicios DNS. Objetivo. Introducción Teórica

IPv6 Servicios DNS. Objetivo. Introducción Teórica IPv6 Servicios DNS Objetivo El objetivo principal de este laboratorio es presentar el funcionamiento del servicio DNS (Domain Name System) en una red IPv6 utilizando el software BIND. Para esto, el laboratorio

Más detalles

Sistema de Nombres de Dominio (DNS)

Sistema de Nombres de Dominio (DNS) ADMINISTRACIÓN DE REDES Y SERVIDORES Sistema de Nombres de Dominio ESCUELA DE INGENIERÍA DE SISTEMAS Y COMPUTACION JOHN GÓMEZ CARVAJAL johncar@univalle.edu.co http://eisc.univalle.edu.co/~johncar/ars/

Más detalles

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 2: Servicios Básicos. DNS

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 2: Servicios Básicos. DNS Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows Módulo 2: Servicios Básicos. DNS Aulas en red. Aplicaciones y servicios. Windows DNS DNS (Domain Name System) es una abreviatura de Sistema

Más detalles

Solución Redes de Datos 2do parcial año 2010

Solución Redes de Datos 2do parcial año 2010 Solución Redes de Datos 2do parcial año 2010 Las hojas se escriben de un solo lado y preguntas separadas se responden en hojas separadas. Letra clara y legible. Respuesta concisa. Nombre, número de cédula

Más detalles