Aller au contenu
> 💻 🧠 Code 1001 > 📑 Fiches Mémo > 🖧 Guide complet et exhaustif sur les enregistrements DNS : des bases à DNSSEC et l’automatisation

🖧 Guide complet et exhaustif sur les enregistrements DNS : des bases à DNSSEC et l’automatisation

Le DNS (Domain Name System) est le système fondamental sur lequel repose tout l’internet moderne. Ce n’est pas simplement un « annuaire téléphonique », mais une base de données complexe et distribuée qui traduit les noms lisibles par les humains (par exemple, google.com) en identifiants techniques tels que des adresses IP, des serveurs de messagerie, des politiques de sécurité et même des coordonnées géographiques. Une configuration DNS incorrecte est l’une des causes les plus fréquentes d’indisponibilité des sites web, de problèmes de livraison de courrier et de vulnérabilités de sécurité.

Ce guide combine tous les aspects du DNS : des enregistrements de base utilisés quotidiennement aux mécanismes complexes comme DNSSEC et DANE. Nous examinerons chaque type d’enregistrement, son objectif, sa syntaxe, des exemples pratiques, les erreurs courantes, les commandes de diagnostic et des modèles prêts à l’emploi pour le déploiement. Les informations sont structurées pour que vous puissiez utiliser ce matériel comme manuel, référence d’administrateur et liste de vérification pour les environnements de production.

In Questo Articolo
  1. 1. Terminologie
  2. 2. Analyse détaillée de tous les types d’enregistrements
  3. 3. Recommandations pratiques et nuances de configuration
  4. 4. Modèles complets de fichiers de zone (style BIND)
  5. 5. Configuration étape par étape du domaine de messagerie (PTR, SPF, DKIM, DMARC)
  6. 6. Commandes pour la vérification et le débogage DNS
  7. 7. Sécurité et meilleures pratiques
  8. 8. Erreurs courantes et comment les éviter
  9. 9. Liste de vérification avant la mise en production ou la migration
  10. 10. Exemples supplémentaires et explications des champs
  11. 11. Scénarios utiles
  12. 12. JSON prêt à l’emploi pour l’importation dans le panneau du fournisseur

1. Terminologie

Avant de plonger dans les types d’enregistrements, il est crucial de comprendre les termes clés utilisés dans le DNS. Cela établit une base linguistique commune et aide à éviter toute confusion.

  • DNS (Domain Name System) : Le Système de Noms de Domaine. Une base de données distribuée globale qui traduit les noms de domaine en adresses IP et autres informations liées.
  • Nom de domaine (Domain Name) : Une adresse lisible par l’homme sur internet, par exemple, example.com. Se compose d’étiquettes séparées par des points.
  • FQDN (Fully Qualified Domain Name) : Un nom de domaine complet qui identifie de manière unique un nœud dans la hiérarchie DNS. Se termine toujours par un point désignant la racine DNS (par exemple, www.example.com.).
  • Zone : Une unité administrative dans le DNS. Une partie de l’espace de noms gérée par un serveur autoritaire (ou un groupe de serveurs). Correspond généralement à un domaine ou sous-domaine.
  • Fichier de zone (Zone File) : Un fichier texte stocké sur un serveur DNS qui contient tous les enregistrements pour une zone spécifique. Utilise la syntaxe définie par la norme BIND.
  • Enregistrement (Resource Record, RR) : L’unité de base de données dans le DNS. Chaque enregistrement a un type, un nom, une valeur et un TTL.
  • Type d’enregistrement (Record Type) : Définit quelles informations l’enregistrement contient (par exemple, A, MX, TXT). Chaque type correspond à un code numérique unique (par exemple, 1 pour A, 15 pour MX).
  • TTL (Time To Live) : La durée de vie de l’enregistrement, spécifiée en secondes. Détermine combien de temps les résolveurs et autres serveurs DNS peuvent mettre en cache l’enregistrement avant de le demander à nouveau au serveur autoritaire.
  • Résolveur (Resolver) : Un client ou serveur DNS qui reçoit une requête d’une application (par exemple, un navigateur) et effectue les requêtes nécessaires pour obtenir une réponse. Peut être récursif (effectue la chaîne complète de requêtes) ou non récursif.
  • Serveur autoritaire (Authoritative Server) : Un serveur DNS qui stocke les enregistrements originaux pour une zone spécifique et en est responsable. Répond aux requêtes en utilisant les données du fichier de zone.
  • Serveur récursif (Recursive Server) : Un serveur qui reçoit une requête d’un client et, s’il n’a pas la réponse dans son cache, effectue une chaîne de requêtes, en commençant par les serveurs racine, pour trouver le serveur autoritaire et obtenir la réponse.
  • Serveur racine (Root Server) : L’un des 13 groupes de serveurs (désignés par les lettres de a.root-servers.net. à m.root-servers.net.) qui sont le point de départ pour résoudre tout nom de domaine. Ils savent où se trouvent les serveurs pour les domaines de niveau supérieur (TLD).
  • TLD (Top-Level Domain) : Un domaine de niveau supérieur. La dernière partie d’un nom de domaine (par exemple, .com, .org, .ru, .io).
  • Registre (Registrar) : L’entreprise par laquelle les noms de domaine sont enregistrés. Gère les informations de délégation (quels serveurs NS desservent le domaine) dans la zone parente (par exemple, dans la zone .com pour le domaine example.com).
  • Titulaire (Registrant) : Le propriétaire du nom de domaine.
  • Délégation (Delegation) : Le processus de transfert du contrôle d’un sous-domaine (ou domaine) de la zone parente à l’enfant. Réalisé à l’aide d’enregistrements NS dans la zone parente.
  • Enregistrement Glue (Glue Record) : Un enregistrement A ou AAAA publié par le registre pour un serveur de noms dont le nom de domaine est à l’intérieur de la zone déléguée. Nécessaire pour rompre une dépendance circulaire.
  • SOA (Start of Authority) : Un enregistrement contenant des informations administratives sur la zone, y compris le serveur primaire, le contact de l’administrateur et les paramètres contrôlant le transfert de zone vers les serveurs secondaires.
  • Numéro de série (Serial Number) : Un champ dans l’enregistrement SOA qui indique la version de la zone. Les serveurs secondaires l’utilisent pour déterminer si une mise à jour est nécessaire.
  • Résolution directe (Forward Resolution) : Le processus de conversion d’un nom de domaine en une adresse IP (par exemple, example.com → 192.0.2.1).
  • Résolution inverse (Reverse Resolution) : Le processus de conversion d’une adresse IP en un nom de domaine (par exemple, 192.0.2.1 → example.com). Géré via les zones in-addr.arpa (pour IPv4) et ip6.arpa (pour IPv6).
  • Cache : Un stockage temporaire pour les enregistrements DNS sur un résolveur ou un serveur DNS pour accélérer les requêtes suivantes.
  • Mise en cache (Caching) : Le processus d’enregistrement des enregistrements DNS dans un cache.
  • Mise en cache négative (Negative Caching) : Mise en cache d’informations indiquant que l’enregistrement demandé n’existe pas.
  • RFC (Request for Comments) : Un document officiel décrivant les normes, protocoles et procédures sur internet. Tous les aspects majeurs du DNS sont décrits dans une série de RFC.
  • BIND (Berkeley Internet Name Domain) : L’implémentation la plus courante d’un serveur DNS. La syntaxe de ses fichiers de zone est devenue la norme de facto.
  • MTA (Mail Transfer Agent) : Un serveur de messagerie responsable du transfert des e-mails (par exemple, Postfix, Exim, Sendmail).
  • FCrDNS (Forward-Confirmed Reverse DNS) : Un mécanisme de vérification où une adresse IP a un enregistrement PTR qui se résout en un nom de domaine, et ce nom de domaine, à son tour, a un enregistrement A pointant vers l’adresse IP d’origine. Critique pour la réputation du serveur de messagerie.
  • DNSSEC (Domain Name System Security Extensions) : Un ensemble d’extensions ajoutant des signatures cryptographiques aux enregistrements DNS pour garantir leur authenticité et leur intégrité.
  • DANE (DNS-based Authentication of Named Entities) : Une norme permettant de lier les certificats TLS aux noms DNS à l’aide d’enregistrements TLSA. Nécessite que DNSSEC soit activé.
  • CAA (Certification Authority Authorization) : Un mécanisme permettant au propriétaire d’un domaine de spécifier quelles autorités de certification (CA) sont autorisées à émettre des certificats pour lui.
  • SPF (Sender Policy Framework) : Un mécanisme permettant au propriétaire d’un domaine de spécifier quels serveurs sont autorisés à envoyer des courriers en son nom.
  • DKIM (DomainKeys Identified Mail) : Un mécanisme permettant de signer numériquement les e-mails sortants, signature que le destinataire peut vérifier à l’aide d’une clé publique publiée dans le DNS.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance) : Une politique définissant comment les serveurs de messagerie doivent gérer les e-mails qui échouent aux vérifications SPF ou DKIM et configurant l’envoi de rapports au propriétaire du domaine.
  • ALIAS / ANAME : Types d’enregistrements non standard offerts par certains fournisseurs de DNS. Permettent de créer des alias pour le domaine racine (apex), ce qui est impossible avec un CNAME standard.
  • CNAME Flattening : Une technologie utilisée par certains fournisseurs de DNS. Lorsqu’un CNAME est interrogé pour un domaine apex, le serveur résout automatiquement la chaîne CNAME et renvoie les enregistrements A/AAAA finaux au client, évitant ainsi la violation de la RFC.

