Administrar registros de recursos

Registros de recursos de host (A)

Los registros de recursos de host (A) se utilizan en una zona para asociar nombres de dominio DNS de equipos (o hosts) a sus direcciones IP y se pueden agregar a una zona de varias formas:

• Puede crear manualmente un RR A para un equipo cliente TCP/IP estático con la consola DNS.

• Los equipos que ejecutan Windows 2000 utilizan el servicio Cliente de DHCP para registrar y actualizar dinámicamente sus propios registros de recursos A en DNS cuando ocurre un cambio en la configuración IP.

• Los equipos cliente habilitados para DHCP que ejecuten versiones anteriores de sistemas operativos de Microsoft pueden hacer que un servidor proxy registre y actualice sus registros de recursos A si obtienen su concesión de IP de un servidor DHCP calificado (sólo el servicio DHCP que proporciona Windows 2000 Server compatibiliza actualmente esta característica).

El registro de recursos de host (A) no es requerido para todos los equipos, pero es necesario para los equipos que comparten recursos en una red. Cualquier equipo que comparta recursos y tenga que identificarse por su nombre de dominio DNS, tiene que utilizar registros de recursos A para facilitar la resolución de nombres DNS a la dirección IP del equipo.

La mayor parte de los RR A requeridos en una zona puede incluir otros servidores o estaciones de trabajo que comparten recursos, otros servidores DNS, servidores de correo electrónico y servidores Web. Estos registros de recursos contienen la mayoría de los registros de recursos de la base de datos de una zona.

Registros de recursos de alias (CNAME)

Los registros de recursos de alias (CNAME) también se llaman, en ocasiones, nombres canónicos. Estos registros permiten utilizar más de un nombre para señalar a un único host, lo que facilita tareas como alojar un servidor FTP y un servidor Web en el mismo equipo. Por ejemplo, los nombres de servidor conocidos (ftp, www) se registran utilizando los RR CNAME que asignan el nombre host de DNS, como "servidor-1", al equipo servidor que aloja estos servicios.

Se recomienda utilizar los RR CNAME en los casos siguientes:

Cuando se necesita cambiar el nombre a un host especificado en un RR A de la misma zona.

• Cuando se necesita resolver un nombre genérico de un servidor conocido como www en un grupo de equipos individuales (cada uno con RR A individuales) que proporcionan el mismo servicio. Por ejemplo, un grupo de servidores Web redundantes.

Cuando cambie el nombre de un equipo con un RR A existente en la zona, podrá utilizar un RR CNAME de forma temporal con el objeto de permitir un período de gracia para que los usuarios y los programas dejen de especificar el nombre de equipo antiguo y usen el nuevo. Para ello, tiene que hacer lo siguiente:

• Para el nombre de dominio DNS nuevo del equipo, se agrega un RR A nuevo a la zona.

• Para el nombre de dominio DNS antiguo, se agrega un RR CNAME que señala al RR A nuevo.

• El RR A original del nombre de dominio DNS antiguo (y su RR PTR asociado, si procede) se quita de la zona.

Cuando utilice un RR CNAME para asignar un alias o cambiar el nombre a un equipo, establezca un límite temporal en la frecuencia con la que utiliza el registro en la zona antes de quitarlo de DNS. Si olvida eliminar el RR CNAME y después se elimina su RR A asociado, el RR CNAME puede desperdiciar recursos del servidor al intentar resolver consultas de un nombre que ya no se utiliza en la red.

El uso más común o popular de un RR CNAME es el de proporcionar un nombre de dominio con un alias de DNS permanente para la resolución de nombres genérica de un nombre basado en servicios, como www.example.microsoft.com, a varios equipos o direcciones IP utilizados en un servidor Web. Por ejemplo, a continuación se muestra la sintaxis básica del uso de un RR CNAME.

nombreAliasIN CNAMEnombreCanónicoPrincipal

En este ejemplo, un equipo denominado host-a.example.microsoft.com necesita funcionar como un servidor Web denominado "www.example.microsoft.com." y como un servidor FTP denominado "ftp.example.microsoft.com". Para conseguir el uso deseado para denominar este equipo, puede agregar y utilizar las entradas CNAME siguientes en la zona example.microsoft.com:

host-a IN A 10.0.0.20

ftp IN CNAME host-a

www IN CNAME host-a

Si decide posteriormente mover el servidor FTP a otro equipo independiente del servidor Web en el "host-a", basta con cambiar el RR CNAME en la zona por ftp.example.microsoft.com y agregar un RR A adicional a la zona del equipo nuevo que aloja el servidor FTP.

Según el ejemplo anterior, si el equipo nuevo se denominara host-b.example.microsoft.com", los RR CNAME y A nuevos y revisados serían de la manera siguiente:

host-a IN A 10.0.0.20

host-b IN A 10.0.0.21

ftp IN CNAME host-b

www IN CNAME host-a

Registros de recursos del agente de intercambio de correo (MX)

El RR del agente de intercambio de correo (MX) es usado por las aplicaciones de correo electrónico para ubicar el servidor de correo electrónico en función del nombre de dominio DNS utilizado en la dirección de destino para el destinatario de un mensaje de correo electrónico. Por ejemplo, se puede utilizar una consulta DNS del nombre "example.microsoft.com" para buscar un RR MX y habilitar una aplicación de correo electrónico para reenviar o intercambiar correo electrónico con un usuario con la dirección de correo electrónico "user(EN)example.microsoft.com".

El RR MX muestra el nombre de dominio DNS del equipo o equipos que procesan correo en un dominio. Si hay varios RR MX, el servicio Cliente DNS intenta entrar en contacto con los servidores de correo en el orden de preferencia desde el valor más bajo (prioridad más alta) al valor más alto (prioridad más baja). A continuación se muestra la sintaxis básica que se utiliza en un RR MX.

nombreDeDominioDeCorreoIN MXpreferencia hostServidorDeCorreo

Al utilizar los RR MX que se muestran debajo en la zona example.microsoft.com, el correo dirigido a user(EN)example.microsoft.com se entrega primero, si es posible, en user(EN)mailserver0.example.microsoft.com. Si este servidor no está disponible, el cliente de resolución puede utilizar en su lugar user(EN)mailserver1.example.microsoft.com.

(EN) IN MX 1 mailserver0

(EN) IN MX 2 mailserver1

Tenga en cuenta que el uso del símbolo arroba ((EN)) en los registros indica que el nombre de dominio DNS del servidor de correo es el mismo que el nombre de origen de la zona (example.microsoft.com).

Registros de recursos de puntero (PTR)

Los RR de puntero (PTR) se utilizan para compatibilizar el proceso de búsqueda inverso, basado en zonas creadas que tienen su raíz en el dominio in-addr.arpa. Estos registros se utilizan para localizar un equipo por su dirección IP y resolver esta información en el nombre de dominio DNS de ese equipo.

Los RR PTR se pueden agregar a una zona de varias formas:

Puede crear manualmente un RR PTR para un equipo cliente TCP/IP estático con el complemento DNS, como procedimiento independiente o como parte del procedimiento para crear un RR A.

• Los equipos que ejecutan Windows 2000 pueden utilizar el servicio Cliente de DHCP para registrar y actualizar dinámicamente sus RR PTR en DNS cuando ocurre un cambio en la configuración IP.

• Todos los demás equipos cliente habilitados para DHCP pueden hacer que el servidor DHCP registre y actualice sus RR PTR si obtienen su concesión de IP de un servidor calificado. El servicio DHCP que proporciona Windows 2000 ofrece esta capacidad.

Registros de recursos de ubicación de servicio (SRV)

Para ubicar los controladores de dominio de Active Directory en Windows 2000, se necesitan RR de ubicación de servicios (SRV). Normalmente, puede evitar la administración manual del RR SRV al instalar Active Directory.

De forma predeterminada, el Asistente para la instalación de Active Directory intenta ubicar un servidor DNS en función de la lista de servidores DNS alternativos o preferidos, configurada en cualquiera de sus propiedades de cliente TCP/IP, para cualquiera de sus conexiones de red activas. Si se entra en contacto con un servidor DNS que puede aceptar la actualización dinámica del RR SRV (y otros RR relacionados con el registro de Active Directory como servicio en DNS), se completa el proceso de configuración.

Si, durante la instalación, no se encuentra un servidor DNS que pueda aceptar actualizaciones del nombre de dominio DNS utilizado para denominar Active Directory, se puede instalar localmente un servidor DNS de Windows 2000 y configurarlo automáticamente con una zona que esté basada en el dominio de Active Directory.

Por ejemplo, si el dominio de Active Directory que eligió para su primer dominio en el bosque fue example.microsoft.com, se agregaría y configuraría una zona que tuviera su raíz en el nombre de dominio de DNS de example.microsoft.com para que se utilizara con el servidor DNS que se ejecuta en el nuevo controlador de dominio.

Si no instala el servidor DNS que proporciona Windows 2000, se escribe y se crea un archivo (Netlogon.dns) durante el proceso de instalación de Active Directory que contiene los RR SRV y otros RR necesarios para permitir el uso de Active Directory. Este archivo se crea en la carpeta %SystemRoot%\System32\Config.

Administrar registros de autoridad

Las zonas se basan en el concepto de autoridad de servidor. Cuando se configura un servidor DNS para cargar una zona, utiliza dos tipos de registros de recursos para determinar las propiedades autorizadas de la zona.

