FCC CSRIC III Working Group 5 DNSSEC Implementation Practices

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

2. 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) The Opportunity Working Group 5: DNSSEC Implementation Practices

3. 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. WG5 Objective Working Group 5: DNSSEC Implementation Practices

4. Measurements of recursive resolvers were carried out through two methods: • Broad survey of the IPv4 address space to find putative resolvers, followed by detailed probing of each putative resolver. • 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: • Validator This means the resolver checks signatures when requested to do so. • DNSSEC Aware Resolver This means the resolver retrieves and passes back to the client the full set of keys, signatures, etc. that enable the client to validate. • Other This means the resolver does not provide enough functionality to enable the client to do his own validation. Measurements Working Group 5: DNSSEC Implementation Practices

5. 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] Measurements – Edge Cases Working Group 5: DNSSEC Implementation Practices

6. >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 Measurements – SamKnows Results Working Group 5: DNSSEC Implementation Practices

7. IPv4 space 4,294,967,295 Addresses probed 3,421,239,040 Dropped responses 10,197,657 Probably 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. Measurements – Shinkuro Survey Working Group 5: DNSSEC Implementation Practices

8. 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. Measurements – Shinkuro Setup Working Group 5: DNSSEC Implementation Practices

9. 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. Findings Working Group 5: DNSSEC Implementation Practices

10. 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. Recommendations Working Group 5: DNSSEC Implementation Practices

11. 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. Comments for Working Group 5 Working Group 5: DNSSEC Implementation Practices

12. 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. Conclusion Working Group 5: DNSSEC Implementation Practices

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