Overview
The DNSSEC oracle implements DNSSEC (DNS Security Extensions) validation on Ethereum. It verifies chains of signed DNS records against trusted root anchors, ensuring that only legitimate DNS owners can prove ownership. Location:contracts/dnssec-oracle/DNSSECImpl.sol
Interface: contracts/dnssec-oracle/DNSSEC.sol
DNSSEC Background
DNSSEC adds cryptographic signatures to DNS records:- Trust Anchors: Root zone public key hashes (DS records)
- Chain of Trust: Each zone signs its child zones
- RRSIG Records: Contain cryptographic signatures of DNS records
- DNSKEY Records: Contain public keys used for verification
- DS Records: Contain hashes of child zone keys
Contract Architecture
DNSSEC Interface
The abstract interface defines the core verification function:DNSSECImpl Implementation
The concrete implementation extends the interface:Core Data Structures
RRSetWithSignature
Represents a signed set of DNS resource records:SignedSet
Parsed representation of a signed RRSet:Main Functions
verifyRRSet (External)
Validates a chain of signed DNS records using the current block timestamp.input: Array of signed RRSets forming a chain from root to target
rrs: The validated RR data from the last RRSetinception: Signature inception time
- Starts with trust anchors as initial proof
- Validates each RRSet in sequence
- Each RRSet’s data becomes proof for the next
- Returns final validated data
verifyRRSet (Public with Timestamp)
Validates a chain at a specific timestamp.input: Array of signed RRSetsnow: Unix timestamp to validate signatures against
Validation Process
Signature Validation
The validation process follows RFC 4035:-
Parse the signed set:
-
Validate label count:
-
Check signature validity period:
-
Verify cryptographic signature:
Serial Number Arithmetic
DNSSEC uses RFC 1982 serial number arithmetic for time comparisons:Signature Verification
Verification with DNSKEY
Verifies a signature using a known public key:- Extracts DNSKEY from proof
- Validates key properties (protocol, flags)
- Computes key tag
- Verifies signature using algorithm contract
Verification with DS
Verifies using a Delegation Signer (hash of key):- Verifies RRSet is self-signed with DNSKEY
- Computes hash of DNSKEY
- Compares hash with DS record from proof
Key Verification
- Protocol must be 3 (DNSSEC)
- Algorithm must match signature
- Key tag must match signature
- Zone flag (bit 7) must be set
- Signature must verify using algorithm contract
Algorithm and Digest Management
Algorithm Registry
Maps algorithm IDs to verification contracts:- 5: RSASHA1
- 7: RSASHA1-NSEC3-SHA1
- 8: RSASHA256
- 13: ECDSAP256SHA256
- 14: ECDSAP384SHA384
Digest Registry
Maps digest type IDs to verification contracts:- 1: SHA-1
- 2: SHA-256
- 4: SHA-384
Trust Anchors
The oracle is initialized with root zone trust anchors:DNS Record Types
Key DNS record type constants:RRUtils Library
The RRUtils library provides utilities for parsing DNS records:DNSKEY Structure
DS Structure
Key Tag Computation
Computes the DNSSEC key tag for a DNSKEY:Errors
InvalidLabelCount
SignatureNotValidYet
SignatureExpired
InvalidClass
SignatureTypeMismatch
InvalidProofType
NoMatchingProof
Events
AlgorithmUpdated
DigestUpdated
Usage Example
Security Considerations
Trust Anchor Security
The security of the entire system depends on the trust anchors:- Must be from authentic root zone
- Should be updated when root keys rotate
- Compromise of root keys compromises entire system
Algorithm Security
Only use secure, well-tested algorithms:- Older algorithms like RSASHA1 (5) may be weak
- Prefer modern algorithms like ECDSAP256SHA256 (13)
Time Validation
Signature validity periods must be checked:- Prevents replay of expired signatures
- Ensures signatures haven’t been created with future timestamps
- Uses serial number arithmetic to handle wraparound
Gas Considerations
DNSSEC verification is computationally expensive:- Long proof chains use more gas
- RSA verification is more expensive than ECDSA
- Consider gas limits when submitting proofs
Limitations
The implementation has some intentional limitations per RFC 4034/4035:- No NSEC/NSEC3 support: Only positive proofs are accepted
- No wildcard support: Wildcard proofs will not validate
- No TTL enforcement: TTLs are ignored as data isn’t stored
- No canonicalization check: Names should be canonical but aren’t verified
Related Contracts
- DNSRegistrar - Uses oracle to verify claims
- Algorithm - Interface for signature algorithms
- Digest - Interface for hash functions