Der Auditor durchläuft die gesamte Vertrauenskette einer Domain in neun Pass/Fail-Schritten. Er beginnt im IANA-RDAP-Bootstrap-Register (data.iana.org/rdap/dns.json), um den autoritativen Registry-Server des TLD zu finden, und befragt diese Registry per RDAP — Registrar-Entität, Erstellungs-/Ablaufereignisse, EPP-Statuscodes, Nameserver und die secureDNS-Sicht der Registry. Parallel löst die DNSSEC-Seite über DNS-over-HTTPS auf (AliDNS mit Cloudflare/Google-Failover, wählbar): Sie holt das Root-DNSKEY-Set und prüft die SHA-256-DS-Digests der eingebetteten Root-Trust-Anchors (KSK-2017 Tag 20326 und KSK-2024 Tag 38696, konsistent mit dem von IANA veröffentlichten root-anchors.xml) und steigt dann ab — der von der Root für den TLD publizierte DS wird aus dem DNSKEY-RDATA des TLD neu berechnet, der vom TLD für die Domain publizierte DS aus dem RDATA des Apex-DNSKEY, byte für byte. Abweichungen, abgelaufene oder bald ablaufende RRSIG-Signaturen (Seriennummern-Arithmetik über die 32-Bit-Zeitfelder), unsignierte Delegationen und fehlende DS-Records werden mit exakten Key Tags, Algorithmen und berechneten Digests markiert. Umfang: Die DS↔DNSKEY-Digest-Übereinstimmung ist das kryptografische Bindeglied der Delegationskette; die volle RRSIG-Signaturprüfung je RRset wird über das AD-Flag des Resolvers und Ablaufprüfungen berichtet, nicht über lokale RSA/ECDSA-Verifikation.