Chaînes CNAME DNS : quand elles deviennent un problème de performance et de fiabilité

Ce qu’est réellement une chaîne CNAME (et ce que ça coûte)

Un enregistrement CNAME indique : « ce nom est un alias pour cet autre nom. » Il ne dit pas où se trouve le service. Il dit qui sait où
se trouve le service.

Une chaîne CNAME se produit lorsque l’alias pointe vers un autre alias, qui pointe vers un autre alias, et ainsi de suite, jusqu’à ce que vous
atteigniez finalement un enregistrement d’adresse (A ou AAAA), ou une réponse terminale comme NXDOMAIN.

Sur un tableau blanc, une chaîne paraît inoffensive :

• api.example.com → CNAME api.edge.vendor.net
• api.edge.vendor.net → CNAME api.geo.vendor.net
• api.geo.vendor.net → A/AAAA 203.0.113.10 / 2001:db8::10

En production, le coût se paie en :

• Allers-retours supplémentaires (ou travail récursif supplémentaire à l’intérieur de votre résolveur) pour suivre chaque saut.
• Points de défaillance supplémentaires (plus de zones, plus de serveurs autoritatifs, plus d’arêtes TTL, plus de politiques, plus de pannes).
• Complexité de cache accrue (TTLs différents à chaque saut, comportement de cache incohérent selon les résolveurs).
• Plus d’accidents « ça marche sur mon laptop » (les résolveurs locaux, VPN, opérateurs mobiles se comportent tous différemment).

Il n’y a pas de « mauvais nombre » universel, mais en tant qu’opérateur je considère tout ce qui dépasse un saut CNAME comme une décision de gestion du risque.
Au-delà de deux sauts, je veux une justification, un propriétaire, et de la surveillance.

Blague n°1 : Une chaîne CNAME, c’est comme le renvoi d’appels au bureau — parfait jusqu’à ce que votre appel passe par trois assistants et que personne ne sache qui fait réellement le travail.

Comment la résolution se passe réellement (rapidement, mais correctement)

Avec un résolveur stub typique (votre hôte applicatif) et un résolveur récursif (votre DNS d’entreprise ou un résolveur public), le stub demande au récursif :
« qu’est-ce que api.example.com ? » Le résolveur récursif fait la chasse : il contacte les serveurs autoritatifs au besoin,
suit les CNAME, valide DNSSEC si activé, et renvoie les réponses A/AAAA finales (et inclut généralement la chaîne CNAME dans la réponse).

Si le cache du résolveur récursif est chaud et que tout tient dans les fenêtres TTL, vous paierez presque zéro temps supplémentaire. Si les caches sont froids,
ou que les TTL sont petits, ou que vous traversez des régions, ces sauts deviennent une vraie latence.

Le multiplicateur caché : réutilisation de connexion et ratés de cache DNS

Une seule recherche DNS importe peu. Ce qui compte, c’est combien vous en faites, à quelle fréquence vous ratez le cache, et sur quoi vous bloquez.
Les clients modernes ouvrent beaucoup de connexions (ou les réutilisent, idéalement). Quand les pools de connexions tournent — à cause de déploiements, d’autoscaling, de timeouts NAT,
ou de réinitialisations HTTP/2 — le DNS revient sur le chemin chaud.

C’est alors que les chaînes CNAME cessent d’être des « trivia DNS » et deviennent un facteur de disponibilité.

Pourquoi les chaînes CNAME nuisent à la performance et à la fiabilité

1) Latence : chaque saut ajoute des opportunités de réponses lentes

Un résolveur récursif peut devoir parler à plusieurs serveurs de noms autoritatifs répartis sur plusieurs domaines. Chaque saut peut impliquer :
un RTT réseau, des minuteries de retry, un basculement sur TCP (lorsque les réponses sont volumineuses), la validation DNSSEC, et une limitation de débit.
Si vous êtes malchanceux, vous rencontrerez aussi des pertes de paquets et des retransmissions — le DNS sur UDP est rapide jusqu’à ce qu’il ne le soit plus.

Le « saut supplémentaire » n’est pas toujours un RTT en plus, car un résolveur peut parfois récupérer plusieurs enregistrements efficacement. Mais en pratique, plus de sauts
signifie plus de dépendances externes et plus de chances de franchir une frontière de cache froid.

2) Inadéquation des TTL : la chaîne se met mal en cache

Chaque enregistrement de la chaîne a son propre TTL. Les résolveurs mettent en cache chaque RRset selon son TTL. Si vous avez :

• un TTL long au premier saut (votre zone),
• un TTL court au deuxième saut (zone du fournisseur),
• et un TTL moyen à l’enregistrement d’adresse,

…alors vous pouvez vous retrouver dans une situation où certains résolveurs conservent votre alias en cache tandis qu’ils rechargent constamment le saut suivant du fournisseur.
La chaîne devient un générateur périodique de misses de cache.

3) Rayon d’impact : plus de zones, plus de pannes

