Analyseur d'enregistrements DNS

DNS (Domain Name System) associe les noms de domaine aux adresses IP et configure le routage des e-mails. Cet outil analyse la sortie de fichiers de zone de dig ou BIND, analyse les enregistrements d'authentification e-mail (SPF, DMARC, DKIM, BIMI) et avertit des mauvaises configurations courantes.

Specifications

Cas d'utilisation courants

Analyser la sortie des commandes dig ou host pour le dépannage
Auditer la configuration DNS d'un domaine avant la migration
Vérifier la configuration d'authentification e-mail (SPF, DMARC, DKIM)
Déboguer les problèmes de délivrabilité des e-mails
Documenter les enregistrements DNS d'un domaine pour la conformité
Vérifier les enregistrements CAA avant de demander des certificats SSL

Fonctionnalites

Analyser la sortie de fichier de zone BIND/dig
Afficher les enregistrements A, AAAA, NS, MX, TXT, CNAME, SOA, SRV, CAA, TLSA
Formatage TTL lisible (5m, 2h, 1d)
Détection automatique et analyse des enregistrements SPF avec explication des mécanismes
Analyse des politiques DMARC et de la configuration de rapports
Analyse des enregistrements DKIM (type de clé, sélecteur, validité, mode test)
Analyse des enregistrements BIMI (présence VMC, validité)
Prise en charge DNSSEC (enregistrements DNSKEY, DS, RRSIG avec expiration)
Affichage de l'épinglage de certificat TLSA/DANE
Validation du nombre de recherches DNS SPF (max 10 selon RFC 7208)
Avertissement sur les mauvaises configurations d'authentification e-mail

Exemples

Sortie de fichier de zone

Essayer →

Sortie de dig montrant différents types d'enregistrements.

example.com.             300     IN      A       192.0.2.1
example.com.             172800  IN      NS      ns1.example.com.
example.com.             172800  IN      NS      ns2.example.com.
example.com.             300     IN      MX      10 mail.example.com.
example.com.             300     IN      TXT     "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com.      300     IN      TXT     "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Enregistrement SPF

Essayer →

Un enregistrement SPF autorisant Google et Mailgun à envoyer des e-mails.

v=spf1 include:_spf.google.com include:mailgun.org ip4:192.168.1.0/24 ~all

Enregistrement DMARC

Essayer →

Une politique DMARC stricte avec rapports agrégés et forensiques.

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s; pct=100

Conseils

Obtenir tous les enregistrements avec : dig example.com ANY +noall +answer
SPF autorise au maximum 10 recherches DNS. Utilisez "include" avec parcimonie.
DMARC p=reject est le plus strict, mais commencez avec p=none et les rapports rua.
Les enregistrements CAA restreignent les AC qui peuvent émettre des certificats pour votre domaine.
Les enregistrements TLSA permettent DANE pour la vérification des certificats.

Comprendre Analyseur d'enregistrements DNS

Le Domain Name System (DNS) est le service d'annuaire d'Internet, traduisant les noms de domaine lisibles par l'homme en adresses IP et fournissant d'autres correspondances critiques. Les enregistrements DNS sont stockés dans des fichiers de zone sur les serveurs de noms faisant autorité, chacun avec un nom, un type, une classe, un TTL (time to live) et des données spécifiques au type.

Les types d'enregistrements les plus fondamentaux gèrent la résolution de noms. Les enregistrements A associent un domaine à une adresse IPv4, les enregistrements AAAA à une adresse IPv6. Les enregistrements CNAME créent des alias pointant un nom vers un autre. Les enregistrements NS délèguent les sous-domaines à des serveurs de noms spécifiques. Les enregistrements MX dirigent les e-mails vers les serveurs de messagerie avec une valeur de priorité. Les enregistrements SOA contiennent les métadonnées de zone incluant le serveur de noms principal et le numéro de série.

Les enregistrements TXT portent les données d'authentification des e-mails. Les enregistrements SPF (v=spf1 ...) spécifient les expéditeurs d'e-mails autorisés. Les enregistrements DMARC (v=DMARC1; ...) indiquent aux destinataires comment gérer les échecs SPF/DKIM. Les enregistrements DKIM stockent les clés publiques pour la vérification des signatures d'e-mails. Une authentification e-mail mal configurée est une cause principale de problèmes de délivrabilité.

La valeur TTL contrôle combien de temps les résolveurs mettent les réponses en cache. Des TTL élevés (86400 secondes = 1 jour) réduisent le trafic DNS mais rendent les changements lents à se propager. Des TTL bas (300 secondes = 5 minutes) permettent des mises à jour rapides mais augmentent le volume de requêtes. Avant les migrations, abaissez les TTL à l'avance pour que les anciennes valeurs expirent rapidement.

Le DNS ne "se propage" pas réellement de la manière que le terme implique. Quand un enregistrement change, les résolveurs continuent de servir l'ancienne valeur en cache jusqu'à l'expiration de son TTL, puis récupèrent la nouvelle valeur depuis le serveur faisant autorité. Si le TTL était de 86400 (24 heures), il peut falloir jusqu'à 24 heures pour que le changement soit visible partout. Pour accélérer les changements, abaissez le TTL bien à l'avance (par exemple, à 300 secondes 48 heures avant la migration), faites la mise à jour, puis remontez le TTL après.

Un enregistrement A associe un domaine directement à une adresse IPv4, tandis qu'un CNAME crée un alias pointant vers un autre nom de domaine — le résolveur suit la chaîne jusqu'à l'enregistrement A final. Les CNAME ne peuvent pas être utilisés à l'apex de zone (domaine nu comme example.com) car ils entrent en conflit avec les enregistrements SOA et NS requis à l'apex. Certains fournisseurs DNS proposent des types d'enregistrements propriétaires ALIAS ou ANAME pour contourner cette limitation.

La mise en place de l'authentification des e-mails implique trois enregistrements DNS. Pour SPF, ajoutez un enregistrement TXT avec "v=spf1" suivi des expéditeurs autorisés. Pour DKIM, ajoutez un enregistrement TXT à un sous-domaine sélecteur contenant la clé publique fournie par le service d'e-mail. Pour DMARC, ajoutez un enregistrement TXT à _dmarc.votredomaine.com spécifiant la politique (none, quarantine ou reject) et une adresse de rapport. Commencer avec p=none permet la surveillance de l'alignement avant l'application. Les échecs SPF sont couramment causés par le dépassement de la limite de 10 recherches DNS, l'oubli d'autoriser un service d'envoi, l'utilisation de -all (échec strict) avant que tous les expéditeurs soient vérifiés, ou la présence de plusieurs enregistrements SPF sur le même domaine — un seul enregistrement v=spf1 est autorisé, et plusieurs enregistrements causent une erreur permanente.

← Retour a tous les outils