Haga clic aquí para instalar Silverlight*
EspañaCambiar|Todos los sitios de Microsoft
Microsoft
|Suscripción CD/DVD|Boletín|Internacional|Suscríbase|Mapa del Web|Contacte con nosotros
Buscar



 

Implementar DNS

Índice

Resumen

El Sistema de nombres de dominio (DNS) de Microsoft® Windows 2003 ofrece resolución de nombres eficaz, compatibilidad con los servicios de directorio de Active Directory™ e interoperabilidad con otras tecnologías basadas en estándares. La implementación de DNS en la infraestructura cliente-servidor permite que los recursos de una red TCP/IP busquen otros recursos en la red mediante la resolución de nombres de host en direcciones IP y viceversa.
[subir]

Información relacionada de los kits de recursos

Para obtener más información acerca de DNS, vea "Introduction to DNS" (Introducción a DNS) en el manual Networking Guide (Guía de redes) del Microsoft® Windows® Server 2003 Resource Kit (Kit de recursos de Microsoft® Windows® Server 2003), o consulte "Introduction to DNS" (Introducción a DNS) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).

Para obtener más información acerca del servidor y el cliente DNS de Windows Server 2003, vea "Windows Server 2003 DNS" (DNS de Windows Server 2003) en el manual Networking Guide (Guía de redes) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003), o consulte "Windows Server 2003  DNS" (DNS de Windows Server 2003) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).

Para obtener información acerca del cliente DNS, vea "Configuring IP Addressing and Name Resolution" (Configurar el direccionamiento IP y la resolución de nombres) en Administering Microsoft® Windows® XP Professional (Administrar Microsoft® Windows® XP Professional).

Para obtener más información acerca de cómo establecer directivas de seguridad, vea "Designing an Authorization Strategy" (Diseñar una estrategia de autorización) en Diseñar e implementar los servicios de directorio y seguridad en este kit.

Para obtener información acerca de cómo implementar DNS específicamente para Active Directory, vea "Designing the Logical Structure" (Diseñar la estructura lógica) en Diseñar e implementar los servicios de directorio y seguridad.
[subir]

Información general acerca de la implementación de DNS

DNS es el método principal para la resolución de nombres en Windows Server 2003. DNS también es un requisito básico para la implementación de Active Directory; sin embargo, Active Directory no es obligatorio para la implementación de DNS. La integración de DNS con Active Directory proporciona la mejor combinación de seguridad, rendimiento y disponibilidad para la resolución de nombres en la empresa.

La implementación de DNS con Active Directory permite utilizar la topología de replicación multifuncional de Active Directory para mejorar el rendimiento y la integridad de la resolución de nombres. Con la implementación de zonas integradas de Active Directory se elimina la necesidad de una topología independiente de transferencia de zonas principales-secundarias con un servidor principal único. Las zonas integradas de Active Directory almacenan datos de zona en la base de datos de Active Directory. Puesto que en Active Directory no se pueden almacenar zonas secundarias, para utilizar las zonas integradas de Active Directory se debe ejecutar el servicio Servidor DNS en los controladores de dominio y utilizar exclusivamente zonas principales. La implementación de zonas integradas de Active Directory permite también aprovechar el modelo de seguridad de Active Directory mediante la implementación de la actualización dinámica segura, que es una extensión del protocolo de actualización dinámica de DNS.

La implementación de DNS ofrece un mecanismo escalable de búsqueda de recursos en redes. Al integrar DNS con Active Directory se mejora la seguridad y el rendimiento de DNS.

Proceso para implementar DNS

La implementación de DNS implica planear y diseñar la infraestructura DNS, lo que incluye el espacio de nombres DNS, la colocación de los servidores, las zonas y la configuración de los clientes DNS. Además se debe planear el nivel de integración con Active Directory e identificar los requisitos de seguridad, escalabilidad y rendimiento antes de implementar la solución DNS en el entorno de producción. En la figura 4.1 se muestra el proceso que es preciso seguir para implementar DNS.

rksdns01

Figura 4.1   Proceso de implementación de DNS

Conceptos de DNS

DNS de Windows Server 2003 interopera con una amplia variedad de sistemas operativos. Además, DNS utiliza una base de datos distribuida que implementa un sistema de nombres jerárquico. Este sistema de nombres permite a las organizaciones expandir su presencia en Internet y hace posible la creación de nombres que son únicos en Internet y en las intranets privadas basadas en TCP/IP.

Debido a su estructura jerárquica distribuida, DNS se utiliza en todo el mundo para el espacio de nombres de Internet. Al utilizar DNS, cualquier equipo de Internet puede buscar el nombre de otro equipo del espacio de nombres de Internet. En los equipos que ejecutan Windows Server 2003 y Windows 2000, DNS se utiliza también para buscar controladores de dominio.

Novedades en Windows Server 2003

DNS de Windows Server 2003 ofrece varias nuevas características, entre las que se incluyen:

  • Reenvío condicional. Permite reenviar consultas DNS en función del nombre de dominio DNS de la consulta. Para obtener más información acerca del reenvío condicional, vea el Centro de ayuda y soporte técnico de Windows Server 2003.
  • Zonas de rutas internas. Permiten sincronizar los servidores DNS que alojan zonas principales con los servidores DNS que tienen autoridad en sus respectivas zonas secundarias. Para obtener más información acerca de las zonas de rutas internas, vea el Centro de ayuda y soporte técnico de Windows Server 2003.
  • Zonas integradas de Active Directory. Permiten almacenar datos de zona en la base de datos de Active Directory. La información de zona de un servidor DNS principal en una zona integrada de Active Directory siempre se replica. Para obtener más información acerca de las zonas integradas de Active Directory, vea el Centro de ayuda y soporte técnico de Windows Server 2003.
Herramientas para implementar DNS

En Windows Server 2003 se incluyen diversas herramientas de ayuda para implementar una infraestructura DNS.

Active Directory Sizer

Calcula el hardware necesario para implementar Active Directory en función del perfil, la información de dominios y la topología de sitios de la organización. Active Directory Sizer utiliza información del usuario y fórmulas internas para calcular el número de:

  • controladores de dominio por dominio por sitio.
  • servidores de catálogo global por dominio por sitio.
  • CPU por equipo y tipo de CPU.
  • discos necesarios para el almacenamiento de datos de Active Directory.

Además, Active Directory Sizer calcula:

  • la cantidad de memoria necesaria.
  • el uso de ancho de banda en la red.
  • el tamaño de la base de datos del dominio.
  • el tamaño de la base de datos del catálogo global.
  • el ancho de banda necesario para la replicación entre sitios.

Netdiag

Ayuda a aislar problemas de red y conectividad. Netdiag realiza una serie de pruebas que se pueden utilizar para determinar el estado del cliente de red. Para obtener más información acerca de Netdiag, vea "Support Tools" (Herramientas de soporte técnico) en el Centro de ayuda y soporte técnico de Windows Server 2003.

Dnscmd.exe

Esta herramienta de línea de comandos se puede utilizar para llevar a cabo la mayoría de las tareas que se pueden realizar en el complemento MMC (Microsoft Management Console) de DNS.

Términos y definiciones

A continuación se incluyen algunos términos importantes relacionados con DNS:

  • Servidor de nombres con autoridad. Servidor que tiene autoridad para resolver consultas DNS en una zona especificada. Los servidores de nombres con autoridad contienen un archivo de zona local con registros de recursos para los equipos de la zona. En cada zona hay como mínimo un servidor de nombres con autoridad.
  • Reenvío condicional. Esta función permite especificar un nombre de dominio y una dirección IP internos que el reenviador asocia con el nombre de dominio designado en la consulta. En DNS de Windows Server 2003 se pueden agregar condiciones basadas en nombres a los reenviadores DNS para mejorar el rendimiento de la resolución de nombres. Después de crear una correspondencia entre el nombre de dominio designado en la consulta y el nombre de dominio especificado en la condición, el reenviador pasa la consulta a un servidor DNS del dominio especificado. Los servidores DNS configurados para utilizar el reenvío condicional pueden llevar a cabo la resolución de nombres sin utilizar la recursividad.
  • Delegación. Proceso que consiste en distribuir la responsabilidad de los nombres de dominio entre diferentes servidores DNS de la red. Para cada nombre de dominio delegado se debe crear al menos una zona. Cuantos más dominios se deleguen, más zonas será necesario crear.
  • Espacio de nombres DNS. Estructura jerárquica del árbol de nombres de dominio. Cada etiqueta que se utiliza en un nombre de dominio completo (FQDN) indica un nodo o rama del árbol del espacio de nombres de dominio. Por ejemplo, host1.contoso.com es un FQDN que representa el nodo host1, que está situado bajo el nodo Contoso, que se encuentra bajo el nodo com, que a su vez está bajo la raíz de Internet.
  • Resolución de DNS. Servicio que se ejecuta en los equipos cliente y envía consultas a un servidor DNS.
  • Servidor DNS. Equipo en el que se ejecuta el servicio Servidor DNS. Los servidores DNS mantienen información acerca de una parte de la base de datos DNS y resuelven consultas DNS.
  • Espacio de nombres externo. Espacio de nombres público, como Internet, al que se puede tener acceso mediante un dispositivo conectado. Debajo de los dominios de nivel superior, la Corporación de Internet para la asignación de nombres y números (ICANN, Internet Corporation for Assigned Names and Numbers) y otras autoridades de nomenclatura en Internet delegan dominios en organizaciones como los proveedores de servicios de Internet (ISP), que a su vez delegan subdominios en sus clientes.
  • Nombre de dominio completo (FQDN). Nombre DNS que identifica de forma exclusiva un nodo de un espacio de nombres DNS. El FQDN de un equipo es una expresión concatenada que se compone del nombre del equipo (por ejemplo, cliente1) y el sufijo DNS principal del equipo (por ejemplo, contoso.com).
  • Espacio de nombres interno. Espacio de nombres controlado por las organizaciones, lo que incluye el acceso al mismo. Las organizaciones pueden utilizar el espacio de nombres interno para proteger de Internet los nombres y direcciones IP de los equipos internos. Una organización puede tener varios espacios de nombres internos. Las organizaciones pueden crear sus propios servidores raíz y los subdominios que necesiten. El espacio de nombres interno puede coexistir con un espacio de nombres externo.
  • Servidor de nombres. Servidor DNS que responde a las solicitudes de resolución DNS de los clientes dentro de una zona especificada y resuelve nombres completos en direcciones IP. Las zonas pueden contener servidores de nombres principales y secundarios.
  • Servidor de nombres maestro. Servidor que tiene autoridad para la resolución de nombres en una zona. Si un servidor maestro es un servidor de nombres principal, debe contener un archivo de zona local de registros de recursos. Si un servidor maestro es un servidor de nombres secundario, debe obtener los registros de recursos para la zona en otro servidor de nombres maestro durante una transferencia de zona.
  • Servidor de nombres principal. Servidor que se encarga de la resolución de nombres para la zona en la que tiene autoridad. Los servidores de nombres principales tienen una base de datos DNS principal de registros de recursos con asignaciones de nombres de host a direcciones IP. Los registros de la base de datos DNS principal están contenidos en un archivo de zona local.
  • Servidor de nombres secundario. Servidor que debe obtener los registros de recursos de una zona en un servidor de nombres maestro durante una transferencia de zona. Los servidores de nombres secundarios no disponen de un archivo de zona local. Si un servidor secundario es un servidor de nombres maestro, tiene autoridad para la resolución de nombres en una zona, pero debe obtener los registros de recursos en otro servidor de nombres maestro. Si un servidor secundario no es un servidor de nombres maestro, se puede utilizar con fines de redundancia y equilibrio de carga.
  • Registro de recursos (RR). Estructura estándar de base de datos DNS que contiene información utilizada para procesar las consultas DNS. Por ejemplo, un registro de recursos de dirección (A) contiene una dirección IP correspondiente a un nombre de host. La mayoría de los RR básicos están definidos en el documento RFC 1035, "Domain Names — Implementation and Specification" (Nombres de dominio: implementación y especificación), pero en otros RFC se definen tipos de RR adicionales que están aprobados para su uso en DNS.
  • Zona de rutas internas. Copia parcial de una zona que se puede alojar en un servidor DNS y utilizar para resolver consultas recursivas o iterativas. Las zonas de rutas internas contienen los registros de recursos de inicio de autoridad (SOA) de la zona, los registros de recursos DNS en los que se enumeran los servidores con autoridad de la zona y los registros de recursos de adherencia de host (A) necesarios para contactar con los servidores que tienen autoridad en la zona.
  • Zona. En una base de datos DNS, parte contigua del árbol DNS que un servidor DNS administra como una entidad única independiente. La zona contiene registros de recursos para todos los nombres de la zona.
  • Archivo de zona. Archivo formado por los registros de recursos de la base de datos DNS que definen la zona. Cada servidor de nombres principal contiene un archivo de zona.
  • Transferencia de zona. Proceso que consiste en mover el contenido del archivo de zona ubicado en un servidor de nombres principal a un servidor de nombres secundario. La transferencia de zonas proporciona tolerancia a errores al sincronizar el archivo de zona de un servidor de nombres principal con el archivo de zona de un servidor de nombres secundario. El servidor de nombres secundario puede continuar realizando la resolución de nombres si se produce un error en el servidor de nombres principal. La transferencia de zonas proporciona también equilibrio de la carga al dividir la carga de la red entre los servidores de nombres principales y secundarios durante períodos en los que tiene lugar un volumen alto de consultas de resolución de nombres.

[subir]

Examinar el entorno actual

Antes de implementar DNS de Windows Server 2003 en el entorno es necesario evaluar los requisitos actuales para determinar si se debe implementar una infraestructura DNS propia o subcontratar su administración. Además se debe crear un plan para la implementación de DNS de Windows Server 2003 que cubra las necesidades actuales y futuras de la organización. En la figura 4.2 se muestra el proceso que es preciso seguir para examinar el entorno actual.


Si su explorador no admite los marcos en línea, haga clic aquí para abrir una página independiente.

Figura 4.2 Examen del entorno actual

Determinar el estado de Internet

Para admitir la resolución de nombres fuera del ámbito del dominio interno, las direcciones IP y los nombres de dominio DNS deben registrarse en una entidad de registro de Internet (registrador de Internet). Los registradores de Internet son organizaciones que se encargan de:

  • asignar direcciones IP.
  • registrar nombres de dominio DNS.
  • mantener registros públicos de las direcciones IP y nombres de dominio registrados.

Si la red está conectada a Internet o lo estará en el futuro, debe determinarse el estado de registro de las direcciones IP. Los demás equipos de Internet utilizarán las direcciones IP de la red para buscar recursos en ella.

Si ya está conectado a Internet, su red es una subred de la red del ISP. Asegúrese de que el ISP ha registrado las direcciones IP de esta subred en un registrador de Internet. Si el ISP ha registrado las direcciones IP de la red, no es necesario que las registre por su cuenta.

Identificar el host de datos DNS

Debe determinarse dónde se alojarán los datos DNS. Estos se pueden alojar internamente o en un ISP externo. Si los datos DNS se alojan internamente se tiene el control total de la asignación y seguridad de los recursos de la red. La opción de alojamiento en un ISP sólo debe utilizarse si se tiene una red pequeña que no va a experimentar una expansión rápida a corto plazo. Si decide alojar los datos DNS internamente, considere la posibilidad de permitir que los clientes y servidores DNS utilicen los servidores DNS de un ISP para llevar a cabo la resolución de nombres de los hosts externos. Esta configuración puede mejorar el uso del ancho de banda en la red interna.

Si decide alojar los datos DNS en un ISP, debe asegurarse de que la infraestructura DNS del ISP puede admitir la implementación DNS mediante la confirmación de que el software de servidor DNS del ISP es compatible con DNS de Windows Server 2003. Si el ISP debe admitir características específicas de Windows Server 2003, confirme que la versión de DNS que utiliza el ISP es compatible con ellas. Asegúrese de conocer qué software de servidor DNS ejecuta el ISP y cómo interoperan las características y opciones de dicho software con DNS de Windows Server 2003. En diferentes soluciones de software de servidor DNS se proporcionan características y opciones distintas.

Si todos los datos DNS se alojan en la organización, no es necesario tener en cuenta la infraestructura DNS del ISP. Observe que incluso si los datos DNS se alojan internamente sin la ayuda del ISP, se puede permitir que los clientes y servidores DNS utilicen los servidores DNS del ISP para llevar a cabo la resolución de nombres de los hosts externos. En ese caso no es necesario informar al ISP de la configuración existente.

Analizar la topología de la red

