Connecter un domaine : enregistrements DNS TXT, CNAME et l'attente
Tous les hébergeurs de la planète vous demandent le même petit rituel un peu mystérieux avant que votre propre domaine ne fonctionne : connectez-vous là où vous avez enregistré le domaine, trouvez un écran appelé quelque chose comme gestion DNS ou DNS avancé, et collez-y deux ou trois enregistrements que personne ne vous a vraiment expliqués. Cliquez sur enregistrer. Cliquez sur vérifier. On vous répond que ce n'est pas encore prêt. Attendez. Recommencez.
Les deux enregistrements, et pourquoi chacun existe
Un nom de domaine est en réalité une entrée dans un fichier de zone, et un enregistrement DNS en est une ligne : un nom, un type, une valeur. Connecter un domaine à un nouvel hébergeur signifie normalement en ajouter deux.
L'enregistrement de propriété (TXT) — une courte valeur texte générée par votre hébergeur, publiée sur votre domaine uniquement pour que l'hébergeur puisse la consulter et savoir que vous contrôlez le DNS. Les visiteurs ne la voient jamais, et elle ne route rien.
L'enregistrement de routage (CNAME) — dirige le trafic du domaine vers l'edge de l'hébergeur. Une fois qu'il se résout, les requêtes pour votre domaine arrivent sur des serveurs qui savent quel site servir pour lui.
Pourquoi cela n'a pas encore fonctionné
Que « Vérifier » échoue au premier clic est normal. Les réponses DNS sont mises en cache de façon agressive — c'est ce cache qui fait que le reste du web est rapide — donc un résolveur qui a répondu pour votre domaine il y a cinq minutes peut continuer à servir l'ancienne réponse, vide, pendant quelques minutes ou, avec un TTL long, presque une journée entière. Rien n'est cassé. Il n'y a rien à réparer, à part de la patience et une nouvelle vérification.
La subtilité du domaine racine (un domaine sans « www »)
Connecter un domaine nu —
yourbusiness.com, sans www — se heurte à une véritable règle DNS, pas à une bizarrerie propre à un hébergeur : un CNAME ne peut pas coexister avec les enregistrements SOA et NS qui doivent obligatoirement se trouver à la racine d'un domaine, donc de nombreux registraires refusent tout simplement d'en créer un à cet endroit. Les solutions habituelles sont un enregistrement ALIAS/ANAME là où le registraire en propose un, ou la connexion d'un sous-domaine avec redirection de l'apex vers celui-ci.Connecter un domaine, dans l'ordre
1
Trouvez vos paramètres DNS
Connectez-vous là où vous gérez le DNS du domaine — c'est-à-dire chez votre bureau d'enregistrement, sauf si vous avez pointé les serveurs de noms du domaine ailleurs, auquel cas c'est chez celui qui les héberge.
2
Ajoutez l'enregistrement de propriété
Collez l'enregistrement TXT exactement tel qu'il est affiché, valeur comprise. Enregistrez avant de continuer — certains panneaux exigent une étape distincte et explicite pour publier réellement une modification en attente.
3
Ajoutez l'enregistrement de routage
Ajoutez l'enregistrement CNAME — ou, sur un apex nu qui le refuse, un enregistrement ALIAS/ANAME, ou une redirection vers un sous-domaine que vous connectez à la place.
4
Vérifiez, puis patientez s'il le faut
Cliquez sur vérifier. Un résultat « pas encore » au premier essai est normal — revérifiez après quelques minutes, puis de nouveau plus tard si votre configuration DNS précédente utilisait un TTL long.
Comment Olmira gère cela
Ajouter un domaine dans les paramètres de site d'Olmira génère les deux enregistrements pour vous, littéralement — le TXT sous un nom commençant par _aether-verify (un vestige du nom de code interne de la plateforme ; seule la valeur compte) et le CNAME pointant vers edge.olmira.app. La vérification effectue un vrai contrôle DNS en direct avec un court délai d'attente, donc « pas encore vérifié » signifie presque toujours une propagation en cours, pas une erreur — attendez quelques minutes et revérifiez, plutôt que d'ouvrir un ticket de support.
Un apex nu dont le routage ne se résout pas bascule automatiquement vers une redirection vers un sous-domaine vérifié du même site — ou, à défaut, vers votre adresse gratuite — plutôt que d'afficher une erreur. Une fois la vérification réussie, le HTTPS suit tout seul : aucun certificat à acheter ou installer. Ce que chaque forfait inclut : domaines personnalisés.
À lire aussi
Certificat HTTPS automatique : pourquoi vous n'aurez plus jamais besoin d'en acheter un — ce qui se passe réellement au moment où votre domaine est vérifié.
Configuration SPF, DKIM, DMARC : des e-mails qui arrivent dans la boîte de réception — les autres enregistrements de votre domaine : ceux qui déterminent si l'e-mail de votre entreprise arrive dans une boîte de réception.
Combien de temps, en secondes, une réponse DNS peut être mise en cache avant que quiconque doive la redemander. Un TTL faible (300 secondes, par exemple) fait apparaître les changements rapidement ; un TTL élevé (86 400 secondes, soit une journée entière) les fait tarder, car les résolveurs continuent de servir l'ancienne réponse en toute confiance.
Non, si vous ne touchez qu'à ce qu'on vous demande. Connecter un domaine à un hébergeur de sites ne requiert jamais qu'un TXT et un CNAME (ou un enregistrement ALIAS/A sur un domaine racine nu) : vos enregistrements MX, qui déterminent où va le courrier, sont distincts et restent intacts, sauf si vous les modifiez vous-même.
Oui, et cela contourne entièrement la subtilité du domaine racine — shop.yourbusiness.com ou www.yourbusiness.com peuvent recevoir un CNAME sans traitement particulier.
Presque toujours un TTL long hérité de ce qui occupait ce nom auparavant — une page de domaine parqué chez votre bureau d'enregistrement, ou un hébergeur précédent. La seule solution, la première fois, c'est la patience ; une fois l'ancien TTL expiré, les changements ultérieurs sur ce nom se propagent beaucoup plus vite.
Non — les enregistrements DNS n'expirent pas d'eux-mêmes comme le font les certificats. Une fois publiés correctement, ils restent corrects jusqu'à ce que vous, ou quelqu'un ayant accès au panneau DNS, les modifiiez.