Avec un enregistrement A/AAAA direct dans votre zone, vos dépendances sont votre fournisseur DNS et vos serveurs autoritatifs. Avec une chaîne,
vous dépendez aussi des serveurs autoritatifs du fournisseur. Ajoutez un second fournisseur (CDN vers WAF vers GSLB), et vous avez essentiellement construit une petite chaîne d’approvisionnement.

Les chaînes d’approvisionnement tombent en panne.

4) Ambiguïté opérationnelle : le débogage devient une « archéologie DNS »

Lorsqu’un utilisateur signale des « timeouts intermittents », les ingénieurs vérifient d’abord l’appli. Puis le load balancer. Puis le pare-feu. Le DNS vient souvent en dernier,
car on le perçoit comme de la plomberie. Les chaînes CNAME rendent cette plomberie dynamique et multi-propriété. Vous ne déboguez pas juste votre config, mais le comportement
de vos fournisseurs, leur politique TTL, leurs pannes, et leur logique de routage.

5) Comportement spécifique aux résolveurs : la même chaîne peut agir différemment

Tous les résolveurs ne se comportent pas de manière identique. Les différences incluent :

• politiques d’éviction de cache et taille maximale du cache
• préfetching plus ou moins agressif
• limites sur la profondeur de chasse CNAME
• timeouts, stratégie de retry, et basculement UDP/TCP
• configuration et modes d’échec de la validation DNSSEC
• comportement EDNS0 et gestion de la taille des réponses

Vous n’avez pas besoin de mémoriser les bizarreries de chaque résolveur. Vous devez accepter qu’une chaîne fragile se comporte comme un système distribué : elle
se dégradera parfois d’une manière que vos tests internes ne reproduisent jamais.

6) Le raisonnement fallacieux « c’est juste un saut de plus »

Chaque saut supplémentaire paraît une petite décision : alias vers le endpoint SaaS, alias vers le CDN, alias vers la plateforme marketing, alias vers le
gestionnaire de trafic. Individuellement rationnel. Collectivement, une chaîne.

Cette illusion cesse quand on vous demande : « Quel est le temps maximum pour résoudre notre endpoint de connexion sous cache froid depuis un opérateur mobile
dans un autre pays ? » Si vous ne pouvez pas répondre à cela, vous avez introduit de l’incertitude dans votre flux de connexion. Ce n’est pas une fonctionnalité.

Une citation à garder sur un post-it : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan.

Faits et contexte historique qui expliquent le bazar d’aujourd’hui

Le DNS n’est pas nouveau, mais la façon dont nous l’utilisons aujourd’hui l’est beaucoup. Les chaînes CNAME sont courantes parce que nous continuons d’empiler
des systèmes sur un protocole conçu pour un internet plus petit et plus calme.

1. Le CNAME existe depuis les premiers RFC DNS, créé pour éviter de dupliquer des enregistrements d’adresse sur de nombreux alias.
   C’est un outil d’indirection, et l’indirection finit toujours par être utilisée.
2. Le DNS a été conçu en supposant que le cache ferait le gros du travail. Toute l’architecture attend que les requêtes répétées soient bon marché
   parce que les résolveurs récursifs mettent en cache les réponses.
3. Le cache négatif a été standardisé plus tard (mise en cache de NXDOMAIN et résultats similaires), ce qui a réduit la charge mais introduit
   son propre délai « pourquoi c’est encore cassé ? » lors de la correction d’une faute de frappe.
4. EDNS0 a été introduit pour gérer les limites de taille de réponse. Cela compte parce que les chaînes CNAME plus DNSSEC peuvent gonfler les réponses,
   déclenchant une fragmentation ou un basculement TCP.
5. Les CDN ont popularisé le steering du trafic basé sur DNS à grande échelle. Cela implique souvent des TTL courts et des réponses plus dynamiques.
   Parfait pour le routage ; rude pour les caches.
6. Beaucoup d’entreprises ont commencé à traiter le DNS comme de la gestion de configuration : « juste CNAME vers la chose. » C’est pratique et
   dangereusement facile à faire sans mesurer le coût.
7. Certaines résolveurs appliquent des limites pratiques sur la chasse d’alias pour prévenir les boucles et l’abus de ressources. Si votre chaîne est longue ou
   bizarre, certains clients échoueront plus tôt que d’autres.
8. L’adoption de DNSSEC a introduit une nouvelle classe de panne : les réponses peuvent être « présentes mais invalides », et les échecs de validation peuvent
   ressembler à des timeouts selon le comportement du client.
9. Le « flattening » CNAME est apparu comme contournement pour les enregistrements apex où les CNAME sont restreints. Il améliore certaines choses et
   en casse d’autres (plus d’informations plus loin).

Modes de panne que vous verrez en production

La profondeur de la chaîne atteint les limites du résolveur

Certains résolveurs plafonnent le nombre de CNAMEs qu’ils chasseront. D’autres plafonnent le travail récursif total par requête. Une chaîne longue peut atteindre ces limites,
ce qui ressemble à SERVFAIL ou des timeouts pour le client.

NXDOMAIN intermittent en amont