Debe analizarse la topología de red existente e identificar los objetivos de servicio y administración representados en el diseño de la red. Al planear el espacio de nombres DNS, asegúrese de tener en cuenta los objetivos de servicio y administración de la organización. Prevea la expansión del número de nodos en la jerarquía DNS mediante la inclusión de marcadores entre los nombres de dominio que se implementen inicialmente. La incorporación de marcadores de nombres de dominio evita la necesidad de volver a diseñar la infraestructura DNS para ampliar el número de nombres de dominio.

Prevea la posibilidad de que se produzcan cambios en el modelo de negocio mediante la asignación de nombres de dominio que se puedan utilizar en un contexto modificado. Por ejemplo, en lugar de utilizar el nombre de dominio contabilidad.contoso.com, puede utilizar finanzas.contoso.com, en previsión de una posible expansión que incluya más servicios financieros que la contabilidad.

Crear un diagrama de la infraestructura DNS existente

Si se va a actualizar a Windows Server 2003, realizar una nueva implementación DNS o integrar DNS de Windows Server 2003 con los servicios de Active Directory, no es necesario efectuar ningún cambio en la infraestructura DNS existente. Sin embargo, si se va a migrar desde una infraestructura DNS de terceros o integrar DNS de Windows Server 2003 con una infraestructura DNS de terceros existente, debe crearse un diagrama de la infraestructura existente en la que se incluyan los dominios, servidores y clientes. Este diagrama debe utilizarse como ayuda para decidir si es necesario realizar cambios en la infraestructura DNS existente al implementar DNS de Windows Server 2003.

Identificar las directivas de seguridad

Antes de diseñar e implementar la infraestructura DNS de Windows Server 2003 se deben identificar y documentar las directivas de seguridad de la organización. De esta forma se puede asegurar que los servidores DNS, zonas y registros de recursos admiten dichas directivas. En DNS de Windows Server 2003 se incluyen características que permiten implementar una infraestructura DNS segura.
[subir]

Diseñar un espacio de nombres DNS

Antes de implementar una infraestructura DNS se debe diseñar un espacio de nombres DNS. Se puede diseñar un espacio de nombres externo que sea visible para los usuarios y equipos de Internet, o uno interno al que sólo tengan acceso los usuarios y equipos que se encuentren dentro del espacio de nombres interno. En la figura 4.3 se muestra el proceso que es preciso seguir para crear un espacio de nombres DNS.


Si su explorador no admite los marcos en línea, haga clic aquí para abrir una página independiente.

Figura 4.3   Creación de un espacio de nombres DNS

Identificar los requisitos de espacio de nombres DNS

El primer paso para diseñar un espacio de nombres DNS consiste en determinar si se necesita un espacio de nombres nuevo para la organización o se puede conservar un espacio de nombres DNS de Windows o de otro proveedor.

Si se va a actualizar a DNS de Windows Server 2003 desde una versión anterior de Windows, puede que sea necesario reemplazar o admitir un sistema de resolución de nombres existente, como el Servicio de nombres de Internet de Windows (WINS), en la infraestructura DNS de Windows Server 2003. Se puede admitir una implementación existente de WINS mediante la configuración de los servidores DNS de Windows Server 2003 para que consulten los servidores WINS como una opción de zona DNS.

Si se va a migrar o integrar DNS de Windows Server 2003 con una infraestructura DNS de otro proveedor, no es necesario cambiar el diseño del espacio de nombres que se utiliza en dicha infraestructura. Si se va a implementar una nueva infraestructura DNS de Windows Server 2003 se debe crear una estrategia de nomenclatura de dominios DNS y equipos, y planear la forma en que estos nombres se resolverán dentro de la red y en Internet.

Si se va a implementar DNS de Windows Server 2003 para admitir Active Directory se deben integrar los nombres de los bosques y dominios de Active Directory en la infraestructura DNS. Por ejemplo, puede modificar el diseño del espacio de nombres DNS existente para incluir recursos de red que deben buscar los nombres específicos de controladores de dominio de Active Directory, unidades organizativas (OU), sitios y subredes.

Nota   El espacio de nombres DNS debe planearse junto con la estructura lógica de Active Directory. Para obtener información acerca de cómo diseñar la estructura lógica de Active Directory, vea "Designing the Logical Structure" (Diseñar la estructura lógica) en Diseñar e implementar los servicios de directorio y seguridad.

En la tabla 4.1 se resumen los requisitos de diseño del espacio de nombres DNS en cada uno de los escenarios posibles.

Tabla 4.1   Requisitos de diseño del espacio de nombres DNS

Escenario Requisitos de diseño
Actualización de una infraestructura DNS existente desde una versión de Windows anterior a Windows Server 2003. El diseño del espacio de nombres DNS puede permanecer igual.
Actualización desde una infraestructura DNS de terceros que utiliza software DNS compatible con las directrices de nomenclatura de dominios DNS estándar. El diseño del espacio de nombres DNS puede permanecer igual.
El software DNS existente no cumple las directrices de nomenclatura de dominios DNS estándar. Antes de implementar un espacio de nombres DNS de Windows Server 2003, debe modificarse el espacio de nombres existente para cumplir con las directrices de nomenclatura de dominios DNS.
El software DNS de terceros existente cumple las directrices de nomenclatura de dominios DNS estándar. DNS de Windows Server 2003 se puede integrar en la infraestructura DNS actual. No es necesario cambiar el diseño del espacio de nombres de la infraestructura DNS de terceros ni el espacio de nombres existente.
Implementación de una nueva infraestructura DNS de Windows Server 2003. Debe diseñarse una convención de nomenclatura lógica para el espacio de nombres DNS basada en las directrices de nomenclatura de dominios DNS.
Implementación de DNS de Windows Server 2003 para admitir Active Directory. El diseño del espacio de nombres DNS debe basarse en la convención de nomenclatura de Active Directory.
Modificación del espacio de nombres DNS existente para admitir Active Directory, pero sin volver a diseñar el espacio de nombres DNS. Es necesario asegurarse de que los nombres de dominio de Active Directory coinciden con los nombres DNS existentes. Esto permite implementar el nivel más alto de seguridad con las técnicas de administración más sencillas.

Crear dominios internos y externos

En las organizaciones que requieren presencia en Internet además de un espacio de nombres interno, se debe implementar un espacio de nombres interno y otro externo, y administrar cada uno de forma independiente. Hay tres maneras de combinar un espacio de nombres DNS interno y externo:

  • Convirtiendo el dominio interno en un subdominio del dominio externo.
  • Utilizando nombres diferentes para los dominios interno y externo.
  • Utilizando el mismo nombre para el dominio interno y el externo al tiempo que se utiliza un espacio de nombres privado para la organización. Este método no se recomienda ya que causa problemas en la resolución de los nombres al introducir nombres DNS que no son únicos.

Debe seleccionarse la opción de diseño de la configuración que mejor se adapte a las necesidades de la organización. En la tabla 4.2 se enumeran las opciones de diseño para implementar un espacio de nombres interno y externo mixto, así como el nivel de complejidad de administración de cada opción, junto con un ejemplo en cada caso.

Tabla 4.2    Opciones de diseño de un espacio de nombres DNS interno y externo mixto

Opción de diseño Complejidad de administración Ejemplo
El dominio interno en un subdominio del dominio externo. Esta configuración es fácil de implementar y administrar. Una organización cuyo nombre de dominio del espacio de nombres externo es contoso.com utiliza el nombre de dominio corp.contoso.com para el espacio de nombres interno.
Los nombres de dominio interno y externo no están relacionados entre sí. Esta configuración ofrece cierta dificultad para su implementación y administración. Una organización utiliza contoso01-ext.com como nombre de dominio del espacio de nombres externo y contoso.com como nombre de dominio del espacio de nombres interno.
El nombre de dominio interno es el mismo que el externo, pero la organización tiene un espacio de nombres privado. Esta configuración es muy difícil de implementar y administrar. Esta opción no se recomienda. Una organización utiliza el nombre de dominio contoso.com como nombre de dominio para el espacio de nombres interno privado y el espacio de nombres externo público.

Utilizar un subdominio interno

La opción de configuración óptima para un espacio de nombres DNS interno y externo mixto es convertir el dominio interno en un subdominio del dominio externo. Por ejemplo, una organización que tiene el nombre de dominio contoso.com para el espacio de nombres externo puede utilizar el nombre de dominio corp.contoso.com para el espacio de nombres interno. El uso como dominio interno de un subdominio de un dominio externo ofrece las siguientes ventajas:

  • Permite registrar un solo nombre en una entidad de registro de nombres de Internet.
  • Asegura que todos los nombres de dominio internos son únicos de forma global.
  • Simplifica la administración al permitir la distribución de las responsabilidades administrativas entre los dominios interno y externo.

El subdominio interno se puede utilizar como principal de dominios secundarios adicionales que se creen para administrar divisiones dentro de la empresa. Los dominios secundarios tienen nombres DNS subordinados directamente al nombre DNS del dominio principal. Por ejemplo, un dominio secundario para el departamento de recursos humanos que se agregue al espacio de nombres us.corp.contoso.com puede tener el nombre de dominio rh.us.corp.contoso.com.

Si se utiliza esta opción de configuración para el dominio interno, los equipos que se desee exponer a Internet deben implementarse en el dominio externo fuera del servidor de seguridad. Los equipos que no se desee exponer a Internet deben implementarse en el subdominio interno.

Utilizar un dominio interno independiente

Si no es posible configurar el dominio interno como un subdominio del dominio externo, puede utilizarse un dominio interno independiente. En este caso, los nombres de los dominios interno y externo no están relacionados. Por ejemplo, una organización que usa el nombre de dominio contoso01-ext.com para el espacio de nombres externo utiliza el nombre contoso.com para el espacio de nombres interno.

La ventaja de este método es que proporciona un nombre de dominio interno único. El inconveniente es que esta configuración requiere que se administren dos espacios de nombres independientes. Además, el uso de un dominio interno independiente no relacionado con el dominio externo puede crear confusión para los usuarios, ya que los espacios de nombres no reflejan una relación entre los recursos que están dentro de la red y los que están fuera. Por otro lado se deben registrar dos nombres DNS en una entidad de registro de nombres de Internet.

Utilizar nombres de dominio interno y externo idénticos

No se recomienda el uso del mismo nombre de dominio para el espacio de nombres interno y externo. Esta configuración causa problemas en la resolución de los nombres porque introduce nombres DNS que no son únicos. Si se utiliza esta configuración, un equipo del espacio de nombres interno puede tener el mismo nombre que un equipo del espacio de nombres de Internet. En consecuencia, los intentos de resolver ese nombre pueden producir errores. Esto aumenta la carga administrativa, puesto que se deben prever todos los posibles duplicados de nombres.

Para habilitar el uso del mismo nombre de dominio en el espacio de nombres DNS interno y externo se pueden utilizar los siguientes métodos:

  • Si los clientes pueden pasar consultas a los servidores externos (como los servidores Web) a través de un servidor de seguridad, copie los datos de zona del servidor DNS externo en el servidor DNS interno.
  • Si los clientes no pueden pasar consultas a través de un servidor de seguridad, duplique en la red interna todos los datos de zona DNS públicos y todos los servidores públicos (como los servidores Web) que pertenezcan a la organización.
  • Mantenga una lista de los servidores públicos que pertenezcan a la organización en el archivo de Configuración automática de proxy (PAC, Proxy Auto-Configuration) de cada uno de los clientes DNS.

El método que se elija depende de las funciones de proxy del software cliente. En la tabla 4.3 se enumeran los métodos que se pueden utilizar para habilitar el uso del mismo nombre de dominio para el espacio de nombres interno y externo, y las funciones de proxy del software cliente posibles en cada método.

Tabla 4.3   Métodos para utilizar el mismo nombre para los espacios de nombres interno y externo, y las funciones de proxy compatibles

Método Función de proxy del software
Sin proxy
Tabla de direcciones local (LAT) Lista de exclusiones de nombres Archivo de configuración automática de proxy (PAC)
Utilizar nombres de dominio diferentes
Copiar los datos de zona del servidor DNS externo en el interno
Duplicar todos los datos de zona DNS públicos y todos los servidores públicos en la red interna
Mantener la lista de servidores públicos en los archivos PAC de los clientes DNS      

Decidir si se implementa una raíz DNS interna

Si tiene una red distribuida de gran tamaño y un espacio de nombres DNS complejo, es conveniente utilizar una raíz DNS interna que esté aislada de las redes públicas. El uso de una raíz DNS interna agiliza la administración del espacio de nombres DNS al permitir administrar la infraestructura DNS como si el espacio de nombres completo estuviera formado por los datos DNS de la red interna.

Si se utiliza una raíz DNS interna, se aloja una zona raíz DNS privada en un servidor DNS de la red interna. Esta zona raíz DNS privada no está expuesta a Internet. Al igual que la zona raíz de Internet contiene delegaciones de todos los nombres de dominio de nivel superior de Internet, por ejemplo .com, .net y .org, una zona raíz privada contiene delegaciones de todos los nombres de dominio de nivel superior de la red interna. El servidor DNS que aloja la zona raíz privada se considera que tiene autoridad para todos los nombres del espacio de nombres DNS interno.

Con una raíz DNS interna se obtienen las siguientes ventajas:

  • Escalabilidad. Una red de gran tamaño con un espacio de nombres DNS interno alojado en múltiples servidores DNS se puede escalar de forma sencilla. Si la red abarca varias ubicaciones, una raíz DNS interna es el mejor método para administrar toda la actividad DNS de la red distribuida.
  • Resolución de nombres eficaz. Con una raíz DNS interna, los clientes y servidores DNS de la red no se ponen en contacto con Internet para resolver los nombres internos. De esta manera, los datos DNS de la red no se difunden a través de Internet. Se puede habilitar la resolución de nombres en otro espacio de nombres si se agrega una delegación de la zona raíz. Por ejemplo, si los equipos necesitan tener acceso a los recursos de una organización asociada, se puede agregar una delegación de la zona raíz al nivel superior del espacio de nombres DNS de la organización asociada.
  • Eliminación de reenviadores. El uso de una raíz DNS interna elimina la necesidad de utilizar reenviadores, ya que la resolución de nombres se lleva a cabo internamente. Los servidores DNS de un espacio de nombres interno se configuran con sugerencias de raíz que apuntan a los servidores raíz internos.
Importante   Los nombres externos no deben repetirse en el espacio de nombres interno. Si los nombres DNS de Internet se repiten en la intranet se pueden producir errores en la resolución de los nombres.

Si los equipos de la red no necesitan tener acceso a los recursos que se encuentran fuera del espacio de nombres DNS, se puede implementar y mantener una raíz DNS interna. Si los equipos necesitan tener acceso a los recursos externos, puede que no sea posible utilizar una raíz interna para la resolución de nombres, dependiendo de las funciones de proxy de los equipos de la red.

Si es necesaria la resolución de nombres en equipos que no admiten proxy de software o en equipos que sólo admiten LAT, no se podrá utilizar una raíz interna para el espacio de nombres DNS. En este caso se debe configurar uno o varios servidores DNS internos para reenviar a Internet las consultas que no es posible resolver localmente.

En la tabla 4.4 se enumeran los tipos de funciones de proxy de cliente y si es posible utilizar una raíz DNS interna con cada tipo.

Tabla 4.4   Funciones de proxy de cliente

Función de proxy Software de Microsoft con funciones de proxy correspondientes Reenvía consultas ¿Se puede utilizar una raíz interna?
Sin proxy Telnet genérico  
Tabla de direcciones local (LAT) Winsock Proxy (WSP) 1.x y versiones posteriores

Internet Security and Acceleration (ISA) Server 2000 y versiones posteriores

 
Lista de exclusiones de nombres WSP 1.x y versiones posteriores

Internet Security and Acceleration (ISA) Server 2000 y versiones posteriores, y todas las versiones de Microsoft® Internet Explorer

Archivo de configuración automática de proxy (PAC) WSP 2.x

Internet Security and Acceleration (ISA) Server 2000 y versiones posteriores

Internet Explorer 3.01 y versiones posteriores


Configurar la resolución de nombres para varios dominios de nivel superior

