1 / 42

Introduction to DNSSEC

Introduction to DNSSEC. AROC Bamako, Mali, 2010. What is DNSSEC?. DNS Problems. Cache-poisoning DNS interception Confidentiality Reliability Reflection attacks. Which of these does DNSSEC address?. Reflection Attacks. DNS servers can act as very efficient packet amplifiers

galia
Download Presentation

Introduction to DNSSEC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction to DNSSEC • AROC Bamako, Mali, 2010

  2. What is DNSSEC?

  3. DNS Problems • Cache-poisoning • DNS interception • Confidentiality • Reliability • Reflection attacks Which of these does DNSSEC address?

  4. Reflection Attacks • DNS servers can act as very efficient packet amplifiers • Use of UDP, small queries, large responses • DNSSEC makes DNS servers better packet amplifiers • Still lots of UDP, larger responses

  5. Reliability • In the grand scheme of things, DNSSEC does not help make your DNS more reliable • in fact it makes the DNS more brittle, and makes it harder to maintain reliable service

  6. Confidentiality • DNSSEC does not address confidentiality of queries or responses • anybody who can intercept a secure response can still see the details • there is no encryption here

  7. Integrity, Authenticity • DNSSEC provides a mechanism for data published in the DNS to carry cryptographic signatures • secure responses include signatures • clients receiving a secure response can tell whether it is authentic

  8. Three Slides about Cryptography

  9. Cryptography • Public Key Cryptography • X.509, PGP, ssh, DNSSEC • (Public, Private) Key Pairs • use the private key to sign data • use the public key to verify signature

  10. Private Key • The private key needs to be kept private and secure • the degree of security depends on what the key is used for • a compromised key means you can no longer expect people to trust signatures • a signature from a compromised key is more dangerous than no signature at all

  11. Public Key • The public key needs to be widely-distributed • it also needs to be accurate

  12. DNSSEC Protocol

  13. DNS Considerations • When using the DNS to distribute keys, we need to remember a few things • the DNS is widely-distributed • information does not update instantaneously • we need to think hard about TTLs and caches

  14. Public Keys in the DNS • In DNSSEC, we distribute public keys in the DNS itself • use the DNSKEY RRSet • supports different key sizes, cryptographic algorithms

  15. DNSKEY in the Wild • [octopus:~]% dig isoc.org DNSKEY +noall +answer • ; <<>> DiG 9.6.0-APPLE-P2 <<>> isoc.org DNSKEY +noall +answer • ;; global options: +cmd • isoc.org.14387INDNSKEY257 3 7 AwEAAcE/XrxyyTSkw3ly60jsF4gz5kvn4QM6E0plIjnnjENmeWNPZxNf BYIKZnJxf3GaoI+qFeqbSc085jOXZiBMSRMQFkfsJNZgCsyVhas3lMoM HXEcEewNCPWv2D6TCYGHiVJaTJ0+6we19hIZZlrgJxfPxOXx9CUAzltQ CCvGD055P+yexHdMNWNvcxqt+1qtVt03heIWhf6QH5lhWaIHQWMXJlky KrgVwXHZHcvUebXqhhJfGZhGGU64x7HpNP3llCRqsut7iWsMLo8yBl3m R7eo/pUc6HF3M9E7hl53fg722xMxVA60kkDZqTp1FUzOCK5AagY+ISNz mKtOLgPcxCs= • isoc.org.14387INDNSKEY256 3 7 AwEAAZj8B7CEDfD4C1iJRJkZCxi6dz+dbVhqUUenXLRBDDtgm1BoF3jq v1Yj+DW+UT29Mzcg1aTR3lXMV1DZcmvHytvtl1N+y02CFSgYVQ+GOxv0 HSRRJhpWTD9sv5/Pr42bJ8eyNZ8cauyIwsHnd+kpVY60Q36VhdK8ZnhZ x69wpwzF • [octopus:~]%

  16. RR Signing in DNSSEC • Each Resource Record Set (RRSet) can carry zero or more signatures • signatures appear in an RRSIG RRSet with the same owner name • signatures have an inception and expiry time • we need to re-sign regularly

  17. RRSIG in the Wild • [octopus:~]% dig www.isoc.org A +dnssec +noall +answer • ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.isoc.org A +dnssec +noall +answer • ;; global options: +cmd • www.isoc.org.16040INA212.110.167.157 • www.isoc.org.16040INRRSIGA 7 3 86400 20101014085009 20100930085009 33644 isoc.org. YhsanPDyYO9tilrwZEHituzhzG8OwF1Peq1MMmY3/q6bE82mSiDxxi/Q hH4GeoYO5EKrcfpuRWLcPNJ3f/3HEc/SCYvF4gPyezJ6XFcbFvUAG4y5 ZR+dt9KawvrDYlOxtk31xgLeWRm3ryOqJgH+8OGLAg2W77xapEdofkfd ENo= • [octopus:~]%

  18. Chain of Trust • If we can trust the public key which corresponds to the private key that made a signature, we can trust a signature • If we can trust a signature, we can trust the data that is signed • How do we trust the public key?

  19. Delegation Signer • DS is the Delegation Signer Resource Record • it carries a hash of a public key • it is signed • this is how we extend trust across delegations

  20. Chain of Trust Child Zone Parent Zone DNSKEY DNSKEY RRSIG(DS) RRSIG(RRSet) DS RRSet

  21. Chain of Trust Root ORG ISOC.ORG

  22. Root Anchor • At some point a validator needs to install a trust anchor into its software • root zone trust anchor • http://www.iana.org/dnssec/

  23. Two DNSKEY RRSets • Common practice in 2010 is to use two different DNSKEY RRSets per zone • ZSK – Zone Signing Key • used to sign the data in the zone • KSK – Key Signing Key • used to sign the DNSKEY RRSet

  24. ZSK • Since we need to re-sign the zone regularly, the ZSK needs to be on-line • The ZSK is the key that is used most often by validators, so we can make it smaller and save some CPU • We can change the ZSK we are using regularly without involving others

  25. KSK • The KSK is the key that corresponds to the DS record in our parent zone • We need to use the KSK to sign the ZSK, and then we can put it away in a safe place • no need to keep the KSK on-line • changing the KSK involves talking to our parent (update DS record)

  26. KSK and ZSK Parent Zone Child Zone DNSKEY(KSK) DNSKEY(ZSK) RRSIG(DNSKEY) RRSIG(DNSKEY) RRSIG(RRSet) RRSet DNSKEY(KSK) DNSKEY(ZSK) RRSIG(DNSKEY) RRSIG(DNSKEY) RRSIG(DS) DS

  27. [KZ]SK in the Wild • [octopus:~]% dig isoc.org DNSKEY +noall +answer • ; <<>> DiG 9.6.0-APPLE-P2 <<>> isoc.org DNSKEY +noall +answer • ;; global options: +cmd • isoc.org.14387INDNSKEY257 3 7 AwEAAcE/XrxyyTSkw3ly60jsF4gz5kvn4QM6E0plIjnnjENmeWNPZxNf BYIKZnJxf3GaoI+qFeqbSc085jOXZiBMSRMQFkfsJNZgCsyVhas3lMoM HXEcEewNCPWv2D6TCYGHiVJaTJ0+6we19hIZZlrgJxfPxOXx9CUAzltQ CCvGD055P+yexHdMNWNvcxqt+1qtVt03heIWhf6QH5lhWaIHQWMXJlky KrgVwXHZHcvUebXqhhJfGZhGGU64x7HpNP3llCRqsut7iWsMLo8yBl3m R7eo/pUc6HF3M9E7hl53fg722xMxVA60kkDZqTp1FUzOCK5AagY+ISNz mKtOLgPcxCs= • isoc.org.14387INDNSKEY256 3 7 AwEAAZj8B7CEDfD4C1iJRJkZCxi6dz+dbVhqUUenXLRBDDtgm1BoF3jq v1Yj+DW+UT29Mzcg1aTR3lXMV1DZcmvHytvtl1N+y02CFSgYVQ+GOxv0 HSRRJhpWTD9sv5/Pr42bJ8eyNZ8cauyIwsHnd+kpVY60Q36VhdK8ZnhZ x69wpwzF • [octopus:~]%

  28. DS in the Wild • [octopus:~]% dig @a0.org.afilias-nst.org ISOC.ORG SOA +dnssec +noall +auth • ; <<>> DiG 9.6.0-APPLE-P2 <<>> @a0.org.afilias-nst.org ISOC.ORG SOA +dnssec +noall +auth • ; (1 server found) • ;; global options: +cmd • ISOC.ORG.86400INNS[...] • ISOC.ORG.86400INDS3330 7 2 7AD5E47FFFFA05AE70D5166E01B7836E34AD3032541D95DB9D1E9D7D 3AFB33D4 • ISOC.ORG.86400INDS3330 7 1 268B71BF480AE2C1484BB1DBA7E0A42089D90298 • ISOC.ORG.86400INRRSIGDS 7 2 86400 20101009155117 20100925145117 37812 org. IMqcyadyAGU+DynuTCz7JgJga+jjEii7PAxQha+q0k8AoGLzhwaI1kWQ bDgt7fLKi8HiJPX5eOouGVvS2RIx82+wNabM9/1cGHO41xYk3t/ttP/L GkqjewoAsw+6X/2k92FnEUqkIotlWuXJSVvqzv4FDh0LRF+wjxc2IYMa CQI= • [octopus:~]%

  29. DNS Transport • Plain old DNS was optimised to work over UDP with small packets (512 bytes) • fall-back to TCP • Modern DNS supports larger messages over UDP (EDNS0, RFC 2671) • DNSSEC means larger DNS messages • beware of faulty assumptions in firewalls!

  30. The Rest • How to provide benefits of DNSSEC to end-users? • validation in resolvers (AD bit) • validation in applications (e.g. browser plug-ins) • early days

  31. The Rest • Verifiable deniability of existence • you can’t sign something that’s not there • use NSEC or NSEC3 records to cover the gaps • sign the NSEC and NSEC3 records

  32. DNSSEC for Registries

  33. So What? • What does this mean for a registry? • need to implement secure key storage, management procedures • need to sign your zones • need to accept DS records from users (how?) • need to publish DS records to parents (how?)

  34. NSEC and NSEC3 • You have to use one of these. Which one? • Simple rule of thumb • if you are happy for anybody in the world to obtain a copy of your zone, use NSEC • if you normally don’t allow (e.g.) zone transfers to random people, use NSEC3

  35. Key Management • How do we keep the ZSK secure? • How do we keep the KSK secure? • important questions • no simple answers here • requires risk analysis, consultation, maybe audit

  36. Communication • Communicate with your customers • explain benefits/risks of DNSSEC • Communicate with end-users • demonstrate how to validate responses • explain operational changes (firewalls, TCP, response sizes)

  37. And Also! • Remember, DNSSEC makes you zones more brittle and fragile than they were before • need to have excellent reliability in registry and DNS operations • need to have emergency procedures to update DS RRSets in your zones

  38. Open-Source Software • BIND9 • http://www.isc.org/ • OpenDNSSEC • http://www.opendnssec.org/

  39. Resources • dnssec-deployment mailing list • http://www.dnssec-deployment.org/ • dns-operations mailing list • http://www.dns-oarc.net/ • Ongoing protocol work • IETF dnsop, dnsext working groups

  40. State of DNS Deployment, September 2010

  41. Deployment • Root zone was signed in July 2010 • Many TLDs are currently signed • 48 out of 294 • ARPA, BE, BG, BIZ, BR, CAT, CH, CL, CZ, DK, EDU, EU, FI, FR, GOV, INFO, KG, LI, LK, MUSEUM, NA, NL, NU, ORG, PM, PR, PT, RE, SE, TF, TH, TM, UK, US, ... • http://stats.research.icann.org/dnssec/

  42. Introduction to DNSSEC • AROC Bamako, Mali, 2010

More Related