Les fournisseurs rollent parfois des changements DNS et servent brièvement des zones incohérentes : certains serveurs autoritatifs connaissent l’enregistrement, d’autres non,
ou les changements de délégation se propagent de manière inégale. Votre résolveur peut interroger un serveur autoritatif « mauvais » et mettre en cache NXDOMAIN (cache négatif),
transformant un problème transitoire du fournisseur en une panne plus longue pour vous.

Fragmentation UDP et basculement DNS sur TCP

Les grandes réponses DNS peuvent être fragmentées. UDP fragmenté n’est pas livré de façon fiable sur tous les réseaux. Quand la fragmentation échoue, les résolveurs
réessaient, basculent sur TCP, ou expirent. Les chaînes CNAME contribuent à l’augmentation de la taille des réponses, et DNSSEC peut aggraver cela en ajoutant des signatures.

Bizarrerie dual-stack (AAAA vs A)

Si votre chaîne se termine par A et AAAA, les clients peuvent préférer l’IPv6, puis retomber sur l’IPv4 (ou inversement). Si la connectivité IPv6 est instable,
l’échec ressemble à « le DNS est lent », parce que la résolution a réussi mais l’établissement de la connexion traîne.

Surprises split-horizon

En interne, service.example.com peut résoudre vers un VIP interne. Externement, il CNAME vers un fournisseur. Si votre chaîne mélange
vues internes et externes, quelqu’un exécutera un mauvais résolveur au mauvais endroit et se demandera pourquoi la staging appelle la prod.

Boucles CNAME

Les mauvaises configurations arrivent : a CNAME vers b et b CNAME de retour vers a. Les bons résolveurs
détectent les boucles, mais les clients voient quand même un échec. Les boucles s’immiscent souvent pendant des migrations où anciens et nouveaux noms coexistent.

Playbook de diagnostic rapide

Quand le DNS est suspecté, ne « fouillez » pas au hasard. Exécutez une boucle serrée de vérifications qui vous disent d’où viennent le temps et les échecs.
C’est l’ordre qui fait gagner du temps.

Premier point : vérifier si vous avez une chaîne et quelle est sa profondeur

• Interrogez avec dig et inspectez la section ANSWER pour plusieurs CNAME.
• Notez les TTL à chaque saut.
• Décidez si la chaîne est stable (mêmes réponses) ou dynamique (réponses qui varient rapidement).

Deuxième point : séparer la latence du résolveur de celle des autoritatifs

• Interrogez votre résolveur récursif habituel et notez le temps de requête.
• Puis interrogez directement les serveurs autoritatifs pour chaque saut.
• Si le résolveur récursif est lent mais que les autoritatifs sont rapides, vous regardez un problème de cache miss, coût de validation DNSSEC, limitation de débit, ou surcharge du résolveur.
• Si les réponses autoritatives sont lentes ou incohérentes, votre chaîne vous a transformé en client de la disponibilité DNS de quelqu’un d’autre.

Troisième point : tester le comportement cache froid vs chaud

• Exécutez des requêtes répétées et voyez si la latence s’effondre après le premier hit.
• Si ce n’est pas le cas, les TTL peuvent être trop bas, les réponses trop dynamiques, ou le cache désactivé/bypassé.

Quatrième point : vérifier le basculement TCP / la troncation

• Recherchez le comportement « TC » (truncated), de grosses réponses, ou le surcoût DNSSEC.
• Testez avec +tcp pour voir si TCP rend la résolution fiable (et plus lente).

Cinquième point : corréler avec les symptômes applicatifs

• Confirmez si l’appli bloque sur le DNS (commun dans les clients HTTP synchrones lors de l’établissement de connexion).
• Vérifiez le churn des pools de connexion autour des déploiements/autoscaling.
• Cherchez des pics dans les taux de « nouvelles connexions » et les requêtes DNS par seconde.

Si vous ne faites qu’une chose : mesurez le temps de résolution depuis le même chemin réseau que les clients affectés. Les problèmes DNS aiment se cacher derrière
« mais c’est rapide depuis mon poste de travail ».

Tâches pratiques : commandes, sorties et décisions

Ce sont les vérifications que j’exécute réellement. Chacune inclut : une commande, ce que signifie une sortie typique, et la décision qu’elle entraîne.
Remplacez les noms exemples par les vôtres. Conservez la structure.

Task 1: Show the whole answer and spot the chain

cr0x@server:~$ dig api.example.com A +noall +answer
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10

Ce que cela signifie : Deux sauts CNAME avant l’enregistrement A. Les TTL sont 300 → 60 → 60, donc vous rafraîchirez fréquemment les sauts du fournisseur.
Décision : Si c’est un endpoint critique (login, checkout, API), visez ≤1 saut ou négociez des TTL plus longs avec le fournisseur.

Task 2: Measure query time from your normal resolver

cr0x@server:~$ dig api.example.com A +stats | tail -n 3
;; Query time: 84 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Wed Dec 31 12:03:11 UTC 2025

