Un DNS che si adatta alle Sue pipeline
Terraform, OctoDNS, Certbot, REST API e una CLI vera – DNS dichiarativo su un backend gestito a tariffa fissa.
Perché il DNS è l’ultima cosa manuale nel Suo stack
L’Infrastructure-as-Code copre tutto tranne il DNS, perché il DNS è di solito presso un provider con un’API datata.
Provider Terraform che funzionano quasi
Provider della community mantenuti a metà, tipi di record mancanti, autenticazioni che si rompono ogni trimestre. Il DNS diventa lo step di terraform apply che fallisce.
Nessuna CLI seria
Vuole automatizzare una modifica alla zona. Il provider offre un’interfaccia web, un SDK Python obsoleto e nient’altro.
Sorprese nella fatturazione a query
La fatturazione a query rende il costo difficile da prevedere da un piano di deploy – un picco di traffico fa salire la bolletta senza preavviso.
Per ACME DNS-01 serve un plugin che non esiste
I certificati wildcard via DNS-01 richiedono la scrittura di un hook Certbot personalizzato per qualunque provider DNS utilizzi.
Cosa ottiene con NexDNS
Strumenti che presumono che il Suo DNS viva nello stesso repository dei Suoi Terraform.
- Provider Terraform ufficiale
nexdns/nexdnssul Terraform Registry. Risorsenexdns_zoneenexdns_record, gestione completa del ciclo di vita, mantenuto in sincronia con la piattaforma.- CLI in Go con DNS dichiarativo
nexdns apply -f nexdns.yaml– applica una rappresentazione YAML dichiarativa delle Sue zone. Idempotente, con dry-run supportato e exit code adatti alla CI.- Provider OctoDNS
- Sincronizzi le zone da qualunque provider supportato da OctoDNS (BIND, Route 53, Cloudflare, Hetzner e altri) in NexDNS con un’unica invocazione di
octodns-sync. - Plugin DNS Certbot per Let's Encrypt
certbot-dns-nexdnsè un plugin DNS-01 ufficiale. I certificati wildcard si emettono e rinnovano automaticamente – nessun hook personalizzato, nessun proxy webhook.- REST API con chiavi con ambito
- Ogni azione del pannello ha un endpoint API documentato. Chiavi API con ambito per azioni specifiche (
zones.read,records.write,dnssec.manage). I limiti di richieste emergono prima di impattarLa. - Prezzi fissi, nessuna fatturazione a query
- Starter, Pro, Business, Enterprise – scelga il piano in base ai limiti di zone e record, non al traffico che instrada. Costo prevedibile già dal piano di deploy.
Una configurazione DevOps tipica
Le modifiche DNS passano dalla review git come tutto il resto.
-
1
Fare il provisioning delle zone tramite Terraform
resource "nexdns_zone" "app" { name = "example.com" }– parte della Sua configurazione Terraform principale, pianificata e applicata insieme a VPC e cluster Kubernetes. -
2
Definire i record come codice
Utilizzi le risorse Terraform
nexdns_record, oppure YAML vianexdns apply, oppure YAML OctoDNS. Qualunque cosa si adatti al resto della Sua pipeline – tutte e tre funzionano sullo stesso backend. -
3
Rivedere le modifiche DNS nelle pull request
Le modifiche DNS sono diff. Chi fa la review vede esattamente quali record vengono aggiunti, modificati o rimossi. Niente più «qualcuno ha cambiato il record MX e adesso l’email non funziona».
-
4
Collegare Certbot per i certificati wildcard
certbot certonly --dns-nexdns --dns-nexdns-credentials /etc/letsencrypt/nexdns.ini -d '*.example.com'– challenge DNS-01 gestita end-to-end, rinnovo automatico via il normale cron di Certbot. -
5
Monitorare le quote API e ricevere avvisi
Gli header di rate limit di NexDNS espongono la quota residua. Li raccolga con il Suo monitoring abituale (Prometheus, Datadog) e riceva avvisi prima che le richieste inizino a fallire nei deploy.
-
Sì – è il provider ufficiale di prima parte, pubblicato sul Terraform Registry. La forma delle risorse è stabile con versionamento semver; breaking change solo al major bump. La gestione dello state funziona come si aspetta: Terraform calcola un piano, applica in modo idempotente, gestisce il rilevamento del drift.
-
Terraform è la scelta giusta se il DNS fa parte di uno stato infrastrutturale più ampio (risorse miste, disciplina plan-and-apply). Il YAML via
nexdns applyè più leggero – migliore quando il DNS è la preoccupazione principale (ad esempio, un team che gestisce 50 domini ma nessun’altra infrastruttura). Può utilizzarli entrambi sullo stesso account. -
Il plugin gestisce la challenge DNS-01; Certbot gestisce tutto il resto. Utilizzi DNS-01 per i wildcard (dove è richiesto) e HTTP-01 per i nomi singoli (dove è più semplice). Il plugin si attiva solo quando Certbot necessita del DNS-01.
-
L’API REST consente 60 richieste al minuto, conteggiate per account (o per IP per le richieste non autenticate). Il limite è lo stesso su tutti i piani, senza livelli per piano. Ogni risposta include gli header
X-RateLimit-Limit,X-RateLimit-RemainingeX-RateLimit-Reset, oltre aRetry-Afterin caso di 429, così può rallentare prima che le richieste inizino a fallire. -
Sì. La CLI è un unico binario Go (installabile con
curl -sL https://get.nexdns.tech/cli | shnel runner), e il provider Terraformnexdnsfunziona con i pattern CI standard di Terraform. Le chiavi API vanno nei secret della CI, con ambito limitato al minimo necessario.
Usi gli strumenti DNS che già utilizza
Terraform, CLI, OctoDNS, Certbot – gli strumenti che già utilizza, supportati nativamente.