Si es necesario crear o combinar dos espacios de nombres al implementar DNS de Windows Server 2003, con el resultado de una infraestructura DNS que incluya dos o más nombres de dominio de nivel superior, debe asegurarse de que la resolución de nombres interna funciona correctamente. Para configurar la resolución de nombres para varios dominios de nivel superior, debe llevar a cabo una de las siguientes acciones:

  • Si tiene una raíz DNS interna, agregue delegaciones para cada zona DNS de nivel superior a la zona raíz DNS interna.
  • Configure los servidores DNS que alojan las zonas de nivel superior en un espacio de nombres para reenviar las consultas de resolución de nombres de otro espacio de nombres a los servidores DNS que alojan las zonas de nivel superior del segundo espacio de nombres. Después, configure los servidores DNS que alojan las zonas de nivel superior en el segundo espacio de nombres para reenviar las consultas de resolución de nombres del primer espacio de nombres a los servidores DNS que alojan las zonas de nivel superior del primer espacio de nombres. Para esta configuración se pueden utilizar reenviadores condicionales de DNS de Windows Server 2003.
  • Configure los servidores DNS que alojan las zonas DNS de nivel superior en el primer y segundo espacios de nombres para alojar zonas secundarias de las zonas de nivel superior del otro espacio de nombres respectivamente. En esta configuración, los servidores DNS que alojan las zonas de nivel superior en cada espacio de nombres tienen conocimiento de los servidores DNS del otro espacio de nombres. Esta solución requiere mayor espacio de almacenamiento para alojar copias secundarias de las zonas de nivel superior de diferentes espacios de nombres y genera más tráfico de transferencia de zonas.

Se pueden utilizar las zonas de rutas internas de DNS de Windows Server 2003 para facilitar la distribución de datos DNS entre espacios de nombres independientes. Sin embargo, el uso de zonas de rutas internas es menos eficaz que utilizar los reenviadores condicionales de Windows Server 2003. Para obtener más información acerca de los reenviadores condicionales y las zonas de rutas internas, vea el Centro de ayuda y soporte técnico de Windows Server 2003 y "Windows Server 2003 DNS" (DNS de Windows Server 2003) en el manual Networking Guide (Guía de redes) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003), o consulte "Windows Server 2003  DNS" (DNS de Windows Server 2003) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).

Integrar una infraestructura DNS de Windows Server 2003  en un espacio de nombres DNS existente

DNS de Windows Server 2003 es compatible con estándares e interopera con otras implementaciones de DNS, lo que incluye Windows NT 4.0, BIND 9.1.0, BIND 8.2, BIND 8.1.2 y BIND 4.9.7. La complejidad del proceso de integración depende en parte de las características de DNS que sea necesario admitir. Si los equipos de la infraestructura DNS ejecutan versiones de DNS que admiten las mismas características, el proceso de integración de la infraestructura DNS de Windows Server 2003 es sencillo. Si los equipos de la infraestructura DNS ejecutan versiones de DNS que no admiten las mismas características, el proceso de integración es más complejo.

En la tabla 4.5 se compara la compatibilidad de características en DNS de Windows Server 2003 y otras implementaciones de DNS.

Tabla 4.5   Compatibilidad de características en diferentes implementaciones de DNS

Característica Windows Server 2003 Windows 2000 Windows NT 4.0 BIND 9 BIND 8.2 BIND 8.1.2 BIND 4.9.7
Compatible con el borrador de Internet de IETF (Internet Engineering Task Force) "A DNS RR for specifying the location of services (DNS SRV)" (RR de DNS para especificar la ubicación de los servicios (DNS SRV)). (Registros SRV)
Actualización dinámica    
Actualización dinámica segura basada en el algoritmo de firma de transacción (TSIG) GSS          
WINS y registros WINS-R        
Transferencia de zona rápida
Transferencia de zona incremental      
Codificación de caracteres UTF-8          
Complemento MMC de DNS          
Dnscmd.exe          
Zonas integradas de Active Directory          
Almacenamiento de zonas en la partición de aplicaciones de Active Directory            
Caducidad y compactación de registros obsoletos          
Zonas de rutas internas          
Reenvío condicional          
Mecanismos de extensión para DNS (EDNS0)          

Crear subdominios

Si va a implementar DNS en una red empresarial de gran tamaño o prevé la expansión de la red para incluir subredes y sitios adicionales, debe distribuir la administración de partes del espacio de nombres DNS entre los administradores de las diferentes subredes y sitios de la red. Para ello, cree subdominios del dominio DNS inicial y delegue la autoridad de estos en los servidores DNS ubicados en las distintas subredes y sitios. De esta forma se puede crear un número indeterminado de entidades independientes dentro de un espacio de nombres DNS, cada una de las cuales tiene autoridad en una parte del espacio de nombres global.

La creación de subdominios del dominio DNS interno ofrece las siguientes ventajas:

  • Distribución de la administración de la red. Los subdominios permiten la distribución y administración de los recursos de la red en grupos o departamentos administrativos. Se pueden implementar subdominios DNS que reflejen los departamentos administrativos existentes de la empresa mediante la creación de un subdominio diferente para cada segmento de la red.
  • Equilibrio de la carga en la red. Mediante la distribución de la carga de la red entre varios subdominios se puede aumentar la eficacia y el rendimiento del espacio de nombres DNS.

Si la organización tiene entidades que actualmente administran sus propios recursos de red, determine si necesitan tener autoridad en su parte del espacio de nombres DNS. En caso afirmativo, delegue la autoridad para dicho dominio secundario.

Crear nombres de dominio DNS y nombres de equipo

Antes de implementar la infraestructura DNS de Windows Server 2003, debe crearse una convención de nombres para los dominios DNS internos y de Internet, así como los equipos DNS de la red. Para crear una convención de nombres DNS, es necesario establecer los siguientes elementos:

  • Un nombre de dominio DNS de Internet si la organización está conectada a Internet.
  • Un nombre de dominio DNS interno para la organización.
  • Una convención de nombres de equipo DNS.

Además, debe determinarse la necesidad de admitir nombres NetBIOS en la organización.

Crear un nombre de dominio DNS de Internet

Si se va a implementar una nueva infraestructura DNS de Windows Server 2003 con conexión a Internet, debe crearse un nombre de dominio DNS de Internet para la organización. Puesto que todos los nodos que requieren la resolución de nombres tienen asignado un nombre DNS que incluye el nombre de dominio DNS de Internet para la organización, es importante seleccionar un nombre de dominio que sea corto y fácil de recordar. Como DNS tiene una estructura jerárquica, el número de nombres de dominio DNS se incrementa al agregar subdominios a la organización. Los nombres de dominio cortos producen nombres de equipo que son sencillos de recordar, con lo que se facilita el acceso a los recursos.

Un espacio de nombres DNS que está conectado a Internet debe ser un subdominio de un dominio de nivel superior o de segundo nivel del espacio de nombres DNS de Internet. Si se va a implementar un nuevo espacio de nombres DNS de Windows Server 2003, debe seleccionarse un dominio DNS de Internet de nivel superior en el que registrar el nombre de dominio. Por ejemplo se puede registrar el dominio como un subdominio de .com, .org o .net, o como un subdominio del nombre de dominio que está asignado al país o región, como .au (Australia), .fr (Francia) o .ca (Canadá).

Después de seleccionar el nombre de dominio DNS de Internet e identificar el dominio de nivel superior del que el dominio DNS es un subdominio, deben realizarse los siguientes pasos para registrar el nombre de dominio:

  1. Haga una búsqueda en Internet para confirmar que el nombre de dominio seleccionado para la organización no ha sido registrado por otra organización. Si el nombre de dominio DNS seleccionado es propiedad de otra organización, puede intentar comprárselo o seleccionar un nombre de dominio diferente.
  2. Configure al menos un servidor DNS con autoridad para alojar la zona DNS del nombre de dominio. Este servidor se puede ubicar en la red interna o en la red del ISP.

Registre el nombre de dominio DNS en un registrador de Internet y proporcione al registrador el nombre DNS y la dirección IP de al menos un servidor DNS que tenga autoridad para el nombre de dominio. Si desea obtener una lista de los registradores de Internet, visite el vínculo de registradores acreditados por ICANN que se incluye en la página Recursos Web en la dirección http://www.microsoft.com/windows/reskits/webresources/ (en inglés).

El proceso de registro de nombres de dominio de Internet varía en función del diseño del espacio de nombres DNS. En la tabla 4.6 se enumeran los nombres de dominio que es necesario registrar para cada tipo de diseño de espacio de nombres DNS.

Tabla 4.6   Registro de nombres de dominio DNS de Internet

Diseño del espacio de nombres Registro de nombres de dominio Ejemplo
El nombre de dominio interno en un subdominio del dominio externo. Registre sólo el nombre de dominio externo. Para el espacio de nombres externo se utiliza el nombre de dominio contoso.com.

Para el espacio de nombres interno se utiliza el nombre de dominio corp.contoso.com.

Los nombres de dominio interno y externo no están relacionados entre sí. Registre los nombres de dominio interno y externo. Para el espacio de nombres externo se utiliza el nombre de dominio contoso01-ext.com.

Para el espacio de nombres interno se utiliza el nombre de dominio contoso.com.

El nombre de dominio interno es el mismo que el externo, pero la organización tiene un espacio de nombres privado. Registre el nombre de dominio interno y externo. El nombre de dominio contoso.com se utiliza para los espacios de nombres interno y externo.

Al registrar el nombre de dominio DNS, el registrador de Internet crea una delegación en la zona DNS que tiene autoridad para el dominio de nivel superior seleccionado. Éste es el dominio de nivel superior de los servidores DNS que tienen autoridad para el nombre de dominio DNS de Internet de la organización.

Nota   Si el nombre de dominio que se desea registrar no está disponible en un dominio de nivel superior, por ejemplo .com, no debe registrarse el mismo nombre en otro dominio de nivel superior, por ejemplo .net. Los usuarios que busquen el nombre de dominio pueden suponer que pertenecen a su empresa los equipos y servicios del dominio de nivel superior incorrecto.
Crear nombres de dominio DNS internos

Al crear nombres para los dominios internos, utilice las siguientes directrices:

  • Si la organización tienen presencia en Internet, utilice nombres relacionados con el nombre de dominio DNS de Internet registrado. Por ejemplo, si la organización tiene registrado el nombre de dominio DNS de Internet contoso.com, utilice un nombre de dominio como corp.contoso.com para el nombre de dominio de la intranet.
  • Para evitar problemas de resolución de nombres, no utilice como nombre de dominio el nombre de una entidad empresarial externa o el nombre de un producto.
  • No utilice en la intranet nombres de dominio de Internet de nivel superior (.com, .net, .org, .us, .fr, .gr, etc.). El uso de nombres de dominio de Internet de nivel superior para los nombres de dominio de la intranet puede producir errores en la resolución de los nombres de los equipos de la red que están conectados a Internet.
  • No utilice acrónimos o abreviaturas en los nombres de dominio. Las unidades de negocio que representan los acrónimos pueden ser difíciles de reconocer para los usuarios.
  • No utilice nombres de unidades de negocio o divisiones en los nombres de dominio. Las unidades de negocio y demás divisiones cambian de forma periódica, y los nombres de dominio pueden quedarse obsoletos o dar lugar a equivocaciones.
  • No utilice nombres geográficos que sean difíciles de escribir y recordar.
  • Evite que la jerarquía de nombres de dominio DNS se extienda más de cinco niveles a partir del dominio raíz interno o de Internet. Al limitar la extensión de la jerarquía de nombres de dominio se reducen los costes administrativos.

Si se va a implementar DNS en una red privada y no se planea crear un espacio de nombres externo, se recomienda registrar el nombre de dominio DNS que se cree para el dominio interno. Si no se registra el nombre y posteriormente se intenta utilizar en Internet, o se conecta a una red que está conectada a Internet, puede que el nombre no esté disponible.

Crear nombres de equipo DNS

Es importante desarrollar una convención de nombres de equipo DNS para la red. Esto permite que los usuarios recuerden con facilidad los nombres de los equipos que se encuentran en redes públicas y privadas, y facilita el acceso a los recursos de la red interna.

El proceso para crear nombres de equipo DNS varía en función de si se va a crear una infraestructura DNS nueva, integrar la infraestructura DNS con una infraestructura de terceros existente o actualizar una infraestructura DNS existente.

Crear nombres de equipo en una nueva infraestructura DNS de Windows Server 2003

Siga las siguientes directrices al crear nombres para los equipos DNS de la nueva infraestructura DNS de Windows Server 2003:

  • Seleccione nombres de equipo que sean fáciles de recordar para los usuarios.
  • Identifique el propietario del equipo en el nombre. Por ejemplo, juan-perez-1 indica que el equipo lo utiliza Juan Pérez.
  • Utilice nombres en los que se describa el propósito del equipo. Por ejemplo, un servidor de archivos llamado cuentas-antiguas-1 indica que en él se almacena información relacionada con cuentas antiguas.
  • No utilice mayúsculas y minúsculas para indicar el propietario o propósito de un equipo. En el sistema DNS no se distingue entre mayúsculas y minúsculas.
  • Utilice el nombre de dominio de Active Directory para el sufijo DNS principal del nombre de equipo. Si un equipo no está unido a un dominio, utilice un nombre de dominio de Internet registrado o un derivado de éste para el sufijo DNS principal.
  • Utilice nombres únicos para todos los equipos de la organización. No asigne el mismo nombre de equipo a distintos equipos de dominios DNS diferentes.
  • Utilice caracteres ASCII para asegurar la interoperabilidad con equipos en los que se ejecuten versiones de Windows anteriores a Windows 2000. Para los nombres de equipo DNS, utilice solamente los caracteres que se enumeran en el documento RFC 1123, "Requirements for Internet Hosts — Application and Support" (Requisitos de los hosts de Internet: aplicación y compatibilidad), entre los que se incluyen A–Z, a–z, 0–9 y el guión (-). DNS de Windows Server 2003 admite casi todos los caracteres UTF-8 en los nombres; sin embargo, no utilice caracteres ASCII extendidos o UTF-8 a menos que los admitan todos los servidores DNS del entorno.
Crear nombres de equipo en una infraestructura DNS integrada

Si va a integrar DNS de Windows Server 2003 con una infraestructura DNS de terceros existente, no es necesario que realice ningún cambio en los nombres de host DNS de dicha infraestructura. Si va a migrar a DNS de Windows Server 2003 desde una infraestructura DNS de terceros, debe asegurarse de que los nombres de host que se utilizan en la infraestructura de terceros son compatibles con los estándares de nomenclatura DNS de Internet.

Si va a integrar o migrar una infraestructura DNS pública que está conectada a Internet en la infraestructura DNS existente, no es necesario que realice ningún cambio en los nombres de dominio DNS de la infraestructura existente.

Crear nombres de equipo al actualizar una infraestructura DNS

Si se va a actualizar a DNS de Windows Server 2003 desde Windows NT 4.0, no es necesario cambiar los nombres de host DNS; sin embargo, es necesario convertir los nombres NetBIOS en nombres DNS. Ambos tipos de nombres deben ser compatibles con el estándar DNS de acuerdo con el documento RFC 1123, "Requirements for Internet Hosts — Application and Support" (Requisitos de los hosts de Internet: aplicación y compatibilidad). Esto incluye las letras mayúsculas (A-Z), las minúsculas (a-z), los números (0-9) y el guión (-).

En la tabla 4.7 se enumeran los diferentes conjuntos de caracteres que se admiten en DNS estándar, DNS de Windows Server 2003 y NetBIOS.

Tabla 4.7   Restricciones de los conjuntos de caracteres

Restricción del conjunto de caracteres DNS estándar (incluido Windows NT 4.0) DNS de Windows 2000 y Windows Server 2003 NetBIOS
Caracteres permitidos Compatible con RFC 1123, que permite las mayúsculas de la "A" a la "Z", las minúsculas de la "a" a la "z", los números del "0" al "9" y el guión (-). Compatible con RFC 1123 y UTF-8. Se puede configurar el servidor DNS de Windows 2000 para permitir o no el uso de caracteres UTF-8 en los servidores Windows 2000. Se puede hacer en cada servidor individualmente. No permitidos: caracteres Unicode, números, espacio en blanco y los símbolos / \ [ ] : | < > + = ; , ? y *)
Longitud máxima del nombre de host y FQDN 63 octetos por etiqueta. 255 bytes por FQDN (254 bytes para el FQDN más un byte para el punto final). Igual que DNS estándar más la compatibilidad con UTF-8. El recuento de caracteres no es suficiente para determinar el tamaño porque la longitud de algunos caracteres UTF-8 es superior a un octeto. Los controladores de dominio están limitados a 155 bytes para el FQDN. 15 bytes de longitud.
Importante   Los nombres codificados en formato UTF-8 no deben sobrepasar los límites definidos en el documento RFC 2181, "Clarifications to the DNS Specification" (Aclaraciones relativas a la especificación de DNS), en el que se especifica un tamaño máximo de 63 octetos por etiqueta y 255 octetos por nombre. El recuento de caracteres no es suficiente para determinar el tamaño porque la longitud de algunos caracteres UTF-8 es superior a un octeto.
Determinar si es necesario admitir nombres NetBIOS

Al actualizar el dominio a Windows Server 2003, puede ser necesaria la compatibilidad con NetBIOS en la red si el dominio incluye clientes que ejecutan versiones de Windows anteriores a Windows 2000. Por ejemplo, si la red está dividida en varios segmentos, es necesario utilizar WINS para crear la lista de búsqueda NetBIOS. Si no se utiliza WINS, la red debe depender de Active Directory para la búsqueda de los recursos. Esto puede tener un efecto significativo en los clientes que ejecuten versiones de Windows anteriores a Windows 2000.

