Introduction to DNSSEC

12,581 views

Published on

Background of what DNSSEC, how it works, and what it does.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
12,581
On SlideShare
0
From Embeds
0
Number of Embeds
42
Actions
Shares
0
Downloads
361
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Introduction to DNSSEC

  1. 1. Introduction to DNSSEC Tom Daly Dynamic Network Services, Inc. tom@dyn-inc.com
  2. 2. Agenda • Generic review of DNS • What is DNSSEC and why is it important? • Design concepts • General implementation • Implementation specific for Dyn Inc.
  3. 3. Generic Review of DNS • DNS maps hostnames (www.example.com) to IP addresses (192.0.2.100). • Authoritative DNS servers are the “keepers of authority” - they know the real and truthful answers to DNS questions. • Recursive DNS servers are the “searchers of authority” - they have to figure out the right questions to ask and which servers to ask!
  4. 4. Delegation of Authority in DNS • Resolvers start with the root zone (.) and work the domain to the left. • . -> The root servers • com. -> The Verisign .com servers • example.com -> The Zone's Authoritative DNS • Let's walk through this!
  5. 5. www.example.com Recursive example.com A? Resolver
  6. 6. www.example.com. Root Servers www.example.com A? Recursive (primed with root hints) Waiting... I don't know the answer, but go ask: a.gtld-servers.net b.gtld-servers.net c.gtld-servers.net Resolver ...
  7. 7. www.example.com. www.example.com A? a. gltd-servers.net Resolver Waiting.... I don't know the answer, but go ask: Resolver ns1.example.com ns2.example.com ...
  8. 8. www.example.com. ns1.example.com www.example.com A? Recursive Waiting... Oh, you want 192.2.0.100 AND this answer is authoritative! Resolver
  9. 9. www.example.com. Recursive www.example.com A? www.example.com A Resolver 192.0.100
  10. 10. Agenda • Generic review of DNS • What is DNSSEC and why is it important? • Design concepts • General implementation • Implementation specifics for Dyn Inc.
  11. 11. What is DNSSEC? • DNS Security Extensions (DNSSEC) are defined by RFC 4033, 4034, 4035. • Relies on standard private/public key crypto. • Adds cryptographic signature to DNS answers returned. • Its kinda / sorta like SSL authentication for the DNS.
  12. 12. Why is DNSSEC Important? • DNS uses UDP for packet transport, so when you query, any returned UDP packet could be the answer! • The returned UDP packet has to have the right source IP, source port, destination IP, destination port, DNS query ID, and pass balliwick checking. • This is super easy to spoof! This is called “DNS Pharming” or “DNS Cache Poisoning”
  13. 13. The Basic Attack Vector ns1.example.com www.example.com A? Oh, you want 192.0.2.100 AND this answer is authoritative! Recursive You want 66.31.95.100 AND this answer is authoritative! AND here www.example.com A? are new nameservers for example.com: ns1.attacker.com ns2.attacker.com Resolver Attacker
  14. 14. example.com just got p0wn3d! • Only if the attacker got his answer to the resolver before the real server answered! • Only if the source IP, source port, destination IP, destination port, DNS query ID, and balliwick matched! • Our anycasted network helps with this a LOT – we answer queries faster, hopefully before the attacker can. • This attack can take hours to be successfully executed.
  15. 15. 2008 DNS Summer of FearThe Kaminsky Attack • Uses the same basic Pharming attack, but does it much much faster! • Forces Recursive DNS servers to ask questions they wouldn't normally ask. Making them ask more questions give more opportunities to inject hacker data. • Can be successfully executed in minutes! • Randomizing the DNS source port helps prevent this, but is far from perfect.
  16. 16. A Far Worse Attack - .com p0wn3d Root Servers www.example.com A? I don't know the answer, but go ask: Recursive a.gtld-servers.net (primed with b.gtld-servers.net root hints) c.gtld-servers.net ... www.example.com A? You want 66.31.95.100. AND here are new nameservers for .com: ns1.attacker.com ns2.attacker.com Resolver Attacker
  17. 17. DNSSEC Fixes This! • DNSSEC fixes this by using cryptography to check each answer down the line of resolution. • Each answer gets authenticated for validity down the line. • Pharming attacks can still happen, but they won't have the right keys, so their answers won't be accepted. • Doesn't fix generic DDoS attacks against the DNS.
  18. 18. Agenda • Generic review of DNS • What is DNSSEC and why is it important? • Design concepts • Generic implementation • Implementation specifics for Dyn Inc.
  19. 19. Design Concepts - Authoritative • Sign your zone with DNSSEC records: – RRSIG – Crypto signatures for A, AAAA, NS, MX, etc. Tracks the type and number at each “node.” – NSEC or NSEC3 – Confirms the NXDOMAIN response. – DNSKEY – Public keys for the entire zone. Private side is used to generate RRSIGs. – DS Record – Handed up to the parent zone to authenticate the NS records up there.
  20. 20. Zone Signing • Two crypto key-pairs are used in DNSSEC: • Zone Signing Key (ZSK) – Signs the zone records, and itself – Public part becomes the DNSKEY at zone apex. • Key Signing Key (KSK) – Signs the keys at the apex of the zone – Public part becomes also a DNSKEY at zone apex. – Can be exported as SEP / DS for that zone!
  21. 21. Zone Signing Record Relationships DS (for Parent) DNS KEY KSK RRSIG by KSK KSK Private Key Used for Signing DNS KEY ZSK RRSIG by ZSK SOA RRSIG by ZSK ZSK Private Key Used for Signing NS RRSIG by ZSK A RRSIG by ZSK
  22. 22. Rollover • RRSIGs have a lifetime they are good for encoded in them, i.e. valid for 30 days. • DNSKEYs also have a lifetime encoded in them. • Per NIST SP800-01: – KSK – Rollover every 12 months (1 year) – ZSK – Rollover every 1 month (30 days) • Current and future keys get published simultaneously to help support this.
  23. 23. Resolver - Trust Anchors • Trust anchors are the records used to validate apex RRSIGs for DNSKEY (usually KSK). • Come in forms of: – Manually obtained trusted keys or ITAR – DS records at parent – DNS Lookaside Validation – Root Signed SEP • Root needs to be signed to create a full chain of trust.
  24. 24. Resolver - Validation • Formulate DNS query, with DNSSEC enabled, and await response. • Along with the response (A record), an RRSIG will be delivered back. • Use DNSKEY from the zone (public part of ZSK) to validate the RRSIG. • Validate that DNSKEY with corresponding RRSIG. • Validate that RRSIG using a public key from KSK. Use the trust anchor here. • If you don't have a trust anchor, traverse upwards for a DS, then validate. Repeat as needed.
  25. 25. Validation Example (installed trust anchor) .com example.com DS validates RRSIGs signed with KSK (SEP) example.com DNSKEY example.com RRSIG for Validates RRSIGs signed DNSKEY by KSK with ZSK Validates Type DNSKEY www.example.com www.example.com A RRSIG for A by ZSK 127.0.0.1 Validates Type A RRsets
  26. 26. Manually Obtaining Trust Anchors • Go to DNS admin, ask for a trust anchor • Securely transmit • Get new anchor when the KSK rolls over • Wash, rinse, repeat • Problem: Know what zones are signed! Good luck finding them all.
  27. 27. Use ITAR for trust anchors • Go to IANA to obtain a trust anchor • Securely transmit over HTTPS (no DNSSEC, chicken and the egg problem here) • Note KSK rollover, fetch updates when needed • Wash, rinse, repeat • Problem: Limited to TLDs
  28. 28. Use DNS Lookaside Validation • If you can't find a DS at the parent, go find it from a DLV service. • You trust the DLV service ahead of time. • You get DS records from the DLV. • Problem: Not everyone contributes keys to DLV.
  29. 29. Solution: Sign the Root and provide SEP • The Root SEP doesn't exist! – Root DNS Zone is not signed, so we can't validate keys from it. – Forced to use ITAR, DLV, and other methods for now. • Can't we sign the root? – Iraq isn't exactly keen on the idea of a USA / DHS signed root zone, are they?
  30. 30. Agenda • Generic review of DNS • What is DNSSEC and why is it important? • Design concepts • Generic implementation • Implementation specifics for Dyn Inc.
  31. 31. Generic Implementation Master DNS DNS Slave #1 (Unsigned Zones) DNS Slave #2 DNSSEC Private Keys DNS Master (dnssec-keygen) DNS Slave #3 DNSSEC Private Keys (dnssec-keygen) DNS Slave #4
  32. 32. dnssec-keygen • Generates ZSKs and KSKs for zones • Private Keys should be kept offline – if someone can get the private parts of your ZSK and KSK, they can sign your zone as YOU – security is busted. • Key store could be as simple as a USB Thumb Drive or as complex as a two-man-rule Hardware Security Module (HSM) • This is the major hurdle to automating DNSSEC.
  33. 33. dnssec-signzone • Uses ZSKs and KSKs to sign a regular zone file, generate DS records, and produces a signed zone file. • Once signed, updates to the zone can be signed incrementally. • This takes CPU time! (thanks for #s Matt) – 44,000 records takes 6m36s initially. Incremental signing after that takes about 30s. – 3,000 records takes 27s initially. Incremental signing after that takes about 1-3s.
  34. 34. Other Needs • Neither application above: – Maintains keys in a database – Performs rollovers – Watches expiry times for keys – Pushes keys to DLV, ITAR, or other SEP repositories • Need more tools to do this! • These are major hurdles for DNSSEC!
  35. 35. Agenda • Generic review of DNS • What is DNSSEC and why is it important? • Design concepts • Generic implementation • Implementation Specifics for Dyn Inc.
  36. 36. Dyn Inc. Proposed Implementation • Dynect will use existing tools: – key generation – zone signing • Dynect will develop new tools: – Key storage database (secure but automated) – Key rollover – DS record management and DLV
  37. 37. Summary • DNS Pharming is bad. Think bankofamerica.com gets p0wn3d. • DNSSEC is the answer. • DNSSEC is hard. • We have to make it as easy as we made DNS for the Average Joe administrator.

×