Aller au contenu principal

Recherche enregistrement CAA (Certificate Authority Authorization)

Contrôlez quelles autorités peuvent émettre des certificats SSL/TLS

Sécurisez vos certificats SSL/TLS en vérifiant que seules les autorités autorisées peuvent en émettre pour votre domaine.

En mode trace itérative, le résolveur est ignoré.
Interroge plusieurs résolveurs publics pour comparer les réponses.

Politique de certification

Découvrez quelles autorités de certification (Let's Encrypt, DigiCert, etc.) sont autorisées à émettre des certificats pour le domaine.

Multi-résolveur

Comparez les réponses de Google, Cloudflare et Quad9 pour détecter les problèmes de propagation.

Tags issue et issuewild

Analysez les autorisations pour les certificats standard et wildcard séparément.

Alertes iodef

Vérifiez si une adresse de notification est configurée pour les tentatives d'émission non autorisées.

Gratuit et illimité

Testez autant de domaines que nécessaire. Aucune inscription requise.

Comment bien utiliser les différentes options du moteur de recherche DNS ?

Qu'est-ce que la trace itérative ?

La trace exécute la résolution pas à pas. Le résolveur interroge d'abord les serveurs de la racine, puis ceux du TLD (.com, .fr, .eu), puis les serveurs autoritaires de la zone cible. À chaque étape, la page affiche le serveur interrogé, la réponse, le RCODE et la latence.

  1. 1. Racine

    Découverte des serveurs du TLD pour le nom demandé.

  2. 2. TLD

    Référence vers les NS de la zone (délégation).

  3. 3. Autoritaires

    Réponse finale (ou erreur) avec TTL et latence.

À quoi ça sert ?

  • Comparer les réponses selon les résolveurs et les régions
  • Détecter un cache chaud, un TTL trop long ou une délégation incomplète
  • Expliquer une différence de latence ou un RCODE inattendu

Astuce : gardez la trace désactivée pour les vérifications rapides ; activez-la quand vous enquêtez ou préparez un ticket/post-mortem.

Qu'est-ce que la trace classique ?

La trace classique interroge uniquement le résolveur sélectionné (UDP ou DoH) et restitue la réponse telle qu'elle est perçue depuis ce point du réseau. Vous obtenez le RCODE, les sections de réponse et la latence du trajet client → résolveur.

  1. 1. Résolveur choisi

    Utilise le preset ou la configuration personnalisée pour lancer la requête exactement comme votre service.

  2. 2. Protocole conservé

    Respecte le transport sélectionné (UDP, TCP ou DoH) afin de reproduire le comportement réel.

  3. 3. Réponse détaillée

    Affiche les sections question, answer, authority/additional quand elles existent, avec TTL et métadonnées utiles.

Pourquoi l'utiliser ?

  • Vérifier la vision d'un résolveur spécifique avant de suspecter la délégation
  • Confirmer les valeurs en cache et l'impact d'un TTL ou d'un flush
  • Documenter une résolution telle qu'un client ou un microservice la voit

Astuce : laissez l'option de trace itérative désactivée quand vous auditez un résolveur donné ; activez-la ensuite pour comparer avec le parcours root → TLD → autoritaire.

Comment fonctionne le test de propagation ?

Le test interroge en parallèle un ensemble de résolveurs publics (Google, Cloudflare, Quad9, OpenDNS, FAI…) et groupe les réponses par contenu et RCODE. Vous visualisez instantanément qui a déjà pris en compte la mise à jour.

  1. 1. Résolveurs multipoints

    Active les presets de propagation pour interroger plusieurs acteurs répartis dans le monde.

  2. 2. Comparaison automatique

    Regroupe les réponses identiques et signale les divergences ou les erreurs propres à un résolveur.

  3. 3. Synthèse exploitable

    Fournit un résumé clair, la liste des résolveurs, leurs latences et l'état de chaque groupe.

Quand l'utiliser ?

  • Suivre la diffusion d'un changement DNS à l'échelle mondiale
  • Identifier les caches encore anciens et décider d'un flush ciblé
  • Partager un état de propagation dans un ticket ou un post-mortem

Astuce : pendant le test de propagation, la sélection de résolveur est figée. Désactivez le mode pour revenir au diagnostic unitaire.

Qu'est-ce qu'un enregistrement CAA ?

Un enregistrement CAA (Certificate Authority Authorization) définit quelles autorités de certification (CA) sont autorisées à émettre des certificats SSL/TLS pour un domaine. C'est une mesure de sécurité qui empêche l'émission non autorisée de certificats.

Structure d'un enregistrement CAA :

ChampDescriptionExemple
Flag0 (standard) ou 128 (critique)0
TagType d'autorisationissue, issuewild, iodef
ValeurCA autorisée ou adresse de contact"letsencrypt.org"
TTLDurée de cache en secondes3600

Tags CAA disponibles

issue - Certificats standard

Autorise une CA pour les certificats non-wildcard :

captaindns.com.  3600  IN  CAA  0 issue "letsencrypt.org"
captaindns.com.  3600  IN  CAA  0 issue "digicert.com"

issuewild - Certificats wildcard

Autorise une CA pour les certificats wildcard (*.domaine) :

captaindns.com.  3600  IN  CAA  0 issuewild "letsencrypt.org"

iodef - Notifications

Adresse pour recevoir les rapports de tentatives non autorisées :

captaindns.com.  3600  IN  CAA  0 iodef "mailto:security@captaindns.com"

Interdire toute émission

Bloquer toutes les CA :

captaindns.com.  3600  IN  CAA  0 issue ";"

Règles importantes

Héritage et sous-domaines

SituationComportement
CAA à l'apexS'applique à tous les sous-domaines
CAA sur sous-domaineRemplace la règle de l'apex pour ce sous-domaine
Pas de CAAAucune restriction, toute CA peut émettre

Bonnes pratiques

PratiquePourquoi
Limiter les CARéduire la surface d'attaque
Configurer iodefÊtre alerté des tentatives
Tester avant productionÉviter les blocages

Problèmes courants

Certificat refusé par la CA

La CA refuse d'émettre car elle n'est pas dans le CAA.

  1. Vérifiez les enregistrements CAA du domaine
  2. Ajoutez la CA si elle est légitime
  3. Attendez la propagation

Wildcard bloqué

Le certificat wildcard est refusé malgré un tag issue.

  1. issuewild est requis pour les wildcards
  2. Ajoutez un enregistrement issuewild
  3. issue seul ne suffit pas pour *.domaine

Sous-domaine non couvert

Un sous-domaine a des règles différentes.

  1. Vérifiez le CAA spécifique au sous-domaine
  2. L'héritage peut être remplacé
  3. Ajoutez le CAA au niveau du sous-domaine si besoin

Vérification en ligne de commande

Linux/Mac

dig CAA captaindns.com

Vérifier un sous-domaine :

dig CAA www.captaindns.com

Windows

nslookup -type=caa captaindns.com

Configuration recommandée

Exemple complet

; Autoriser Let's Encrypt pour tous les certificats
captaindns.com.  3600  IN  CAA  0 issue "letsencrypt.org"
captaindns.com.  3600  IN  CAA  0 issuewild "letsencrypt.org"

; Notifications de sécurité
captaindns.com.  3600  IN  CAA  0 iodef "mailto:security@captaindns.com"

Outils complémentaires

OutilUtilité
Recherche TXTVérifier d'autres politiques de sécurité
Propagation DNSVérifier la propagation mondiale

Ressources utiles