Exportar (0) Imprimir
Expandir todo
Este artículo proviene de un motor de traducción automática. Mueva el puntero sobre las frases del artículo para ver el texto original. Más información.
Traducción
Original

Estructura física de DNS

La estructura lógica de Windows Server ® 2008 DNS implica la partición, en el espacio de nombres DNS que se extiende la jerarquía de nombres de dominio DNS en varios subdominios. La estructura física de DNS implica la distribución de la base de datos DNS que utilizan servidores DNS para las zonas DNS de host para los subdominios de la jerarquía de nombres de dominio DNS. El cliente DNS y el servidor de aplicaciones de servicios de administran los datos físicos de DNS en la base de datos DNS.

Servicio cliente DNS

Windows Server 2008 incluye un servicio de cliente DNS está habilitado de forma predeterminada. Este servicio realiza todas las búsquedas DNS necesarias y proporciona una caché local para las consultas DNS que reduce el tráfico de red DNS y velocidades de resolución de nombres.

Este servicio puede detenerse y comenzó a usar la consola de servicios.

El servicio cliente DNS de Windows Server 2008 realiza las siguientes tareas:

  • Registra sus nombres en DNS.

  • Realiza la resolución de nombres.

  • Almacena en caché las respuestas a consultas de resolución de nombres.

  • Quita previamente resolver nombres de la caché cuando recibe una respuesta negativa para el nombre.

  • Realiza la caché negativa.

  • Realiza un seguimiento de las conexiones de red transitorios (Plug and Play) y las listas de servidores DNS basadas en sus configuraciones de IP.

  • Mantiene los sufijos de nombre de dominio específico.

  • Si se configuran varios servidores DNS en el cliente, da prioridad a los servidores DNS que se utiliza según para responder a una consulta.

  • Da prioridad a varios registros de recursos que recibe de un servidor DNS basado en su dirección IP.

  • Inicia un tiempo de espera de un error de red cuando todo el servicio cliente DNS consulta tiempo de espera y no envía más consultas durante 30 segundos. Esta característica se aplica a cada adaptador por separado.

Configuración del cliente DNS de Windows Server 2008 incluye a los siguientes ajustes en las propiedades de TCP/IP para cada equipo:

  • Nombres de dominio

  • Nombres de host

  • Sufijos DNS principales

  • Nombres específicos de la conexión

  • Nombres NetBIOS

  • Lista de servidores DNS

  • Lista de búsqueda de sufijos DNS

Nombres de dominio

El nombre de dominio se utiliza con el nombre del equipo cliente para formar el nombre de dominio completo (FQDN), conocido también como el nombre completo de equipo. En general, el nombre de dominio DNS es el resto del FQDN que no se utiliza como el nombre de host único para el equipo.

Por ejemplo, si el FQDN o nombre completo de equipo, es wkstn1.ejemplo.Microsoft.com;el nombre de dominio es la parte ejemplo.Microsoft.com del nombre.

Nombres de dominio DNS tienen dos variaciones: un nombre DNS y un nombre NetBIOS. El nombre completo de equipo (un nombre DNS completo) se utiliza durante la consulta y la ubicación de los recursos con nombre de la red. Para clientes de versiones anteriores, el nombre NetBIOS se utiliza para localizar varios tipos de servicios NetBIOS que se comparten en la red.

Un ejemplo que muestra la necesidad de nombres NetBIOS y DNS es el servicio Net Logon. DNS de Windows Server 2008, el servicio de Net Logon en un controlador de dominio registra sus registros de recursos de servicio (SRV) en un servidor DNS. Para Windows NT Server 4.0 y versiones anteriores del sistema operativo, controladores de dominio registran una entrada de nombre de dominio en Internet nombres Windows Service (WINS) para realizar el mismo registro y anunciar su disponibilidad para proporcionar el servicio de autenticación a la red.

Cuando un equipo cliente se inicia en la red, utiliza a la resolución DNS para consultar un servidor DNS para los registros SRV para su nombre de dominio configurado. Esta consulta se utiliza para buscar controladores de dominio y proporcionar autenticación de inicio de sesión para tener acceso a recursos de red. Un cliente o un controlador de dominio en la red utiliza opcionalmente el servicio de resolución de NetBIOS para consultar los servidores WINS, intentando localizar las entradas DomainName [1C] para completar el proceso de inicio de sesión.

Los nombres de dominio DNS deben seguir los mismos estándares y prácticas recomendadas que se aplican a la nomenclatura de equipo DNS. En general, las convenciones de nomenclatura aceptables para nombres de dominio incluyen el uso de letras A Z, números del 0 al 9 y el guión (-). El uso del punto (.) en un nombre de dominio siempre se utiliza para separar las partes discretas de un nombre de dominio, comúnmente conocida como etiquetas. Cada etiqueta corresponde a un nivel adicional definido en el árbol de espacio de nombres DNS.

Para la mayoría de los equipos, el sufijo DNS principal configurado para el equipo puede ser el mismo que su nombre de dominio de Active Directory, aunque los dos valores pueden ser diferentes.

Nombres de host

Los equipos que utilizan el protocolo TCP/IP subyacente de una red basada en Windows utilizan una dirección IP, un valor numérico de 32 bits (en el caso de IPv4) o un valor numérico de 128 bits (en el caso de IPv6), para identificar la conexión de red del equipo de hosts de red. Sin embargo, los usuarios de red prefieren utilizar nombres alfanuméricos fáciles de recordar. Para apoyar esta necesidad, los recursos en una red basada en Windows se identifican mediante nombres alfanuméricos y el IP de red direcciones. DNS y WINS son dos mecanismos de resolución de nombres que permiten el uso de nombres alfanuméricos y conversión estos nombres en sus respectivas direcciones IP. Por ejemplo, en el FQDN wkstn1.ejemplo.Microsoft.com., el nombre de equipo DNS es el Puesto1 de etiqueta.

NetBIOS vs. Nombres de equipo DNS

En redes que ejecutan Windows NT 4.0 y anteriores, los usuarios normalmente localizar y tener acceso a un equipo de la red mediante un nombre NetBIOS (Network Basic Input Output System). En versiones posteriores del sistema operativo Windows, incluyendo Windows Server 2008, los usuarios localizar y tener acceso a un equipo mediante DNS. En esta implementación de DNS, un equipo se identifica por su nombre completo de equipo, que es un FQDN de DNS.

Sufijos DNS principales

El nombre completo de equipo es una concatenación del nombre de host de etiqueta única, como, por ejemplo, hostcomputer, y un multietiqueta nombre, como corp.ejemplo.com, que es el nombre DNS del dominio de Active Directory al que está unido el equipo el sufijo DNS principal. Con el host y ejemplos de sufijo DNS principales, el nombre completo es hostcomputer.corp.example.com.

El nombre de host es el mismo que el nombre de equipo especificado durante la instalación de Windows Server 2008 y aparece en Las propiedades del sistema. El nombre de sufijo DNS principal es el mismo que el nombre de dominio especificado durante la instalación de Windows Server 2008 y aparece en Las propiedades del sistema. El nombre completo de equipo también aparece en Las propiedades del sistema.

Además, los sufijos DNS específicos de la conexión pueden aplicarse a las conexiones del adaptador de red independiente utilizadas por un equipo multitarjeta. Sufijos DNS específicos de la conexión a identifican el host cuando se conecta para separar las redes que utilizan diferentes nombres de dominio. Al utilizar los sufijos DNS específicos de la conexión, un nombre completo de equipo también es una concatenación del nombre de host y un sufijo DNS específico de conexión.

Utilizando su nombre de host y sufijos DNS, un único equipo puede tener su nombre completo de equipo configurado con dos métodos posibles:

  • Un nombre completo del equipo principal, que se aplica como nombre completo de equipo predeterminado para el equipo y todas sus conexiones de red configuradas.

  • Un nombre completo de equipo específico, que puede configurarse como un nombre de dominio DNS alternativo que sólo se aplica a un único adaptador de red instalado y configurado en el equipo.

Al utilizar Active Directory, de forma predeterminada, la parte del sufijo DNS principal un nombre de equipo completo de equipo debe ser el mismo que el nombre del dominio de Active Directory donde se encuentra el equipo. Para permitir diferentes sufijos DNS principales, un administrador de dominio puede crear una lista restringida de sufijos permitidos mediante la creación del atributo msDS-AllowedDNSSuffixes en el contenedor de objetos de dominio. Este atributo es creado y administrado por el administrador del dominio mediante Interfaces de servicio de Active Directory (ADSI) o el protocolo ligero de acceso a directorios (LDAP).

Nombres específicos de la conexión

Como se muestra en la figura siguiente, un equipo de servidor de hosts múltiples llamado "host-a" puede denominarse segun tanto sus principales y específicos de la conexión de nombres de dominio DNS.

Nombres DNS específicos de la conexión

Connection-specific DNS Names

En este ejemplo, el servidor equipo host-a se conecta a dos subredes distintas, subred 1 y la subred 2, que también están vinculadas en puntos redundantes utilizando dos enrutadores para rutas adicionales entre cada subred. Dada esta configuración, host-a ofrece acceso siguiente a través de sus conexiones de red de área local (LAN) por separado con nombre:

  • El nombre "host-a.public.example.microsoft.com" proporciona acceso mediante la conexión LAN 1 sobre la subred 1, una LAN Ethernet de baja velocidad (10 megabits), para el acceso normal a los usuarios que tienen necesidades de servicios de impresión y archivo típico.

  • El nombre "host-a.backup.example.microsoft.com" proporciona acceso mediante la conexión LAN 2 sobre la subred 2, una LAN Ethernet de alta velocidad (100 megabits), para el acceso reservado por las aplicaciones de servidor y los administradores que necesiten para solucionar problemas de red del servidor, realizar copia de seguridad de red o replicar datos de zona entre servidores.

Además de los nombres DNS específicos de la conexión, el equipo también puede ser accesible mediante cualquiera de las dos conexiones LAN especificando su nombre de dominio DNS principal, "host-a.ejemplo.Microsoft.com".

Cuando se configura como se muestra, un equipo puede registrar los registros de recursos en DNS según de sus tres nombres y distintos conjuntos de direcciones IP, como se muestra en la tabla siguiente:

Nombres de DNS

Nombre DNS Direcciones IP Descripción

host-a.ejemplo.Microsoft.com

10.1.1.11, 10.2.2.22

Nombre DNS principal del equipo. El equipo registra los registros de recursos de a y PTR para todas las direcciones IP configuradas con este nombre en la zona "ejemplo.Microsoft.com".

host-a.public.example.microsoft.com

10.1.1.11

Conexión-nombre DNS específico para la conexión LAN 1, que registra los registros de recursos a y PTR para la dirección IP 10.1.1.11 en la zona de "public.example.microsoft.com".

host-a.backup.example.microsoft.com

10.2.2.22

Conexión-nombre DNS específico para la conexión LAN 2, que registra los registros de recursos a y PTR para la dirección IP 10.2.2.22 en la zona "backup.example.microsoft.com".

Cuando cambia de equipo entre las conexiones a redes diferentes alojar diferentes dominios DNS, el nombre de host no tiene que cambiarse a menos que haya un host en el nuevo dominio DNS con el mismo nombre de host. Se puede cambiar el sufijo DNS principal para el equipo desde el antiguo nombre de dominio para el nuevo dominio y el equipo registrará el nuevo nombre de equipo completo en DNS.

Dd197495.note(es-es,WS.10).gif Nota
Si tienes cualquier dinámica de hosts múltiples clientes de actualización y al menos un adaptador utiliza DHCP, configurar el servidor DHCP para actualizar los registros de recursos de acuerdo con la solicitud del cliente. Si el servidor DHCP está configurado para registrar y registros de recursos PTR, el servidor DHCP puede reemplazar todos los registros de recursos para el nombre que se trata de registrar. Como resultado, los registros de recursos que se corresponden con el equipo del otro podrían eliminarse las direcciones IP.

En Windows Server 2008, el nombre completo de equipo es ver y establecer en la ficha Nombre de equipo de Propiedades del sistema. Sufijos DNS específicos de la conexión se configuran en el cuadro de diálogo Configuración avanzada de TCP/IP de las Propiedades de protocolo Internet (TCP/IP) para una conexión de red.

Nombres NetBIOS

El nombre NetBIOS se crea utilizando los 16 primeros bytes del nombre de host, que es el número máximo de caracteres para nombres NetBIOS. El nombre NetBIOS es una cadena de 16 bytes que identifica un equipo o servicio para la comunicación de red. Si el nombre de host DNS es 15 bytes, el nombre NetBIOS es el nombre de host más espacios necesarios para formar un nombre de 15 bytes, seguido de un identificador único de 1 byte. El byte decimosexto especifica el servicio de red asociado con el equipo. Cuando el nombre del equipo supera la longitud máxima para NetBIOS, el nombre de equipo NetBIOS se crea mediante el truncamiento del nombre de host para formar un nombre de 15 bytes, seguido de un identificador único de 1 byte.

