Découvrez PostScale -- API e-mail pour l'envoi transactionnel, la réception et les adresses masquées. PostScale

    DNS multi-fournisseurs avec Terraform et DNSControl

    Deployez des zones DNS a travers DNScale et Hetzner DNS pour la redondance en utilisant Terraform ou DNSControl.

    Faire transiter votre DNS par un seul fournisseur signifie un point de defaillance unique. Si ce fournisseur tombe en panne — qu'il s'agisse d'une panne, d'une attaque DDoS ou d'une mauvaise configuration — vos domaines deviennent inaccessibles. Le DNS multi-fournisseurs elimine ce risque en servant la meme zone depuis deux fournisseurs independants simultanement.

    Ce guide explique comment configurer DNScale et Hetzner DNS en tant que fournisseurs doubles en utilisant Terraform ou DNSControl. Les deux outils vous permettent de definir les enregistrements une seule fois et de les envoyer aux deux fournisseurs, gardant tout synchronise sans duplication manuelle.

    Pourquoi le DNS multi-fournisseurs

    Le DNS est la base de chaque service Internet que vous exploitez. Une panne de fournisseur ne signifie pas seulement que votre site web est inaccessible — cela signifie que les e-mails cessent de circuler, les API deviennent inaccessibles et les services qui dependent d'enregistrements SRV ou TXT cessent de fonctionner.

    Le DNS multi-fournisseurs fonctionne en deleguant votre domaine aux serveurs de noms des deux fournisseurs. Les resolveurs du monde entier interrogeront l'ensemble de serveurs de noms qui repond, donc si un fournisseur est en panne, l'autre continue de servir les reponses.

    Quand le multi-fournisseurs a-t-il du sens ?

    • Domaines de production ou les temps d'arret ont un cout reel
    • Environnements de conformite qui exigent de la redondance
    • Services mondiaux ou la couverture des fournisseurs varie selon la region

    Quand est-ce excessif ? Pour les domaines de developpement, l'outillage interne ou les domaines ou quelques minutes d'indisponibilite sont acceptables, un seul fournisseur avec une bonne disponibilite est generalement suffisant.

    Comment ca fonctionne

    Le concept est simple :

    1. Definissez vos enregistrements une fois dans Terraform ou DNSControl
    2. Envoyez des enregistrements identiques a DNScale et Hetzner DNS
    3. Configurez les enregistrements NS chez votre registraire pointant vers les serveurs de noms des deux fournisseurs
    4. Les resolveurs interrogent l'un ou l'autre — celui qui repond en premier gagne
    ┌──────────────┐
│   Registraire│
│              │
│ NS records:  │
│  ns1.dnscale │
│  ns2.dnscale │
│  hydrogen.ns │  ← Hetzner
│  oxygen.ns   │  ← Hetzner
└──────┬───────┘
       │
       ▼
┌──────────────┐     ┌──────────────┐
│   DNScale    │     │  Hetzner DNS │
│              │     │              │
│ example.com  │     │ example.com  │
│  A, MX, TXT  │     │  A, MX, TXT  │
│ (identiques) │     │ (identiques) │
└──────────────┘     └──────────────┘
       ▲                    ▲
       │    ┌──────────┐    │
       └────│ Resolveur│────┘
            └──────────┘
      Interroge l'un ou l'autre

    Les deux fournisseurs detiennent les memes enregistrements. Votre outil IaC est la source unique de verite, et les deux fournisseurs ne sont que des miroirs de cette verite.

    Prerequis

    Vous aurez besoin de :

    1. Un compte DNScale avec une cle API — Obtenir votre cle API
    2. Un compte Hetzner DNS avec un jeton API — Console Hetzner DNS
    3. Terraform (v1.0+) ou DNSControl (v4.0+) installe
    4. Un domaine que vous controlez avec acces pour configurer les enregistrements NS chez le registraire

    Terraform : Configuration multi-fournisseurs

    Terraform rend le DNS multi-fournisseurs propre avec son support natif de plusieurs providers et les boucles for_each. Vous definissez vos enregistrements une fois dans un bloc locals et les creez chez les deux fournisseurs.

    Configuration des providers

    # providers.tf
terraform {
  required_providers {
    dnscale = {
      source  = "dnscaleou/dnscale"
      version = "~> 1.0"
    }
    hetznerdns = {
      source  = "timohirt/hetznerdns"
      version = "~> 2.2"
    }
  }
}
 
provider "dnscale" {
  api_key = var.dnscale_api_key
}
 
provider "hetznerdns" {
  apitoken = var.hetzner_dns_token
}
    # variables.tf
variable "dnscale_api_key" {
  description = "DNScale API key"
  type        = string
  sensitive   = true
}
 
variable "hetzner_dns_token" {
  description = "Hetzner DNS API token"
  type        = string
  sensitive   = true
}
 