• Primero, el registro de recursos de inicio de autoridad (SOA) indica el nombre de origen de la zona y contiene el nombre del servidor que es el origen principal de información acerca de la zona. También indica otras propiedades básicas de la zona.

• A continuación, se utiliza el registro de recursos del servidor de nombres (NS) para anotar qué servidores DNS están designados como autorizados para la zona. Al mostrar un servidor en el RR NS, se da a conocer a los otros como servidor autorizado para la zona. Esto significa que cualquier servidor especificado en el RR NS va a ser considerado por los demás como un origen autorizado y puede responder con seguridad cualquier consulta realizada de nombres incluidos en la zona.

Los registros de recursos NS y SOA desempeñan una función especial en la configuración de zona. Son registros necesarios para cualquier zona y, normalmente, son los primeros registros de recursos que se muestran en los archivos. De forma predeterminada, el Asistente para agregar zonas nuevas crea automáticamente estos registros cuando se agrega una nueva zona principal con el complemento DNS.

Delegar zonas

DNS proporciona la opción de dividir el espacio de nombres en una o varias zonas, que se pueden almacenar, distribuir y replicar en otros servidores DNS. Cuando decida si va a dividir el espacio de nombres DNS para crear zonas adicionales, considere las razones siguientes para utilizar zonas adicionales:

• La necesidad de delegar la administración de parte del espacio de nombres DNS en otra ubicación o departamento dentro de la organización.

• La necesidad de dividir una zona grande en zonas más pequeñas para distribuir las cargas de tráfico entre varios servidores, mejorar el rendimiento de resolución de nombres DNS o crear un entorno DNS con una mayor tolerancia a errores.

• La necesidad de aumentar el espacio de nombres al agregar numerosos subdominios a la vez, como para adaptarse a la apertura de un nuevo sitio o sucursal.

Si, por cualquiera de estas razones, pudiera beneficiarse al delegar zonas, puede que tenga sentido reestructurar el espacio de nombres mediante la adición de zonas. Cuando elija cómo estructurar las zonas, debe utilizar un plan que refleje la estructura de la organización.

Al delegar las zonas dentro del espacio de nombres, sea consciente de que, para cada nueva zona que cree, necesitará registros de delegación en otras zonas que señalen a los servidores DNS autorizados para la zona nueva. Esto es necesario tanto para transferir la autoridad como para proporcionar una referencia correcta a otros clientes y servidores DNS de los servidores nuevos que se autorizan para la zona nueva.

Cuando se crea una zona principal estándar por primera vez, se almacena como un archivo de texto que contiene toda la información del registro de recursos en un único servidor DNS. Este servidor actúa como el servidor principal de la zona. La información de zona se puede replicar en otros servidores DNS para mejorar la tolerancia a errores y el rendimiento del servidor.

Al estructurar las zonas, hay varias buenas razones para utilizar servidores DNS adicionales para la replicación de zonas.

• Los servidores DNS agregados proporcionan redundancia de zona, lo que permite que los nombres DNS en la zona sean resueltos para los clientes si el servidor principal de la zona deja de responder.

• Los servidores DNS agregados se pueden situar de manera que reduzcan el tráfico de red DNS. Por ejemplo, agregar un servidor DNS en el lado opuesto de un vínculo WAN de baja velocidad puede ser útil para administrar y reducir el tráfico de red.

• Se pueden utilizar servidores secundarios adicionales para reducir la carga en un servidor principal de una zona.

Ejemplo: delegar un subdominio a una zona nueva

Como se muestra en la ilustración siguiente, cuando se crea una zona nueva para un subdominio (example.microsoft.com), se necesita la delegación de la zona principal (microsoft.com).

En este ejemplo, se asigna nombre a un equipo servidor DNS autorizado para el subdominio example.microsoft.com recién delegado en función de un subdominio derivado incluido en la zona nueva (ns1.na.example.microsoft.com). Para dar a conocer este servidor a otros fuera de la zona nueva delegada, se necesitan dos RR en la zona microsoft.com para completar la delegación en la zona nueva.

Estos RR incluyen:

• Un RR NS para llevar a cabo la delegación. Este RR se utiliza para anunciar que el servidor denominado ns1.na.example.2icrosoft.com es un servidor autorizado para el subdominio delegado.

• Un RR A, conocido también como un registro con adherencia es necesario para resolver el nombre del servidor especificado en el RR NS a su dirección IP. El proceso de resolución del nombre de host en este RR al servidor DNS delegado en el RR NS se denomina, algunas veces, persecución de adherencia.

Cuando las delegaciones de zona se configuran correctamente, la forma de referencia de zona normal puede, en ocasiones, evitarse si se utiliza una lista de servidores de reenvío en la configuración del servidor DNS