Gestion des domaines DNS chez SdV

Vue d'ensemble

SdV met à disposition des API sécurisées pour gérer de manière autonome la configuration DNS de vos domaines. Cette approche permet une intégration native dans vos workflows DevOps et vos pipelines CI/CD.

Deux modes de gestion coexistent :

• Mode traditionnel : demandes via l'outil de requêtes avec accompagnement de l'équipe Système
• Mode autonome : utilisation des API SdV pour une gestion programmatique des enregistrements DNS

L'utilisation des API nécessite l'obtention de clés d'API. Contactez l'équipe Système pour en faire la demande.

Cas d'usage

Certificats SSL et challenge DNS

Lors de la génération de certificats SSL via Let's Encrypt ou tout autre CA supportant le protocole ACME, le challenge DNS est l'un des modes de validation de propriété du domaine.

Principe du challenge DNS

Le CA génère un token unique et demande la création d'un enregistrement DNS de type TXT sur un sous-domaine spécifique :

_acme-challenge.example.com. 300 IN TXT "token_generated_by_ca"

Une fois l'enregistrement détecté, le CA valide la propriété du domaine et émet le certificat.

Avantages du challenge DNS

• Permet la génération de certificats wildcard (*.example.com)
• Fonctionne sans exposition HTTP publique (pas besoin d'ouvrir le port 80)
• Idéal pour les environnements internes ou les serveurs sans accès Internet direct

Intégration avec CertBot

SdV fournit un plugin CertBot compatible avec l'API de challenge DNS :

Repository : certbot_challenge_dns_sdv

certbot certonly \
  --authenticator dns-sdv \
  --dns-sdv-credentials ~/.secrets/certbot/sdv.ini \
  --dns-sdv-propagation-seconds 60 \
  -d example.com \
  -d *.example.com

Fichier de credentials ~/.secrets/certbot/sdv.ini :

dns_sdv_api_url = https://api-challenge-dns.sdv.fr
dns_sdv_api_key = your_api_key_here

Consultez le guide détaillé Let's Encrypt pour un workflow complet.

Infrastructure as Code (IaC)

La gestion DNS s'inscrit naturellement dans une approche Infrastructure as Code. SdV supporte deux outils majeurs :

• Terraform : via le provider PowerDNS
• Ansible : via les modules de gestion DNS (documentation en cours)

Exemple Terraform

terraform {
  required_providers {
    powerdns = {
      source  = "pan-net/powerdns"
      version = "~> 1.5.0"
    }
  }
}
 
provider "powerdns" {
  api_key    = var.powerdns_api_key
  server_url = "https://powerdns-endpoint-dns.sdv.fr"
}

resource "powerdns_record" "app_web" {
  zone    = "example.com."
  name    = "app.example.com."
  type    = "A"
  ttl     = 300
  records = ["192.0.2.10"]
}
 
resource "powerdns_record" "app_cname" {
  zone    = "example.com."
  name    = "www.example.com."
  type    = "CNAME"
  ttl     = 3600
  records = ["app.example.com."]
}

Référez-vous au guide Terraform pour des exemples avancés et des patterns de modules.

Édition directe de fichier de zone

Pour une gestion ponctuelle ou exploratoire, SdV permet l'usage d'une interface Web via PowerDNS Admin.

Cas d'usage recommandés :

• Modifications mineures ponctuelles
• Consultation de l'état actuel des zones
• Dépannage rapide
• Environnements de développement ou test

Limitations :

• Non adapté à la gestion à grande échelle
• Pas de traçabilité Git
• Risque d'erreurs manuelles

Consultez le guide PowerDNS Admin pour la configuration et l'utilisation.

Architecture des API SdV

SdV expose deux API distinctes selon les cas d'usage :

API Challenge DNS

Caractéristiques :

• Restriction fonctionnelle : création/suppression d'enregistrements TXT pour validation ACME uniquement
• Sécurité renforcée : scope limité pour minimiser les risques en cas de compromission
• Intégration native : plugin CertBot, cert-manager Kubernetes

Pour Kubernetes, référez-vous à la documentation cert-manager de la Kubernetes FAQ.

Exemple de création d'enregistrement TXT avec curl

curl -X POST https://api-challenge-dns.sdv.fr/v1/challenge \
  -H "X-API-Key: your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "domain": "_acme-challenge.example.com",
    "value": "validation_token_here"
  }'

Réponse attendue (201 Created) :

{
  "status": "created",
  "domain": "_acme-challenge.example.com",
  "value": "validation_token_here",
  "ttl": 60
}

API PowerDNS

Caractéristiques :

• Fonctionnalités complètes : gestion de tous types d'enregistrements (A, AAAA, CNAME, MX, TXT, SRV, NS, etc.)
• Compatibilité : respecte le standard API PowerDNS, compatible avec l'écosystème Open Source
• Documentation : PowerDNS HTTP API

