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

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

.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

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

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)

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

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

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/)

Testbed Findings

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)

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

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

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

Lessons Learned

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

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

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

EDUCAUSE Registrar Application

EDUCAUSE Registrar Application

EDUCAUSE Registrar Application Functional specs are in the RFC 4034. We knew what fields we needed and what the valid values were from the RFC. Also refer to EPP SDK documentation.

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.

EDUCAUSE Registrar Application

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

EDUCAUSE Registrar Application Value add not required

Getting Started with DNSSEC

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

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

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 e-mail listserve was effective for us We used a password-protected Google document with sheets for each tester and a master suggestion sheet

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

Questions? Contact Becky Granger at rgranger@educause.edu