Dd197495.note(es-es,WS.10).gif Nota
Porque los nombres de host están codificados en formato UTF-8, no necesariamente tienen sólo 1 byte por carácter. Los caracteres ASCII tienen 1 byte, pero el tamaño de los caracteres extendidos es más de 1 byte. Para obtener información detallada de las restricciones y una descripción más completa de UTF8 de nomenclatura, consulte "Restricciones de nombre para hosts y dominios" más adelante en este tema.

Si está utilizando nombres de NetBIOS para admitir la tecnología de red de Microsoft heredada, se recomienda que revise los nombres de equipo NetBIOS utilizados en la red para preparar la migración a un entorno sólo DNS estándar. Esto prepara la red para el crecimiento de largo plazo y compatibilidad con futuros requisitos de nomenclatura. Por ejemplo, si utiliza el mismo nombre para la resolución NetBIOS y DNS, considere la posibilidad de convertir caracteres especiales en los nombres NetBIOS actuales que no cumplen con estándares, como, por ejemplo, el carácter de subrayado (_) de nombres DNS. Mientras estos caracteres están permitidos en nombres de NetBIOS, más a menudo son incompatibles con los nombres de requisitos y la mayoría de los programas de cliente de resolución DNS existentes tradicional host de DNS.

Dd197495.note(es-es,WS.10).gif Nota
Si está habilitada la búsqueda WINS para zonas que alojan los servidores DNS de Windows, deberá utilizar el mismo nombre para equipos NetBIOS y DNS. De lo contrario, los resultados de los clientes que intenten realizar consultas y resolver los nombres de estos equipos serán incoherentes.

La siguiente tabla resume las diferencias entre los nombres DNS y NetBIOS mediante el CLIENTE1.example.com FQDN de ejemplo.

Nombres DNS y NetBIOS

Tipo de nombre Descripción

Nombre de NetBIOS

El nombre NetBIOS se utiliza para identificar servicios de NetBIOS del equipo. Los nombres NetBIOS se resuelve a la dirección IP del equipo a través de la difusión, WINS o el archivo LMHosts. De forma predeterminada, el nombre del equipo NetBIOS es el mismo que el nombre de host de hasta 15 bytes, más los espacios necesarios para que el nombre largo de 15 bytes más el identificador de servicio.

Por ejemplo, un nombre de NetBIOS podría ser CLIENTE1.

Nombre de host

El nombre de host es la primera etiqueta de un FQDN.

Por ejemplo, la primera etiqueta de la CLIENTE1.example.com FQDN es CLIENTE1.

Sufijo DNS principal

Cada equipo que ejecuta el sistema operativo Windows se puede asignar un sufijo DNS principal que se utilizará en el registro de nombre y la resolución de nombre. Puede ver el sufijo DNS principal para el equipo desde la ficha Nombre de equipo de Propiedades del sistema.

El sufijo DNS principal es también conocida como el nombre de dominio principal.

Por ejemplo, la CLIENTE1.example.com FQDN tiene el example.com de sufijo DNS principal.

Sufijo DNS específico de conexión

El sufijo DNS específico de conexión es un sufijo DNS que se asigna a una conexión de red. El sufijo DNS específico de conexión también es conocido como un sufijo DNS específico del adaptador. Por ejemplo, un sufijo DNS específico de conexión podría ser acquired01-ext.com.

Nombre de dominio completo (FQDN)

El FQDN es un nombre DNS que identifica el equipo en el espacio de nombres DNS. De forma predeterminada, es una concatenación del nombre de host, el sufijo DNS principal y un período. Por ejemplo, un FQDN podría ser CLIENTE1.example.com.

Nombre completo de equipo

El nombre completo de equipo es el FQDN. Es la concatenación del host nombre y sufijo DNS principal (o nombre de host y sufijo DNS específico de conexión).

Lista de servidores DNS

Para que los clientes DNS funcionen eficazmente, debe configurarse una lista de prioridades de servidores de nombres DNS para que cada equipo utilice cuando procese consultas y resolver nombres DNS. En la mayoría de los casos, el equipo cliente se pone en contacto y utiliza su servidor DNS preferido, que es el primer servidor DNS de la lista configurada localmente. Enumerados servidores DNS alternativos se contactó con y se utiliza cuando el servidor preferido no está disponible. Por este motivo, es importante que el servidor DNS preferido es apropiado para el uso continuo del cliente en condiciones normales.

Para equipos que ejecutan Windows XP, la lista de servidores DNS se utiliza por los clientes sólo para resolver nombres DNS. Cuando los clientes envían actualizaciones dinámicas, como, por ejemplo, al cambiar su nombre de dominio DNS o una dirección IP configurada, es posible que con estos servidores u otros servidores DNS según sea necesario para actualizar sus registros de recursos DNS.

De forma predeterminada, el cliente DNS de Windows XP no intenta realizar actualizaciones dinámicas a través de un servicio de acceso remoto (RAS) o conexión de red privada virtual (VPN). De forma predeterminada, el servicio cliente DNS de Windows Server 2008 no intenta realizar actualizaciones dinámicas de zonas de dominio de nivel superior (TLD). Cualquier zona en el nombre de una sola etiqueta se considera una zona TLD, por ejemplo, com, edu, en blanco, mi-empresa. Cuando los clientes DNS configurados dinámicamente utilizando un servidor DHCP, es posible tener una lista más amplia de servidores DNS proporcionados. Para compartir de forma eficaz la carga cuando se proporcionan varios servidores DNS en una lista de opciones especificadas de DHCP, puede configurar un alcance DHCP distinto que invierta el orden de lista de servidores DNS y WINS proporcionados a los clientes.

Lista de búsqueda de sufijos DNS

Para los clientes DNS, puede configurar una lista de búsqueda de sufijos de dominio DNS que aumente o revise sus capacidades de búsqueda DNS. Al agregar sufijos adicionales a la lista, puede buscar nombres de equipo cortos y sin calificar en más de un dominio DNS especificado. A continuación, si se produce un error en una consulta DNS, el servicio cliente DNS puede utilizar esta lista para anexar otros finales de sufijos de nombre al nombre original y repetir las consultas DNS del servidor DNS para estos FQDN alternativos.

Los servidores y equipos, el siguiente comportamiento de búsqueda DNS predeterminado es predeterminado y se utiliza cuando completan y resuelven los nombres cortos e incompletos.

Cuando la lista de búsqueda de sufijos está vacía o no especificado, el sufijo DNS principal del equipo es anexa a corta los nombres incompletos y se utiliza una consulta DNS para resolver el FQDN resultante. Si falla esta consulta, el equipo puede intentar consultas adicionales para FQDN alternativos anexando cualquier sufijo DNS específicos de la conexión configurado para conexiones de red.

Si hay configurado ningún sufijo específico de la conexión o fallan las consultas de estos FQDN específicos de la conexión resultantes, el cliente, a continuación, puede volver a intentar las consultas sobre la reducción sistemática del sufijo principal (también conocido como devolución).

Por ejemplo, si el sufijo principal fuera "ejemplo.Microsoft.com", el proceso de devolución sería volver a intentar las consultas del nombre corto al buscarlo en microsoft."dominios de "com" y "com".

Cuando la lista de búsqueda de sufijos no está vacía y tiene al menos un sufijo DNS especificado, intentos de calificar y resolver nombres DNS cortos se limita a la búsqueda sólo aquellos FQDN puestos a disposición por la lista de sufijos especificada. Si no se resuelven consultas para todos los FQDN que se crean como resultado de anexar y probar cada sufijo en la lista, se produce un error en el proceso de consulta, producir un resultado "nombre no encontrado".

Si se utiliza la lista de sufijos de dominio, los clientes continuarán enviando consultas alternativas adicionales basadas en los distintos nombres de dominio DNS cuando una consulta no responden ni resolver. Después de un nombre se resuelve con una entrada en la lista de sufijos, no se prueban las entradas de la lista no utilizados. Por esta razón, es más eficaz a orden de que la lista con el mayor número primero los sufijos de dominio usados comúnmente.

Búsquedas de sufijos de nombre de dominio se utilizan sólo cuando una entrada de nombre DNS no está completa. Para completar un nombre DNS, un punto (. ) se escribe al final del nombre..

Restricciones de nombre de hosts y dominios

Diferentes implementaciones de DNS permiten caracteres diferentes y longitudes y difieren de las restricciones de nombres NetBIOS. La siguiente tabla muestra las restricciones de nombres DNS estándar, nombres DNS en Windows Server 2008 y nombres NetBIOS.

Restricción DNS estándar (incluido Windows NT 4.0) DNS en Windows Server 2008 NetBIOS

Caracteres

Es compatible con RFC 1123, que permite el "A" a "Z", "a" a "z", "0" a "9" y el guión (-)

Varias configuraciones diferentes son posibles, como se describe al final de esta sección.