Ce que cela signifie : 84 ms pour une recherche depuis votre environnement. Ce n’est pas gratuit.
Décision : Si vous voyez >20 ms dans un data center, considérez cela suspect et continuez vers l’isolation autoritative.

Task 3: Compare against a public resolver (sanity check, not a fix)

cr0x@server:~$ dig @1.1.1.1 api.example.com A +stats | tail -n 3
;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Dec 31 12:03:26 UTC 2025

Ce que cela signifie : Le résolveur public est plus rapide. Votre résolveur interne peut être surchargé, mal configuré, ou loin géographiquement.
Décision : Enquêtez sur la santé et la topologie du résolveur interne ; ne vous contentez pas de « passer au DNS public » et d’appeler ça fait.

Task 4: Force a cold-ish view by bypassing cache (as much as you can)

cr0x@server:~$ dig api.example.com A +nocache +stats | tail -n 3
;; Query time: 92 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Wed Dec 31 12:03:45 UTC 2025

Ce que cela signifie : Toujours lent. Soit le résolveur ne peut pas mettre en cache efficacement (TTL très bas / réponses dynamiques), soit la lenteur est en amont.
Décision : Passez aux vérifications serveur autoritatif par serveur autoritatif pour localiser le saut lent.

Task 5: Find the authoritative nameservers for your zone

cr0x@server:~$ dig example.com NS +noall +answer
example.com.          172800 IN NS ns1.dns-provider.net.
example.com.          172800 IN NS ns2.dns-provider.net.

Ce que cela signifie : Votre zone est servie par ns1/ns2.
Décision : Interrogez-les directement pour voir si vos enregistrements sont corrects et cohérents.

Task 6: Query your authoritative server directly (verify your first hop)

cr0x@server:~$ dig @ns1.dns-provider.net api.example.com CNAME +noall +answer +stats
api.example.com.        300 IN CNAME api.edge.vendor.net.
;; Query time: 12 msec
;; SERVER: ns1.dns-provider.net#53(ns1.dns-provider.net) (UDP)

Ce que cela signifie : Votre autoritatif répond rapidement et renvoie le CNAME attendu.
Décision : Votre zone n’est probablement pas le problème ; poursuivez vers le saut fournisseur suivant.

Task 7: Find the vendor zone’s authoritative servers

cr0x@server:~$ dig edge.vendor.net NS +noall +answer
edge.vendor.net.      3600 IN NS ns-101.vendor-dns.net.
edge.vendor.net.      3600 IN NS ns-102.vendor-dns.net.

Ce que cela signifie : Le fournisseur utilise une infrastructure autoritative séparée. C’est une dépendance que vous n’opérez pas.
Décision : Interrogez-les directement et mesurez. Si c’est lent, vous avez des preuves pour ouvrir un ticket fournisseur.

Task 8: Query the vendor authoritative directly (measure the second hop)

cr0x@server:~$ dig @ns-101.vendor-dns.net api.edge.vendor.net CNAME +noall +answer +stats
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
;; Query time: 97 msec
;; SERVER: ns-101.vendor-dns.net#53(ns-101.vendor-dns.net) (UDP)

Ce que cela signifie : 97 ms vers un autoritatif fournisseur. C’est très probablement votre coupable de latence DNS.
Décision : Envisagez de réduire la profondeur de chaîne (intégration directe), demandez des TTL/latences améliorés, ou ajoutez un endpoint de trafic plus fiable que vous contrôlez.

Task 9: Check for inconsistencies across vendor authoritative servers

cr0x@server:~$ for ns in ns-101.vendor-dns.net ns-102.vendor-dns.net; do dig @$ns api.edge.vendor.net CNAME +noall +answer; done
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.edge.vendor.net.     60 IN CNAME api-alt.geo.vendor.net.

Ce que cela signifie : Deux serveurs autoritatifs ne sont pas d’accord. Ce n’est pas du « load balancing DNS. » C’est de l’incohérence.
Décision : Traitez cela comme un risque d’incident fournisseur. Si votre résolveur tombe sur le mauvais serveur, vous obtiendrez des cibles différentes et potentiellement des comportements différents.

Task 10: Detect CNAME loops or excessive chasing with trace

cr0x@server:~$ dig api.example.com A +trace
; <<>> DiG 9.18.24 <<>> api.example.com A +trace
;; Received 525 bytes from 10.0.0.53#53(10.0.0.53) in 1 ms
example.com.     172800 IN NS ns1.dns-provider.net.
example.com.     172800 IN NS ns2.dns-provider.net.
api.example.com.    300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net. 60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.  60 IN A 203.0.113.10

Ce que cela signifie : Le trace montre clairement la chaîne. Si vous voyiez des rebonds répétés entre deux noms, c’est une boucle.
Décision : Si une boucle ou une chaîne très longue apparaît, corrigez immédiatement ; ne « pas attendre et voir ».

Task 11: Check for truncation and TCP fallback risk

cr0x@server:~$ dig api.example.com A +dnssec +bufsize=1232 +noall +comments +answer
;; Got answer:
;; WARNING: Message has 1 extra bytes at end
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10