2. Analyse détaillée de tous les types d’enregistrements

Tous les exemples sont fournis au format de fichier de zone style BIND. Les noms se terminant par un point (par exemple, example.com.) sont des FQDN. Le TTL (Time To Live) est spécifié en secondes et détermine combien de temps l’enregistrement peut être mis en cache par les résolveurs.

A — Enregistrement d’adresse (IPv4)

  • Objectif : Lie un nom de domaine à une adresse IPv4 de 32 bits. L’enregistrement le plus basique et le plus fréquemment utilisé.
  • Format : nom TTL IN A adresse-IPv4
  • Exemple :
    example.com. 3600 IN A 192.0.2.1 www.example.com. 3600 IN A 192.0.2.1
  • Quand utilisé : Pour spécifier l’adresse IP d’un serveur web, d’une API, d’un serveur de jeu ou de tout autre service accessible via IPv4.
  • Vérification : dig +short example.com A
  • Meilleures pratiques :
    • L’utilisation d’un enregistrement A pour le domaine racine (apex, @) est une pratique standard et correcte.
    • Choisissez le TTL en fonction de la stabilité de l’adresse IP. Pour les adresses stables — 3600 (1 heure) ou 86400 (1 jour). Avant une migration — réduisez à 300 (5 minutes).

AAAA — Enregistrement d’adresse IPv6

  • Objectif : Analogue à l’enregistrement A, mais pour les adresses IPv6 de 128 bits. Critiquement important pour l’avenir d’internet.
  • Format : nom TTL IN AAAA adresse-IPv6
  • Exemple :
    example.com. 3600 IN AAAA 2001:db8::1
  • Quand utilisé : Pour garantir la disponibilité du service via le protocole IPv6.
  • Vérification : dig +short example.com AAAA

CNAME — Enregistrement de nom canonique

  • Objectif : Crée un alias pour un nom de domaine. Toute requête vers un CNAME est automatiquement convertie en une requête vers son nom cible (canonique).
  • Format : nom TTL IN CNAME cible.
  • Exemple :
    www.example.com. 3600 IN CNAME example.com. blog.example.com. 3600 IN CNAME blog-hosting.example.net.
  • Restrictions importantes :
    • Conflit d’enregistrements : Vous ne pouvez pas avoir un CNAME et tout autre enregistrement (A, MX, TXT, etc.) pour le même nom. C’est une violation de la RFC.
    • Domaine Apex : La norme RFC interdit l’utilisation de CNAME pour le domaine racine (par exemple, example.com.) car il contient déjà des enregistrements NS et SOA. Pour résoudre cela, les fournisseurs de DNS (Cloudflare, AWS Route 53) offrent des extensions non standard : ALIAS ou ANAME, qui résolvent l’alias en enregistrements A/AAAA à la volée.
  • Application pratique : Connexion à un CDN (faire de www un CNAME vers l’adresse du CDN), utilisation de plates-formes SaaS (blog, boutique).
  • Vérification : dig +short www.example.com CNAME

MX — Enregistrement d’échange de courrier

  • Objectif : Spécifie les serveurs qui acceptent le courrier entrant pour le domaine. L’enregistrement contient une priorité : plus le nombre est petit, plus la priorité est élevée.
  • Format : nom TTL IN MX priorité serveur_de_courrier.
  • Exemple :example.com. 3600 IN MX 10 mail1.example.com. example.com. 3600 IN MX 20 mail2.example.com.
    • Le courrier sera d’abord envoyé à mail1.example.com.. S’il est indisponible, le MTA (Agent de Transfert de Courrier) essaiera mail2.example.com..
  • Exigences clés :
    • Le serveur de messagerie (mail1.example.com.) doit avoir son propre enregistrement A ou AAAA.
    • Un enregistrement PTR doit être configuré pour l’adresse IP du serveur de messagerie, et il doit correspondre au nom du serveur spécifié dans le MX. C’est critique pour la réputation du serveur et la livraison du courrier.
  • Vérification : dig +short example.com MX

TXT — Enregistrement de texte

  • Objectif : Stocke des données textuelles arbitraires. Largement utilisé pour les politiques de sécurité du courrier électronique (SPF, DKIM, DMARC), la vérification de la propriété du domaine (Google, Microsoft, Yandex) et d’autres fins.
  • Format : nom TTL IN TXT "texte"
  • Exemples :
    • SPF (Sender Policy Framework) : Définit quels serveurs sont autorisés à envoyer du courrier au nom du domaine. example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all"
      • ip4:192.0.2.0/24 — autorise tout le sous-réseau.
      • include:_spf.google.com — inclut les règles de la zone Google (pour Gmail).
      • ~all — « échec doux » pour tous les autres (softfail). -all — échec strict (fail).
    • DKIM (DomainKeys Identified Mail) : Publie la clé publique pour vérifier la signature numérique ajoutée aux e-mails sortants. Généralement créé pour un sous-domaine comme sélecteur._domainkey.domaine. default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
      • v=DKIM1 — version.
      • k=rsa — type de clé.
      • p=... — la clé publique elle-même au format base64.
    • DMARC (Domain-based Message Authentication, Reporting & Conformance) : Définit la politique de gestion des e-mails qui échouent aux vérifications SPF ou DKIM et configure l’envoi de rapports. _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
      • p=reject — rejeter les e-mails qui échouent à la vérification.
      • rua=mailto:... — adresse pour les rapports agrégés.
      • ruf=mailto:... — adresse pour les rapports médico-légaux (échecs spécifiques).
      • pct=100 — appliquer la politique à 100% des e-mails.
    • Vérification : example.com. 3600 IN TXT "google-site-verification=abc123..."
  • Remarques :
    • Si une chaîne de texte dépasse 255 octets, elle peut être divisée en plusieurs parties dans le fichier de zone, chaque partie étant encadrée de guillemets. Le serveur DNS les concaténera automatiquement.
      example.com. IN TXT ("v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; " "pct=100; fo=1")
  • Vérification : dig +short example.com TXT

