Propagation & diagnostics

Comparez plusieurs résolveurs et analysez les réponses servies.

Recherche enregistrement SVCB

En mode trace itérative, le résolveur est ignoré.
Interroge plusieurs résolveurs publics pour comparer les réponses.

Comment bien utiliser les différentes options du moteur de recherche DNS ?

Qu'est-ce que la trace itérative ?

La trace exécute la résolution pas à pas. Le résolveur interroge d'abord les serveurs de la racine, puis ceux du TLD (.com, .fr, .eu), puis les serveurs autoritaires de la zone cible. À chaque étape, la page affiche le serveur interrogé, la réponse, le RCODE et la latence.

  1. 1. Racine

    Découverte des serveurs du TLD pour le nom demandé.

  2. 2. TLD

    Référence vers les NS de la zone (délégation).

  3. 3. Autoritaires

    Réponse finale (ou erreur) avec TTL et latence.

À quoi ça sert ?

  • Comparer les réponses selon les résolveurs et les régions
  • Détecter un cache chaud, un TTL trop long ou une délégation incomplète
  • Expliquer une différence de latence ou un RCODE inattendu

Astuce : gardez la trace désactivée pour les vérifications rapides ; activez-la quand vous enquêtez ou préparez un ticket/post-mortem.

Qu'est-ce que la trace classique ?

La trace classique interroge uniquement le résolveur sélectionné (UDP ou DoH) et restitue la réponse telle qu'elle est perçue depuis ce point du réseau. Vous obtenez le RCODE, les sections de réponse et la latence du trajet client → résolveur.

  1. 1. Résolveur choisi

    Utilise le preset ou la configuration personnalisée pour lancer la requête exactement comme votre service.

  2. 2. Protocole conservé

    Respecte le transport sélectionné (UDP, TCP ou DoH) afin de reproduire le comportement réel.

  3. 3. Réponse détaillée

    Affiche les sections question, answer, authority/additional quand elles existent, avec TTL et métadonnées utiles.

Pourquoi l'utiliser ?

  • Vérifier la vision d'un résolveur spécifique avant de suspecter la délégation
  • Confirmer les valeurs en cache et l'impact d'un TTL ou d'un flush
  • Documenter une résolution telle qu'un client ou un microservice la voit

Astuce : laissez l'option de trace itérative désactivée quand vous auditez un résolveur donné ; activez-la ensuite pour comparer avec le parcours root → TLD → autoritaire.

Comment fonctionne le test de propagation ?

Le test interroge en parallèle un ensemble de résolveurs publics (Google, Cloudflare, Quad9, OpenDNS, FAI…) et groupe les réponses par contenu et RCODE. Vous visualisez instantanément qui a déjà pris en compte la mise à jour.

  1. 1. Résolveurs multipoints

    Active les presets de propagation pour interroger plusieurs acteurs répartis dans le monde.

  2. 2. Comparaison automatique

    Regroupe les réponses identiques et signale les divergences ou les erreurs propres à un résolveur.

  3. 3. Synthèse exploitable

    Fournit un résumé clair, la liste des résolveurs, leurs latences et l'état de chaque groupe.

Quand l'utiliser ?

  • Suivre la diffusion d'un changement DNS à l'échelle mondiale
  • Identifier les caches encore anciens et décider d'un flush ciblé
  • Partager un état de propagation dans un ticket ou un post-mortem

Astuce : pendant le test de propagation, la sélection de résolveur est figée. Désactivez le mode pour revenir au diagnostic unitaire.

Informations complémentaires sur les enregistrements DNS de type SVCB

Un SVCB record décrit comment joindre un service. Il peut désigner un autre nom et donner des paramètres comme le protocole l'adresse de secours et le port. Pour un site web, on publie souvent un enregistrement HTTPS qui est la variante dédiée du SVCB.
Un SVCB record contient un nom un type une priorité une cible des paramètres et un TTL. Le TTL indique combien de temps la réponse reste en cache dans le résolveur local.

Exemple enregistrement DNS de type SVCB

NomTypePrioritéCibleParamètresTTL en secondes
_imap._tcp.exemple.comSVCB1mail.exemple.net.alpn=imap port=993 ipv4hint=203.0.113.103600

Dans cet exemple le nom vise le service imap en tcp. La cible est un autre nom d hôte. Les paramètres indiquent le protocole la porte d entrée et une adresse de secours. Un TTL à 3600 correspond à une heure.

Exemple en mode alias

La priorité à zéro active un mode alias. Le nom se comporte alors comme un alias vers la cible.

NomTypePrioritéCibleParamètresTTL en secondes
apex.exemple.comSVCB0cdn.exemple.net.(aucun paramètre)3600

Ce mode sert de pont. Il évite d utiliser un CNAME là où il n est pas souhaité.

Paramètres courants

Nom du paramètreRôle
alpnAnnonce les protocoles pris en charge comme h2 ou h3
portIndique la porte d entrée du service
ipv4hintFournit des adresses v4 indicatives
ipv6hintFournit des adresses v6 indicatives
echPublie la donnée ECH pour chiffrer le ClientHello

Ces paramètres guident le client. Ils ne remplacent pas les enregistrements A et AAAA qui restent la source d adresses.

TTL expliqué en clair

Un TTL court rend un changement plus visible. Pratique pendant une transition.
Un TTL moyen ou long réduit les requêtes vers les serveurs autoritaires. Adapté à un service stable.
Réduire le TTL quelques heures avant une bascule puis le remonter après validation.

Bon à savoir
Pour le web privilégier un enregistrement HTTPS. Il suit les mêmes règles que SVCB et ajoute des champs utiles aux navigateurs.

Où utiliser un SVCB record

Sur un nom de service dédié comme _imap._tcp ou _smtp._tcp quand le protocole le prévoit.
À l'apex en mode alias si l'on doit viser un autre nom tout en évitant un CNAME.
SVCB peut coexister avec A et AAAA. Les clients qui ne comprennent pas SVCB utilisent les adresses classiques.

À éviter
Chaîner des cibles sans raison. Aller à l'essentiel.
Publier des paramètres incohérents avec le service réel.
Oublier A ou AAAA sur la cible quand le client doit s'y rendre

Vérifier en ligne

Un DNS lookup en ligne permet d'entrer un nom de domaine. On voit la priorité la cible les paramètres et le TTL tels que perçus depuis Internet. C'est un premier contrôle utile. Faire ensuite un test local depuis sa machine.

Vérifier sous Windows

Windows fournit nslookup. On peut l'utiliser en mode interactif.

Résolveur local
nslookup
set q=svcb
exemple.com
Résolveur précis
nslookup
set q=svcb
server 1.1.1.1
exemple.com

La première partie interroge selon la configuration réseau de la machine. La seconde force l'usage d'un résolveur tiers ici celui de Cloudflare.

Vérifier sous Linux et sous Mac

Sur ces systèmes la commande dig est pratique et facile à utiliser.

Résolveur local
dig SVCB exemple.com
Résolveur précis
dig SVCB exemple.com @1.1.1.1

Lecture rapide des réponses

Une priorité à zéro indique un alias. Une valeur supérieure à zéro indique un service avec paramètres.
La présence de alpn guide le choix du protocole. Les champs ipv4hint et ipv6hint ne sont que des indices.
Un TTL restant élevé peut expliquer un décalage après un changement.

Mise en place simple

  1. Définir le besoin. Alias vers une cible ou publication de paramètres.
  2. Réduire le TTL à 300 voire 60 secondes quelques heures avant la mise en place.
  3. Publier le SVCB avec la priorité et les paramètres choisis.
  4. Vérifier avec nslookup ou avec la commande dig depuis plusieurs réseaux.
  5. Remonter le TTL quand tout est stable.

Astuce pratique
Documenter la priorité la cible et chaque paramètre. Conserver la date et la raison du changement. Cette trace facilite les contrôles

Cas fréquents

Service d application

Publier un SVCB sur _api._tcp pour annoncer alpn et port. L'application sait comment se connecter.

Site derrière un fournisseur

Utiliser le mode alias pour viser le nom fourni par le service. Garder A et AAAA sur la cible.

Passage à HTTP en version trois

Sur un site web publier un enregistrement HTTPS dédié avec alpn h3. Ajouter ech si le service le propose.

Dépannage rapide

  1. Si les clients ignorent SVCB vérifier que A et AAAA existent sur la cible.
  2. Si le mauvais protocole est choisi vérifier alpn.
  3. Si une boucle apparaît vérifier que la cible ne renvoie pas vers le nom d origine.
  4. Si la réponse reste ancienne malgré la mise à jour attendre l expiration du TTL et purger le cache du résolveur local si possible.

En résumé, un enregistrement SVCB décrit un service et peut servir d'alias contrôlé. Les paramètres guident le client sans remplacer A et AAAA. Un TTL bien réglé facilite les transitions. La vérification passe par un outil en ligne puis par nslookup et par dig.
Avec ces repères la gestion reste claire. Les changements se déroulent sans stress. Les utilisateurs accèdent au service sans incident.