GeoDNS y Health Checks de DNS: Enruta por Región y Haz Failover Automático

El DNS de CubePath puede hacer dos cosas que una zona DNS normal no puede: responder IPs distintas a los visitantes de cada región (GeoDNS) y sacar automáticamente de rotación un servidor caído hasta que vuelva (Health Checks). Juntas te permiten servir el mismo hostname desde varios servidores por el mundo y mantenerlo apuntando solo a los que están cerca y vivos.

Es la configuración habitual para apps multi-región, APIs sensibles a la latencia, failover activo/standby, y cualquier servicio donde un único registro A a una sola máquina no basta.

Cómo funciona

Etiquetas cada registro A/AAAA con una región (o lo dejas en global). Nuestro edge anycast responde a cada visitante con el registro cuya región le queda más cerca, y recurre a tus registros global cuando no hay coincidencia regional. Por separado, asocias un health check a un registro: sondeamos su destino en el intervalo que elijas desde varias ubicaciones, y cuando falla suficientes veces seguidas dejamos de entregar esa IP en las respuestas DNS hasta que vuelve a pasar. Configuras ambas cosas en el panel o por la API; el enrutado y el sondeo ocurren en el edge, sin instalar nada.

Antes de empezar

• GeoDNS y Health Checks forman parte de los planes DNS Pro y Business. Las zonas Free no pueden usar ninguno. Sube el plan de la zona en su configuración de DNS en el panel.
• En el panel: my.cubepath.com → DNS → tu zona.
• Por la API: URL base https://api.cubepath.com, autentica con Authorization: Bearer <token> (scopes dns:read / dns:write) y añade X-Requested-With: XMLHttpRequest en las escrituras. Consigue un token en Cuenta → Tokens de API.

Parte 1: GeoDNS

Las regiones

Cada registro A/AAAA lleva una región. global (el valor por defecto) se sirve en todas partes; un valor regional se sirve solo a los visitantes cercanos a esa región.

Puedes listarlas en cualquier momento con GET /dns/regions.

Global más overrides regionales

El truco que hace seguro a GeoDNS es que el mismo nombre en una región distinta es un registro separado. Así publicas un registro global como comodín y luego añades registros regionales que lo sobrescriben para los visitantes cercanos:

www  A  185.230.55.10   region = global       (fallback, todos)
www  A  10.0.1.5        region = eu-west       (servido en/cerca de Ámsterdam)
www  A  10.0.2.5        region = us-east       (servido en/cerca de Virginia, Miami)

Un visitante en Madrid recibe la respuesta eu-west; uno en Texas recibe us-east; uno sin coincidencia regional recibe la global. Mantén siempre al menos un registro global por nombre para que nadie se quede sin respuesta.

Asignar una región desde la API

Añade region al crear o actualizar un registro:

curl -X POST https://api.cubepath.com/dns/zones/<zone_uuid>/records \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{ "name": "www", "record_type": "A", "content": "10.0.1.5", "ttl": 60, "region": "eu-west" }'

Dejar region fuera, vacío, o en "global" significa lo mismo: servido en todas partes. En el panel es un desplegable Región en el formulario del registro.

Parte 2: Health Checks

Un health check vigila el destino de un registro y lo retira del DNS cuando deja de responder. Un health check por registro.

A qué puedes asociarlo

Los health checks funcionan solo en registros A y AAAA. Es a propósito: el failover funciona quitando una IP caída del conjunto de respuestas, lo cual solo tiene sentido cuando el valor del registro es una dirección que se puede sondear. No se puede hacer health check de un MX, NS, TXT, ni de un CNAME suelto.

Tipos de check

Parámetros

Crear uno desde la API

curl -X PUT https://api.cubepath.com/dns/zones/<zone_uuid>/records/<record_uuid>/health-check \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "api uptime",
    "check_type": "https",
    "path": "/health",
    "expected_status": 200,
    "interval_secs": 30,
    "timeout_secs": 5,
    "healthy_threshold": 2,
    "unhealthy_threshold": 3
  }'

La misma llamada actualiza un check existente (es un upsert). En el panel es el apartado Health check del registro.

Qué significa el estado

Cada check reporta un last_status:

• healthy: el destino está pasando; su IP se está sirviendo.
• unhealthy: falló unhealthy_threshold veces seguidas; su IP no se está sirviendo ahora mismo.
• unknown: el check se acaba de crear y todavía no ha hecho suficientes sondeos.

Cuando un destino se recupera y pasa healthy_threshold veces, su IP vuelve al DNS automáticamente.

Combinándolos

Región y health check se apilan en el mismo registro. Un patrón común es un registro con health check por región más un fallback global, así los visitantes reciben el servidor más cercano, los servidores caídos se retiran solos, y el registro global recoge a quien no tiene coincidencia regional:

api  A  185.230.55.10  region = global    + health check
api  A  10.0.1.5        region = eu-west    + health check
api  A  10.0.2.5        region = us-east    + health check

Mantén el TTL del registro bajo (por ejemplo de 30 a 60 segundos) para que los resolvers recojan rápido un failover o un cambio de región.

Planes y precio

Cada health check se factura a $10/mes, prorrateado y detenido en cuanto lo eliminas o lo desactivas.

Lo que esto no hace

• GeoDNS enruta por la ubicación del resolver del visitante, no por carga. No es un balanceador de carga; manda toda una región a un conjunto de respuestas, no reparte peticiones por carga de servidor. Para balanceo por petición dentro de una región, usa un Load Balancer.
• Un health check es por registro, no por servicio. Vigila una IP. Si tienes tres servidores, son tres registros y tres checks.
• El failover de DNS no es instantáneo. Los resolvers cachean las respuestas durante el TTL, así que el failover es tan rápido como tu TTL más el intervalo del check. Pon ambos bajos si necesitas un cambio rápido.

Solución de problemas

Referencia de la API

GET    /dns/regions                                          Listar regiones de GeoDNS.       (scope: dns:read)
POST   /dns/zones/{uuid}/records          { ..., "region" }  Crear un registro con región.    (scope: dns:write)
PUT    /dns/zones/{uuid}/records/{uuid}   { "region" }       Cambiar la región de un registro. (scope: dns:write)
GET    /dns/zones/{uuid}/health-checks                       Listar los health checks de una zona. (scope: dns:read)
GET    /dns/zones/{uuid}/records/{uuid}/health-check         Ver el health check de un registro. (scope: dns:read)
PUT    /dns/zones/{uuid}/records/{uuid}/health-check  {...}  Crear o actualizar (upsert).     (scope: dns:write)
DELETE /dns/zones/{uuid}/records/{uuid}/health-check         Eliminar (se detiene la facturación). (scope: dns:write)

Todas las peticiones se autentican con Authorization: Bearer <token> (o X-API-Key). Las peticiones de escritura necesitan además X-Requested-With: XMLHttpRequest.