Ce que cela signifie : Vous poussez vers des bords taille/transport (l’avertissement exact varie). Avec DNSSEC, les réponses peuvent grossir rapidement.
Décision : Si vous voyez de la troncation (« TC ») dans des captures réelles, évaluez la taille des réponses DNS, réduisez la chaîne, ou ajustez le résolveur/réseau pour gérer TCP de manière fiable.

Task 12: Force TCP to see whether it’s “UDP is flaky”

cr0x@server:~$ dig api.example.com A +tcp +stats | tail -n 3
;; Query time: 143 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (TCP)
;; WHEN: Wed Dec 31 12:05:02 UTC 2025

Ce que cela signifie : TCP est plus lent mais peut être plus fiable sur certains réseaux. Si les résultats UDP time-out et que TCP marche, vous avez un problème de chemin/MTU/fragmentation.
Décision : Corrigez les problèmes de chemin réseau et la taille des réponses. Ne forcez pas TCP partout comme « solution » à moins d’aimer payer une taxe de latence pour toujours.

Task 13: Inspect local resolver configuration (see what you’re actually using)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54
        DNS Domain: corp.example

Ce que cela signifie : Vous utilisez des résolveurs internes ; la validation DNSSEC est désactivée à ce niveau (elle peut toujours être activée en amont).
Décision : Si la latence diffère énormément entre 10.0.0.53 et 10.0.0.54, la distribution de charge ou les checks de santé sont mauvais. Corrigez la santé de la flotte de résolveurs avant de toucher aux enregistrements.

Task 14: Measure resolver behavior over time (latency distribution, not one sample)

cr0x@server:~$ for i in {1..10}; do dig api.example.com A +stats +noall +answer; done
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10

Ce que cela signifie : La sortie montre un mapping stable (bien), mais vous devez quand même inspecter les temps de requête. En pratique vous incluriez les lignes de stats ou captureriez avec un script.
Décision : Si la première recherche est lente et les neuf suivantes rapides, le caching marche et les TTL ne sont pas catastrophiques. Si les dix varient, la chaîne est dynamique ou le résolveur est en difficulté.

Task 15: Check whether your app host is spamming DNS (system view)

cr0x@server:~$ sudo ss -uapn | grep ':53 ' | head
UNCONN 0 0 10.10.5.21:58642 10.0.0.53:53 users:(("python3",pid=24817,fd=9))
UNCONN 0 0 10.10.5.21:49811 10.0.0.53:53 users:(("java",pid=11302,fd=123))

Ce que cela signifie : Vous voyez quels processus parlent au DNS. Si un service martèle le DNS, le pooling de connexion ou le caching peuvent être cassés.
Décision : Corrigez le comportement client (réutiliser les connexions, activer un cache DNS local si approprié) avant de repenser les enregistrements DNS.

Task 16: Validate the end of the chain returns both A and AAAA (or intentionally not)

cr0x@server:~$ dig api.example.com A AAAA +noall +answer
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10
api.geo.vendor.net.      60 IN AAAA  2001:db8::10

Ce que cela signifie : Le dual-stack est en jeu. C’est bien — si votre réseau supporte l’IPv6 de façon fiable.
Décision : Si des clients dans certains environnements échouent sur IPv6, vous verrez des délais « aléatoires ». Envisagez l’état de santé IPv6, le comportement Happy Eyeballs, ou la désactivation volontaire du AAAA si vous ne pouvez pas le supporter.

Trois mini-histoires d’entreprise (anonymisées, douloureusement plausibles)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une équipe produit a migré leur endpoint API public derrière une passerelle de sécurité. Le plan de migration était « sûr » parce qu’ils n’avaient pas changé
les IP ; ils ont juste mis à jour le DNS. Le api.example.com d’origine est devenu un CNAME vers le nom d’hôte de la passerelle.

La mauvaise hypothèse : « le DNS est essentiellement instantané. » Ils avaient des tests de charge pour le débit, la latence à la passerelle, et la performance de la base de données.
Ils n’ont pas testé les clients cold-start à grande échelle — nouveaux pods qui démarrent, pools de connexions vides, caches froids. Le comportement réel du système était
dominé par des recherches DNS répétées pendant l’établissement des connexions.

La chaîne s’est retrouvée à trois CNAMEs de profondeur parce que le fournisseur de la passerelle utilisait un alias régional, qui pointait ensuite vers un alias par POP,
qui enfin retournait A/AAAA. Les TTL du fournisseur étaient de 30–60 secondes. Sous charge stable, c’était acceptable. Lors d’une vague de déploiement, la flotte a commencé
à résoudre agressivement. Les QPS du résolveur ont grimpé, puis la latence de résolution a augmenté, puis la latence des requêtes a augmenté, et enfin les timeouts côté client se sont transformés en retries.
Boucle de rétroaction positive classique.

L’incident ressemblait à « la passerelle est lente. » Ce n’était pas le cas. La passerelle était au repos. Le DNS était le goulot, et personne ne voulait le croire
parce que, culturellement, le DNS est quelque chose qu’on ne touche que quand on achète un domaine.