Exemple de récupération de zone :

curl -X GET https://powerdns-endpoint-dns.sdv.fr/api/v1/servers/localhost/zones/example.com. \
  -H "X-API-Key: your_api_key_here"

Réponse attendue (200 OK) :

{
  "id": "example.com.",
  "name": "example.com.",
  "type": "Zone",
  "kind": "Native",
  "serial": 2026022601,
  "notified_serial": 2026022601,
  "rrsets": [
    {
      "name": "example.com.",
      "type": "A",
      "ttl": 3600,
      "records": [
        {"content": "192.0.2.1", "disabled": false}
      ]
    }
  ]
}

Gestion des clés d'API

Codes de retour API

Les API SdV suivent les conventions HTTP standard :

Principes de sécurité

Une clé d'API SdV repose sur trois piliers de sécurité :

1. Périmètre de domaines : chaque clé donne accès à un ensemble défini de domaines
2. Filtrage par IP source : seules les adresses IP autorisées peuvent utiliser la clé
3. Révocabilité : possibilité de révoquer une clé compromise sans impact sur les autres

Demande de clé d'API

Procédure :

1. Ouvrir un ticket via l'outil de requêtes SdV
2. Préciser les informations suivantes :
   • Liste exhaustive des domaines concernés
   • Adresses IP sources autorisées (IP publiques fixes)
   • Cas d'usage prévu (CertBot, Terraform, autre)
   • Environnement cible (production, preprod, dev)

Délai de traitement : sous 48h ouvrées

Stockage sécurisé

Bonnes pratiques de stockage :

À éviter absolument :

• Commit de clés dans Git (même en repo privé)
• Stockage en clair dans des fichiers de configuration
• Partage par email ou messagerie instantanée
• Logs applicatifs contenant la clé en clair

Stratégie de découpage des clés

Appliquez le principe du moindre privilège : chaque clé doit avoir le scope minimal nécessaire.

Comparaison des approches

Exemples concrets

# Séparation par domaine et environnement
cle_boutique_prod:
  domaines: [shop.example.com, www.shop.example.com]
  environnement: production
  usage: Terraform production
 
cle_boutique_staging:
  domaines: [shop-staging.example.com]
  environnement: staging
  usage: Terraform staging
 
cle_boutique_acme:
  domaines: [shop.example.com, *.shop.example.com]
  api: Challenge DNS uniquement
  usage: Certificats Let's Encrypt

Avantages du découpage

Types d'enregistrements supportés

L'API PowerDNS supporte l'ensemble des types d'enregistrements DNS standards :

Recommandations TTL

Le TTL (Time To Live) représente la durée de mise en cache de l'enregistrement par les résolveurs DNS.

Validation et vérification

Après modification DNS, il est impératif de valider la propagation des changements.

Commandes de diagnostic

dig (recommandé pour diagnostic avancé)

# Interrogation simple
dig example.com A
 
# Interrogation d'un serveur DNS spécifique
dig @8.8.8.8 example.com A
 
# Trace complète de résolution
dig +trace example.com
 
# Affichage court (uniquement la réponse)
dig +short example.com A
 
# Vérification TTL
dig example.com A | grep -E "^example.com"
 
# Enregistrements multiples
dig example.com ANY

nslookup (disponible partout, moins verbeux)

# Interrogation simple
nslookup example.com
 
# Serveur DNS spécifique
nslookup example.com 8.8.8.8
 
# Type d'enregistrement spécifique
nslookup -type=MX example.com

host (output minimaliste)

# Résolution simple
host example.com
 
# Type spécifique
host -t AAAA example.com

Vérification de propagation

Les modifications DNS ne sont pas instantanées. Le délai de propagation dépend :

• Du TTL de l'ancien enregistrement
• Du cache des résolveurs intermédiaires
• De la configuration des serveurs DNS autoritatifs

Checklist post-modification

1. Vérifier sur les serveurs DNS SdV autoritatifs
2. Vérifier sur un résolveur public (Google 8.8.8.8, Cloudflare 1.1.1.1)
3. Vérifier depuis l'application cliente
4. Attendre au minimum 2× le TTL avant validation complète

Exemple de script de vérification

#!/bin/bash
set -euo pipefail
 
# Configuration
DOMAIN="${1:-example.com}"
EXPECTED_IP="${2:-192.0.2.10}"
DNS_SERVERS=("8.8.8.8" "1.1.1.1" "208.67.222.222")
 
