FCC CSRIC III Working Group 5 DNSSEC Implementation Practices

FCC CSRIC III

Working Group 5

DNSSEC Implementation PracticesSteve CrockerCEO, Shinkuro, [email protected] 6, 2013Working Group 5: DNSSEC Implementation Practices

Working Group 5: DNSSEC Implementation Practices

The OpportunityProtection against cache poisoning

Security increasingly resonates with customersDNSSEC 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 PracticesMarch 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


MeasurementsMeasurements 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:

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


Measurements Edge CasesIn 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 Validators2/3 Full Validators1/3 Partial

1/2 DNSSEC Aware2/3 Full1/3 Partial

>1/4 Broken

~ 5% Other



Measurements Shinkuro SurveyIPv4 space4,294,967,295Addresses probed3,421,239,040Dropped responses 10,197,657Probably 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 SetupShinkuro 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


FindingsMany 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


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



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.



ConclusionISP 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 YouSteve [email protected](301) 961-3131, ext. 111March 6, 2013Working Group 5: DNSSEC Implementation Practices


*************

Documents

FCC CSRIC III Working Group 5 DNSSEC Implementation Practices