variable "domain" {
  description = "Domain to manage"
  type        = string
  default     = "example.com"
}

    Definir les enregistrements une fois

    La cle du DNS multi-fournisseurs avec Terraform est de definir vos enregistrements en un seul endroit. Utilisez locals pour creer un jeu d'enregistrements partage :

    # records.tf
locals {
  dns_records = {
    # Enregistrements A
    "root-a" = {
      name  = "@"
      type  = "A"
      value = "203.0.113.10"
      ttl   = 3600
    }
    "www-a" = {
      name  = "www"
      type  = "CNAME"
      value = "example.com."
      ttl   = 3600
    }
    # Messagerie
    "mx-primary" = {
      name     = "@"
      type     = "MX"
      value    = "mail.example.com."
      ttl      = 3600
      priority = 10
    }
    "mail-a" = {
      name  = "mail"
      type  = "A"
      value = "203.0.113.20"
      ttl   = 3600
    }
    # SPF
    "spf" = {
      name  = "@"
      type  = "TXT"
      value = "v=spf1 mx -all"
      ttl   = 3600
    }
    # IPv6
    "root-aaaa" = {
      name  = "@"
      type  = "AAAA"
      value = "2001:db8::1"
      ttl   = 3600
    }
  }
}

    Creer chez les deux fournisseurs

    # dnscale.tf
resource "dnscale_zone" "primary" {
  name = var.domain
}
 
resource "dnscale_record" "all" {
  for_each = local.dns_records
 
  zone_id  = dnscale_zone.primary.id
  name     = each.value.name
  type     = each.value.type
  content  = each.value.value
  ttl      = each.value.ttl
  priority = lookup(each.value, "priority", null)
}
    # hetzner.tf
resource "hetznerdns_zone" "secondary" {
  name = var.domain
  ttl  = 3600
}
 
resource "hetznerdns_record" "all" {
  for_each = local.dns_records
 
  zone_id = hetznerdns_zone.secondary.id
  name    = each.value.name
  type    = each.value.type
  value   = each.value.value
  ttl     = each.value.ttl
}

    Pour les enregistrements MX sur Hetzner DNS, la priorite est generalement incluse dans le champ value (ex. "10 mail.example.com."). Vous devrez peut-etre ajuster le format selon la version du provider. Consultez la documentation du provider Terraform Hetzner DNS pour les details.

    Appliquer

    export TF_VAR_dnscale_api_key="your-dnscale-key"
export TF_VAR_hetzner_dns_token="your-hetzner-token"
 
terraform init
terraform plan    # Examiner les changements pour les deux fournisseurs
terraform apply   # Envoyer aux deux simultanement

    Terraform cree les ressources chez les deux fournisseurs en parallele, donc un seul apply met tout a jour. Pour une exploration plus approfondie du provider DNScale specifiquement, consultez le guide du provider Terraform.

    DNSControl : Configuration multi-fournisseurs

    DNSControl dispose d'un support natif multi-fournisseurs integre. Vous pouvez attacher plusieurs providers DNS a un seul domaine, et DNSControl envoie des enregistrements identiques a tous en une seule commande.

    Identifiants

    // creds.json
{
  "dnscale": {
    "TYPE": "DNSCALE",
    "api_key": "your-dnscale-key"
  },
  "hetzner": {
    "TYPE": "HETZNER",
    "api_token": "your-hetzner-token"
  }
}

    Gardez creds.json hors du controle de version :

    echo "creds.json" >> .gitignore

    Configuration

    La fonction DnsProvider() de DNSControl accepte plusieurs providers pour un seul domaine. Les enregistrements sont automatiquement envoyes a tous les providers attaches :

    // dnsconfig.js
var REG_NONE = NewRegistrar("none");
var DSP_DNSCALE = NewDnsProvider("dnscale");
var DSP_HETZNER = NewDnsProvider("hetzner");
 
D("example.com", REG_NONE,
  DnsProvider(DSP_DNSCALE),
  DnsProvider(DSP_HETZNER),
 
  // Enregistrements A
  A("@", "203.0.113.10", TTL(3600)),
  A("mail", "203.0.113.20", TTL(3600)),
 
  // IPv6
  AAAA("@", "2001:db8::1", TTL(3600)),
 
  // CNAME
  CNAME("www", "example.com.", TTL(3600)),
 
  // Messagerie
  MX("@", 10, "mail.example.com.", TTL(3600)),
 
  // SPF
  TXT("@", "v=spf1 mx -all", TTL(3600)),
 
END);

    C'est tout. Les deux fournisseurs sont listes sur le meme domaine, et DNSControl gere le reste.

    Previsualiser et appliquer

    # Voir ce qui changerait chez les deux fournisseurs
dnscontrol preview
 
