1. FCC CSRIC III Working Group 5 DNSSEC Implementation Practices Steve Crocker CEO, Shinkuro, Inc. steve@shinkuro.com March 6, 2013 Working Group 5: DNSSEC Implementation Practices

2. The Opportunity Protection against cache poisoning Security increasingly resonates with customers DNSSEC can be a market differentiator for early adopters DNSSEC may help ISPs avoid some costs if a cache poisoning attack occurs ISP DNSSEC awareness in DNS recursive nameservers is necessary for end- user validation (e.g., DANE) Working Group 5: DNSSEC Implementation Practices March 6, 2013

3. WG5 Objective Recommend the best practices for deploying and managing the Domain Name System Security Extensions (DNSSEC) by Internet service providers (ISPs). Recommend proper metrics and measurements that allow for evaluation of the effectiveness of DNSSEC deployment by ISPs. March 6, 2013Working Group 5: DNSSEC Implementation Practices

4. Measurements Measurements of recursive resolvers were carried out through two methods: 1.Broad survey of the IPv4 address space to find putative resolvers, followed by detailed probing of each putative resolver. 2.Similar detailed probing from SamKnows clients inside of networks. The detailed probing comprised 13 tests for both basic functionality and specific edge cases. We restated basic functionality as: ValidatorThis means the resolver checks signatures when requested to do so. DNSSEC Aware ResolverThis means the resolver retrieves and passes back to the client the full set of keys, signatures, etc. that enable the client to validate. OtherThis means the resolver does not provide enough functionality to enable the client to do his own validation. March 6, 2013 Working Group 5: DNSSEC Implementation Practices

5. Measurements – Edge Cases In preliminary measurement we discovered unanticipated limitations. We evolved the test set to check for: Support for large responses via large packets and/or TCP Support for DNAME Support for NSEC3 Support for unknown (new) record types We annotated the description of a resolver to reflect these limitations, as in this case: Partial Validator [DNAME] March 6, 2013 Working Group 5: DNSSEC Implementation Practices

6. Measurements – SamKnows Results >1/6 Validators 2/3 Full Validators 1/3 Partial 1/2 DNSSEC Aware 2/3 Full 1/3 Partial >1/4 Broken ~ 5% Other March 6, 2013 Working Group 5: DNSSEC Implementation Practices

7. Measurements – Shinkuro Survey IPv4 space4,294,967,295 Addresses probed3,421,239,040 Dropped responses 10,197,657Probably overran our nameserver bandwidth Full responses 26,603,239 “Good” responses 11,697,272 Well-formed responses 5,908,002 Most of these were evaluated as Not a Resolver or alternately, we had timeout issues. This part of the testing needs to be redone. March 6, 2013 Working Group 5: DNSSEC Implementation Practices

8. Measurements – Shinkuro Setup Shinkuro test site sent a basic DNS query to each IPv4 address. The query was tailored to the address being sent. The address was encoded in the query. This query was resolvable only via a special Shinkuro nameserver. Thus, we could see the query we sent, and we could see the resolver trying to fetch the answer from our nameserver. This gave us insight into which resolvers were forwarding to other resolvers versus sending queries to our nameservers. We discovered many SOHO stub resolvers accepting queries from off net. We discovered some “closed” resolvers accessible via open SOHO stub resolvers. March 6, 2013 Working Group 5: DNSSEC Implementation Practices

9. Findings Many resolvers are DNSSEC Aware. This is good news. Of these, a significant portion have specific limitations. Improvement is needed. Some resolvers check signatures, i.e. are Validators. Some of these also have specific limitations. March 6, 2013 Working Group 5: DNSSEC Implementation Practices

10. Recommendations ISPs implement their DNS recursive nameservers so that they are at a minimum DNSSEC- aware, as soon as possible. Key industry segments, such as banking, credit cards, healthcare and others, sign their respective domain names with DNSSEC. Software developers, such as those creating operating-system, web-browser, and other Internet-focused applications, study how and when to incorporate DNSSEC validation functions into their software. The survey and description process should continue with refinement and with continued measurement over time. Controversy over DNSSEC and DDoS attacks persists. This should be documented and these attacks countered thoroughly. March 6, 2013 Working Group 5: DNSSEC Implementation Practices

11. Comments for Working Group 5 Laurie Flaherty at DOT suggested that an acronym list, and the spelling out of acronyms on first citation, would help potential lay readers understand the report better. We added an acronym list and made sure that acronyms’ elements were spelled out on first reference. March 6, 2013 Working Group 5: DNSSEC Implementation Practices

12. Conclusion ISP support for DNSSEC is necessary even in a future in which end points perform all validation. They must be able to, at a minimum, recognize DNSSEC-related traffic and allow it to pass for the smooth functioning of an end- to-end, DNSSEC-secured system. March 6, 2013 Working Group 5: DNSSEC Implementation Practices

13. Thank You Steve Crocker steve@shinkuro.com (301) 961-3131, ext. 111 March 6, 2013 Working Group 5: DNSSEC Implementation Practices