Servidores dns
Descargar como DOCX, PDF0 recomendaciones275 vistas
Este documento describe los conceptos básicos de los servidores DNS y las zonas. Explica que los servidores DNS mapean nombres de dominio a direcciones IP, permitiendo que los usuarios accedan a recursos de red mediante nombres en lugar de direcciones numéricas. También describe los tipos de zonas como las zonas de búsqueda directa e inversa, y cómo estas zonas almacenan y organizan la información de nombres de dominio. Finalmente, explica cómo las consultas inversas permiten buscar un nombre de dominio a partir de una dirección
Servidores dns
- 1. SUBSECRETARIA DE EDUCACION SUPERIOR DIRECCION GENERAL DE EDUCACION SUPERIOR TECNOLOGICA INSTITUTO TECNOLOGICO DE TAPACHULA ADMINISTRACION DE REDES SHEYLA BERENICE MARTÍNEZ RAMOS MAURICIO DE JESUS HIDALGO MARTINEZ LUIS ALBERTO BARRIOS MARIN ANTONIO CABRERA OVILLA CONCEPTOS DE LA PRÁCTICA TAPACHULA, CHIAPAS DE CORDOVA Y ORDOÑES., A 4 DE JUNIO DE 2015
- 2. SERVIDORES DNS El sistema de nombres de dominio (DNS) es un sistema para asignar nombres a equipos y servicios de red que se organiza en una jerarquía de dominios. Las redes TCP/IP, como Internet, usan DNS para buscar equipos y servicios mediante nombres descriptivos. Para que el uso de los recursos de red sea más fácil, los sistemas de nombres como DNS proporcionan un método para asignar el nombre descriptivo de un equipo o servicio a otros datos asociados a dicho nombre, como una dirección IP. Un nombre descriptivo es más fácil de aprender y recordar que las direcciones numéricas que los equipos usan para comunicarse a través de una red. La mayoría de la gente prefiere usar un nombre descriptivo (por ejemplo, sales.fabrikam.com) para buscar un servidor de correo electrónico o servidor web en una red en lugar de una dirección IP, como 157.60.0.1. Cuando un usuario escribe un nombre DNS descriptivo en una aplicación, los servicios DNS convierten el nombre en su dirección numérica. ¿Qué hace un servidor DNS? Un servidor DNS proporciona resolución de nombres para redes basadas en TCP/IP. Es decir, hace posible que los usuarios de equipos cliente utilicen nombres en lugar de direcciones IP numéricas para identificar hosts remotos. Un equipo cliente envía el nombre de un host remoto a un servidor DNS, que responde con la dirección IP correspondiente. El equipo cliente puede entonces enviar mensajes directamente a la dirección IP del host remoto. Si el servidor DNS no tiene ninguna entrada en su base de datos para el host remoto, puede responder al cliente con la dirección de un servidor DNS que pueda tener información acerca de ese host remoto, o bien puede consultar al otro servidor DNS. Este proceso puede tener lugar de forma recursiva hasta que el equipo cliente reciba las direcciones IP o hasta que se establezca que el nombre consultado no pertenece a ningún host del espacio de nombres DNS especificado.
- 3. ¿A QUIÉN PUEDE INTERESARLE ESTA FUNCIÓN DE SERVIDOR? A excepción de las redes TCP/IP más sencillas, todas las redes necesitan acceso a uno o más servidores DNS para funcionar adecuadamente. Sin la resolución de nombres y los demás servicios proporcionados por los servidores DNS, el acceso de los clientes a equipos host remotos sería excesivamente difícil. Por ejemplo, sin acceso a un servidor DNS, navegar por la World Wide Web sería virtualmente imposible: la gran mayoría de los vínculos de hipertexto que se publican en la Web usan el nombre DNS de hosts web en lugar de sus direcciones IP. Los mismos principios se aplican a las intranets, ya que los usuarios de equipo rara vez conocen las direcciones IP de los equipos de su red de área local (LAN). Considere la posibilidad de implementar el servicio Servidor DNS de Windows Server 2008 si su red contiene lo siguiente: Equipos unidos a dominios Equipos cliente DHCP basados en Windows Equipos conectados a Internet Sucursales o dominios ubicados en una red de área extensa (WAN) ADMINISTRACIÓN DE UNA BÚSQUEDA DE CONSULTA DIRECTA Cuando el espacio de nombres del Sistema de nombres de dominio (DNS) se divide en dominios, también se divide el espacio de nombres DNS en una o varias zonas, cada una de las cuales almacena información de nombre sobre uno o más dominios DNS. Una zona es el origen de autoridad de la información sobre cada uno de los nombres de dominio DNS incluidos en la zona. Una zona de búsqueda directa es el tipo de zona más frecuente. Los clientes DNS pueden usar esta zona para obtener información, como las direcciones IP correspondientes a los servicios o nombres de dominio DNS, que está almacenada en la zona. Otro tipo de zona, la zona de búsqueda inversa, restablece la asignación de direcciones IP a los nombres de dominio DNS. Para obtener más información sobre las zonas de búsqueda inversa, consulte Proporcionar búsqueda inversa. Una zona comienza con un solo nombre de dominio DNS. Si se agregan otros dominios debajo del dominio inicial, estos dominios pueden formar parte de la misma zona o pertenecer a otra zona. Es decir, cuando agrega un subdominio, puede incluirlo como parte de la zona original o puede delegarlo a otra zona que cree para que sea compatible con el subdominio. Una zona de rutas internas es un tipo especial de zona de búsqueda directa que contiene información solo sobre los servidores de nombres autoritativos para la zona. La zona de este servidor se debe obtener de otro equipo servidor DNS que hospede la zona. Este servidor DNS debe tener acceso de red al servidor DNS remoto para copiar la información del servidor de nombres autoritativo sobre la zona. Las zonas de rutas internas son útiles para mantener actualizada la información de la zona delegada, mejorar la resolución de nombres al evitar las consultas a los servidores raíz y simplificar la administración de DNS al reducir la necesidad de zonas secundarias.
- 4. Debido a la importante función que tienen las zonas en DNS, deben estar disponibles desde más de un servidor DNS de la red para que puedan ofrecer disponibilidad y tolerancia a errores. De lo contrario, si solo hay disponible un servidor y no responde, las consultas de nombres en la zona pueden generar errores. Para que otros servidores puedan hospedar una zona, se requieren transferencias de zona para la replicación y sincronización de todas las copias de la zona que se usan en cada servidor que está configurado para hospedar la zona. CONSULTAS INVERSAS El uso de consultas inversas es una práctica obsoleta, propuesta originariamente como parte del estándar DNS para buscar un nombre de host basándose en su dirección IP. Se usa la operación de consulta DNS no estándar y su uso está limitado a algunas de las primeras versiones de Nslookup, una utilidad de línea de comandos para solucionar problemas y comprobar el servicio Servidor DNS. El servicio Servidor DNS reconoce y acepta los mensajes de consultas inversas, y los responde con una respuesta de consulta inversa falsa. En la mayoría de búsquedas del Sistema de nombres de dominio (DNS), los clientes suelen realizar una búsqueda directa, que es una búsqueda basada en el nombre DNS de otro equipo al estar almacenado en un registro de recursos de host (A). Este tipo de consulta espera una dirección IP como los datos de recursos para la respuesta ofrecida. DNS también proporciona un proceso de búsqueda inversa, en el que los clientes usan una dirección IP conocida y buscan un nombre de equipo basado en su dirección. La búsqueda inversa adopta la forma de una pregunta, como "¿Puede indicar el nombre DNS del equipo que usa la dirección IP 192.168.1.20?" DNS no se diseñó en un principio para admitir este tipo de consultas. Un problema para admitir el proceso de consultas inversas es la diferencia con la que el espacio de nombres DNS organiza e indiza los nombres y la forma de asignar las direcciones IP. Si el único método para responder la consulta anterior es buscar en todos los dominios del espacio de nombres DNS, una consulta inversa tardaría demasiado y requeriría demasiados procesos para resultar útil. Para resolver este problema, se ha definido un dominio especial en los estándares DNS, el dominio in-addr.arpa, y se ha reservado en el espacio de nombres DNS de Internet para proporcionar una forma práctica y confiable de llevar a cabo consultas inversas. Para crear el espacio de nombres inverso, se forman subdominios dentro del dominio in-addr.arpa, con la clasificación inversa de los números en la notación decimal con punto de direcciones IP. Esta clasificación inversa de los dominios para cada valor de octeto es necesaria ya que, a diferencia de los nombres DNS, cuando las direcciones IP se leen de izquierda a derecha, se interpretan de forma opuesta. Cuando se lee una dirección IP de izquierda a derecha, se visualiza desde su información más generalizada (una dirección de red IP) en la primera parte de la dirección hasta la información más específica (una dirección de host IP) que está contenida en los últimos octetos. Por este motivo, el orden de los octetos de la dirección IP debe invertirse cuando se genera el árbol de dominios in-addr.arpa. Las direcciones IP del árbol in- addr.arpa de DNS se pueden delegar en organizaciones ya que se les asigna un
- 5. conjunto específico o limitado de direcciones IP dentro de las clases de direcciones definidas por Internet. Por último, el árbol de dominios in-addr.arpa, al estar integrado en DNS, requiere que se defina un tipo de registro de recursos adicional: el registro de recursos de puntero (PTR). Este registro de recursos crea una asignación en la zona de búsqueda inversa que suele corresponder a un registro de recursos de host (A) con nombre asignado para el nombre del equipo DNS de un host en su zona de búsqueda directa. El dominio in-addr.arpa se aplica a todas las redes TCP/IP que están basadas en el direccionamiento del protocolo de Internet versión 4 (IPv4). El Asistente para nueva zona da por supuesto que se usa este dominio al crear una zona de búsqueda inversa nueva. Si va a instalar DNS y a configurar zonas de búsqueda inversa para una red de protocolo de Internet versión 6 (IPv6), puede especificar un nombre exacto en el Asistente para nueva zona. De esta forma, puede crear zonas de búsqueda inversa en el Administrador de DNS que pueden admitir redes IPv6, que usan un nombre de dominio diferente, el dominio ip6.arpa. Ejemplo: consulta inversa (para redes IPv4) En las siguientes ilustraciones se muestra un ejemplo de una consulta inversa que inicia un cliente DNS para conocer el nombre de otro host (host-a) en función de la dirección IP: 192.168.1.20. El proceso de consulta inversa sigue estos pasos: 1. El cliente consulta al servidor DNS un registro de recursos de puntero (PTR) que se asigna a la dirección IP de 192.168.1.20 para host-a. Como la consulta es para registros de recursos de puntero (PTR), la resolución invierte la dirección y anexa el dominio in-addr.arpa al final de la dirección invertida. Así se obtiene el nombre de dominio completo (FQDN) (20.1.168.192.in-addr.arpa.) que se puede buscar en la zona de búsqueda inversa. 2. Una vez localizado, el servidor DNS autoritativo de 20.1.168.192.in-addr.arpa puede responder con la información del registro de recursos de puntero (PTR). Esto incluye el nombre de dominio DNS de host-a, que completa el proceso de búsqueda inversa.
- 6. Recuerde que, si el nombre inverso consultado no obtiene una respuesta del servidor DNS, se puede usar la resolución de DNS normal (recursión o iteración) para buscar un servidor DNS que sea autoritativo para la zona de búsqueda inversa y que contenga el nombre consultado. En este sentido, el proceso de resolución de nombres que se usa en una búsqueda inversa es idéntico al de la búsqueda directa. CNAME Un nombre canónico (CNAME) crea un alias para un nombre de dominio completo. Cuando un usuario intenta acceder a un nombre de dominio que es en realidad un alias, el sistema DNS sustituye el nombre de dominio real - conocido como el nombre canónico - para el alias. El campo de propietario en el registro CNAME proporciona el nombre del alias que desea crear. Entonces, el campo RDATA proporciona el nombre canónico - es decir, el nombre real del host. Por ejemplo, considere estos registros de recursos: ftp.lowewriter.com. EN UN 207.126.127.132 files.lowewriter.com. IN CNAME www1.lowewriter.com. En este caso, el nombre de host de un servidor FTP a 207.126.127.132 esftp.lowewriter.com. El registro CNAME permite a los usuarios acceder a este huésped comofiles.lowewriter.com si lo prefieren. REGISTROS PTR Un puntero (PTR) es lo contrario de un registro de dirección: Proporciona el nombre de dominio completo para una dirección determinada. El campo titular debe especificar el nombre de dominio de búsqueda inversa, y el campo RDATA especifica el nombre de dominio completo. Por ejemplo, el siguiente registro asigna la dirección 64.71.129.102 awww.lowewriter.com: 102.129.71.64.in-addr.arpa. IN PTR www.lowewriter.com. Registros PTR no suelen aparecer en zonas de dominio normales. En cambio, aparecen en zonas especiales de búsqueda inversa. REGISTROS MX Mail Exchange (MX) identifica el servidor de correo de un dominio. El campo propietario proporciona el nombre de dominio que los usuarios le envían correo a. La sección RDATA del registro tiene dos campos. El primero es un número de prioridad se
- 7. utiliza para determinar qué servidores de correo para utilizar cuando varios están disponibles. El segundo es el nombre de dominio completo del servidor de correo. Por ejemplo, considere los siguientes registros MX: lowewriter.com. IN MX 0 mail1.lowewriter.com. lowewriter.com. IN MX 10 mail2.lowewriter.com. En este ejemplo, el dominio lowewriter.com tiene dos servidores de correo, mail1.lowewriter.com nombrado y mail2.lowewriter.com. Los números de prioridad para estos servidores son 0 y 10. Debido a que tiene un número de prioridad inferior, el correo será entregado a mail1.lowewriter.com primero. El servidor mail2.lowewriter.com se utilizará sólo simail1.lowewriter.com no está disponible. El nombre del servidor especificado en la sección RDATA debe ser un nombre de host real, no un alias creado por un registro CNAME. Aunque algunos servidores de correo pueden manejar los registros MX que apuntan a CNAMEs, no todos podemos. Como resultado de ello, no se debe especificar un alias en un registro MX. Asegúrese de crear un registro de búsqueda inversa (PTR, se describe en la siguiente sección) para los servidores de correo. Algunos servidores de correo no aceptarán correo de un servidor que no tiene entradas de búsqueda inversa válidos.