NS — Enregistrement de serveur de noms

  • Objectif : Spécifie les serveurs DNS qui sont autoritaires pour la zone. Ces enregistrements sont la base de la délégation de la gestion du domaine.
  • Format : nom TTL IN NS nom_du_serveur.
  • Exemple :
    example.com. 3600 IN NS ns1.example.net. example.com. 3600 IN NS ns2.example.net.
  • Points importants :
    • Les enregistrements NS dans la zone doivent correspondre exactement aux serveurs de noms spécifiés auprès du registre de domaine.
    • Enregistrements Glue : Si le serveur de noms (par exemple, ns1.example.com.) se trouve à l’intérieur de la même zone qu’il dessert (example.com.), une dépendance circulaire se produit. Pour la rompre, ajoutez des enregistrements « glue » — des enregistrements A ou AAAA pour ces serveurs de noms — auprès du registre.
  • Vérification : dig +short example.com NS

SOA — Enregistrement de début d’autorité

  • Objectif : L’enregistrement administratif principal d’une zone DNS. Contient des informations sur le serveur primaire, l’administrateur et les paramètres contrôlant la synchronisation entre le serveur primaire et les serveurs secondaires.
  • Format :
    nom TTL IN SOA serveur_primaire. email_administrateur. ( numéro_de_série ; Serial intervalle_de_réactualisation ; Refresh intervalle_de_réessai ; Retry délai_d'expiration ; Expire ttl_minimum ) ; Minimum TTL
  • Exemple :
    example.com. 3600 IN SOA ns1.example.net. admin.example.com. ( 2025092201 ; Serial (YYYYMMDDNN) 7200 ; Refresh (2 heures) 3600 ; Retry (1 heure) 1209600 ; Expire (14 jours) 86400 ) ; Minimum TTL (1 jour)
  • Explications des champs :
    • Serial : Version de la zone. Il est extrêmement important d’incrémenter ce nombre à chaque modification de la zone. Les serveurs secondaires comparent leur Serial avec le Serial sur le serveur primaire et, s’il est plus petit, demandent une mise à jour. Format recommandé : YYYYMMDDNN (année, mois, jour, numéro de révision du jour).
    • Refresh : Intervalle (en secondes) après lequel les serveurs secondaires doivent vérifier le serveur primaire pour les mises à jour.
    • Retry : Intervalle après lequel un serveur secondaire doit réessayer si la première tentative de mise à jour échoue.
    • Expire : Temps (en secondes) après lequel un serveur secondaire cessera de répondre aux requêtes s’il ne peut pas contacter le serveur primaire. La zone est considérée comme « expirée ».
    • Minimum TTL : Initialement fixait le TTL minimum pour tous les enregistrements de la zone. Maintenant souvent utilisé comme TTL pour la mise en cache négative (combien de temps mettre en cache une réponse « enregistrement non trouvé »).
  • Vérification : dig +short example.com SOA

PTR — Enregistrement de pointeur (DNS inverse)

  • Objectif : Fournit une résolution inverse — convertit une adresse IP en un nom de domaine. Géré par le propriétaire de l’adresse IP (FAI, hébergeur), et non par le propriétaire du domaine.
  • Format pour IPv4 : L’adresse IP est écrite à l’envers, et le suffixe .in-addr.arpa. est ajouté.
    • IP 192.0.2.5 → 5.2.0.192.in-addr.arpa.
  • Format pour IPv6 : Chaque partie de 4 bits (nibble) de l’adresse est écrite à l’envers, et le suffixe .ip6.arpa. est ajouté.
    • IPv6 2001:db8::1 → 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
  • Exemple (IPv4) :
    5.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.
  • Signification pratique : Critiquement important pour les serveurs de messagerie. La plupart des systèmes de messagerie vérifient que l’enregistrement PTR pour l’adresse IP de l’expéditeur correspond au nom que le serveur présente dans la commande HELO/EHLO. Une incohérence est une raison fréquente pour que les e-mails soient marqués comme spam.
  • Vérification : dig -x 192.0.2.5 +short ou host 192.0.2.5

SRV — Enregistrement de service

  • Objectif : Spécifie l’emplacement des serveurs pour des services spécifiques, y compris le protocole et le port. Permet aux clients de trouver automatiquement le serveur nécessaire.
  • Format de nom :_service._protocole.nom.
    • Service : sip, xmpp-server, _minecraft, etc.
    • Protocole : tcp, udp.
  • Format d’enregistrement : nom TTL IN SRV priorité poids port cible.
  • Exemple :
    _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com. _minecraft._tcp.example.com. 3600 IN SRV 5 0 25565 mc1.example.com.
  • Explications des champs :
    • Priority (Priorité) : Plus le nombre est petit, plus la priorité est élevée. Le client essaiera d’abord de se connecter au serveur avec la priorité la plus basse.
    • Weight (Poids) : Utilisé pour l’équilibrage de charge entre les serveurs ayant la même priorité. La probabilité de sélectionner un serveur est proportionnelle à son poids. Si tous les poids sont égaux, la sélection est aléatoire.
    • Port (Port) : Le port sur lequel le service s’exécute.
    • Target (Cible) : Le FQDN du serveur vers lequel la requête doit être dirigée. Ce serveur doit avoir un enregistrement A ou AAAA.
  • Application : VoIP (SIP), messagerie instantanée (XMPP), jeux (Minecraft), annuaires (LDAP).
  • Vérification : dig +short _sip._tcp.example.com SRV

CAA — Autorisation d’autorité de certification

  • Objectif : Permet au propriétaire du domaine de spécifier quelles autorités de certification (CA) sont autorisées à émettre des certificats SSL/TLS pour ce domaine. C’est un mécanisme de sécurité important pour empêcher l’émission non autorisée de certificats.
  • Format : nom TTL IN CAA drapeaux étiquette valeur
  • Exemple :
    example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
  • Explications :
    • Flags : Généralement 0. Le drapeau 128 (critique) signifie qu’une CA qui ne comprend pas cette étiquette doit refuser d’émettre le certificat.
    • Tags :
      • issue : Permet à la CA spécifiée d’émettre des certificats. Une valeur vide (;) interdit l’émission par quiconque.
      • issuewild : Permet l’émission de certificats wildcard (*.example.com).
      • iodef : URL (généralement mailto: ou http(s):) pour envoyer des rapports sur les tentatives de violation de la politique CAA.
  • Vérification : dig +short example.com CAA

NAPTR — Enregistrement de pointeur d’autorité de nom

  • Objectif : Utilisé pour des règles complexes de réécriture de noms et d’URI. Le plus souvent appliqué dans les systèmes de télécommunications (ENUM pour convertir les numéros de téléphone en URI SIP) et pour la découverte de services dynamique.
  • Format : nom TTL IN NAPTR ordre préférence drapeaux service expression_régulière remplacement.
  • Exemple (simplifié pour ENUM) :
    4.3.2.1.5.5.5.1.e164.arpa. IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:info@example.com!" .
  • Explications :
    • Order (Ordre) : Traité du plus petit au plus grand.
    • Preference (Préférence) : Analogue au weight dans SRV pour les enregistrements ayant le même order.
    • Flags : U signifie que le résultat est un URI (par exemple, sip:).
    • Service : Type de service (par exemple, E2U+sip — conversion en URI SIP).
    • Regexp : Expression régulière pour transformer la chaîne d’entrée.
    • Replacement : Alternative à l’expression régulière (généralement vide si regexp est utilisé).
  • Application : Scénarios de routage complexes en VoIP, ENUM.

TLSA — Enregistrement d’association de certificat TLSA (DANE)

  • Objectif : Lie un certificat TLS (ou une partie de celui-ci) à un nom DNS à l’aide d’un enregistrement DNS. C’est une partie de la norme DANE (Authentification Basée sur DNS des Entités Nommées). Nécessite que DNSSEC soit activé pour garantir la confiance ; sinon, l’enregistrement peut être falsifié.
  • Format de nom : _port._protocole.nom.
  • Format d’enregistrement : nom TTL IN TLSA utilisation sélecteur type_de_correspondance données
  • Exemple :
    _443._tcp.www.example.com. 3600 IN TLSA 3 1 1 d2abde...f21
  • Explications des champs :
    • Usage (Utilisation) :
      • 3 (DANE-EE) : Certificat d’entité finale. Le plus courant.
      • 1 (PKIX-EE) : Certificat d’entité finale, doit être signé par une CA de confiance.
      • 2 (DANE-TA) : Certificat d’autorité de certification de confiance.
      • 0 (PKIX-TA) : Certificat de CA, doit être dans la chaîne de confiance.
    • Selector (Sélecteur) :
      • 0 : Certificat complet.
      • 1 : Seulement la clé publique du certificat.
    • Matching Type (Type de correspondance) :
      • 0 : Données exactes (non utilisé).
      • 1 : Hachage SHA-256.
      • 2 : Hachage SHA-512.
    • Data : Hachage du certificat ou de sa clé publique au format hex.
  • Application : Amélioration de la sécurité TLS, en particulier dans les environnements où les CA publiques ne peuvent pas être considérées comme fiables.
  • Vérification : dig +short _443._tcp.www.example.com. TLSA

Enregistrements DNSSEC (DNSKEY, DS, RRSIG, NSEC, NSEC3)

DNSSEC (Extensions de Sécurité du Système de Noms de Domaine) est un ensemble d’extensions qui ajoutent des signatures cryptographiques aux enregistrements DNS pour se protéger contre la falsification (usurpation) et les attaques d’empoisonnement de cache.

  • Principe général : La zone est signée avec une clé privée. La clé publique est publiée dans un enregistrement DNSKEY. Pour créer une chaîne de confiance, le hachage de cette clé (DS enregistrement) est publié dans la zone parente (par exemple, pour example.com — dans la zone .com). Les clients prenant en charge DNSSEC peuvent vérifier la signature (RRSIG) de chaque enregistrement en utilisant la clé publique et s’assurer de son authenticité.
  • DNSKEY : La clé publique de la zone.
    • Exemple :example.com. 3600 IN DNSKEY 257 3 13 AwEAAa3d...9QAB
      • 257 — drapeaux (257 = KSK, 256 = ZSK).
      • 3 — protocole (toujours 3).
      • 13 — algorithme (13 = ECDSA/SHA256).
      • Dernier champ — clé en base64.
  • DS (Delegation Signer) : Hachage de la clé publique (DNSKEY) de la zone enfant, publié dans la zone parente pour créer une chaîne de confiance.
    • Exemple :example.com. 3600 IN DS 54517 13 2 84C8...D34F
      • 54517 — Key Tag (identifiant de clé).
      • 13 — Algorithme.
      • 2 — Type de digest (SHA-256).
      • Dernier champ — hachage en hex.
  • RRSIG (Resource Record Signature) : Signature numérique pour un ensemble d’enregistrements DNS.
    • Exemple (signature pour l’enregistrement A) :example.com. 3600 IN RRSIG A 13 2 3600 20251001000000 20250901000000 54517 example.com. oNvL...7Q==
      • A — type d’enregistrements signés.
      • 13 — algorithme.
      • 2 — nombre d’étiquettes dans le nom.
      • 3600 — TTL d’origine.
      • 20251001000000 — heure d’expiration de la signature.
      • 20250901000000 — heure de début de la signature.
      • 54517 — Key Tag de la clé de signature.
      • example.com. — nom du signataire.
      • Dernier champ — signature en base64.
  • NSEC / NSEC3 : Utilisés pour authentifier les réponses négatives (preuve qu’un enregistrement avec un tel nom ou type n’existe pas). NSEC3 hache en outre les noms pour se protéger contre les « promenades de zone ».
  • Activation de DNSSEC : C’est un processus séparé et complexe :
    1. Générez des paires de clés (KSK et ZSK) sur le serveur DNS.
    2. Publiez les enregistrements DNSKEY dans la zone.
    3. Générez un enregistrement DS à partir du KSK.
    4. Publiez l’enregistrement DS auprès du registre de domaine (dans la zone parente).
    5. Activez la signature de la zone sur le serveur DNS (génération automatique de RRSIG, NSEC/NSEC3).
    6. Testez en utilisant dig +dnssec et des outils en ligne (par exemple, Verisign DNSSEC Debugger).
  • Vérification :
    • dig +dnssec example.com A (affichera RRSIG pour l’enregistrement A si DNSSEC est activé et fonctionne).
    • dig +short example.com DNSKEY
    • dig +short example.com DS

SSHFP — Empreinte de clé publique SSH

  • Objectif : Publie le hachage (empreinte) de la clé SSH de l’hôte dans le DNS. Les clients SSH peuvent utiliser cet enregistrement pour vérifier automatiquement l’authenticité du serveur lors de la première connexion, empêchant ainsi les attaques de « l’homme du milieu » (MITM). Il est recommandé de l’utiliser avec DNSSEC pour garantir l’authenticité de l’enregistrement.
  • Format : nom TTL IN SSHFP algorithme type_de_digest empreinte
  • Exemple :
    example.com. 3600 IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
  • Explications :
    • Algorithm (Algorithme) :
      • 1 — RSA
      • 2 — DSA
      • 3 — ECDSA
      • 4 — ED25519
    • Digest Type (Type de digest) :
      • 1 — SHA-1
      • 2 — SHA-256
    • Fingerprint : Hachage de la clé publique au format hex.
  • Génération : Sur le serveur, vous pouvez générer l’enregistrement avec la commande : ssh-keygen -r example.com
  • Vérification : dig +short example.com SSHFP

Enregistrements rares et de service

  • HINFO (Informations sur l’hôte) : Stocke des informations sur le type de CPU et le système d’exploitation de l’hôte. Non recommandé pour une utilisation car il divulgue des informations potentiellement sensibles sur le système.
    • Exemple : server1.example.com. 3600 IN HINFO "Intel Xeon" "Ubuntu 22.04"
  • LOC (Emplacement) : Stocke les coordonnées géographiques (latitude, longitude, altitude) de l’hôte.
    • Exemple : example.com. 3600 IN LOC 55 45 21.000 N 37 37 03.000 E 15m
  • RP (Personne responsable) : Spécifie la personne de contact responsable de la zone. L’e-mail est spécifié au format nom d’hôte (point au lieu de @).
    • Exemple : example.com. 3600 IN RP admin.example.com. txt-record.example.com.
  • SPF (obsolète) : Existait auparavant comme un type d’enregistrement séparé mais est maintenant entièrement remplacé par TXT. Ne doit pas être utilisé.
    • Exemple (à ne pas utiliser) : example.com. IN SPF "v=spf1 ..."

3. Recommandations pratiques et nuances de configuration

  • Gestion du TTL :
    • Valeur standard : 3600 secondes (1 heure) — un bon équilibre entre performance (mise en cache) et flexibilité.
    • Avant la migration : Réduisez le TTL pour les enregistrements pertinents (par exemple, A/AAAA pour votre site web) à 300 secondes (5 minutes) 24-72 heures avant le changement prévu. Cela réduit le temps de propagation des changements.
    • Après la migration : Une fois les changements stabilisés, augmentez le TTL à une valeur optimale (par exemple, 3600 ou 86400) pour réduire la charge sur les serveurs DNS.
  • SOA Serial :
    • Toujours incrémenter le numéro de série après chaque modification de la zone. Sinon, les serveurs secondaires ne seront pas informés des mises à jour.
    • Format recommandé : YYYYMMDDNN (par exemple, 2024051701). C’est clair et permet de suivre facilement la date de la dernière modification.
  • CNAME sur Apex (Domaine racine) :
    • Problème : La norme RFC interdit CNAME sur le domaine apex (par exemple, example.com.) car il entre en conflit avec d’autres enregistrements obligatoires (NS, SOA).
    • Solution : Utilisez les fonctionnalités fournies par votre fournisseur DNS :
      • ALIAS/ANAME : Types d’enregistrements non standard qui se comportent comme CNAME mais sont résolus par le serveur DNS du fournisseur en enregistrements A/AAAA pour la réponse du client. Cela permet d’utiliser des alias sur l’apex.
      • CNAME Flattening : Une technologie (par exemple, dans Cloudflare) où un CNAME sur l’apex est automatiquement « aplati » — le serveur DNS renvoie les enregistrements A/AAAA de l’hôte cible au lieu du CNAME.
  • Enregistrements Glue :
    • Quand nécessaires : Si vos serveurs de noms (par exemple, ns1.example.com.) se trouvent dans la même zone qu’ils desservent (example.com.).
    • Que faire : Trouvez la section de configuration des enregistrements glue auprès de votre registre de domaine et ajoutez des enregistrements A (et/ou AAAA) pour vos serveurs de noms. Cela rompt la dépendance circulaire.
  • Configuration de PTR pour le courrier :
    • Exigence : L’adresse IP de votre serveur de messagerie doit avoir un enregistrement PTR qui se résout en son nom de domaine pleinement qualifié (FQDN, par exemple, mail.example.com.).
    • Cohérence : Le nom que le serveur de messagerie envoie dans la commande HELO/EHLO doit correspondre au nom de l’enregistrement PTR, et ce nom, à son tour, doit avoir un enregistrement A pointant vers la même adresse IP. Cela s’appelle « Forward-Confirmed Reverse DNS » (FCrDNS) et est critique pour la réputation.
    • Où configurer : Avec votre hébergeur ou propriétaire de l’adresse IP, et non dans la zone DNS de votre domaine.
  • Fractionnement des enregistrements TXT longs :
    • Si une chaîne dans un enregistrement TXT dépasse 255 octets, elle doit être divisée en plusieurs parties dans le fichier de zone. Chaque partie est encadrée de guillemets, et le serveur DNS les concatène automatiquement.
    • Exemple :
      example.com. IN TXT ( "v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:dmarc@thirdparty.com; " "ruf=mailto:forensics@example.com; fo=1; adkim=s; aspf=s; pct=100" )

4. Modèles complets de fichiers de zone (style BIND)

Ci-dessous se trouvent des modèles prêts à l’emploi pour trois scénarios courants. Remplacez example.com, example.net, les adresses IP et les clés par vos propres valeurs.

a) Site web simple (statique, sans courrier)

