Table of Contents DNS security Karst Koymans Informatics Institute University of Amsterdam (version 1.19, 2011/09/27 14:18:11) Friday, September 23, 2011 The long (and winding) road to the DNSSEC specification On locks and seals Chain of Trust Details of RR s used in the chain of trust Denial of existence Ignoring wildcards Including wildcard processing Details of RR s used in denial of existence Resolver and protocol issues DNSSEC specification Alternative DNS security mechanism Original specification from January 1997 RFC 2065 Revised specification from March 1999 RFC 2535 Incorporated feedback from early users Had deployment problems, especially scaling issues Final specification from March 2005 DNSSEC-bis (RFC 4033, 4034 and 4035) Final addition from February 2008 NSEC3 (RFC 5155) DNSCurve Idea by Dan Bernstein Proposed in August 2008 (after NSEC3 spec) Encrypts and authenticates on the link level Signs communication packets, not resource records Uses labels of name servers to distribute public keys Uses state of the art elliptic curve cryptography for speed Worth a read at http://dnscurve.org/ Also see http://curvecp.org/
Secret key cryptography Public key cryptography encryption Use one lock and two identical keys Use a lock, which closes without key, and one key to open (Source: Cisc, University of Hong Kong) (Source: Cisc, University of Hong Kong) Public key cryptography signing Trusted party and/or certificate authority Use an unforgeable seal and check the characterisitics Use a trusted repository or party Create a chain of trust by signing public keys (Source: Cisc, University of Hong Kong) (Source: Cisc, University of Hong Kong)
DNSSEC-bis resource records DNSSEC-bis chain of trust (1) RRSIG: signatures of RRsets DNSKEY: public keys used to verify these signatures DS: hash of public key of child zone (secure entry point) used to create the chain of trust To validate a resource record set RRset Validate RRSIG(RRset) by using a ZSK (zone signing key) from the DNSKEY RRset Validate RRSIG(DNSKEYset) by using a KSK (key signing key) from that same DNSKEY RRset Validate the KSK by using a DS (present in the parent zone) which contains a hash of the KSK the KSK used is called a SEP (Secure Entry Point) DNSSEC-bis chain of trust (2) Chain of Trust illustration Continue validating one level higher in the hierarchy Use DS as RRset and iterate Use trusted anchors for DNSKEY s or DS s to terminate for instance for checking root zone keys Authority around a cut is now as follows NS and DNSKEY are authoritative on the child side of the cut (zone apex) DS is authoritative on the parent side of the cut (delegation point) 1 2 3 Walking the Chain of Trust Locally configured Trusted key:. 8907 $ORIGIN.. DNSKEY ( ) 5TQ3s (8907) ; KSK DNSKEY ( ) lase5 (2983) ; ZSK RRSIG DNSKEY ( ) 8907. 69Hw9.. net. DS 7834 3 1ab15 RRSIG DS ( ). 2983 $ORIGIN ripe.net. ripe.net. DNSKEY ( ) rwx002 (4252) ; KSK DNSKEY ( ) sovp42 (1111) ; ZSK 8 RRSIG DNSKEY ( ) 4252 ripe.net. 5t... www.ripe.net. A 193.0.0.202 RRSIG A ( ) 1111 ripe.net. a3... 9 7 5 4 $ORIGIN net. net. DNSKEY ( ) q3dew (7834) ; KSK DNSKEY ( ) 5TQ3s (5612) ; ZSK RRSIG DNSKEY ( ) 7834 net. cmas... ripe.net. DS 4252 3 1ab15 RRSIG DS ( ) net. 5612 6 http://www.nlnetlabs.nl/ Albuquerque Feb 2006 (Source: Olaf Kolkman, RIPE NCC, NLnet Labs)
RRSIG record example from RFC 4034 RRSIG record content host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( 20030220173103 2642 example.com. ojb1w6wngv+ldvq3wdg0mqkg5iehjrip8wtr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) Type covered Algorithm Labels TTL Expiration and Inception Key Tag Signer s Name Signature Record type this RRSIG is about Signature algorithm used; 5 is RSA/SHA-1 Number of labels of owner (without root) Original time to live Signature validity date bounds To help find (not identify) the signing key Owner name of zone and key to use Signature (in Base64) DNSKEY record example from RFC 4034 DNSKEY record content example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31gajiqky+5cptlr3buxa10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL 742iU/TpPSEDhm2SNKLijfUppn1U anvv4w== ) Flags Protocol Algorithm Public key Zone key (KSK+ZSK); Secure entry point (KSK) Always 3 (for backward compatibility with KEY RR) Signature algorithm used; 5 is RSA/SHA-1 Key used for signing (in Base64)
DS record example from RFC 4034 and 4509 DS record content dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz fwjr1aytsmx3tgkjanxvbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egxd/m5+x7orzkbambcvdflu Uh6DhweJBjEVv5f2wwjM9Xzc nof+epbtg9dmbmadjfdc2w/r ljwvfw== ) ; key id = 60485 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A98631FAD1A292118 ) ; SHA-1 dskey.example.com. 86400 IN DS 60485 5 2 ( D4B7D520E7BB5F0F67674A0C CEB1E3E0614B93C4F9E99B83 83F6A1E4469DA50A ) ; SHA-256 Key Tag Algorithm Digest Type Digest To help find (not identify) the signing key Signature algorithm of the signing key Hashing algorithm used; 1 is SHA-1, 2 is SHA-256 Sequence of case-insensitive hexadecimal digits Positive and negative answers Methods for denial of existence Proving existence (and authenticity) is elaborate, but easy It uses standard public key cryptography signing mechanisms Proving non-existence is much more difficult There is nothing to sign Empty non-terminals Wildcards Doing a zone transfer Only possible for trusted clients On the fly (realtime) signing of negative replies Often too compute intensive Enumerating the zone Makes zone walking possible Unless the real names are hidden somehow
More DNSSEC-bis resource records Example zone NSEC: authenticated denial of existence Uses canonical ordering to list domain names in a zone Lexicographic ordering for labels by considering them as unsigned left-justified octet strings Lexicographic ordering for domain names as sequence of labels, in fact walking the domain name tree in preorder traversal No support to thwart zone enumeration NSEC3 introduced later to frustrate zone enumeration All domain names are disguised as hashes One can still count the number of domain names 1 data empty TXT * 2 leaf TXT 0 apex SOA, NS 3 data TXT nxdomain 4 wildcard TXT 5 * the TXT matches Proving Nodata with matching NSEC record Proving Nodata for empty non-terminals Nodata means No Error, but also no data So some QTYPE s have data, but the queried QTYPE has not The NSEC record at the owner contains a bitmap for existing types Given the query data.apex A Consider the NSEC record data.apex NSEC leaf.*.empty.apex TXT An empty non-terminal implies No Error, but also no data But now no QTYPE s at all have data There is no NSEC record for the empty non-terminal The empty non-terminal is covered (skipped) by some NSEC record Given the query empty.apex A Consider the NSEC record data.apex NSEC leaf.*.empty.apex TXT Server should include this NSEC record in the answer Client should verify this NSEC record is the right one
Proving NXDOMAIN ( Name Error or No such domain ) NSEC records in the (positive) answer case There is no NSEC record for the non-existing domain name The non-existing domain name is covered by some NSEC record Given the query nxdomain.apex A Consider the NSEC record data.empty.apex NSEC wildcard.apex TXT Server should include this NSEC record in the answer Client should verify this NSEC record is the right one What is the difference with the previous case? If a domain name is synthesized from a wildcard record we also need proof that this has been done correctly The next closer is the last (non-existing) domain name on the path to the closest encloser The next closer domain name is covered by some NSEC record Given the query matches.the.wildcard.apex TXT Consider the NSEC record *.wildcard.apex NSEC apex TXT Server should include this NSEC record in the answer Client should verify this NSEC record is the right one Proving Nodata for wildcard expansions Proving NXDOMAIN revisited This is a combination of previous cases Use the NSEC type bitmap to prove queried QTYPE is not available Use a covering NSEC RR for the next closer domain name Given the query matches.the.wildcard.apex A Consider the NSEC record *.wildcard.apex NSEC apex TXT This sole NSEC record works for both requirements above Server includes and client verifies this NSEC record What if the wildcard happens to be an empty non-terminal? Find the NSEC record that covers the next closer domain name Moreover find the NSEC record that covers the (non-existing) source of synthesis Given the query nxdomain.apex A Consider the NSEC record data.empty.apex NSEC wildcard.apex TXT And also the NSEC record apex NSEC data.apex SOA NS Server includes and client verifies these NSEC records
NSEC3 records NSEC record example from RFC 4034 NSEC3 also creates a (circular) chain, but uses hashes of the original domain names as labels for the owner domain names of the NSEC3 records also hashes empty non-terminals orders the hashes instead of the original domain names uses the NSEC3PARAM type to specify hashing parameters and indicate the use of NSEC3 instead of NSEC defines the Opt-Out flag to exclude insecure delegations from the chain alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 ) NSEC record content NSEC3 record example from RFC 5155 Next Domain Name Type Bit Maps Defined by a standard ordering Types present at the current owner This mechanism can be used to enumerate a complete zone... q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )... which is why certain organisations refuse to implement DNSSEC-bis NSEC chains wrap around and fork or join at a delegation point or zone apex NSEC3 RR s can anonymise the NSEC records
NSEC3 record content Protocol flags Hash Algorithm Flags Iterations Salt Length Salt 1 Hash Length Next Hashed Owner Name Type Bit Maps 1 for SHA-1 Opt-out for skipping unsigned delegations Number of times hash is calculated 0-255 (not represented in text format) Prevents dictionary attacks 1-255 (not represented in text format) (binary data) Types present at the current owner DO (DNSSEC OK) Indicate that you want all DNSSEC-related information like RRSIG and NSEC(3) for normal queries, if available Presupposes use of EDNS0 CD (Checking Disabled) From (stub) resolver to (recursive) name server Indicate that you want to do checking yourself Also insecure (invalid) data is passed along Copied from name server side to resolver side in a recursive server AD (Authentic Data) From recursive name server to (stub) resolver Data has been verified successfully In most cases not set by authoritative server Checking is done at the resolver side 1 Hash Algorithm, Flags, Iterations and Salt are communicated to slave servers via the NSEC3PARAM Resource Record in the zone apex. Security status of RR s Secure Chain of trust exists and signature is valid Insecure Chain of trust exists and signature is invalid Results in SERVFAIL Bogus Chain of trust should exist but is broken Results in SERVFAIL Indeterminate Chain of trust does not exist