Vérification des DNS

Récemment dans mon quotidien de développeur, je me suis retrouvé confronté à la question de la validité de la zone DNS, ou, pour le formuler plus simplement, à la question : comment vérifier le contenu d’une zone DNS ?

J’avais en effet transmis des informations à un tiers pour la configuration de la zone DNS d’un domaine, mais après vérification capture d’écran à l’appui : rien à faire. La validation du domaine restait en erreur du côté de Firebase. Et comme parfois avec Google, aucune information de débogage. Seul un laconique « Impossible de valider le domaine » est présent dans l’interface.

N’ayant pas accès aux interfaces de gestion du domaine, j’ai donc cherché à consulter le contenu de la zone DNS d’une autre manière et je me suis donc tourné vers nslookup. Avec en particulier les commandes telles que :

nslookup <domaine>
nslookup -type=txt <domaine>
nslookup -type=cname <domaine>

L’exécution de ces commandes, avec quelques variations pour vérifier différents sous-domaines, m’a permis de constater que les entrées configurées ne figurent pas dans la zone DNS, bien que présent dans l’interface. Je postule donc que la nouvelle zone DNS est sauvegardée, mais non publiée. Les vérifications sont en cours pour vérifier cette hypothèse. Si ce n’est pas le cas, la recherche continuera, et j’aurais au moins découvert un outil bien pratique, faute d’avoir trouvé l’élément bloquant.

Ajout du champ Certification Authority Authorization (CAA) à la zone DNS

Je m’étais intéressé il y a de cela plusieurs semaines aux entêtes de sécurité du protocole http et j’en avais également profité pour regarder du côté de la zone DNS. Je m’étais donc occupé d’ajouter un champ CAA, pour Certification Authority Authorisation à la zone DNS de mon domaine.

Quelques mots sur le champ en question. Le but est d’indiquer publiquement quelles autorités de certification sont aptes à générer un certificat pour le domaine concerné (zéro, une ou plusieurs). Si une tentative de génération d’un certificat devait être tenté par une autre autorité, celle-ci devrait échouer car ne figurant pas comme autorité autorisée. A condition bien sûr que l’autorité de certification prenne en compte le champ CAA et le respecte. L’objectif étant de réduire le risque que quelqu’un demande et obtienne un certificat pour votre domaine sans y être autorisé.

Pour la mise en place sur unicoda.com, cela nous donne la configuration suivante :

Trois paramètres possibles: issue, issuewild et iodef. Dans l’ordre, issue restreint la génération des certificats pour le domaine, issuewild restreint la génération de certificat « wildcard » (et ignore tout autre champ comportant issue). Enfin, iodef permet de spécifier un moyen de communication (mailto, http ou https) pour signaler une violation du champ CAA.

Pour davantage d’informations, rien de mieux que d’aller lire directement la RFC : RFC 6844. On peut également consulter les explications de Let’s Encrypt.