$TTL 3600
@   IN SOA ns1.hosting.net. hostmaster.example.com. (
        2025092201 ; serial (YYYYMMDDNN)
        7200       ; refresh (2 heures)
        3600       ; retry (1 heure)
        1209600    ; expire (14 jours)
        86400 )    ; minimum TTL (1 jour)

; Serveurs de noms autoritaires
@       IN NS   ns1.hosting.net.
@       IN NS   ns2.hosting.net.

; Serveur web (IPv4 et IPv6)
@       IN A    192.0.2.10
@       IN AAAA 2001:db8::10

; Sous-domaine WWW (alias vers apex)
www     IN CNAME @

; Sécurité : Restreindre les autorités de certification
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

b) Site web + serveur de messagerie propre

$TTL 3600
@   IN SOA ns1.example.net. admin.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        86400 )    ; minimum

; Serveurs de noms
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Section Web ---
@       IN A    192.0.2.10
www     IN CNAME @

; --- Section Courrier ---
; Enregistrement A pour le serveur de messagerie
mail    IN A    192.0.2.20

; Enregistrement MX pointant vers le serveur de messagerie
@       IN MX   10 mail.example.com.

; --- Authentification du courrier ---
; SPF : Autoriser l'adresse IP du serveur de messagerie et Google Workspace
@       IN TXT  "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all"

