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

2. Agenda .edu testbed EDUCAUSE registrar application functionality
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
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
End-to-end testing to exercise the following
Registrant to Registrar (EDUCAUSE) application
Registrar (EDUCAUSE) to Registry (VeriSign) application
Zone file updates (Registry)
Zone file updates (Registrant’s)
Name server resolution (Registrant to VeriSign)

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
Will be different for registrars that provide dns – at a minimum they need to provide interface for registrants, but should also consider providing it as an additional service if they offer dns services

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 (

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 Name Server resolution
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
Functional specs are in the RFC We knew what fields we needed and what the valid values were from the RFC. Also refer to EPP SDK documentation.

21. EDUCAUSE Registrar Application
Dig , parse out the zone public key, run it thru a function to generate a DS record (function will be available in an upcoming version of the SDK – ver 3.11) , and then validate that the DS record matches what they entered in the form. Totally optional whether you want to do this or not – not required.

22. EDUCAUSE Registrar Application

23. EDUCAUSE Registrar Application
Dummy data – not real! Using the update command to implement the delete buttons at the moment.

24. EDUCAUSE Registrar Application
Value add not required

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
Each tester completes the same tests
Ensures thorough testing of all cases
Ask testers to note where their results differ from expected results
An listserve was effective for us
We used a password-protected Google document with sheets for each tester and a master suggestion sheet

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