DNS que encaja en tus pipelines
Terraform, OctoDNS, Certbot, API REST y un CLI de verdad – DNS-as-Code sobre un backend gestionado con precios de tarifa plana.
Por qué el DNS sigue siendo lo último que haces a mano
Infrastructure-as-Code cubre todo menos el DNS, porque el DNS suele estar en un proveedor con una API anticuada.
Providers de Terraform que casi funcionan
Providers comunitarios a medio mantener, tipos de registro que faltan, autenticación que se rompe cada trimestre. El DNS acaba siendo el paso de terraform apply que falla.
Sin un CLI decente
Quieres scriptear un cambio en una zona. El proveedor te ofrece una UI web, un SDK de Python desactualizado y nada más.
Sorpresas con la facturación por consulta
La facturación por consulta hace que el coste sea difícil de prever desde un plan de despliegue – un pico de tráfico aumenta la factura sin aviso.
ACME DNS-01 necesita un plugin que no existe
Para certificados wildcard vía DNS-01 acabas escribiendo un hook personalizado de Certbot para el proveedor DNS de turno.
Lo que obtienes con NexDNS
Tooling que asume que tu DNS vive en el mismo repo que tu Terraform.
- Provider oficial de Terraform
nexdns/nexdnsen el Terraform Registry. Recursosnexdns_zoneynexdns_record, gestión completa del lifecycle, mantenido en sincronía con la plataforma.- CLI en Go con DNS-as-Code
nexdns apply -f nexdns.yaml– aplica una representación declarativa en YAML de tus zonas. Idempotente, dry-run soportado, exit codes amigables para CI.- Provider de OctoDNS
- Sincroniza zonas desde cualquier proveedor que OctoDNS soporte (BIND, Route 53, Cloudflare, Hetzner y más) hacia NexDNS con una sola invocación de
octodns-sync. - Plugin DNS de Certbot para Let's Encrypt
certbot-dns-nexdnses un plugin DNS-01 oficial. Los certificados wildcard se emiten y renuevan automáticamente – sin scripts hook personalizados, sin proxies de webhook.- API REST con claves por scopes
- Cada acción del panel tiene un endpoint de API documentado. Claves de API con scope para acciones concretas (
zones.read,records.write,dnssec.manage). Los rate limits se ven antes de que te afecten. - Precio plano, sin facturación por consulta
- Starter, Pro, Business, Enterprise – eliges plan por límites de zonas y registros, no por cuánto tráfico enrutas. Coste predecible desde el plan de despliegue.
Un setup típico de DevOps
Los cambios DNS pasan por revisión en git como todo lo demás.
-
1
Aprovisiona zonas vía Terraform
resource "nexdns_zone" "app" { name = "example.com" }– parte de tu config principal de Terraform, planificado y aplicado junto a VPCs y clusters de Kubernetes. -
2
Define los registros como código
Usa recursos
nexdns_recordde Terraform, o YAML connexdns apply, o YAML de OctoDNS. Lo que mejor encaje en tu pipeline – los tres funcionan contra el mismo backend. -
3
Revisa los cambios DNS en PRs
Los cambios DNS son diffs. El reviewer ve exactamente qué registros se añaden, modifican o eliminan. Se acabó el "alguien tocó el registro MX y ahora el correo no funciona".
-
4
Conecta Certbot para certificados wildcard
certbot certonly --dns-nexdns --dns-nexdns-credentials /etc/letsencrypt/nexdns.ini -d '*.example.com'– el reto DNS-01 se gestiona de extremo a extremo, con auto-renovación vía el cron estándar de Certbot. -
5
Monitoriza y alerta sobre las cuotas de la API
Las cabeceras de rate-limit de NexDNS exponen la cuota restante. Recógelas con tu monitorización habitual (Prometheus, Datadog) y alerta antes de que las peticiones empiecen a fallar en los despliegues.
-
Sí – es el provider oficial de primera parte, publicado en el Terraform Registry. La forma de los recursos es estable con versionado semver; los cambios incompatibles solo ocurren en saltos de versión mayor. La gestión de estado funciona como esperas: Terraform calcula un plan, aplica de forma idempotente y detecta drift.
-
Terraform encaja cuando el DNS forma parte de un estado de infra mayor (recursos mixtos, disciplina de plan-and-apply). El YAML vía
nexdns applyes más ligero – mejor cuando el DNS es lo principal (por ejemplo, un equipo que gestiona 50 dominios pero ninguna otra infra). Puedes usar ambos en la misma cuenta. -
El plugin gestiona el reto DNS-01; Certbot gestiona todo lo demás. Usa DNS-01 para wildcards (donde es obligatorio) y HTTP-01 para nombres simples (donde es más sencillo). El plugin solo entra en juego cuando Certbot necesita DNS-01.
-
La API REST permite 60 solicitudes por minuto, contadas por cuenta (o por IP en solicitudes no autenticadas). El límite es el mismo en todos los planes, sin niveles por plan. Cada respuesta incluye las cabeceras
X-RateLimit-Limit,X-RateLimit-RemainingyX-RateLimit-Reset, además deRetry-Afteren un 429, para que puedas reducir el ritmo antes de que las solicitudes empiecen a fallar. -
Sí. El CLI es un único binario en Go (instalable con
curl -sL https://get.nexdns.tech/cli | shen el runner) y el providernexdnsde Terraform funciona con los patrones estándar de Terraform en CI. Las claves de API van en los secretos de tu CI, con scope al mínimo de permisos necesarios.
Usa las herramientas DNS que ya tienes
Terraform, CLI, OctoDNS, Certbot – el tooling que ya usas, soportado de forma nativa.