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.