Diferencias

Muestra las diferencias entre dos versiones de la página.

--- sri:t2 [2018/11/07 12:50] – creado José Manuel Guallar
+++ sri:t2 [2024/11/26 11:55] (actual) – José Manuel Guallar
@@ Línea 1: / Línea 1: @@
-Contenidos
+Configurar un servidor DNS en Debian es un proceso que implica instalar y configurar BIND (Berkeley Internet Name Domain).
-•	Sistemas de nombres planos vs jerárquicos.
-•	Características y funcionamiento del servicio DNS.
-•	Espacio de nombres de dominio. Nombres de dominio. Dominios y subdominios. Delegación. Registro de nombres de dominio.
-•	Servidores de nombres. Zonas, tipos de servidores y servidores raíz.
-•	Clientes DNS (resolvers).
-•	Proceso de resolución. Consultas recursivas e iterativas. Cache y TTL.
-•	Resolución inversa.
-•	Base de datos DNS. Tipos de registros de recursos.
-•	Transferencias de zona. Actualizaciones de DNS dinámicas.
-•	Seguridad DNS.
-•	Whois
-Objetivos
-•	Identificar y describir escenarios en los que surge la necesidad de un servicio de resolución de nombres
-•	Clasificar los principales mecanismos de resolución de nombres y describir la estructura, nomenclatura y funcionalidad de los sistemas de nombres jerárquicos.
-•	Instalar y configurar servicios jerárquicos de resolución de nombres, reenviar consultas de recursos externos a otro servidor de nombres y almacenar y distribuir las respuestas procedentes de otros servidores.
-•	Añadir registros de nombres correspondientes a una zona nueva, con opciones relativas a servidores de correo y alias y realizar transferencias de zona entre dos o más servidores.
-•	Implementar soluciones de servidores de nombres en direcciones "ip" dinámicas.
-•	Documentar los procedimientos de instalación y configuración.
-.- Introducción
+Requisitos previos
-Las direcciones IP que identifican a los equipos en las redes TCP/IP, son números fáciles de manejar para las máquinas pero que pueden resultar complicados de utilizar y memorizar para los humanos. A las personas les resulta más sencillo usar y recordar nombres.
-Para facilitar el uso de los servicios y recursos que ofrece una red se han creado sistemas de nombres utilizados por servicios de resolución de nombres que permiten asociar nombres sencillos con direcciones numéricas. Los servicios de nombres almacenan las direcciones y sus nombres (por ejemplo, "ftp.asir.es" se corresponde con la dirección IP 193.100.200.102). El proceso por el cual "se traduce" entre un nombre y una dirección numérica es lo que se denomina "resolver el nombre".
-El principal servicio de resolución de nombres usado en redes TCP/IP, y por lo tanto en Internet, es el servicio DNS (Domain Name System o Sistema de Nombres de Dominio).
-.-    Sistemas de nombres planos vs jerárquicos
+.	Sistema operativo Debian instalado.
-Los sistemas de nombres, no solo los usados en redes, se pueden clasificar en:
-■ Sistemas de nombres planos:
-•	Uso de nombres sin ningún tipo de agrupamiento.
-•	No existe una jerarquía que permita clasificar dichos nombres.
-• Ejemplos: DNIs, nombres de ciudades, de calles, nombres NETBIOS de windows...
-■ Sistemas de nombres jerárquicos:
-•	Uso de nombres agrupados y clasificados según algún criterio( por ejemplo distribución geográfica, funcionalidad, tamaño
-•	Facilitan la administración y gestión y gestión distribuida
-•  Ejemplos: numero de teléfono 0034918889999 identifica España y Madrid, C:\datos\apuntes.txt.
-DNS ofrece un sistema de nombres jerárquico
-.-    Historia de DNS
+.	Acceso como usuario con privilegios de superusuario.
-En los comienzos de Internet se usaba un sistema de nombres planos. La relación entre nombres de equipos (hosts) y direcciones IP se almacenaba en un archivo (host.txt) localizado en un servidor central. Los equipos de la red obtenían periódicamente por FTP el archivo y así podían usar los nombres que contenía.
-Inicialmente, este esquema funcionaba bien (hasta mediados de los años 80) porque había pocos nombres y el fichero se actualizaba pocas veces a la semana. A medida que el número de equipos de la red aumentaba, el tamaño del archivo crecía y esto desencadenó una serie de problemas.
-•	Sobrecarga del servidor que contenía el fichero hosts como consecuencia del aumento del tamaño del fichero y del número de descargas.
-•	Tráfico y carga de la red como consecuencia de la descarga del fichero.
-•	Aumento de la probabilidad de duplicidad de nombres al usarse un sistema de nombres plano.
-•	Dificultad para administrar el fichero y gestionar las múltiples peticiones de nuevos nombres.
-Ante los problemas de funcionamiento se pensó en un nuevo sistema que ofreciera características tales como escalabilidad, administración descentralizada, velocidad, etc. El nuevo sistema fue DNS y se introdujo en 1983.
-.    Características y utilidad del servicio DNS
+.	Configuración de red estática en el servidor.
-DNS ofrece un servicio de almacenamiento y consulta de información. La información se guarda en una base de datos distribuida entre múltiples equipos (servidores de nombres) y se indexa según un esquema de nombres jerárquico (espacio de nombres de dominio). A los servidores de nombres se les pueden realizar preguntas y para ello se usan programas (clientes DNS) que dialogan con los servidores en base a unas reglas (protocolo DNS).
-DNS puede almacenar varios tipos de información sobre cada nombre de dominio y por ello se puede utilizar para diferentes propósitos. Lo habitual es asociar direcciones IP con nombre de dominio y por eso se utiliza comúnmente para:
-■ Resolución de nombres (búsqueda directa)
+.	Nombre de dominio que deseas configurar (por ejemplo, asir.es).
-•	Obtener la información asociada a un nombre de dominio
-•	Por ejemplo, ¿cuál es la dirección o direcciones IP asociada al nombre "www.asir.es"
-■ Resolución inversa de direcciones (búsqueda inversa)
-•	Mecanismo inverso al anterior.
-•	Por ejemplo, ¿cuál es o cuáles son los nombres de dominio asociados a la dirección IP 200.100.89.10?
-■  Resolución de servidores de correo
-•	Dado un nombre de dominio, por ejemplo "gmail.com", obtener el servidor a través del cual debe realizarse la entrega del correo electrónico ( "gmail-smtp-in.l.google.com").
-También se puede utilizar DNS para otros propósitos: balanceo de carga, obtención de claves públicas, ubicación de servidores para un servicio determinado, listas negras de spam, etc.
-En los siguientes apartados se explica el funcionamiento de DNS utilizando ejemplos basados en la resolución directa de nombres. Una vez tratado de forma global el servicio se explica la resolución inversa
-.5.     Componentes y funcionamiento
-El servicio que ofrece DNS se basa en los siguientes componentes,
-• Espacio de nombres de dominio (domain name space). Conjunto de nombres que se pueden utilizar para identificar maquinas o servicios de una red
-• Base de datos DNS. Base de datos distribuida  y redundante, que almacena información, por ejemplo direcciones IP sobre los nombres de dominio. Esta base de datos se organiza en zonas que almacenan la información en lo que se conoce como registros (RR, Reosurce Records)
-• Servidores de nombres (o servidores DNS) (name servers): Programas que guardan parte de la base de datos DNS (zonas) y que responden a preguntas sobre la información almacenada. Por ejemplo, ¿cuál es la dirección IP asociada al nombre "www.asir.es"?
-• Cliente DNS (resolvers). Programas que realizan preguntas a los servidores de nombres y procesan las respuestas para ofrecerle la información a los usuarios y/o a las aplicaciones que los invocan
-• Protocolo DNS. Conjunto de normas y reglas en base a las cuales "dialogan" los clientes y los servidores DNS
-El funcionamiento del servicio DNS se basa en el modelo cliente/servidor:
-■   Los clientes DNS (resolvers) preguntan a los servidores de nombres.
-■   Los servidores de nombres también se comunican entre sí.
-•	Pueden realizar preguntas a otros servidores de nombres cuando no tienen la información por la que le han preguntado.
-•	Pueden intercambiar información sobre sus zonas (transferencias de zona)
-.    Espacio de nombres de dominio
-El espacio de nombres de dominio  es el conjunto de nombres que se pueden utilizar para identificar maquinas o servicios de una red.
-.1.    Nombres de dominio
-Cada nombre de dominio puede estar formado por una o varias cadenas de caracteres separadas por puntos. No se distingue entre mayúsculas y minúsculas, por ejemplo, "ASIR.ES." es equivalente a "asir.es.".
-Ejemplos de nombres de dominio:
-"pc01.redes.asir.es."
-"com."
-"redes.asir.es."
-"google.com."
-El conjunto de nombre, forman el denominado espacio de nombres de dominio que se puede representar mediante una estructura jerárquica organizada en forma de árbol es decir todos los nombres forman un árbol donde cada nodo se separa de los otros nodos por un punto.
-Se pueden usar nombres que tengan como máximo 127 niveles y cada parte separada por puntos, es decir, cada uno puede tener como máximo 63 caracteres. En total un nombre de domino no puede superar los 255 carácteres
-.2    Dominio raíz. Dominios y subdominios
-	Observa que en los ejemplos anteriores el dominio termina en punto ".". Esto es así  porque el árbol de nombres de dominio empieza en el dominio "." que se conoce como dominio raíz (root). Realmente es un nombre nulo con 0 caracteres pero se representa usando un punto "."
- Como consecuencia de la organización jerárquica de los nombre de dominio es posible utilizar los términos dominio y subdominio, al igual que en un sistema de ficheros de un disco duro es posible referirse a directorios y subdirectorios.  Por ejemplo, "asir.es" es un subdominio del dominio ".es". "redes.asir.es." es un subdominio del dominio "asir.es.". Los dominios o subdominios (usa el término que prefieras) que "cuelgan" del dominio raíz se conocen como dominios de primer nivel o dominios de nivel superior (TLD, Top Level Domains), los que "cuelgan" de los dominios de primer nivel se denominan dominios de segundo nivel y así sucesivamente.
-.3.     Nombres relativos y absolutos. FQDN
-Supongamos que hemos decido usar dominio "asir.es." para nombrar a todos los equipos de la red de área local. En la red hay varios equipos y a cada uno se le identifica con uno o varios nombres que formen parte del dominio "asir.es.".
-Si hacemos referencia a   "www.asir.es." sabemos que se trata del equipo con IP 193.100.100.101, y si hacemos referencia a   "www.google.es." sabemos que se trata de otro equipo diferente. Si tan solo usamos www podríamos interpretar que el equipo "www.asir.es." en nuestra red tan solo usamos  el nombre de dominio "asir.es", pero ¿por qué tiene que ser este y no otro?
-Cuando se hace referencia a un dominio usando un nombre se puede emplear su nombre relativo o su nombre absoluto.
-■ Nombres Relativos: es necesario saber el contexto del dominio superior para determinar a que nombre se hace referencia exactamente. por ejemplo "obelix", "www", "panoramix.asir"
-■ Nombres absolutos: nombre formado por todas las partes separadas por puntos desde el nodo correspondiente hasta el dominio raiz. Por ejemplo "asir.es.", obelix.asir.es", "www.asir.es". Los nombres indicados de esta forma se llaman nombres de dominio completos (FQDN, Fully Qualified Domain Names). El "." final del dominio raíz permite distinguir si el nombre usado es FQDN o no.
-Normalmente, los usuarios no utilizamos el "." final del los nombres FQDN en las aplicaciones (navegadores web, clientes ftp.clientes de correo...), pero internamente si se usa.
-.4.     Uso de dominios
-Lo habitual os usar un dominio, por ejemplo "asir.es", para nombrar a un conjunto de hosts y/o subdominios que se agrupan según algún criterio (hosts de la misma red. hosts de la misma empresa - este en la misma o en diferentes redes - , hosts de una misma localización,...) aunque no tiene por qué ser así.
-Se podría usar el dominio "asir.es" como en ejemplo anterior (equipos de una red de área local), pero también se podría emplear para referirse a hosts que no tienen por qué formar parte de la misma red ("www.asir.es" -> 90.100.10.10, "obelix.asir.es -> 200.10.20.1 "ftp.asir.es" ->100.100.100.2...)
-.5.    Administración de nombres de dominio en Internet. Delegación
-La administración y organización del espacio de nombres de dominio de Internet se distribuye entre múltiples empresas  y organizaciones, estando coordinada por la ICANN (Internet Corporation for Assigned Names and Numbers)
-.5.1.     Dominio raíz y la ICANN
-La ICANN' es una organización sin ánimo de lucro que tiene el objetivo de garantizar que Internet sea estable, operativa y segura. Se encarga, entre otras funciones, de administrar el dominio raíz y de mantener un registro de los dominios de nivel superior (TLD) existentes.
-InterNIC es la organización asociada a la ICANN que permite registrar dominios TLD
-.5.2.    Dominios TLD y los operadores de registro (registry)
-Los dominios de nivel superior (TLD, Top Level Domain) son clasificados por la ICANN desde un punto administrativo en:
-■ Genéricos (gTLD, generic TLD)
-•  Nombre significativo en función del propósito o el tipo de organización que lo utiliza.
-•  Se clasifican a su vez en:
-•	Dominios patrocinados (sTLD, sponspred TLD), Operan según las reglas de una entidad que soporta su patrocinio (Ejemplos: "aero", "asia", "cat", ucoop', "edu*, '"gov", "travel",...).
-•	Dominios no patrocinados (nTLD, unsponsored TLD). Operan según las reglas del ICANN con unas políticas de uso establecidas globalmente (Ejemplos: "com", "info", "org", "net",...).
-■ Geográficos (ccTLDs, country code TLDs)
-•  Nombres de dos letras establecidos en función países o regiones.
-•  Las tareas de gestión y políticas de uso se delegan en una entidad del país o territorio (el gobierno de cada país determina la entidad que gestiona el dominio) para favorecer las políticas locales, que permitan satisfacer mejor las circunstancias economicen, culturales, lingüísticas y legales del país o territorio en cuestión.
-•  Ejemplos: "es" (España), "fr" (Francia), "np" (Nepal), etc.
-■ arpa
-• Además de los gTLD y ccTLD existe el dominio "arpa", que se utiliza para la infraestructura técnica de Internet. ICANN lo administra en cooperación con la comunidad técnica de Internet bajo la dirección de la IAB (Internet Architecture Board).
-• Los  dominios "in-addr.arpa." y "ip6.arpa" se utilizan para resolución inversa de direcciones IP
-■ Dominios reservados
-• Existen una serie de nombres de dominio de primer nivel que están reservados para que puedan usarse en pruebas privadas, ejemplos de documentación, etc. sin temor a entrar en conflicto con nombres TLD actuales o futuros.
-• Los nombre reservados "test", "example", "invalid"  y "localhost".
-La administración de cada TLD (incluyendo la gestión y el registro de los dominios de segundo nivel dentro del TLD) es delegado en una organización particular. Estas organizaciones se denominan operadores de registro (registry operators) o patrocinadores (sponsors) y están acreditadas por la ICANN. Por ejemplo, la ICCAN delega en Red.es (http://wvw.red.es) la administración del dominio "es".
-Actividad:
-■ Lee la información sobro la función de la ICANN en http: //www.icann.org/es/participate/what-icann-do-es.htm.
-■   Consulta la web http://ww.iana.org/domains/root/db/ y observa los dominios TLD existentes y como se clasifican según la ICANN.
-■   Consulta el documento http://www.rfc-es.org/rfc/rfc2606-es.txt donde se explica el uso recomendado de los dominios reservados.
-Actividad:
-■ Consulta la web http://www.iana.org/domains/root/db/ para saber cuál es el operador de registro (registry) que se encarga de los dominios TLD "com", "net"  y "es"
-■ Accede a la web http://www.red.es y consulta la información que ofrece sobre el dominio "es"
-.5.3.     Delegación
-La administración descentralizada de DNS (recuerda que los nombre de dominio y la información asociada a ellos, como direcciones IP, constituyen una base de datos distribuida en múltiples servidores de nombres) se basa en la delegación
-La delegación consiste en que la organización que administra un dominio cede la administración a uno, varios o todos sus subdominios a otras organizaciones, como ya se ha explicado, la ICAAN administra el dominio raíz y delega la administración de los dominios TLD en otras organizaciones. Cada una de estas organizaciones (por ejemplo red.es para el dominio "es") puede delegar la administración de los dominios de segundo nivel en otras ( por ejemplo red.es delega la administración del dominio "upm.es" en la universidad Politécnica de Madrid. A su vez, cada organización puede delegarla administración de sus subdominios en otras organizaciones y  así sucesivamente (por ejemplo, la Universidad Politécnica de Madrid puede delegar la administración del dominio "fi.upm.es" en la facultad de informática)
-La división de un dominio en subdominios no implica siempre ceder su delegación (por ejemplo, la Universidad Politécnica de Madrid puede crear los subdominios "fi.upm.es" y "rectorado. upm.es", encargase de la administración del subdominio "rectorado.upm.es". y delegar solo la administración del dominio "fi.upm.es"). Además, si una organización delega un subdominio en otra, no tiene por qué informar a "su superior" (la Universidad Politécnica de Madrid no tiene por qué informar a Red.es de que ha delegado el dominio ufi.upm.es").
-La organización que administra un dominio es responsable de los nombres usados en ese dominio, de las direcciones IP asociadas a ellos y, del funcionamiento y mantenimiento de los servidores de nombres que almacenan esta información.
-.5.4.    Registro de dominios. Agentes registradores (registrar)
-Registrar un dominio consiste en "reservar" el nombre durante un tiempo (normalmente durante un año) para poder crear subdominios y asociar el nombre y/o los subdominios con direcciones IP o con la información que se considere oportuna. Las personas, empresas u organizaciones, denominadas registradores (registrar), pueden registrar nombres de dominio de segundo nivel (por ejemplo, "asir.es"...). Existen diferentes normativas que determinan qué nombres se pueden registrar en función del uso que se le dará y del dominio TLD del que depende.
-Un nombre de dominio puede ser registrado a través de diferentes compañías, conocidas como agentes registradores (registrant), que asesoran a los registradoras (registrar), y tramitan la solicitud haciendo de intermediario con los operadores de registro (registry) (estos también pueden actuar como aguates registradores). Los agentes registradores deben estar acreditados por los operadores  de registro y tienen libertad para asignar una parte del precio que cuesta el registro
-Actividad:
-■ Consulta las preguntas frecuentes (FAQs) de la web de la ICANN ((http://ww.icann.org/es/faq/).
-•  ¿Cuáles son las normas de registro de los dominios gTLD''
-•  ¿Cuáles son las normas de registro de los dominios ccTLD?
-•  Si hay problemas con un agente registrador ¿Hay que informar la ICANN?
-Consulta las web de la ICANN (http://www.icann.org) y de InterNIC (http://www.internic.net/) para conocer una lista de agentes registradores acreditados
-Consulta la web de Red.es (http://www.red.es) para consultar la lista de agentes registradores acreditados para el dominio "es"
-Actividad
-Elige un nombre de dominio (por ejemplo, "minombre.com"), accede a la web de tres agentes registradores acreditados por Red.es y:
-■ Comprueba que no está registrado.
-■ Realiza una comparativa de precios entre los 3 agentes registradores.
-■ Elige un agente registrador y completa el proceso de registro hasta el punto donde se pide que realices el pago.
-.7.    Servidores de nombres
-Los servidores de nombres, también llamados servidores DNS, son programas que guardan información sobre nombres de dominio y responden a las preguntas que les realizan los clientes DNS y otros servidores de nombres. Almacenan por lo tanto, una parte de la base de datos DNS,
-Por defecto escuchan peticiones en los puertos 53/TCP y 53/UDP.
-.7.1.     Zonas
-Los servidores de nombres mantienen información de una parte del espacio de nombres de dominio que se conoce como zona (por ejemplo, el servidor DNS del Instituto ASIR almacena la información de la zona "asir.es."). Cuando un servidor de nombres contiene una zona se dice que es autorizado (authoritative) para esa zona (el servidor de DNS del colegio ASIR es autorizado para la zona "asir.es")
-Las zonas se almacenan en ficheros de texto o en bases de datos (en tablas relacionales, en un directorio LDAP, etc), dependiendo del tipo de servidor usado y de cómo se configure. Su formato está definido en la RFC 1035.
-En el siguiente ejemplo se puede observar una parte del fichero de zona del dominio "asir.es".
-Cada una de las líneas del fichero es lo que se conoce como registro de recursos (RR Resource  Records). Según el tipo de información que se asocie con un nombre de dominio se utiliza un tipo de registro de recursos (por ejemplo, un registro de tipo A permite asociar una dirección IP con un nombre de dominio y un registro NS permite definir un servidor DNS autorizado para la zona). Cuando un servidor DNS es autorizado para una zona es responsable de los nombres de dominio de la misma. El servidor DNS del colegio ASIR que es autorizado para la zona "asir.es", y por lo tanto en él se define los nombres que "cuelgan" de "asir.es" como por ejemplo "ftp.asir.es". "asterix.asir.es", etc.
-Fichero de zona de resolución directa del dominio asir.es. que se almacena en un servidor DNS que esta en el equipo con IP 193.100.200.100 y cuyo nombre es ns1.asir.es.
-asir.es.                             IN		NS           ns1.asir.es.
-nsl.asir.es.                     IN	 A             193.100.200.100
-obelix.asir.es.              IN		 A             193.100.200.101
-asterix.asir.es.            IN 	A             193.100.200.102
-www.asir.es.                     IN 	CNAME     obelix.asir.es.
-ftp.asir.es.                     IN 	CNAME     asterix.asir.es.
-Como se ha explicado anteriormente la organización que administra el servidor de nombres y por lo tanto la zona puede decidir si delega o no alguno de sus subdominios
-En los siguientes ejemplos se puede observar como el instituto ha delegado el subdomino "redes.asir.es", en los profesores de redes. Existirá otro servidor DNS que sea autorizado para el domino "redes.asir.es• y que almacene el fichero de zona del dominio. Sin embargo, el subdominio "bbdd.asir.es" no se ha delegado.
-Una zona no es lo mismo que un dominio. Un dominio es un subarbol del espacio de nombres de dominio. Los datos asociados a los nombres de un dominio pueden estar almacenados en una o varias zonas distribuidas en uno o varios servidores DNS
-Fichero de zona de resolución directa del dominio asir.es. que se almacena en un servidor DNS que esta en el equipo con IP 193.100.200.100 y cuyo nombre es ns1.asir.es.
-asir.es.                               IN	 NS            nsl.asir.es.
-nsl.asir.es.                      IN	 A              193.100.200.100
-obelix.asir.es.               IN	 A              193.100.200.101
-asterix.asir.es-             IN 	 A              193.100.200.102
-www.asir.es.                      IN	 CNAME     obelix.asir.es.
-ftp.asxr.es.                      IN	 CNAME     asterix.asir.es.
-;Subdominio redes.asir.es delegado
-redes.asir.es.                  IN	 NS            nsl.redes.asir.es.
-nsl.redes.asir.es.         IN 	A              193.100.40.100
-;Subdominio bbdd.asir.es. No delegado.
-www.bbdd.asir.es.           IN 	A              193.100.110.200
-pcOl.bbdd.asir.es.        IN 	A              193.100.110.101
-pc02.bbdd.asir.es.        IN	A              193.100.110.102
-Fichero de zona de resolución directa del dominio redes.asir.es. que se almacena en un servidor DNS que esta en el equipo con IP 193.100.40.100 y cuyo nombre es ns1.redes.asir.es.
-redes.asir.es.                 IN NS           nsl.redes.asir.es.
-nsl.redes.asir.es.        IN 	A             193.100.40.100
-www.redes.asir.es.        IN 	A             193.100.40.200
-pcOl.redes.asir.es.      IN 	A             193.100.40.101
-pc02.redes.asir.es.      IN	A             193.100.40.102
-Un servidor de nombres puede tener autoridad sobre varias zonas (por ejemplo, el mismo servidor puede ser autorizado para la zona "asir.es" y para la zona "informatica.es'").
-Supongamos que el servidor autorizado para la zona "asir.es", tiene un problema y deja de estar activo, ¿Qué pasaría cuándo los clientes DNS le preguntasen.', y si el servidor autorizado Para "google.com" recibe tantas preguntas que responde lentamente, ¿qué ocurriría cuando un los usuarios de Internet pusiese en el navegador www.google.com y tuviesen que esperar varios segundos?
-Para evitar este tipo de problemas y mejorar el funcionamiento del servicio, DNS permite almacenar una misma zona en varios servidores DNS, ofreciendo así balanceo de carga, rapidez y una mayor tolerancia a fallos. Teniendo en cuenta esto es posible distinguir entre zonas maestras o primarias y zonas esclavas o secundarias
-.2.     Tipos de servidores de nombres
-Según la función que realizan loe servidores de nombres se pueden clasificar en diferentes tipos:
-■   Servidor maestro o primario.
-■   Servidor esclavo o secundario.
-■   Servidor cache.
-■ Servidor reenviador (forwarding).
-■   Servidor solo autorizado.
-Es muy importante tener en cuenta que mismo servidor DNS puede combinar varias de estas funciones simultáneamente (por ejemplo, un servidor DNS puede ser simultáneamente maestro para una zona, secundario para otra y actuar como caché)
-.2.1.     Servidor maestro (o primario)
-Un servidor DNS maestro (también denominado primario o principal) define una o varias zonas para las que es autorizado. Sus archivos de zona locales son de lectura y escritura y es en ellos donde el administrador añade, modifica o elimina nombres de dominio.
-■  Si un cliente DNS u otro servidor DNS le pregunta por un nombre de dominio para el que es autorizado, consulta con los ficheros de zona y responde a la pregunta.
-■  Si un cliente DNS u otro servidor DNS le pregunta por un nombre de dominio para el que el que no es autorizado, tendrá que buscar la información en otros servidores DNS o responder que no conoce la respuesta.
-.2.2.     Servidor esclavo (o secundario)
-Un servidor esclavo (también denominado secundario) define una o varias zonas para las que es autorizado. La diferencia con un maestro es que obtiene los ficheros de zona de otro servidor autorizado para la zona (normalmente un servidor maestro) mediante un proceso que se denomina transferencia de zona. Los ficheros de zona del servidor esclavo son solo de lectura, y por lo tanto, el administrador no tiene que editar estos ficheros. La modificación de los ficharos de zona debe realizarse en el servidor maestro.
-El funcionamiento ante las respuestas de los clientes es similar al de un servidor maestro.
-Ten en cuenta que la definición de maestro o esclavo se determina a nivel de zona, así, un servidor DNS puede ser maestro para una o varias zonas y al mismo tiempo esclavo para otras (por ejemplo, el servidor DNS de instituto ASIR puede ser maestro para la zona asir.es y esclavo para la zona dam.es), Pueden exigir varios servidores esclavos para una misma zona. Las principales razones para su implantación son:
-■  Reducir y repartir la carga entre varios servidores.
-■  Favorecer la tolerancia a fallos (al menos un servidor primario y un secundario para cada zona).
-■  Ofrecer respuestas mas rápidas.
-Lo ideal es que los servidores DNS de una zona esté ubicados en redes y localizaciones diferentes para evitar que un problema (como fallo eléctrico o un ataque de denegacón de servicio) les afecte simultáneamente y deje sin servicio de resolución a los nombres de dicha zona
-.2.3.     Servidor cache
-El proceso de resolución de nombres es costoso ya que utiliza los recursos de la red y los recursos de los equipos que ejecutan los servidores y los clientes. Para mejorar los tiempos de respuesta de las consultas, reducir la carga de los equipos y disminuir el tráfico de red, los servidores de nombres pueden actuar como servidores caché
-Cuando un servidor DNS recibe una pregunta sobre un nombre de dominio de una zona para la que no es autorizado, es decir, de un nombre del que no tiene información, puede preguntar ( si así se ha configurado) a otros servidores para que le den la respuesta. Si el servidor actúa como cache guarda durante un tiempo (TTL, Time To Live) las respuestas a las últimas preguntas que ha realizado a otros servidores de nombres. Cada vez que un cliente DNS u otro servidor DNS le formula una pregunta, consulta en primer lugar en su memoria caché, ahorrándose la pregunta a otros servidores si ya la había hecho anteriormente.
-Un servidor de nombres es solo cache (caching only server) cuando:
-•	No tiene autoridad sobre ningún dominio.
-•	Pregunta a otros servidores para resolver las peticiones de los clientes DNS y guarda las respuestas en cache.
-Actividad: Busca en Internet un listado que muestre los servidores DNS cache que ofrecen las empresas de comunicación que operan en España. Buscar cuáles son los servidores DNS cache que pone Google a disposición de todos los usuarios de Internet
-.2.4.    Servidor reenviador (forwarder)
-Cuando un servidor DNS recibe una pregunta sobre un nombre de dominio del que no dispone información puede preguntar a otros servidores DNS. ¿A cuantos servidores pregunta y como lo hace? Por ahora vamos a simplificar distinguiendo entre dos posibilidades:
-Se encarga de procesar la consulta preguntando a diversos servidores DNS y empezando por los servidores DNS raíz.
-Reenvía la consulta a otro servidor DNS, que se denomina reenviador (forwarder), para que se encarque de resolverla
-Por lo tanto, un reenviador es un servidor DNS que otros servidores DNS designan para reenviarles consultas. Se utilizan para minimizar las consultas y el tráfico de peticiones DNS desde una red hacia Internet. Además permite a los equipos locales compartir la caché DNS del reenviador minimizando los tiempos de respuesta
-.7.2.5.     Servidor solo autorizado
-El término solo autorizado (authoritative only) se usa para describir un servidor que:
--   Es autorizado para una o varias zonas como maestro y/o esclavo.
--   No responde a preguntas que no sean relativas a sus zonas, es decir, no pregunta a otros servidores DNS. Esto implica que no tiene activada le recursividad, no es reenviador y no actúa como caché
-Actividad accede a alguna de las máquinas de la red virtual debianXX, w7XX....) y abre un terminal.
-•  Ejecuta el comando nslookup www.google.es  8.8.8.8 para preguntar al servidor DNS de 8.8.8.8 por el nombre de dominio www.google.es. Observa que la respuesta es no autorizada. Significa que el  servidor DNS no es autorizado para la zona google.es.
-•   Ejecuta el comando nslookup www.google.es ns1.google.com para preguntar al servidor DNS de ns1.google.com por el nombre de dominio www.google.es. Observa que la respuesta es autorizada. Significa que el servidor DNS si es autorizado para google.es.
-•   Ejecuta el comando nslookup www.colegiomontessori.com 8.8.8.8 para preguntar al servidor DNS de 8.8.8.8 por el nombre de dominio www.colegiomontessori.com ¿Qué significa?
-•   Ejecuta el comando nslookup www.colegiomontessori.com ns1.google.com para preguntar al servidor DNS de 8.8.8.8 por el nombre de dominio www.colegiomontessori.com ¿Qué significa? ¿Qué diferencia hay entre el servidor DNS de 8.8.8.8 y el servidor DNS de ns1.google.com?
-.7.3.    Ejemplos de servidores de nombres
-Existen múltiples servidores DNS tanto para sistemas libres como para sistemas propietarios. Algunos de los más utilizados son:
-. BIND (http://www.isc.org/software/bind http://www.bind9.net
-. Servidor DNS de Microsoft (http://www.microsoft.com/dns).
-. PowerDNS (http://www.powerdns.com/).
-. NSD (http://www.nlnetlabs.nl/projects/nsd/).
-. Simple DNS (http://www.simpledns.com/).
-. Cisco network registrar (http://www.cisco.com/en/US/products/sw/netmgtsw/ps1982/)
-. dnsmasq (http://www.thekelleys.org.uk/dnsmasq/doc.html
-.4.    Servidores raíz (root servers)
-Existen en Internet un conjunto de servidores DNS autorizados para el dominio raíz conocidos como servidores raíz (root servers). Contienen por lo tanto el fichero de la zona que almacena cuales son los servidores DNS autorizados para cada uno de los dominios TLD
-Los servidores raíz están bajo la responsabilidad de la ICANN pero son operados por un consorcio de organizaciones. El RSSAC (Root Servers Systems Advisory Committee) proporciona asesoramiento en su administración. "Existen 13 servidores raíz" y cada uno de ellos tiene múltiples copias distribuidas por todo el mundo (es decir, que realmente no existen solo 13). Cada grupo, cada conjunto de copias de uno de los 13, se identifica por una misma IP. Cuando un cliente realiza una pregunta a una IP de un servidor raíz, ten en cuenta que esa IP se corresponde realmente con tantos equipos como copias de ese servidor existan, los routers de Internet encaminan la pregunta hacia la copia más cercana mediante un procedimiento denominado anycastinq.
-Estos servidores son claves en el proceso de resolución de nombres de dominio en Internet y deben ser conocidos por todos los servidores DNS que respondan a preguntas sobre nombres para los que no son autorizados.
-Actividad  Consulta la web de enlaces populares de la de la IANA (http://www.iana.org/about/popular-links/), descarga el archivo root.zone y ábrelo en un editor de textos. Este archivo es una copia del fichero de la zona "." que contienen los servidores DNS raiz. Aunque no entiendas la mayor parte del contenido del fichero observa que hay varios registros de recursos de tipo NS para cada dominio TLD. Cada uno de ellos indica los servidores de nombre autorizados para el dominio TLD correspondiente. Así como los servidores raíz delegan la autoridad de los dominios TLD en los servidores DNS de los operadores de registro (registry). Compara los servidores autorizados para el domino "es" definidos en el fichero con los descritos en la web http://www.iana.org/domains/root/db/
-Actividad Consulta las webs http://root-servers.org/ y http://public-root.com para conocer los servidores raíz, como se nombran, dónde se ubican y que empresas se encargan de su administración como para sistemas propietarios.
-Actividad Consulta la web de enlaces populares de la de la IANA (http://www.iana.org/about/popular-links/), descarga el archivo named.root (Hints File) y ábrelo con un editor de textos. Contiene una copia del la información que tienen los servidores DNS que necesitan conocer cuáles son los servidores raíz.
-.8.    Clientes DNS (resolvers)
-Se puede considerar que un resolver es cualquier software capaz de preguntar a un servidor DNS e interpretar sus respuestas.
-Los sistemas operativos incluyen o permiten instalar un conjunto de librerías, denominadas stub resolver, que realizan estas funciones. Son invocadas por las aplicaciones (navegador web, cliente ftp,...) cuando se utiliza un nombre de dominio. Si se configuran para ello pueden mantener una cache de respuestas, al igual que los servidores de nombres, para minimizar los accesos a la red e incrementar el rendimiento.
-La forma en la que se resuelven nombres de dominio en un sistema operativo es configurable. En la mayoría de los sistemas hay archivos de texto en donde se pueden asociar direcciones IP con nombres y es posible definir si el resolver mirará en primer lugar en estos archivos para hacer la resolución. También es posible habilitar o no la cache de respuestas.
-Cuando una aplicación quiere resolver un nombre invoca al resolver
-.	El resolver consulta la cache de resolución de nombres del hosts (si está configurada) (almacenada en memoria). Si obtiene una respuesta positiva se la entrega a la aplicación.
-.	Si el nombre buscado no está en la cache, el resolver buscará en el archivo hosts local del equipo. En sistemas Windows el archivo es %SYSTEMROOT %\system32\drivers\etc\hosts y en sistemas Linux/Unix el archivo es /etc/hosts.
-.	Si el nombre buscado no está en el archivo hosts, el resolver efectuará una consulta recursiva al servidor de nombres que esté configurado y le entregará la respuesta a la aplicación.
-.    Proceso de resolución
-Ya hemos visto que los clientes y los servidores DNS consultan a otros servidores para resolver nombres de dominio. En este apartado se explica qué tipos de consultas existen y qué características tienen. Pretendemos que estas explicaciones sirvan para afianzar conceptos como delegación, autoridad, cache, reenviadores, utilidad de los servidores raíz...
-Las consultas a un servidor DNS pueden ser de dos tipos: recursivas o iterativas.
-.1.    Consultas recursivas
-Una consulta recursiva es aquella en la que el servidor tiene que dar una respuesta completa o exacta. Hay tres posibles respuestas:
-• Respuesta positiva, es decir, da la información del nombre por el que se ha preguntado. En ella se indica si es autorizada o no. No es posible saber si el servidor que responde con autoridad es maestro o esclavo para el dominio preguntado.
-■ Respuesta negativa, indica que el nombre no se pudo resolver (NXDOMAIN).
-Una indicación de error (por ejemplo, que no se puede preguntar a otros servidores por un fallo de red).
-Cuando un servidor recibe una consulta recursiva:
-.   Si es autorizado para alguna zona (maestro o esclavo) comprueba sus archivos de zona. Si encuentra respuesta responde indicando que la respuesta es autoritativa
-.   Si no encuentra la respuesta o no es autorizado y actúa como caché, consulta su cache de respuestas anteriores. Si encuentra la respuesta responde indicando que la respuesta no es autoritativa.
-.   En otro caso:
-a Si tiene configurados reenviadores entonces reenvia la consulta recursiva a otro servidor DNS. La respuesta que obtenga se la traslada al cliente o al servidor que le preguntó.
-b Si no tiene configurados reenviadores:
-Inicia una serie de consultas iterativas a otros servidores DNS.
-Los servidores DNS consultados devuelven referencias (referrals) a otros servidores DNS que se usan para realizar otra pregunta
-La recursividad finaliza siempre cuando un servidor autorizado del espacio de nombres proporcione una respuesta positiva o negativa
-Si un servidor que actúa como cache obtiene la respuesta directamente de un servidor maestro, dará una respuesta autoritativa. Si la obtiene de cache dará una respuesta no autoritativa
-Ejemplo de resolución DNS:
-.- El resolver del equipo envía una consulta recursiva al servidor DNS. El servidor DNS recibe la pregunta. Como no es autorizado para la zona "asir.es" no tiene en sus archivos de zona el nombre de dominio por el que le han preguntado. No está configurado para reenviar consultas y además actúa como cache, es decir, tiene activada la recursividad, por lo que es capaz de tratar una consulta recursiva. Para resolver la pregunta inicia una serie de consultas iterativas.
-. La primera consulta iterativa se la envía a uno de los servidores raiz. El servidor sabe cuales son los servidores raíz por qué almacena el fichero hits file
-.- El servidor raíz que recibe la consulta iterativa responde con una referencia al servidor autorizado para el dominio "es". El servidor raíz ha delegado la autoridad del dominio "es" en otros servidores DNS. Realmente le envía la referencia de todos los que existan. En el fichero de la zona raiz se indica cual es el servidor autorizado del dominio "es", en el que se delega, con un RR de tipo NS
-. A continuación el servidor DNS envía una consulta iterativa al servidor autorizado del dominio "es".
-.  El servidor autorizado para el dominio "es" que recibe la consulta iterativa responde con una referencia al  servidor autorizado para el dominio "asir.es". El servidor autorizado para el dominio "es" ha delegado la autoridad del dominio "asir.es", en otros servidores DNS.
-Realmente le envía la referencia de todos los que existan En el fichero de la zona raiz se indica cual es el servidor autorizado del dominio "es", en el que se delega, con un RR de tipo NS
-.  Posteriormente, el servidor DNS envía una consulta iterativa al servidor autorizado del dominio "asir.es".
-.  El servidor autorizado para el dominio "asir.es", consulta sus ficheros de zona y como existe el nombre do dominio "www.asir.es", responde con la información asociada a él. Si no existiese el nombre en los archivos de zona respondería de forma negativa indicando que no sabe resolver el nombre.
-.  El servidor que recibió la consulta recursiva responde al resolver con la información por la que se le preguntó.
-Ten en cuenta que si a continuación un cliente DNS pregunta al servidor DNS de la figura por el nombre de dominio "ftp.colegiomontessori.es", este no preguntará de nuevo a un servidor raíz ya que tiene almacenadas en cache las direcciones de los servidores DNS autorizados para el dominio "es". Como puedes observar el uso de la cache es muy importante en el rendimiento de DNS.
-Las consultas recursivas son iniciadas por un cliente DNS (resolver) o por un servidor DNS que reenvía la consulta recursiva a otro servidor (reenviador).
-Actividad  Accede al equipo debianXX de la red virtual y abre un terminal. Ejecuta el comando dig @8.8.8.8 www.colegiomontessori.com +trace. Con este comando se le enviará una consulta recursiva el servidor DNS 8.8.8.8 preguntando por el nombre www.colegiomontessori.com, y se le indica con la opción +trace que muestre el rastro de todo el proceso de resolución. Observa que se pregunta en primer lugar a un servidor raíz, posteriormente a un servidor autorizado para el dominio ".com" y por último al servidor autorizado para colegiomontessori.com
-En el ejemplo anterior, el servidor que recibe la consulta recursiva está configurado como reenviador y por eso le reenvía la consulta a otro servidor DNS.
-Las consultas recursivas son costosas para los servidores DNS, y por eso es habitual que un servidor DNS es autorizado para una zona no responda a consultas recursivas. Los servidores DNS raíz y los servidores DNS autorizados para los dominios TLD no responden a consultas recursivas.
-.2.     Consultas iterativas
-Una consulta iterativa (o no recursiva) es aquella en la que el servidor DNS puede proporcionar una respuesta parcial. Hay cuatro posibles respuestas:
-■   Respuesta positiva, es decir, da la información del nombre por el que se ha preguntado. En ella se indica si es autorizada o no.
-■   Respuesta negativa, indica que el nombre no se pudo resolver (NXDOMAIN).
-■   Respuesta indicando una referencia a otros servidores, autorizados o no, a los que se puede preguntar para resolver la pregunta (una referencia no se es válida como respuesta a una consulta recursiva).
-■   Una indicación de error.
-Cuando un servidor recibe una consulta recursiva:
-.  Si es autorizado para alguna zona (maestro o esclavo) comprueba sus archivos de zona. Si encuentra la respuesta responde indicando que la respuesta es autoritativa.
-.  Si no encuentra la respuesta o no es autorizado y actúa como cache, consulta su cache de respuestas anteriores. Si encuentra la respuesta responde indicando que la respuesta no es autoritativa.
-.  Si no se encuentra respuesta exacta con el nombre, devuelve una referencia que apunta a un servidor DNS que está autorizado para un nivel inferior del espacio de nombres de dominio.
-Como va se ha explicado, esta información es usada por el servidor que realizó la consulta iterativa para continuar su proceso de resolución (proceso recursivo).
-Las consultas iterativas son realizadas por servidores a otros servidores DNS después de haber recibido una consulta recursiva (y no encontrar respuesta en sus archivos de zona o caché)
-.3.     Cache y TTL
-Los clientes y los servidores DNS mantienen en memoria cache,  si están configurados para ello, las respuestas y las preguntas que realizan a otros servidores. El tiempo guardan las respuestas en cache se denomina TTL (time to live) y se define en los archivos de zona de los servidores DNS preguntados
-Los clientes y servidores DNS almacenan en cache:
-■   Respuestas positivas. Registros de recursos de nombres resueltos.
-■   Respuestas negativas. Información de que no existen registros de recursos para un nombre consultado. Impiden la repetición de solicitudes adicionales para nombres que no existen.
-En los ficheros de zona se define el tiempo que se guardarán en cache las respuestas positivas y el tiempo que se guardan en cache las respuestas negativas. Por lo tanto, se diferencia entre TTL de respuestas positivas y TTL de respuestas negativas.
-La RFC 1912 recomienda que el valor TTL positivo sea de 1 día o mayor, y para los registros de recursos que cambien poco se usen valores de 2 o 3 semanas. La RFC 2308 indica que el máximo valor del TTL negativo sea de 3 horas.
-El administrador de un servidor DNS debe hacer un balance teniendo en cuenta la frecuencia con la que cambian los registros de recursos, la carga de los servidores DNS y el tráfico de red. Los valores TTL pequeños ayudan a asegurar que la información acerca del dominio es más coherente en la red, en caso de que estos datos cambien a menudo, pero incrementan la carga en los servidor e incrementan el tráfico en la red.
-.4.    Recursividad y cache
-Para que un servidor DNS pregunte a otros servidores  cuando recibe consultas recursivas tiene que tener activada la recursividad. La recursividad está asociada con el comportamiento del servidor como cache. Para que un servidor pregunte a otros y almacene las respuestas en su cache tiene que resolver consultas recursivas.
-. Resolución inversa
-Ahora que ya se ha explicado el funcionamiento del servicio DNS basándose en la resolución directa, vamos a tratar la resolución inversa. Recuerda que una consulta inversa a un servidor DNS consiste en preguntar por una dirección IP en lugar de preguntar por un nombre de dominio, ejemplo ¿cuál o cuales son los nombres de dominio asociados a la dirección ip 200.100.89.10?
-Actividad Accede a alguna de las máquinas de la red virtual (debianXX. w7XX,...) y abre un terminal. Ejecuta el comando nslookup 8.8.4.4 Y observa los resultados. El comando nslookup realiza una pregunta al servidor DNS que esté configurado en las propiedades TCP/IP del equipo y muestra por pantalla información sobre la respuesta obtenida. En dicha respuesta se puede observar cual es el servidor DNS que responde y qué nombres de dominio se asocian con la dirección IP.
-Existen muchos motivos para preguntar por los nombres de dominio asociados a una IP, por ejemplo, resolver problemas de red, detectar spam en los servidores de correo, seguir la traza de un ataque, conocer qué nombres aloja un servidor de hosting, etc.
- Actividad  Inicia una sesión en el equipo w7XX de la red virtual y abre un terminal. Ejecuta el comando tracert - d www.google.es. Observa que se muestran las direcciones IP de los routers, por los que pasan los datagramas IPs hasta llegar al equipo www.google.es. Ejecuta el comando tracert www.google.es (sin la opción -d). En este caso, en lugar de mostrarse las direcciones IP de los routers se muestra su nombre de dominio porque el programa tracert hace preguntas DNS inversas para obtener los nombres de dominio que se corresponden con las IPs de los routers.
-.1.     Mapeo de direcciones IP y dominio arpa
-La resolución de direcciones IP funciona igual que la resolución de nombres de dominio. Las direcciones IP se tratan como nombres donde cada byte es un dominio que cuelga de los dominios "in-addr.arpa" para direcciones IPv4, e "ip6. arpa" para las direcciones IPv6. Vamos a explicar esto con un ejemplo.
-■   Cuando usamos un nombre de dominio, por ejemplo "www.asir.es.'' lo leemos y lo escribimos de izquierda a derecha, pero su estructura jerárquica es de derecha a izquierda, el dominio más alto de la jerarquía es el raíz ".", después "es.", después "asir" y por ultimo "www".
-■   Cuando usamos una dirección IP para realizar una pregunta DNS inversa, por ejemplo 192. 168.200.100, realmente estamos preguntando por el nombre de dominio "100.200.168.192.in-addr.arpa". La estructura jerárquica de la dirección IP tratada como nombre de dominio es de izquierda a derecha y comenzado por el dominio "in-addr.arpa".
-.2.     Zonas de resolución inversa
-Los servidores de nombres tienen que almacenar zonas de resolución inversa con registros de recursos que asocien nombres de dominio con direcciones IP. Pueden existir zonas de resolución inversa maestras o primarias, y zonas de resolución inversa esclavas o secundarias.
-Las zonas directas e inversas son independientes, y es responsabilidad de los administradores que contengan información coherente v que no existan discrepancias. Además, no es obligatorio que un organismo o empresa que administra la zona directa de un dominio tenga que administrar la o las zonas inversas que se corresponden con las direcciones IPs asociadas a los nombres del dominio. Por ejemplo, si administramos un dominio y asociamos un nombre con una IP pública contratada a un ISR tendremos que ponernos en contacto con él para que modifique su zona inversa e incluya nuestro nombre de dominio, si queremos que las consultas inversas a esa IP se resuelvan con "el nombre correcto que nosotros queremos.
-vamos a analizar los siguientes ejemplos:
--   Si un cliente DNS pregunta por el nombre de dominio "obelix.asir.es" el servidor DNS consultará el fichero de resolución directa y devolverá la ip 193.100.200.101.
--  Si un cliente DNS pregunta la dirección IP 193.100.200.101 el servidor DNS consultará el fichero de resolución inversa y devolverá el nombre "obelix.asir.es".
--   Si un cliente DNS pregunta por el nombre de dominio "panoramix.asir.es" el servidor DNS consultará el fichero de resolución directa y devolverá la ip 193.100.200.103.
--  Si un cliente DNS pregunta la dirección IP 193.100.200.103 el servidor DNS consultará el fichero de resolución inversa y devolverá que no ha encontrado nada. En este caso, la zona de resolución directa o inversa no son coherentes
--  Si un cliente DNS pregunta la dirección IP 193.100.200.123 el servidor DNS consultará el fichero de resolución inversa y devolverá "panoramix.asir.es". En este caso, la zona de resolución directa o inversa no son coherentes
-.10.3.    Proceso de resolución
-Las direcciones IP se tratan como nombres de dominio, por lo tanto, el proceso de resolución inversa es similar al de resolución directa. Existen consultas recursivas, iterativas, cache, TTL, etc.
-Fichero de la zona de resolución directa asir.es. que permite resolver las consultas directas de los nombres del dominio asir.es.
-...
-asir.es.	IN	NS	ns1.asir.es.
-ns1.asir.es.	IN	A	193.100.200.100
-obelix.asir.es.	IN	A	193.100.200.101
-axterix.asir.es	IN	A	193.100.200.102
-panoramix.asir.es.	IN	A	193.100.200.103
-...
-Fichero de la zona de resolución inversa 200.100.193.in-addr.arpa., que permite resolver las consultas inversas sobre direcciones IP de la red 193.100.200.0/24
-...
-.100.193.in-addr.arpa.	IN	NS	ns1.asir.es.
-.200.100.193.in-addr.arpa.	IN	PTR	ns1.asir.es.
-.200.100.193.in-addr.arpa.	IN	PTR	obelix.asir.es.
-.200.100.193.in-addr.arpa.	IN	PTR	asterix.asir.es.
-.200.100.193.in-addr .arpa.	IN	PTR		panoramix.asir.es.
-...
-Por ejemplo, si un cliente DNS realiza una consulta recursiva de la IP 192.168.200.100 a un servidor DNS, éste, si no lo tiene en cache, iniciaría una serie de consultas iterativas a los servidores DNS raíz, a los servidores autorizados para el dominio "192.in-addr.arpa*: y así sucesivamente.
-.4.    Delegación y resolución inversa
-La delegación de zonas de resolución inversa cuando las mascaras de red son múltiplos de 8 (/8, /16, /24) es similar a la delegación en la resolución directa, pero cuando las máscaras son diferentes, por ejemplo /27, hay que usar registros de tipo CNAME en las zonas de resolución inversa. Este tema no lo vamos a tratar, pero se recomienda buscar información adicional una vez que hayas hecho varias prácticas y tengas claro cómo funciona la delegación.
-.    Registros de recursos DNS
-Ya sabemos que el servicio DNS gestiona una base de datos distribuida entre múltiples servidores DNS que almacenan ficheros de zona con información sobrenombres de dominio Cada fichero de zona organiza esta información en registros de recurso (RR, Resource Records) los cuales se envían en las preguntas y respuestas entre clientes y servidores DNS
-.1.     Formato general
-Los RR tienen dos representaciones. La representación textual utilizada en los archivos de zona y la representación en binario, que es la que se emplea en los mensajes del protocolo DNS (definida en la RFC 1035). A continuación se explica la representación textual.
-Formato: NombreDeDominio   [TTL]   Clase   Tipo   Tipo-Dato
-Ejemplo: obelix.asir.es.           7200    	  IN         A         193.100.200.101
-■   Nombre de dominio
-•  Nombre de dominio con el que se asocia el recurso
-•  Ejemplos: obelix.asir.es, 101.200.100.193.in-addr.arpa
-■   TTL (Time To Livé)
-•  Número de segundos que puede estar el registro en caché antes de ser descartado.
-•  Es opcional a nivel de recurso.
-•  Se puede definir un tiempo global que se aplica a todos los registros de una zona.
-•  Un TTL de 0 indica que el registro no tiene que ser almacenado en caché.
-Clase
-•  Define la arquitectura de protocolos usada.
-•  IN para la TCP/IP.
-Tipo
-•  Tipo de registro.
-•  Son diferentes en función del campo clase.
-•  Para el campo IN existen muchos tipos ( A, CNAME, NS, MX    )
-Tipo-Dato
-•  Información asociada al nombre de dominio.
-•  Varía en función del tipo de registro.
-•  Ejemplo: dirección IP para el tipo A.
-.2.     Tipos de registros
- A continuación de explican los mas utilizados. Puedes consultar todos los existentes en http://www.iana.org/assignments/dns-parameters.
-.2.1.     Registro SOA
-El registro SOA (Start Of Authority) es el primer registro de una zona y define una serie de opciones generales
-Los datos asociados con un registro SOA son los siguientes (consulta el apartado relativo a transferencias de zona para relacionarlo con los valores que se definen en este registro):
-■   MNAME
-•   Nombre FQDN del servidor de nombres maestro del dominio.
-•   Ejemplo: ns1.asir.es.
-■   Contacto (contact)
-•  Correo de la persona responsable del dominio.
-•  Es parecido a una dirección de correo electrónico normal, a excepción que la arroba se remplaza con un punto.
-•  Ejemplo: admi.asir.es
-■   Número de serie (serial)
-•  Indica la versión del archivo de zona, y debe ser incrementado cada vez que el archivo se modifique.
-•  Los servidores secundarios consultan el registro SOA para realizar transferencias de zona. Si ha cambiado, entonces se realiza la transferencia de zona.
-•   Una práctica muy común es utilizar la fecha en el formato aaaammdd y agregarle dos dígitos más para los cambios que se hacen al archivo en el mismo día.
-•  Ejemplo: 2001032201.
-■  Actualización (refresh)
-•  Tiempo que esperan los servidores esclavos para preguntar al servidor maestro si hay cambios en la zona.
-•  La RFC 1912 recomienda valores entre 1200 y 43200 segundos (12 horas) dependiendo de la frecuencia de cambios en los archivos de zona.
-•  Si se usan notificaciones (NOTIFY) se puede usar un valor muy alto (1 o más días).
-■   Reintentos (retry)
-•  Si la transferencia de zona ha fallado, indica el tiempo que espera el servidor secundario antes de volver a intentarlo,
-•  Valores inferiores al tiempo de actualización.
-■  Caducidad (expire)
-•  Determina el tiempo que el servidor esclavo puede estar intentando contactar con el maestro para ver si hay cambios de zona.
-•  Si el tiempo expira, el servidor esclavo considera que algo ha pasado y se declara como no autorizado para la zona, y por lo tanto, no responde a preguntas sobre esa zona.
-•  La RFC 1912 recomienda valores entre 2 y 4 semanas.
-TTL negativo (Time To Live)
-•  Tiempo mínimo que se almacenan las respuestas negativas sobre esa zona.
-•  Diferente al TTL de los RR
-asir.es.   IN   SOA  ns1.asir.es. admin.asir.es.(
-		; Número de serie
-	; Tiempo de refresco
-	; Tiempo de reintento
-		       2419200   ; Tiempo de expiración
-)  ; TTL negativo
-Actividad 3.15: Inicia una sesión en el equipo debianXX de la red virtual y abre un terminal. Ejecuta el comando dig @8.8.8.8 google.es SOA para preguntarle al servidor DNS 8.8.8.8 cuál es el registro SOA del dominio "google.es" ¿Cuál es el tiempo de actualización de los servidores esclavos de la zona google.es?
-.2.2.    Registro NS
-El registro de recursos NS (Name Server) permite establecer:
-■ El/los servidores de nombres autorizados una zona
-asir.es.		IN  NS	ns1.asir.es.  ; Servidor DNS maestro
-asir.es.		IN  NS	ns2.asir.es.  ; Servidor DNS esclavo
-asir.es.		IN  NS	dns.asir.es.  ; Servidor DNS esclavo
-ns1.asir.es.	 IN   A	193.100.200.100
-ns2.asir.es.	 IN   A	193.100.200.200
-	• Cada zona debe de contener, como mínimo un registro NS
-	• Los servidores DNS, pueden tener un nombre de la misma zona o de otras
-■ Quiénes son los servidores de nombre con autoridad en los subdominios delegados
-	•  Cada zona debe contener al menos un registro NS por cada subdominio que haya delegado.
-asir.es.		IN  NS	ns1.asir.es.  ; Servidor DNS maestro
-asir.es.		IN  NS	ns2.asir.es.  ; Servidor DNS esclavo
-asir.es.		IN  NS	dns.asir.es.  ; Servidor DNS esclavo
-ns1.asir.es.	 IN   A	193.100.200.100
-ns2.asir.es.	 IN   A	193.100.200.200
-; Delegación
-redes.asir.es	IN	NS 	ns1.redes.asir.es.	; Delegación
-sistemas.asir.es	IN	NS		dns.asir.org.		; Delegación
-ns1.redes.asir.es.	IN 	A	193.100.40.100		; GLUE Record
-La parte de derecha de un registro NS no debe ser un nombre de tipo CNAME.
-Actividad 3.16: Inicia una sesión en el equipo debianXX de la red virtual y abre un terminal. Ejecuta el comando dig @8.8.8.8 google.es NS para preguntarle al servidor DXS 8.8.8.8 cuáles son los registros NS del dominio "google•es. Observa que hay servidores autorizados para el dominio google.es cuyo nombre DNS no está dentro del dominio.
-.2.3.     Registro A
-El registro de recursos A (Address) establece una correspondencia entre un nombre de dominio completamente cualificado (FQDN) y una dirección IP versión 4
-ns1.asir.es.	IN	A	193.100.200.100
-ns2.asir.es.	IN	A	193.100.200.200
-obelix.asir.es	IN	A	193.100.200.101
-marmita.asir.es	IN	A	193.100.200.101
-asterix.asir.es	IN	A	193.100.200.102
-Actividad 3.17: Inicia una sesión en el equipo debianXX de la red virtual y abre un terminal. Ejecuta el comando dig ©8.8.8.8 a.root-servers.net A para preguntarle al servidor DNS 8.8.8.8 cuáles son los registros A del nombre "a.root-servers.net".
-.2.4.     Registro AAAA
-El registro de recursos AAAA (Address Address Address Address) establece una correspondencia entre un nombre de dominio completamente cualificado (FQDN) y una dirección IP versión 6.
-ns1.asir.es.	IN	A	193.100.200.100
-ns2.asir.es.	IN	A	193.100.200.200
-obelix.asir.es	IN	A	193.100.200.101
-marmita.asir.es	IN	A	193.100.200.101
-asterix.asir.es	IN	A	193.100.200.102
-obelix.asir.es	IN	AAAA	2001:db8::63
-asterix.asir.es	IN	AAAA	2001:db3::64
-Actividad: Inicia una sesión en el equipo debianXX de la red virtual y abre un terminal. Ejecuta el comando dig @8.8.8.8 a.root-servers.net AAAA para preguntarle al servidor DXS 8.8.8.8 cuáles son los registros AAAA del nombre "a.root-servers.net'.
-.2.5.    Registro CNAME
-El registro de recursos CNAME (Canonical name) permite crear alias para nombres de dominio especificados en registros A y AAAA,
-obelix.asir.es.	IN	A	 	193.100.200.101
-www. asir.es.	IN	CNAME		obelix.asir.es.
-db.asir.es.	IN	CNAME		obelix.asir.es.
-Un registro CNAME puede apuntar a un nombre de otro dominio.
-www.asrr.es.         IN        CNAME   www.aula51.es.
-No se deben usar registros C'NAME en la parte derecha de los registros MX y NS. La parte derecha de estos recursos tiene que ser un nombre que aparezca un registro de tipo A
-;  mal
-asir.es.         	 IN		NS	 dns.asir.es.;   Mal,   dns  es   un  CNAME
-ns1.asir.es.	IN	A	193.100.200.100
-dns.asir.es.	IN	CNAME	ns1.asir.es.
-;  bien
-asir.es.         	 IN		NS	 ns1.asir.es.;   BIEN
-ns1.asir.es.	IN	A	193.100.200.100
-dns.asir.es.	IN	CNAME	ns1.asir.es.
-Hay que tener en cuenta que el uso de muchos CNAME perjudica el rendimiento de los servidores DNS. Cuando se pregunta por un registro CNAME hay que buscar dos veces en el fichero de zona para encontrarlo. En servidores con poco tráfico su impacto en el rendimiento es insignificante, pero en servidores con zonas muy grandes y mucho tráfico hay que tenerlo en cuenta. El administrador tendrá que hacer un balance de las ventajas o inconvenientes de su uso.
-.2.6.    Registro MX
-El registro de recursos MX (Mail Exchange) permite definir equipos encargados de la entrega de correo en el dominio. Son consultados por los agentes de transporte de correo SMTP (MTA, Mail Transport Agent)
-asir.es.        IN	MX	10	mail1.asir.es.
-asir.es.       IN	MX	20	mail2.asir.es.
-mail1.asir.es.	IN	A	153.100.200.221
-mail2.asir.es.	IN	A	133.100.200.222
-Un registro MX puede apuntar a un nombre de otro dominio.
-mail3.asir.es.  IN   MX   30   smtp.videosdeinformatica.com.
-Es posible definir varios registros MX para un mismo dominio, es decir varios servidores de correo para ese dominio. En cada registro MX se especifica un número positivo (entre 0 y 65535) que determina la preferencia en el caso de que existan varios registros MX. Un número más pequeño indica mayor preferencia. Fíjate en los ejemplos anteriores, el servidor de correo consultará los registros MX e intentará enviar el correo a mail1.asir.es, si no responde o esta ocupado, usará mail2.asir.es como segunda opción y si este tampoco está activo lo intentará con smtp.videosdeinformatica.es
-La parte derecha de un registro MX no debe ser un nombre de tipo CNAME.
-.2.7.     Registro SRV
-El rcgfetro de recurso* SRV (Service Record) permite definir equipos que soportan un servicio en particular
-_http._tcp.asir.es.	IN	SRV		0	5	80	www.asir.es.
-_ldap._tcp.asir.es.	IN	SRV		0	0	389	ldap.asir.es.
-Puedes consultar más información en RFC 2782
-.2.8.     Registro PTR
-El registro de recursos PTR (Pointer Record) establece una correspondencia entre nombres de direcciones IPv4 e IPv6 y nombres de dominio. Se utilizan por lo tanto en las zonas de resolución inversa.
-En una misma zona no puede haber registros PTR IPv4 y registros PTR IPv6. Existen por lo tanto zonas de resolución inversa IPv4 y zonas IPv6.
-.200.100.193.in-addr.arpa.		IN	PTR	ns1.asir.es.
-.200.100.193.in-addr.arpa.		IN 	PTR	ns2.asir.es
-.200.100.193.in-addr.arpa.		IN	PTR	obelix.asir.es
--3.    Delegación y registros pegamento (Glue Record)
-La organización que administra un servidor de nombres y por lo tanto, sus zonas, puede decidir si delega o no alguno de sus subdominios en otros servidores de nombres. Se puede diferenciar dos casos:
-■ Si el nombre del servidor DNS autorizado del subdominio (en el que se delega) se encuentra a su vez dentro del propio subdominio.
-asir.es.	IN	NS	ns1.asir.es.;	Servidor DNS maestro
-asir.es.	IN	NS	ns2.asir.es.;	Servidor DNS esclavo
-asir.es.	IN	NS	dns.asir.org.	; Servidor DNS esclavo
-ns1.asir.es. 	IN	   A 	 193.100.200.100
-ns2.asir.es.	IN	   A 	 193.100.200.200
-;Delegación
-redes.asir.es.     	IN 	NS	ns1.redes.asir.es.	; Delegación
-ns1.redes.asir.es.	IN 	 A    	193.100.40.100		; GLUE Record
-•   Hay que añadir un registro NS en la zona del padre que define el servidor de nombres autorizado para la zona delegada.
-•   Hay que añadir un registro de tipo A para indicar la dirección IP del servidor de nombres autorizado para la zona delegada.
-o	A este tipo de registros se les denomina "glue record" porque unen o pegan la zona hija con la zona padre (realmente no pertenecen a la zona padre).
-o	Observa que si no se define este registro, el cliente que realiza una pregunta iterativa (por ejemplo pc1.redes.asir.es) y obtiene una referencia al siguiente servidor DNS al que preguntar (ns1.redes.asir.es) no podría obtener la IP del nuevo servidor DNS hasta que no acceda a él (ns1 es un nombre del dominio redes.asir.es). Observa que no puede preguntarle si no sabe su IP (" ...la pescadilla que se muerde la cola ...").
-o	Si se omiten o se colocan registros de pegamento incorrectos, se dejará parte del espacio de nombres inaccesible.
-o	Por lo tanto, los servidores de un dominio padre deben conocer la dirección IP de los servidores de nombres de todos sus subdominios.
-Si el nombre del servidor DNS del subdominio (en el que se delega) no se encuentra en el subdominio, véase Figura 3.35.
-•  Hay que añadir un registro NS en la zona del padre que define el servidor de nombres autorizado para la zona delegada.
-•  No hace falta ni hay que añadir un registro de tipo A para indicar la dirección IP del servidor de nombres para la zona delegada.
-o	En este caso, el cliente que realiza una pregunta iterativa (por ejemplo pc1.sistemas.asir.es) y obtiene una referencia al siguiente servidor DNS al que preguntar (dns.asir.org) podrá resolver el nombre dns.asir.org normalmente.
-o	Es un error incluir registros de pegamento para nombres de host que no los necesitan. La regla general es que se deben incluir registros A únicamente para los hosts que están dentro del dominio o cualquiera de sus subdominios.
-asir.es.	IN	NS	ns1.asir.es.;	Servidor DNS maestro
-asir.es.	IN	NS	ns2.asir.es.;	Servidor DNS esclavo
-asir.es.	IN	NS	dns.asir.org.	; Servidor DNS esclavo
-ns1.asir.es. 	IN	   A 	 193.100.200.100
-ns2.asir.es.	IN	   A 	 193.100.200.200
-;Delegación
-sistemas.asir.es	IN	NS	dns.asir.org.;	Delegación
-.     Transferencias de zona
-Los servidores DNS que declaran zonas esclavas o secundarias obtienen los archivos de zona (los registros de recursos) de otros servidores DNS autorizados para esas zonas. A este proceso se le denomina transferencia de zona. Existen diferentes formas de llevarlo a cabo y es posible configurarlo en los servidores de nombres. El objetivo es que todos los servidores autorizados para una zona tengan la misma información.
-Los servidores maestros usan el puerto 53/TCP para el intercambio de datos en las transferencias de zona.
-.1.     Tipos de transferencias de zona
-Existen dos tipos de transferencias de zona entre servidores maestros y esclavos.
-.1.1.     Transferencias de zona completas (AXFR)
-En una transferencia de zona completa el servidor maestro le envía al servidor esclavo todos los datos de la zona. Una petición AXFR de un servidor esclavo a uno maestro es una solicitud para una transferencia de zona completa. Las especificaciones originales del servicio DNS (RFC 1034 y RFC 1035) solo contemplaban este tipo de transferencias
-.1.2.     Transferencias de zona incrementales (IXFR)
-Las transferencias completas de zonas con muchos registros de recursos consumen ancho de banda, y pueden llegar a tardar "mucho tiempo" dependiendo de las condiciones de la red y del tamaño de la zona. Para evitar estos inconvenientes, en la RFC 1995 se introdujeron las transferencias de zona increméntales.
-En una transferencia de zona incremental el servidor maestro le envía al servidor esclavo solo los datos que han cambiado desde la última transferencia de zona. Una petición IXFR de un servidor esclavo a uno maestro es una solicitud para una transferencia de zona incremental.
-.2.    Proceso de transferencia de zona
-El proceso de transferencia de zona se puede iniciar de dos maneras:
-■   El servidor esclavo pregunta al servidor maestro para comprobar si hay cambios en los archivos de zona. Lo hace cuando se inicia por primera vez y posteriormente, cada cierto tiempo de forma periódica.
-■   El servido maestro notifica (NOTIFY) al servidor o servidores esclavos que se han producido cambios en sus archivos de zona.
-.2.1.     El servidor esclavo pregunta
-Este mecanismo es el que se definió en las especificaciones DNS originales.
-.   El servidor esclavo, cuando se inicia por primera vez o cada cierto tiempo (especificado en el campo refresh del registro de recursos SOA que el servidor secundario consiguió del servidor maestro), solicita al servidor maestro su SOA.
-.   El servidor maestro responde con el registro de recursos SOA.
-.   El servidor esclavo compara el número de serie devuelto con su propio número de serie. Si el número de serie que el servidor maestro envía para la zona es superior al suyo propio, su base de datos de zonas no está actualizada.
-.  El servidor maestro envía una petición AXFR para solicitar una transferencia de zona completa o una petición IXFR para solicitar una transferencia de zona incremental.
-.  El servidor maestro envía los datos de la zona al servidor secundario.
-.2.2.    El servidor maestro notifica (NOTIFY)
-Cuando el método anterior si se produce una actualización en los archivos de zona del servidor maestro, el servidor esclavo "no se entera" y, por lo tanto, no actualizará sus archivos de zona hasta que pase su tiempo de refresco y vuelva a preguntar Por ejemplo, supongamos que el tiempo de refresco es de 6 horas, un servidor esclavo pregunta y no hay ningún cambio; a la hora el archivo de zona del maestro cambia ¿cuánto tiempo pasa hasta que el servidor esclavo vuelve a preguntar y por lo tanto a actualizar sus archivos de zona?, 5 horas. ¿Y si hay múltiples servidores esclavos?
-Por ello en la RFC 1996 se introdujo un nuevo mecanismo. El servidor maestro envía un mensaje de notificación (NOTIFY) a los servidores esclavos cuando se produce un cambio en sus archivos de zona.
-.  Cuando se actualiza un archivo de zona el servido maestro envía un mensaje de notificación a los servidores esclavos.
-.  El servidor esclavo solicita al servidor maestro su SOA.
-   El servidor maestro responde con el registro de recursos SOA.
-   El servidor esclavo compara el número de serie devuelto con su propio número de serie. Si el número de serie que el servidor maestro envía para la zona es superior al suyo propio, su base do datos de zonas no está actualizada.
-   El servidor maestro envía una consulta AXFR para solicitar una transferencia de zona completa o una consulta IXFR para solicitar una transferencia de zona incremental.
-. El servidor maestro envía los datos de la zona al servidor secundario.
-La notificación ayuda a mejorar la coherencia de los datos entre servidores DNS autorizados para una zona.
-. DNS Dinámico (DDNS, Dynamic DNS)
-Para que los usuarios tengan acceso a los recursos DNS correctamente, es fundamental que los senadores de nombres estén actualizados. La actualización de los registros de recursos de un archivo de zona se puede realizar manualmente o dinámicamente.
-.1. Actualizaciones manuales
-En las actualizaciones manuales el administrador crea, elimina o modifica registros de recursos editando los ficheros de zona. Cuando el volumen de actualizaciones de los archivos de zona es elevado y hay varias zonas (imagina una red en la que se asignan direcciones usando un servidor DHCP y se quieren registrar los nombres DNS de los clientes DHCP) el trabajo del administrador y las probabilidades de equivocarse y no mantener los archivos de zona actualizados crece considerablemente.
-.2. Actualizaciones dinámicas
-La RFC 2162 define el proceso mediante el cual una fuente externa puede actualizar los registros de recursos de una zona. Una actualización dinámica es por lo tanto, el proceso por el cual se crean o modifican registros de recursos por parte de una fuente externa (cliente DNS. servidor DHCP,...) sin que el administrador del servidor DNS edite los ficheros de zona.
-	Las actualizaciones dinámicas pueden ser realizadas:
-■  Directamente por los equipos
-o	Hay que configurar el cliente DNS de cada equipo.
-o	Hay que configurar el servidor DNS para que permita actualizaciones dinámicas por parte de los equipos.
-■  Por servidores DHCP
-o	Hay que configurar adecuadamente el servidor DHCP para que envíen su nombre al servidor DHCP o configurar el servidor DHCP para que les asigne un nombre
-o	Hay que configurar el servidor DNS para que permita actualizaciones dinámicas por parte del servidor DHCP.
-.3.    DNS dinámico en Internet
-Los proveedores de acceso a Internet (ISP, Internet Services Provider) asignan una dirección IP por DHCP al router que nos conecta a su red (a no ser que contratemos una dirección IP fija). La dirección IP puede cambiar cada cierto tiempo o cada vez que se apaga o enciende el router, por lo tanto, no tenemos control sobre ella. ¿Qué ocurre si queremos asignar un nombre de dominio asociado a la IP del router para ofrecer servicios, por ejemplo, un servidor web en nuestra red? ¿Qué IP le asociamos a nuestro nombre de dominio?, la que tengamos en el momento actual ¿Y si cambia?
-Existen webs que ofrecen servicios de DNS dinámico en Internet. Permiten registrar un nombre DNS y actualizar su dirección IP "en tiempo real".
-Lo habitual es configurar un programa en el router de conexión a Internet o en un equipo de la red para que actualice el servidor DNS cuando la IP asignada por DHCP cambie Los routers que se comercializan actualmente suelen integrar estos programas.
-Algunas webs que ofrecen servicios de DNS Dinámico en Internet son:
-■   DynDNS (http://www.dyndns.org).
-■  No-ip (http://www.no-ip.com/).
-■   EasyDNS (http://www.easydns.com/).
-■   ZoneEdit (http://www.zoneedit.com/).
-■   Cdmon (https://wvv.cdmon.com/).
-.    Protocolo DNS
-El protocolo DNS determina el conjunto de normas y reglas en base a las cuales "dialogan" los clientes y los servidores DNS. El formato de un mensaje DNS es el que se muestra a continuación. Como ya sabemos usa TCP como protocolo de transporte.
-HEADER
-QUESTION
-ANSWER
-AUTHORITY
-ADDITIONAL
-■ Header: específica cuales son las secciones presentes, el tipo de mensaje y otros campos.
-■ Question : campos que definen una consulta a un servidor de nombres.
-■ Answer: RRs que responden a la consulta.
-■ Authority: RRs que apuntan a los servidores de nombre autoritativos.
-■ Additional. RRs que contienen información adicional.
-.    Seguridad DNS
-El servicio DNS es un servicio vital para el funcionamiento de Internet y de cualquier red TCP/IP. Los usuarios y el resto de servicios de la red dependen de él se verían afectados sino funcionase correctamente. Por ello, está en el punto de mira de potenciales atacantes.
-Se diseñó como un sistema abierto y en sus especificaciones originales no se contemplaban astectos de seguridad. Además, su seguridad es difícil de gestionar y administrar al ser un servicio distribuido formado por varios componentes que se comunican entre sí.
-La seguridad de DNS es un tema muy amplio que no se abordamos en esta asignatura. El objetivo de este apartado es ofrecer una visión global de los peligros, los mecanismos de seguridad existentes, y concienciar sobre la importancia de la seguridad en los servidores y clientes DNS.
-.1.    Vulnerabilidades, amenazas y ataques
-Cuándo se pregunta a un servidor DNS ¿Podemos fiarnos de que es quien dice ser o ha sido suplantado? ¿Las respuestas son reales o están falsificadas? ¿Si un servidor secundario recibe una transferencia de zona, la ha obtenido del maestro o ha sido suplantado. ...
-Desde su puesta en marcha en Internet DNS ha sufrido muchos tipos de ataques y se han publicado múltiples vulnerabilidades. Además, la información que se puede obtener de los servidores DNS de una organización se puede utilizar como punto de partida para otros tipos de ataques.
-Actividad: Busca en Internet:
-■   Noticias sobre ataques a servidores DNS.
-■ Información sobre el ataque Pharming.
-■ Información sobre técnicas de Footprinting basadas en DNS.
-Teniendo en cuenta loe componente, del servicio DNS y el flujo de información entre ellos es posible definir diferentes puntos de amenazas
-.   Servidores DNS
-o	Ataques contra el propio servidor aprovechando vulnerabilidades (uso de exploits).
-o	Modificación de los archivos de zona por una mala configuración de seguridad en el sistema donde está  instalado el servidor
-o	Ataques de denegación de servicio (DoS).
-.   Consultas de clientes DNS a otros a servidores DNS
-o	Envenenamiento de la cache del cliente DNS suplantando al servidor DNS remoto y enviado registros de recursos incorrectos
-.   Consultas de servidores DNS a otros a servidores DNS
-o	Envenenamiento de la cache del senador suplantado al servidor DNS remoto y enviado registros de recursos incorrectos.
-.  Transferencias de zona
-o	Suplantación del servidor maestro que envía registros de recursos a los secundarios.
-.  Actualizaciones dinámicas a servidores DNS
-o	Suplantación de la fuente externa que envía las actualizaciones al servidor DNS.
-.2.    Mecanismos de seguridad
-Las vulnerabilidades y las amenazas a DNS están relativamente controladas. Además, se han creado mecanismos para poder configurar el servicio de forma segura.
-■  Seguridad local en los servidores DNS
-•  Actualizar a las últimas versiones y parches de seguridad.
-•  En sistemas Linux/Unix ejecutar el servidor en un entorno chroot.
-•  Configurar adecuadamente los privilegios de acceso a los ficheros de zonas.
-•  Realizar copias de segundad de los archivos de zona.
-• Evitar puntos de fallo y prevenir ataques de denegación de servicio (DoS) creando al menos un servidor secundario por cada zona, distribuyendo los servidores DNS en diferentes redes y ubicaciones, etc.
-■  Seguridad en las transferencias de zona y en las actualizaciones dinámicas
-o	Establecer a ni de direcciones IP y/o nombres de dominio (usando listas de control de acceso) los servidores desde los que se permiten transferencias de zona y/o actualizaciones dinámicas.
-o	Utilizar cortafuegos para controlar las solicitudes de transferencias de zona y/o actualizaciones dinámicas.
-o	Mecanismos TSIG v TKEY que proporcionan autenticación entre servidores.
-	TSIG: Usa algoritmos de clave secreta para autenticar a los servidores entre sí. Los dos servidores usan una clave secreta compartida. No contempla la distribución de la clave secreta. Hay que distribuirla por otros medios (ssh, correo cifrado)
-	TKEY: Similar a TSIG pero los servidores generan la clave secreta de manera automática y la intercambian básicamente el algorito Diffie-Hellman.
-o	Mecanismos de autenticación de Active Directory en dominios Microsoft para garantizar transferencias de zona y actualizaciones dinámicas seguras.
-■ Seguridad en las consultas DNS de clientes o servidores a otros servidores
-o	El problema de envenenamiento de cache es difícil de solucionar porque pueden existir muchos servidores involucrados en la resolución.
-o	Algunos mecanismos para mejorar la seguridad son:
-	Configurar los senadores DNS para que resuelvan consultas recursivas solo si es necesario. Si un servidor resuelve consultas recursivas preguntará iterativamente a otros servidores que pueden enviar información falsa si han sido comprometidos o suplantados.
-	Restringir a nivel de direcciones IP quienes son los clientes que puede preguntar a un servidor. Por ejemplo, que solo puedan hacer preguntas recursivas los equipos de la red de la organización a la que pertenece el servidor y que el resto puedan hacer preguntas iterativas sobre las zonas para las que es autorizado.
-o	En los últimos años se están definiendo e implantando un conjunto especificaciones, orientadas a resolver el problema, conocidas como DNSSEC (Domain Name System Security Extensions). Se basan en el uso de algoritmos criptográficos de clave asimétrica (o pública) y firma, digitales para garantizar la autenticidad y la integridad en las consultas y respuestas DNS.
-.     Whois
-Whois es un protocolo que permite realizar consultas a bases de datos que contienen información sobre el usuario, empresa u organización que registra un nombre de dominio y/o una dirección IP en Internet.
-El protocolo whois se encapsula en TCP y solo especifica el intercambio de peticiones y respuestas, no en el formato de datos a intercambiar. Por eso, los resultados de las consultas whois pueden ser diferentes dependiendo de la base de datos whois a la que se pregunte.
-Usando webs especializadas (http://www.whois.net/, http://whois.domaintools.com/, http://www. internic.net/whois.html,...).
-Usando clientes instalados en un equipo.
-Actividad:
-■  Accede a la web http://whois.domaintools.com y consulta información sobre el nombre
-"google.com".
-■  Inicia sesión en ubuntuXX abre un terminal y ejecuta whois google.com.
-. Inicia sesión en ubuntuXX y accede a Sistema, Administración, Herramientas de red y a la pestaña Whois. Busca información sobre el nombre de dominio que quieras.
+{{:sri:t2:diapositivas:diapositiva1.png?600|}}
+{{:sri:t2:diapositivas:diapositiva2.png?600|}}
+{{:sri:t2:diapositivas:diapositiva3.png?600|}}
+{{:sri:t2:diapositivas:diapositiva4.png?600|}}
+{{:sri:t2:diapositivas:diapositiva5.png?600|}}
+{{:sri:t2:diapositivas:diapositiva6.png?600|}}
+{{:sri:t2:diapositivas:diapositiva7.png?600|}}
+{{:sri:t2:diapositivas:diapositiva8.png?600|}}
+{{:sri:t2:diapositivas:diapositiva9.png?600|}}
+{{:sri:t2:diapositivas:diapositiva10.png?600|}}
+{{:sri:t2:diapositivas:diapositiva11.png?600|}}
+{{:sri:t2:diapositivas:diapositiva12.png?600|}}
+{{:sri:t2:diapositivas:diapositiva13.png?600|}}
+{{:sri:t2:diapositivas:diapositiva14.png?600|}}
+{{:sri:t2:diapositivas:diapositiva15.png?600|}}
+{{:sri:t2:diapositivas:diapositiva16.png?600|}}
+{{:sri:t2:diapositivas:diapositiva17.png?600|}}
+{{:sri:t2:diapositivas:diapositiva18.png?600|}}
+{{:sri:t2:diapositivas:diapositiva19.png?600|}}
+{{:sri:t2:diapositivas:diapositiva20.png?600|}}
+{{:sri:t2:diapositivas:diapositiva21.png?600|}}
+{{:sri:t2:diapositivas:diapositiva22.png?600|}}
+{{:sri:t2:diapositivas:diapositiva23.png?600|}}
+{{:sri:t2:diapositivas:diapositiva24.png?600|}}
+{{:sri:t2:diapositivas:diapositiva25.png?600|}}
+{{:sri:t2:diapositivas:diapositiva26.png?600|}}
+{{:sri:t2:diapositivas:diapositiva27.png?600|}}
+{{:sri:t2:diapositivas:diapositiva28.png?600|}}
+{{:sri:t2:diapositivas:diapositiva29.png?600|}}
+{{:sri:t2:diapositivas:diapositiva30.png?600|}}
+{{:sri:t2:diapositivas:diapositiva31.png?600|}}
+{{:sri:t2:diapositivas:diapositiva32.png?600|}}
+{{:sri:t2:diapositivas:diapositiva33.png?600|}}
+{{:sri:t2:diapositivas:diapositiva34.png?600|}}
+{{:sri:t2:diapositivas:diapositiva35.png?600|}}
+{{:sri:t2:diapositivas:diapositiva36.png?600|}}
+{{:sri:t2:diapositivas:diapositiva37.png?600|}}
+{{:sri:t2:diapositivas:diapositiva38.png?600|}}
+{{:sri:t2:diapositivas:diapositiva39.png?600|}}
+{{:sri:t2:diapositivas:diapositiva40.png?600|}}
+{{:sri:t2:diapositivas:diapositiva41.png?600|}}
+{{:sri:t2:diapositivas:diapositiva42.png?600|}}
+{{:sri:t2:diapositivas:diapositiva43.png?600|}}
+{{:sri:t2:diapositivas:diapositiva44.png?600|}}
+{{:sri:t2:diapositivas:diapositiva45.png?600|}}
+{{:sri:t2:diapositivas:diapositiva46.png?600|}}
+{{:sri:t2:diapositivas:diapositiva47.png?600|}}
+{{:sri:t2:diapositivas:diapositiva48.png?600|}}
+{{:sri:t2:diapositivas:diapositiva49.png?600|}}
+{{:sri:t2:diapositivas:diapositiva50.png?600|}}
+{{:sri:t2:diapositivas:diapositiva51.png?600|}}
+{{:sri:t2:diapositivas:diapositiva52.png?600|}}
+{{:sri:t2:diapositivas:diapositiva53.png?600|}}
+{{:sri:t2:diapositivas:diapositiva54.png?600|}}
+{{:sri:t2:diapositivas:diapositiva55.png?600|}}
+{{:sri:t2:diapositivas:diapositiva56.png?600|}}
+{{:sri:t2:diapositivas:diapositiva57.png?600|}}
+{{:sri:t2:diapositivas:diapositiva58.png?600|}}
+{{:sri:t2:diapositivas:diapositiva59.png?600|}}
+{{:sri:t2:diapositivas:diapositiva60.png?600|}}
+{{:sri:t2:diapositivas:diapositiva61.png?600|}}
+{{:sri:t2:diapositivas:diapositiva62.png?600|}}
+{{:sri:t2:diapositivas:diapositiva63.png?600|}}
+{{:sri:t2:diapositivas:diapositiva64.png?600|}}
+{{:sri:t2:diapositivas:diapositiva65.png?600|}}
+{{:sri:t2:diapositivas:diapositiva66.png?600|}}
+{{:sri:t2:diapositivas:diapositiva67.png?600|}}
+{{:sri:t2:diapositivas:diapositiva68.png?600|}}
+{{:sri:t2:diapositivas:diapositiva69.png?600|}}
+{{:sri:t2:diapositivas:diapositiva70.png?600|}}
+{{:sri:t2:diapositivas:diapositiva71.png?600|}}
+{{:sri:t2:diapositivas:diapositiva72.png?600|}}
+{{:sri:t2:diapositivas:diapositiva73.png?600|}}
+{{:sri:t2:diapositivas:diapositiva74.png?600|}}
+{{:sri:t2:diapositivas:diapositiva75.png?600|}}
+{{:sri:t2:diapositivas:diapositiva76.png?600|}}
+{{:sri:t2:diapositivas:diapositiva77.png?600|}}
+{{:sri:t2:diapositivas:diapositiva78.png?600|}}
+{{:sri:t2:diapositivas:diapositiva79.png?600|}}
+{{:sri:t2:diapositivas:diapositiva80.png?600|}}
+{{:sri:t2:diapositivas:diapositiva81.png?600|}}
+{{:sri:t2:diapositivas:diapositiva82.png?600|}}
+{{:sri:t2:diapositivas:diapositiva83.png?600|}}
+{{:sri:t2:diapositivas:diapositiva84.png?600|}}
+{{:sri:t2:diapositivas:diapositiva85.png?600|}}
+{{:sri:t2:diapositivas:diapositiva86.png?600|}}
+{{:sri:t2:diapositivas:diapositiva87.png?600|}}
+{{:sri:t2:diapositivas:diapositiva88.png?600|}}
+{{:sri:t2:diapositivas:diapositiva89.png?600|}}
+{{:sri:t2:diapositivas:diapositiva90.png?600|}}
+{{:sri:t2:diapositivas:diapositiva91.png?600|}}
+{{:sri:t2:diapositivas:diapositiva92.png?600|}}
+{{:sri:t2:diapositivas:diapositiva93.png?600|}}