Un DNS qui s’intègre à vos pipelines
Terraform, OctoDNS, Certbot, API REST et un vrai CLI – du DNS-as-Code sur un backend managé à tarif forfaitaire.
Pourquoi le DNS est la dernière chose manuelle de votre stack
L’Infrastructure-as-Code couvre tout sauf le DNS, parce que le DNS est généralement chez un fournisseur à l’API vieillissante.
Des providers Terraform qui fonctionnent presque
Des providers communautaires à moitié maintenus, des types d’enregistrements manquants, une authentification qui casse chaque trimestre. Le DNS devient l’étape terraform apply qui échoue.
Pas de vrai CLI
Vous voulez scripter un changement de zone. Le fournisseur propose une interface web, un SDK Python dépassé, et rien d’autre.
Surprises de facturation à la requête
La facturation à la requête rend le coût difficile à prévoir depuis un plan de déploiement – un pic de trafic alourdit la facture sans prévenir.
ACME DNS-01 nécessite un plugin qui n’existe pas
Obtenir des certificats wildcard via DNS-01 oblige à écrire un hook Certbot personnalisé pour le fournisseur DNS sur lequel vous êtes.
Ce que vous obtenez avec NexDNS
Un outillage qui suppose que votre DNS vit dans le même dépôt que votre Terraform.
- Provider Terraform officiel
nexdns/nexdnssur le Terraform Registry. Ressourcesnexdns_zoneetnexdns_record, gestion complète du cycle de vie, maintenu en synchronisation avec la plateforme.- CLI Go avec DNS-as-Code
nexdns apply -f nexdns.yaml– appliquez une représentation YAML déclarative de vos zones. Idempotent, dry-run pris en charge, codes de sortie compatibles CI.- Provider OctoDNS
- Synchronisez les zones depuis n’importe quel fournisseur pris en charge par OctoDNS (BIND, Route 53, Cloudflare, Hetzner et d’autres) vers NexDNS en une seule invocation
octodns-sync. - Plugin DNS Certbot pour Let's Encrypt
certbot-dns-nexdnsest un plugin DNS-01 officiel. Les certificats wildcard sont émis et renouvelés automatiquement – pas de scripts hook personnalisés, pas de proxys webhook.- API REST avec clés à portée définie
- Chaque action du tableau de bord dispose d’un endpoint API documenté. Les clés API sont à portée définie sur des actions précises (
zones.read,records.write,dnssec.manage). Les limites de débit apparaissent avant de vous impacter. - Tarifs fixes, pas de facturation à la requête
- Starter, Pro, Business, Enterprise – choisissez un plan en fonction des limites de zones/enregistrements, pas de la quantité de trafic que vous routez. Coût prévisible dès le plan de déploiement.
Une configuration DevOps typique
Les changements DNS passent par la revue git comme tout le reste.
-
1
Provisionner les zones via Terraform
resource "nexdns_zone" "app" { name = "example.com" }– fait partie de votre configuration Terraform principale, planifié et appliqué aux côtés des VPC et des clusters Kubernetes. -
2
Définir les enregistrements en tant que code
Utilisez les ressources Terraform
nexdns_record, le YAML vianexdns apply, ou le YAML OctoDNS. Selon ce qui s’intègre au reste de votre pipeline – les trois fonctionnent contre le même backend. -
3
Revoir les changements DNS en PR
Les changements DNS sont des diffs. Le relecteur voit exactement quels enregistrements sont ajoutés, modifiés ou supprimés. Fini le « quelqu’un a changé l’enregistrement MX et maintenant les emails sont cassés ».
-
4
Brancher Certbot pour les certificats wildcard
certbot certonly --dns-nexdns --dns-nexdns-credentials /etc/letsencrypt/nexdns.ini -d '*.example.com'– challenge DNS-01 géré de bout en bout, renouvellement automatique via le cron Certbot standard. -
5
Superviser et alerter sur les quotas d’API
Les en-têtes de rate-limit de NexDNS exposent le quota restant. Scrapez-les avec votre supervision habituelle (Prometheus, Datadog) et alertez avant que les requêtes ne commencent à échouer lors des déploiements.
Questions fréquemment posées
Les questions les plus courantes, avec des réponses.
Parcourir la documentation-
Oui – c’est le provider officiel first-party, publié sur le Terraform Registry. La forme des ressources est stable avec un versioning sémantique ; les ruptures de compatibilité n’arrivent qu’aux montées de version majeure. La gestion de l’état fonctionne comme attendu : Terraform calcule un plan, applique de manière idempotente, gère la détection de dérive.
-
Terraform est le bon choix si le DNS fait partie d’un état d’infrastructure plus large (ressources mixtes, discipline plan-and-apply). Le YAML via
nexdns applyest plus léger – préférable quand le DNS est la préoccupation principale (par exemple, une équipe qui gère 50 domaines mais aucune autre infrastructure). Vous pouvez utiliser les deux sur le même compte. -
Le plugin gère le challenge DNS-01 ; Certbot gère tout le reste. Utilisez DNS-01 pour les wildcards (là où il est requis) et HTTP-01 pour les noms uniques (là où c’est plus simple). Le plugin n’intervient que lorsque Certbot a besoin de DNS-01.
-
L’API REST autorise 60 requêtes par minute, comptées par compte (ou par IP pour les requêtes non authentifiées). La limite est la même sur tous les plans, sans paliers par plan. Chaque réponse inclut les en-têtes
X-RateLimit-Limit,X-RateLimit-RemainingetX-RateLimit-Reset, ainsi queRetry-Afteren cas de 429, pour vous permettre de ralentir avant que les requêtes ne commencent à échouer. -
Oui. Le CLI est un binaire Go unique (installable via
curl -sL https://get.nexdns.tech/cli | shsur le runner), et le providernexdnsde Terraform fonctionne avec les patterns CI Terraform standards. Les clés API vont dans les secrets de votre CI, à portée définie sur les permissions strictement nécessaires.
Utilisez l’outillage DNS que vous avez déjà
Terraform, CLI, OctoDNS, Certbot – l’outillage que vous utilisez déjà, pris en charge nativement.