Un enregistrement A sert à relier un nom de domaine à une adresse IPv4, et c’est souvent lui qui détermine si un site, une API ou un environnement de préproduction pointe au bon endroit. En DevOps, ce réglage paraît banal, mais il influence directement les déploiements, les bascules de trafic, la propagation des changements et le dépannage. Je vais expliquer ici comment il fonctionne, quand l’utiliser, où il échoue le plus souvent et comment l’automatiser proprement.
Les points clés à garder en tête avant de modifier un enregistrement A
- Un enregistrement A associe un nom d’hôte à une adresse IPv4, pas à un serveur “en général”.
- La modification n’est jamais instantanée partout à cause des caches DNS et du TTL.
- Plusieurs enregistrements A peuvent répartir le trafic, mais ce n’est pas un vrai mécanisme de haute disponibilité.
- Le choix entre A, AAAA, CNAME et alias dépend surtout de l’emplacement du nom, de l’IPv4/IPv6 et du fournisseur DNS.
- En production, les erreurs les plus coûteuses viennent souvent d’un mauvais TTL, d’un mauvais nom de zone ou d’un oubli de validation.
- En DevOps, le DNS doit être versionné, testé et déployé comme le reste de l’infrastructure.
Ce que fait vraiment un enregistrement A
Dans sa forme la plus simple, un enregistrement A dit au résolveur DNS qu’un nom précis correspond à une adresse IPv4 précise. C’est le mécanisme qui permet à www.exemple.fr, api.exemple.fr ou staging.exemple.fr de pointer vers une machine, un équilibreur de charge ou un service exposé sur Internet.
Je le vois souvent comme la couche de traduction la plus directe du DNS. Le nom est lisible par un humain, l’adresse IPv4 est exploitable par le réseau. Cette traduction reste indispensable, même si l’on parle beaucoup de conteneurs, de service discovery et d’orchestration : dès qu’un client externe doit joindre votre service, il faut bien une adresse résoluble quelque part.
Il faut aussi distinguer le cas où le nom pointe vers une IP fixe et celui où il pointe vers une infrastructure qui change. Un serveur physique ou une VM avec IP réservée supporte bien un A record classique. En revanche, un service derrière un load balancer ou une plateforme managée demande parfois une autre approche, surtout quand l’adresse n’est pas stable.
Cette distinction devient plus claire quand on regarde le chemin complet de la résolution DNS, du résolveur jusqu’au serveur ciblé.
Comment la résolution se déroule entre le client et l’adresse IPv4
Quand un navigateur, un outil de supervision ou un déploiement essaie d’atteindre un nom de domaine, il ne contacte pas directement votre serveur. Il interroge d’abord un résolveur récursif, qui vérifie si la réponse est déjà en cache. Si ce n’est pas le cas, le résolveur remonte l’arborescence DNS jusqu’à obtenir la réponse finale, puis la conserve pendant la durée indiquée par le TTL (time to live), c’est-à-dire le temps de vie du cache.
C’est là que beaucoup d’équipes se trompent : changer une IP dans la zone DNS ne signifie pas que tout le monde verra la nouvelle valeur immédiatement. En pratique, la propagation dépend des caches intermédiaires, des politiques des fournisseurs DNS et du comportement du résolveur côté client. Pour une migration, je pars souvent sur un TTL de 300 à 3600 secondes selon le niveau de risque et la fréquence de changement. Un TTL trop bas augmente le volume de requêtes DNS ; un TTL trop haut ralentit les bascules.
Quand plusieurs enregistrements A existent pour le même nom, le résolveur peut renvoyer plusieurs adresses IPv4. Le but est parfois de répartir la charge, mais il faut rester lucide : ce n’est pas un load balancer intelligent. Il n’y a pas forcément de vérification de santé, et le comportement final dépend aussi du client et du cache local.
Pour vérifier ce que retourne réellement le DNS, je conseille de tester depuis plusieurs points de vue :
dig www.exemple.fr A +short
nslookup www.exemple.fr
dig www.exemple.fr A @1.1.1.1
dig www.exemple.fr A @8.8.8.8Ces commandes montrent vite la différence entre ce que vous avez configuré et ce qu’un client voit réellement. Une fois ce mécanisme compris, on peut configurer le record sans improviser.
Configurer un enregistrement A proprement en production
La configuration elle-même est simple, mais elle mérite de la rigueur. Je vérifie toujours quatre éléments avant de valider un changement : le nom exact, la zone DNS, l’adresse IPv4 cible et le TTL. Sur le papier, cela semble trivial ; en production, un suffixe oublié ou une zone mal choisie suffit à rendre le service inaccessible.
Pour un sous-domaine comme api.exemple.fr, le record A pointe généralement vers une IPv4 unique. Pour le domaine racine, comme exemple.fr, c’est là qu’apparaissent les contraintes les plus fréquentes. Tous les fournisseurs ne traitent pas le “naked domain” de la même manière, et certains cas exigent un mécanisme d’alias plutôt qu’un A classique si la cible n’est pas une IP fixe.
Voici la logique que j’applique le plus souvent :
- Nom court et explicite pour savoir immédiatement à quoi sert le record.
- IP stable quand le service est censé rester joignable sans intervention fréquente.
- TTL adapté au niveau de volatilité du service.
- Validation après changement avec un test DNS et un test applicatif.
Quand je veux sécuriser l’opération, j’ajoute aussi une règle simple : si l’adresse change souvent, le DNS ne doit pas être géré “à la main” dans l’interface web du fournisseur. Il doit passer par l’infrastructure as code, comme le reste du système.
Cette rigueur devient encore plus utile quand il faut choisir entre plusieurs types d’enregistrements proches.
Choisir entre A, AAAA, CNAME et alias
Le bon choix ne dépend pas seulement du nom de domaine. Il dépend aussi du type d’adresse, de la position du record dans la zone et du niveau de contrôle que vous voulez garder sur l’infrastructure. Voici le tableau que je garde en tête quand je dois trancher rapidement :
| Type | Ce qu’il pointe | Utilisation idéale | Limite principale |
|---|---|---|---|
| A | Adresse IPv4 | Serveur, VM, load balancer avec IPv4 stable | Ne gère pas l’IPv6 |
| AAAA | Adresse IPv6 | Services accessibles nativement en IPv6 | Ne remplace pas l’IPv4 si vos clients n’ont pas de connectivité IPv6 |
| CNAME | Un autre nom DNS | Alias de sous-domaine, délégation simple | Ne s’utilise pas au sommet de zone dans la plupart des cas |
| Alias / ANAME | Une cible virtuelle ou un nom résolu par le fournisseur | Racine de zone vers un service dynamique ou managé | Comportement dépendant du fournisseur DNS |
Je résume souvent ainsi : A si vous avez une IPv4 claire et stable, AAAA si vous exposez aussi de l’IPv6, CNAME si vous voulez un alias sur un sous-domaine, et alias si vous devez résoudre proprement un domaine racine sans IP figée. Ce dernier point est important, parce qu’on voit encore beaucoup d’équipes tenter de forcer un CNAME là où le modèle DNS ne s’y prête pas.
Le bon réflexe n’est donc pas de “choisir le record le plus courant”, mais celui qui colle à la topologie réelle du service. Et c’est précisément là que les erreurs de production apparaissent.
Les erreurs qui font perdre du temps en production
La première erreur, très classique, consiste à croire qu’un changement d’IP dans la zone DNS suffit à basculer tout le trafic immédiatement. En réalité, un cache peut continuer à servir l’ancienne adresse pendant un certain temps, surtout si le TTL a été élevé. Si vous préparez une migration, ce délai doit faire partie du plan, pas être découvert en urgence.
La deuxième erreur, c’est le faux sentiment de sécurité offert par plusieurs enregistrements A. Beaucoup d’équipes pensent qu’ajouter deux IP va automatiquement créer de la redondance. En pratique, sans santé active, sans mécanisme de retrait et sans stratégie de failover, vous obtenez surtout un routage imprévisible.
La troisième erreur concerne les zones publique et privée. J’ai déjà vu des équipes mettre à jour le bon record dans la mauvaise zone, puis chercher pendant une heure pourquoi l’application interne ne résolvait pas la bonne IP. Le symptôme est trompeur, parce que la résolution fonctionne “quelque part”, mais pas au bon endroit.
Voici les pièges que je surveille en priorité :
- TTL trop long avant une migration.
- Nom de zone ou sous-domaine mal saisi.
- Confusion entre DNS public et DNS privé.
- Utilisation d’un A record comme mécanisme de haute disponibilité sans supervision.
- Oubli du contrôle inverse pour des services sensibles comme le mail.
Pour éviter ces pièges, il ne suffit pas de comprendre le DNS ; il faut aussi industrialiser les changements.
Automatiser les changements DNS dans une chaîne DevOps
En DevOps, je traite le DNS comme une ressource d’infrastructure à part entière. Cela veut dire qu’un enregistrement A ne devrait pas dépendre d’un clic manuel isolé, mais d’un fichier de configuration, d’un plan de déploiement ou d’un contrôleur automatique. Cette approche réduit les écarts entre l’environnement attendu et l’environnement réel.
Le schéma le plus robuste ressemble souvent à ceci :
- Déclarer le record dans l’infrastructure as code.
- Valider la syntaxe et les variables avant l’application.
- Appliquer le changement dans un environnement de test ou de préproduction.
- Vérifier la résolution avec
digounslookupdepuis plusieurs résolveurs. - Promouvoir en production avec un TTL temporairement réduit si une migration est prévue.
Dans des environnements Kubernetes ou cloud managé, je préfère souvent que la source de vérité soit un objet applicatif ou un manifest, puis qu’un contrôleur mette à jour le DNS de façon déclarative. Cela évite les décalages entre l’état du cluster et l’état des zones DNS. En contrepartie, il faut surveiller les droits d’accès, les délais de réconciliation et les éventuelles limites de l’API du fournisseur.
Voici le point de discipline que je trouve le plus utile : après chaque modification DNS importante, je vérifie à la fois la réponse DNS et le comportement applicatif. Un enregistrement peut être techniquement correct et malgré tout pointer vers un service mal configuré, un load balancer fermé ou une IP qui ne répond plus.
Cette logique d’automatisation ferme bien la boucle, mais il reste un dernier point pratique à garder en tête avant de toucher une adresse IPv4 en production.
Ce qu’il faut garder en tête avant de faire évoluer l’adresse d’un service
Un enregistrement A n’est pas complexe, mais il devient stratégique dès qu’un service prend de l’importance. Plus le trafic est critique, plus le DNS doit être traité avec méthode : plan de bascule, TTL ajusté, tests de résolution, vérification des zones et retour arrière clair si quelque chose ne se passe pas comme prévu.
Si je devais retenir une règle simple, ce serait celle-ci : un bon record A ne se contente pas de “pointer vers une IP”. Il s’inscrit dans une chaîne complète qui relie l’infra, le déploiement et l’exploitation. C’est pour cela que les équipes les plus solides ne gèrent pas le DNS à part du reste du système, mais comme une pièce normale de leur livraison logicielle.
Quand l’IPv4 devient trop statique pour votre architecture, ou quand le service doit être exposé différemment selon l’environnement, ce n’est plus le record lui-même qu’il faut “optimiser” ; c’est la stratégie de résolution autour de lui. Et c’est souvent là que se joue la différence entre un changement fluide et une interruption évitable.
