DNSSEC Testbed Lessons Learned

1. .edu DNSSEC Testbed Lessons Learned Becky Granger, EDUCAUSE Shumon Huque,University of Pennsylvania April 20, 2010

2. Agenda • .edu testbed • Overview • Registrant experience • Findings • Lessons learned • EDUCAUSE registrar application functionality • Getting started with DNSSEC • Implementing your own testbed • Recruiting testers • Managing the process

3. .edu DNSSEC Testbed Goal & Objectives • Goal • Exercise DNSSEC registration and resolution in a representative end-to-end test environment • Objectives • Demonstrate that all components function properly • Document where actual behavior differs from expected behavior • Obtain technical feedback from registrants • Inform future DNSSEC implementations in larger zones

4. Testbed Landscape • Duration – 2 months • Active Participants – 12 • VeriSign: operator of the .edu registry • EDUCAUSE: registrar for the .edu zone • Registrants: 10 volunteering domain name holders • 7 universities • 3 regional networks

5. High-Level Architecture Test environment was a reproduction of the .edu domain name space

6. Registrant preparation for testbed • Deploy authoritative DNS servers with signed zones • Test servers and test zones okay • Some participants used signed production servers • Run “validating” resolvers • Configured to use testbed .edu servers as authoritative for .edu top level domain

7. Overview of some registrant tests • Confirm connectivity to testbed • Add DS records of various algorithms and digests • Remove DS records • Add incorrect DS records • View DS record history report • Perform key rollover operations and DS updates • At each test stage, perform verification tests with appropriately configured validating resolver • Attempt to validate records of other participants also

8. Current DNSSEC activity inside .edu • Signed subdomains directly under .edu • 7 total second level domains • berkeley.edu, merit.edu, penn.edu, psc.edu, upenn.edu, internet2.edu, ucaid.edu • Signed zones further down • 58 more (as of Jan 2010) • 3rd level domains inside universities • Many are subdomains for computer science departments, or for DNS research projects. Data from SecSpider (http://secspider.cs.ucla.edu/)

9. Testbed Findings

10. Testbed Findings • Registrant to Registrar application • General satisfaction from registrants • Minor functionality and display alterations suggested • Registrar to Registry application • Successfully exercised info, delete, and update EPP commands • Discovered a limitation in RFC 4310, which prompted a new RFC revision (draft-gould-rfc4310bis)

11. Testbed Findings • Zone updates • No issues identified; zones were updated correctly • Name Server resolution • Resolution worked correctly • Current version of BIND is needed for NSEC3

12. Participant Survey Results • 100% of testbed participants… • Agreed that the test cases were representative of the functionality required for DNSSEC • Had a high confidence level about implementing DNSSEC • Most testers used BIND but other software packages worked too • 7 used BIND • 2 used ZKT • 1 used a DNSSEC signing appliance

13. Participant Survey Results - Challenges • Developing a strong technical understanding of the end-to-end DNSSEC process • Lack of documentation and best practices for DNSSEC implementations • Timing, managing, and automating key rollovers • Troubleshooting validation failures

14. Lessons Learned

15. Lessons Learned - General • Learn, Live, Love the RFCs • RFC 4033 – DNSSEC introduction and requirements • RFC 4034 – Resource records for DNSSEC • RFC 4310 – DNSSEC mapping for EPP • Also see revision draft-gould-rfc4310bis • RFC 4641 – DNSSEC operational practices • Brush up on DNS

16. Lessons Learned – Registrant Application • Validate everything • Key Tag must be an integer between 1 and 65535 • Algorithm must be an integer • Digest Type must be an integer • SHA-1 Digests must be a sequence of 40 hexadecimal digits • SHA-256 Digests must be a sequence of 64 hexadecimal digits • Dig to compare the entered DS data against the public key in the domain’s zone

17. Lessons Learned – Registrant Application • Remove whitespace automatically • Allow multiple Digests to have the same Key Tag • Consider automatically generating DS records • Allow upload of BIND DSSET file or • Allow data entry of public key information

18. EDUCAUSE Registrar Application

19. EDUCAUSE Registrar Application

20. EDUCAUSE Registrar Application

21. EDUCAUSE Registrar Application

22. EDUCAUSE Registrar Application

23. EDUCAUSE Registrar Application

24. EDUCAUSE Registrar Application

25. Getting Started with DNSSEC

26. Why Implement a DNSSEC Testbed? • Make sure *you* understand the intricacies of DNSSEC • Evaluate the user interface of your registrar application • Make sure your registrant application WORKS • Get your registrants involved • Build confidence throughout the community

27. Recruiting Testers • Ask! • Include registrants with different technical ability • Include registrants using different software packages

28. Managing Your Testbed • Create a set of tests for testers to perform • Specify expected results of each test and ask testers to note where their results differed • Provide a way for testers to interact when they have questions • Provide a central location for tracking testing progress, noting inconsistencies, and making suggestions • Survey testers after testbed completion to gauge comfort with process and challenges faced

29. Many Resources Available • Use VeriSign's DNSSEC OTE for .net and .com • Test the Registrar to Registry EPP interface • Leverage VeriSign’s EPP SDK & active EPP Tool • Test your signing and key management solution • Leverage VeriSign’s DNSSEC Tool Guide to evaluate signing solutions • Engage with VeriSign’s DNSSEC Forum to ask your questions and dialogue with technical colleagues

31. Questions? Contact Becky Granger at rgranger@educause.edu