La correction n’a pas été héroïque. Ils ont aplati la chaîne en utilisant un nom direct fourni par le fournisseur conçu pour les clients API à haut QPS, ont augmenté les TTL
quand c’était possible, et ont monté la flotte de résolveurs internes. Le vrai gain a été d’ajouter un élément à la checklist de déploiement : mesurer la latence de recherche DNS sur des pods froids
pour chaque nom critique.

Mini-histoire 2 : L’optimisation qui a mal tourné

Le marketing voulait un basculement « instantané » entre deux CDN, plus un WAF, plus un service d’optimisation d’images. Quelqu’un a proposé une élégante indirection DNS :
CNAME partout, TTL bas, laisser les fournisseurs router dynamiquement. Ça sonnait moderne. C’était aussi un sandwich de dépendances.

Ils ont construit : assets.example.com CNAME vers un traffic manager, qui CNAME vers le WAF, qui CNAME vers le CDN choisi, qui CNAME vers un nom edge régional.
Sur le papier ce ne sont que des alias. En pratique c’est une chaîne à travers plusieurs fournisseurs avec des caractéristiques de panne différentes et des idées différentes de ce que signifie « TTL 60 secondes ».

Le retour de bâton est arrivé pendant un incident fournisseur qui n’était même pas une panne totale : les serveurs autoritatifs d’un fournisseur étaient joignables mais lents.
Les résolveurs récursifs ont commencé à expirer et à réessayer. Certains ont renvoyé SERVFAIL, d’autres des données mises en cache obsolètes, d’autres sont passés en TCP. Les expériences
utilisateurs ont divergé selon la géographie et l’ISP.

Le plus ennuyeux : même après la récupération du fournisseur, le cache négatif et le comportement incohérent des résolveurs ont prolongé les symptômes.
Certains utilisateurs étaient « réparés », d’autres non. Les tickets de support sont arrivés en vagues. La société a brûlé du temps d’ingénierie à faire du diagnostic client par client,
parce que la couche DNS était devenue une roulette russe.

Ils ont finalement simplifié : un seul fournisseur contrôlait l’edge pour ce nom d’hôte, et le basculement est passé de la « magie DNS » à un runbook contrôlé et testé avec un temps de cutover mesuré.
Le système est devenu moins intelligent et plus fiable, ce qui est la bonne direction.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe plateforme maintenait une petite norme interne : tout nom critique externe doit avoir un « budget de chaîne DNS » documenté (nombre maximal de sauts),
et doit être surveillé avec des vérifications synthétiques de résolution depuis plusieurs réseaux. Ce n’était pas glamour. Personne n’a reçu de prix.

Un après-midi, leur monitoring a signalé que le temps de résolution de login.example.com avait dépassé le seuil dans deux régions.
Pas la latence applicative. Pas la poignée TLS. Juste la résolution DNS. L’alerte incluait la chaîne observée et quel saut était lent.

Ils ont consulté leur inventaire existant : login.example.com était autorisé à avoir un CNAME vers leur propre traffic manager, puis il devait terminer en enregistrements A/AAAA qu’ils contrôlaient.
Cela signifiait que les seuls serveurs autoritatifs impliqués étaient les leurs. Pas de dépendance tierce dans la chaîne. Le saut lent se situait à l’intérieur du edge de leur fournisseur DNS pour ces régions.

Ils ont exécuté une contingence ennuyeuse : basculer la délégation NS vers leur fournisseur secondaire (préconfiguré, testé trimestriellement), attendre la propagation,
et observer la chute des temps de résolution. Les utilisateurs ont à peine remarqué. L’incident n’a jamais dégénéré en panne majeure.

Le « sauvetage » n’était pas le basculement lui-même. Le sauvetage, c’était qu’ils avaient limité l’indirection CNAME pour le nom le plus critique et s’étaient exercés au basculement DNS.
L’ennuyeux gagne encore.

Blague n°2 : Le DNS est le seul endroit où ajouter « juste un alias » peut se transformer en roman à suspense avec plusieurs auteurs et aucun éditeur.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: random spikes in API latency that don’t match backend metrics

Cause racine : la résolution DNS est sur le chemin de la requête à cause de nombreuses nouvelles connexions ; chaîne CNAME avec TTL court augmente les misses de cache.

Correction : Réduire la profondeur de chaîne pour les hostnames critiques ; augmenter les TTL si sûr ; améliorer la réutilisation des connexions ; ajouter un résolveur cache local sur les nœuds si approprié.

2) Symptom: some clients fail while others work, by geography or ISP

Cause racine : les serveurs autoritatifs du fournisseur sont incohérents ou lents dans certaines régions ; les résolveurs récursifs se comportent différemment ; le comportement EDNS0 varie.

Correction : Interrogez les autoritatifs du fournisseur depuis les régions affectées ; exigez de la cohérence ; envisagez de terminer la chaîne dans votre propre zone avec des A/AAAA vers des endpoints anycast du fournisseur si disponibles.

3) Symptom: SERVFAIL appears after a DNS change, then “fixes itself” later