DNS de Windows Server 2003 es compatible con WINS; por lo tanto, en un entorno de red mixto se puede utilizar una combinación de DNS y WINS. Esto permite mejorar la capacidad de la red para buscar recursos y servicios. Los clientes basados en Windows NT 4.0 se pueden registrar en WINS de Windows 2000 y WINS de Windows Server 2003. Además, los equipos que ejecuten Windows 2000 Professional o Windows® XP® Professional se pueden registrar en WINS de Windows NT 4.0. Para mantener la compatibilidad con versiones anteriores, cada equipo recibe un nombre NetBIOS que debe ser único en el dominio al que pertenece el equipo.

Puede ser difícil conservar los nombres NetBIOS existentes, ya que estos utilizan un conjunto de caracteres más amplio que los nombres DNS. Una solución consiste en reemplazar los nombres NetBIOS por nombres DNS para asegurar que cumplen los estándares de nomenclatura DNS existentes. Este proceso consume mucho tiempo y no es posible llevarlo a cabo en aquellas organizaciones que tengan equipos con versiones de Windows anteriores a Windows 2000.

En el documento RFC 2181, "Clarifications to the DNS Specification" (Aclaraciones relativas a la especificación de DNS) se amplía el conjunto de caracteres permitido en los nombres DNS para incluir cualquier cadena binaria. Las cadenas binarias no tienen que interpretarse como caracteres ASCII. En Windows 2000 y Windows Server 2003 se admite la codificación de caracteres UTF-8 (RFC 2044). UTF-8 es un supraconjunto del conjunto de caracteres ASCII y una traducción de la codificación de caracteres UCS-2 (Unicode). El conjunto de caracteres UTF-8 permite llevar a cabo la transición de los nombres NetBIOS de Windows NT 4.0 a nombres DNS de Windows 2000 y Windows Server 2003.

De forma predeterminada se utiliza la comprobación de nombres UTF-8 multibyte. De esta forma se proporciona la máxima tolerancia cuando el servicio DNS procesa los caracteres. Éste es el método preferido para la comprobación de nombres en la mayoría de los servidores DNS privados que no ofrecen un servicio de nombres para los hosts de Internet.

Importante   En DNS de Windows Server 2003 y Windows 2000 se admiten caracteres NetBIOS y UTF-8 para los nombres de equipo. En otras versiones de DNS sólo se admiten los caracteres permitidos en el documento RFC 1123. Por ello, sólo deben utilizarse los caracteres NetBIOS y UTF-8 si se tiene la seguridad de que el método utilizado para la resolución de nombres es DNS de Windows Server 2003 o Windows 2000. Los nombres que estén orientados a ser visibles en Internet deben contener únicamente caracteres ASCII, según se recomienda en el documento RFC 1123.
Ejemplo: combinación de espacios de nombres DNS

Contoso Corporation se ha fusionado con Acquired Corporation. Antes de la fusión, cada una de las empresas utilizaba dominios internos que eran subdominios de sus dominios externos. En Contoso Corporation se utilizaba una raíz privada para simplificar la administración de los servidores DNS. En Acquired Corporation, las consultas se reenviaban a Internet en lugar de utilizar una raíz privada, ya que no deseaban crear y administrar listas de exclusiones ni archivos PAC.

El espacio de nombres externo de la nueva empresa resultante de la fusión contiene las zonas contoso.com y acquired01-ext.com. Cada zona del espacio de nombres externo contiene los registros de recursos DNS que las compañías desean exponer a Internet. El espacio de nombres interno contiene las zonas internas corp.contoso.com y corp.acquired01-ext.com.

La división de Contoso y la división de Acquired utilizan métodos diferentes para admitir la resolución de nombres en su espacio de nombres. La división de Contoso utiliza el nombre contoso.com externamente y corp.contoso.com internamente. La zona raíz se aloja en los servidores raíz internos. En los servidores internos se aloja también la zona corp.contoso.com. El nombre contoso.com está registrado en una entidad de registro de nombres de Internet.

Con el fin de asegurar que todos los clientes internos de la organización pueden resolver todos los nombres de la nueva organización fusionada, la zona raíz privada contiene una delegación de la zona del nivel superior del espacio de nombres interno de la organización fusionada, corp.acquired01-ext.com.

Todos los equipos de la división de Contoso admiten listas de exclusiones o archivos PAC. Para resolver los nombres internos y externos, todos los clientes DNS deben enviar las consultas a los servidores DNS internos o a un servidor proxy, en función de una lista de exclusiones o un archivo PAC. En la figura 4,4 se muestra esta configuración.


Si su explorador no admite los marcos en línea, haga clic aquí para abrir una página independiente.

Figura 4.4   Resolución de nombres en la división de Contoso

Con base en esta configuración, los clientes internos pueden consultar nombres de las siguientes maneras:

  • Consultar nombres internos en servidores DNS internos. La consulta se resuelve en los servidores DNS internos. Si un servidor DNS que recibe una consulta no contiene los datos solicitados en sus zonas o caché, se pone en contacto con los servidores DNS raíz internos para realizar una resolución de nombres recursiva.
  • Consultar nombres de Internet en un servidor proxy. El servidor proxy reenvía la consulta a los servidores DNS de Internet. La consulta se resuelve en los servidores DNS de Internet.
  • Consultar nombres del espacio de nombres externo de la división de Contoso en un servidor proxy. El servidor proxy reenvía la consulta a los servidores DNS de Internet. La consulta se resuelve en los servidores DNS de Internet.
  • Consultar nombres de la división de Acquired en servidores DNS internos. Puesto que los servidores raíz contienen una delegación del nivel superior del espacio de nombres DNS de la división de Acquired, los servidores DNS internos resuelven la consulta de forma recursiva poniéndose en contacto con los servidores DNS de la división de Acquired.

Clientes externos:

  • No pueden consultar nombres internos. Esta limitación ayuda a proteger la red interna.
  • Consultar nombres del espacio de nombres externo de la división de Contoso en servidores DNS de Internet. La consulta se resuelve en los servidores DNS de Internet.

En la división de Acquired se utiliza el nombre acquired01-ext.com externamente y el nombre corp.acquired01-ext.com internamente. En el servidor InternalDNS.corp.acquired01-ext.com se aloja la zona corp.acquired01-ext.com. La división de Acquired no dispone de una raíz privada.

Para simplificar la administración de los clientes y servidores DNS, los administradores de la división de Acquired han decidido utilizar el reenvío condicional. Los administradores han configurado el servidor DNS InternalDNS.corp.acquired01-ext.com para reenviar las consultas de la manera siguiente:

  • El servidor reenvía todas las consultas dirigidas a la división de Contoso a un servidor DNS de la división de Contoso. Por ejemplo, las consultas dirigidas a corp.contoso.com se reenvían a InternalDNS.corp.contoso.com.
  • Al mismo tiempo, las demás consultas dirigidas a contoso.com se reenvían a un servidor DNS de Internet.

En la figura 4.5 se muestra esta configuración.

rksdns05

Figura 4.5   Reenvío condicional en la división de Acquired

Diseñar servidores DNS

En los servidores DNS se almacena información acerca del espacio de nombres que se utiliza para responder a las consultas de los clientes DNS. Algunos factores que afectan a la topología de servidores DNS son la ubicación donde se desea almacenar la información acerca de la parte del espacio de nombres DNS, el número de clientes DNS y la ubicación física de los mismos.

El planeamiento del diseño de los servidores DNS permite crear una distribución eficaz de los datos DNS y actualizar la topología, además de minimizar el tráfico de distribución y actualización en la red. En la figura 4.6 se muestra el proceso que es preciso seguir para diseñar servidores DNS.


Si su explorador no admite los marcos en línea, haga clic aquí para abrir una página independiente.

Figura 4.6   Diseño de servidores DNS

Asignar recursos de hardware

A la hora de asignar recursos de hardware para los servidores DNS, deben tenerse en cuenta las siguientes recomendaciones básicas:

  • Equipos con procesador dual y CPU Pentium II a 400 MHz
  • 256 MB de memoria RAM para cada procesador
  • Discos duros de 4 GB

El uso de CPU más rápidas, más memoria RAM y discos duros de mayor tamaño mejora la escalabilidad y el rendimiento de los servidores DNS. Tenga en cuenta que los servidores DNS utilizan aproximadamente 100 bytes de memoria RAM para cada registro de recursos.

Se pueden utilizar equipos con procesador dual para mejorar el rendimiento de los servidores DNS mediante la asignación del servicio Servidor DNS al primer procesador y los procesos de base de datos, como las transferencias de zonas, al segundo procesador.

Determinar el número de servidores DNS necesarios

Para reducir la sobrecarga administrativa, utilice el número mínimo de servidores DNS necesarios. Asegúrese de establecer al menos dos servidores DNS con autoridad para cada zona con el fin de habilitar la tolerancia a errores y el uso compartido de la carga.

Agregue servidores DNS adicionales para lograr los siguientes objetivos:

  • Proporcionar redundancia cuando el diseño del espacio de nombres requiera mayor disponibilidad de DNS.
  • Mejorar el tiempo de respuesta a las consultas cuando sea necesario mayor rendimiento de DNS.
  • Reducir el tráfico WAN de las ubicaciones remotas.

Utilice las siguientes directrices para determinar el número de servidores DNS que se deben implementar:

  • Si tiene un gran número de clientes, agregue servidores DNS adicionales para alojar zonas secundarias o integradas de Active Directory. Calcule el número previsto de consultas y actualizaciones dinámicas por segundo. El servicio Servidor DNS de Windows Server 2003 puede responder a más de 10.000 consultas por segundo en un equipo con microprocesador Pentium III a 700 MHz.

Para obtener información acerca de cómo planear la capacidad, consulte la sección "Asignar recursos de hardware" anteriormente en este capítulo.

  • Si se delegan zonas, agregue servidores DNS adicionales para controlarlas. Observe que si tiene múltiples zonas no es necesario delegarlas. Puede alojar todas las zonas en el mismo servidor o servidores. En un solo servidor DNS de Windows Server 2003 se pueden alojar 200.000 zonas que contengan 6 registros de recursos.
  • Si planea utilizar zonas integradas de Active Directory, debe alojarlas en servidores DNS.
  • Si no se van a utilizar zonas integradas de Active Directory, las transferencias de zonas y el tráfico de consultas DNS pueden sobrecargar los vínculos lentos. Si el volumen elevado de tráfico es un problema en el entorno, agregue servidores DNS adicionales para proporcionar equilibrio de la carga. Aunque DNS está diseñado para ayudar a reducir el tráfico de difusión entre las subredes locales, genera tráfico entre los servidores y clientes que se debe tener en cuenta, especialmente en entornos enrutados complejos. Además, a pesar de que el servicio DNS admite Transferencias de zona incrementales (IXFR) y los clientes y servidores pueden almacenar en la caché los nombres utilizados recientemente, en ocasiones las consideraciones de tráfico siguen siendo un problema. Esto se aplica especialmente a las concesiones DHCP de corta duración, que requieren actualizaciones dinámicas más frecuentes.
  • Si tiene una red LAN enrutada con vínculos confiables de alta velocidad, un servidor DNS puede ser suficiente para una área de red de mayor tamaño que incluya varias subredes.
  • Si cuenta con un número elevado de nodos cliente en una única subred, el uso de varios servidores DNS en la subred ofrece la posibilidad de tener servicios de copia de seguridad y conmutación por error en el caso de que el servidor DNS preferido deje de responder.

Si el diseño DNS incluye zonas principales y secundarias, y se ejecuta un gran número de servidores secundarios en una zona, el servidor de nombres maestro principal puede sobrecargarse cuando tenga lugar el sondeo de los servidores secundarios para asegurarse de que sus datos de zona están actualizados. Este problema se puede resolver de tres maneras:

  • Utilice algunos de los servidores secundarios como servidores maestros de la zona. Los demás servidores secundarios pueden sondear y solicitar actualizaciones de zona en los servidores maestros.
  • Incremente el intervalo de actualización de forma que los servidores secundarios lleven a cabo el sondeo con menos frecuencia. Sin embargo, observe que al prolongar el intervalo de actualización las zonas secundarias quedan obsoletas con más frecuencia.
  • Cree servidores DNS sólo de almacenamiento en caché. Las ubicaciones remotas pueden obtener ventajas de un servidor DNS local de sólo almacenamiento en caché, además de los servidores DNS que se hayan agregado para asegurar la disponibilidad.
Determinar la colocación de los servidores DNS

La colocación de los servidores DNS y el número de servidores que se implementen afecta a la disponibilidad, seguridad y rendimiento de DNS. Es importante asegurarse de que la colocación de los servidores DNS se planea para prever la disponibilidad de DNS y Active Directory.

Colocar servidores DNS para disponibilidad

Con el fin de garantizar que DNS siempre está disponible, asegúrese de que la infraestructura DNS no incluye ningún punto de error único. Para mejorar la tolerancia a errores y el uso compartido de la carga, cree al menos dos servidores DNS con autoridad para cada zona, de una de las siguientes maneras:

  • Si tiene una red LAN, coloque los dos servidores DNS en subredes independientes.
  • Si tiene una red WAN, coloque los servidores DNS con autoridad para cada zona en redes diferentes.

Asegúrese de que al menos uno de los servidores DNS está disponible para cada red. Esta precaución elimina los enrutadores como un punto de error. Si es posible, distribuya los servidores DNS en ubicaciones geográficas diferentes. Esto permite que las comunicaciones no se interrumpan en el caso de que se produzca un desastre natural.

Si se identifican puntos de error únicos en la red, determine si afectan sólo a DNS o a todos los servicios de red. Si un enrutador queda inactivo y los clientes no pueden tener acceso a los servicios de red, los errores de DNS no suponen ningún problema. Si un enrutador queda inactivo y los servidores DNS locales no están disponibles, pero sí lo están otros servicios de red, los clientes no pueden tener acceso a los recursos de red necesarios porque no pueden consultar nombres DNS.

Si dispone de presencia en Internet, DNS debe funcionar correctamente para que los clientes tengan acceso a los servidores Web, envíen correo y busquen otros servicios; por ello se recomienda ejecutar un servidor DNS secundario fuera del sitio. Si mantiene relaciones comerciales con una organización en Internet, ya sean socios comerciales o ISP, puede que acepten ejecutar el servidor secundario; sin embargo, asegúrese de que los datos del servidor de la organización están protegidos de los ataques de Internet.

Para asegurar que DNS está disponible si los servidores DNS principales del sitio quedan inactivos, considere la posibilidad de implementar un servidor DNS secundario fuera del sitio. Esta medida de precaución se recomienda incluso si no dispone de presencia en Internet.

Colocar servidores DNS para disponibilidad de Active Directory

La disponibilidad de DNS afecta directamente a la disponibilidad de Active Directory. Los clientes dependen de DNS para buscar los controladores de dominio y éstos dependen de DNS para buscar otros controladores de dominio. Por esta razón, puede que sea necesario ajustar el número y la colocación de los servidores DNS para cubrir las necesidades de los clientes y controladores de dominio de Active Directory.

La mejor solución es colocar al menos un servidor DNS en cada sitio. Asegúrese de que los servidores DNS del sitio tienen autoridad para los registros del ubicador de los dominios del sitio, de forma que los clientes no tengan que consultar servidores DNS fuera del sitio para buscar los controladores de dominio que se encuentran en él. Los controladores de dominio comprueban periódicamente que las entradas de cada registro del ubicador son correctas.

Nota   Se puede ejecutar el servicio Servidor DNS de Windows Server 2003 en uno o varios controladores de dominio en cada sitio y, después, agregar zonas integradas de Active Directory para el nombre de zona que corresponda al dominio de Active Directory. Esta sencilla configuración cubre todos los requisitos. Por lo general, el tráfico de replicación adicional que se crea al agregar DNS a un controlador de dominio es mínimo.
Utilizar el reenvío

Si un servidor DNS está configurado correctamente pero no puede resolver una consulta mediante su caché o zonas, reenvía la consulta a otro servidor, denominado reenviador. Los reenviadores son servidores DNS normales y no requieren ninguna configuración especial; su denominación de reenviadores obedece a que son los destinatarios de consultas reenviadas por otro servidor DNS.

El reenvío es útil para el tráfico de fuera del sitio o de Internet. Por ejemplo, un servidor DNS de una sucursal puede reenviar todo el tráfico de fuera del sitio a un reenviador de la oficina principal y un servidor DNS interno puede reenviar todo el tráfico de Internet a un reenviador de Internet. Para asegurar la disponibilidad, es conveniente reenviar las consultas a varios reenviadores.

