zkDNSSEC

📜 Overview

zkDNSSEC is a privacy-preserving DNSSEC validator using zero-knowledge proofs (ZKPs). It allows users to prove that a DNS record (e.g., A, TXT, CNAME) is cryptographically signed under DNSSEC rules (RFC 4034) without revealing the record itself, its signature (RRSIG), or the queried domain name.

Key Points

1. Zero-Knowledge DNSSEC: Prove RRSIG validity while hiding all sensitive DNS data.
2. Web3 Compatibility: Generate proofs verifiable on Ethereum and other EVM chains (Groth16/PLONK).
3. Multi-Proof Systems: Support for SP1(Core/Compressed), Groth16, and PLONK backends.
4. RFC 4034 Compliance: Implements DNSSEC signing/validation logic natively in ZK circuits.

💡 Use Cases

• Private Domain Ownership Proof
• Trustless Cross-Chain Bridging: Prove a TXT record (e.g., _bridge.chain.example.com) authorizes a cross-chain transaction.
• DNSSEC-Anchored Confidential PKI: Certificate Authorities (CAs) use DNS (CAA/DANE records) to validate domain ownership, but queries leak certificate metadata. Prove a domain’s CAA or TLSA (DANE) record authorizes a TLS certificate without revealing the certificate’s public key or DNS query.
• Light Client Bootstrapping: Light clients (e.g., Ethereum LES) rely on DNS for peer discovery, exposing them to sybil attacks. Validate peer lists via DNSSEC-signed ENR (Ethereum Node Records) with ZK proofs, ensuring peers are legitimate without trusting resolvers.
• and many more...

Input Data Collection

The prover begins by collecting the raw DNS data required for DNSSEC validation:

RRset: The canonical DNS record set (e.g., example.com. 3600 IN A 1.2.3.4) containing the owner name, TTL, class, type, and RDATA.

RRSIG: The DNSSEC signature record, which includes metadata such as the signer’s name, algorithm (e.g., RSA/SHA256), inception/expiration timestamps, and the cryptographic signature itself.

DNSKEY: The public key corresponding to the zone’s ZSK (Zone Signing Key), stored as a DNS record with flags, protocol, and algorithm identifiers.

These inputs are parsed and structured according to RFC 4034 specifications to ensure compatibility with DNSSEC’s signing rules.

RFC 4034 Message Construction

The core of DNSSEC validation lies in reconstructing the exact byte-for-byte message that was originally signed by the zone owner. This process adheres strictly to RFC 4034’s "Signed Data" format, which consists of:

• RRSIG RDATA Fields: The prover extracts critical fields from the RRSIG record, including:
• Algorithm: Specifies the cryptographic algorithm (e.g., RSA/SHA256).
• Labels: The number of labels in the original owner name.
• Original TTL: The TTL value of the RRset at signing time.
• Signature Expiration/Inception: Timestamps for validity checks.
• Canonical RRset Format: The RRset is converted to its canonical form:
• Lowercasing: Domain names are lowercased.
• Name Compression: DNS name compression is removed.
• Ordering: Records are sorted in canonical wire format order.
• Signature-Specific Data: The RRSIG’s signer name, algorithm, and labels are prepended to the canonical RRset to form the final message.

This reconstructed message is hashed using the algorithm specified in the RRSIG (e.g., SHA256) to produce a digest.

Signature Verification

The prover validates the DNSSEC signature within a zero-knowledge circuit by performing the following steps:

• Public Key Extraction: The DNSKEY’s public key is extracted from the DNSKEY RData. Hash Validation: The reconstructed message (from Step 2) is hashed using the algorithm specified in the RRSIG. -Signature Verification: The resulting digest is signed using the PublicKey and the signatures are compared
• Validity Window Checks: The current time is compared against the RRSIG’s inception and expiration timestamps to ensure the signature is active.

Zero-Knowledge Proof Generation

At last the prover generates a proof attesting to the correctness of the DNSSEC validation process.