Recherche d'enregistrement DNS
Chaque enregistrement publié par un domaine, avec ce qu'il implique concernant son courrier et ses certificats.
Les enregistrements, et à quoi ils servent réellement
| Type | Pointe vers | Se présente quand |
|---|---|---|
A | Une adresse IPv4 | Toujours. C’est lui qui fait charger un domaine. |
AAAA | Une adresse IPv6 | De plus en plus. Les réseaux mobiles sont fréquemment en IPv6 seul. |
CNAME | Un autre nom | Faire pointer www vers l’apex, ou un sous-domaine vers un prestataire SaaS. |
MX | Un serveur de messagerie, avec une priorité | Le courrier n’arrive pas. Le plus petit numéro de priorité l’emporte. |
NS | Les serveurs de noms faisant autorité sur la zone | Vous avez changé de prestataire et voulez savoir de qui vient la réponse. |
TXT | Du texte libre | SPF, DKIM, DMARC et tous les jetons de validation de domaine que vous avez collés un jour. |
SOA | Les métadonnées et les minuteries de la zone | Déboguer la réplication entre serveurs de noms. |
CAA | Les autorités de certification autorisées | Restreindre qui peut émettre des certificats pour vous. |
« Propagation » est le mauvais mot
C’est la chose la plus utile à comprendre au sujet du DNS, car elle transforme une attente imprévisible en un nombre que vous maîtrisez.
Rien ne se propage. Aucun envoi, aucune diffusion, aucune vague de mises à jour ne déferle sur Internet. Votre serveur de noms détient la nouvelle valeur à l’instant où vous l’enregistrez. Ce qui prend du temps, c’est que chaque résolveur du monde conserve une copie en cache de l’ancienne réponse, et la gardera jusqu’à l’expiration du TTL qui lui a été communiqué.
Le délai n’a donc rien de mystérieux : c’est précisément le TTL publié lors de la dernière interrogation de chaque résolveur. Si votre enregistrement avait un TTL de 3 600 secondes, certains résolveurs redemanderont dans cinq minutes et d’autres dans une heure — d’où l’impression qu’un changement atteint les gens de façon inégale.
D’où la marche à suivre pour tout changement planifié :
- Un jour avant, abaissez le TTL à 300 secondes. Attendez que l’ancien TTL expire, afin que tout le monde ait récupéré le court.
- Faites le changement. Il prend désormais cinq minutes au lieu d’une journée.
- Une fois les choses stabilisées, remontez le TTL.
La raison de le remonter : un TTL bas signifie plus de requêtes, plus de latence en cas d’échec de cache, et une panne plus dure si vos serveurs de noms deviennent injoignables — personne n’a alors de réponse en cache utilisable sur laquelle se rabattre.
Les enregistrements de messagerie, là où se trouvent la plupart des problèmes
Trois enregistrements TXT décident si l’on croit votre courrier. Ils sont fréquemment mal configurés et l’échec est silencieux : le message part en indésirable plutôt que d’être rejeté, donc personne ne vous prévient.
SPF
Il énumère les serveurs autorisés à envoyer du courrier pour votre domaine. Les erreurs, par ordre de fréquence :
- Deux enregistrements SPF. Le RFC 7208 impose aux destinataires de traiter cela comme une erreur permanente : le contrôle échoue donc entièrement. Fusionnez-les en un seul.
- Plus de dix requêtes DNS. Chaque
include:compte, et les include s’imbriquent. Un prestataire de messagerie, plus une plateforme marketing, plus un outil de support, et vous y êtes déjà — et dépasser la limite fait échouer le contrôle. - Se terminer par `~all` ou `?all`. Les deux signifient « probablement pas nous, mais faites comme vous voulez ». Seul
-alldemande aux destinataires de rejeter.
DKIM et DMARC
DKIM signe chaque message avec une clé dont la moitié publique vit dans un enregistrement TXT sous un nom de sélecteur tel que selector1._domainkey.example.com — il faut connaître le sélecteur pour l’interroger, et c’est pourquoi il ne figure pas dans la requête par défaut ci-dessus. DMARC vit à _dmarc.example.com et indique aux destinataires quoi faire quand SPF et DKIM divergent, ainsi que l’adresse où envoyer les rapports.
Interrogez _dmarc.votredomaine.com dans l’outil ci-dessus. Si rien ne revient, les destinataires n’ont aucune instruction et appliqueront leur propre jugement à tout ce qui usurpe votre domaine.
La règle du CNAME à l’apex
Un CNAME ne peut coexister avec aucun autre enregistrement portant le même nom. L’apex d’un domaine doit posséder des enregistrements SOA et NS : il ne peut donc pas avoir de CNAME — d’où la difficulté de faire pointer example.com vers un prestataire SaaS, là où www.example.com est trivial.
Les contournements dépendent du prestataire : ALIAS, ANAME ou aplatissement de CNAME, qui résolvent tous la cible côté serveur et répondent par un enregistrement A. Ils fonctionnent, ils ne sont pas normalisés, et mieux vaut les connaître avant d’y passer un après-midi.
À voir aussi
Une fois que les enregistrements pointent là où vous vouliez, vérifiez le certificat que l’hôte présente réellement et les en-têtes qu’il renvoie. Pour savoir quel réseau possède l’adresse visée par un enregistrement, c’est la consultation d’ASN qui répond.
Questions sur le DNS
J'ai modifié un enregistrement et l'ancienne valeur s'affiche toujours. Pourquoi?
Mise en cache, sur plusieurs couches. Chaque enregistrement a une durée de vie indiquant la durée pendant laquelle les résolveurs peuvent le conserver, et jusqu'à son expiration, vous continuerez à voir l'ancienne réponse, indépendamment de ce que dit maintenant le serveur faisant autorité. En plus de cela, votre système d'exploitation et le cache de votre navigateur. La recherche ici est effectuée vers un résolveur plutôt que directement vers le serveur de noms faisant autorité, elle voit donc également les valeurs mises en cache. Pour vérifier ce qui est réellement publié, interrogez directement le serveur de noms du domaine : dig @ns1.example.com example.com A.
Combien de temps prend la propagation DNS ?
Il n’y a pas de propagation – ce cadrage est la source de la confusion. Rien n'est poussé nulle part. Les résolveurs conservent simplement leur copie en cache jusqu'à ce que sa durée de vie expire, puis demandent à nouveau, de sorte que le délai que vous rencontrez est exactement la durée de vie qui a été publiée lors de leur dernière demande. Réduisez la durée de vie un jour avant un changement prévu et le changement prend quelques minutes au lieu de plusieurs heures ; oubliez cela, et un TTL de 24 heures signifie une journée pendant laquelle certains visiteurs voient l'ancienne valeur.
Qu’est-ce qu’un dossier CAA et en ai-je besoin ?
Il répertorie les autorités de certification autorisées à émettre des certificats pour votre domaine, et les autorités de certification sont tenues de les vérifier avant de les émettre. Sans cela, n'importe quelle autorité de certification publique dans le monde peut émettre pour votre domaine. Ainsi, un attaquant qui compromet un processus de validation auprès d'une centaine d'autorités de certification obtient un certificat valide. Avec un, la surface d'attaque est constituée des autorités de certification que vous avez nommées. C'est une ligne et elle mérite d'être ajoutée.
Pourquoi mon enregistrement SPF échoue-t-il même s'il semble correct ?
Trois causes courantes. Deux enregistrements SPF sur le même domaine constituent une erreur permanente selon la RFC 7208 et échouent à toute la vérification : publiez-en exactement un. Le dépassement de dix recherches DNS (chacune incluant : compte et inclut le nid) échoue également ; cette limite est plus facile à atteindre qu’il n’y paraît une fois que vous disposez d’un fournisseur de messagerie, d’un outil marketing et d’un service d’assistance. Et se terminant par ~all ou ?all ne fait que conseiller les destinataires plutôt que de leur donner des instructions, donc le courrier provenant d'autres hôtes est souvent distribué de toute façon.
Quelle est la différence entre un enregistrement A et un CNAME ?
Un enregistrement A pointe un nom directement vers une adresse IPv4. Un CNAME pointe un nom vers un autre nom, qui doit ensuite être résolu à son tour. La règle qui retient les gens est qu'un CNAME ne peut coexister avec aucun autre enregistrement portant le même nom — ce qui signifie que le sommet d'un domaine, qui doit avoir des enregistrements SOA et NS, ne peut pas avoir de CNAME. Les fournisseurs contournent ce problème avec des enregistrements ALIAS ou ANAME qui se comportent comme un CNAME au sommet mais sont résolus côté serveur.
Quel résolveur cela utilise-t-il ?
Celui de notre serveur, délibérément. L'interrogation d'un résolveur public fixe tel que 8.8.8.8 rapporterait ce que Google voit plutôt que ce qu'un client ordinaire voit, et les deux diffèrent plus souvent que vous ne le souhaiteriez : les réponses géographiquement divisées, le DNS à horizon partagé et le filtrage au niveau du résolveur produisent tous cet écart.
DNS is also the part of your own browsing that is most often unencrypted. Which resolver answers your queries determines who can see every domain you visit, whatever else is encrypted. Test which resolver you are really using
Dernière vérification . Vous avez repéré quelque chose de dépassé ? Dites-le-nous.