DNSSEC: What a Registrar Needs to Know (Part 2)


Published on

This presentation covers a "crib sheet" authored by Shinkuro, Inc. that walks a registrar through the operational considerations when implementing DNSSEC. We also had the pleasure of hearing from Dyn, Inc. an ICANN accredited registrar who shared lessons learned from their work and testing in DNSSEC.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

DNSSEC: What a Registrar Needs to Know (Part 2)

  1. 1. DNSSEC Industry Coalition Webinar Series Brought to you by .ORG, The Public Interest Registry, Shinkuro, Inc. and Dyn, Inc. Presented 2 December 2009
  2. 2. The first open gTLD to be signed A .ORG registrar also providing DNS service for its registrants with a strong desire to support DNSSEC Two organizations funded* to support the deployment of DNSSEC. *The Department of Homeland Security Science and Technology (S&T) Directorate has funded SPARTA, Inc., dba Cobham Analytic Solutions, under contract FA8750-04-C-0229 and Shinkuro, Inc. under contracts FA8750-04-C-0269 and FA8750-10-C-0020. The information presented does not necessarily represent the views of the U.S. Government. 2
  3. 3.  Our registry is ready for DNSSEC  Our registrar wants to sign and serve zones for its registrants and accept DS records for those signing and serving elsewhere  Some of our registrants want to click a button to have the zone the registrar serves for them signed while some merely want to provide their DS records  DNSSEC tools have many settable parameters and it isn’t clear which settings are right for our registrar and those in a similar situation 3
  4. 4.  Multiple standards (NSEC vs. NSEC3)  Recommendations from others (RFCs, NIST)  One size (key size, signature lifetime) does not fit all  Non-ubiquitous support for DNSSEC and its underlying standards (EDNS0)  Additional computational requirements  Legacy systems that have a limited understanding of DNS, let alone DNSSEC 4
  5. 5.  A consistent set of DNSSEC parameters  Suitable for small zones with guessable names  Adequate cryptographic security  Avoiding undue burden on ◦ The registrar’s infrastructure ◦ ISPs and recursive resolvers ◦ Last-mile connectivity  Updates as DNSSEC adoption grows 5
  6. 6.  DNSSEC Operations: Setting the Parameters (http://dnssec-deployment.org/documents/SettingtheParameters.pdf)  A work in progress  Feedback: dnssec-parameters@shinkuro.com  Most recent version: 2009-11-24 (03) 6
  7. 7. During the time remaining we will go over DNSSEC Operations: Setting the Parameters, its recommendations, and the reasoning behind them. The paper contains more detailed explanations than are in this presentation. 7
  8. 8. RR Type TTL SOA 1 day NS 1 day A/AAAA <= 1 day DNSKEY 1day Max UDP packet Size 1492 SOA Expire Value 1 week SOA Negative Cache Time 1 hour 8
  9. 9. Algorithm RSA w/SHA1 Key Type Key Key Signature Re- Length Lifetime Lifetime Signing Period KSK 1280 bits 4 years 4 weeks 2 weeks ZSK 1024 bits 1 year 2 weeks 1 week Jitter 1 hour 9
  10. 10. Negative Support Response NSEC Default Hash Salt Size Salt Iterations Lifetime NSEC3 Optional 1 64 bits Signature lifetime 10
  11. 11. Key Prepublication/ Introduction Retirement Signing Policy Time for New Time for Old Key Key KSK 2K, 1S 1 week 4 weeks ZSK 2K, 1S 4 days 2 weeks 2K,1S means two keys and one active signature. Old keys must be removed to prevent DNSKEY answers from growing in size with each rollover. 11
  12. 12.  You can ask questions now  You can send questions to dnssec- parameters@shinkuro.com 12
  13. 13. Jeremy Hitchcock Dyn Inc. / jeremy@dyn.com
  14. 14.  Go over our story with DNSSEC  Some lessons learned  Poll DNSSEC knowledge/plans  Answer questions
  15. 15.  DNS operator first ◦ Dynamic DNS to twitter.com (plus some [g|cc]TLDs)  Registrar with about 50k registrations  Allow managed DNSSEC on one system  Allow DS keys/registry EPP on different system  Plan both systems to do both operations
  16. 16. RFC Theory PIR Documentation Registry Practice User Experience Practice
  17. 17.  Some conversations with DNSSEC transfers  Did some internal testing with DNSSEC and NS  Did DNS part first (DNSSEC key management)  Added DS record EPP commands  Spec is pretty fleshed out ◦ Operational practices alright ◦ Best practices still being worked on
  18. 18.  Most written about  RFCs and BIND/NSD well documented  TLDs have great operational experience  Secure key management (HSM/software)  Not doing NSEC3  DS, RSIG, NSEC records Example…
  19. 19. ; ; f l ags : qr aa r d; QUERY: 1, ANSW ER: 2, AUTHORI TY: 5, ADDI TI ONAL: 1 ;; W ARNI NG: r ec ur s i on r eques t ed but not av ai l abl e ; ; QUESTI ON SECTI ON: ; s l eepz er o. or g. IN A ; ; ANSW SECTI ON: ER s l eepz er o. or g. 3600 IN A 204. 13. 248. 107 s l eepz er o. or g. 3600 IN RRSI G A 5 2 3600 20091123214939 20091024214939 13911 s l eepz er o. or g. H4pnVbaf aDGP+dQEol Gh7y t QW y KR0Zz r s ZPpRHP0f m VJ g/ / ERUO4n pj y EEA3hKr gj v hULj 8VHj BNg9i f t z 9VJ AM75wk i +WXdAz 63W SL2+3+Kt R4c Uf EKYZnLQU9x ql nx r mHUoEGO3EON8qI 3YgTLQt r I or 14i eKu05nM Yuq y J U= I
  20. 20. $ di g @ 1. p26. dy nec t . net s l eepz er o. or g dns k ey +s hor t ns 256 3 5 AwEAAds DDf 9p7eEVo/ W euGuChdCRwm UW k e3s m M Gc NBB5QT6y W s Ql nQ 1x CE3Dy 0Pn4Vz 9z nv DN7BPDp+hOk p90r m s c W y T4bE4c 6aSW c Qc 2 bj +Si Tl m KRpeY32bs uFZCR6aUPOM PgZ1Ap0Ui euZYf v j s 8j m x q6Rnc y CU4Ti LHo hYx a+J Dd 257 3 5 AwEAAem PX/ k P3+ox Cu9s SGt 5Ns g1U+8oTI v GYI m y / EUz wBI hqP7Hv t z f j KmFoBg9E53c aD/ eo3dpt eZ5aI v M 7dq8s pi Vx Sj ZUERgf a49y LGx Yac z W 4FeCs Lk M m Bq0f 6PDCm 2K4Hk oHCPV1i PDI i D3Vt VDa0F3k j Dz R8M k p8n 3qhl EXI 9x O72M bm f t / Sr t Cohx ny Od29KoOz 3e9R9nNdUnEx QJ l M Dk ex v qJ 5l d3Cnz q5Su4w27O6bbYHPnKTHeFz f 41UCVVHz 355QM F4aqgpx LOe r ThZFCE0Q0nhYXHXpT9OPs x r Zx l dBnf k 4qZ+7J Dwx Ci / 9QGhqk m wBpW j s doKQXCNQo0s =
  21. 21.  EPP extensions are simple  It’s expected all registries similar  Just another piece of data  Testing with registry
  22. 22. $ di g @ ORG. AFI LI AS- NST. I NFO. s l eepz er o. or g +dns s ec A2. s l eepz er o. or g. 86400 IN DS 17917 5 1 CC8EB33C421B1829EBF5449D741D661C4F4A0C1B s l eepz er o. or g. 86400 IN RRSI G DS 7 2 86400 20091215181210 20091201171210 53990 or g. hz / FW u4W pCFj s T6b7bAgi x 5ey 6M l l wBk c FHH1pEr W M eql w2x m P8z U20C 7Ev c s N9t 3Bv g/ Pv Ex 5BKi Unby 489wp6Q0Yi 46w563DwoE7pf dt ey 5l XT t j FSPX4Cay / x qVdpk 0BOI 6hVAZOz uJ h/ 0Oi A6AMKqKRXqx 1RaSNI R1l 4 +D8=
  23. 23.  Next steps: both systems to get both  System is all in-house, same as you?  Transfer testing is ongoing ◦ ccTLDs have done this for years, requires registrar cooperation  Key rollover and registry operations separate ◦ Bit of a mess since DNS drives registry operation
  24. 24.  Maybe not so much?  A few customers actually using it to try out  Solid single digit percentage of resolvers have do bit set (DNSSEC ok), active validation?  Has to be easy, tools to validate  Makes DNS more brittle
  25. 25.  How many have heard DNSSEC demand?  How many have had had no DNSSEC demand?  How many are rolling DNSSEC out now?  How many in 3-6 months?  How many in 6-12 months?  Currently have no DNSSEC plans?
  26. 26. Jeremy Hitchcock Dyn Inc. / jeremy@dyn.com
  27. 27. Lauren Price The DNSSEC Industry Coalition Feedback lprice@pir.org