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