Uso de directiva DNS para la administración del tráfico basada en la ubicación geográfica con implementaciones primarias-secundarias

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Puede usar este tema para obtener información sobre cómo crear una directiva DNS para la administración del tráfico basada en la ubicación geográfica cuando la implementación de DNS incluye servidores DNS principales y secundarios.

En el escenario anterior, Uso de la directiva DNS para la administración del tráfico basada en la ubicación geográfica con servidores principales, se proporcionaban instrucciones para configurar la directiva DNS para la administración del tráfico basada en la ubicación geográfica en un servidor DNS principal. Sin embargo, en la infraestructura de Internet, los servidores DNS se implementan ampliamente en un modelo principal-secundario, donde la copia grabable de una zona se almacena en servidores primarios seleccionados y seguros, y las copias de solo lectura de la zona se mantienen en varios servidores secundarios.

Los servidores secundarios usan los protocolos de transferencia de zona Transferencia autoritativa (AXFR) y Transferencia de zona incremental (IXFR) para solicitar y recibir actualizaciones de zona que incluyan nuevos cambios en las zonas de los servidores DNS principales.

Nota

Para más información sobre AXFR, consulte la Solicitud para comentarios 5936 del Grupo de trabajo de ingeniería de Internet (IETF). Para más información sobre IXFR, consulte la Solicitud para comentarios 1995 del Grupo de trabajo de ingeniería de Internet (IETF).

Ejemplo de administración del tráfico basada en la ubicación geográfica principal-secundaria

A continuación se muestra un ejemplo de cómo puede usar la directiva DNS en una implementación principal-secundaria para lograr el redireccionamiento del tráfico en función de la ubicación física del cliente que realiza una consulta de DNS.

En este ejemplo se usan dos empresas ficticias: Contoso Cloud Services, que proporciona soluciones de hospedaje de sitios web y dominios, y Woodgrove Food Services, que proporciona servicios de entrega de alimentos en varias ciudades de todo el mundo y que tiene un sitio web llamado woodgrove.com.

Para asegurarse de que los clientes de woodgrove.com obtienen una experiencia dinámica desde su sitio web, Woodgrove quiere que los clientes europeos vayan dirigidos al centro de datos europeo y los clientes estadounidenses al centro de datos de EE. UU. Los clientes ubicados en otros lugares del mundo pueden ir dirigidos a cualquiera de los dos.

Contoso Cloud Services tiene dos centros de datos, uno en EE. UU. y otro en Europa, en los que Contoso hospeda su portal de pedidos de alimentos para woodgrove.com.

La implementación de DNS de Contoso incluye dos servidores secundarios: SecondaryServer1, con la dirección IP 10.0.0.2; y SecondaryServer2, con la dirección IP 10.0.0.3. Estos servidores secundarios actúan como servidores de nombres en las dos regiones, con SecondaryServer1 ubicado en Europa y SecondaryServer2 ubicado en EE. UU.

Hay una copia de zona grabable principal en PrimaryServer (dirección IP 10.0.0.1), donde se realizan los cambios de zona. Con las transferencias de zona regulares a los servidores secundarios, los servidores secundarios siempre están actualizados con los nuevos cambios en la zona del PrimaryServer.

En la siguiente ilustración se muestra este escenario.

Funcionamiento del sistema DNS principal-secundario

Al implementar la administración del tráfico basada en la ubicación geográfica en una implementación DNS principal-secundaria, es importante comprender cómo se producen las transferencias normales de la zona principal-secundaria antes de aprender sobre las transferencias a nivel de ámbito de zona. En las siguientes secciones se proporciona información sobre las transferencias de zona y a nivel de ámbito de zona.

• Transferencias de zona en una implementación principal-secundaria de DNS
• Transferencias a nivel de ámbito de zona en una implementación principal-secundaria de DNS

Transferencias de zona en una implementación principal-secundaria de DNS

Puede crear una implementación principal-secundaria de DNS y sincronizar zonas con los siguientes pasos.

1. Al instalar DNS, la zona principal se crea en el servidor DNS principal.
2. En el servidor secundario, cree las zonas y especifique cuáles son los servidores principales.
3. En los servidores principales, puede agregar los servidores secundarios como secundarias de confianza en la zona principal.
4. Las zonas secundarias realizan una solicitud de transferencia de zona completa (AXFR) y reciben la copia de la zona.
5. Cuando sea necesario, los servidores principales envían notificaciones a los servidores secundarios sobre las actualizaciones de zona.
6. Los servidores secundarios realizan una solicitud de transferencia de zona incremental (IXFR). Por este motivo, los servidores secundarios permanecen sincronizados con el servidor principal.

