Ce guide s’adresse aux ingénieurs plateforme qui doivent valider dans la même revue le SSH inter-régions et les gros pulls binaires. Il complète la matrice PoP plus large de l’article GeoDNS, latence SSH et critères régionaux (2026) en zoomant sur le comportement des résolveurs, les types d’enregistrements actionnables et une liste d’acceptation p95 pour le retour des artefacts. Partez de l’accueil français ou ouvrez directement une page régionale adaptée à votre audience : anglais, allemand, russe, japonais, coréen, chinois simplifié, chinois (Taïwan), puis alignez DNS et supervision sur les tableaux ci-dessous.
Matrice de décision split-horizon vs GeoDNS
Le DNS split-horizon sert des réponses différentes à l’intérieur du réseau d’entreprise (ou du VPC CI) et sur Internet public. Le GeoDNS (souvent avec EDNS Client Subnet) oriente les clients publics vers une cible régionale selon les indices du résolveur et les pondérations de politique. L’un ne remplace pas l’autre : le split retire l’ambiguïté pour l’automatisation ; le GeoDNS optimise la découverte pour les humains derrière un seul nom de marque.
| Dimension | Split-horizon (vue interne) | GeoDNS (vue publique) |
|---|---|---|
| Gain principal | Cibles CI / runners déterministes | Nom global peu frictionné pour humains et portables |
| Posture TTL | Souvent 300–3600 s ; peut être agressif car vous maîtrisez les résolveurs | Plus court en fenêtre de changement (60–300 s) ; plus long en régime établi (600–1800 s) |
| Risque de collant cache | Forwarders collants ou proxys DNS transparents en siège | Caches récursifs FAI/publics ignorant l’ECS ; cartes continent obsolètes |
| SSH (poignée de main) | Jump hosts et bastions mappés 1:1 aux identifiants PoP | La poignée suit ce que le résolveur a mis en cache ; valider par marché |
| Origine artefacts | Facile d’épingler registry.internal sur des VIP in-région |
ALIAS/ANAME ou règles apex ; surveiller la divergence dual-stack CDN |
| Mode défaillance | Dérive entre catalogue interne et DNS marketing public | Guidage partiel pendant chevauchement TTL ; health checks qui flappent |
Types d’enregistrements DNS exécutables (livre de recettes)
Choisissez le plus petit jeu d’enregistrements qui permet encore le basculement sans renommer les hôtes. Préférez des noms stables (ssh-asia.prod.example) et l’indirection CNAME pour les services qui changent de cloud ; à l’apex, restez sur ALIAS/ANAME natif fournisseur ou A/AAAA aplatis.
| Enregistrement | Rôle typique | Quand le choisir |
|---|---|---|
| A / AAAA | Bastions SSH, VPN hérité, bords bare metal | Moins d’indirection ; pairez les deux familles pour builders Mac dual-stack |
| CNAME | Alias de service vers cibles pondérées ou noms d’hôte CDN | Jamais à l’apex sans flattening DNS |
| ALIAS / ANAME (fournisseur) | Apex vers cibles dynamiques (pools GeoDNS, passerelles managées) | Domaine racine marketing avec ensembles PoP changeants |
| SRV | SSH ou gRPC interne découvrables si les clients l’honorent | Idéal pour catalogues d’automatisation ; beaucoup de clients SSH exigent des wrappers |
| TXT | Preuve de propriété, ACME, jetons canari | Court ; évitez d’y stocker l’état opérationnel |
| NS / délégation | Sous-zones par région | Quand juridique ou facturation impose des SOA distincts |
Gammes TTL et idées de sondes « collant cache »
Le TTL n’est pas « la vitesse à laquelle le DNS se met à jour partout dans le monde » : c’est la borne supérieure de durée de vie d’une réponse dans un cache récursif qui respecte le TTL. Le collant vient aussi des pools applicatifs (réutilisation de connexion), du réordonnancement happy-eyeballs et des CDN qui vous épinglent à un POP périphérique. Traitez TTL restant observé + âge de cache comme une seule métrique.
| Cycle de vie | Fenêtre TTL suggérée | Intention |
|---|---|---|
| Production stable | 600–1800 s pour A/AAAA régionaux ; 300–900 s pour pools à forte churn | Réduire le bruit résolveur tout en gardant des corrections le jour même |
| Migration planifiée | Pré-découpe 60–120 s pendant ≥ une fenêtre TTL antérieure | La majorité des caches se rafraîchissent avant la bascule |
| Retour arrière d’urgence | 30–60 s seulement avec automatisation et santé surveillées | TTL court = plus de QPS — surveillez les limites autoritatives |
| Vue interne split | 300–3600 s selon alignement baux DHCP | Coller aux caches des forwarders campus ; documenter les contournements |
# Comparer réponses publiques vs internes (remplacer ZONE/HÔTE)
dig +ttlunits A ssh.example.com @8.8.8.8
dig +ttlunits A ssh.example.com @10.0.0.2 # exemple résolveur d’entreprise
# Chaîne complète y compris flattening CNAME
dig +trace +ttlunits A ssh.example.com
# Collant bord HTTPS (TLS + TTFB) ; rejouer depuis deux FAI
curl -sS -o /dev/null -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n' \
https://registry.example.com/v2/dig) avec vos sondes SSH et HTTP. Si des ingénieurs à Séoul atterrissent encore en Virginie après un changement DNS « vert », l’incident est en général du collant de cache, pas du BGP.Sondes de poignée de main SSH inter-régions
SSH ajoute l’échange de clés et la vérification de clé d’hôte au-dessus du TCP. Pour des sessions Mac distant inter-régions, mesurez le mur horloge du SYN au premier prompt distant, pas seulement l’ICMP. Lancez les sondes depuis les sous-réseaux CI et depuis le domicile des développeurs, car le GeoDNS peut diverger.
- Budget poignée de main : suivez p50 / p95 de
time ssh … exit; alertez si le p95 grimpe de 40 % semaine sur semaine pour une paire de PoP. - Chemin des clés : préférez
-o BatchMode=yesen automatisation ; gardez des clés d’hôte stables par PoP pour éviter le flapping de confiance. - MTU / VPN : rejouez en VPN split-tunnel ; réduisez MSS si des trous noirs n’apparaissent qu’avec chiffrement.
# Sonde SSH mur horloge (utilisateur d’automatisation en lecture seule)
for i in $(seq 1 30); do
/usr/bin/time -p ssh -o BatchMode=yes -o ConnectTimeout=12 \
-o StrictHostKeyChecking=accept-new user@HOST 'exit' 2>&1 | awk '/^real/{print $2}'
sleep 1
done | sort -n | awk 'NR==1{min=$1} {sum+=$1; a[NR]=$1} END{
print "samples:", NR, "min:", min, "max:", a[NR], "p95:", a[int(0.95*NR)] }'
# OpenSSH verbeux une fois par fenêtre de changement (rédiger les clés avant ticket)
ssh -vvv -o BatchMode=yes user@HOST true 2>&1 | tee /tmp/ssh-trace.txtRetour d’artefacts — checklist d’acceptation p95
Les couches conteneur, les binaires SwiftPM et les objets Git LFS sollicitent le DNS autrement que SSH : beaucoup de connexions HTTPS parallèles, requêtes par plages et redirections CDN. La validation doit s’appuyer sur le p95 de bout en bout depuis la carte réseau du builder, pas seulement sur les tableaux de bord CDN.
| Contrôle | Critères de passage (préprod → prod) | Idée de sonde |
|---|---|---|
| Réponses DNS = PoP attendu | ≥ 99 % des jobs résolvent vers des cibles in-région en régime établi | Logger getent / sortie résolveur au démarrage du job ; comparer à une liste blanche |
| TLS et profondeur de redirection | ≤ 2 redirections HTTP ; p95 handshake TLS ≤ 250 ms intra-région | Modèle curl -w ci-dessus avec -L --max-redirs |
| Plancher de débit | p95 du tirage d’un gabarit 500 Mo ≤ baseline équipe × 1,25 | Job pipeline avec gabarit d’artefact ; archiver les durées en observabilité |
| Plage / reprise | Les pulls interrompus reprennent sans retéléchargement intégral | Couper en milieu de transfert ; vérifier les plages d’octets dans les journaux d’accès |
| Exercice de failover | Après fenêtre TTL, ≥ 95 % des jobs choisissent l’origine secondaire sans /etc/hosts manuel |
Flip d’enregistrement pondéré + région canari synthétique |
| Parité IPv6 | Chemin AAAA pas plus lent que A seul de > 20 % au p95 | Forcer -4 / -6 dans une paire de curl |
Quand la matrice, le plan TTL et la checklist p95 s’alignent, provisionnez les builders dans le même métro que vos miroirs de registre afin que les changements DNS et la localité des binaires avancent ensemble. vpshalo propose des Mac distants mensuels sur plusieurs régions — choisissez le PoP qui concilie politique de résolution et gravité des artefacts.