DNS managé : zones, records, failover et routage intelligent

Le DNS est le seul composant de votre infrastructure dont une erreur met des heures à se corriger, quoi que vous fassiez. Partout ailleurs, un mauvais réglage se répare et l'effet est immédiat. Ici, des caches que vous ne contrôlez pas continuent de servir l'ancienne valeur jusqu'à expiration. Cette page explique comment tenir une zone, préparer une bascule sans coupure, et pourquoi la redondance du DNS est la première à mettre en place.

Ce que vous allez apprendre

• Tenir une zone DNS et choisir le bon type d'enregistrement.
• Régler les durées de vie pour pouvoir basculer sans attendre un jour.
• Préparer une migration en trois temps, sans coupure visible.
• Comprendre ce qu'un basculement automatique peut faire, et ce qu'il ne peut pas.
• Éviter la panne DNS qui rend tout le reste inutile.

Prérequis

La leçon sur l'adressage et la résolution de noms, dont cette page reprend les notions de TTL et de types d'enregistrements.

La zone, et qui fait autorité

Une zone DNS est l'ensemble des enregistrements d'un domaine, tenus par des serveurs qui « font autorité » sur lui. Faire autorité signifie que leur réponse est la vérité, par opposition aux résolveurs qui ne font que relayer et mettre en cache.

Le point le plus important tient dans la délégation : votre registraire, celui chez qui vous avez acheté le domaine, indique quels serveurs font autorité. Tant que cette délégation pointe ailleurs, la plus belle zone du monde ne sera jamais consultée.

dig +short NS stephane-robert.info

Cette commande répond par les serveurs qui font autorité. Si vous venez de migrer votre DNS et que la réponse cite encore l'ancien hébergeur, vous tenez l'explication de ce qui « ne prend pas ».

Les enregistrements, et les deux pièges

Les types courants ont été vus dans la première leçon. Deux d'entre eux méritent un avertissement, parce qu'ils causent des pannes régulières.

Un CNAME ne peut pas cohabiter avec un autre enregistrement sur le même nom. C'est une règle du protocole, pas une limitation de fournisseur. La conséquence pratique est bien connue : vous ne pouvez pas mettre un CNAME sur la racine d'un domaine, exemple.fr, parce que celle-ci porte déjà des enregistrements NS et généralement MX.

C'est exactement le cas quand on veut faire pointer un domaine racine vers un répartiteur de charge, qui n'a qu'un nom. Les fournisseurs ont inventé pour cela des enregistrements non standards, souvent appelés ALIAS ou ANAME, qui se comportent comme un CNAME mais restent compatibles avec la racine. Si votre hébergeur DNS n'en propose pas, vous devrez résoudre l'adresse vous-même et tenir un enregistrement A, avec le risque qu'elle change.

Un enregistrement MX pointe vers un nom, jamais vers une adresse. Écrire une adresse IP dans un MX produit une configuration qui semble valide et que beaucoup de serveurs de messagerie refusent.

Les durées de vie, et la bascule en trois temps

Le TTL décide du temps que met un changement à se propager, et il se règle avant, pas pendant. C'est la seule contrainte de cette page qui ne se rattrape pas : une fois qu'un cache a mémorisé une valeur avec un TTL d'un jour, personne ne peut le forcer à l'oublier.

D'où la méthode en trois temps, qui est la bonne pratique du métier.

1. La veille, abaisser le TTL

   Passez l'enregistrement concerné à 300 secondes, et attendez au moins la durée de l'ancien TTL avant de continuer. Si l'ancien TTL était de 24 heures, il faut attendre 24 heures : c'est le temps que mettent les caches à apprendre la nouvelle valeur courte.

   dig +noall +answer www.exemple.fr

   Attendez que la valeur affichée soit bien tombée à 300.

2. Le jour J, changer la valeur

   Modifiez l'enregistrement. Grâce au TTL court, la propagation prend cinq minutes au lieu d'un jour, et un retour en arrière est tout aussi rapide.

3. Après validation, remonter le TTL

   Une fois la bascule confirmée, repassez à 3600 secondes ou plus. Un TTL court en permanence multiplie les requêtes vers vos serveurs et rallonge légèrement chaque première visite.

« La propagation DNS prend 48 heures » est une légende commode

Cette phrase, qu'on entend chez beaucoup d'hébergeurs, mélange deux choses.

Il n'existe pas de propagation au sens d'une diffusion : vos serveurs faisant autorité répondent la nouvelle valeur immédiatement. Ce qui prend du temps, c'est l'expiration des caches, et le TTL que vous avez posé en donne l'ordre de grandeur.