Utilice reenviadores en cadena para limitar el número de servidores que deben enviar las consultas fuera del sitio. Por ejemplo, los servidores DNS internos pueden reenviar todas las consultas a uno o dos reenviadores, que a su vez las reenvían a un servidor de Internet. De esta forma no es necesario que los servidores DNS internos realicen las consultas directamente en Internet. Dependiendo de los modelos de tráfico, el uso de reenviadores puede reducir al mínimo la cantidad de tráfico de fuera del sitio en la organización.

Los reenviadores proporcionan también seguridad de red adicional al minimizar la lista de los servidores DNS que se pueden comunicar a través de un servidor de seguridad.

Para controlar el proceso de resolución de nombres con mayor granularidad se puede utilizar el reenvío condicional. Éste permite asignar dominios específicos a los reenviadores. El reenvío condicional se puede utilizar para resolver los siguientes tipos de consultas:

  • Consultas de nombres en dominios internos fuera del sitio
  • Consultas de nombres en otros espacios de nombres
Utilizar el reenvío condicional para consultar nombres de dominios internos fuera del sitio

El reenvío condicional permite que los servidores consulten nombres de dominios internos fuera del sitio para eliminar el tráfico de WAN innecesario de las consultas. En DNS de Windows Server 2003, los servidores que no son raíz resuelven nombres para los que no tienen autoridad, no tienen delegación y que no se encuentran en su caché, mediante una de las siguientes acciones:

  • Consulta de un servidor raíz.
  • Reenvío de las consultas a un reenviador.

Esto genera tráfico de red adicional. Por ejemplo, un servidor que no es raíz en el sitio A está configurado para reenviar las consultas a un reenviador del sitio B y debe resolver un nombre de una zona alojada en un servidor del sitio C. Dado que el servidor que no es raíz sólo puede reenviar las consultas al sitio B, no tiene la posibilidad de consultar directamente el servidor del sitio C. En su lugar, reenvía la consulta al reenviador del sitio B y éste consulta el servidor del sitio C.

Si se utiliza el reenvío condicional se pueden configurar los servidores DNS para que reenvíen las consultas a distintos servidores en función del nombre de dominio especificado en la consulta. De esta forma se eliminan pasos en la cadena de reenvío y se reduce el tráfico de red. Al aplicar el reenvío condicional, el servidor del sitio A puede reenviar las consultas a los reenviadores del sitio B o C, según corresponda.

Por ejemplo, los equipos del sitio de Sevilla de Contoso Corporation deben consultar equipos del sitio de la Región Administrativa Especial (RAE) de Hong Kong, en Asia. Ambos sitios utilizan un servidor raíz DNS común, DNS3.Seville.avionics01-int.com, que está ubicado en Seattle.

Antes de que Contoso actualizara a Windows Server 2003, el servidor de Sevilla reenviaba todas las consultas que no podía resolver a su servidor principal, DNS1.avionics01-int.com, ubicado en Seattle. Cuando el servidor de Sevilla consultaba nombres del dominio Avionics (en la RAE de Hong Kong y Tokio), primero reenviaba las consultas a Seattle.

Después de actualizar a Windows Server 2003, los administradores configuraron el servidor DNS de Sevilla para reenviar las consultas dirigidas al sitio de la RAE de Hong Kong directamente a un servidor de dicho sitio, en lugar de desviarlas primero a Seattle, como se muestra en la figura 4.7.


Si su explorador no admite los marcos en línea, haga clic aquí para abrir una página independiente.

Figura 4.7   Reenvío condicional a un servidor fuera del sitio

Los administradores configuraron DNS3.Seville.avionics01-int.com para que las consultas dirigidas a acquired01-int.com se reenviaran a DNS5.acquired01-int.com o DNS6.acquired01-int.com. El servidor DNS3.Seville.avionics01-int.com reenvía las demás consultas a DNS1.avionics01-int.com o DNS2.avionics01-int.com.

Para obtener más información acerca del reenvío condicional, vea "Windows Server 2003 DNS" (DNS de Windows Server 2003) en el manual Networking Guide (Guía de redes) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003), o consulte "Windows Server 2003  DNS" (DNS de Windows Server 2003) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).

Utilizar el reenvío condicional para realizar consultas en otros espacios de nombres

Si no se dispone de una raíz privada en la red interna y los usuarios necesitan tener acceso a otros espacios de nombres, por ejemplo una red perteneciente a una empresa asociada, utilice el reenvío condicional para permitir que los servidores realicen consultas en otros espacios de nombres.

Antes de que estuviera disponible el reenvío condicional, los servidores DNS sólo podían reenviar las consultas a un servidor. Debido a esta limitación, era habitual que se configuraran los servidores para reenviar a un servidor de Internet todas las consultas que no podían resolver (todas las consultas fuera de su espacio de nombres). De esa forma, los servidores DNS internos podían resolver los nombres del espacio de nombres interno y del espacio de nombres de Internet. Sin embargo, para la resolución en otros espacios de nombres, todos los servidores DNS que alojaban el dominio de nivel superior de la empresa tenían que alojar también una zona secundaria para el dominio de nivel superior de la empresa asociada. Esta solución requería más espacio de almacenamiento en el servidor DNS y tráfico adicional de transferencia de zonas. Con el reenvío condicional, los servidores DNS pueden reenviar las consultas a diferentes servidores en función del nombre de dominio, lo que elimina la necesidad de utilizar zonas secundarias.

Por ejemplo, Contoso Corporation cuenta con dos espacios de nombres: Contoso y Acquired. Los equipos de cada división necesitan tener acceso al otro espacio de nombres. Además, los equipos de ambas divisiones necesitan tener acceso a los equipos del espacio de nombres privado del proveedor Supplier.

Antes de actualizar a Windows Server 2003, la división de Acquired creó zonas secundarias para asegurar que los equipos de los espacios de nombres de Contoso y Acquired podían resolver los nombres de los espacios de nombres de Contoso, Acquired y Supplier. Después de actualizar a Windows Server 2003, la división de Acquired eliminó sus zonas secundarias y configuró el reenvío condicional en su lugar.

Actualizar servidores DNS a DNS de Windows Server 2003

Los servidores DNS se pueden actualizar a DNS de Windows Server 2003 de dos maneras:

  • Realizando una actualización en contexto desde DNS de Windows NT 4.0 o Windows 2000 a DNS de Windows Server 2003.
  • Migrando un servidor completo.

Haga una copia de seguridad de la configuración existente de forma que se pueda restaurar si se produce algún error. Planee la migración de forma que los clientes tengan acceso a un servidor DNS en todo momento. Por ejemplo, puede retrasar la desconexión del servidor DNS existente hasta que esté seguro de que el servidor DNS de Windows Server 2003 funciona correctamente.

Después de actualizar o migrar los servidores, pruébelos para asegurarse de que funcionan correctamente. Para obtener más información acerca de cómo probar el rendimiento de los servidores DNS, vea "Monitor Servers" (Supervisar servidores) en el Centro de ayuda y soporte técnico de Windows Server 2003 y "Troubleshooting Windows Server 2003 DNS" (Solucionar problemas de DNS de Windows Server 2003) en el manual Networking Guide (Guía de redes) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003), o consulte "Troubleshooting Windows Server 2003  DNS" (Solucionar de problemas de DNS de Windows Server 2003) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).

Migrar servidores DNS de terceros a DNS de Windows Server 2003

Si se van a migrar servidores DNS que no son de Microsoft a DNS de Windows Server 2003, deben introducirse primero servidores DNS de Windows Server 2003 como servidores secundarios para las zonas superpuestas. Configure una transferencia de zona desde los servidores DNS principales de terceros a los servidores DNS secundarios de Windows Server 2003. Después de transferir las zonas, asegúrese de que no se ha generado ningún error en el proceso de transferencia. Se pueden producir errores durante el proceso de transferencia de zonas si el servidor DNS de Windows Server 2003 no puede reconocer los registros enviados por el servidor DNS de terceros. Modifique los registros de terceros de la zona para que sean compatibles con DNS de Windows Server 2003 o elimínelos para asegurar que la transferencia de zona se lleva a cabo correctamente.

Después de comprobar que las zonas se han transferido a los servidores DNS de Windows Server 2003, actualice las zonas secundarias a zonas integradas de Active Directory. A continuación, puede retirar de la red de forma segura los servidores DNS de terceros.

Nota   Si se utiliza el archivo de inicio de BIND con el servicio DNS de Windows Server 2003 son aplicables otras limitaciones al uso de ese archivo en el servicio DNS. Por ejemplo, no se admiten algunas directivas de inicio de BIND. Para obtener más información acerca de cómo utilizar los archivos de inicio de BIND con DNS de Windows Server 2003, consulte el vínculo de Microsoft Knowledge Base de la página Recursos Web en la dirección http://support.microsoft.com/default.aspx?scid=fh;EN-US;kbhowto&sd=GN&ln=EN-US&FR=1 y busque los artículos Q194513, "The Structure of a Domain Name System Boot File", y Q234144, "DNS Boot File Directives and Configuration for Windows NT 4.0" (en inglés).
[subir]
Diseñar zonas DNS

Cada tipo de zona que está disponible en DNS de Windows Server 2003 tiene un propósito específico. Para seleccionar el tipo de zona que se debe implementar es necesario determinar el propósito práctico de la misma.

En la figura 4.8 se muestra el proceso que es preciso seguir para diseñar zonas DNS.

rksdns08

Figura 4.8 Diseño de zonas DNS

Elegir un tipo de zona

Las zonas deben diseñarse en correspondencia con la infraestructura de administración de la red. Si un sitio de la red se administra de forma local, implemente una zona para el subdominio. Si un departamento tiene un subdominio pero no un administrador, mantenga el subdominio en la zona principal. Planee zonas de búsqueda inversa si es necesario y decida si las zonas se almacenarán en Active Directory. En Active Directory, los datos se distribuyen según un modelo de replicación multifuncional que ofrece mayor seguridad que el DNS estándar. En Active Directory se pueden almacenar todos los tipos de zonas a excepción de las zonas secundarias. Al diseñar las zonas DNS, aloje cada una de ellas en varios servidores DNS.

Decida qué tipo de zona se debe utilizar en función de la estructura de dominios. Para cada tipo de zona, con la excepción de las zonas secundarias, decida si se implementarán zonas basadas en archivos o zonas integradas de Active Directory.

Zonas principales

Implemente zonas principales en correspondencia con los nombres de dominio DNS planeados. No se puede almacenar una copia de la misma zona principal integrada de Active Directory y basada en archivos.

Zonas secundarias

Agregue zonas secundarias si no dispone de una infraestructura de Active Directory. Si no cuenta con esta infraestructura, utilice zonas secundarias en los servidores DNS que no ofrecen servicio como controladores de dominio. Una zona secundaria contiene una copia completa de una zona. Por lo tanto, utilice zonas secundarias para mejorar la disponibilidad de las zonas en sitios remotos si no desea que los datos de zona se repliquen a través de un vínculo WAN mediante la replicación de Active Directory.

Es conveniente agregar zonas secundarias para la mayoría de las zonas principales, o todas. Este diseño permite disponer de tolerancia a errores, distribución geográfica de los hosts de la red y equilibrio de la carga.

Zonas de rutas internas

Una zona de rutas internas es una copia de una zona que sólo contiene el registro de recursos de inicio de autoridad (SOA) de la zona original, los registros de recursos de servidor de nombres (NS) en los que se enumeran los servidores con autoridad para la zona y los registros de recursos de adherencia de host (A) necesarios para identificar los servidores con autoridad.

Un servidor DNS que aloje una zona de rutas internas se configuran con la dirección IP del servidor con autoridad desde el que se carga. El servidor puede actualizar manualmente la zona de rutas internas. Cuando un servidor DNS que aloja una zona de rutas internas recibe una consulta de un nombre de equipo de la zona a la que hace referencia la zona de rutas internas, el servidor DNS utiliza la dirección IP para consultar el servidor con autoridad o, si la consulta es iterativa, devuelve una referencia a los servidores DNS enumerados en la zona de rutas internas. Los servidores DNS pueden utilizar zonas de rutas internas para las consultas iterativas y recursivas.

Las zonas de rutas internas se actualizan a intervalos regulares determinados por el intervalo de actualización del registro de recursos SOA de la zona de rutas internas. Cuando un servidor DNS carga una zona de rutas internas, consulta los servidores maestros de la zona en busca de los registros de recursos SOA, los registros de recursos NS de la raíz de la zona y los registros de recursos A. El servidor DNS intenta actualizar sus registros de recursos al final del intervalo de actualización del registro de recursos SOA. Para actualizar sus registros, el servidor DNS consulta los servidores maestros en busca de los registros de recursos enumerados anteriormente.

Las zonas de rutas internas se pueden utilizar para asegurar que el servidor DNS que tiene autoridad para una zona principal recibe automáticamente actualizaciones acerca de los servidores de nombres con autoridad para una zona secundaria. Para ello, debe agregarse la zona de rutas internas al servidor que aloja la zona principal. Las zonas de rutas internas pueden estar basadas en archivos o integradas en Active Directory. Si se utilizan zonas de rutas internas integradas en Active Directory se pueden configurar en un equipo y dejar que la replicación de Active Directory las propague a otros servidores DNS que se ejecuten en controladores de dominio.

Las zonas de rutas internas se pueden utilizar también para que los servidores tengan conocimiento de otros espacios de nombres, si bien para este fin es preferible el método de reenvío condicional. Para obtener más información acerca de cómo utilizar las zonas de rutas internas, vea el Centro de ayuda y soporte técnico de Windows Server 2003.

Nota   Las zonas de rutas internas sólo se admiten en DNS de Windows Server 2003.
Zonas de búsqueda inversa

Las zonas de búsqueda inversa contienen información necesaria para realizar las búsquedas inversas. En estas búsquedas se utiliza la dirección IP del equipo para buscar el nombre DNS correspondiente. Las zonas de búsqueda inversa no son necesarias en las redes Windows ni para la compatibilidad con Active Directory.

Para obtener más información acerca de las zonas de búsqueda inversa, vea el Centro de ayuda y soporte técnico de Windows Server 2003.

Si en la topología DNS se incluye Active Directory, utilice zonas integradas de Active Directory. Puesto que la replicación DNS se lleva a cabo con un servidor principal único, un servidor DNS principal de una zona DNS principal estándar puede constituir un punto de error único. En una zona integrada de Active Directory, un servidor DNS principal no puede constituir un punto de error único, ya que Active Directory utiliza la replicación multifuncional. Las actualizaciones que se llevan a cabo en un controlador de dominio se replican en todos los controladores de dominio y la información de zona de los servidores DNS principales de una zona integrada de Active Directory se replica siempre. Las zonas integradas de Active Directory ofrecen las siguientes ventajas:

  • Permiten proteger zonas mediante la actualización dinámica segura.
  • Proporcionan mayor tolerancia a errores. Todas las zonas integradas de Active Directory se pueden replicar en todos los controladores de dominio del dominio o bosque de Active Directory. Todos los servidores DNS que se ejecuten en los controladores de dominio pueden actuar como servidores principales de la zona y aceptar actualizaciones dinámicas.
  • Permiten la replicación que propaga únicamente los datos modificados, comprimen los datos replicados y reducen el tráfico de red.

Si tiene una infraestructura de Active Directory, sólo puede utilizar las zonas integradas de Active Directory en los controladores de dominio de Active Directory. Si utiliza las zonas integradas de Active Directory, debe decidir si éstas se almacenarán en la partición del directorio de aplicaciones.

En el mismo diseño se pueden combinar zonas integradas de Active Directory y zonas basadas en archivos. Por ejemplo, si el servidor DNS que tiene autoridad para la zona raíz privada ejecuta un sistema operativo distinto de Windows Server 2003 o Windows 2000, no puede actuar como controlador de dominio de Active Directory. Así pues, en ese servidor se deben utilizar las zonas basadas en archivos. Sin embargo, la zona se puede delegar en un controlador de dominio que ejecute Windows Server 2003 o Windows 2000.

Por ejemplo, los administradores de una empresa que necesitan implementar Active Directory han examinado los requisitos DNS de compatibilidad con Active Directory y han descubierto que el servidor DNS con autoridad para el nombre (supplier01-int.com) se ejecuta en un servidor BIND 4.9.7 que no es compatible con Active Directory. Han decidido agregar una delegación de la zona basada en archivos, supplier01-int.com, alojada en el servidor BIND. La delegación hace referencia a un servidor Windows Server 2003, partner.supplier01-int.com, con autoridad para la zona. Este servidor actúa también como controlador de dominio. De esta forma, los administradores han convertido la zona, partner.supplier01-int.com, en una zona integrada de Active Directory.