Transferencias a nivel de ámbito de zona en una implementación principal-secundaria de DNS

El escenario de administración del tráfico requiere pasos adicionales para dividir las zonas en distintos ámbitos de zona. Por este motivo, se requieren pasos adicionales para transferir los datos dentro de los ámbitos de zona a los servidores secundarios y transferir directivas y subredes de cliente DNS a los servidores secundarios.

Después de configurar la infraestructura DNS con servidores principales y secundarios, DNS realiza automáticamente las transferencias de nivel de ámbito de zona mediante los siguientes procesos.

Para garantizar la transferencia de nivel de ámbito de zona, los servidores DNS usan los mecanismos de extensión para DNS (EDNS0) OPT RR. Todas las solicitudes de transferencia de zona (AXFR o IXFR) de las zonas con ámbitos se originan con un EDNS0 OPT RR, cuyo id. de opción se establece en "65433" de manera predeterminada. Para más información sobre EDNSO, consulte la Solicitud para comentarios 6891 de IETF.

El valor de OPT RR es el nombre del ámbito de zona para el que se envía la solicitud. Cuando un servidor DNS principal recibe este paquete de un servidor secundario de confianza, interpreta la solicitud como si viniera para ese ámbito de zona.

Si el servidor principal tiene ese ámbito de zona, responde con los datos de transferencia (XFR) de ese ámbito. La respuesta contiene un OPT RR con el mismo id. de opción "65433" y el valor establecido en el mismo ámbito de zona. Los servidores secundarios reciben esta respuesta, recuperan la información de ámbito de la respuesta y actualizan ese ámbito concreto de la zona.

Después de este proceso, el servidor principal mantiene una lista de secundarias de confianza que han enviado dicha solicitud de ámbito de zona para las notificaciones.

Para cualquier actualización adicional en un ámbito de zona, se envía una notificación IXFR a los servidores secundarios, con el mismo OPT RR. El ámbito de zona que recibe esa notificación realiza la solicitud IXFR que contiene ese OPT RR y se da el mismo proceso que se ha descrito anteriormente.

Cómo realizar la configuración de la directiva DNS para la administración del tráfico basada en la ubicación geográfica principal-secundaria

Antes de comenzar, asegúrese de haber completado todos los pasos del tema Uso de la directiva DNS para la administración del tráfico basada en la ubicación geográfica con servidores principales y de que el servidor DNS principal está configurado con zonas, ámbitos de zona, subredes de cliente DNS y directiva DNS.

Nota

Las instrucciones de este tema para copiar subredes de cliente DNS, ámbitos de zona y directivas DNS de servidores principales DNS a servidores secundarios DNS son para la configuración y validación iniciales de DNS. En el futuro, es posible que quiera cambiar la configuración de subredes de cliente DNS, ámbitos de zona y directivas en el servidor principal. Si se da esa circunstancia, puede crear scripts de automatización para mantener los servidores secundarios sincronizados con el servidor principal.

Para configurar la directiva DNS para las respuestas a consultas basadas en la ubicación geográfica principal-secundaria, debe seguir estos pasos.

• Creación de las zonas secundarias
• Configuración de los valores de transferencia de zona en la zona principal
• Copia de las subredes del cliente DNS
• Creación de los ámbitos de zona en el servidor secundario
• Configuración de la directiva DNS

En las siguientes secciones se proporcionan instrucciones de configuración detalladas.

Importante

En las secciones siguientes se incluyen comandos de ejemplo Windows PowerShell que contienen valores de ejemplo para muchos parámetros. Asegúrese de reemplazar los valores de ejemplo de estos comandos por los valores adecuados para la implementación antes de ejecutar estos comandos.

Se requiere pertenencia a DnsAdmins, o una categoría equivalente, para realizar los siguientes procedimientos.

Creación de las zonas secundarias

Puede crear la copia secundaria de la zona que desea replicar en SecondaryServer1 y SecondaryServer2 (suponiendo que los cmdlets se ejecutan de forma remota desde un único cliente de administración).

Por ejemplo, puede crear la copia secundaria de www.woodgrove.com en SecondaryServer1 y SecondaryServer2.

Puede usar los siguientes comandos de Windows PowerShell para crear las zonas secundarias.