if [ $# -eq 0 ]; then
  echo "Usage: $0 DOMAIN EXPECTED_IP"
  echo "Exemple: $0 example.com 192.0.2.10"
  exit 1
fi
 
echo "Vérification DNS pour $DOMAIN (IP attendue: $EXPECTED_IP)"
echo "-----------------------------------------------------------"
 
for dns in "${DNS_SERVERS[@]}"; do
  result=$(timeout 5 dig @"$dns" +short "$DOMAIN" A | head -n1 || echo "TIMEOUT")
  if [ "$result" = "$EXPECTED_IP" ]; then
    echo "✓ $dns : OK ($result)"
  else
    echo "✗ $dns : KO (got '$result', expected '$EXPECTED_IP')"
  fi
done

Bonnes pratiques

Gestion des zones

• Versionner vos configurations Terraform dans Git avec revue de code systématique
• Tester les modifications en preprod avant application en production
• Documenter les enregistrements critiques : raison d'être, date de création, équipe responsable
• Utiliser des modules Terraform pour standardiser la création d'enregistrements récurrents

Sécurité

• Rotation des clés API : au minimum annuelle, immédiatement en cas de suspicion de compromission
• Audit des accès : consulter régulièrement les logs d'utilisation des API
• Principe du moindre privilège : une clé par contexte/application
• Filtrage IP strict : autoriser uniquement les IP nécessaires (NAT gateway, runners CI/CD)

Opérations

• Planifier les changements DNS critiques : horaires de faible trafic, communication préalable
• Abaisser le TTL 24-48h avant un changement d'infrastructure majeur
• Conserver un rollback plan : garder les anciennes valeurs documentées
• Monitorer la résolution DNS : alertes sur échec de résolution depuis différents points du réseau

CI/CD

• Terraform plan automatique sur les Merge Requests pour visibilité des changements
• Validation des zones : terraform validate, tflint pour détection d'erreurs de syntaxe
• Approbation manuelle pour les modifications production
• Notification post-déploiement : Slack, email, ticketing

Points d'attention

Impacts opérationnels

• Modification d'un enregistrement A/AAAA : peut causer une coupure temporaire (durée = TTL + cache applicatif)
• Suppression d'enregistrement : vérifier l'absence de dépendances (CNAME pointant vers la cible, certificats SSL)
• Modification de MX : risque de perte d'emails pendant la transition (utiliser des priorités progressives)
• Changement de NS : opération critique, propagation globale de 24-72h

Erreurs fréquentes

• FQDN mal formé : toujours terminer par un point (example.com. et non example.com)
• CNAME sur le domaine apex : interdit par la RFC (utiliser ALIAS ou A/AAAA)
• TTL trop élevé : complique les modifications d'urgence
• TTL trop faible : charge excessive sur les serveurs DNS
• Enregistrements orphelins : nettoyer régulièrement les enregistrements obsolètes

Dépendances applicatives

• Certificats SSL : penser à renouveler après changement de domaine/CNAME
• CDN : reconfiguration nécessaire en cas de changement de CNAME
• Load Balancers : vérifier la cohérence DNS/configuration LB
• Services tiers (SendGrid, Mailchimp, etc.) : nécessitent parfois des enregistrements DNS spécifiques

Notes d'exploitation

Démarrage d'un nouveau projet

1. Demander la création d'une clé API dédiée (ticket SdV)
2. Stocker la clé de manière sécurisée (vault d'équipe)
3. Initialiser le repository Terraform avec backend distant
4. Créer les enregistrements DNS de base (A, AAAA, MX si applicable)
5. Configurer les enregistrements de validation (SPF, DKIM, DMARC pour les emails)
6. Mettre en place le monitoring DNS (uptimerobot, pingdom, ou équivalent)

Incident DNS : procédure de remédiation

1. Identification : utiliser dig, nslookup pour diagnostiquer
2. Rollback d'urgence :
   • Via Terraform : git revert + terraform apply
   • Via API directe : restauration manuelle des valeurs précédentes
   • Via GUI PowerDNS Admin pour un fix immédiat
3. Communication : informer les équipes impactées du statut et ETA
4. Post-mortem : documenter la cause racine et les actions correctives

Changement d'infrastructure majeur

Exemple : migration d'un service vers un nouveau datacenter.

Préparation (J-2 ou J-7)

# Abaisser le TTL des enregistrements concernés
terraform apply -var="app_dns_ttl=60"

Bascule (J-Day)

# Mise à jour des enregistrements avec nouvelle IP
terraform apply -var="app_ip=new_datacenter_ip"

Post-bascule (J+1)

# Rétablir un TTL standard
terraform apply -var="app_dns_ttl=3600"

Contacts et escalade

• Support SdV : https://requete.sdv.fr/
• Documentation API PowerDNS : https://doc.powerdns.com/authoritative/http-api/

En cas d'incident DNS critique impactant la production, privilégier le contact direct (téléphone/escalade) plutôt que le ticket.