L’auditeur parcourt toute la chaîne de confiance d’un domaine en neuf étapes pass/fail. Il commence par le registre bootstrap RDAP de l’IANA (data.iana.org/rdap/dns.json) pour découvrir le serveur de registre autoritaire du TLD, puis interroge ce registre via RDAP — entité du registrar, événements de création/expiration, codes de statut EPP, serveurs de noms et vision secureDNS du registre. En parallèle, le volet DNSSEC résout via DNS-over-HTTPS (AliDNS avec bascule Cloudflare/Google, au choix) : il récupère le jeu DNSKEY racine et vérifie les digests SHA-256 DS des ancres de confiance racine embarquées (KSK-2017 tag 20326 et KSK-2024 tag 38696, conformes au root-anchors.xml publié par l’IANA), puis descend — le DS publié par la racine pour le TLD est recalculé depuis le RDATA du DNSKEY du TLD, et le DS publié par le TLD pour le domaine depuis le RDATA du DNSKEY de l’apex, octet par octet. Les décalages, signatures RRSIG expirées ou proches de l’expiration (arithmétique séquentielle sur les champs 32 bits), délégations non signées et enregistrements DS manquants sont signalés avec leurs key tags, algorithmes et digests calculés exacts. Périmètre : la correspondance des digests DS↔DNSKEY est la colle cryptographique de la chaîne de délégation ; la validation complète des signatures RRSIG par RRset est rapportée via le drapeau AD du résolveur et les contrôles d’expiration, sans vérification RSA/ECDSA locale.