Permite que los caracteres Unicode, números, espacios en blanco, símbolos:! @ $ % ^ &) ( . - _ { } ~

Longitud del nombre de dominio completo

Permite 63 bytes por etiqueta y 255 bytes para el FQDN

Permite 63 bytes por etiqueta y 255 bytes de un FQDN;el nombre completo de un nombre de dominio de Active Directory está limitado a 64 bytes.

Permisos de 16 bytes para un nombre de host

Dd197495.note(es-es,WS.10).gif Nota
Aunque mucho tiempo, puede crear nombres DNS complejos, se recomienda crear nombres más cortos y fáciles de usar.

Windows Server 2008 admite la migración al permitir que un conjunto a la especificada en el documento RFC 1123 de caracteres más amplio. RFC 2181 amplía el juego de caracteres admitido en los nombres DNS. Indica que una etiqueta DNS puede ser cualquier cadena binaria, y no necesariamente deben interpretarse como ASCII. Según esta definición, Microsoft ha propuesto que la especificación del nombre DNS se reajuste para aceptar un juego de caracteres mayor: codificación de caracteres de UTF-8, como se describe en RFC 2044.

Codificación de caracteres UTF-8 es un superconjunto de ASCII y una traducción de la codificación de caracteres UCS-2 (también conocido como Unicode). El juego de caracteres UTF-8 incluye caracteres de la mayoría de los idiomas del mundo escrito;Esto permite una mayor gama de posibles nombres. El servicio DNS de Windows Server 2008 incluye soporte para la codificación de caracteres UTF-8. Para obtener más información acerca de UTF-8, vea "caracteres Unicode" apoyo en Procesos DNS y las interacciones .

Sin embargo, antes de utilizar caracteres adicionales en los nombres DNS, tenga en cuenta lo siguiente:

  • Otro software de cliente DNS sólo admite los caracteres especificados en RFC 1123. Este software de cliente DNS puede que no se puede resolver los nombres DNS de equipos con nombres que utilizan caracteres fuera del conjunto de RFC 1123.

  • Un servidor DNS que no admite la codificación UTF-8 podría aceptar a una transferencia de una zona con nombres UTF-8, pero no se puede escribir esos nombres a un archivo de zona o volver a cargarlos desde un archivo de zona. Por lo tanto, no debe transferir una zona que contenga caracteres UTF-8 a un servidor DNS que no los admite.

  • Si intenta registrar un nombre DNS en AD DS que contiene un carácter extendido que no se puede representar en un nombre distinguido LDAP, AD DS responderá con un error de sintaxis no válida.

    Puede configurar el servidor DNS de Windows Server 2008 para permitir o rechazar el uso de caracteres UTF-8 en los nombres DNS. Puede hacerlo para cada servidor DNS que se administra mediante la consola DNS.

    Dd197495.note(es-es,WS.10).gif Nota
    Cuando se modifica un nombre de host o el sufijo DNS o crear un dominio de Active Directory, si introduce un nombre DNS que incluye UTF-8 o no aparece en el documento RFC 1123 de caracteres de subrayado, aparece un mensaje de advertencia que explica que algunas implementaciones de servidor DNS puede que no admitan estos caracteres.

Asignación de prioridades de subred

Asignación de prioridades de subred DNS devuelve direcciones IP locales para el servicio cliente DNS en direcciones IP en subredes diferentes. Esta función reduce el tráfico de red al fomentar los equipos cliente para conectarse a recursos de red más cercanos a ellos.

Por ejemplo, supongamos que los tres servidores Web que alojan www.example.com se encuentran en distintas subredes. En el servidor DNS, puede crear los siguientes registros de recursos:



www.example.com.

EN un 172.16.64.11www.example.com.

EN un 172.17.64.22www.example.com.

EN UN 172.18.64.33

Cuando un usuario consulta www.example.com, se devuelven todos los registros de recursos de tres. Con la asignación de prioridades de subred, el servicio cliente DNS vuelve a pedir la lista de registros devueltos para que comience con las direcciones IP de las redes a las que el equipo está conectado directamente. Por ejemplo, si un usuario con las consultas de 172.17.64.93 de dirección IP para www.example.com, el servicio cliente DNS devuelve los registros de recursos en el siguiente orden:



www.example.com.

EN un 172.17.64.22www.example.com.

EN un 172.16.64.11www.example.com.

EN UN 172.18.64.33

Dd197495.note(es-es,WS.10).gif Nota
Asignación de prioridades de subred impide que el servicio cliente DNS mediante el método de operación por turnos en el servicio servidor DNS. Para obtener más información, consulte "Round robin" más adelante en este tema.

Aunque la asignación de prioridades de subred puede reducir el tráfico de red en subredes, es preferible utilizar round robin, tal como se describe en RFC 1794.

Servicio servidor DNS

El servicio servidor DNS es el componente que proporciona la implementación de servidor de DNS. Las configuraciones expuestas en esta sección se incluyen:

  • Deshabilitar el uso de la recursividad

  • Uso de turnos de registros de recursos

  • Asignación de prioridades de subred

  • Parámetros avanzados

Deshabilitar la recursividad

De forma predeterminada, la recursión está habilitada para el servicio servidor DNS y los clientes generalmente solicitan que el servidor utiliza la recursividad para resolver un nombre al enviar una consulta. Si se deshabilita la recursividad, el servicio servidor DNS utiliza siempre la referencia, independientemente de la solicitud de cliente.

En general, los servidores DNS pueden responder a consultas de nombres fuera de las zonas autorizadas de dos maneras:

  • Los servidores pueden enviar respuestas de referencia, que son una respuesta inmediata al cliente solicitante con una lista de registros de recursos para otros servidores DNS que conocen que parecen estar más cerca o más probable que sea de ayuda para resolver el nombre consultado.

  • Servidores pueden utilizar la recursividad para consultar otros servidores en nombre del cliente solicitante e intentar resolver completamente el nombre. Las búsquedas recursivas continúan hasta que el servidor recibe una respuesta con autoridad para el nombre consultado. El servidor reenvía esta respuesta en respuesta a la consulta original del cliente solicitante.

En la mayoría de los casos, se deshabilita la recursividad en un servidor DNS cuando los clientes DNS se limitan a resolver nombres administrados de forma autorizada en un servidor específico. Por ejemplo, es el caso cuando un servidor DNS tiene sólo datos de nombres DNS para una red interna o cuando el servidor DNS no puede resolver nombres DNS externos (como los nombres DNS de Internet) y se espera que los clientes para volver a intentar otro servidor DNS para resolver estos nombres.

Dd197495.note(es-es,WS.10).gif Nota
Si deshabilita la recursividad en el servidor DNS, no podrá utilizar reenviadores en el mismo servidor. Para obtener más información acerca de los reenviadores, vea "Reenvío" en Procesos DNS y las interacciones .

Round robin

DNS por turnos es un método de administración de congestión en el servidor al distribuir la carga de la conexión entre varios servidores (que contienen contenido idéntico). Obras de turnos de forma rotativa en que se entrega una dirección IP del servidor, a continuación, mueve hacia atrás en la lista;la siguiente dirección IP del servidor se distribuyen, a continuación, se mueve al final de la lista;y así sucesivamente, dependiendo del número de servidores que se utilizan. Esto funciona de forma bucle.

Este mecanismo de equilibrio local se utiliza por servidores DNS para compartir y distribuir la carga de recursos de red. Puede utilizar por turnos para girar todos los tipos de registro de recursos contenidos en respuesta a una consulta si se encuentran varios RR.

De forma predeterminada, DNS utiliza por turnos para girar el orden de los datos de RR devueltos en las respuestas a consultas donde existen múltiples RR del mismo tipo para un nombre de dominio DNS consultado. Esta característica proporciona un método sencillo para uso del cliente de servidores Web y otros equipos multitarjeta frecuentemente consultados de equilibrio de carga.

Si está desactivada por turnos para un servidor DNS, el orden de la respuesta de estas consultas se basará en un orden estático de RR en la lista de respuestas se almacenan en la zona (su archivo de zona o AD DS).

Ejemplo: Rotación de turnos

Se realiza una consulta de tipo búsqueda hacia adelante (para todos los RR de dirección de Host [A] que coincidan con un nombre de dominio DNS) en un equipo multitarjeta (multihomed.example.microsoft.com) que tiene tres direcciones IP. Se utilizan distintos RR para asignar el nombre del host a cada una de estas direcciones IP en la zona. En la zona ejemplo.Microsoft.com almacenada, los RR aparecen en el siguiente orden fijo:



multitarjeta IN una 10.0.0.1multihomed en un 10.0.0.2multihomed IN A 10.0.0.3

El primer cliente DNS que consulta al servidor para resolver el nombre de este host recibe la lista de forma predeterminada en orden. Cuando un segundo cliente envía una consulta posterior para resolver este nombre, se rota la lista como sigue:



multitarjeta IN una 10.0.0.2multihomed en un 10.0.0.3multihomed IN A 10.0.0.1

Restringir la rotación de turnos para los tipos de RR seleccionados

De forma predeterminada, DNS realizará rotación de turnos de todos los tipos de RR. Ahora puede especificar que ciertos tipos de RR no son debe ser round-robin girado en el registro. Se pueden realizar estas modificaciones en el registro.

Restringir la rotación de turnos para todos los tipos de RR

De forma predeterminada, todos los tipos de RR giran, excepto aquellos que se han especificado como excluidos de rotación en el registro.

Asignación de prioridades de subred

De forma predeterminada, el servicio de servidor DNS utiliza las prioridades como método para dar preferencia a direcciones IP en la misma red cuando una consulta de cliente se resuelve en un nombre de host que se asigna a más de una dirección IP de subred local. Esta característica requiere que la aplicación cliente intenta conectarse al host mediante su dirección IP más cercana (y normalmente más rápida) disponible para la conexión.

El servicio servidor DNS utiliza la prioridad de subred local como sigue:

  1. El servicio servidor DNS determina si es necesario pedir la respuesta de consulta de asignación de prioridades de subred local.

    Si más de un registro de recursos (RR) coincide con el nombre de host consultado, el servicio servidor DNS puede volver a ordenar los registros por la ubicación de la subred. Si el host consultado coincide un sólo el registro de recursos de nombre, o si la red IP dirección del cliente no coincide con una dirección de red IP para cualquiera de las direcciones asignadas en una lista de respuestas de varios RR, no establecer prioridades es necesario.

  2. Para cada RR de la lista de respuestas coincidentes, el servicio servidor DNS determina qué registros (si hay alguno) coinciden con la ubicación de la subred del cliente solicitante.

  3. El servicio servidor DNS vuelve a pedir la lista de respuestas para que los RR a que coincidan con la subred local del cliente solicitante se colocan primero en la lista de respuestas.

  4. Prioridad por orden de subred, la lista de respuestas se devuelve al cliente solicitante.

Ejemplo sencillo: establecer prioridades de la red Local

Un equipo multitarjeta, multihomed.example.microsoft.com, tiene tres RR a para sus tres direcciones IP de host en la zona example.microsoft.com. Se utiliza un RR a diferente para cada una de las direcciones de host, que aparecen en este orden en la zona:



multitarjeta IN una 192.168.1.27multihomed en un 10.0.0.14multihomed en un 172.16.20.4

Si la resolución de un cliente DNS en la dirección IP 10.4.3.2 consulta al servidor para las direcciones IP del host multihomed.example.microsoft.com, el servicio servidor DNS se observa que la dirección de red IP de origen (10.0.0.0) del cliente coincide con la parte de la red (clase A) de la 10.0.0.4 dirección en la lista de respuestas de RR. El servicio servidor DNS vuelve a pedir las direcciones en la respuesta como sigue:



multitarjeta IN una 10.0.0.14multihomed en un 192.168.1.27multihomed en un 172.16.20.4

Si la dirección IP del cliente solicitante no tiene ninguna red local coincide con ninguno de los RR en la lista de respuestas, no se asigna la lista de prioridad.

Ejemplo complejo: las prioridades de subred Local

En Windows Server 2008, las direcciones se asignan prioridades por coincidencia de la subred de clase c de forma predeterminada, independientemente de la clase de dirección o de máscara de subred de la dirección de destino.

Por ejemplo, un equipo multitarjeta, multihomed.example.microsoft.com, tiene cuatro RR a para cuatro direcciones IP de host en la zona example.microsoft.com. Dos de estas direcciones IP son para redes no locales. Las otras dos direcciones IP comparten una dirección de red IP común pero, como se utilizan subredes IP, representan las conexiones de red de la subred física diferente basándose en su subred personalizada (no predeterminado) valor de 255.255.248.0 de máscara. Estos ejemplo RR aparecen en el siguiente orden de la zona:



multitarjeta IN una 192.168.1.27multihomed en un 172.16.22.4multihomed en un 10.0.0.14multihomed IN A 172.16.31.5

Si la dirección IP del cliente solicitante es 172.16.22.8, tanto de las direcciones IP que coinciden con la misma IP de red como el cliente, el 172.16.0.0 de red, se devuelven en la parte superior de la lista de respuestas al cliente. Sin embargo, en este ejemplo, la 172.16.22.4 dirección se sitúa delante de la 172.16.31.5 porque coincide con la dirección IP del cliente hacia abajo 172.16.20.0 de direcciones dirección de subred.

La lista de respuestas reordenado devuelta por el servicio de servidor DNS sería:



multitarjeta IN una 172.16.22.4multihomed en un 172.16.31.5multihomed en un 192.168.1.27multihomed IN A 10.0.0.14

Dd197495.note(es-es,WS.10).gif Nota
Las subredes IP se impone mediante el uso de un valor de máscara de subred no predeterminado o personalizado con todas las direcciones IP en una red. Prioridad de subred local pasa por alto el uso de la rotación de operación por turnos para nombres de hosts múltiples. Cuando está habilitada por turnos, sin embargo, los RR continúan utilizando round robin como método secundario para ordenar la lista de respuesta.

Parámetros avanzados de servicio de servidor DNS

Cuando inicia el servicio, los servidores DNS utilizan la configuración de servidor obtenidos de los parámetros establecidos en el archivo de información de inicio, en el registro y posiblemente información de zona proporcionada a través de la integración de AD DS.

En la mayoría de los casos, los valores predeterminados de instalación son aceptables y no deberían requerir la modificación. Sin embargo, cuando sea necesario, puede utilizar la consola DNS para ajustar los siguientes parámetros avanzados, tener en cuenta situaciones y necesidades especiales de distribución.

Servicio de servidor DNS parámetros avanzados

Valor Descripción

Deshabilitar la recursividad

Determina si el servidor DNS utiliza recursividad. De forma predeterminada, el servicio servidor DNS está habilitado para utilizar la recursividad.

Enlazar secundarios

Determina si se utiliza el formato de transferencia rápida al transferir una zona a servidores DNS que ejecuten implementaciones de Berkeley Internet Name Domain (BIND) heredados.

De forma predeterminada, los servidores DNS de todo basado en Windows utilizan un formato de transferencia de zona rápida, que utiliza la compresión y puede incluir varios registros por mensaje TCP durante una transferencia conectada. Este formato también es compatible con los más recientes basados en BIND a servidores DNS que ejecutan versiones 4.9.4 y posteriores.

Error en carga si mal datos de zona

Establece el servidor DNS para analizar estrictamente los archivos.

De forma predeterminada, el servicio servidor DNS registra los errores de datos, omite los datos erróneos en los archivos de zona y sigue a una zona de carga. Esta opción puede configurarse con la consola DNS para que el servicio servidor DNS registra los errores y no se puede cargar un archivo de zona que contiene datos de registros que contengan errores.

Habilitar operación por turnos

Determina si el servidor DNS utiliza por turnos para rotar y reordenar una lista de registros de recursos si existen múltiples RR del mismo tipo de respuesta a una consulta.

Habilitar el orden de máscara de red

Determina si el servidor DNS reordenar un conjunto de registros en el mismo registro de recursos en respuesta a una consulta basada en la dirección IP de origen de la consulta de recursos.

Asegurar caché contra corrupción

Determina si el servidor intenta limpiar las respuestas para evitar la contaminación de la caché. Esta opción está habilitada de forma predeterminada.

De forma predeterminada, los servidores DNS utilizan una opción de respuesta segura que no permite agregar registros de recursos no relacionados incluidos en una respuesta de referencia a su caché. En la mayoría de los casos, los nombres agregados en las respuestas de referencia normalmente se almacenan en caché y ayudan a acelerar la resolución de consultas DNS posteriores.

Sin embargo, con esta característica, el servidor puede determinar que los nombres de referencia son potencialmente contaminantes o no seguros y descartarlos. El servidor determina la memoria caché el nombre ofrecido en una referencia sobre la base de que sea parte el exacto relacionado dominio árbol de nombres DNS para el que se realizó el nombre original consultado.

Por ejemplo, si originalmente se realizó una consulta para "ejemplo.Microsoft.com" y una respuesta de referencia proporciona un registro de un nombre fuera del árbol de nombre de dominio "microsoft.com", como, por ejemplo, msn.com, a continuación, ese nombre podría no almacenará en caché si esta característica está habilitada para su uso.

Registros de recursos en DNS

Registros de recursos DNS son los datos que está asociados con nombres DNS en el espacio de nombres DNS. Cada nombre de dominio del árbol de espacio de nombres DNS contiene un conjunto de registros de recursos y cada registro de recursos en el conjunto contiene distintos tipos de información relacionada con el nombre de dominio. Una consulta DNS incluye el nombre de dominio DNS que debe resolverse y el tipo de información deseada (los registros de recursos que se solicitan). Las consultas de las direcciones IP de host DNS devuelven un recurso de registros y las consultas de los servidores DNS autorizados para un nombre de dominio DNS devuelven registros de recursos de nombres (NS) del servidor.

Registros de recursos se tratan normalmente en dos categorías: registros de autoridad y otros registros. Registros de autoridad de identifican los servidores DNS que tienen autoridad para los nombres de dominio en el espacio de nombres DNS y cómo se deben administrar sus zonas y todos los demás registros DNS contienen información acerca de un nombre de dominio que está relacionado con la autoridad.

Registros de autoridad

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

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

  • A continuación, el registro de recursos de servidor (NS) de nombre se utiliza para anotar qué servidores DNS están designados como autorizados para la zona. Con una lista de un servidor en el RR NS, se conoce a otros como servidor autorizado para la zona. Esto significa que cualquier servidor especificado en el RR NS se considera una fuente autorizada por otros usuarios y puede responder con seguridad cualquier consulta realizada sobre los nombres incluidos en la zona.

Los registros de recursos NS y SOA desempeñan una función especial en configuración de zona. Son registros necesarios para cualquier zona y normalmente los primeros registros de recursos incluidos en archivos.

Registro de recursos SOA

El registro de recursos de inicio de autoridad (SOA) se encuentra siempre el primero en cualquier zona estándar. Indica el servidor DNS que originalmente se creó o es ahora el servidor principal de la zona. También se utiliza para almacenar otras propiedades como, por ejemplo, información de versión y los intervalos que afectan a la caducidad o renovación de la zona. Estas propiedades afectan a la frecuencia se realizan las transferencias de la zona entre servidores autorizados para la zona.

El registro de recursos SOA contiene la siguiente información:

Campos de registro de recursos SOA

Campo Descripción

Servidor principal (propietario)

El nombre de host del servidor DNS principal para la zona.

Persona responsable

La dirección de correo electrónico de la persona responsable de administrar la zona. Un punto (. ) en lugar de una arroba (@) en este nombre de correo electrónico..

Número de serie

El número de revisión de la zona. Este número aumenta cada vez que un registro de recursos en los cambios de zona. Es importante que este valor aumenta cada vez que cambia la zona, de modo que los cambios de zona parcial o la zona revisada totalmente puede replicarse en otros servidores secundarios durante las transferencias posteriores.

Intervalo de actualización

El tiempo, en segundos, que un servidor DNS secundario espera antes de consultar a su origen para la zona de intento de renovación de la zona. Cuando caduca el intervalo de actualización, el servidor DNS secundario solicita una copia del registro SOA actual para la zona de su origen, lo que responde a esta solicitud. El servidor DNS secundario, a continuación, compara el número de serie del registro SOA de la actual del servidor de origen (como se indica en la respuesta) con el número de serie en su propio registro SOA local. Si son diferentes, el servidor DNS secundario solicita una transferencia de zona desde el servidor DNS principal. El valor predeterminado para este campo es 900 segundos (15 minutos).

Intervalo de reintento

El tiempo, en segundos, un servidor secundario espera antes de reintentar a una transferencia de zona fallida. Normalmente, este tiempo es menor que el intervalo de actualización. El valor predeterminado es 600 segundos (10 minutos).

Intervalo de caducidad

El tiempo, en segundos, antes de que un servidor secundario deje de responder a las consultas después de un intervalo de actualización caducado donde la zona no era actualiza o actualizado. La caducidad ocurre porque en este momento, el servidor secundario debe tener en cuenta sus datos locales no confiables. El valor predeterminado es 86.400 segundos (24 horas).

TTL mínimo (predeterminado)

El valor predeterminado Time-To-Live (TTL) de la zona y el intervalo máximo de almacenamiento en caché negativo las respuestas a consultas de nombres. El valor predeterminado es de 3.600 segundos (1 hora).

El siguiente es un ejemplo de un registro de recursos SOA predeterminado:



@ EN SOA nameserver.example.microsoft.com.

postmaster.example.Microsoft.com.

(                               1            ;número de serie 3600;actualizar [1 h] 600;Reintentar [10 m] 86400;caducar [1D] 3600);TTL mínimo [1 h]

En el registro SOA de ejemplo anterior, el servidor de origen o principal de la zona se muestra como nameserver.example.microsoft.com. La dirección de correo electrónico de la persona de contacto preguntas acerca de esta zona es postmaster.example.microsoft.com.

Períodos se utilizan para representar direcciones de correo electrónico al escribir y almacenar nombres de dominio DNS en una zona. En una aplicación de correo electrónico, la dirección del ejemplo anterior podría aparecer como postmaster@example.microsoft.com. Los paréntesis utilizados en el registro de recursos SOA tal y como aparece en un archivo de zona se utilizan para habilitar el ajuste del registro a través de varias líneas de texto. Si se asigna un valor TTL individual y se aplicado a un registro de recursos especificado que se utiliza en la zona, suplanta el TTL mínimo (predeterminado) establecido en el registro SOA.

Registro de recursos NS

Registros de recursos de nombres (NS) del servidor pueden utilizarse para asignar autoridad a servidores especificados para un nombre de dominio DNS de dos maneras:

  • Mediante el establecimiento de una lista de servidores autorizados para el dominio para que los servidores puedan darse a conocer a otras personas que soliciten información acerca de este dominio (zona).

  • Por lo que indica los servidores DNS autorizados para cualquier subdominio que se delegue fuera de la zona.

En el caso de asignación de servidores con nombres de host en la misma zona, normalmente se utilizan registros de recursos de dirección (A) correspondiente en la zona para resolver los nombres de los servidores especificados en sus direcciones IP. Los servidores que se especifican mediante este RR como parte de una delegación de zona a un subdominio, el registro de recursos NS normalmente contiene nombres de la zona. Para que resolver los nombres de fuera de la zona, registros de recursos para el servidor fuera de la zona especificado pueden ser necesaria. Cuando estos NS de fuera de la zona y registros son necesarios para la delegación, se conocen como registros de adherencia.

En la tabla siguiente muestra la sintaxis básica de cómo se utiliza un RR de NS.

Sintaxis básica de un registro de recursos NS

Descripción: Se utiliza para asignar un nombre de dominio DNS especificado en el propietario en el nombre de hosts que funcionan los servidores DNS especificados en el campo de nombreServidorNombreDominio .

Sintaxis: propietario ttl IN NS nombreServidorNombreDominio.

Ejemplo:

example.microsoft.com.    IN NS nameserver1.example.microsoft.com

Otros registros importantes

Después de crea una zona, deben agregarse los registros de recursos adicionales a ella. La tabla siguiente muestra los registros de recursos (RR) para agregar más comunes.

Registros de recursos DNS comunes

Registro de recursos Descripción

Host (A)

Para la asignación de un nombre de dominio DNS a una dirección IP utilizado por un equipo.

Alias (CNAME)

Para asignar un nombre de dominio DNS de alias a otro nombre canónico o principal.

Intercambiador de correo (MX)

Para asignar un nombre de dominio DNS para el nombre de un equipo que intercambia o reenvía correo.

Puntero (PTR)

Para la asignación de un nombre de dominio DNS basado en la dirección IP de un equipo que apunta al nombre de dominio DNS directo de ese equipo.

Ubicación de servicio (SRV)

Para asignar un nombre de dominio DNS a una lista especificada de DNS alojar los equipos que ofrecen un tipo específico de servicio, como controladores de dominio de Active Directory.

Registros de recursos de host (A)

Registros de recursos de host (A) se utilizan en una zona para asociar los nombres de dominio DNS de equipos (o hosts) a sus direcciones IP. Registros de recursos de host (A) se pueden agregar manualmente. Los servidores y clientes de Windows también pueden utilizar el servicio cliente DHCP para registrar y actualizar dinámicamente sus propios registros de recursos en DNS cuando ocurre un cambio de configuración de IP. Los equipos cliente DHCP que ejecutan versiones anteriores de sistemas operativos Windows pueden tener sus registros de recursos registre y actualice proxy si obtienen su concesión de IP de un servidor DHCP calificado.

El registro de recursos de host (A) no es necesario para todos los equipos, pero es necesario para los equipos que comparten recursos en una red. Cualquier equipo que comparte recursos y debe identificarse por su nombre de dominio DNS, debe utilizar un recurso de registros para proporcionar DNS el nombre de resolución a la dirección IP del equipo.

La mayoría de los RR a necesarios en una zona puede incluir otras estaciones de trabajo o servidores que comparten recursos, otros servidores DNS, servidores de correo y servidores Web. Estos registros de recursos forman la mayoría de los registros de recursos en una base de datos de zona.

Registros de recursos de alias (CNAME)

Registros de recursos de alias (CNAME) también se denominan nombres canónicos. Estos registros permiten utilizar más de un nombre para señalar a un único host, lo que facilita realizar operaciones tales como host de 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 se asignan al nombre de host DNS, como "servidor-1" para el equipo servidor que aloja estos servicios.

Se recomiendan los RR CNAME para su uso en los siguientes escenarios:

  • Cuando un host especificado en un RR en la misma zona necesita cambiarse.

  • Cuando un nombre genérico de un servidor conocido como www necesita resolver a un grupo de equipos individuales (cada uno con RR A individuales) que proporciona el mismo servicio. Un ejemplo sería un grupo de servidores Web redundantes.

Al cambiar el nombre de un equipo con un RR en la zona existente, puede utilizar un RR CNAME temporalmente, para permitir un período de gracia para los usuarios y programas de especificar el nombre de equipo antiguo y usen el nuevo. Para ello, necesitará lo siguiente:

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

  • El antiguo nombre de dominio DNS, se agrega un RR CNAME que señala al RR a nuevo.

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

Cuando utilice un RR CNAME para cambiar el nombre o un equipo, establecer un límite temporal en cuánto tiempo se utiliza el registro en la zona antes de quitarlo de DNS. Si olvida eliminar el RR CNAME y posteriormente su asociado se elimina un registro de recursos, 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 de un RR CNAME es proporcionar un nombre de dominio de alias DNS permanente para la resolución de nombre genérico de un nombre de servicio, como www.example.microsoft.com, a más de un equipo o una dirección IP utilizada en un servidor Web. Por ejemplo, la siguiente muestra la sintaxis básica de cómo se utiliza un RR CNAME.




nombre_alias EN CNAME primary_canonical_name


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




host-a en un 10.0.0.20



CNAME en un host de FTP



www CNAME en host-a


Si posteriormente decide trasladar el servidor FTP a otro equipo, independiente del servidor Web en el "host-a", simplemente cambie el RR CNAME en la zona de ftp.example."Microsoft.com"y agregar un RR a adicional a la zona para el nuevo equipo que aloja el servidor FTP.

Basado en el ejemplo anterior, si el nuevo equipo se denomina "host-b.ejemplo.Microsoft.com", las nuevas y revisadas RR CNAME y sería como sigue:




host-a en un 10.0.0.20



host-b en un 10.0.0.21



FTP CNAME en host-b



www CNAME en host-a


Intercambiador de correo registros de recursos (MX)

El intercambiador de correo (MX) RR se utiliza por las aplicaciones de correo electrónico para localizar un servidor de correo basado en un nombre de dominio DNS utilizado en la dirección de destino para el destinatario de correo electrónico de un mensaje. Por ejemplo, una consulta DNS para el nombre ejemplo.Microsoft.com podría utilizarse para buscar un RR MX y habilitar una aplicación de correo electrónico para reenviar o intercambiar correo electrónico a un usuario con usuario@Microsoft.com de dirección de correo electrónico.

El RR MX muestra el nombre de dominio DNS para el equipo o equipos que procesan el correo de un dominio. Si existen varios RR MX, el servicio cliente DNS intenta ponerse en contacto con servidores de correo en el orden de preferencia del valor más bajo (prioridad más alta) al valor más alto (prioridad más baja). La siguiente muestra la sintaxis básica para el uso de un RR MX.




preferencia de MX en mail_domain_name hostServidorDeCorreo


Mediante el uso de los RR MX se muestra a continuación, en la zona example.microsoft.com, correo dirigido a user@example.microsoft.com se entrega a user@mailserver0.example.microsoft.com en primer lugar, si es posible. Si este servidor no está disponible, el cliente de resolución puede, a continuación, utilice user@mailserver1.example.microsoft.com.




@ EN MX 1 mailserver0



@ EN 2 MX mailserver1


El uso de la arroba (@) en los registros indica que el nombre de dominio DNS mailer es el mismo que el nombre de origen (example.microsoft.com) para la zona.

Registros de recursos de puntero (PTR)

Los registros de recursos de puntero (PTR) se utilizan para apoyar el proceso de búsqueda inversa, basándose en las 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 para ese equipo.

Los RR PTR pueden agregarse a una zona de varias maneras:

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

  • Equipos utilizan el servicio cliente DHCP para registrar y actualizar dinámicamente sus RR PTR en DNS cuando ocurre un cambio de configuración de IP.

  • Todos los demás equipos cliente habilitados para DHCP pueden tener sus RR PTR registre y actualice el servidor DHCP si obtienen su concesión de IP de un servidor calificado.

El registro de recursos de puntero (PTR) se utiliza sólo en las zonas de búsqueda inversa para admitir la búsqueda inversa.

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

Para localizar los controladores de dominio de Active Directory, la ubicación de servicio (SRV) se necesitan RR. Normalmente, puede evitar la administración manual del RR SRV al instalar AD DS.

De forma predeterminada, los intentos de Asistente para instalación de Active Directory para localizar un servidor DNS basado en la lista de servidores DNS preferidos o alternativos, configurada en cualquiera de sus propiedades de cliente TCP/IP, para cualquiera de sus conexiones de red activa. Si se estableció contacto con un servidor DNS que puede aceptar actualizaciones dinámicas de los RR de SRV (y otros RR relacionados con el registro de Active Directory como un servicio en DNS), el proceso de configuración es completado.

Si, durante la instalación, un servidor DNS que pueda aceptar actualizaciones para el nombre de dominio DNS utilizado con nombre que no se encuentra Active Directory, el asistente puede instalar a un servidor DNS localmente y automáticamente configurar con una zona para admitir el dominio de Active Directory.

Por ejemplo, si el dominio de Active Directory que eligió para el primer dominio del bosque era ejemplo.Microsoft.com, una zona cuya raíz está en el nombre de dominio DNS de example.microsoft.com se sería agregada y configurada para utilizar el servidor DNS que se ejecutan en el nuevo controlador de dominio.

O no instalar el servicio de servidor DNS localmente, un archivo (Netlogon.dns) está escrito y creado durante el proceso de instalación de AD DS que contiene los RR de SRV y otros RR necesarios para admitir el uso de AD DS. Este archivo se crea en la carpeta systemroot\System32\Config.

Si utiliza un servidor DNS que se ajusta a una de las siguientes descripciones, debe utilizar los registros de Netlogon.dns para configurar manualmente la zona principal en ese servidor para admitir AD DS.

  • El equipo que funciona el servidor DNS se está ejecutando en otra plataforma, como, por ejemplo, UNIX y no puede aceptar o reconocer actualizaciones dinámicas.

  • Un servidor DNS en este equipo que no es el servicio de servidor DNS proporcionado con el sistema operativo Windows Server 2008 está autorizado para la zona principal correspondiente al nombre de dominio DNS para el dominio de Active Directory.

  • El servidor DNS admite el RR de SRV, como se define en el borrador de Internet "A DNS RR specifying the location of services DNS SRV", pero no admite actualizaciones dinámicas. Por ejemplo, el servicio de servidor DNS proporcionado con Windows NT Server 4.0, cuando se actualiza al Service Pack 4 o posterior, se ajusta a esta descripción.

En el futuro, el RR de SRV podría utilizarse también para registrar y buscar otros servicios TCP/IP muy conocidos en la red si las aplicaciones implementan y admiten consultas de nombres DNS que especifican este tipo de registro.

Otros registros de recursos son compatibles con DNS de Windows Server 2008 y se utilizan con menos frecuencia en la mayoría de las zonas. Estos tipos de registros de recursos adicionales se pueden agregar según sea necesario mediante la consola DNS. Para obtener más información acerca de los registros de recursos admitidos, consulte Información de referencia DNS .

Archivos relacionados con DNS

Los archivos siguientes se refieren al uso y configuración de clientes y servidores DNS.

Archivo Descripción

Inicio

Archivo de configuración de inicio de BIND. Este archivo no es creado por la consola DNS. Sin embargo, como una configuración opcional para el servicio servidor DNS, se puede copiar de otro servidor DNS con la implementación de DNS server de Berkeley Internet Name Domain (BIND). Para utilizar este archivo con el servicio servidor DNS, deberá hacer clic en desde archivo en las propiedades del servidor. En los servidores BIND, este archivo se denomina a menudo el archivo "como named.boot".

Cache.DNS

Se utiliza para cargar los registros de recursos en la caché de nombres de servidor DNS. Los servidores DNS utilizan este archivo para ayudar a localizar los servidores raíz de la red o Internet.

De forma predeterminada, este archivo contiene registros de recursos DNS que preparan la caché local del servidor con las direcciones de servidores raíz autorizados para Internet. Si está configurando un servidor DNS para resolver nombres DNS de Internet, la información de este archivo es necesaria a menos que habilite el uso de otro servidor DNS como reenviador para resolver estos nombres.

Tráfico a los servidores raíz de Internet es denso, pero debido a que los nombres de host no se resuelven normalmente en este nivel, la carga puede controlarse. En su lugar, el archivo de sugerencias de raíz proporciona información de referencia que puede ser útil durante la resolución de nombres DNS para redirigir una consulta a otros servidores que están autorizados para nombres localizados por debajo de la raíz.

Los servidores DNS funcionan de forma privada en la red interna, la consola DNS puede aprender y reemplazar el contenido de este archivo con servidores raíz internos en la red, siempre que sean alcanzables a través de la red cuando instale y configure los nuevos servidores DNS. Se puede actualizar mediante la consola DNS desde la ficha de Sugerencias de raíz que se encuentra en las propiedades de servidor correspondiente.

Este archivo se carga previamente la caché de nombres de servidor cuando se inicia.

Root.DNS

Archivo de zona raíz. Este archivo puede aparecer en un servidor DNS si está configurado como servidor raíz para la red.

nombreZona.dns

Se utiliza cuando se agrega una zona estándar (principal o secundaria) y se configura para el servidor. Archivos de este tipo no se crean o se utiliza para las zonas de tipo principal integradas en directorio, que se almacenan en la base de datos de Active Directory.

Estos archivos pueden encontrarse en la carpeta raízSistema\System32\Dns en el equipo servidor.

Las zonas y transferencia de zona

DNS distribuye la base de datos del espacio de nombres DNS mediante las zonas DNS, que almacenan información de nombre de uno o más dominios DNS. Hay tres tipos de zonas DNS de Windows Server 2008 admite:

  • Zona principal. Copia original de una zona donde se agregan todos los registros de recursos, modificado y eliminado.

  • Zona secundaria. Copia de sólo lectura de la zona principal que se crea y se actualiza mediante la transferencia de datos de zona desde la zona primaria.

  • Zona de código auxiliar. Copia de sólo lectura de la zona principal que contiene sólo los registros de recursos DNS para los servidores DNS mostrados en la zona (SOA, NS y registros de recursos de adherencia).

Diferencia entre zonas y dominios

Una zona comienza como una base de datos de almacenamiento de información para un único nombre de dominio DNS. Si se agregan otros dominios bajo el dominio utilizado para crear la zona, estos dominios pueden formar parte de la misma zona o pertenecer a otra zona. Después de agrega un subdominio, se puede ser administrado y incluido como parte de los registros de zona original o delegarse a otra zona creada para admitir el subdominio.

Por ejemplo, la siguiente figura muestra el dominio microsoft.com, que contiene los nombres de dominio para Microsoft. Cuando el dominio microsoft.com se crea en un único servidor, se configura como una sola zona para todo el espacio de nombres DNS de Microsoft. Si, sin embargo, el dominio microsoft.com tiene que utilizar subdominios, estos subdominios deben ser incluidos en la zona o delegarse a otra zona.

Nombres de dominio DNS y nombres de subdominio

DNS Domain Names and Subdomain Names

En este ejemplo, el dominio example.microsoft.com muestra un subdominio nuevo, el dominio example.microsoft.com, delegado fuera de la zona microsoft.com y administrado en su propia zona. Sin embargo, la zona microsoft.com debe contener algunos registros de recursos para proporcionar la información de delegación que hace referencia a los servidores DNS que tienen autoridad para el subdominio delegado example.microsoft.com.

Si la zona microsoft.com no usa la delegación para un subdominio, los datos del subdominio sigue formando parte de la zona microsoft.com. Por ejemplo, el subdominio dev.microsoft.com no está delegado, pero es administrado por la zona microsoft.com.

¿Por qué se necesitan las transferencias de zona y replicación de zona

Debido al importante papel que desempeñan las zonas en DNS, se pretende que estén disponibles desde más de un servidor DNS en la red, para proporcionar disponibilidad y tolerancia a errores al resolver consultas de nombres. De lo contrario, si se utiliza un único servidor y éste no responde, las consultas de nombres en la zona pueden fallar. Para que otros servidores alojen una zona, las transferencias de zona son necesarias para replicar y sincronizar todas las copias de la zona utilizada en cada servidor configurado para alojar la zona.

Cuando un nuevo servidor DNS se agrega a la red y se configura como un nuevo servidor secundario en una zona existente, realiza una transferencia inicial completa de la zona para obtener y replicar una copia completa de registros de recursos de la zona. La mayoría de implementaciones anteriores de servidores DNS, este mismo método de transferencia completa de una zona también se utiliza cuando la zona requiere actualizarse después de que se realizan cambios en la zona. Los servidores DNS que ejecutan Windows Server 2008, el servicio DNS admite la transferencia de zona incremental, un proceso de transferencia de zona DNS revisado para cambios intermedios.

Delegación de dominio

Un nombre de dominio subordinado, o un subdominio, se puede delegar desde la zona DNS donde se almacena su nombre de principal a una zona en otro servidor DNS. Al decidir si desea delegar el espacio de nombres DNS para crear zonas adicionales, tenga en cuenta las siguientes razones para utilizar zonas adicionales:

  • Necesidad de delegar la administración de parte del espacio de nombres DNS a otra ubicación o departamento dentro de su organización.

  • Necesidad de dividir una zona de gran tamaño en zonas más pequeñas para distribuir la carga de tráfico entre varios servidores.

  • Necesidad de ampliar el espacio de nombres al agregar numerosos subdominios a la vez, por ejemplo, para admitir la apertura de una nueva sucursal o sitio.

Si por alguna de estas razones, podrían beneficiarse de la delegación de nombres de dominio subordinado a zonas adicionales, puede que tenga sentido reestructurar el espacio de nombres agregando zonas. Cuando elija cómo estructurar las zonas, debe utilizar un plan que refleje la estructura de la organización.

Al delegar zonas dentro del espacio de nombres, tenga en cuenta que para cada nueva zona que cree, necesitará registros de delegación en otras zonas que apunten a los servidores DNS autorizados para la nueva zona. Esto es necesario para transferir la autoridad y proporcionar referencias correctas a otros servidores DNS y clientes de los nuevos servidores que se autorizan para la nueva zona.

Cuando se crea una zona principal estándar, se almacena como un archivo de texto que contiene todos los recursos registrar información sobre un único servidor DNS. Este servidor actúa como maestro principal en la zona. Información de zona puede replicarse a otros servidores DNS para mejorar el rendimiento de servidor y de tolerancia de errores.

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

  • Servidores DNS adicionales proporcionan redundancia de zona, lo que permite nombres DNS en la zona se resuelvan para los clientes si un servidor principal de la zona deja de responder.

  • Se pueden colocar servidores DNS adicionales para reducir el tráfico de red DNS. Por ejemplo, agregar un DNS server en el lado opuesto de un vínculo (WAN) de red de área extensa de baja velocidad puede ser útil para administrar y reducir el tráfico de red.

  • Los otros servidores DNS secundarios pueden utilizarse para reducir la carga en un servidor principal de una zona.

Ejemplo: Delegar un subdominio a una zona nueva

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

Delegar un subdominio

Delegating a Subdomain

En este ejemplo, un equipo de servidor DNS autorizado para el subdominio example.microsoft.com recién delegado se denomina basado en un subdominio derivado incluido en la zona nueva (ns1.na.example.microsoft.com). Para que este servidor conocido a otras personas fuera de la zona delegada, se necesitan dos RR en la zona microsoft.com para completar la delegación a la nueva zona:

  • Un RR NS para anunciar que el servidor denominado ns1.na.example.microsoft.com es un servidor autorizado para el subdominio delegado.

  • Un RR (también conocido como un registro de adherencia) para resolver el nombre del servidor especificado en el RR NS a su dirección IP. El proceso de resolver el nombre de host en este RR al servidor DNS delegado en el RR NS a veces se conoce como adherencia.

    Dd197495.note(es-es,WS.10).gif Nota
    Cuando las delegaciones de zona se configuran correctamente, la forma de referencia de zona normal puede a veces evitarse si está utilizando reenviadores en la configuración del servidor DNS. Para obtener más información, consulte "Reenvío" en Procesos DNS y las interacciones .

Transferencias de zona incrementales

Las transferencias de zona incremental se describen en el documento RFC 1995 como un estándar DNS adicional para replicar zonas DNS. Cuando un servidor DNS que actúa como el origen de una zona y los servidores que copian la zona de él admiten transferencias incrementales, la transferencia incremental proporciona un método más eficiente de propagación de actualizaciones y cambios en la zona.

En las implementaciones DNS anteriores, cualquier solicitud de actualización de datos de zona requería a una transferencia completa de la base de datos de zona completa mediante una consulta AXFR. Con la transferencia incremental, puede utilizarse en su lugar un tipo de consulta alternativo (IXFR). Esto permite al servidor secundario extraer sólo los cambios de zona que necesita para sincronizar su copia de la zona con su origen, ya sea una copia primaria o secundaria de la zona que mantiene otro servidor DNS.

Con las transferencias de zona IXFR, primero se determinan las diferencias entre el origen y las versiones replicadas de la zona. Si las zonas se identifican en la misma versión, como se indica en el campo de número de serie en el registro de recursos SOA de cada zona, se realiza ninguna transferencia.

Si el número de serie para la zona de origen es mayor que en el servidor secundario solicitante, se realiza una transferencia de sólo los cambios a los registros de recursos para cada versión incremental de la zona. Para que una consulta IXFR correcta y enviar los cambios, el servidor DNS de origen para la zona debe mantener un historial de cambios de zona incrementales para utilizarlo al responder a estas consultas. El proceso de transferencia incremental requiere bastante menos tráfico en una red y las transferencias de zona se completan mucho más rápido.

Ejemplo: Transferencia de zona

Una transferencia de zona puede ocurrir en cualquiera de los siguientes escenarios:

  • Caduca el intervalo de actualización de la zona.

  • Cuando un servidor secundario se notifica los cambios de zona por su servidor principal.

  • Cuando se inicia el servicio servidor DNS en un servidor secundario de la zona.

  • Cuando se utiliza la consola DNS en un servidor secundario de la zona para iniciar manualmente una transferencia de su servidor principal.

Solicitudes de transferencia de zona son siempre se inician en el servidor secundario para una zona y, a continuación, se envía a sus servidores maestros configurados que actúan como origen para la zona. Los servidores maestros pueden ser cualquier otro servidor DNS que carga la zona, como, por ejemplo, el servidor principal de la zona u otro servidor secundario. Cuando el servidor maestro recibe la solicitud para la zona, puede responder con cualquiera una transferencia parcial o completa de la zona al servidor secundario.

Proceso de transferencia de zona

Como se muestra en la siguiente figura, las transferencias de zona entre servidores siguen un proceso ordenado. Este proceso varía, dependiendo de si una zona se ha replicado anteriormente o si inicial replicación de una zona nueva se está realizando.

Proceso de transferencia de zona

Zone Transfer Process
  1. Durante la nueva configuración, el servidor de destino envía a una transferencia inicial "toda la zona" (AXFR) solicitud al servidor DNS principal configurado como su origen para la zona.

  2. El servidor maestro (origen) responde y transfiere toda la zona al servidor secundario (destino).

    La zona se entrega al servidor de destino que solicita a la transferencia con su versión establecida mediante el uso de un campo de número de serie en las propiedades de los RR de inicio de autoridad. El RR SOA también contiene un intervalo de actualización expresado en segundos (de forma predeterminada, 900 segundos o 15 minutos) para indicar cuando el servidor de destino debe siguiente solicitud para renovar la zona con el servidor de origen.

  3. Cuando caduca el intervalo de actualización, una consulta SOA se utiliza el servidor de destino para solicitar la renovación de la zona desde el servidor de origen.

  4. El servidor de origen responde a la consulta para su registro SOA.

    Esta respuesta contiene el número de serie para la zona en su estado actual en el servidor de origen.

    El servidor de destino comprueba el número de serie del registro SOA en la respuesta y determina cómo renovar la zona.

    Si el valor del número de serie en la respuesta SOA es igual a su número de serie local actual, se deduce que la zona es el mismo en ambos servidores y que no es necesaria una transferencia de zona. El servidor de destino, a continuación, renueva la zona y restablece su intervalo de actualización según el valor de este campo en la respuesta SOA de su servidor de origen.

    Si el valor del número de serie en la respuesta de inicio de autoridad es mayor que su número de serie local actual, se deduce que la zona se ha actualizado y que se requiere una transferencia.

  5. Si el servidor de destino deduce que la zona ha cambiado, envía una consulta IXFR al servidor de origen, que contiene su valor local actual para el número de serie en el registro SOA de la zona.

  6. El servidor de origen responde con una transferencia incremental o completa de la zona.

    Si el servidor de origen admite la transferencia incremental y mantiene un historial de cambios de zona incrementales recientes para registros de recursos modificados, puede responder con una IXFR de la zona.

    Si el servidor de origen no admite la transferencia incremental o no tiene un historial de cambios de zona, puede responder con una transferencia (completa AXFR) completa de la zona.

    Dd197495.note(es-es,WS.10).gif Nota
    Servidores que ejecutan Windows Server 2008 y Windows Server 2003, se admite la transferencia de zona incremental a través de consultas IXFR. Para versiones anteriores del servicio DNS y muchas otras implementaciones de servidor DNS, transferencia de zona incremental no está disponibles y sólo toda la zona consultas (AXFR) y las transferencias se utilizan para replicar zonas.

Notificación DNS

Windows-based DNS servers support DNS Notify, an update to the original DNS protocol specification that permits a means of initiating notification to secondary servers when zone changes occur (RFC 1996). DNS notification implements a push mechanism for notifying a select set of secondary servers for a zone when the zone is updated. Servers that are notified can then initiate a zone transfer as described above, to pull zone changes from their master servers and update their local replicas of the zone.

For secondaries to be notified by the DNS server acting as their configured source for a zone, each secondary server must first have its IP address in the notify list of the source server. When using the DNS console, this list is maintained in the Notify dialog box, which is accessible from the Zone Transfer tab located in zone Properties.

In addition to notifying the listed servers, the DNS console permits you to use the contents of the notify list as a means to restrict or limit zone transfer access to only those secondary servers specified in the list. This can help prevent an undesired attempt by an unknown or unapproved DNS server to pull, or request, zone updates.

DNS notification process

The following is a brief summary of the typical DNS notification process for zone updates:

  • The local zone at a DNS server acting as a master server, a source for the zone to other servers, is updated. When the zone is updated at the master or source server, the serial number field in the SOA RR is also updated, indicating a new local version of the zone.

  • The master server sends a DNS notify message to other servers that are part of its configured notify list.

  • All secondary servers that receive the notify message can then respond by initiating a zone transfer request back to the notifying master server.

The normal zone transfer process can then continue as described in the previous section.

You cannot configure a notify list for a stub zone.

Use DNS notification only to notify servers operating as secondary servers for a zone. For replication of directory-integrated zones, DNS notification is not required. This is because any DNS servers that load a zone from AD DS automatically poll the directory (as specified by the SOA resource record’s refresh interval) to update and refresh the zone. In these cases, configuring a notify list can actually degrade system performance by causing unnecessary additional transfer requests for the updated zone.

Dd197495.note(es-es,WS.10).gif Note
By default, the Windows Server 2008 DNS Server service will only allow a zone transfer to authoritative DNS servers listed in the name server (NS) resource records for the zone.

Stub zones

A stub zone is a copy of a zone that contains only those resource records required to identify the authoritative DNS servers for that zone. A stub zone is used to resolve names between separate DNS namespaces. The need for this type of resolution can occur when a corporate merger requires that the DNS servers for two separate DNS namespaces resolve names for clients in both namespaces.

A stub zone consists of:

  • The SOA resource record, NS resource records, and the glue A resource records for the delegated zone.

  • The IP address of one or more master servers that can be used to update the stub zone.

The master servers for a stub zone are one or more DNS servers authoritative for the child zone, usually the DNS server hosting the primary zone for the delegated domain name.

Stub zone resolution

When a DNS client performs a recursive query operation on a DNS server hosting a stub zone, the DNS server uses the resource records in the stub zone to resolve the query. The DNS server sends an iterative query to the authoritative DNS servers specified in the NS resource records of the stub zone as if it were using NS resource records in its cache. If the DNS server cannot find the authoritative DNS servers in its stub zone, the DNS server hosting the stub zone attempts standard recursion using its root hints.

The DNS server will store the resource records it receives from the authoritative DNS servers listed in a stub zone in its cache, but it will not store these resource records in the stub zone itself; only the SOA, NS, and glue A resource records returned in response to the query are stored in the stub zone. The resource records stored in the cache are cached according to the TTL value in each resource record. The SOA, NS, and glue A resource records, which are not written to cache, expire according to the expire interval specified in the stub zone’s SOA record, which is created during the creation of the stub zone and updated during transfers to the stub zone from the original, primary zone.

If the query was an iterative query, the DNS server returns a referral containing the servers specified in the stub zone.

Stub zone updates

Stub zone updates involve the following conditions:

  • When a DNS server loads a stub zone, it queries the zone’s master server for the SOA resource record, NS resource records at the zone’s root, and glue A resource records.

  • During updates to the stub zone, the master server is queried by the DNS server hosting the stub zone for the same resource record types requested during the loading of the stub zone.

  • The refresh interval of the SOA resource record determines when the DNS server hosting the stub zone will attempt a zone transfer (update).

  • If an update fails, the retry interval of the SOA resource record determines when the update is retried.

  • After the retry interval has expired without a successful update, the expiration time, as specified in the Expires field of the SOA RR, determines when the DNS server stops using the stub zone data.

Root hints

Root hints are used to prepare servers authoritative for non-root zones so that they can learn and discover authoritative servers that manage domains located at a higher level or in other subtrees of the DNS domain namespace. These hints are essential for servers authoritative at lower levels of the namespace when locating and finding servers under these conditions.

For example, suppose a DNS server (Server A) has a zone called sub.example.microsoft.com. In the process of answering a query for a higher-level domain, such as the example.microsoft.com domain, Server A needs some assistance to locate an authoritative server (such as Server B) for this domain.

In order for Server A to find Server B, or any other servers that are authoritative for the microsoft.com domain, it needs to be able to query the root servers for the DNS namespace. The root servers can then refer Server A to the authoritative servers for the com domain. The servers for the com domain can, in turn, offer referral to Server B or other servers that are authoritative for the microsoft.com domain.

The root hints used by Server A must have helpful hints to the root servers for this process to locate Server B (or another authoritative server) as intended.

To configure and use root hints correctly, first determine how the following applies to your DNS servers:

  • Are you using DNS on the Internet or on a private network?

  • Is the server used as a root server?

By default, the DNS Server service implements root hints using a file, Cache.dns, stored in the systemroot\System32\Dns folder on the server computer. This file normally contains the NS and A resource records for the Internet root servers. If, however, you are using the DNS Server service on a private network, you can edit or replace this file with similar records that point to your own internal root DNS servers.

Another server configuration in which root hints are treated differently is one in which a DNS server is configured to be used by other DNS servers in an internal namespace as a forwarder for any DNS queries of names managed externally (the Internet, for example). Even though the DNS server used as a forwarder can be located internally on the same network as servers using it as a forwarder, it needs hints for the Internet root servers to work properly and resolve external names.

Dd197495.note(es-es,WS.10).gif Note
If you are operating internal root servers, do not use root hints. Instead, delete the Cache.dns file for any of your root servers.

EDNS0

Extension Mechanisms for DNS (EDNS0, as defined in RFC 2671) allow DNS requestors to advertise the size of their UDP packets and facilitate the transfer of packets larger than 512 octets, the original DNS restriction for UDP packet size (RFC 1035). When a DNS server receives a request over the UDP transport layer, it identifies the requestor’s UDP packet size from the option (OPT) RR and scales its response to contain as many resource records as are allowed in the maximum UDP packet size specified by the requestor.

In Windows Server 2008, DNS support for EDNS0 is enabled by default. It can be disabled using the registry. Locate the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters

Add the entry EnableEDNSProbes to the subkey. Give the entry a DWORD value and set it to 0x0 to disable EDNS0.

Use extreme caution when editing the registry. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system.

For more information about resource records, see DNS Reference Information .

ENDS0 UDP responses

Before a DNS server assumes that the requestor supports EDNS0, the DNS server must receive a query containing an OPT resource record. An OPT record contains no actual DNS data and its contents relate to the UDP transport layer message only. The OPT record stores the sender’s UDP payload size in its CLASS field and lists the number of octets in the largest UDP payload that the requestor can deliver in the requestor’s network.

When the DNS server receives a query containing an OPT record advertising the maximum UDP packet size, it will truncate any UDP response’s size larger than the limit specified in the OPT record.

By default, the DNS server includes OPT resource records indicating its UDP maximum in responses to queries containing OPT resource records.

If the DNS server receives a query that does not contain an OPT resource record, it assumes the requestor’s server does not support EDNS0 and will respond to the requestor assuming that the sender does not accept UDP packets larger than 512 octets. In this case, the DNS server will truncate its UDP response size to a maximum of 512 octets.

EDNS0 UDP queries

Before the requesting DNS server sends a query, it checks its cache to identify if the responding DNS server supports EDNS0. If the responding DNS server supports EDNS0, the requesting DNS server attaches an OPT resource record to the additional section of the query it sends. (All queries have five sections: header, question, answer, authority, and additional.) If, according to the requesting DNS server’s cache, the responding DNS server does not support EDNS0, the requesting DNS server will not attach an OPT resource record to the query before it is sent.

Identifying and caching EDNS0 support

When the DNS server receives a request or response from a host containing an OPT record, the DNS server caches the EDNS version supported by the host (such as EDNS0). If there is no OPT record in a request or response from a host, the DNS server’s cache will indicate that the host does not support EDNS0. If the cache already indicates that the host supports ENDS0, then cache will not be changed.

The default value for how long a host’s EDNS0 support information is cached is 86400 (one day, specified in seconds). This value can be modified in the registry.

The DNS server determines that a host does not support EDNS0 when it requests an OPT resource record and receives a response containing one of the following response code (RCODE) values in the header, as shown in the following table.

EDNS0 failure code values

Name Value Description

FORMERR

1

Format Error. The name server did not interpret the OPT resource record.

SERVFAIL

2

Server Failure. The name server did not process the query because of a problem with the name server.

NOTIMPL

4

Not Implemented. The name server does not support the kind of query requested.

(The RCODE field is a 4-bit field set in the header section as part of responses.) In this situation (as a requester), the DNS server determines that the server does not support EDNS0 and caches this information.

Dd197495.note(es-es,WS.10).gif Note
When considering packet sizes, you should take account of the network transmission path’s discovered Maximum Transmission Unit (MTU), if this information is available. When configuring the UDP packet size to be larger than 512 octets, remember that the UDP packets must travel through devices other than UDP hosts and these devices, such as routers, might not support UDP packets larger than 512 octets. The maximum UDP packet size should always be compared with the MTU, which in some cases might be smaller. It is recommended that you establish the maximum UDP packet length support for all devices, and configure your UDP hosts for this maximum.

DNSSEC

Windows Server 2008 DNS provides basic support of the DNS Security Extensions (DNSSEC) protocol, as defined in RFC 2535. The current feature support allows DNS servers to perform as secondary DNS servers for existing DNSSEC–compliant, secure zones. DNS supports the storing and loading of the DNSSEC-specific resource records. Currently, a DNS server is not capable of signing zones and resource records (creating cryptographic digital signatures) or validating the SIG RRs. The DNSSEC resource records are KEY, SIG, and NXT. For more information about resource records, see DNS Reference Information .

Server support for DNSSEC

When loading a zone containing DNSSEC resource records, the DNS server loads these records along with all other types of resource records contained in the zone. When receiving a zone transfer containing DNSSEC resource records (SIG, KEY, NXT), the DNS server writes these records to the zone storage (zone data file or Active Directory database) along with all other resource records.

When a DNS server receives a request or response containing DNSSEC resource records, it does not verify the digital signatures, but caches the response and uses it for ensuing queries. When a DNS server receives a request for a resource record in a zone also containing DNSSEC resource records, it attaches the appropriate DNSSEC records to the response.

When a signed zone contains resource records for an owner name, including a CNAME resource record for that name, the DNS server will return the DNSSEC resource records associated with the owner name and the CNAME resource record’s alias name. The DNS server will not suppress the retrieval of the CNAME resource record, and it will not return a SIG resource record for the canonical name. Rather, it will return the SIG resource record for the alias name.

Client support for DNSSEC

The DNS client does not read and store a key for the trusted zone and, consequently, it does not perform any cryptography, authentication, or verification. When a resolver initiates a DNS query and the response contains DNSSEC resource records, programs running on the DNS client will return these records and cache them in the same manner as any other resource records. This is the extent to which DNS clients running Windows XP and Windows Vista support DNSSEC. Cuando el cliente DNS recibe el RR de SIG relativas al RRset, no realizará una consulta adicional para obtener el registro KEY asociado o cualquier otro registro DNSSEC.

Los interpretadores no autentican los registros de recursos mediante la comprobación de la información de firma contenida en el registro de recursos SIG. El cliente DNS no contiene ninguna información para indicar qué registros de recursos se han autenticado o en qué medida se han autenticado.

Cuando un interpretador recibe una respuesta o realiza una operación de consulta, no se reconoce la comprobación deshabilitada (CD) consulta encabezado bits, que en DNSSEC indica que los datos es autenticados por el servidor de acuerdo con sus políticas, ni establecer el bit de encabezado de consulta de datos auténticos, que en DNSSEC indica que los datos no autenticados están aceptables para la resolución.

Dd197495.note(es-es,WS.10).gif Nota
Si hay un agente de firma que se ejecutan en el servidor DNS que ejecutan Windows Server 2008 que firma los registros de recursos de la zona, este servidor DNS también puede utilizarse como servidor principal para zonas seguras compatibles con DNSSEC.

Integración con Active Directory

El servicio servidor DNS está integrado en el diseño e implementación de AD DS, que proporciona una herramienta de nivel empresarial para organizar, administrar y localizar recursos en una red.

Además de ser compatible con los métodos tradicionales para mantener y replicar archivos de zona DNS, la implementación de DNS en Windows Server 2008 tiene la opción de usar AD DS como el motor de almacenamiento y replicación de datos de DNS. DNS es el mecanismo de ubicación del controlador de dominio de AD DS.

Ventajas de integrar DNS con AD DS

Integración con Active Directory proporciona numerosas ventajas, como la tolerancia a errores, seguridad, administración simplificada y más eficaz replicación de zonas.

Con AD DS como el motor de almacenamiento y replicación de datos proporciona las siguientes ventajas:

  • Replicación de DNS se realiza por AD DS, así que no hay ninguna necesidad de apoyar una topología de replicación independiente para los servidores DNS.

  • Replicación de servicio de Active Directory proporciona replicación de cada propiedad.

  • Replicación de servicio de Active Directory es segura.

  • Se elimina un servidor DNS principal como un punto único de falla. La replicación DNS original es de maestro único y se basa en un servidor DNS principal para actualizar todos los servidores secundarios. A diferencia de la replicación DNS original, replicación del servicio de Active Directory es multimaster;se puede realizar una actualización en cualquier controlador de dominio en ella y el cambio se propagará a otros controladores de dominio. De este modo, si DNS está integrada en el servicio de Active Directory, el motor de replicación siempre sincronizará la información de zona DNS.

Así la integración de Active Directory simplifica significativamente la administración de un espacio de nombres DNS. Al mismo tiempo, aún se admiten las transferencias de zona estándar a otros servidores DNS (DNS servidores distintos, por ejemplo, Windows 2000 Server, Windows Server 2003 y Windows Server 2008 servidores DNS, así como las versiones anteriores de los servidores DNS de Microsoft).

¿Cómo se integra DNS con AD DS

Al instalar AD DS en un servidor, promover al servidor a la función de un controlador de dominio para un dominio especificado. Al completar este proceso, solicitará que especifique un nombre de dominio DNS para el dominio de Active Directory para el que va a unir y promocionar al servidor.

Dd197495.note(es-es,WS.10).gif Nota
Cuando se especifica el nombre de dominio DNS para el primer dominio de Active Directory del primer bosque de Active Directory, conocido como el dominio raíz del bosque, Windows Server 2008 no admite nombres de dominio de etiqueta única.

Si durante este proceso, un servidor DNS autorizado para el dominio especificado no se encuentra en la red o no admite el protocolo de actualización dinámica de DNS, se le ofrecerá la opción para instalar a un servidor DNS. Esta opción se proporciona porque se necesita un servidor DNS para localizar este servidor u otros controladores de dominio para miembros de un dominio de Active Directory.

Después de instalar AD DS, tiene dos opciones para almacenar y replicar las zonas cuando funciona con el servidor DNS en el nuevo controlador de dominio:

  • Almacenamiento de zona estándar, mediante un archivo de texto.

    Las zonas almacenadas de esta forma se encuentran en archivos de DNS que se almacenan en la carpeta raízSistema\System32\Dns en cada equipo que funciona con un servidor DNS. Los nombres de archivo de zona se corresponden con el nombre elegido para la zona cuando se crea, como "ejemplo.Microsoft.com.DNS" Si el nombre de zona "ejemplo.Microsoft.com."

  • Almacenamiento de zona integrada en directorio, mediante la base de datos de Active Directory.

    Las zonas almacenadas de esta forma se encuentran en el árbol de Active Directory en la partición de directorio de dominio o aplicación. Cada zona integrada en el directorio se almacena en un objeto de contenedor dnsZone identificado por el nombre elegido para la zona al crearlo.

Las zonas almacenadas en archivos de texto normalmente se conocen como zonas de seguridad de archivo y las zonas almacenadas en AD DS se conocen como las zonas integradas en Active Directory.

En DNS integradas en Active Directory, cada zona DNS se convierte en un objeto de contenedor de Active Directory (DnsZone). Este objeto contiene un objeto de hoja DnsNode para cada nombre único dentro de esa zona. El objeto DnsNode tiene un atributo multivalor de DnsRecord con una instancia de un valor para cada registro asociado con el nombre del objeto.

Dd197495.note(es-es,WS.10).gif Nota
Las zonas integradas en Active Directory sólo pueden cargarse en un controlador de dominio cuando se ejecuta el servicio servidor DNS de Windows Server 2008 en el controlador de dominio.

Modelo de replicación

Cuando se almacena información de zona DNS en AD DS y se realiza una actualización a un servidor DNS, escribe los datos de la actualización a AD DS. Ahora es responsable de replicar los datos a otros controladores de dominio AD DS. Los servidores DNS que se ejecutan en otros controladores de dominio sondean las actualizaciones de AD DS.

Como servicio de Active Directory utiliza el modelo de replicación con varios maestros, actualizaciones de DNS se pueden escribir en cualquier servidor DNS integrado en Active Directory y los datos se replican automáticamente en todos los controladores de dominio.

La capacidad de escribir en AD DS desde varios controladores de dominio al mismo tiempo puede crear una situación conflictiva donde se realizan los cambios al mismo objeto en dos servidores DNS diferentes. Eventualmente se resolverá el conflicto en favor de la última actualización realizada en el objeto basándose en las marcas de hora de las actualizaciones. La misma regla se aplica en el caso de que se crean dos o más nodos con el mismo nombre en dos o más servidores DNS. Hasta que se resuelva el conflicto y el servidor DNS, que contiene la actualización no válida, sondea los datos válidos de Active Directory, es posible que las solicitudes para el mismo objeto realizadas a dos servidores DNS distintos se resuelvan de forma diferente. Por eso se llama sin excesiva coherencia a la base de datos de Active Directory.

Integración de Active Directory proporciona una ventaja sobre las zonas copiadas en el archivo. Con zonas de seguridad de archivo, sólo el principal servidor DNS autorizado para una zona puede modificar la zona. Con la integración con Active Directory-, todos los controladores de dominio para el dominio de Active Directory donde se almacena la zona pueden modificar la zona y, a continuación, replicar los cambios en otros controladores de dominio. Este proceso de replicación se denomina replicación con varios maestros porque varios controladores de dominio pueden actualizar la zona.

Los controladores de dominio de Windows Server 2008 replican los registros de recursos contenidos en zonas integradas en Active Directory mediante la replicación de Active Directory. Las zonas almacenadas en AD DS también pueden transferirse a servidores secundarios para crear zonas secundarias de la misma manera que se transfieren las zonas copiadas en el archivo.

Zonas integradas en Active Directory

Cuando configura una zona principal para ser integradas en Active Directory, la zona se almacena en AD DS.

La figura siguiente muestra esta configuración.

Integrada en Active Directory

Active Directory integrated Zone

El componente de servidor DNS contiene sólo una copia de la zona. Cuando se inicia el DNS, lee una copia de la zona de la base de datos de Active Directory (paso 1). A continuación, cuando el servidor DNS recibe un cambio, escribe el cambio en la base de datos de Active Directory (paso 2).

Mediante la replicación de Active Directory, la zona se replica en otros controladores de dominio en el mismo dominio. Además, mediante la transferencia de zona estándar, el servidor DNS puede enviar su copia de la zona a cualquier servidor DNS secundario que lo solicitan. El servidor DNS puede realizar ambas transferencias de zona incrementales y completas. La figura siguiente muestra cómo se puede replicar la misma zona mediante el uso de replicación de Active Directory y la transferencia de zona estándar.

Transferencia de zona y la replicación de Active Directory

Active Directory Replication and Zone Transfer

De forma predeterminada, cuando se inicia el servicio servidor DNS en un controlador de dominio, comprueba si AD DS está disponible y si contiene ninguna zona DNS. Si AD DS tiene zonas, el servicio servidor DNS carga. El servicio servidor DNS automáticamente vuelve a escribe el archivo de inicio a intervalos regulares. El archivo de arranque puede actualizarse manualmente mediante la consola DNS.

El servicio servidor DNS carga también los parámetros de servidor y la zona y las sugerencias de raíz desde ubicaciones diferentes, dependiendo de su configuración. La siguiente tabla muestra las ubicaciones de que el servicio de servidor DNS carga y a la que escribe las zonas, sugerencias de raíz y servidor y parámetros de la zona.

Dd197495.note(es-es,WS.10).gif Nota
No se recomienda que cambie el tipo de inicio. Pueden producir errores de infraestructura DNS.

Cómo el servidor DNS carga zonas, sugerencias de raíz y parámetros

Tarea Cargar datos en el conjunto de inicio A: Desde archivo Cargar datos en el conjunto de inicio para: Del registro Cargar datos en el conjunto de inicio para: Del registro y Active Directory

Lea las sugerencias de raíz desde:

Archivo de sugerencias de raíz

Si está disponible, archivo de sugerencias de raíz. En caso contrario, si el directorio está disponible y contiene sugerencias de raíz, el directorio.

Si el directorio está disponible y contiene sugerencias de raíz del directorio. De lo contrario, desde el archivo de sugerencias de raíz.

Escribir sugerencias de raíz para:

Archivo de sugerencias de raíz

Archivo de sugerencias de raíz.

Si el directorio está disponible, el directorio.

Zonas de lectura de:

Archivo de inicio, para obtener la lista de zonas, a continuación, de archivos de zona

Registro

El directorio (para zonas integradas en Active Directory) y el registro.

Escribir las zonas para:

Archivo de inicio y el registro

Registro y, si la zona está integrada en Active Directory, el directorio.

Registro y, si la zona está integrada en Active Directory, el directorio.

Leer los parámetros de servidor y las zonas de:

Archivo de inicio y el registro

Registro y (para las zonas integradas en Active Directory) del directorio.

El directorio (para zonas integradas en Active Directory) y el registro.

Escribir parámetros server y las zonas para:

Archivo de inicio y el registro

Registro (para todas las zonas) y (para las zonas integradas en Active Directory) del directorio

El directorio (para zonas integradas en Active Directory) y el registro

Si cambia la configuración del servicio servidor DNS, escribe primero el archivo de sugerencias de raíz, zonas y los parámetros para las ubicaciones especificadas en la configuración predeterminada y, a continuación, el servicio servidor DNS los lee desde la nueva configuración.

Ubicación de almacenamiento de información de zona integrada en el directorio

AD DS es una base de compatibles con X.500 orientada a objetos que organiza los recursos disponibles en la red en una estructura de árbol jerárquica. Esta base de datos está administrado por un conjunto de controladores de dominio. La parte de la base de datos de Active Directory para el que está autorizado un controlador de dominio específico se encuentra físicamente en el mismo equipo que el controlador de dominio. Todos los recursos de Active Directory está representado por un objeto. Existen dos tipos distintos de objetos compatibles con AD DS:

  • Contenedores: objetos que pueden contener otros objetos contenedor y hoja.

  • Hojas: objetos que representan un recurso específico dentro del árbol de servicio de Active Directory.

Cada objeto de Active Directory tiene atributos asociados que definen características particulares del objeto.

Las clases de objetos de la base de datos de Active Directory, así como los atributos de cada objeto, se definen en el esquema de Active Directory. En otras palabras, el esquema contiene definiciones para cada objeto de clase disponible en AD DS. Los siguientes son ejemplos de objetos de clase de servicio de Active Directory:

  • Usuario

  • Grupo

  • Unidad organizativa

  • DnsZone

  • DnsNode

En Windows 2000 Server, las zonas integradas en Active Directory se almacenaban en la partición de dominio del directorio. Las zonas almacenadas en la partición de dominio se replican en todos los controladores de dominio del dominio. Este ámbito de replicación no es necesario para algunas aplicaciones, como DNS. Active Directory de Windows Server 2008 proporciona un tipo de partición, llamada partición de directorio de aplicación, para permitir diferentes ámbitos de replicación. Particiones de directorio de aplicaciones proporcionan almacenamiento para datos específicos de la aplicación que se pueden replicar en cualquier conjunto arbitrario de controladores de dominio del bosque, como pocos o como máximo requerido por la aplicación que utiliza los datos.

Dd197495.note(es-es,WS.10).gif Nota
En el momento de que una partición de directorio de aplicaciones DNS crear (manualmente por un administrador o mediante programación una aplicación), operaciones de maestro único flexibles de nombres de dominio papel (FSMO) del bosque debe mantenerse por un controlador de dominio que ejecutan Windows Server 2008 o Windows Server 2003. Tras la creación de particiones de directorio de aplicación, puede mover la función de nombres de dominio a un controlador de dominio que ejecuta Windows 2000, si es necesario.

Hay dos particiones de directorio predeterminado DNS de Windows Server 2008 aplicación creadas para permitir diferentes ámbitos de replicación de zona DNS: la partición de directorio de aplicaciones DNS de todo el bosque y la partición de directorio de aplicaciones de todo el dominio. Las zonas integradas en Active Directory pueden almacenarse en las particiones de directorio de dominio o aplicación. En la tabla siguiente describe las opciones de almacenamiento de información de Active Directory de Windows Server 2008 disponibles para las zonas DNS.

Opciones de almacenamiento de información de Active Directory de Windows Server 2008

Opción de almacenamiento de información de directorio activo Descripción

Partición de dominio

Partición de dominio de Active Directory para cada dominio del bosque. Las zonas DNS almacenadas en esta partición se replican en todos los controladores de dominio del dominio. Esta es la única opción de almacenamiento de información de Active Directory para las zonas DNS se replican en controladores de dominio que ejecutan Windows 2000 Server.

Partición de directorio de aplicaciones DNS de todo el bosque

Partición de directorio de aplicaciones DNS para todo el bosque. Las zonas DNS almacenadas en esta partición de directorio de aplicaciones se replican en todos los servidores DNS que se ejecutan en controladores de dominio del bosque. Esta partición de directorio de aplicaciones DNS se crea al instalar el servicio servidor DNS en el primer controlador de dominio de Windows Server 2008 en el bosque.

Partición de directorio de aplicaciones de todo el dominio DNS

Partición de directorio de aplicaciones DNS para cada dominio del bosque. Las zonas DNS almacenadas en esta partición de directorio de aplicaciones se replican en todos los servidores DNS que se ejecutan en controladores de dominio del dominio. Para el dominio raíz del bosque, esta partición de directorio de aplicaciones DNS se crea cuando instala por primera vez el servicio servidor DNS en un controlador de dominio de Windows Server 2008 en el bosque.

Para cada nuevo dominio del bosque (dominio secundario), esta partición de directorio de aplicaciones DNS se crea cuando instala por primera vez el servicio servidor DNS en un controlador de dominio de Windows Server 2008 para el nuevo dominio.

Partición de directorio de aplicaciones DNS personalizada

Partición de directorio de aplicaciones DNS para cualquier controlador de dominio que se inscribe en su ámbito de replicación. Este tipo de partición de directorio de aplicaciones DNS no existe de forma predeterminada y debe crearse. Las zonas DNS almacenadas en esta partición de directorio de aplicaciones se replican en todos los servidores DNS que se ejecutan en controladores de dominio que se incluyen en la partición.

Dd197495.note(es-es,WS.10).gif Nota
Puede especificar la partición de directorio de aplicaciones DNS donde desea almacenar la zona mediante la consola DNS o la herramienta de soporte Dnscmd o puede cambiar la opción de almacenamiento de información de zona después de crea la zona con la consola DNS o Dnscmd.

Objetos de DNS de Active Directory

De forma predeterminada, las zonas integradas en Active Directory de Windows Server 2008 se almacenan en la partición de directorio de aplicaciones de todo el dominio del directorio. La información de zona se almacena con el contenedor cuyo nombre completo es: CN = MicrosoftDNS, DC = nombre de dominio DNS. La información de zona para las zonas almacenadas en controladores de dominio del dominio ejemplo.com se almacenaría en CN = MicrosoftDNS, DC = DomainDnsZones, DC = example, DC = com.

Las particiones de directorio de aplicaciones DNS no se muestran todas las herramientas administrativas de Active Directory. Para ver estas particiones de directorio, puede utilizar dnscmd (herramienta de línea de comandos) o ADSI Edit (adsiedit.msc) en herramientas de soporte.

El ámbito de replicación de una partición de directorio de aplicaciones DNS personalizada se define por el número de controladores de dominio inscrito en la partición. De forma predeterminada, sólo los miembros del grupo Administradores de organización pueden dar de alta a un servidor DNS en una partición de directorio de aplicaciones DNS.

Después de un servidor DNS está inscrito en una partición de directorio de aplicaciones DNS, puede almacenar zonas DNS en esa partición de directorio de aplicación mediante la consola DNS. El valor requerido de FQDN especifica el nombre de la nueva partición de directorio de aplicaciones DNS. Debe utilizar un nombre de dominio completo de DNS.

El contenedor MicrosoftDNS contiene otros objetos que representan las zonas y los registros de recursos DNS individuales en esas zonas. La siguiente tabla enumera los tipos de objeto DNS almacenados en la base de datos de Active Directory.

Objeto Descripción

DnsZone

Contenedor creado cuando una zona se almacena en la base de datos de Active Directory.

DnsNode

Objeto de hoja utilizado para asignar y asociar un nombre en la zona de datos de recursos.

DnsRecord

Atributo multivalor de un objeto dnsNode utilizado para almacenar los registros de recursos asociados con el objeto de nodo con nombre.

DnsProperty

Atributo multivalor de un objeto dnsZone utilizado para almacenar información de configuración de zona.

El objeto de contenedor MicrosoftDNS contiene uno o más objetos de contenedor dnsZone. Cada objeto dnsZone representa una zona.

MicrosoftDNS contiene los objetos dnsZone siguientes:

  • La zona de búsqueda inversa, 72.16.172.inaddr.arpa

  • La zona de búsqueda directa

  • Las sugerencias de raíz, RootDNSServers

Puede ver los objetos DNS desde la consola de Active Directory Users and Computers.

Este objeto contenedor contiene un objeto de hoja dnsNode para cada nombre único dentro de esa zona. Siguiente es una lista de objetos de dnsNode dentro de este objeto contenedor:

  • @, lo que significa que el nodo tiene el mismo nombre que este objeto.

  • delegado, un subdominio delegado.

  • host.notdelegated, un host en el notdelegated.com de dominio, un dominio controlado por la zona en el dominio raíz.

  • host1, un host en el dominio.

  • servidor de correo electrónico, el servidor de correo en el dominio.

  • servidor de nombres, el servidor de nombres.

  • notdelegated, notdelegated.com de dominio, que está controlado por la zona en el dominio raíz.

El objeto de hoja dnsNode tiene un atributo multivalor llamado dnsRecord con una instancia de un valor para cada registro asociado con el nombre del objeto.

Aunque puede ver los objetos de la zona desde dentro del componente de Active Directory Users and Computers, el componente de usuarios de Active Directory y los equipos no puede interpretar los valores del atributo dnsRecord . Si desea ver la jerarquía de dominios DNS y registros asociados, utilice la consola DNS. O bien, si desea ver las zonas, se puede recuperar mediante el uso de Nslookup.

Dd197495.note(es-es,WS.10).gif Nota
Los controladores de dominio de Windows 2000 no admiten las particiones de directorio de aplicación. Por lo tanto, no puede ver las zonas almacenadas en particiones de directorio de aplicaciones DNS mediante herramientas de administración de Windows 2000.

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios

Adiciones de comunidad

AGREGAR
Mostrar:
© 2014 Microsoft