; DKIM : Clé publique pour le sélecteur 'default'
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

; DMARC : Politique pour mettre en quarantaine les échecs et envoyer des rapports
_dmarc  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

; --- Sécurité ---
@       IN CAA  0 issue "letsencrypt.org"

c) Site web + CDN + Courrier + DNSSEC (exemple complexe)

$TTL 300 ; Réduire le TTL pour plus de flexibilité avec le CDN
@   IN SOA ns1.example.net. hostmaster.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        3600 )     ; minimum (également utilisé pour la mise en cache négative)

; Serveurs de noms
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Section Web (avec CDN) ---
; Domaine Apex : Utilisez ALIAS/ANAME (spécifique au fournisseur) pour pointer vers l'origine ou le bord du CDN
; Si votre fournisseur prend en charge ALIAS :
; @     IN ALIAS origin.examplehost.net.
; Si vous utilisez l'aplatissement de CNAME pour l'apex (par exemple, Cloudflare) :
@       IN A    192.0.2.10 ; IP temporaire ou de secours, souvent gérée par le fournisseur

; Sous-domaine WWW : CNAME vers le fournisseur de CDN
www     IN CNAME cdn-provider.example.net.

; --- Section Courrier ---
mail    IN A    192.0.2.20
@       IN MX   10 mail.example.com.

; --- Authentification du courrier ---
@       IN TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
_dmarc  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:abuse@example.com; pct=100"

; --- Sécurité ---
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 issuewild "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

