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 un red de nube privada virtual (VPC) (reenvío y registro de DNS).
- Las políticas de respuesta anulan las respuestas de DNS privadas basadas en la consulta de la fuente de datos.
- Las políticas de enrutamiento dirigen el tráfico en función de las consultas (por ejemplo, round robin, 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. Tú puede configurar una política del servidor entrante según la dirección del DNS del proyecto. Si tus cargas de trabajo planean usar un agente de resolución de DNS local, puedes configurar zonas de reenvío de DNS con una política de servidor saliente. En la por otro lado, si quieres que tus cargas de trabajo locales resuelvan nombres en Google Cloud, puedes configurar una política del 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 a el DNS zona de política de respuesta (RPZ) de concepto de borrador (IETF). La función de política de respuesta permite ingresar reglas personalizadas en los servidores DNS dentro de la red que la resolución de DNS consulta durante las búsquedas. Si una regla en la política de respuesta afecta a la consulta entrante, se procesa. De lo contrario, el la búsqueda continúa de manera normal. 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. Las verificaciones de estado están disponibles para balanceadores de cargas de red de transferencia internos y balanceadores de cargas de aplicaciones internos que tengan acceso global habilitado, y balanceadores de cargas de aplicaciones internos entre regiones.
Cloud DNS admite las siguientes políticas de enrutamiento:
- Política de enrutamiento de round robin ponderado
- Política de enrutamiento de ubicación geográfica
- Política de enrutamiento con 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 conmutación por error de enrutamiento de ubicación geográfica, en la que puedes establecer una política de enrutamiento de ubicación geográfica como copia de seguridad.
Políticas de enrutamiento ponderado de round robin
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
según las ponderaciones. Puedes usar esta política para admitir las transacciones manuales
active-active o active-passive
de configuración. Puedes
el tráfico entre las versiones
de producción y experimentales del software.
La verificación de estado está disponible de forma predeterminada si los destinos son balanceadores de cargas de red de transferencia internos. Esta habilita la conmutación por error automática cuando los extremos fallan sus verificaciones de estado. En la una conmutación por error, la división del tráfico se ajusta automáticamente entre las 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 tráfico que se origina desde el 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 origine en Google Cloud y se vincula a balanceadores de cargas de red de transferencia internos. Cloud DNS se usa la región en la que las consultas ingresan a Google Cloud como origen a la raza, el género y datos geográficos.
La verificación de estado está disponible de forma predeterminada si el destino es un 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 en sus verificaciones de estado. En el caso de la ubicación geográfica, cuando 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 de 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 que la ubicación geográfica no es saludable. En una política de ubicación geográfica, cuando la verificación de estado se observan fallas para un bucket geográfico específico, el tráfico se conmuta por error a la siguiente ubicación geográfica más cercana. Cuando se habilita el geovallado, la conmutación por error automática no ocurrirá. Como servidor autorizado, Cloud DNS debe mostrar un valor y, en este caso, Cloud DNS devuelve todas las direcciones IP intactas 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 permite establecer parámetros de configuración de copia de seguridad activos proporcionan alta disponibilidad para los recursos internos 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 la
Siempre se muestran los valores establecidos de active. Cuando todas las direcciones IP del conjunto activo
falla (el estado cambia a en mal estado), Cloud DNS comienza a entregar
las direcciones IP en el conjunto de copia de seguridad. Puedes configurar la copia de seguridad como
de las políticas de ubicación geográfica, que se comportan igual que
sección de políticas. Si está configurado como balanceador de cargas de red de transferencia interno, balanceador de cargas de aplicaciones interno o
balanceador de cargas de aplicaciones interno entre regiones, todas las direcciones IP virtuales (VIP) de copia de seguridad también
estado verificado.
Cloud DNS te permite enviar tráfico gradualmente a las direcciones VIP de copia de seguridad para que puedas estar seguro de que las direcciones VIP de copia de seguridad funcionan. Puedes configura 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. Las verificaciones de estado solo se pueden aplicar a balanceadores de cargas internos por lo que 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 con acceso global habilitado y balanceadores de cargas de aplicaciones internos entre regiones.
Las verificaciones de estado de los balanceadores de cargas privados solo están disponibles en las cuentas administradas de forma privada zonas diferentes. Las verificaciones de estado no están disponibles para el reenvío, el intercambio de tráfico ni zonas de búsqueda inversa.
Para obtener información detallada sobre las verificaciones de estado para 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 usando el 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 sea apto para recibir tráfico cuando se encuentre al menos el 20% de las verificaciones de estado son correctas.
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 que se ejecutan detrás de él. Cloud DNS busca señales de salud del protocolo y el puerto especificados en la configuración de verificación de estado para la balanceador de cargas HTTP(S) global externo. 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 elemento El balanceador de cargas recibe una consulta y distribuye el tráfico solo al backend en buen estado de Google Cloud. Para asegurarte de que haya backends en buen estado, puedes administrar el ciclo de vida del los backends usando servicios como grupos de instancias administrados (MIG). Cloud DNS no necesita conocer el estado de las personas backends; el balanceador de cargas se encarga de esta tarea.
Políticas del round robin ponderado y verificaciones de estado
Cloud DNS admite pesos de 0 a 1,000, ambos incluidos. Cuándo se incluyen las verificaciones de estado, ocurre lo siguiente:
- Si configuras varios destinos, todos con peso 0, el tráfico se distribuye por igual entre los objetivos.
- Si configuras un nuevo objetivo ponderado distinto de cero, este se convierte en objetivo principal y todo el tráfico se traslada a ese objetivo.
- A medida que agregues más destinos con pesos distintos de cero, Cloud DNS Calcula de forma dinámica la división del tráfico entre los destinos (con cada solicitud). y distribuye el tráfico de forma adecuada. Por ejemplo, si tienes configuraste tres objetivos con ponderaciones de 0, 25 y 75; el objetivo con el peso 0 no recibe tráfico, el objetivo con un peso de 25 obtiene un cuarto de el tráfico, y el objetivo restante recibirá tres cuartos de la cantidad tráfico.
- Si las verificaciones de estado están asociadas con objetivos ponderados distintos de cero, pero no con sin objetivos ponderados, los objetivos ponderados en cero siempre se consideran en buen estado. Si todos los registros distintos de cero están en mal estado, Cloud DNS devuelve los registros ponderados cero.
- Si las verificaciones de estado están asociadas con valores ponderados distintos de cero y cero y, si todos ellos fallan las verificaciones de estado, Cloud DNS devuelve cualquier objetivo ponderado que no sea cero y evita los objetivos ponderados cero.
- Cuando Cloud DNS elige un bucket de peso para devolver al solicitante (un único elemento de la política), solo se determina la dirección IP que se devuelven. Si solo especificas una dirección IP en el bucket de peso, solo esa la dirección IP en la respuesta. Si hay más de una dirección IP en el bucket de peso, Cloud DNS devuelve todas las direcciones IP de orden aleatorio.
Política de ubicación geográfica con verificación de estado
Para las políticas de ubicación geográfica con verificaciones de estado habilitadas, ocurre lo siguiente:
- Cuando un bucket geográfico tiene varias direcciones IP configuradas, y todas 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 verificación de estado fallan todas las direcciones IP con verificación de estado, Cloud DNS devuelve todas Direcciones IP que no tenían configurada la verificación de estado. En este caso, la conmutación por error automática a la siguiente ubicación geográfica más cercana.
- Esta política enruta automáticamente el tráfico al siguiente bucket geográfico más cercano
cuando:
- Todas las direcciones IP de un bucket geográfico 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 tener una configuración conmutación por error al siguiente destino geográfico más cercano.
Registro de verificaciones de estado
Cloud DNS admite la verificación de estado registro y registra la verificación de estado el estado de cualquier cambio en el backend. Te permite realizar las siguientes acciones:
- Valida si las políticas de enrutamiento tienen el rendimiento esperado. Para
ejemplo:
- En el caso de las políticas
GEO, te permite validar si se detectan la ubicación geográfica correcta y devolver el conjunto de datos de RR correcto. - Para las políticas de
WRR, te permite validar si las políticas devuelven las direcciones IP con la ponderación correcta.
- En el caso de las políticas
- Identificar problemas de infraestructura con backends y direcciones IP específicas que fallan.
- Solucionar problemas relacionados con el motivo por el que ciertos backends nunca se incluyen o son los únicos que se devuelven.
Para crear, editar o borrar políticas de enrutamiento de DNS, sigue estos pasos: consulta Administra el estado y las políticas de enrutamiento de DNS y verificaciones de control.
Tipos de registros compatibles con las políticas de enrutamiento de DNS
Las políticas de enrutamiento DNS no admiten todos los tipos de registro que respaldada por Cloud DNS 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 |