RFC 4033 / START HERE
DNSSEC, before the details
DNSSEC: DNS Security Extensions
DNSSEC adds a way to authenticate DNS data using digital signatures. This RFC introduces its purpose and security model.
The idea in one picture
A zone signs its DNS data
A resolver checks a trust chain
Forged data can be detected
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
An ordinary DNS answer does not by itself prove that its records came from the expected authority. DNSSEC adds authenticity and integrity checks, not secrecy.
A familiar example
A validating resolver checks signed DNS data before accepting the answer for a domain.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Verify a signed record setDNSSEC authenticates the origin and integrity of DNS RRsets, not a server’s transport connection.→
- Follow a chain of trustA validator starts with a configured trust anchor and follows authenticated delegations.→
- Authenticate a missing name or typeDNSSEC must prove negative answers as well as existing records.→
- Protect the last hop separatelyA validating recursive resolver and a stub client are distinct trust boundaries.→
- Check cache lifetime and signature timeTTL expiration and RRSIG validity periods solve different timing problems.→
This introduction explains RFC 4033 (2005). Read the original RFC ↗