DNSSEC: How to deploy it, and why you should bother (ION Toronto 2011)

DNSSEC: How to deploy it, and why you should bother (ION Toronto 2011)

• 1.
  DNSSEC How to deployit, and why you should bother. [email protected]
• 2.
  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
• 3.
  Trust Follows Delegations Zonecontains public keys. Resource Record Sets are signed with corresponding private keys. Secure delegations contain a hash of a child’s public Secure Delegation key. (NS, signed DS, glue) Parent Zone Child Zone Zone contains public keys. Resource Record Sets are signed with corresponding private keys.
• 4.
  How to TrustLots of Stuff Trust Anchor Root Zone ORG COM NET ISOC.ORG
• 5.
  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
• 6.
  Zone Signing •  Rootzone 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
• 7.
  DNSSEC in TLDs
• 8.
  DNSSEC in ccTLDs
• 9.
  How to SignYour 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
• 10.
  How to ServeSigned 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
• 11.
  Cache Operators •  Unlessyou’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
• 12.
  End Users •  Usea 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
• 13.
  Why Bother? •  Thereis 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
• 14.
  Why is aGlobal 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
• 15.
  e.g. DANE •  DNS-basedAuthentication 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
• 16.
  Homework •  Sign someZones •  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