# Appliquer les changements aux deux fournisseurs
dnscontrol push

    La sortie de preview affiche les changements par fournisseur, vous permettant de verifier que DNScale et Hetzner recevront les bons enregistrements avant d'appliquer.

    Pour plus de details sur DNSControl avec DNScale, consultez le guide DNSControl.

    Maintenir les enregistrements synchronises

    Le plus grand risque avec le DNS multi-fournisseurs est la derive — les enregistrements qui se desynchronisent entre les fournisseurs. Votre outil IaC resout cela en etant la source unique de verite.

    L'IaC comme source de verite

    Ne modifiez jamais les enregistrements directement dans les tableaux de bord DNScale ou Hetzner. Tous les changements passent par votre configuration Terraform ou DNSControl. Cela garantit que les deux fournisseurs ont toujours des enregistrements identiques.

    Pipeline CI/CD

    Automatisez les deploiements pour que les enregistrements soient envoyes aux deux fournisseurs a chaque fusion dans main :

    # .github/workflows/dns.yml
name: DNS Deploy
on:
  push:
    branches: [main]
    paths: ["dns/**"]
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
 
      - name: Apply DNS changes
        working-directory: dns/
        env:
          TF_VAR_dnscale_api_key: ${{ secrets.DNSCALE_API_KEY }}
          TF_VAR_hetzner_dns_token: ${{ secrets.HETZNER_DNS_TOKEN }}
        run: |
          terraform init
          terraform apply -auto-approve

    Detection de derive

    Lancez des verifications periodiques pour detecter tout changement manuel ou incoherence d'API :

    # Terraform : detecter la derive
terraform plan -detailed-exitcode
# Code de sortie 2 signifie derive detectee
 
# DNSControl : preview montrera les differences
dnscontrol preview

    Planifiez cela en CI (par exemple un cron quotidien) et alertez en cas de differences inattendues.

    Delegation NS chez votre registraire

    Apres avoir deploye les enregistrements chez les deux fournisseurs, mettez a jour les enregistrements NS chez votre registraire de domaine pour inclure les serveurs de noms de DNScale et Hetzner.

    Un jeu NS typique ressemble a :

    ns1.dnscale.eu
ns2.dnscale.eu
hydrogen.ns.hetzner.com
oxygen.ns.hetzner.com
helium.ns.hetzner.de

    Les noms exacts des serveurs de noms DNScale dependent de votre compte. Verifiez les details de votre zone dans le tableau de bord DNScale pour les serveurs de noms attribues.

    Configurez tous ces serveurs comme enregistrements NS chez votre registraire. La plupart des registraires vous permettent d'ajouter autant de serveurs de noms que necessaire.

    Verifier la delegation

    Apres avoir mis a jour les enregistrements NS (prevoyez jusqu'a 48 heures pour la propagation), verifiez avec :

    dig NS example.com +short

    Vous devriez voir les serveurs de noms des deux fournisseurs dans la reponse. Vous pouvez egalement verifier que chaque fournisseur repond correctement :

    # Interroger DNScale directement
dig @ns1.dnscale.eu example.com A +short
 
# Interroger Hetzner directement
dig @hydrogen.ns.hetzner.com example.com A +short

    Les deux devraient renvoyer la meme adresse IP.

    Limitations et considerations

    DNSSEC

    Le DNSSEC multi-fournisseurs est complexe. Chaque fournisseur signe la zone avec ses propres cles, donc vous avez besoin soit :

    • Que les deux fournisseurs supportent le DNSSEC multi-signataire (RFC 8901) — pas encore largement supporte
    • Qu'un fournisseur soit le signataire et transfère les zones signees a l'autre
    • D'ignorer DNSSEC sur les zones multi-fournisseurs jusqu'a ce que le support multi-signataire s'ameliore

    Pour la plupart des configurations, ignorer DNSSEC sur les zones multi-fournisseurs est le choix pragmatique. Si DNSSEC est une exigence stricte, envisagez d'utiliser un seul fournisseur avec de fortes garanties de disponibilite. Consultez le guide DNSSEC pour la configuration DNSSEC mono-fournisseur.

    Alignement des TTL

    Gardez des TTL identiques chez les deux fournisseurs. Des TTL differents signifient que les resolveurs mettent en cache les enregistrements pendant des durees differentes selon le fournisseur interroge, entrainant un comportement incoherent.

    Delais de propagation

    Lorsque vous appliquez des changements, les deux fournisseurs les traitent independamment. Il y a une breve fenetre (generalement quelques secondes, parfois quelques minutes) ou un fournisseur a les nouveaux enregistrements et l'autre sert encore les anciens. Pour la plupart des cas d'utilisation c'est acceptable — evitez simplement de faire des changements qui casseraient s'ils etaient partiellement appliques.

    Types d'enregistrements specifiques aux fournisseurs

    Restez sur les types d'enregistrements standard que les deux fournisseurs supportent : A, AAAA, CNAME, MX, TXT, SRV, CAA, NS. Les extensions specifiques aux fournisseurs ou les types d'enregistrements proprietaires ne seront pas portables.

    Prochaines etapes