draft-ietf-dnsop-dnssec-roadblock-avoidance-03.txt   draft-ietf-dnsop-dnssec-roadblock-avoidance-04.txt 
DNSOP W. Hardaker DNSOP W. Hardaker
Internet-Draft Parsons Internet-Draft Parsons
Intended status: Best Current Practice O. Gudmundsson Intended status: Best Current Practice O. Gudmundsson
Expires: September 22, 2016 CloudFlare Expires: October 6, 2016 CloudFlare
S. Krishnaswamy S. Krishnaswamy
Parsons Parsons
March 21, 2016 April 4, 2016
DNSSEC Roadblock Avoidance DNSSEC Roadblock Avoidance
draft-ietf-dnsop-dnssec-roadblock-avoidance-03.txt draft-ietf-dnsop-dnssec-roadblock-avoidance-04.txt
Abstract Abstract
This document describes problems that a DNSSEC aware resolver/ This document describes problems that a DNSSEC aware resolver/
application might run into within a non-compliant infrastructure. It application might run into within a non-compliant infrastructure. It
outline potential detection and mitigation techniques. The scope of outline potential detection and mitigation techniques. The scope of
the document is to create a shared approache to detect and overcome the document is to create a shared approach to detect and overcome
network issues that a DNSSEC software/system may face. network issues that a DNSSEC software/system may face.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016. This Internet-Draft will expire on October 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 47 skipping to change at page 2, line 47
3.3. Support for DNSKEY and DS combinations . . . . . . . . . 11 3.3. Support for DNSKEY and DS combinations . . . . . . . . . 11
4. Aggregating The Results . . . . . . . . . . . . . . . . . . . 11 4. Aggregating The Results . . . . . . . . . . . . . . . . . . . 11
4.1. Resolver capability description . . . . . . . . . . . . . 12 4.1. Resolver capability description . . . . . . . . . . . . . 12
5. Roadblock Avoidance . . . . . . . . . . . . . . . . . . . . . 12 5. Roadblock Avoidance . . . . . . . . . . . . . . . . . . . . . 12
5.1. Partial Resolver Usage . . . . . . . . . . . . . . . . . 15 5.1. Partial Resolver Usage . . . . . . . . . . . . . . . . . 15
5.1.1. Known Insecure Lookups . . . . . . . . . . . . . . . 15 5.1.1. Known Insecure Lookups . . . . . . . . . . . . . . . 15
5.1.2. Partial NSEC/NSEC3 Support . . . . . . . . . . . . . 15 5.1.2. Partial NSEC/NSEC3 Support . . . . . . . . . . . . . 15
6. Start-Up and Network Connectivity Issues . . . . . . . . . . 15 6. Start-Up and Network Connectivity Issues . . . . . . . . . . 15
6.1. What To Do . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. What To Do . . . . . . . . . . . . . . . . . . . . . . . 16
7. Quick Test . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Quick Test . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Test negative answers Algorithm 5 . . . . . . . . . . . . 16 7.1. Test negative answers Algorithm 5 . . . . . . . . . . . . 17
7.2. Test Algorithm 8 . . . . . . . . . . . . . . . . . . . . 17 7.2. Test Algorithm 8 . . . . . . . . . . . . . . . . . . . . 17
7.3. Test Algorithm 13 . . . . . . . . . . . . . . . . . . . . 17 7.3. Test Algorithm 13 . . . . . . . . . . . . . . . . . . . . 17
7.4. Really fails when DNSSEC does not validate . . . . . . . 17 7.4. Really fails when DNSSEC does not validate . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document describes problems with DNSSEC ([RFC4034], [RFC4035]) This document describes problems with DNSSEC ([RFC4034], [RFC4035])
deployment due to non-compliant infrastructure. It poses potential deployment due to non-compliant infrastructure. It poses potential
detection and mitigation techniques. detection and mitigation techniques.
1.1. Background 1.1. Background
skipping to change at page 3, line 37 skipping to change at page 3, line 38
the DNS port (53) either UDP and/or TCP . the DNS port (53) either UDP and/or TCP .
o Network component in path does not allow UDP fragments o Network component in path does not allow UDP fragments
o etc... o etc...
This document talks about ways a Host Validator can detect the state This document talks about ways a Host Validator can detect the state
of the network it is attached to, and ways to hopefully circumvent of the network it is attached to, and ways to hopefully circumvent
the problems associated with the network defects it discovers. The the problems associated with the network defects it discovers. The
tests described in this document may be performed on any validating tests described in this document may be performed on any validating
resolver to detect and prevent problems. While these recomendations resolver to detect and prevent problems. While these recommendations
are mainly aimed at Host Validators it it prudent to perform these are mainly aimed at Host Validators it it prudent to perform these
test from regular Validatating Resolvers before enabling just to make test from regular Validating Resolvers before enabling just to make
sure things work. sure things work.
There are situations where a host can not talk directy to a Resolver There are situations where a host can not talk directly to a Resolver
the tests below do not address how to overcome that. In these the tests below do not address how to overcome that. In these
situations it is not uncommon to get results that are not consistent. situations it is not uncommon to get results that are not consistent.
This mainly happens when there are DNS proxies/forwarders between the This mainly happens when there are DNS proxies/forwarders between the
user and the actual resolvers. user and the actual resolvers.
1.2. Implementation experiences 1.2. Implementation experiences
Multiple lessons learned from multiple implementations led to the Multiple lessons learned from multiple implementations led to the
development of this document, including (in alphabetical order) development of this document, including (in alphabetical order)
DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger, DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger,
FCC_Grade. FCC_Grade.
Detecting full non-support for specified DNSKEY algorithms and DS Detecting full non-support for specified DNSKEY algorithms and DS
digiest algorithms is outside the scope of this document but the digest algorithms is outside the scope of this document but the
document provides information on how to do that, see sample test document provides information on how to do that, see sample test
tool: https://github.com/ogud/DNSSEC_ALG_Check This document will tool: https://github.com/ogud/DNSSEC_ALG_Check This document will
test compliance with Algorithm 5, 7 and Algorithm 13 with DS digest test compliance with Algorithm 5, 7 and Algorithm 13 with DS digest
algorithm 1 and 2. algorithm 1 and 2.
1.3. Notation 1.3. Notation
When we talk about a "Host Validator", this can either be a library When we talk about a "Host Validator", this can either be a library
that an application has linked in or an actual validating resolver that an application has linked in or an actual validating resolver
running on the same machine. running on the same machine.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
A Host Validator has two choices: it can wait to determine that it A Host Validator has two choices: it can wait to determine that it
has problems with a recursive resolver based on the results that it has problems with a recursive resolver based on the results that it
is getting from real-world queries issued to it, or it can is getting from real-world queries issued to it, or it can
proactively test for problems (Section Section 3) to build a work proactively test for problems (Section Section 3) to build a work
around list ahead of time (Section Section 5). There are pros and around list ahead of time (Section Section 5). There are pros and
cons to both of these paths that are application specific, and this cons to both of these paths that are application specific, and this
document does not attempt to provide guidance about whether proactive document does not attempt to provide guidance about whether proactive
tests should or should not be used. Either way, DNSSEC roadblock tests should or should not be used. Either way, DNSSEC roadblock
avoidance techniques ought to be used when needed and if possible. avoidance techniques ought to be used when needed and if possible.
Note: The same tests can be used for a recursive resovler to check if Note: The same tests can be used for a recursive resolver to check if
its upstream connections hinder DNSSEC validation. its upstream connections hinder DNSSEC validation.
This document specifies two sets of tests to perform a comprehensive This document specifies two sets of tests to perform a comprehensive
one and a fast one. The fast one will detect most common problems, one and a fast one. The fast one will detect most common problems,
thus if the fast one passes then the comprensive MAY be exectued as thus if the fast one passes then the comprehensive MAY be executed as
well. well.
3. Detecting DNSSEC Non-Compilance 3. Detecting DNSSEC Non-Compilance
A Host Validator may choose to determine early-on what bottlenecks A Host Validator may choose to determine early-on what bottlenecks
exist that may hamper its ability to perform DNSSEC look-ups. This exist that may hamper its ability to perform DNSSEC look-ups. This
section outlines tests that can be done to test certain features of section outlines tests that can be done to test certain features of
the surrounding network. the surrounding network.
NOTE: when performing these tests against an address, we make the NOTE: when performing these tests against an address, we make the
following assumtption about that address: It is a unicast address or following assumption about that address: It is a uni-cast address or
an anycast cluster where all servers have identical configuration and an any-cast cluster where all servers have identical configuration
connectivity. and connectivity.
NOTE: when performing these tests we also assume that the path is NOTE: when performing these tests we also assume that the path is
clear of "DNS interfering" crapware/middle-boxes, like stupid clear of "DNS interfering" crap-ware/middle-boxes, like stupid
firewalls, proxies, forwarders. Presence of such crap can easily firewalls, proxies, forwarders. Presence of such crap can easily
make the recursive resolver look bad. It is beond the scope of the make the recursive resolver look bad. It is beyond the scope of the
docuent as how to test around the interferance. document as how to test around the interference.
3.1. Determining DNSSEC support in neighboring recursive resolvers 3.1. Determining DNSSEC support in neighboring recursive resolvers
Ideally, a Host Validator can make use of the caching present in Ideally, a Host Validator can make use of the caching present in
neighboring recursive resolvers. This section discusses the tests neighboring recursive resolvers. This section discusses the tests
that a neighboring recursive resolver MUST pass in order to be fully that a neighboring recursive resolver MUST pass in order to be fully
usable as a near-by DNS cache. usable as a near-by DNS cache.
Unless stated otherwise, all of the following tests SHOULD have the Unless stated otherwise, all of the following tests SHOULD have the
recursive flag set when sending out a query and SHOULD be sent over recursive flag set when sending out a query and SHOULD be sent over
skipping to change at page 11, line 28 skipping to change at page 11, line 28
Note: an implementation can use the local resolvers for determining Note: an implementation can use the local resolvers for determining
the address of the name server that is authoritative for the given the address of the name server that is authoritative for the given
zone. The recursive bit MAY be set for this request, but does not zone. The recursive bit MAY be set for this request, but does not
need to be. need to be.
3.3. Support for DNSKEY and DS combinations 3.3. Support for DNSKEY and DS combinations
Purpose: These tests can check if an algorithm combinations are Purpose: These tests can check if an algorithm combinations are
supported. supported.
Pre-requesitive: At least one of above tests has returned AD bit Pre-requisite: At least one of above tests has returned AD bit
proving upstream is validating proving upstream is validating
Test: A DNS request is sent over UDP to the resolver under tests for Test: A DNS request is sent over UDP to the resolver under tests for
a known combination of the DS number (N) and DNSKEY number (M) of the a known combination of the DS number (N) and DNSKEY number (M) of the
form ds-N.alg-M-nsec.dnssec-test.org, for example ds-2.alg-13- form ds-N.alg-M-nsec.dnssec-test.org, for example ds-2.alg-13-
nsec.dnssec-test.org TXT or ds-4.alg-13-nsec3.dnssec-test.org TXT. nsec.dnssec-test.org TXT or ds-4.alg-13-nsec3.dnssec-test.org TXT.
SUCCESS: a DNS respose is received with AD bit set with TXT record in SUCCESS: a DNS response is received with AD bit set with TXT record
the answer section. in the answer section.
BONUS: AD in response to the exaples above demonstrates support for BONUS: AD in response to the examples above demonstrates support for
Algorihtm 13 and the two DS algoritm(s) with both NSEC and NSEC3 Algorithm 13 and the two DS algorithm(s) with both NSEC and NSEC3
Note: for algorithms 6 and 7 NSEC is not defined thus query for alg- Note: for algorithms 6 and 7 NSEC is not defined thus query for alg-
M-nsec3 is requried, simlarly NSEC3 is not defined for algorithms 1, M-nsec3 is required, similarly NSEC3 is not defined for algorithms 1,
3 and 5. Furthermore algorithms 2, 4, 9, 11 do not have definitions 3 and 5. Furthermore algorithms 2, 4, 9, 11 do not have definitions
to sign zones. to sign zones.
4. Aggregating The Results 4. Aggregating The Results
Some conclusions can be drawn from the results of the above tests in Some conclusions can be drawn from the results of the above tests in
an "aggregated" form. This section defines some labels to assign to an "aggregated" form. This section defines some labels to assign to
a resolver under test given the results of the tests run against a resolver under test given the results of the tests run against
them. them.
skipping to change at page 13, line 27 skipping to change at page 13, line 27
validation on the results. validation on the results.
If validation fails, try the next resolver If validation fails, try the next resolver
Else if the resolver is labeled "Not a DNS Resolver" or Else if the resolver is labeled "Not a DNS Resolver" or
"Non-DNSSEC capable" "Non-DNSSEC capable"
Mark it as unusable and try next resolver Mark it as unusable and try next resolver
Else if no more resolvers are configured and if direct queries Else if no more resolvers are configured and if direct queries
are supported try iterating from Root are supported
1. try iterating from Root
Else return a useful error code 2. If the answer is SECURE/BOGUS:
Return the result of the iteration
3. If the query is INSECURE:
Re-query "Non-DNSSEC capable" servers and return
answers from them w/o the AD bit set to the client.
This will increase the likelihood that spit-view unsigned
answers are found.
Else return an useful error code
While attempting resolution through a particular recursive name While attempting resolution through a particular recursive name
server with a particular transport method that worked, any transport- server with a particular transport method that worked, any transport-
specific parameters MUST be remembered in order to short-circuit any specific parameters MUST be remembered in order to short-circuit any
unnecessary fallback attempts. unnecessary fallback attempts.
Transport-specific parameters MUST also be remembered for each Transport-specific parameters MUST also be remembered for each
authoritative name server that is queried while performing an authoritative name server that is queried while performing an
iterative mode lookup. iterative mode lookup.
skipping to change at page 15, line 44 skipping to change at page 16, line 5
This is real uncommon and only affects old resolvers, that also lack This is real uncommon and only affects old resolvers, that also lack
support for Unknown types, rendering them mostly useless and to be support for Unknown types, rendering them mostly useless and to be
avoided. avoided.
6. Start-Up and Network Connectivity Issues 6. Start-Up and Network Connectivity Issues
A number of scenarios will produce either short-term or long-term A number of scenarios will produce either short-term or long-term
connectivity issues with respect to DNSSEC validation. Consider the connectivity issues with respect to DNSSEC validation. Consider the
following cases: following cases:
Time Synchronization: Time synchronization problems can occure Time Synchronization: Time synchronization problems can occur when
when a device which has been off for a period of time and the a device which has been off for a period of time and the clock is
clock is no longer in close synchronization with "real time" or no longer in close synchronization with "real time" or when a
when a device always has clock set to the same time during start- device always has clock set to the same time during start-up.
up. This will cause problems when the device needs to resolve This will cause problems when the device needs to resolve their
their source of time synchronization, such as "ntp.example.com". source of time synchronization, such as "ntp.example.com".
Changing Network Properties: A newly established network Changing Network Properties: A newly established network
connection MAY change state shortly after a HTTP-based pay-wall connection MAY change state shortly after a HTTP-based pay-wall
authentication system has been used. This especially common in authentication system has been used. This especially common in
hotel networks, where DNSSEC, validation and even DNS are not hotel networks, where DNSSEC, validation and even DNS are not
functional until the user proceeds through a series of forced web functional until the user proceeds through a series of forced web
pages used to enable their network. The tests in pages used to enable their network. The tests in
Section Section 3 will produce very different results before and Section Section 3 will produce very different results before and
after the network authorization has succeeded. APIs exist on many after the network authorization has succeeded. APIs exist on many
operating systems to detect initial network device status changes, operating systems to detect initial network device status changes,
skipping to change at page 17, line 35 skipping to change at page 17, line 41
This document discusses problems that may occur while deploying the This document discusses problems that may occur while deploying the
secure DNSSEC protocol and what mitigation's can be used to help secure DNSSEC protocol and what mitigation's can be used to help
detect and mitigate these problems. Following these suggestions will detect and mitigate these problems. Following these suggestions will
result in a more secure DNSSEC operational environment than if DNSSEC result in a more secure DNSSEC operational environment than if DNSSEC
was simply disabled when it fails to perform as expected. was simply disabled when it fails to perform as expected.
9. IANA Considerations 9. IANA Considerations
No IANA actions are required. No IANA actions are required.
10. Normative References 10. Acknowledgments
We thank Petr Spacek for extensive comments and suggestions.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
skipping to change at page 18, line 24 skipping to change at page 18, line 32
Davis, CA 95617 Davis, CA 95617
US US
Email: ietf@hardakers.net Email: ietf@hardakers.net
Olafur Gudmundsson Olafur Gudmundsson
CloudFlare CloudFlare
San Francisco, CA 94107 San Francisco, CA 94107
USA USA
Email: ogud@ogud.com Email: olafur+ietf@cloudflare.com
Suresh Krishnaswamy Suresh Krishnaswamy
Parsons Parsons
7110 Samuel Morse Dr 7110 Samuel Morse Dr
Columbia, MD 21046 Columbia, MD 21046
US US
Email: suresh@tislabs.com Email: suresh@tislabs.com
 End of changes. 25 change blocks. 
35 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/