FCC CSRIC III Working Group 5 DNSSEC Implementation Practices

FCC CSRIC III

Working Group 5

DNSSEC Implementation Practices

Steve Crocker

CEO, Shinkuro, Inc.

[email protected]

March 6, 2013Working Group 5: DNSSEC Implementation Practices

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

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

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:

•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.

March 6, 2013Working Group 5: DNSSEC Implementation Practices

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, 2013Working Group 5: DNSSEC Implementation Practices

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, 2013Working Group 5: DNSSEC Implementation Practices

Measurements – Shinkuro Survey

IPv4 space 4,294,967,295Addresses probed 3,421,239,040Dropped responses 10,197,657 Probably overran our nameserver bandwidthFull 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, 2013Working Group 5: DNSSEC Implementation Practices

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, 2013Working Group 5: DNSSEC Implementation Practices

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, 2013Working Group 5: DNSSEC Implementation Practices

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, 2013Working Group 5: DNSSEC Implementation Practices

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, 2013Working Group 5: DNSSEC Implementation Practices

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, 2013Working Group 5: DNSSEC Implementation Practices

Thank You

Steve [email protected]

(301) 961-3131, ext. 111

March 6, 2013Working Group 5: DNSSEC Implementation Practices