Elegir un método de replicación

Después de decidir qué zona se aloja en cada servidor, debe decidirse cómo replicar las zonas entre los servidores. Las zonas replicadas ofrecen mayor disponibilidad, mejoran el tiempo de respuesta a las consultas y reducen el tráfico de red generado por las consultas de nombres; sin embargo, las zonas replicadas requieren espacio de almacenamiento y aumentan el tráfico de red. Si la red está distribuida y se administra en diferentes sitios, utilice subdominios para los sitios. En el caso de que no tenga una red distribuida, evite utilizar subdominios si es posible.

El diseño de la replicación de zonas incluye identificar dónde se deben utilizar zonas replicadas con fines de redundancia y disponibilidad.

En Windows Server 2003, las zonas se pueden replicar mediante la transferencia de zona basada en archivos o la replicación de Active Directory. Seleccione el método de replicación de zonas correcto de acuerdo con las siguientes indicaciones:

  • Si utiliza zonas basadas en archivos, use la transferencia de zona basada en archivos.
  • Si tiene zonas integradas de Active Directory en Windows Server 2003 y Windows 2000, utilice la replicación de Active Directory. Si utiliza zonas integradas de Active Directory en un dominio de Windows Server 2003, debe establecer el ámbito de replicación.
Transferencia de zona basada en archivos

En DNS de Windows Server 2003 y Windows 2000 se admite la transferencia de zona incremental y completa de las zonas basadas en archivos. La transferencia de zona incremental es el método predeterminado, pero si este método no se admite en un servidor DNS de terceros participante en la transferencia, DNS de Windows Server 2003 y Windows 2000 utilizan como predeterminado el método de transferencia de zona completa.

La transferencia de zona incremental, que se describe en el documento RFC 1995, "Incremental Zone Transfer in DNS" (Transferencia de zona incremental en DNS), ofrece un mejor uso del ancho de banda de red disponible. En lugar de enviar todo el contenido del archivo de zona, el servidor maestro sólo transfiere los cambios incrementales de la zona. Esto reduce el impacto de las transferencias de zona DNS en el tráfico de la red. Sin las transferencias de zona incrementales, el servidor maestro transfiere el archivo de zona completo al servidor secundario cada vez que se actualiza una zona DNS.

En DNS de Windows Server 2003 se utiliza la transferencia de zona completa cuando las zonas deben transferirse a servidores DNS que no admiten la transferencia incremental, como los servidores DNS que ejecutan Windows NT 4.0 o BIND 8.12 y versiones anteriores.

Replicación de Active Directory

La replicación de Active Directory propaga los cambios de las zonas entre los controladores de dominio. El procesamiento de la replicación es distinto de las transferencias de zona completas, en las que el servidor DNS transfiere toda la zona. El procesamiento de la replicación es distinto también de las transferencias de zona incrementales, en las que el servidor transfiere todos los cambios realizados desde la última vez.

La replicación de zonas de Active Directory proporciona las siguientes ventajas adicionales:

  • El tráfico de red se reduce porque los controladores de dominio sólo envían el resultado final de todos los cambios.
  • Cuando una zona está almacenada en Active Directory, la replicación tiene lugar automáticamente. No es necesaria configuración adicional.
  • Cuando la replicación de zonas de Active Directory se produce entre sitios, los datos de zona que superan el tamaño de transferencia predeterminado se comprimen de forma automática antes de la transferencia. Esta compresión reduce la carga de tráfico de la red.

Tras un análisis detenido se pueden crear particiones de las zonas DNS y delegarlas, según sea necesario para proporcionar un servicio de nombres eficaz y con tolerancia a errores en cada ubicación o sitio.

Si utiliza zonas integradas de Active Directory en un dominio de Windows Server 2003, debe seleccionar un ámbito de replicación de zonas integradas de Active Directory mediante MMC. Al seleccionar un ámbito de replicación, observe que cuanto más amplio sea el ámbito, mayor será el tráfico de red generado por la replicación. Por ejemplo, si elige replicar los datos de zonas integradas de Active Directory en todos los servidores DNS del bosque, se generará más tráfico de red que si se replican los datos de las zonas en todos los servidores DNS de un único dominio de Active Directory de ese bosque. Sopese la necesidad de minimizar el tráfico de replicación con la necesidad de minimizar el tráfico de consultas de zona.

En la tabla 4.8 se enumeran las opciones de replicación de los datos de zonas integradas de Active Directory.

Tabla 4.8   Opciones de replicación de los datos de zonas integradas de Active Directory

Opción Descripción Cuándo utilizarla
Todos los servidores DNS del bosque de Active Directory Los datos de zona se replican en todos los servidores DNS que se ejecutan en los controladores de dominio basados en Windows Server 2003 de todos los dominios del bosque de Active Directory. Se desea el ámbito de replicación más amplio. En general, esta opción genera la mayor cantidad de tráfico de replicación de zona. Observe que esta opción sólo se puede elegir si se ejecuta Windows Server 2003 en todos los servidores DNS que alojan una copia de esta zona integrada de Active Directory.
Todos los servidores DNS de un dominio de Active Directory especificado Los datos de zona se replican en todos los servidores DNS que se ejecutan en los controladores de dominio basados en Windows Server 2003 del dominio de Active Directory especificado. Ésta es la configuración predeterminada para la replicación de zonas DNS integradas de Active Directory.

(El dominio de Active Directory especificado es el domino alojado en el controlador de dominio en el que se ejecuta el servidor DNS que aloja la zona.)

No es necesario que la zona se replique en todo el bosque y se desea limitar el tráfico de replicación de zona. Esta opción genera menos tráfico de replicación de zona que la replicación de la zona en todos los servidores DNS del bosque o en todos los controladores del dominio. Si se elige esta opción, los datos de zona no se replican en los servidores DNS que se ejecutan en controladores de dominio basados en Windows 2000.
Todos los controladores del dominio de Active Directory Los datos de zona se replican en todos los controladores del dominio de Active Directory especificado, se ejecuten o no servidores DNS en ellos. Se aloja una copia de esta zona integrada de Active Directory en un servidor DNS que se ejecuta en un controlador de dominio basado en Windows 2000.
Todos los controladores de dominio especificados en el ámbito de replicación de una partición de directorio de aplicaciones Los datos de zona se replican en todos los controladores de dominio especificados en el ámbito de replicación de la partición de directorio de aplicaciones. Se desea personalizar el ámbito de replicación de zona de la organización. Con esta opción se puede minimizar el tráfico de replicación de zona al tiempo que se maximiza la funcionalidad. Sin embargo, esta opción produce más sobrecarga administrativa. Esta opción sólo se puede elegir si se ejecuta Windows Server 2003 en todos los servidores DNS que alojan una copia de esta zona integrada de Active Directory.

Migrar zonas a servidores DNS de Windows Server 2003

Las zonas se pueden migrar a servidores DNS de Windows Server 2003 de dos maneras:

  • Mediante la transferencia de zona
  • Mediante la copia de los archivos de zona

Si copia los archivos de zona, debe comprobar manualmente la integridad de las zonas. Con independencia del método que utilice para migrar las zonas, debe decidir si el servidor DNS original se desconectará o se utilizará como servidor secundario. Si determina que el servidor DNS original de terceros causa problemas de interoperabilidad en la red o si necesita utilizar ese hardware para otro propósito, desconecte el servidor. De lo contrario, mantenga el servidor en la red para proporcionar una copia de seguridad del servicio DNS principal de Windows Server 2003.

Para obtener más información acerca de cómo utilizar la transferencia de zonas, consulte "Initiate a zone transfer at a secondary server" (Iniciar una transferencia de zona en un servidor secundario) en el Centro de ayuda y soporte técnico de Windows Server 2003.
[subir]

Configurar y administrar clientes DNS

Al configurar clientes DNS, debe especificar una lista de los servidores que los clientes deben utilizar para resolver los nombres DNS. Debe especificar también una lista de búsqueda de sufijos DNS que los clientes utilizarán al realizar consultas DNS en busca de nombres de dominio cortos no completos. También se puede utilizar una directiva de grupo para simplificar la configuración de los clientes DNS.

En la figura 4.9 se muestra el proceso que es preciso seguir para configurar y administrar los clientes DNS.


Si su explorador no admite los marcos en línea, haga clic aquí para abrir una página independiente.

Figura 4.9 Configuración y administración de clientes DNS

Configurar listas de servidores DNS de cliente y listas de búsqueda de sufijos

Para configurar las listas de servidores DNS y la lista de búsqueda de sufijos de los clientes se deben incluir al menos dos direcciones IP de servidores DNS en los clientes y controladores de dominio: la dirección IP de un servidor preferido y la dirección IP de un servidor alternativo. Utilice un servidor que se ejecute en el sitio local como servidor preferido. El servidor alternativo puede ejecutarse en un sitio local o remoto.

De forma predeterminada, la lista de búsqueda de sufijos DNS se llena en función del sufijo DNS principal del cliente y los sufijos DNS específicos de la conexión. La lista de búsqueda de sufijos DNS se puede modificar mediante el administrador de DNS o Directiva de grupo. Si es posible, conviene limitar el tamaño de la lista de búsqueda de sufijos, ya que si es grande se incrementa el tráfico de red.

Utilizar directivas de grupo para simplificar la configuración de los clientes

En Windows Server 2003 se incluye un nuevo conjunto de directivas de grupo para simplificar la implantación de los clientes DNS de Windows Server 2003. Se pueden utilizar para especificar las listas de servidores DNS, las listas de búsqueda de sufijos y la configuración de actualización dinámica, entre otras muchas opciones. Como en todas las directivas de grupo, se pueden especificar diferentes configuraciones basadas en el sitio, dominio o unidad organizativa.

Para obtener más información acerca de estas directivas de grupo, vea "Windows Server 2003 DNS" (DNS de Windows Server 2003) en el manual Networking Guide (Guía de redes) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003), o consulte "Windows Server 2003  DNS" (DNS de Windows Server 2003) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).
[subir]

Proteger la infraestructura DNS

Puesto que DNS se ha diseñado como un protocolo abierto, la seguridad de los datos DNS es vulnerable a los ataques. En DNS de Windows Server 2003 se proporcionan características de seguridad mejoradas para reducir el grado de vulnerabilidad. En la figura 4.10 se muestra el proceso que es preciso seguir para proteger la infraestructura DNS.


Si su explorador no admite los marcos en línea, haga clic aquí para abrir una página independiente.

Figura 4.10 Protección de la infraestructura DNS

Identificar las amenazas a la seguridad del sistema DNS

La seguridad de una infraestructura DNS es vulnerable a los siguientes tipos de amenazas:

  • Creación de huellas. Proceso que consiste en crear un diagrama, o huella, de una infraestructura DNS mediante la captura de datos de zonas DNS, como nombres de dominio, nombres de equipo y direcciones IP de recursos de red confidenciales. En los nombres de equipo y de dominio DNS se suele indicar la función o la ubicación de los dominios y los equipos.
  • Ataque de denegación de servicio. Ataque en el que el intruso intenta denegar la disponibilidad de los servicios de red mediante la saturación de uno o varios servidores de la red con consultas recursivas. Al saturar un servidor DNS con consultas, el uso de la CPU acaba por alcanzar su nivel máximo y el servicio Servidor DNS deja de estar disponible. Si en la red no hay un servidor DNS totalmente operativo, los servicios de red que utilicen DNS dejarán de estar disponibles para los usuarios.
  • Modificación de datos. Uso de direcciones IP válidas en paquetes IP que un intruso crea para destruir datos o llevar a cabo otro tipo de ataques. Por lo general, la modificación de datos se intenta en una infraestructura DNS en la que ya se ha creado una huella. Si el ataque tiene éxito, los paquetes parecen provenir de una dirección IP válida de la red. Esto se denomina comúnmente "falsificación IP". Con una dirección IP válida (una dirección IP que esté dentro del intervalo de direcciones IP de una subred), un intruso puede obtener acceso a la red.
  • Redirección. Ataque en el que un intruso es capaz de redirigir consultas de nombres DNS a servidores que están bajo su control. Uno de los métodos de redirección consiste en intentar dañar la caché de un servidor DNS con datos erróneos que pueden dirigir las consultas futuras a servidores que están bajo el control de un intruso. Por ejemplo, si se realiza una consulta con ejemplo.contoso.com y en una respuesta de referencia se proporciona un registro de un nombre que está fuera del dominio contoso.com, el servidor DNS utiliza los datos de la caché para resolver la consulta del nombre externo. Un intruso puede llevar a cabo la redirección si dispone de acceso de escritura a los datos DNS, por ejemplo en las actualizaciones dinámicas no protegidas.

Para obtener más información acerca de los tipos de ataques comunes, cómo desarrollar una directiva de seguridad y cómo evaluar el nivel de riesgo, consulte "Designing an Authentication Strategy" (Diseñar una estrategia de autenticación) y "Designing an Authorization Strategy" (Diseñar una estrategia de autorización) en Diseñar e implementar los servicios de directorio y seguridad.

Desarrollar una directiva de seguridad de DNS

Si los datos DNS no están protegidos, los intrusos pueden obtener información acerca de la red que se puede utilizar para poner en peligro otros servicios. Por ejemplo, los intrusos pueden perjudicar a la organización de las siguientes maneras:

  • Mediante la transferencia de zonas, los intrusos pueden recuperar una lista de todos los hosts de la red y sus direcciones IP.
  • Mediante ataques de denegación de servicio, los intrusos pueden impedir la entrega de correo electrónico en la red y la visibilidad del servidor Web.
  • Si los intrusos pueden modificar los datos de zona, pueden configurar servidores Web falsos o hacer que el correo electrónico se redirija a sus servidores.

El riesgo de ataque varía en función de la exposición a Internet. Para un servidor DNS de una red privada en la que se utiliza un espacio de nombres privado, un esquema de direcciones privado y un servidor de seguridad eficaz, el riesgo de ataque es menor y hay más posibilidades de descubrir al intruso. En el caso de un servidor DNS que está expuesto a Internet, el riesgo es más alto.

El desarrollo de una directiva de seguridad de DNS incluye:

  • Decidir qué tipo de acceso necesitan los clientes, qué concesiones se desean hacer en cuanto a seguridad y rendimiento, y qué datos son los que más se deben proteger.
  • Familiarizarse con los problemas de seguridad comunes de los servidores DNS internos y externos.
  • Estudiar el tráfico de resolución de nombres para ver qué clientes pueden consultar cada servidor.

Se puede adoptar una directiva de seguridad de DNS de nivel bajo, medio o alto.

Directiva de seguridad de DNS de nivel bajo

La seguridad de nivel bajo no requiere configuración adicional de la implementación de DNS. Este nivel de seguridad se puede utilizar en un entorno de red en el que no haya que preocuparse por la integridad de los datos DNS o en una red privada en la que no exista la posibilidad de conexión externa. Entre las características de una directiva de seguridad de nivel bajo se incluyen las siguientes:

  • La infraestructura DNS de la organización está expuesta completamente a Internet.
  • En todos los servidores DNS de la red se lleva a cabo la resolución DNS estándar.
  • Los servidores DNS están configurados con sugerencias de raíz que apuntan a los servidores raíz de Internet.
  • Todos los servidores DNS permiten transferencias de zona a cualquier servidor.
  • Los servidores DNS están configurados para escuchar en todas sus direcciones IP.
  • La prevención de daños en la caché está deshabilitada en todos los servidores DNS.
  • En todas las zonas DNS se permite la actualización dinámica.
  • En el servidor de seguridad de la red está abierto el puerto UDP (Protocolo de datagramas de usuario) y el puerto TCP/IP 53 para las direcciones de origen y destino.
Directiva de seguridad de DNS de nivel medio

El nivel medio consiste en utilizar las características de seguridad que están disponibles sin ejecutar servidores DNS en controladores de dominio y almacenar zonas DNS en Active Directory. Entre las características de una directiva de seguridad de nivel medio se incluyen las siguientes:

  • La infraestructura DNS de la organización tiene una exposición limitada a Internet.
  • Los servidores DNS están configurados para utilizar reenviadores que apuntan a una lista específica de servidores DNS internos si no pueden resolver los nombres localmente.
  • Los servidores DNS limitan las transferencias de zona a los servidores enumerados en los registros NS de su zona.
  • Los servidores DNS están configurados para escuchar en direcciones IP especificadas.
  • La prevención de daños en la caché está habilitada en todos los servidores DNS.
  • La actualización dinámica no se permite en ninguna zona DNS.
  • Los servidores DNS internos se comunican con los servidores DNS externos a través del servidor de seguridad con una lista limitada de direcciones de origen y destino permitidas.
  • Los servidores DNS externos que se encuentran dentro del servidor de seguridad están configurados con sugerencias de raíz que apuntan a los servidores raíz de Internet.
  • La resolución de nombres de Internet se lleva a cabo mediante servidores proxy y puertas de enlace.