L'ordre de grandeur, et pas la durée exacte, car plusieurs acteurs s'intercalent : certains résolveurs appliquent un TTL minimum ou maximum qui leur est propre, le cache négatif fait persister une réponse « ce nom n'existe pas », et au-delà du résolveur il reste le cache du système, celui du navigateur et celui de l'application. Un changement de serveurs faisant autorité au niveau du registre suit encore d'autres délais, propres à l'extension du domaine.

Retenez donc l'essentiel : si l'on vous annonce 48 heures, c'est d'abord que votre TTL valait 48 heures, et cela, vous le maîtrisez.

Le basculement automatique, et sa limite

Certains services DNS surveillent une adresse et retirent l'enregistrement quand elle ne répond plus. C'est séduisant, et il faut comprendre ce que cela couvre réellement.

Cela fonctionne bien pour une bascule entre deux sites entiers, par exemple d'une région vers une autre après une panne majeure. Le délai de détection s'ajoute au TTL, donc comptez au minimum quelques minutes avant que le changement soit vu partout.

Cela ne remplace pas un répartiteur de charge. Le DNS répartit à la granularité du nom et à la vitesse des caches ; un répartiteur travaille à la requête et réagit en secondes. Utilisez le DNS pour choisir un site, le répartiteur pour choisir un serveur.

Une limite plus subtile mérite d'être connue : certains clients ignorent le TTL et gardent une résolution en mémoire tant que le processus tourne. Beaucoup de bibliothèques applicatives et de machines virtuelles Java sont dans ce cas. Un basculement DNS ne les atteindra pas, et il faudra redémarrer le processus.

La panne qui rend tout le reste inutile

Quand le DNS tombe, toutes vos applications tombent, même si les serveurs vont parfaitement bien. C'est le composant dont la panne a l'effet le plus large, et c'est aussi celui que l'on redonde le moins.

Trois mesures, par ordre d'efficacité :

• Plusieurs serveurs faisant autorité, chez au moins deux opérateurs distincts. Tous les hébergeurs DNS sérieux en fournissent plusieurs, mais ils sont souvent sur la même infrastructure : la vraie redondance passe par deux fournisseurs.
• Un TTL qui n'est pas trop court. Contre-intuitif, mais un TTL long fait que les caches continuent de répondre pendant une panne de vos serveurs de noms. Un TTL de cinq minutes en permanence transforme une panne DNS de dix minutes en panne totale.
• Une surveillance du nom, pas seulement du serveur. Sondez la résolution depuis l'extérieur : c'est ce que vit un visiteur, et une zone supprimée par erreur ne se voit sur aucun tableau de bord d'infrastructure.

Vérifier une zone depuis l'extérieur

Interrogez directement un serveur faisant autorité, sans passer par votre résolveur ni par aucun cache. C'est le seul test qui dit ce que votre zone contient réellement.

dig @ns1.exemple-hebergeur.fr www.exemple.fr +noall +answer

Comparez avec la réponse obtenue par votre résolveur habituel : une différence signale un cache qui n'a pas encore expiré, pas une erreur de configuration.

À retenir

• La délégation prime sur tout : si le registraire ne pointe pas vers vos serveurs, votre zone n'est jamais lue.
• Un CNAME ne cohabite avec rien, donc pas sur la racine d'un domaine. Cherchez un enregistrement ALIAS ou ANAME chez votre hébergeur.
• Un MX pointe vers un nom, jamais vers une adresse.
• Baissez le TTL la veille, changez le jour J, remontez après validation. C'est la méthode de référence pour une bascule sans coupure.
• La « propagation de 48 heures » n'existe pas : c'est d'abord l'expiration de votre propre TTL, auquel s'ajoutent les caches que vous ne maîtrisez pas.
• Le basculement DNS choisit un site, un répartiteur choisit un serveur. Ils ne se remplacent pas.
• Certains clients ignorent le TTL et gardent leur résolution jusqu'au redémarrage.
• Redondez chez deux opérateurs. Le DNS est le composant dont la panne coupe tout le reste.

Prochaines étapes

IPv6 dans le cloud Le protocole que vos sous-réseaux activent parfois sans vous le dire.

Patrons d'architecture réseau Assembler tout ce parcours en architectures cohérentes.

Répartition de charge et TLS Ce vers quoi votre nom de domaine pointe, le plus souvent.

Disponibilité et durabilité Chiffrer ce qu'une bascule coûte en indisponibilité.

×

📖 Voir la documentation →