Add-DnsServerSecondaryZone -Name "woodgrove.com" -ZoneFile "woodgrove.com.dns" -MasterServers 10.0.0.1 -ComputerName SecondaryServer1
Add-DnsServerSecondaryZone -Name "woodgrove.com" -ZoneFile "woodgrove.com.dns" -MasterServers 10.0.0.1 -ComputerName SecondaryServer2

Para más información, consulte Add-DnsServerSecondaryZone.

Configuración de los valores de transferencia de zona en la zona principal

Debe configurar los valores de zona principal para que:

1. Se permitan transferencias de zona desde el servidor principal a los servidores secundarios especificados.
2. El servidor principal envía notificaciones de actualizaciones de zona a los servidores secundarios.

Puede usar los siguientes comandos de Windows PowerShell para configurar los valores de transferencia de zona en la zona principal.

Nota

En el siguiente comando de ejemplo, el parámetro -Notify especifica que el servidor principal enviará notificaciones sobre las actualizaciones a la lista de secundarias seleccionada.

Set-DnsServerPrimaryZone -Name "woodgrove.com" -Notify Notify -SecondaryServers "10.0.0.2,10.0.0.3" -SecureSecondaries TransferToSecureServers -ComputerName PrimaryServer

Para más información, consulte Set-DnsServerPrimaryZone.

Copia de las subredes del cliente DNS

Debe copiar las subredes de cliente DNS del servidor principal en los servidores secundarios.

Puede usar los siguientes comandos de Windows PowerShell para copiar las subredes en los servidores secundarios.

Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-DnsServerClientSubnet -ComputerName SecondaryServer1
Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-DnsServerClientSubnet -ComputerName SecondaryServer2

Para más información, consulte Add-DnsServerClientSubnet.

Creación de los ámbitos de zona en el servidor secundario

Debe crear los ámbitos de zona en los servidores secundarios. En DNS, los ámbitos de zona también comienzan a solicitar XFR desde el servidor principal. Con cualquier cambio en los ámbitos de zona del servidor principal, se envía una notificación que contiene la información del ámbito de zona a los servidores secundarios. Después, los servidores secundarios pueden actualizar sus ámbitos de zona con cambios incrementales.

Puede usar los siguientes comandos de Windows PowerShell para crear los ámbitos de zona en los servidores secundarios.

Get-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName PrimaryServer|Add-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName SecondaryServer1 -ErrorAction Ignore
Get-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName PrimaryServer|Add-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName SecondaryServer2 -ErrorAction Ignore

Nota

En estos comandos de ejemplo, se incluye el parámetro -ErrorAction Ignore, porque hay un ámbito de zona predeterminado en cada zona. El ámbito de zona predeterminado no se puede crear ni eliminar. La canalización dará lugar a un intento de crear ese ámbito y se producirá un error. Como alternativa, puede crear los ámbitos de zona no predeterminados en dos zonas secundarias.

Para más información, consulte Add-DnsServerZoneScope.

Configuración de la directiva DNS

Una vez que haya creado las subredes, las particiones (ámbitos de zona) y haya agregado registros, debe crear directivas que conecten las subredes y las particiones, de modo que, cuando una consulta proceda de un origen en una de las subredes del cliente DNS, la respuesta de consulta se devuelva desde el ámbito correcto de la zona. No se requieren directivas para asignar el ámbito de zona predeterminado.

Puede usar los siguientes comandos de Windows PowerShell para crear una directiva DNS que vincule las subredes de cliente DNS y los ámbitos de zona.

$policy = Get-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName PrimaryServer
$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName SecondaryServer1
$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName SecondaryServer2

Para más información, consulte Add-DnsServerQueryResolutionPolicy.

Ahora, ya tiene configurados los servidores DNS secundarios con las directivas DNS necesarias para redirigir el tráfico en función de la ubicación geográfica.

Cuando el servidor DNS recibe consultas de resolución de nombres, el servidor DNS evalúa los campos de la solicitud DNS con respecto a las directivas DNS configuradas. Si la dirección IP de origen de la solicitud de resolución de nombres coincide con cualquiera de las directivas, el ámbito de zona asociado se usa para responder a la consulta y el usuario se dirige al recurso que esté más cercano geográficamente.

Puede crear miles de directivas DNS según los requisitos de administración del tráfico y todas las directivas nuevas se aplicarán dinámicamente, sin reiniciar el servidor DNS, en las consultas entrantes.