Cause racine : échecs de validation DNSSEC (mauvaises signatures, délégation cassée) ou déploiement autoritatif incohérent ; le cache négatif prolonge la douleur.

Correction : Validez la chaîne de confiance DNSSEC ; vérifiez les enregistrements DS et les réponses autoritatives ; faites un rollback rapide ; gardez des TTL raisonnables pendant les migrations.

4) Symptom: resolution works from laptops but fails in containers

Cause racine : différents résolveurs (VPN/corp vs cluster DNS), chemins egress différents, ou différences de caching local sur les nœuds ; la chaîne atteint les limites du résolveur sous charge.

Correction : Testez depuis le même environnement que la charge défaillante ; ajustez CoreDNS/node-local DNS ; réduisez la profondeur de chaîne ; évitez des TTL ultra-bas qui neutralisent le cache.

5) Symptom: “temporary failure in name resolution” during deploys/autoscaling

Cause racine : surcharge du résolveur due à des démarrages à froid en rafale ; la chaîne CNAME multiplie les requêtes en amont ; TTL court provoque des rafraîchissements fréquents.

Correction : Scalez la flotte de résolveurs ; ajoutez des couches de cache ; échelonnez les rollouts ; préchauffez les caches DNS critiques ; minimisez les sauts CNAME sur les hostnames du chemin chaud.

6) Symptom: DNS queries suddenly shift to TCP and latency rises

Cause racine : réponses volumineuses (chaîne CNAME + DNSSEC), troncation, ou problèmes de MTU/fragmentation sur le chemin.

Correction : Réduisez la taille des réponses (raccourcissez la chaîne, supprimez les enregistrements inutiles), assurez-vous que les résolveurs supportent correctement EDNS0, et validez le MTU/la gestion de fragmentation du réseau.

7) Symptom: intermittent NXDOMAIN for a hostname that exists

Cause racine : incohérence autoritative pendant un déploiement fournisseur ; le résolveur interroge un autoritatif en retard et met en cache la réponse négative.

Correction : Interrogez tous les serveurs autoritatifs ; capturez des preuves ; demandez au fournisseur de corriger la discipline de propagation ; en attendant, évitez de chaîner via des zones instables pour les noms critiques.

Check-lists / plan étape par étape

Checklist A: Decide whether a CNAME is appropriate

1. Le nom d’hôte est-il critique ? (login, checkout, API, récepteur de webhook) Si oui, limitez agressivement la profondeur de chaîne.
2. Contrôlez-vous le saut suivant ? Si non, vous importez la disponibilité de quelqu’un d’autre dans la vôtre.
3. Les TTL sont-ils < 60s ? Si oui, supposez une forte charge sur les résolveurs et une latence de queue plus élevée sous churn.
4. Allez-vous avoir un comportement apex ? Si oui, soyez prudent avec le flattening ; comprenez ce que fait votre fournisseur en coulisses.
5. Pouvez-vous utiliser A/AAAA en toute sécurité ? Si les IP cibles sont stables ou anycast, préférez des enregistrements directs pour les endpoints critiques.

Checklist B: Reduce chain depth safely (migration plan)

1. Inventoriez la chaîne actuelle avec dig ; enregistrez les sauts et les TTL.
2. Confirmez si le fournisseur offre un endpoint stable destiné aux A/AAAA directs (certains le font).
3. Baissez le TTL sur l’enregistrement actuel avant le cutover (heures/jours en avance, selon le TTL existant).
4. Implémentez la nouvelle cible en parallèle (si possible) et testez depuis plusieurs réseaux.
5. Basculez pendant une fenêtre à risque réduit ; surveillez la latence de résolution et les taux d’erreur.
6. Après stabilité, remontez le TTL à une valeur sensée (souvent minutes à heures, selon votre cadence de changement).
7. Documentez la propriété : qui approuve l’indirection DNS future pour ce nom.

Checklist C: Monitor the chain like an SLO dependency

1. Suivez la latence de résolution DNS (p50/p95/p99) depuis des réseaux clients représentatifs.
2. Alertez sur changement de profondeur de chaîne (un changement fournisseur silencieux peut ajouter des sauts).
3. Alertez sur incohérence autoritative (réponses différentes entre NS).
4. Suivez les taux SERVFAIL/NXDOMAIN séparément des erreurs applicatives.
5. Pendant les incidents, capturez : résolveur utilisé, temps de requête, chaîne de réponses, et si TCP était requis.

Checklist D: If you must keep a chain (because business)

1. Gardez-la courte : un saut est préférable, deux est une exception négociée, trois est un symptôme de conception.
2. Exigez des SLOs fournisseur pour leur DNS autoritatif et publiez des chemins d’escalade.
3. Demandez des endpoints anycast régionaux ou des noms « directs » pour les cas d’usage API à haut QPS.
4. Rendez la politique TTL explicite : un TTL extrêmement bas doit être traité comme une demande de performance nécessitant des tests de charge.
5. Ayez un plan de secours sous votre contrôle (hostname secondaire, fournisseur alternatif, ou endpoint mis en cache) et exercez-le.

