DNS pour un domaine personnalisé : préparer les enregistrements

1. Trouver les réglages DNS réellement utilisés

Le bureau d’enregistrement gère l’enregistrement du domaine. Le fournisseur DNS faisant autorité fournit ses enregistrements de référence. Ces rôles peuvent relever de comptes différents. Les instructions de DreamHost, par exemple, ne s’appliquent que si les serveurs de noms du domaine pointent vers DreamHost. Un compte d’enregistrement chez ce fournisseur ne suffit pas.[1][2]

Avant toute modification, confirmez les serveurs de noms actuels et le compte qui gère leur zone DNS. Si une autre personne s’occupe du domaine, demandez-lui d’identifier ce compte et le changement prévu. Ne remplacez pas les serveurs de noms simplement pour utiliser un éditeur plus pratique. Ce serait un changement plus large, nécessitant de revoir les services qui utilisent déjà le domaine.

2. Comprendre le type avant de copier la valeur

Ce sont des fonctions distinctes, pas cinq enregistrements obligatoires pour chaque site. Ajoutez uniquement les types demandés. Un TXT de vérification n’envoie pas lui-même les visiteurs vers une page ; modifier un MX ne publie pas un site.[1]

Demandez comment sont traités le domaine sans sous-domaine et les sous-domaines voulus. Les CNAME ordinaires ont des restrictions, notamment les conflits avec d’autres enregistrements au même nom. Certains fournisseurs proposent des mécanismes particuliers pour le domaine de base. Ne présumez pas qu’ils existent partout et ne les substituez pas sans instructions.[1]

3. Préparer une fiche avant d’enregistrer

Les interfaces DNS n’interprètent pas toutes le champ du nom de la même façon. Elles peuvent attendre un libellé court, un nom complet ou une représentation particulière du domaine de base. Suivez leur documentation pour éviter que le domaine soit ajouté deux fois. Les conventions de DreamHost décrivent sa propre interface, pas celle de tous les services.[1]

4. Délimiter le changement avec un exemple hypothétique

Supposons que example.com possède déjà un site principal et une messagerie opérationnelle. L’organisateur veut utiliser tickets.example.com pour une page d’événement. Il vérifie d’abord que le service choisi accepte ce nom d’hôte, puis obtient ses véritables instructions de routage et de vérification. Il inscrit chaque modification dans la fiche. Aucun exemple de destination n’est fourni pour être copié dans un compte réel.

L’objectif est de raccorder tickets.example.com, pas de remplacer toute la configuration du domaine. Examinez les enregistrements de ce nom et conservez les autres réglages web et de messagerie. Si le service demande plutôt un changement de serveurs de noms ou le domaine de base, suspendez l’intervention limitée et préparez un plan pour préserver les autres services.

5. Préserver la messagerie et documenter le changement

Les MX orientent la distribution des courriels. Les TXT peuvent contenir des vérifications ou des informations liées à la messagerie. Un raccordement web mérite donc une vérification du courrier, même sans migration de celui-ci. Conservez une copie de la configuration existante et identifiez les enregistrements à maintenir.[1]

Si vous ignorez la fonction d’une valeur, interrogez son responsable avant de la remplacer. Le but n’est pas une zone DNS visuellement plus propre, mais le maintien de l’accès à chaque service prévu.

6. Vérifier séparément le DNS, la page et HTTPS

Les réponses DNS peuvent être mises en cache. Différents appareils peuvent voir une modification à des moments différents, selon les informations mémorisées et leur renouvellement. Le TTL participe à ce fonctionnement, sans garantir que le site sera accessible partout après un délai fixe.[2][1]

Confiez la fiche à la personne qui maintient le domaine. Elle documentera le changement et servira de point de départ au prochain événement, sans transformer cet exemple en recette de configuration propre à une plateforme.