; --- DNSSEC (Clés d'exemple - REMPLACER PAR LES VÔTRES) ---
; Enregistrements DNSKEY (générés automatiquement par le serveur DNS lors de la signature)
@       IN DNSKEY 257 3 13 ( ; KSK
        AwEAAbOv...QAB )
@       IN DNSKEY 256 3 13 ( ; ZSK
        AwEAAa3d...9QAB )

; Les enregistrements RRSIG sont générés automatiquement par le serveur DNS lors de la signature et ne sont pas ajoutés manuellement au fichier de zone.
; Les enregistrements NSEC/NSEC3 sont également générés automatiquement.

; --- Services supplémentaires (Exemple) ---
; Enregistrement SRV pour le service SIP
_sip._tcp IN SRV 10 50 5060 sip1.example.com.

5. Configuration étape par étape du domaine de messagerie (PTR, SPF, DKIM, DMARC)

La configuration du courrier est une tâche complexe. Suivez ces étapes pour assurer une livraison maximale et une protection contre le spam.

Étape 1 : Configurer A/AAAA pour le serveur de messagerie
Assurez-vous que votre serveur de messagerie a un enregistrement A (et de préférence AAAA).

mail.example.com. 3600 IN A 192.0.2.20

Étape 2 : Configurer les enregistrements MX
Spécifiez que le courrier pour example.com doit être livré à mail.example.com..

example.com. 3600 IN MX 10 mail.example.com.

Étape 3 : Configurer PTR (DNS inverse)
C’est l’étape la plus importante et souvent négligée. Contactez votre hébergeur ou propriétaire de l’adresse IP (192.0.2.20) et demandez un enregistrement PTR pointant vers mail.example.com..

  • Vérification : dig -x 192.0.2.20 +short devrait renvoyer mail.example.com..

Étape 4 : Configurer SPF (via TXT)
Définissez quels serveurs sont autorisés à envoyer du courrier au nom de example.com. Incluez votre serveur et tous les services tiers (Gmail, SendGrid, etc.).

example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.20 include:_spf.google.com -all"
  • Commencez par ~all (échec doux) pour les tests, puis passez à -all (échec strict).

Étape 5 : Configurer DKIM

  1. Générez une paire de clés (privée et publique) sur votre serveur de messagerie (MTA). Choisissez un « sélecteur » (par exemple, default, 202405).
  2. Configurez le MTA pour signer les e-mails sortants en utilisant la clé privée et le sélecteur choisi.
  3. Publiez la clé publique dans le DNS sous forme d’enregistrement TXT pour le sous-domaine sélecteur._domainkey.example.com..
    default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

Étape 6 : Configurer DMARC
Définissez la politique de gestion des e-mails qui échouent aux vérifications SPF/DKIM et configurez l’envoi de rapports.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
  • Stratégie de déploiement :
    1. Commencez par p=none — les e-mails ne sont pas bloqués, vous recevez uniquement des rapports.
    2. Analysez les rapports, corrigez les erreurs dans SPF/DKIM.
    3. Passez à p=quarantine — les e-mails suspects vont dans le spam.
    4. Passez à p=reject — les e-mails suspects sont rejetés.

Conseils supplémentaires :

  • Assurez-vous que le nom que votre serveur de messagerie envoie dans la commande HELO/EHLO correspond au nom de l’enregistrement PTR (mail.example.com.).
  • Utilisez des outils en ligne pour vérifier votre configuration : mail-tester.com, mxtoolbox.com, dmarcian.com.

6. Commandes pour la vérification et le débogage DNS

Les outils en ligne de commande sont indispensables pour les administrateurs.

  • dig (Domain Information Groper) — l’outil le plus puissant et recommandé.
    • Requêtes de base :
      • dig +short example.com A — obtenir uniquement l’adresse IPv4.
      • dig +short example.com AAAA — obtenir uniquement l’adresse IPv6.
      • dig +short example.com MX — obtenir les enregistrements MX.
      • dig +short example.com TXT — obtenir les enregistrements TXT (SPF, DKIM, DMARC).
      • dig +short www.example.com CNAME — obtenir le CNAME.
      • dig +short _sip._tcp.example.com SRV — obtenir l’enregistrement SRV.
    • DNS inverse :
      • dig -x 192.0.2.1 +short — obtenir le PTR pour l’IP.
    • Tracé de la délégation :
      • dig +trace example.com — montre tout le chemin depuis les serveurs racine jusqu’aux serveurs autoritaires de votre zone. Idéal pour diagnostiquer les problèmes de délégation.
    • Requête à un serveur spécifique :
      • dig @ns1.example.net example.com SOA — demander l’enregistrement SOA à un serveur de noms spécifique.
    • Vérification DNSSEC :
      • dig +dnssec example.com A — effectuer une requête avec le drapeau DO (DNSSEC OK) et afficher les enregistrements RRSIG s’ils existent.
      • dig +short example.com DNSKEY — obtenir les enregistrements DNSKEY.
      • dig +short example.com DS — obtenir l’enregistrement DS (de la zone parente).
    • Vérification TLSA (DANE) :
      • dig +short _443._tcp.www.example.com. TLSA
    • Vérification SSHFP :
      • dig +short example.com SSHFP
  • nslookup — outil ancien mais encore rencontré.
    • nslookup -type=MX example.com
    • nslookup -type=TXT example.com
    • nslookup 192.0.2.1 (pour PTR)
  • host — simple et pratique pour les requêtes de base.
    • host -t A example.com
    • host -t MX example.com
    • host -t TXT example.com
    • host 192.0.2.1 (pour PTR)
    • host -t sshfp example.com

7. Sécurité et meilleures pratiques

  • DNSSEC : Activez DNSSEC pour les domaines critiques. Cela protège vos utilisateurs contre les réponses DNS falsifiées. Commencez avec un domaine de test pour maîtriser la procédure (génération de clés, publication de DS auprès du registre). Utilisez des validateurs en ligne pour vérifier.
  • CAA : Configurez toujours les enregistrements CAA. C’est un moyen simple et efficace d’empêcher l’émission non autorisée de certificats pour votre domaine. Spécifiez uniquement les CA que vous utilisez (par exemple, letsencrypt.org).
  • Gestion des clés DKIM : Générez régulièrement (par exemple, annuellement) de nouvelles paires de clés DKIM. Publiez la nouvelle clé publique dans le DNS, configurez le MTA pour utiliser le nouveau sélecteur, et après quelques semaines (en vous assurant que tous les anciens e-mails signés avec l’ancienne clé sont traités), supprimez l’ancien enregistrement TXT.
  • Confidentialité : Ne publiez pas les enregistrements HINFO car ils divulguent des informations sur le matériel et les logiciels qui pourraient être utiles aux attaquants.
  • Requêtes ANY : De nombreux résolveurs DNS publics (par exemple, Google Public DNS, Cloudflare) ne traitent plus les requêtes ANY en raison de leur utilisation dans les attaques DDoS. Ne vous y fiez pas.

8. Erreurs courantes et comment les éviter

  1. CNAME entre en conflit avec d’autres enregistrements : Vous ne pouvez pas avoir un CNAME et, par exemple, un A ou MX pour le même nom. Solution : Revoir la structure de votre zone. Utilisez des enregistrements A ou ALIAS/ANAME pour l’apex.
  2. Absence de PTR pour le serveur de messagerie : C’est la principale raison pour laquelle le courrier finit dans le spam. Solution : Configurez toujours PTR avec votre hébergeur.
  3. Numéro de série SOA inchangé : Si vous n’incrémentez pas le numéro de série, les serveurs secondaires ne seront pas informés des mises à jour. Solution : Incrémentez toujours Serial après toute modification de la zone. Automatisez ce processus si possible.
  4. Formatage incorrect des enregistrements TXT longs : Si une chaîne est plus longue que 255 octets et n’est pas divisée en parties, elle peut être tronquée ou provoquer une erreur. Solution : Divisez toujours les chaînes longues dans les enregistrements TXT, en encadrant chaque partie de guillemets.
  5. DS incorrect lors de l’activation de DNSSEC : Si l’enregistrement DS publié auprès du registre ne correspond pas à votre DNSKEY, la zone deviendra « non fiable », et les clients avec DNSSEC activé ne pourront pas obtenir d’enregistrements à partir de celle-ci. Solution : Suivez attentivement les instructions de votre serveur DNS et de votre registre. Vérifiez deux fois les hachages.
  6. TTL élevé avant la migration : Si le TTL est élevé (par exemple, 86400), après avoir changé l’adresse IP, les utilisateurs atteindront l’ancienne adresse pendant une journée. Solution : Réduisez toujours le TTL un jour ou deux avant une migration planifiée.
  7. CNAME sur le domaine apex : L’utilisation directe de CNAME pour example.com. viole la RFC et peut provoquer un comportement imprévisible. Solution : Utilisez ALIAS/ANAME ou CNAME flattening fourni par votre fournisseur DNS.

9. Liste de vérification avant la mise en production ou la migration

Utilisez cette liste pour les vérifications finales avant de lancer ou de déplacer un site/service.

  • [ ] Enregistrements de base : A/AAAA pour tous les hôtes clés (web, courrier) sont configurés et pointent vers les bonnes adresses IP.
  • [ ] Courrier : Les enregistrements MX sont configurés et pointent vers des hôtes ayant des enregistrements A/AAAA.
  • [ ] DNS inverse : Les enregistrements PTR pour toutes les adresses IP des serveurs de messagerie sont configurés et corrects (vérifié via dig -x).
  • [ ] SPF : L’enregistrement TXT SPF est configuré, inclut toutes les sources autorisées et a le mécanisme de terminaison correct (-all ou ~all).
  • [ ] DKIM : La clé publique est publiée dans le DNS, le MTA est configuré pour signer les e-mails. La signature est vérifiée sur un e-mail de test.
  • [ ] DMARC : L’enregistrement TXT DMARC est publié. Pour les nouveaux déploiements, il est recommandé de commencer par p=none.
  • [ ] Serveurs de noms : Les enregistrements NS dans la zone correspondent aux serveurs spécifiés auprès du registre. Les enregistrements glue sont configurés si nécessaire.
  • [ ] Numéro de série SOA : Le numéro de série a été incrémenté après tous les changements récents.
  • [ ] CAA : Les enregistrements CAA sont configurés pour restreindre l’émission de certificats.
  • [ ] TTL : Le TTL a été réduit à l’avance (si une migration était prévue).
  • [ ] Vérification : Des vérifications ont été effectuées à l’aide de dig +trace, dig MX, dig TXT et d’outils en ligne (par exemple, MXToolbox).
  • [ ] DNSSEC (si activé) : L’enregistrement DS est correctement ajouté auprès du registre, les vérifications DNSSEC réussissent.
  • [ ] Sauvegarde : L’exportation de la zone actuelle est enregistrée.
  • [ ] Plan de retour en arrière : Les étapes pour annuler les changements en cas d’échec sont clairement écrites.
  • [ ] Surveillance : Les systèmes de surveillance sont configurés pour suivre la disponibilité des serveurs DNS et les changements de zone.

10. Exemples supplémentaires et explications des champs

  • SRV — Approfondissement :_xmpp-client._tcp.example.com. 3600 IN SRV 5 20 5222 xmpp1.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 5 30 5222 xmpp2.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 10 100 5222 backup.example.com.
    • Le client contactera d’abord les serveurs avec la priorité 5 (xmpp1 et xmpp2).
    • Entre xmpp1 et xmpp2, la sélection sera proportionnelle à leur poids : xmpp1 a 40% de chances (20/(20+30)), xmpp2 — 60% (30/(20+30)).
    • Le serveur backup.example.com. (priorité 10) ne sera utilisé que si les deux serveurs avec la priorité 5 sont indisponibles.
  • TLSA — Décodage de l’exemple :_443._tcp.www.example.com. IN TLSA 3 1 1 d2abde...f21
    • 3 (DANE-EE) : Le client doit utiliser ce certificat exact (ou sa clé publique), indépendamment de la chaîne de confiance de la CA.
    • 1 (Sélecteur) : L’enregistrement stocke le hachage non pas du certificat entier, mais uniquement de sa clé publique. C’est plus pratique car lors du renouvellement d’un certificat avec la même clé, vous n’avez pas besoin de modifier l’enregistrement TLSA.
    • 1 (Type de correspondance) : Le hachage SHA-256 est utilisé.
  • SSHFP — Décodage de l’exemple :
    example.com. IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
    • 4 : Algorithme — ED25519 (moderne et sécurisé).
    • 2 : Type de digest — SHA-256.
    • 356a19...28ab : Hachage SHA-256 de la clé publique ED25519.

11. Scénarios utiles

  • Connexion d’un site web à un CDN :
    1. Généralement, le fournisseur de CDN vous demande de faire un CNAME pour un sous-domaine (par exemple, www) vers leur adresse (par exemple, example.cdnprovider.com).
    2. Si vous souhaitez utiliser le CDN pour le domaine racine (example.com), utilisez la fonctionnalité ALIAS/ANAME ou CNAME flattening de votre fournisseur DNS.
    3. Assurez-vous que le CDN est correctement configuré pour fonctionner avec votre certificat SSL (souvent le CDN prend en charge la terminaison SSL). La prise en compte des enregistrements CAA est importante dans ce cas.
  • Déplacement d’un hôte (migration) :
    1. 48-72 heures avant la migration : Réduisez le TTL pour les enregistrements A/AAAA de votre site à 300 secondes.
    2. Attendez : Attendez que l’ancien TTL se « propage » (attendez une période égale à l’ancien TTL, par exemple, 3600 secondes).
    3. Le jour de la migration : Modifiez les enregistrements A/AAAA pour qu’ils pointent vers les nouvelles adresses IP.
    4. Vérification : Utilisez dig +short example.com A avec différents DNS publics (Google 8.8.8.8, Cloudflare 1.1.1.1) pour vérifier la propagation des changements.
    5. Après stabilisation (après 24-48 heures) : Augmentez le TTL à une valeur optimale (par exemple, 3600).

12. JSON prêt à l’emploi pour l’importation dans le panneau du fournisseur

Ci-dessous se trouve un modèle JSON étendu contenant presque tous les types d’enregistrements couverts dans ce guide. Ce format est généralisé et peut nécessiter une adaptation à l’API spécifique de votre fournisseur DNS (Cloudflare, AWS Route 53, DigitalOcean, etc.).

{
  "zone": "example.com",
  "records": [
    {
      "type": "A",
      "name": "@",
      "value": "192.0.2.10",
      "ttl": 3600
    },
    {
      "type": "AAAA",
      "name": "@",
      "value": "2001:db8::10",
      "ttl": 3600
    },
    {
      "type": "CNAME",
      "name": "www",
      "value": "example.com.",
      "ttl": 3600
    },
    {
      "type": "MX",
      "name": "@",
      "value": "mail.example.com.",
      "priority": 10,
      "ttl": 3600
    },
    {
      "type": "MX",
      "name": "@",
      "value": "backup-mail.example.com.",
      "priority": 20,
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "@",
      "value": "v=spf1 ip4:192.0.2.20 include:_spf.google.com -all",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "default._domainkey",
      "value": "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQA...",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "_dmarc",
      "value": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "value": "ns1.example.net.",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "value": "ns2.example.net.",
      "ttl": 3600
    },
    {
      "type": "SOA",
      "name": "@",
      "primary_ns": "ns1.example.net.",
      "admin_email": "admin.example.com.",
      "serial": 2025092201,
      "refresh": 7200,
      "retry": 3600,
      "expire": 1209600,
      "minimum": 86400,
      "ttl": 3600
    },
    {
      "type": "PTR",
      "name": "20.2.0.192.in-addr.arpa.",
      "value": "mail.example.com.",
      "ttl": 3600
    },
    {
      "type": "SRV",
      "name": "_sip._tcp",
      "target": "sipserver.example.com.",
      "port": 5060,
      "priority": 10,
      "weight": 60,
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "value": "letsencrypt.org",
      "flags": 0,
      "tag": "issue",
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "value": "mailto:security@example.com",
      "flags": 0,
      "tag": "iodef",
      "ttl": 3600
    },
    {
      "type": "TLSA",
      "name": "_443._tcp.www",
      "usage": 3,
      "selector": 1,
      "matching_type": 1,
      "value": "d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971",
      "ttl": 3600
    },
    {
      "type": "SSHFP",
      "name": "@",
      "algorithm": 4,
      "digest_type": 2,
      "value": "356a192b7913b04c54574d18c28d46e6395428ab",
      "ttl": 3600
    },
    {
      "type": "HINFO",
      "name": "server1",
      "cpu": "Intel Xeon",
      "os": "Ubuntu 22.04 LTS",
      "ttl": 3600
    },
    {
      "type": "LOC",
      "name": "@",
      "latitude": "55.7558 N",
      "longitude": "37.6176 E",
      "altitude": 150,
      "ttl": 3600
    },
    {
      "type": "RP",
      "name": "@",
      "mbox": "admin.example.com.",
      "txt": "Technical Support",
      "ttl": 3600
    },
    {
      "type": "NAPTR",
      "name": "4.3.2.1.5.5.5.1.e164.arpa.",
      "order": 100,
      "preference": 10,
      "flags": "U",
      "service": "E2U+sip",
      "regexp": "!^.*$!sip:info@example.com!",
      "replacement": ".",
      "ttl": 3600
    },
    {
      "type": "DS",
      "name": "@",
      "key_tag": 54517,
      "algorithm": 13,
      "digest_type": 2,
      "digest": "84C84478D00A57973FC5D3E32F7E2BF539FB697D2660874C6D33A3313872D34F",
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "flags": 257,
      "protocol": 3,
      "algorithm": 13,
      "public_key": "AwEAAbOv...QAB",
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "flags": 256,
      "protocol": 3,
      "algorithm": 13,
      "public_key": "AwEAAa3d...9QAB",
      "ttl": 3600
    }
  ]
}


Cloudflare:

{
  "zone_name": "example.com",
  "zone_type": "full",
  "records": [
    {
      "type": "A",
      "name": "@",
      "content": "192.0.2.10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "AAAA",
      "name": "@",
      "content": "2001:db8::10",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "CNAME",
      "name": "www",
      "content": "example.com",
      "ttl": 3600,
      "proxied": false
    },
    {
      "type": "MX",
      "name": "@",
      "content": "mail.example.com",
      "priority": 10,
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "@",
      "content": "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "_dmarc",
      "content": "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns1.example.net",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "content": "ns2.example.net",
      "ttl": 3600
    },
    {
      "type": "SRV",
      "name": "_sip._tcp",
      "data": {
        "target": "sipserver.example.com",
        "port": 5060,
        "priority": 10,
        "weight": 60
      },
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "data": {
        "flags": 0,
        "tag": "issue",
        "value": "letsencrypt.org"
      },
      "ttl": 3600
    },
    {
      "type": "TLSA",
      "name": "_443._tcp",
      "data": {
        "usage": 3,
        "selector": 1,
        "matching_type": 1,
        "certificate": "<hex-of-cert-hash>"
      },
      "ttl": 3600
    },
    {
      "type": "SSHFP",
      "name": "@",
      "data": {
        "algorithm": 4,
        "digest_type": 2,
        "fingerprint": "d6f8..."
      },
      "ttl": 3600
    },
    {
      "type": "HINFO",
      "name": "@",
      "data": {
        "cpu": "INTEL",
        "os": "Linux"
      },
      "ttl": 3600
    },
    {
      "type": "LOC",
      "name": "@",
      "data": {
        "latitude": "37.7749N",
        "longitude": "122.4194W",
        "altitude": 30
      },
      "ttl": 3600
    },
    {
      "type": "RP",
      "name": "admin",
      "data": {
        "mbox": "admin.example.com",
        "txt": "Responsible person for the domain"
      },
      "ttl": 3600
    },
    {
      "type": "NAPTR",
      "name": "_sip._tcp",
      "data": {
        "order": 100,
        "preference": 10,
        "flags": "U",
        "service": "SIP+D2U",
        "regexp": "",
        "replacement": "_sip._udp.example.com"
      },
      "ttl": 3600
    },
    {
      "type": "DS",
      "name": "@",
      "data": {
        "key_tag": 12345,
        "algorithm": 8,
        "digest_type": 2,
        "digest": "<hex-digest>"
      },
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "data": {
        "flags": 256,
        "protocol": 3,
        "algorithm": 8,
        "public_key": "<base64-key>"
      },
      "ttl": 3600
    },
    {
      "type": "RRSIG",
      "name": "@",
      "data": {
        "type_covered": "A",
        "algorithm": 8,
        "labels": 1,
        "original_ttl": 3600,
        "signature_expiration": 1700000000,
        "signature_inception": 1690000000,
        "key_tag": 12345,
        "signer_name": "example.com",
        "signature": "<base64-signature>"
      },
      "ttl": 3600
    },
    {
      "type": "NSEC",
      "name": "@",
      "data": {
        "next_domain": "example.net",
        "types": ["A","AAAA","MX","TXT","NS"]
      },
      "ttl": 3600
    }
  ]
}

Route 53:

{
  "Comment": "Full DNS cheat sheet import",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "A",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "192.0.2.10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "AAAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "2001:db8::10"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com.",
        "Type": "CNAME",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "MX",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 mail.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_dmarc.example.com.",
        "Type": "TXT",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NS",
        "TTL": 3600,
        "ResourceRecords": [
          {"Value": "ns1.example.net"},
          {"Value": "ns2.example.net"}
        ]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "SRV",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "10 60 5060 sipserver.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "CAA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "0 issue \"letsencrypt.org\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_443._tcp.example.com.",
        "Type": "TLSA",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "3 1 1 <hex-of-cert-hash>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "SSHFP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "4 2 d6f8..."}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "HINFO",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "\"INTEL\" \"Linux\""}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "LOC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "37.7749N 122.4194W 30m"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "admin.example.com.",
        "Type": "RP",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "admin.example.com Responsible person for the domain"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com.",
        "Type": "NAPTR",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "100 10 U SIP+D2U "" _sip._udp.example.com"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DS",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "12345 8 2 <hex-digest>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "DNSKEY",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "256 3 8 <base64-key>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "RRSIG",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "A 8 1 3600 1700000000 1690000000 12345 example.com <base64-signature>"}]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "NSEC",
        "TTL": 3600,
        "ResourceRecords": [{"Value": "example.net A AAAA MX TXT NS"}]
      }
    }
  ]
}

