GeoDNS responde IPs distintas a visitantes de regiones distintas, para que cada usuario llegue al servidor más cercano. No es una pestaña aparte: es el campo Región de cada registro A y AAAA, en la pestaña Registros de la zona.
NotaEl selector de región solo aparece en zonas Pro y Business. En una zona Free todos los registros son globales.
Las regiones
| Región | Se sirve a visitantes cerca de |
|---|---|
global | Todas partes — es el valor por defecto |
us-east | EE. UU. Este (Virginia, Miami) |
us-central | EE. UU. Centro (Houston) |
eu-west | Europa Oeste (Ámsterdam) |
eu-south | Europa Sur (España) |
Cómo se comporta
El mecanismo que hace esto seguro es que el mismo nombre en otra región es un registro distinto. No estás editando la respuesta de un registro por región: estás publicando varios registros bajo un mismo nombre, cada uno etiquetado con el público al que va.
Publica un registro global como comodín y añade después registros regionales que lo sobrescriban en su zona:
www A 185.230.55.10 región = global (respaldo, para todos)
www A 10.0.1.5 región = eu-west (se sirve en/cerca de Ámsterdam)
www A 10.0.2.5 región = us-east (se sirve en/cerca de Virginia, Miami)
Un visitante en Madrid recibe la respuesta eu-west, uno en Texas la us-east, y quien no case con ninguna región recibe la global. En la lista de registros, los que no son globales llevan su región como etiqueta junto al valor, así ves el reparto de un vistazo.
AdvertenciaMantén siempre al menos un registro
globalpor nombre. Sin él, un visitante cuyo resolver no case con ninguna región no recibe ninguna respuesta — no una respuesta lenta: ninguna.
Qué significa de verdad "la región del visitante"
Casamos por la ubicación del resolver, no la del visitante. Para la gran mayoría de usuarios son el mismo sitio: el resolver de su ISP está cerca de ellos. Se separan cuando alguien usa un resolver público lejano, un resolver corporativo de otro país o una VPN. Esos usuarios reciben la respuesta del sitio donde esté su resolver, que es el comportamiento correcto — de ahí sale realmente su tráfico —, pero es la razón de que un usuario concreto pueda decir que "le toca el servidor equivocado" mientras el enrutado funciona exactamente como se diseñó.
Usarlo bien
- Empieza global y luego añade. Consigue primero un registro global que funcione y superpón las regiones encima. Así nunca falta el respaldo.
- El TTL bajo solo hace falta si los destinos se mueven. El enrutado por región no necesita TTL bajo; el failover sí. Mira Health checks.
- Pon un servidor real en cada región que publiques. Un registro regional que apunta a una máquina al otro lado del mundo es peor que no tener registro regional.
- Región y health check se apilan. Un registro comprobado por región más un respaldo global te da enrutado al servidor más cercano, retirada automática de los servidores muertos y una respuesta para todos los demás.
Diagnóstico
| Síntoma | Causa probable |
|---|---|
| No aparece el selector de región | La zona está en el plan Free; GeoDNS requiere Pro o Business |
| El cambio de región no surte efecto | Un resolver sigue sirviendo la respuesta cacheada; espera al TTL |
| Un visitante recibe la respuesta global sin esperarlo | No hay registro para su región, o su resolver está geográficamente lejos de él |
| Una región no recibe tráfico | Comprueba que exista de verdad un registro etiquetado con ella — si falta, cae en silencio al global |
ConsejoGeoDNS reparte visitantes entre ubicaciones. No balancea peticiones entre los servidores de una misma ubicación, ni sabe nada de carga. Para eso, pon un Balanceador de Carga detrás de la dirección regional.