Cloud DNS admite diferentes tipos de políticas. En esta página, se proporcionan detalles sobre los diferentes tipos de políticas y cuándo puedes usar cada uno.
- Las políticas del servidor aplican la configuración de DNS privado a una red de nube privada virtual (VPC) (reenvío y registro de DNS).
- Las políticas de respuesta anulan las respuestas de DNS privadas según el nombre de la consulta.
- Las políticas de enrutamiento dirigen el tráfico según la consulta (por ejemplo, round robin, la ubicación geográfica).
Puedes usar las tres políticas al mismo tiempo según tus necesidades.
Políticas del servidor
Usa las políticas del servidor con el fin de configurar implementaciones híbridas para las resoluciones de DNS. Puedes configurar una política del servidor entrante según la dirección de las resoluciones DNS. Si tus cargas de trabajo planean usar un agente de resolución de DNS local, puedes configurar zonas de reenvío de DNS mediante una política del servidor saliente. Por otro lado, si deseas que tus cargas de trabajo locales resuelvan nombres en Google Cloud, puedes configurar una política de servidor entrante.
Para obtener información detallada sobre las políticas del servidor, consulta la Descripción general de las políticas del servidor.
Para configurar y aplicar políticas del servidor DNS, consulta Aplica políticas de servidor DNS.
Políticas de respuesta
Una política de respuesta es un concepto de zona privada de Cloud DNS que contiene reglas en lugar de registros. Estas reglas se pueden usar para lograr efectos similares al concepto de borrador de la zona de política de respuesta (RPZ) de DNS (IETF). La función de política de respuesta te permite ingresar reglas personalizadas en los servidores DNS dentro de la red que el agente de resolución de DNS consulta durante las búsquedas. Si una regla de la política de respuesta afecta a la consulta entrante, se procesa. De lo contrario, la búsqueda se realiza con normalidad. Para obtener más información, consulta Administra políticas y reglas de respuesta.
Una política de respuesta es diferente de una RPZ, que es una zona normal del DNS, con datos con formato especial que provoca que los agentes de resolución compatibles realicen acciones especiales. Las políticas de respuesta no son zonas del DNS y se administran por separado en la API. Para crear y modificar políticas de respuesta en Cloud DNS, usa la API de ResponsePolicies. Las políticas de respuesta son independientes de ManagedZones y no se pueden administrar con la API de ManagedZones ni la API de RRSet.
Políticas de enrutamiento
Las políticas de enrutamiento DNS te permiten dirigir tu tráfico según criterios específicos. Cloud DNS también admite la verificación de estado y las conmutaciones por error automáticas incorporadas en cada política de enrutamiento. La verificación de estado está disponible para los balanceadores de cargas de red de transferencia internos y los balanceadores de cargas de aplicaciones internos que tengan habilitado el acceso global, y los balanceadores de cargas de aplicaciones internos entre regiones.
Cloud DNS admite las siguientes políticas de enrutamiento:
- Política de enrutamiento round robin ponderado
- Política de enrutamiento de ubicación geográfica
- Política de enrutamiento geovallado
- Política de enrutamiento de conmutación por error
Solo se puede aplicar un tipo de política de enrutamiento a un conjunto de registros de recursos a la vez. No puedes combinar políticas de enrutamiento, excepto cuando configuras una política de enrutamiento de conmutación por error, en la que puedes establecer una política de enrutamiento de ubicación geográfica como copia de seguridad.
Políticas de enrutamiento de round robin ponderado
Una política de enrutamiento de round robin ponderado (WRR) te permite especificar diferentes ponderaciones por objetivo de DNS, y Cloud DNS garantiza que tu tráfico se distribuya de acuerdo con las ponderaciones. Puedes usar esta política para admitir las configuraciones manuales de active-active o active-passive. También puedes dividir el tráfico entre las versiones de software de producción y las experimentales.
La verificación de estado está disponible de forma predeterminada si los objetivos son balanceadores de cargas de red de transferencia internos. Esto habilita la conmutación por error automática cuando los extremos fallan en las verificaciones de estado. En el caso de una conmutación por error, la división del tráfico se ajusta de forma automática entre los extremos en buen estado restantes. Para obtener más detalles, consulta Verificaciones de estado.
Políticas de enrutamiento de ubicación geográfica
Una política de enrutamiento de ubicación geográfica (GEO) te permite asignar el tráfico que se origina de las ubicaciones geográficas de origen (regiones de Google Cloud) a destinos de DNS específicos. Usa esta política para distribuir las solicitudes entrantes a diferentes instancias de servicio según el origen del tráfico. Puedes usar esta función con Internet, con tráfico externo o con tráfico que se origina en Google Cloud y vinculado a balanceadores de cargas de red de transferencia internos. Cloud DNS usa la región en la que las consultas ingresan a Google Cloud como la ubicación geográfica de origen.
La verificación de estado está disponible de forma predeterminada si el objetivo es el balanceador de cargas de red de transferencia interno, el balanceador de cargas de aplicaciones interno o el balanceador de cargas de aplicaciones interno entre regiones. Esto habilita la conmutación por error automática cuando los extremos fallan sus verificaciones de estado. En el caso de la ubicación geográfica, el tráfico se conmuta por error a la siguiente ubicación geográfica más cercana al tráfico de origen.
Políticas de enrutamiento geovallado
La verificación de estado habilita el tipo de política de enrutamiento con geovallado, en el que puedes restringir el tráfico a una ubicación geográfica específica, incluso si todos los extremos de esa ubicación geográfica están en mal estado. En una política de ubicación geográfica, cuando se observan fallas en la verificación de estado de un bucket de ubicación geográfica específico, el tráfico conmuta por error automáticamente a la siguiente ubicación geográfica más cercana. Cuando el geovallado está habilitado, la conmutación por error automática no ocurre. Como servidor autorizado, Cloud DNS debe mostrar un valor y, en este caso, muestra todas las direcciones IP sin cambios cuando fallan sus verificaciones de estado.
Políticas de enrutamiento de conmutación por error
La política de enrutamiento de conmutación por error te permite establecer configuraciones de copia de seguridad activas a fin de proporcionar alta disponibilidad para los recursos internos dentro de tu VPC. Puedes configurar una política de enrutamiento de conmutación por error solo para zonas privadas.
En funcionamiento normal, las direcciones IP aprovisionadas en el conjunto active siempre se muestran. Cuando todas las direcciones IP en el conjunto activo fallan (el estado cambia a mal estado), Cloud DNS comienza a entregar las direcciones IP en el conjunto de copia de seguridad. Puedes configurar el conjunto de copias de seguridad como políticas de ubicación geográfica, y estas se comportan de la misma manera que se describe en la sección de políticas de ubicación geográfica. Si se configura como balanceador de cargas de red de transferencia interno, balanceador de cargas de aplicaciones interno o balanceador de cargas de aplicaciones interno entre regiones, también se verifica el estado de todas las direcciones IP virtuales (VIP) de copia de seguridad.
Cloud DNS te permite hacer saltar el tráfico de forma gradual a las direcciones VIP de copia de seguridad para que puedas estar seguro de que funcionan correctamente. Puedes configurar el porcentaje del tráfico enviado a la copia de seguridad como una fracción de 0 a 1. El valor típico debe ser 0.1, aunque Cloud DNS te permite enviar el 100% del tráfico a las direcciones VIP de copia de seguridad para activar una conmutación por error de forma manual. Las verificaciones de estado solo se pueden aplicar a balanceadores de cargas internos. Por lo tanto, todas las direcciones VIP configuradas deben ser balanceadores de cargas de red de transferencia internos, balanceadores de cargas de aplicaciones internos o balanceadores de cargas de aplicaciones internos entre regiones.
Verificaciones de estado
Cloud DNS admite verificaciones de estado para balanceadores de cargas de red de transferencia internos y balanceadores de cargas de aplicaciones internos que tienen habilitado el acceso global, así como balanceadores de cargas de aplicaciones internos entre regiones.
Las verificaciones de estado para balanceadores de cargas privados solo están disponibles en zonas administradas privadas. Las verificaciones de estado no están disponibles para el reenvío, el intercambio de tráfico y las zonas de búsqueda inversa administradas.
Para obtener información detallada sobre las verificaciones de estado de los balanceadores de cargas, consulta Descripción general de las verificaciones de estado.
Verificaciones de estado para balanceadores de cargas de red de transferencia internos
Cloud DNS determina el estado de un balanceador de cargas de red de transferencia interno mediante la configuración de verificación de estado integrada del balanceador de cargas. Cloud DNS considera que el balanceador de cargas de red de transferencia interno está en buen estado y apto para recibir tráfico cuando al menos el 20% de las verificaciones de estado se realizan de forma correcta.
Para un balanceador de cargas de red de transferencia interno, Cloud DNS obtiene señales de estado directas de las instancias de backend individuales y se aplica un algoritmo de umbral para determinar si un extremo está en buen estado o no.
Una sola dirección IP virtual del balanceador de cargas de red de transferencia interno puede tener varios servicios ejecutándose detrás de ella. Cloud DNS busca señales de estado del protocolo y el puerto especificados en la configuración de verificación de estado del balanceador de cargas. Para obtener información detallada sobre las verificaciones de estado, consulta Descripción general de las verificaciones de estado.
Para el balanceador de cargas de aplicaciones interno y el balanceador de cargas de aplicaciones interno entre regiones, Cloud DNS considera el estado del balanceador de cargas durante la decisión de enrutamiento. Cuando un balanceador de cargas recibe una consulta, distribuye el tráfico solo a los servicios de backend en buen estado. Para asegurarte de que haya backends en buen estado, puedes administrar el ciclo de vida de los backends mediante servicios como los grupos de instancias administrados (MIG). Cloud DNS no necesita conocer el estado de los backends individuales; el balanceador de cargas controla esta tarea.
Políticas de round robin ponderado y verificaciones de estado
Cloud DNS admite ponderaciones de 0 a 1,000, ambos incluidos. Cuando se incluyen las verificaciones de estado, sucede lo siguiente:
- Si configuras varios objetivos, todos con un peso de 0, el tráfico se distribuye de manera equitativa entre los destinos.
- Si configuras un objetivo ponderado nuevo que no sea cero, este se convierte en el objetivo principal y todo el tráfico cambia a ese objetivo.
- A medida que agregas más destinos con ponderaciones distintas de cero, Cloud DNS calcula de forma dinámica la división del tráfico entre los destinos (con cada solicitud) y lo distribuye de forma adecuada. Por ejemplo, si configuraste tres objetivos con ponderaciones de 0, 25 y 75, el objetivo con la ponderación 0 no recibe tráfico, el objetivo con un peso de 25 recibe un cuarto del tráfico y el objetivo restante recibe tres cuartos del tráfico entrante.
- Si las verificaciones de estado se asocian con objetivos ponderados distintos de cero, pero no con objetivos ponderados cero, estos objetivos siempre se consideran en buen estado. Si todos los registros distintos de cero están en mal estado, Cloud DNS muestra los registros ponderados en cero.
- Si las verificaciones de estado están asociadas con registros ponderados distintos de cero y cero, y si todos los registros fallan en las verificaciones de estado, Cloud DNS muestra todos los objetivos ponderados distintos de cero y evita por completo los objetivos ponderados de cero.
- Cuando Cloud DNS elige un bucket de peso para mostrar al solicitante (un único elemento de la política), solo se muestra la dirección IP en ese bucket. Si solo especificas una dirección IP en el bucket de peso, solo esa dirección IP estará en la respuesta. Si hay más de una dirección IP en el bucket de peso, Cloud DNS muestra todas las direcciones IP en un orden aleatorio.
Política de ubicación geográfica con verificación de estado
Para las políticas de ubicación geográfica con las verificaciones de estado habilitadas, ocurre lo siguiente:
- Cuando un bucket de ubicación geográfica tiene varias direcciones IP configuradas, y todas las direcciones IP tienen verificación de estado, solo se muestran las direcciones IP en buen estado.
- Si hay una combinación de verificaciones de estado frente a ninguna, y todas las direcciones IP con verificación de estado fallan, Cloud DNS muestra todas las direcciones IP que no tenían verificación de estado configurada. En esta situación, no se produce la conmutación por error automática a la siguiente geografía más cercana.
- Esta política enruta automáticamente el tráfico al siguiente bucket geográfico más cercano en los siguientes casos:
- Todas las direcciones IP de un bucket de ubicación geográfica tienen habilitada la verificación de estado.
- La política tiene la protección inhabilitada.
- Todas las direcciones IP fallan en las verificaciones de estado. Esto te permite realizar una conmutación por error automática a la siguiente segmentación geográfica más cercana.
Registro de verificaciones de estado
Cloud DNS admite el registro de verificaciones de estado y registra el estado de la verificación de estado de cualquier cambio en el backend. Te permite realizar las siguientes acciones:
- Valida si las políticas de enrutamiento tienen el rendimiento esperado. Por ejemplo:
- En el caso de las políticas de
GEO, te permite validar si las políticas detectan la geografía correcta y muestran el conjunto de datos de RR correcto. - En el caso de las políticas
WRR, te permite validar si las políticas muestran las direcciones IP con el peso correcto.
- En el caso de las políticas de
- Identifica problemas de infraestructura con backends y direcciones IP específicos que tienen fallas.
- Soluciona por qué nunca se incluyen backends específicos o son los únicos que se muestran.
Para crear, editar o borrar políticas de enrutamiento de DNS, consulta Administra las políticas y verificaciones de estado de enrutamiento de DNS.
Tipos de registros compatibles con las políticas de enrutamiento de DNS
Las políticas de enrutamiento de DNS no admiten todos los tipos de registro compatibles con Cloud DNS. Las políticas de enrutamiento de DNS admiten los siguientes tipos de registros.
| Tipo de registro | Descripción |
|---|---|
| A | Direcciones IPv4 |
| AAAA | Direcciones IPv6 |
| CNAME | Nombres canónicos |
| MX | Registros de intercambio de correo electrónico |
| SRV | Host/puerto (RFC 2782) |
| TXT | Datos de texto |