Directiva de seguridad de DNS de nivel alto

En la seguridad de nivel alto se utiliza la misma configuración que en la de nivel medio junto con las características de seguridad disponibles cuando se ejecuta el servicio Servidor DNS en un controlador de dominio y las zonas DNS se almacenan en Active Directory. Adicionalmente, en el nivel alto de seguridad se elimina completamente la comunicación DNS con Internet. No se trata de una configuración típica, pero se recomienda si no es necesaria la conexión a Internet. Entre las características de una directiva de seguridad de nivel alto se incluyen las siguientes:

  • La infraestructura de la organización no tiene comunicación con Internet por medio de los servidores DNS internos.
  • En la red se utilizan una raíz y un espacio de nombres DNS internos, donde la autoridad para todas las zonas DNS es interna.
  • En los servidores DNS configurados con reenviadores sólo se utilizan direcciones IP de servidores DNS internos.
  • Todos los servidores DNS limitan las transferencias de zona a las direcciones IP especificadas.
  • Los servidores DNS están configurados para escuchar en direcciones IP especificadas.
  • La prevención de daños en la caché está habilitada en todos los servidores DNS.
  • Los servidores DNS internos están configurados con sugerencias de raíz que apuntan a los servidores DNS internos que alojan la zona raíz del espacio de nombres interno.
  • Todos los servidores DNS se ejecutan en controladores de dominio. En el servicio Servidor DNS está configurada una Lista de control de acceso discrecional (DACL) para permitir que únicamente determinados usuarios puedan realizar tareas administrativas en los servidores DNS.
  • Todas las zonas DNS se almacenan en Active Directory. Está configurada una lista DACL para permitir que únicamente determinados usuarios puedan crear, eliminar o modificar las zonas DNS.
  • En los registros de recursos DNS están configuradas listas DACL para permitir que únicamente determinados usuarios puedan crear, eliminar o modificar los datos DNS.
  • La actualización dinámica segura está configurada para todas las zonas DNS excepto las zonas de nivel superior y raíz, en las que no se permiten las actualizaciones dinámicas.
Proteger los servidores DNS que están expuestos a Internet

Los servidores DNS que están expuestos a Internet son especialmente vulnerables a los ataques. Para proteger estos servidores, puede llevar a cabo las siguientes acciones:

  • Coloque el servidor de nombres en una red perimetral en lugar de la red interna.

    Para obtener más información acerca de las redes perimetrales, vea "Deploying ISA Servers" (Implementar servidores ISA Server) en este manual.

    Utilice un servidor DNS para los servicios de acceso público dentro de la red perimetral y un servidor DNS independiente para la red interna privada. Esto reduce el riesgo de exposición del espacio de nombres privado, que puede dejar al descubierto nombres y direcciones IP confidenciales ante los usuarios basados en Internet. También aumenta el rendimiento, ya que disminuye el número de registros de recursos en el servidor DNS.

  • Agregue un servidor secundario en otra subred o red, o en un ISP. Esto le protege de ataques de denegación de servicio.
  • Elimine los puntos de error únicos protegiendo los enrutadores y servidores DNS, y distribuyendo los servidores DNS geográficamente. Agregue copias secundarias de las zonas como mínimo a un servidor DNS fuera del sitio.
  • Cifre el tráfico de replicación de zonas mediante túneles IPSec o VPN para ocultar los nombres y direcciones IP a los usuarios basados en Internet.
  • Configure servidores de seguridad para exigir el filtrado de paquetes en el puerto UDP y TCP 53.
  • Restrinja la lista de servidores DNS que tienen permiso para iniciar una transferencia de zona en el servidor DNS. Aplique la restricción a cada una de las zonas de la red.
  • Examine los registros de DNS y supervise los servidores DNS con el Visor de sucesos.
Proteger los servidores DNS internos

Los servidores DNS internos son menos vulnerables a los ataques que los externos, pero también es necesario protegerlos. Para proteger estos servidores, lleve a cabo las siguientes acciones:

  • Elimine los puntos de error únicos. Sin embargo, observe que la redundancia de DNS no le ayudará si los clientes no pueden tener acceso a los servicios de red. Piense dónde están ubicados los clientes de cada zona y cómo resuelven los nombres si el servidor DNS deja de responder a las consultas.
  • Impida el acceso no autorizado a los servidores. Permita sólo la actualización dinámica segura en las zonas y limite la lista de servidores DNS que tienen permiso para obtener una transferencia de zona.
  • Examine los registros de DNS y supervise los servidores DNS internos con el Visor de sucesos. La supervisión de los registros y los servidores puede ayudar a detectar modificaciones no autorizadas de los archivos de los servidores o las zonas.
  • Implemente zonas integradas de Active Directory con actualización dinámica segura.
Proteger las zonas DNS de actualización dinámica

El uso de la actualización dinámica no segura plantea nuevos riesgos de seguridad. Puesto que cualquier equipo puede modificar un registro, los intrusos pueden modificar datos de zona y, después, suplantar los servidores existentes. Por ejemplo, si se instala el servidor Web web.contoso.com y se registra su dirección IP en DNS mediante actualización dinámica, un intruso puede instalar un segundo servidor Web, asignarle también el nombre web.contoso.com y utilizar la actualización dinámica para modificar la dirección IP correspondiente en el registro DNS. De esta forma, el intruso puede suplantar el servidor Web original y capturar información segura. Por esta razón es importante implementar la actualización dinámica segura.

Para impedir la suplantación de servidores, utilice zonas integradas de Active Directory y configúrelas para actualización dinámica segura. Con la actualización dinámica segura, sólo los equipos y usuarios especificados en una lista de control de acceso (ACL) pueden crear o modificar objetos dentro de una zona.

Si es necesaria una directiva de seguridad más estricta, modifique la configuración para restringir más el acceso. Restrinja el acceso por equipo, grupo o cuenta de usuario, y asigne permisos para toda la zona DNS y para los nombres DNS individuales dentro de la zona.

Para obtener más información acerca de cómo proteger las zonas DNS de actualización dinámica, vea "Windows Server 2003 DNS" (DNS de Windows Server 2003) en el manual Networking Guide (Guía de redes) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003), o consulte "Windows Server 2003  DNS" (DNS de Windows Server 2003) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).

Proteger la replicación de zonas DNS

La replicación de zonas puede producirse por medio de transferencias de zona o como parte de la replicación de Active Directory. Si no se protege la replicación de zonas se corre el riesgo de exponer los nombres y direcciones IP de los equipos ante los intrusos. Para proteger la replicación de zonas DNS se pueden llevar a cabo las siguientes acciones:

  • Utilizar la replicación de Active Directory
  • Cifrar la replicación de zonas realizada a través de redes públicas como Internet
  • Restringir la transferencia de zonas a los servidores autorizados
Utilizar la replicación de Active Directory

La replicación de zonas como parte de la replicación de Active Directory ofrece las siguientes ventajas de seguridad:

  • El tráfico de replicación de Active Directory está cifrado, por lo que el tráfico de replicación de zonas se cifra automáticamente.
  • Sólo un número limitado de usuarios pueden intervenir en la replicación de Active Directory. Los servidores DNS que alojan zonas integradas de Active Directory deben ser controladores de dominio, lo que significa que la replicación de Active Directory sólo puede tener lugar entre controladores de dominio. En consecuencia, sólo los administradores autorizados para administrar los controladores de dominio pueden intervenir en la replicación de Active Directory.
  • Los controladores de dominio de Active Directory que realizan la replicación se autentican mutuamente y no es posible la suplantación.
Nota   Deben utilizarse las zonas integradas de Active Directory siempre que sea posible, ya que se replican como parte de la replicación de Active Directory, que es más segura que la transferencia de zonas basadas en archivos.
Cifrar el tráfico de replicación enviado a través de redes públicas

El tráfico de replicación enviado a través de redes públicas debe cifrarse mediante túneles IPSec o VPN. Al cifrar este tipo de tráfico de replicación, siga estas directrices:

  • Utilice el nivel más seguro de cifrado o autenticación de túnel VPN que admitan los servidores.
  • Utilice el Servicio de enrutamiento y acceso remoto de Windows Server 2003 para crear el túnel IPSec o VPN.
Restringir la transferencia de zonas a los servidores autorizados

Si tiene servidores secundarios y los datos de zona se replican mediante la transferencia de zona, configure los servidores para especificar los servidores que tienen autoridad para recibir transferencias de zona. Esto impide que los intrusos utilicen la transferencia para descargar datos de zona. Si en su lugar utiliza zonas integradas de Active Directory, configure los servidores para prohibir la transferencia de zona.
[subir]

Integrar DNS con otros servicios de Windows Server 2003

Al implementar DNS de Windows Server 2003, es importante integrar el servicio DNS con otros servicios, como DHCP y WINS. En la figura 4.11 se muestra el proceso para integrar DNS con otros servicios de Windows Server 2003.


Si su explorador no admite los marcos en línea, haga clic aquí para abrir una página independiente.

Figura 4.11 Integración de DNS con otros servicios de Windows Server 2003

Integrar DNS con DHCP

DNS de Windows Server 2003 admite DHCP mediante la actualización dinámica de zonas DNS. Al integrar DHCP y DNS en una implementación de DNS se puede proporcionar a los recursos de la red información dinámica de direcciones almacenada en DNS. Para habilitar esta integración se puede utilizar el servicio DHCP de Windows Server 2003.

El estándar de actualización dinámica, especificado en el documento RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)" (Actualizaciones dinámicas en el sistema de nombres de dominio (ACTUALIZACIÓN DNS)), actualiza los registros DNS automáticamente. En Windows Server 2003 y Windows 2000 se admite la actualización dinámica y los clientes y servidores DHCP pueden enviar actualizaciones dinámicas cuando sus direcciones IP cambian. En sí misma, la actualización dinámica no es segura porque cualquier cliente puede modificar los registros DNS. Para proteger las actualizaciones dinámicas se puede utilizar la característica de actualización dinámica segura incluida en Windows Server 2003. Para eliminar los registros obsoletos se puede utilizar la característica de caducidad y compactación de los servidores DNS.

La actualización dinámica permite que los servidores DHCP registren registros de recursos A y PTR en nombre de los clientes DHCP. Este proceso requiere el uso de la opción 81 de FQDN del cliente DHCP. Esta opción permite que el cliente proporcione su FQDN al servidor DHCP. El cliente proporciona también al servidor instrucciones en las que se describe cómo procesar las actualizaciones dinámicas en nombre del cliente DHCP.

Cuando un cliente DHCP calificado emite la opción 81, ésta se procesa e interpreta en un servidor DHCP de Windows Server 2003 para determinar cómo debe el servidor iniciar las actualizaciones en nombre del cliente. Si el servidor está configurado para realizar actualizaciones dinámicas de DNS, lleva a cabo una de las siguientes acciones:

  • El servidor DHCP actualiza los registros DNS A y PTR si lo solicitan los clientes que utilizan la opción 81.
  • El servidor DHCP actualiza los registros DNS A y PTR con independencia de que el cliente solicite esta acción.

Además, el servidor DHCP puede actualizar dinámicamente los registros DNS A y PTR en nombre de los clientes antiguos que no pueden enviar la opción 81 al servidor. También se puede configurar el servidor DHCP para que descarte los registros A y PTR de los clientes si se ha eliminado la concesión de cliente. De esta forma se reduce el tiempo necesario para administrar los registros manualmente y se proporciona compatibilidad con los clientes DHCP que no pueden realizar actualizaciones dinámicas. Además, la actualización dinámica simplifica la configuración de Active Directory al permitir el registro dinámico de los controladores de dominio con registros SRV.

Integrar DNS con WINS

Al actualizar a DNS de Windows Server 2003 desde una versión anterior de Windows, puede que sea necesario ofrecer compatibilidad con una infraestructura WINS existente. DNS de Windows Server 2003 habilita la compatibilidad con una implementación de WINS existente al permitir la configuración de un servidor DNS para que consulte un servidor WINS como una opción de zona DNS.

WINS proporciona resolución dinámica de nombres NetBIOS. Si en la organización se admiten clientes y programas que utilizan WINS para la resolución de nombres NetBIOS, es necesario continuar ofreciendo compatibilidad con WINS. Si algunos de los clientes están registrados en WINS y otros necesitan resolver los nombres pero no pueden llevar a cabo la resolución de nombres NetBIOS se puede utilizar la búsqueda WINS para permitir que el servidor DNS realice la consulta en el espacio de nombres WINS.

Esta característica es particularmente útil si algunos de los clientes que requieren la resolución de nombres NetBIOS no pueden utilizar WINS o si algunos de los clientes no pueden registrarse en DNS (por ejemplo, los clientes Microsoft® Windows® 95 o Windows® 98). La referencia WINS es el método preferido si algunos de los servidores DNS no admiten los registros de recursos utilizados para la búsqueda WINS y la búsqueda inversa WINS.

Búsqueda WINS y búsqueda inversa WINS

Mediante la configuración del servidor DNS para la búsqueda WINS se puede dirigir la resolución de nombres DNS para que se consulte WINS, de forma que los clientes DNS puedan consultar nombres y direcciones IP de clientes WINS. Si desea dirigir la resolución de nombres DNS para que se consulte WINS, agregue un registro de búsqueda WINS a la zona con autoridad. Cuando un servidor DNS con autoridad para la zona reciba una consulta de nombres, comprobará la zona en la que tiene autoridad. Si el servidor DNS no encuentra el nombre en la zona, pero ésta contiene un registro de búsqueda WINS, el servidor DNS consultará el servidor WINS. Si el nombre está registrado en WINS, el servidor WINS devolverá al servidor DNS el registro asociado.

Después, el servidor DNS compilará y devolverá el registro DNS correspondiente en respuesta a la solicitud DNS original. Los clientes DNS no necesitan saber si un cliente está registrado en WINS o DNS, y no necesitan consultar el servidor WINS.

El servidor DNS se puede configurar también para realizar búsquedas inversas WINS. Las búsquedas inversas funcionan de manera ligeramente distinta. Cuando se consulta un registro PTR no existente en un servidor DNS con autoridad y la zona correspondiente contiene el registro R de WINS, el servidor DNS utiliza una búsqueda del estado del adaptador del nodo NetBIOS.

Nota   Para proporcionar tolerancia a errores se pueden especificar múltiples servidores WINS en el registro de búsqueda WINS. El servidor en el que se ejecuta el servicio DNS de Windows 2000 o Windows Server 2003 intenta buscar el nombre en los servidores WINS en el orden especificado en la lista.
Configurar la referencia WINS

Los equipos en los que se ejecutan implementaciones de servidores DNS de terceros no admiten los registros que se utilizan para la búsqueda WINS y la búsqueda inversa WINS. Si se intenta utilizar una combinación de servidores DNS de Microsoft y de terceros para alojar una zona que contiene dichos registros, se pueden producir errores de datos o de transferencia de zona en los servidores DNS de terceros.

Si existe tal combinación se puede utilizar la referencia WINS para crear y delegar una zona especial que envía a WINS las consultas DNS. Esta zona no lleva a cabo ningún registro ni actualización. A continuación se deben configurar los clientes DNS para adjuntar el nombre de la zona de referencia WINS a las consultas no calificadas. De esa forma, el cliente puede consultar DNS y WINS al mismo tiempo con una consulta DNS. Con el fin de simplificar la administración se puede utilizar DHCP o Directiva de grupo para configurar los clientes para que realicen la configuración.

Para obtener más información acerca de DHCP, vea "Deploying DHCP" (Implementar DHCP) en este manual. Para obtener más información acerca de Directiva de grupo, vea "Designing a Group Policy Infrastructure" (Diseñar una infraestructura de directiva de grupo) en Designing a Managed Environment (Diseñar un entorno administrado) en este manual.

Nota   La zona WINS debe estar alojada en un servidor DNS de Windows Server 2003  o Windows 2000 y no se debe replicar en servidores DNS de terceros. Los servidores DNS de terceros no admiten los registros de recursos WINS y es posible que no puedan alojar la zona.
[subir]
Implementar DNS de Windows Server 2003

Una vez comprobada la configuración en un laboratorio de pruebas se pueden implantar los cambios en el entorno de producción. En la figura 4.9 se muestra el proceso que es preciso seguir para implementar DNS de Windows Server 2003.


Si su explorador no admite los marcos en línea, haga clic aquí para abrir una página independiente.

Figura 4.12 Implementación de DNS de Windows Server 2003

Preparar la implementación de DNS de Windows Server 2003

