DNSSEC: How to deploy it, and why you should bother (ION Toronto 2011)
Post on 22-Apr-2015
3559 Views
Preview:
DESCRIPTION
Transcript
DNSSEC How to deploy it, and why you should bother. joe.abley@icann.org
DNS What?
• DNSSEC. Pay attention. • RFC 4033, RFC 4034, RFC 4035
• Cryptographic keys and signatures published in the DNS • Public, private key-pairs • Allows a chain of trust to be established through the data published
in the DNS
• No encryption, no transport security, no privacy measures • Authenticity of Answers
Trust Follows Delegations Zone contains public keys. Resource Record Sets are signed with corresponding private keys. Secure delegations contain a hash of a child’s public key.
Zone contains public keys. Resource Record Sets are signed with corresponding private keys.
Parent Zone Child Zone
Secure Delegation (NS, signed DS, glue)
How to Trust Lots of Stuff
Root Zone
ORG COM NET
ISOC.ORG
Trust Anchor
Deployment
• Zone Managers • sign your zones • publish trust anchors in parent zones • provide mechanisms for children to publish trust anchors in your
zone
• Cache Operators • ensure your caches are DNSSEC-friendly • turn on validation • don’t be evil
Zone Signing
• Root zone was signed in 2011, with great fanfare
• Today, many TLDs are signed (83 out of 310) • COM, NET, ORG, INFO, BIZ, others • Growing number of ccTLDs • ARPA
• Even in regions associated with ccTLDs that are signed, however, DNSSEC deployment is slow • CZ doing particularly well in this regard
DNSSEC in TLDs
DNSSEC in ccTLDs
How to Sign Your Zones
• BIND makes this easy, from 9.8 onwards • Good for people who already use and like BIND9
• OpenDNSSEC makes this easy • especially if you feel a need to use Hardware Security Modules
• PowerDNS makes this easy • POWERDNS is now declared ready for production • good for people who already use and like PowerDNS
How to Serve Signed Zones
• Probably, you just have to sign the zones • i.e. do nothing in particular to your masters and slaves • most DNS authority-only servers have had DNSSEC turned on by
default for some time
Cache Operators
• Unless you’re being evil, your caches probably already pass through DNSSEC records to end users • i.e. do nothing, and end-users can validate
• Turn on Validation • if you want to avoid cache poisoning attacks • there is a support overhead here • the helpdesk phone might ring, sometimes
End Users
• Use a cache that is validating • You won’t see signed records unless the signatures are good
• Use software that does validation for you • Chrome • FireFox with the NIC.CZ DNSSEC Validator module • DNSSEC Trigger, by NLNet Labs
Why Bother?
• There is lots of response spoofing and cache poisoning going on • so we hear • problem is, it’s often hard to tell
• What we’re building is a global Public Key Infrastructure based on the DNS • this is good • we want this
Why is a Global PKI Good?
• Building a reliable PKI is hard • have you ever tried to use PGP? • ever heard of an X.509 Certificate Authority going bad? • ever known a user to click “Continue” when a certificate warning
pops up?
• Reliable PKIs are useful • TLS (HTTPS, SMTP, IMAP, etc) • Routing Security • SSH key management
e.g. DANE
• DNS-based Authentication of Named Entities • IETF Working Group • Aims to use the DNS to distribute X.509 certificates
• Promises the convenience and price of self-signed certificates with near real-time revocation • no need to e-mail bits of photoshopped letterhead round the place • no fees • set your own key roll schedules
Homework
• Sign some Zones
• Make sure your caches are nice and clean, and pass through DNSSEC records correctly • don’t forget not to be evil
• Turn on Validation in your cache • if you feel like it
• Install some client software that does DNSSEC validation
top related