FAQ

1) How many CNAMEs is “too many”?

Pour les chemins critiques : plus d’un est déjà une décision de risque. Plus de deux devrait être rare et justifié par des mesures et de la surveillance.
Pour des noms non critiques (pages marketing, hostnames vanity), vous pouvez en tolérer davantage — mais gardez un œil dessus.

2) Do CNAME chains always add latency?

Pas toujours. Avec des caches chauds et des TTL stables, une chaîne peut être pratiquement gratuite. Le problème est que vos pires moments (déploiements, pannes,
pics de trafic) sont exactement ceux où les caches sont froids et où les retries se produisent.

3) Why does a short TTL make things worse if it’s “more dynamic”?

Un TTL court augmente la fréquence des requêtes. Cela augmente la charge sur les résolveurs et la probabilité qu’un client subisse un cache miss.
Cela augmente aussi le taux auquel vous payez la latence des autoritatifs en amont.

4) Should we just run our own recursive resolvers everywhere?

Parfois. Des résolveurs node-local ou VPC-local peuvent réduire la latence et vous protéger de certaines instabilités en amont. Mais cela fait de vous l’opérateur
d’un autre système distribué. Si vous ne pouvez pas le monitorer et le dimensionner, vous créerez un nouveau mode de panne.

5) What about CNAME flattening?

Le flattening est une fonctionnalité fournisseur qui renvoie A/AAAA à l’apex pendant que vous configurez un alias de type CNAME. Cela peut réduire la profondeur
visible côté client, mais cela transfère la complexité au fournisseur et peut changer le comportement des TTL. Traitez-le comme une fonctionnalité produit avec des compromis, pas comme un déjeuner gratuit.

6) Can CNAME chains break TLS or certificates?

Pas directement. TLS vérifie le nom d’hôte auquel le client se connecte, pas le nom cible du CNAME. Mais les chaînes peuvent orienter les clients vers des endpoints différents
de manière inattendue, et si la configuration du fournisseur est incohérente, vous pouvez vous retrouver avec des mismatches de certificat sur l’IP atteinte.

7) Why do we see NXDOMAIN for a record that exists?

Parce que le DNS est distribué et met aussi en cache les résultats négatifs. Si un serveur autoritatif sert brièvement NXDOMAIN (problème de propagation, split brain),
les résolveurs peuvent le mettre en cache pendant un certain temps. Ce « certain temps » est défini par les paramètres SOA et la politique du résolveur, pas par votre patience.

8) How do I prove to a vendor that their DNS is slow?

Interrogez directement leurs serveurs autoritatifs (par nom), enregistrez les temps de requête depuis les régions affectées, et montrez les incohérences dans leur jeu de NS.
Fournissez des timestamps, le nom interrogé, et si UDP vs TCP a changé les résultats.

9) Do CNAME chains affect caching on CDNs and browsers?

Les navigateurs et les résolveurs stub OS mettent en cache différemment, souvent avec leurs propres limites et comportements. La complexité principale de caching est au niveau
des résolveurs récursifs, mais le comportement côté client peut amplifier les problèmes — surtout lorsque les applications contournent le cache OS ou créent des contextes de lookup fréquents.

10) Is replacing CNAME with A/AAAA always better?

C’est mieux pour la performance et la fiabilité lorsque les IPs endpoints sont stables et que vous pouvez opérer les changements en toute sécurité. C’est pire lorsque le fournisseur
change les IPs sans prévenir, ou lorsque vous perdez une logique de routage dont vous avez réellement besoin. Si vous utilisez A/AAAA, vous acceptez plus de responsabilité.

Prochaines étapes (celles qui réduisent le bruit des pagers)

Les chaînes CNAME ne sont pas maléfiques. Ce n’est que de l’indirection, et l’indirection est la façon de faire croître la complexité sans admettre qu’on l’a faite.
Le problème commence lorsqu’une chaîne devient longue, dynamique et contrôlée par un fournisseur — alors ce n’est plus de la « config DNS », c’est un graphe de dépendances d’exécution.

Étapes pratiques que vous pouvez faire cette semaine :

1. Inventoriez les noms critiques et enregistrez leur profondeur de chaîne et leurs TTL.
2. Mesurez la latence de résolution DNS (p50/p95/p99) depuis les mêmes réseaux que vos utilisateurs et workloads.
3. Fixez un budget : un saut CNAME pour les noms critiques sauf exception écrite.
4. Simplifiez les pires : aplatissez les chaînes, préférez des endpoints stables, ou terminez l’indirection dans des zones que vous contrôlez.
5. Surveillez la dérive de la chaîne : les fournisseurs changent le comportement DNS sans vous prévenir, bien sûr qu’ils le font.
6. Répétez une contingence DNS pour un nom critique. La première fois que vous la pratiquez ne devrait pas être pendant un incident.

Si vous ne retenez qu’une leçon : quand votre système dépend du DNS à grande échelle, traitez le DNS comme une infrastructure de production, pas comme un formulaire que l’on remplit une fois par an.