Para preparar el entorno para la implementación de DNS de Windows Server 2003, debe asegurarse de que cuenta con copias de seguridad confiables de todo lo que planee cambiar, incluidos los servidores y las zonas. Pruebe las copias de seguridad antes de llevar a cabo la implementación. Cree también un plan de recuperación para el caso de que se produzcan problemas como la pérdida de datos, errores de servidor y errores de las conexiones de red.

Antes de llevar a cabo la implementación de DNS, asegúrese de que los vínculos de enrutamiento entre los servidores que planea implementar funcionan correctamente. Dependiendo de cómo esté configurada la infraestructura, es posible que los servidores DNS deban realizar consultas en los siguientes equipos:

  • Servidores raíz
  • Reenviadores
  • Servidores que alojan zonas principales
  • Servidores que alojan zonas secundarias
  • Servidores que alojan zonas maestras
  • Servidores que alojan copias de la misma zona integrada de Active Directory, si se trata de servidores integrados de Active Directory
  • Servidores de Internet

Si prevé que los clientes consultarán nombres en Internet y planea utilizar un servidor proxy, asegúrese de que el servidor proxy está en funcionamiento.

Puede que le resulte conveniente instalar DNS en los controladores de dominio como parte de la instalación de Active Directory. En ese caso, tenga en cuenta que no se puede cambiar el nombre del equipo después de instalar Active Directory en él.

Instalar el servidor DNS

Antes de instalar DNS, asegúrese de que el equipo tiene el nombre correcto y de que puede hacer ping a otros equipos de la red en los que los servidores puedan necesitar realizar consultas. Puesto que los clientes buscan los servidores DNS por su dirección IP, asegúrese de asignar una dirección IP estática a cada servidor DNS.

El servidor DNS se puede instalar de cuatro maneras distintas:

  • Puede instalar DNS en un servidor mediante el Asistente para instalación de Active Directory.

    El asistente crea automáticamente una copia integrada de Active Directory de la zona de búsqueda directa correspondiente al nombre del dominio de Active Directory y configura la zona para actualización dinámica segura. Además, el asistente crea las zonas estándar de búsqueda inversa recomendadas en los documentos RFC de DNS. En determinados casos, el asistente configura el servidor como un servidor raíz o inicializa las sugerencias de raíz con los nombres de los servidores raíz.

    Para iniciar el Asistente para instalación de Active Directory se puede ejecutar el archivo de respuesta, que contiene las respuestas a todas las preguntas que formula el asistente. Para obtener más información acerca de cómo utilizar el archivo de respuesta, vea "Active Directory Data Storage" (Almacenamiento de datos en Active Directory) en el manual Distributed Services Guide (Guía de servicios distribuidos) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003), o consulte "Active Directory Data Storage" (Almacenamiento de datos en Active Directory) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).

  • Antes o después de instalar Active Directory en el servidor, puede utilizar la herramienta Agregar o quitar programas para instalar el servicio Servidor DNS y, a continuación, ejecutar el Asistente para configurar servidor DNS para configurar las zonas. Igual que el Asistente para instalación de Active Directory, el Asistente para configurar servidor DNS crea las zonas estándar de búsqueda inversa recomendadas en los documentos RFC de DNS y configura el servidor como un servidor raíz o inicializa las sugerencias de raíz.
  • Puede utilizar la herramienta de línea de comandos Dnscmd.exe para configurar el servidor DNS.
  • Puede utilizar VB Script u otros lenguajes de secuencias de comandos a través del proveedor WMI que se incluye con Windows Server 2003.

Después de instalar el servidor DNS, revise las sugerencias de raíz. Si el servidor está configurado como un servidor raíz y no desea conservar esa configuración, elimine la zona raíz.

Para obtener más información acerca de estas opciones y cómo el Asistente para instalación de Active Directory y el Asistente para configurar servidor DNS determinan si se deben inicializar las sugerencias de raíz, vea "Windows Server 2003 DNS" (DNS de Windows Server 2003) en el manual Networking Guide (Guía de redes) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003), o consulte "Windows Server 2003  DNS" (DNS de Windows Server 2003) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).

Configurar zonas

Si se instala DNS mediante el Asistente para instalación de Active Directory, el asistente crea zonas DNS correspondientes a los dominios de Active Directory que se especifiquen. Si las zonas especificadas durante la fase de planeamiento de la implementación no existen, créelas en este momento.

Si la zona que crea el asistente no es del tipo que desea, cámbiela en este momento. Por ejemplo, puede que necesite convertir una zona principal estándar en una zona integrada de Active Directory. Si el asistente para la instalación crea la zona, pero no agrega la delegación, agréguela en este momento.

Para cada zona que cree, agregue los registros de recursos correspondientes y habilite o deshabilite la actualización dinámica o la actualización dinámica segura, según corresponda. Si desea insertar actualizaciones en servidores secundarios para una zona, configure la opción DNS notify (Notificación DNS) en el servidor principal.

Para obtener más información acerca de cómo agregar y eliminar zonas, vea el Centro de ayuda y soporte técnico de Windows Server 2003.

Configurar el reenvío

Si alguno de los servidores debe reenviar consultas a otro servidor, configure el reenvío en aquellos que lo necesiten. Si desea que el servidor reenvíe las consultas a diferentes servidores en función del sufijo DNS especificado en la consulta, configure el reenvío condicional como corresponda.

Para obtener más información acerca del reenvío condicional, vea "Utilizar el reenvío" en este capítulo y "Windows Server 2003 DNS" (DNS de Windows Server 2003) en el manual Networking Guide (Guía de redes) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003), o consulte "Windows Server 2003  DNS" (DNS de Windows Server 2003) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).

Configurar el servidor DNS para actualización dinámica

Dependiendo de cómo se configuren el servidor y las zonas, éstas pueden estar ya configuradas para actualización dinámica o actualización dinámica segura. Si no están configuradas como desea, realice los cambios necesarios.

Para obtener información acerca de cómo configurar la actualización dinámica y la actualización dinámica segura, vea el Centro de ayuda y soporte técnico de Windows Server 2003.

Configurar la caducidad y la compactación

Con la actualización dinámica, cuando un equipo se une a la red y se registra en DHCP, el servidor DNS agrega registros a la zona automáticamente. Sin embargo, en algunos casos, el servidor DNS no los elimina de forma automática y pueden quedar obsoletos. Los registros de recursos obsoletos ocupan espacio en el servidor y se pueden utilizar para responder a las consultas. Como consecuencia, el rendimiento del servidor DNS se ve afectado. Para solucionar estos problemas, el servidor DNS de Windows Server 2003 puede compactar los registros obsoletos en la base de datos y eliminarlos.

La caducidad y compactación se pueden configurar en el Administrador de DNS o mediante Dnscmd.exe.

Para obtener más información acerca de cómo utilizar la caducidad y la compactación, vea "Windows Server 2003 DNS" (DNS de Windows Server 2003) en el manual Networking Guide (Guía de redes) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003), o consulte "Windows Server 2003  DNS" (DNS de Windows Server 2003) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).

Configurar la replicación de zona

Si utiliza zonas principales o secundarias basadas en archivos, configure cada uno de los servidores maestros de una zona para permitir las transferencias de zona a cada servidor secundario de una zona. Después, configure cada uno de los servidores secundarios de una zona con una lista de los servidores maestros de dicha zona.

Si utiliza la replicación de Active Directory en un dominio de Windows Server 2003, configure el ámbito de replicación de zona. Si decide utilizar particiones de directorio de aplicaciones, debe tener credenciales de administrador de organización para poder configurar el ámbito de replicación de zona. Las credenciales de administrador de organización también son necesarias si las particiones predeterminadas de directorio de aplicaciones no están disponibles en Active Directory y el servidor DNS no las crea de forma automática.

Para obtener más información acerca de cómo almacenar y replicar zonas en Active Directory, incorporar un servidor DNS a una partición de directorio de aplicaciones DNS, quitar un servidor DNS de una partición de directorio de aplicaciones o cambiar el ámbito de replicación de zona, vea el Centro de ayuda y soporte técnico de Windows Server 2003.

Comprobar que el servidor DNS funciona correctamente

Después de instalar y configurar el servidor DNS, compruebe que funciona correctamente. Utilice las características de supervisión del complemento MMC de DNS, como la comprobación de consultas sencillas o recursivas. También puede examinar el registro de sucesos o el archivo de registro de depuración, o utilizar la herramienta de línea de comandos Nslookup para intentar realizar consultas. Para tener acceso a las características de supervisión del complemento MMC de DNS, haga clic en Propiedades en el menú Acción y, después, haga clic en la ficha Supervisión.

Para obtener más información acerca de cómo comprobar el funcionamiento del servidor DNS, vea "DNS Troubleshooting" (Solución de problemas de DNS) en el manual Networking Guide (Guía de redes) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003), o consulte "DNS Troubleshooting" (Solución de problemas de DNS) en la dirección Web http://www.microsoft.com/windows/reskits/default.asp (en inglés).

Configurar los clientes DNS

Configure cada cliente DNS con los siguientes datos:

  • Nombre de host y sufijo DNS
  • Servidores DNS preferido y alternativo
  • Opcionalmente, archivo de configuración automática de proxy o lista de exclusiones de nombres (si se trata de un cliente proxy)

Para configurar los clientes DNS, puede utilizar los siguientes métodos:

  • Utilice la configuración TCP/IP del cliente
  • Utilice Directiva de grupo para configurar grupos de clientes
  • Utilice el servicio Servidor DHCP para configurar determinadas opciones de los clientes automáticamente.

Para obtener más información acerca de cómo instalar y configurar clientes DNS, vea el Centro de ayuda y soporte técnico de Windows Server 2003.

Utilizar herramientas de línea de comandos para implementar DNS

Puede utilizar la herramienta de línea de comandos Dnscmd.exe para llevar a cabo la mayoría de las tareas que se pueden realizar en el complemento MMC de DNS. Con Dnscmd.exe se pueden crear, eliminar y ver zonas y registros, así como restablecer las propiedades de los servidores y las zonas. También se pueden realizar operaciones de administración habituales, como crear, volver a cargar o actualizar una zona, escribir de nuevo la zona en un archivo o en Active Directory, pausar y reanudar la zona, borrar la caché, agregar registros a las sugerencias de raíz, detener e iniciar el servicio DNS, y ver estadísticas.

La herramienta Dnscmd.exe se puede utilizar también para escribir secuencias de comandos de archivos por lotes y para administración remota. Para obtener más información acerca de Dnscmd.exe, en el Centro de ayuda y soporte técnico, haga clic en Herramientas y, a continuación, en Herramientas de soporte técnico de Windows. Para obtener información acerca de cómo instalar y utilizar las herramientas de soporte técnico y la Ayuda de las herramientas de soporte técnico de Windows Server 2003, consulte el archivo Sreadme.doc, que se encuentra en la carpeta \Support\Tools del CD del sistema operativo Windows Server 2003.

La herramienta Nslookup.exe se puede utilizar para efectuar pruebas de consultas del espacio de nombres de dominio DNS y mostrar información de diagnóstico.
[subir]

Recursos adicionales

Los siguientes recursos contienen información adicional y herramientas relacionadas con los temas de este capítulo.

Información relacionada de los kits de recursos

"Windows Server 2003 DNS" (DNS de Windows Server 2003) en el manual Networking Guide (Guía de redes) del Windows Server 2003 Resource Kit (Kit de recursos de Windows Server 2003) para obtener información acerca del servicio Servidor DNS.

"Configuring IP Addressing and Name Resolution" (Configurar el direccionamiento IP y la resolución de nombres) en Administering Microsoft Windows XP Professional (Administrar Microsoft Windows XP Professional) para obtener información acerca del cliente DNS.

Información relacionada fuera de los kits de recursos

  • RFC 1035, "Domain Names — Implementation and Specification" (Nombres de dominio: implementación y especificación).
  • DNS and BIND, 4th ed., por Paul Albitz y Cricket Liu, 2001, Sebastopol, CA: O'Reilly & Associates, para obtener más información acerca de DNS.
  • Windows 2000 TCP/IP Protocols and Services, por Thomas Lee y Joseph Davies, 2000, Redmond, Washington: Microsoft Press, para obtener más información acerca del protocolo DNS en línea.

Vínculo de Internet Engineering Task Force (IETF) de la página Recursos Web en la dirección http://www.microsoft.com/windows/reskits/webresources/, para obtener más información acerca de los documentos Solicitud de comentarios (RFC) y los borradores de Internet de IETF.

Herramientas relacionadas

Para obtener información acerca de cómo instalar y utilizar las herramientas de soporte técnico y la Ayuda de las herramientas de soporte técnico de Windows Server 2003, consulte el archivo Sreadme.doc, que se encuentra en la carpeta \Support\Tools del CD del sistema operativo Windows Server 2003.

  • Active Directory Sizer

    La herramienta Active Directory Sizer permite calcular el hardware necesario para implementar Active Directory en función del perfil, la información de dominios y la topología de sitios de la organización.

  • Netdiag.exe

    La herramienta Netdiag.exe ayuda a aislar los problemas de red y conectividad mediante una serie de pruebas encaminadas a determinar el estado del cliente de red y si funciona.

  • Dnscmd.exe

    La herramienta de línea de comandos Dnscmd.exe se puede utilizar para llevar a cabo la mayoría de las tareas que se pueden realizar en el complemento MMC de DNS.

  • Nslookup.exe

    La herramienta Nslookup se utiliza para realizar pruebas de consultas del espacio de nombres de dominio DNS y diagnosticar problemas en los servidores de nombres.

Renuncia de responsabilidad de la versión beta

Esta documentación es una versión previa de la documentación final, que puede cambiar en gran medida antes de la versión comercial final, y contiene información confidencial y propiedad de Microsoft Corporation. La información se divulga en virtud de un acuerdo de confidencialidad entre el destinatario y Microsoft. Este documento se proporciona a título meramente informativo y Microsoft no ofrece garantías expresas ni implícitas en el mismo. La información de este documento, incluidas las direcciones URL y otras referencias a sitios Web Internet, está sujeta a cambios sin aviso previo. El usuario asume todo el riesgo de uso o como resultado del uso de este documento. Salvo si se indica lo contrario, las empresas, organizaciones, productos, personas y sucesos de ejemplo descritos aquí son ficticios y no tienen asociación alguna con una empresa, organización, producto, persona o suceso real. Es responsabilidad del usuario el cumplimiento de las leyes de derechos de autor aplicables. Ninguna parte de este documento puede ser reproducida, almacenada o introducida en un sistema de recuperación, o transmitida de ninguna forma, ni por ningún medio (ya sea electrónico, mecánico, por fotocopia, grabación o de otra manera) con ningún propósito, sin la previa autorización por escrito de Microsoft Corporation.

Microsoft puede ser titular de patentes, solicitudes de patentes, marcas registradas, derechos de autor u otros derechos de propiedad intelectual sobre los contenidos de este documento. La posesión de este documento no le otorga ninguna licencia sobre estas patentes, marcas registradas, derechos de autor u otros derechos de propiedad intelectual, a menos que se prevea en un contrato de licencia por escrito de Microsoft.

© 2002 Microsoft Corporation. Reservados todos los derechos.

Active Accessibility, Active Channel, Active Client, Active Desktop, Active Directory, ActiveMovie, ActiveX, Authenticode, BackOffice, Direct3D, DirectAnimation, DirectDraw, DirectInput, DirectMusic, DirectPlay, DirectShow, DirectSound, DirectX, DoubleSpace, DriveSpace, FrontPage, IntelliMirror, IntelliMouse, IntelliSense, JScript, Links, Microsoft, Microsoft Press, Microsoft QuickBasic, MSDN, MS-DOS, MSN, Natural, NetMeeting, NetShow, OpenType, Outlook, PowerPoint, SideWinder, Slate, TrueImage, Verdana, Visual Basic, Visual C++, Visual FoxPro, Visual InterDev, Visual J++, Visual Studio, WebBot, Win32, Windows, Windows Media y Windows NT son marcas registradas o marcas comerciales de Microsoft Corporation en los Estados Unidos y en otros países.

Otros nombres de productos y compañías reales mencionados aquí pueden ser marcas registradas de sus respectivos propietarios.

Gracias por revisar la documentación elaborada por el equipo Windows Resource Kits. Si desea expresar su opinión acerca de la importancia, utilidad o integridad del contenido, envíe sus comentarios a docbeta@microsoft.com. Especifique en el asunto de su mensaje el título del capítulo. Incluya los números de página en sus comentarios. Si lo prefiere, puede enviarnos sus comentarios en un documento adjunto.

© 1985-2002 Microsoft Corporation. Reservados todos los derechos.
[subir]

Última actualización de esta página: 20 de julio de 2004




©2016 Microsoft Corporation. Todos los derechos reservados. Póngase en contacto con nosotros |Condiciones de uso |Marcas registradas |Declaración de Privacidad
Microsoft