Full support for all record types: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, TLSA, SSHFP, HINFO, LOC, RP, NAPTR, DS, DNSKEY, RRSIG, NSEC. TTL and priorities are already set and can be adapted as needed. Uses ResourceRecords for each record, as required by AWS.
Direct import via AWS CLI with the command:

aws route53 change-resource-record-sets --hosted-zone-id ZONE_ID --change-batch file://dns_records.json


Le DNS est un système puissant et flexible, et la connaissance de celui-ci est crucialement importante pour toute personne gérant des projets web, des systèmes de messagerie ou une infrastructure réseau. Ce guide couvre tous les aspects — des enregistrements A simples aux mécanismes de sécurité complexes comme DNSSEC et DANE.

Points clés à retenir :

  • Planifiez les changements : Réduisez toujours le TTL avant une migration.
  • Testez : Utilisez dig, nslookup et des outils en ligne pour vérifier chaque configuration.
  • Sécurité d’abord : Configurez SPF, DKIM, DMARC pour le courrier. Activez CAA pour contrôler les certificats. Envisagez d’utiliser DNSSEC pour les domaines critiques.
  • Documentez : Tenez des listes de vérification et sauvegardez les zones.

Ce matériel est conçu pour être votre référence universelle. Enregistrez-le, et il vous aidera à résoudre toute tâche liée au DNS.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *