Préparez-vous une zone ou vérifiez-vous la zone publiée ?
Le générateur produit un projet de zone ; DNS Query lit les enregistrements A, AAAA, MX, TXT, NS et CNAME publiés. Le fichier créé ne prouve aucune propagation.
Elysia Tools
Navigation mobile
Workflow Playbook
Préparez une zone DNS, comparez les réponses publiées, puis contrôlez la délégation DNSSEC et le certificat HTTPS réellement présenté.
Dossiers
Ce parcours s'adresse à l'administrateur qui lance un nouvel hôte ou change la zone d'un domaine existant. Relevez le bureau d'enregistrement, les serveurs de noms attendus, les cibles web, les routes de messagerie et le nom HTTPS visité. Dans dns-zone-file-record-builder, préparez les enregistrements SOA, NS, A ou AAAA, CNAME, MX et TXT réellement nécessaires. Relisez les noms propriétaires, les noms cibles complets et les éventuels conflits. Le résultat est un projet de zone lisible, pas une opération de publication chez le fournisseur DNS ni une preuve de visibilité publique.
Une fois la modification publiée, utilisez dns-query pour chaque hôte et chaque type pertinent. Conservez l'heure, le résolveur, la valeur obtenue et la valeur attendue. L'outil emploie actuellement le résolveur système même si un serveur de noms personnalisé est renseigné : ne présentez donc pas la réponse comme une interrogation directe du serveur faisant autorité. Si l'ancienne valeur persiste, vérifiez le TTL et les caches avant de changer à nouveau une configuration peut-être correcte.
Quand DNSSEC est activé, lancez whois-rdap-dnssec-chain-validator-and-iana-bootstrap-trust-auditor afin d'examiner la délégation et les maillons DS-DNSKEY. Un ancien DS conservé après une migration DNS constitue un incident différent d'une délégation volontairement non signée. Consignez le maillon problématique ; une zone non signée n'est pas une chaîne validée.
Après résolution vers le bon service, testez le nom public avec ssl-checker et vérifiez les dates et noms couverts par le certificat présenté. certificate-decoder permet d'inspecter un PEM ou CRT que vous possédez : émetteur, noms alternatifs et empreinte. Ce décodage seul ne dit pas ce que reçoit le visiteur. Comparez les deux seulement si vous soupçonnez un déploiement incorrect. Terminez par un compte rendu des valeurs attendues et observées, heures, état DNSSEC et contrôle HTTPS. Pour une panne de trafic ou de livraison, consultez network-triage-debugging ; pour choisir un nom disponible, domain-name-ideation-and-availability.
Guide de workflow
Construisez SOA, NS et les enregistrements web ou mail nécessaires ; ce texte est un plan à publier chez votre fournisseur, pas une zone déjà active.
Après publication, interrogez chaque hôte et type A, AAAA, MX, TXT, NS ou CNAME utile ; notez l'heure et le résolveur.
Examinez les données RDAP et, pour une zone signée, les liens DS-DNSKEY ; distinguez une absence volontaire de signature d'une chaîne rompue.
Contrôlez l'hôte en ligne avec SSL Checker ; analysez séparément un PEM candidat pour comparer émetteur, noms alternatifs, dates ou empreinte.
Le générateur produit un projet de zone ; DNS Query lit les enregistrements A, AAAA, MX, TXT, NS et CNAME publiés. Le fichier créé ne prouve aucune propagation.
Vérifiez DS et DNSKEY si DNSSEC est activé. SSL Checker contrôle le certificat servi ; Certificate Decoder analyse uniquement un fichier PEM disponible.
Restez ici pour les preuves de mise en ligne ; passez à network-triage-debugging pour les captures, webhooks, fichiers hosts ou pannes de connexion.