draft-ietf-dnsop-dnssec-roadblock-avoidance-04.txt   draft-ietf-dnsop-dnssec-roadblock-avoidance-05.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: October 6, 2016 CloudFlare Expires: February 12, 2017 CloudFlare
S. Krishnaswamy S. Krishnaswamy
Parsons Parsons
April 4, 2016 August 11, 2016
DNSSEC Roadblock Avoidance DNSSEC Roadblock Avoidance
draft-ietf-dnsop-dnssec-roadblock-avoidance-04.txt draft-ietf-dnsop-dnssec-roadblock-avoidance-05.txt
Abstract Abstract
This document describes problems that a DNSSEC aware resolver/ This document describes problems that a Validating DNS resolver,
application might run into within a non-compliant infrastructure. It stub-resolver or application might run into within a non-compliant
outline potential detection and mitigation techniques. The scope of infrastructure. It outlines potential detection and mitigation
the document is to create a shared approach to detect and overcome techniques. The scope of the document is to create a shared approach
network issues that a DNSSEC software/system may face. to detect and overcome 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 October 6, 2016. This Internet-Draft will expire on February 12, 2017.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Implementation experiences . . . . . . . . . . . . . . . 4 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Implementation experiences . . . . . . . . . . . . . . . 4
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.1. Test Zone Implementation . . . . . . . . . . . . . . 4
3. Detecting DNSSEC Non-Compilance . . . . . . . . . . . . . . . 5 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Determining DNSSEC support in neighboring recursive 3. Detecting DNSSEC Non-Compliance . . . . . . . . . . . . . . . 5
resolvers . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Determining DNSSEC support in recursive resolvers . . . . 6
3.1.1. Supports UDP answers . . . . . . . . . . . . . . . . 5 3.1.1. Supports UDP answers . . . . . . . . . . . . . . . . 6
3.1.2. Supports TCP answers . . . . . . . . . . . . . . . . 6 3.1.2. Supports TCP answers . . . . . . . . . . . . . . . . 6
3.1.3. Supports EDNS0 . . . . . . . . . . . . . . . . . . . 6 3.1.3. Supports EDNS0 . . . . . . . . . . . . . . . . . . . 7
3.1.4. Supports the DO bit . . . . . . . . . . . . . . . . . 6 3.1.4. Supports the DO bit . . . . . . . . . . . . . . . . . 7
3.1.5. Supports the AD bit DNSKEY algorithm 5 . . . . . . . 7 3.1.5. Supports the AD bit DNSKEY algorithm 5 and 8 . . . . 7
3.1.6. Returns RRsig for signed answer . . . . . . . . . . . 7 3.1.6. Returns RRsig for signed answer . . . . . . . . . . . 8
3.1.7. Supports querying for DNSKEY records . . . . . . . . 7 3.1.7. Supports querying for DNSKEY records . . . . . . . . 8
3.1.8. Supports querying for DS records . . . . . . . . . . 8 3.1.8. Supports querying for DS records . . . . . . . . . . 8
3.1.9. Supports negative answers with NSEC records . . . . . 8 3.1.9. Supports negative answers with NSEC records . . . . . 9
3.1.10. Supports negative answers with NSEC3 records . . . . 8 3.1.10. Supports negative answers with NSEC3 records . . . . 9
3.1.11. Supports queries where DNAME records lead to an 3.1.11. Supports queries where DNAME records lead to an
answer . . . . . . . . . . . . . . . . . . . . . . . 9 answer . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.12. Permissive DNSSEC . . . . . . . . . . . . . . . . . . 9 3.1.12. Permissive DNSSEC . . . . . . . . . . . . . . . . . . 10
3.1.13. UDP size limits . . . . . . . . . . . . . . . . . . . 9 3.1.13. Supports Unknown RRtypes . . . . . . . . . . . . . . 10
3.1.14. Supports Unknown RRtypes . . . . . . . . . . . . . . 9
3.2. Direct Network Queries . . . . . . . . . . . . . . . . . 10 3.2. Direct Network Queries . . . . . . . . . . . . . . . . . 10
3.2.1. Support for Remote UDP Over Port 53 . . . . . . . . . 10 3.2.1. Support for Remote UDP Over Port 53 . . . . . . . . . 11
3.2.2. Support for Remote UDP With Fragmentation . . . . . . 10 3.2.2. Support for Remote UDP With Fragmentation . . . . . . 11
3.2.3. Support for Outbound TCP Over Port 53 . . . . . . . . 11 3.2.3. Support for Outbound TCP Over Port 53 . . . . . . . . 11
3.3. Support for DNSKEY and DS combinations . . . . . . . . . 11 3.3. Support for DNSKEY and DS combinations . . . . . . . . . 12
4. Aggregating The Results . . . . . . . . . . . . . . . . . . . 11 4. Aggregating The Results . . . . . . . . . . . . . . . . . . . 12
4.1. Resolver capability description . . . . . . . . . . . . . 12 4.1. Resolver capability description . . . . . . . . . . . . . 12
5. Roadblock Avoidance . . . . . . . . . . . . . . . . . . . . . 12 5. Roadblock Avoidance . . . . . . . . . . . . . . . . . . . . . 13
5.1. Partial Resolver Usage . . . . . . . . . . . . . . . . . 15 5.1. Partial Resolver Usage . . . . . . . . . . . . . . . . . 16
5.1.1. Known Insecure Lookups . . . . . . . . . . . . . . . 15 5.1.1. Known Insecure Lookups . . . . . . . . . . . . . . . 16
5.1.2. Partial NSEC/NSEC3 Support . . . . . . . . . . . . . 15 5.1.2. Partial NSEC/NSEC3 Support . . . . . . . . . . . . . 16
6. Start-Up and Network Connectivity Issues . . . . . . . . . . 15 6. Start-Up and Network Connectivity Issues . . . . . . . . . . 16
6.1. What To Do . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. What To Do . . . . . . . . . . . . . . . . . . . . . . . 17
7. Quick Test . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Quick Test . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Test negative answers Algorithm 5 . . . . . . . . . . . . 17 7.1. Test negative answers Algorithm 5 . . . . . . . . . . . . 18
7.2. Test Algorithm 8 . . . . . . . . . . . . . . . . . . . . 17 7.2. Test Algorithm 8 . . . . . . . . . . . . . . . . . . . . 18
7.3. Test Algorithm 13 . . . . . . . . . . . . . . . . . . . . 17 7.3. Test Algorithm 13 . . . . . . . . . . . . . . . . . . . . 18
7.4. Really fails when DNSSEC does not validate . . . . . . . 17 7.4. Fails when DNSSEC does not validate . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. Normative References . . . . . . . . . . . . . . . . . . . . 17 11. Normative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document describes problems with DNSSEC ([RFC4034], [RFC4035]) This document describes problems observable during DNSSEC ([RFC4034],
deployment due to non-compliant infrastructure. It poses potential [RFC4035]) deployment that derive from non-compliant infrastructure.
detection and mitigation techniques. It poses potential detection and mitigation techniques.
1.1. Background 1.1. Notation
In this document a "Host Validator" can either be a validating stub-
resolver, such as library that an application has linked in, or a
validating resolver daemon running on the same machine. It may or
may not be trying to use upstream caching resolvers during its own
resolution process; both cases are covered by the tests defined in
this document.
The sub-variant of this is a "Validating Forwarding Resolver", which
is a resolver that is configured to use upstream Resolvers when
possible. A Validating Forward Resolver also needs to perform the
tests outlined in this document before using an upstream recursive
resolver.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Background
Deployment of DNSSEC validation is hampered by network components Deployment of DNSSEC validation is hampered by network components
that make it difficult or sometimes impossible for validating that make it difficult or sometimes impossible for validating
resolvers to effectively obtain the DNSSEC data they need. This can resolvers to effectively obtain the DNSSEC data they need. This can
occur for many different reasons including occur for many different reasons including, but not limited to:
o Because neighboring recursive resolvers and DNS proxies [RFC5625]
are not fully DNSSEC compliant
o Because resolvers are not even DNSSEC aware
o Because "middle-boxes" active block/restrict outbound traffic to o Because recursive resolvers and DNS proxies [RFC5625] are not
the DNS port (53) either UDP and/or TCP . fully DNSSEC compliant
o Network component in path does not allow UDP fragments o Because resolvers are not DNSSEC aware
o etc... o Because "middle-boxes" actively block, modify and/or restrict
outbound traffic to the DNS port (53) either UDP and/or TCP .
This document talks about ways a Host Validator can detect the state o In-path network components do not allow UDP fragments
of the network it is attached to, and ways to hopefully circumvent This document talks about ways that a Host Validator can detect the
the problems associated with the network defects it discovers. The state of the network it is attached to, and ways to hopefully
tests described in this document may be performed on any validating circumvent the problems associated with the network defects it
resolver to detect and prevent problems. While these recommendations discovers. The tests described in this document may be performed on
are mainly aimed at Host Validators it it prudent to perform these any validating resolver to detect and prevent problems. While these
test from regular Validating Resolvers before enabling just to make recommendations are mainly aimed at Host Validators it it prudent to
sure things work. perform these tests from regular Validating Resolvers before enabling
just to make sure things work.
There are situations where a host can not talk directly to a Resolver There are situations where a host can not talk directly to a
the tests below do not address how to overcome that. In these Resolver; the tests below can not address how to overcome that, and
situations it is not uncommon to get results that are not consistent. inconsistent results can be seen in such cases. This can happen, for
This mainly happens when there are DNS proxies/forwarders between the instance, when there are DNS proxies/forwarders between the user and
user and the actual resolvers. the actual resolvers.
1.2. Implementation experiences 1.3. 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 lack of support for specified DNSKEY algorithms and DS
digest 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
test compliance with Algorithm 5, 7 and Algorithm 13 with DS digest
algorithm 1 and 2.
1.3. Notation This document does describe compliance tests for algorithms 5, 7 and
13 with DS digest algorithms 1 and 2.
When we talk about a "Host Validator", this can either be a library 1.3.1. Test Zone Implementation
that an application has linked in or an actual validating resolver
running on the same machine.
A variant of this is a "Validating Forwarding Resolver", which is a In this document, the "test.example.com" domain is used to refer to
resolver that is configured to use upstream Resolvers if possible. DNS records which contain test records that have known DNSSEC
Validating Forward Resolver needs to perform the same set of tests properties associated with them. For example, the "badsign-
before using an upstream recursive resolver. a.test.example.com" domain is used below to refer to a DNS A record
where the signatures published for it are invalid (i.e., they are
"bad signatures" that should cause a validation failure).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", At the time of this publication, the "test.dnssec-tools.org" domain
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this implements all of these test records. Thus, it may be possible to
document are to be interpreted as described in [RFC2119]. replace "test.example.com" in this document with "test.dnssec-
tools.org" when performing real-world tests.
2. Goals 2. Goals
This document is intended to show how a Host Validator can detect the This document is intended to show how a Host Validator can detect the
capabilities of a nearby recursive resolver, and work around any capabilities of a recursive resolver, and work around any problems
problems that could potentially affect DNSSEC resolution. This that could potentially affect DNSSEC resolution. This enables the
enables the Host Validator to make use of the caching functionality Host Validator to make use of the caching functionality of the
of the recursive resolver, which is desirable in that it decreases recursive resolver, which is desirable in that it decreases network
network traffic and improves response times. traffic and improves response times.
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 3) to build a work around list
around list ahead of time (Section Section 5). There are pros and ahead of time (Section 5). There are pros and cons to both of these
cons to both of these paths that are application specific, and this paths that are application specific, and this document does not
document does not attempt to provide guidance about whether proactive attempt to provide guidance about whether proactive tests should or
tests should or should not be used. Either way, DNSSEC roadblock should not be used. Either way, DNSSEC roadblock avoidance
avoidance techniques ought to be used when needed and if possible. techniques ought to be used when needed and if possible.
Note: The same tests can be used for a recursive resolver to check if
its upstream connections hinder DNSSEC validation.
This document specifies two sets of tests to perform a comprehensive Note: Besides being useful for Host Validators, the same tests can be
one and a fast one. The fast one will detect most common problems, used for a recursive resolver to check if its upstream connections
thus if the fast one passes then the comprehensive MAY be executed as hinder DNSSEC validation.
well.
3. Detecting DNSSEC Non-Compilance 3. Detecting DNSSEC Non-Compliance
A Host Validator may choose to determine early-on what bottlenecks A Host Validator may choose to determine early-on what roadblocks
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.
These tests should be performed when a resolver determines its
network infrastructure has changed. Certainly a resolver should
perform these tests when first starting, but MAY also perform these
tests when they've detected network changes (e.g. address changes, or
network reattachment, etc).
NOTE: when performing these tests against an address, we make the NOTE: when performing these tests against an address, we make the
following assumption about that address: It is a uni-cast address or following assumption about that address: It is a uni-cast address or
an any-cast cluster where all servers have identical configuration an any-cast [RFC4786] cluster where all servers have identical
and connectivity. configuration 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" crap-ware/middle-boxes, like stupid clear of "DNS interfering" middle-boxes, like firewalls, proxies,
firewalls, proxies, forwarders. Presence of such crap can easily forwarders. Presence of such infrastructure can easily make a
make the recursive resolver look bad. It is beyond the scope of the recursive resolver appear to be improperly performing. It is beyond
document as how to test around the interference. the scope of the document as how to work around such interference,
although the tests defined in this document may indicate when such
misbehaving middle-ware is causing interference.
3.1. Determining DNSSEC support in neighboring recursive resolvers NOTE: This document specifies two sets of tests to perform: a
comprehensive one and a fast one. The fast one will detect most
common problems, thus if the fast one passes then the comprehensive
MAY be considered passed as well.
3.1. Determining DNSSEC support in 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 recursive resolvers. This section discusses the tests that a
that a neighboring recursive resolver MUST pass in order to be fully recursive resolver MUST pass in order to be fully usable as a DNS
usable as a near-by DNS cache. 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 Recursion Desired (RD) flag set when sending out a query and SHOULD
UDP. Unless otherwise stated, the tests MUST NOT have the DO bit set be sent over UDP. Unless otherwise stated, the tests MUST NOT have
or utilize any of the other DNSSEC related requirements, like EDNS0. the DO bit set or utilize any of the other DNSSEC related
The tests are designed to check for one feature at a time. requirements, like EDNS0, unless otherwise specified. The tests are
designed to check for support of one feature at a time.
3.1.1. Supports UDP answers 3.1.1. Supports UDP answers
Purpose: This tests basic DNS over UDP functionality to a resolver. Purpose: This tests basic DNS over UDP functionality to a resolver.
Test: A DNS request is sent to the resolver under test for an A Test: A DNS request is sent to the resolver under test for an A
record for a known existing domain, such as www.dnssec-tools.org. record for a known existing domain, such as good-a.test.example.com.
SUCCESS: A DNS response was received that contains an A record in the
answer section. (The data itself does not need to be checked.)
SUCCESS: A DNS response was received that contains an a A record in
the answer section. (The data itself does not need to be checked.)
Note: an implementation MAY chose to not perform the rest of the Note: an implementation MAY chose to not perform the rest of the
tests if this test fails, as clearly the resolver under test is tests if this test fails, as it is highly unlikely that the resolver
severely broken. under test will pass any of the remaining tests.
3.1.2. Supports TCP answers 3.1.2. Supports TCP answers
Purpose: This tests basic TCP functionality to a resolver. Purpose: This tests basic TCP functionality to a resolver.
Test: A DNS request is sent over TCP to the resolver under test for Test: A DNS request is sent over TCP to the resolver under test for
an A record for a known existing domain, such as www.dnssec- an A record for a known existing domain, such as good-
tools.org. a.test.example.com.
SUCCESS: A DNS response was received that contains an A record in the SUCCESS: A DNS response was received that contains an A record in the
answer section. (The data itself does not need to be checked.) answer section. (The data itself does not need to be checked.)
3.1.3. Supports EDNS0 3.1.3. Supports EDNS0
Purpose: Test whether a resolver properly supports the EDNS0 Purpose: Test whether a resolver properly supports the EDNS0
extension option. extension option.
Pre-requisite: "Supports UDP or TCP". Pre-requisite: "Supports UDP or TCP".
Test: Send a request to the resolver under test for an A record for a Test: Send a request to the resolver under test for an A record for a
known existing domain, such as www.dnssec-tools.org, with an EDNS0 known existing domain, such as good-a.test.example.com, with an EDNS0
OPT record in the additional section. OPT record in the additional section.
SUCCESS: A DNS response was received that contains an EDNS0 option SUCCESS: A DNS response was received that contains an EDNS0 option
with version number 0. with version number 0.
3.1.4. Supports the DO bit 3.1.4. Supports the DO bit
Purpose: This tests whether a resolver has minimal support of the DO Purpose: This tests whether a resolver has minimal support of the DO
bit. bit.
Pre-requisite: "Supports EDNS0". Pre-requisite: "Supports EDNS0".
Test: Send a request to the resolver under test for an A record for a Test: Send a request to the resolver under test for an A record for a
known existing domain such as www.dnssec-tools.org. Set the DO bit known existing domain such as good-a.test.example.com. Set the DO
in the outgoing query. bit in the outgoing query.
SUCCESS: A DNS response was received that contains the DO bit set. SUCCESS: A DNS response was received that contains the DO bit set.
Note: this only tests that the resolver sets the DO bit in the Note: this only tests that the resolver sets the DO bit in the
response. Later checks will determine if the DO bit was actually response. Later tests will determine if the DO bit was actually made
made use of. Some resolvers successfully pass this test because they use of. Some resolvers successfully pass this test because they
simply copy the unknown flags into the response. Don't worry, simply copy the unknown flags into the response. These resolvers
they'll fail the later tests. will fail the later tests.
3.1.5. Supports the AD bit DNSKEY algorithm 5 3.1.5. Supports the AD bit DNSKEY algorithm 5 and 8
Purpose: This tests whether the resolver is a validating resolver. Purpose: This tests whether the resolver is a validating resolver.
Pre-requisite: "Supports the DO bit". Pre-requisite: "Supports the DO bit".
Test: Send a request to the resolver under test for an A record for a Test: Send requests to the resolver under test for an A record for a
known existing domain in a DNSSEC signed zone which is verifiable to known existing domain in a DNSSEC signed zone which is verifiable to
a configured trust anchor, such as www.dnssec-tools.org using the a configured trust anchor, such as good-a.test.example.com using the
root's published DNSKEY or DS record as a trust anchor. Set the DO root's published DNSKEY or DS record as a trust anchor. Set the DO
bit in the outgoing query. bit in the outgoing query. This test should be done twice, once for
a zone that contains algorithm 5 (RSASHA1) and another for algorithm
8 (RSASHA256).
SUCCESS: A DNS response was received that contains the AD bit set. SUCCESS: A DNS response was received that contains the AD bit set for
algorithm 5 (RSASHA1).
BONUS: As AD is set this resolver supports Algorithm 5 RSASHA1 BONUS: The AD bit is set for a resolver that supports Algorithm 8
RSASHA256
3.1.6. Returns RRsig for signed answer 3.1.6. Returns RRsig for signed answer
Purpose: This tests whether a resolver will properly return RRSIG Purpose: This tests whether a resolver will properly return RRSIG
records when the DO bit is set. records when the DO bit is set.
Pre-requisite: "Supports the DO bit". Pre-requisite: "Supports the DO bit".
Test: Send a request to the resolver under test for an A record for a Test: Send a request to the resolver under test for an A record for a
known existing domain in a DNSSEC signed zone, such as www.dnssec- known existing domain in a DNSSEC signed zone, such as good-
tools.org. Set the DO bit in the outgoing query. a.test.example.com. Set the DO bit in the outgoing query.
SUCCESS: A DNS response was received that contains at least one RRSIG SUCCESS: A DNS response was received that contains at least one RRSIG
record. record.
3.1.7. Supports querying for DNSKEY records 3.1.7. Supports querying for DNSKEY records
Purpose: This tests whether a resolver can query for and receive a Purpose: This tests whether a resolver can query for and receive a
DNSKEY record from a signed zone. DNSKEY record from a signed zone.
Pre-requisite: "Supports the DO bit." Pre-requisite: "Supports the DO bit."
Test: Send a request to the resolver under test for an DNSKEY record Test: Send a request to the resolver under test for an DNSKEY record
which is known to exist in a signed zone, such as dnssec-tools.org/ which is known to exist in a signed zone, such as test.example.com/
DNSKEY. Set the DO bit in the outgoing query. DNSKEY. Set the DO bit in the outgoing query.
SUCCESS: A DNS response was received that contains a DNSKEY record in SUCCESS: A DNS response was received that contains a DNSKEY record in
the answer section. the answer section.
Note: Some DNSKEY RRset's are large and if the network path has Note: Some DNSKEY RRset's are large and if the network path has
problems with large answers this query may result in either false problems with large answers this query may result in either false
positive or false negative. In general the DNSKEY queried for is a positive or false negative. In general the DNSKEY queried for should
small enough to fit into 1220 byte answer, to avoid false negative be small enough to fit into a 1220 byte answer, to avoid false
result when TCP is disabled. However, querying many zones will negative result when TCP is disabled. However, querying many zones
result in answers greater than 1220 bytes so ideally TCP MUST be will result in answers greater than 1220 bytes so DNS over TCP MUST
available. be available for DNSSEC use in general.
3.1.8. Supports querying for DS records 3.1.8. Supports querying for DS records
Purpose: This tests whether a resolver can query for and receive a DS Purpose: This tests whether a resolver can query for and receive a DS
record from a signed zone. record from a signed zone.
Pre-requisite: "Supports the DO bit." Pre-requisite: "Supports the DO bit."
Test: Send a request to the resolver under test for an DS record Test: Send a request to the resolver under test for an DS record
which is known to exist in a signed zone, such as dnssec-tools.org/ which is known to exist in a signed zone, such as test.example.com/
DS. Set the DO bit in the outgoing query. DS. Set the DO bit in the outgoing query.
SUCCESS: A DNS response was received that contains a DS record in the SUCCESS: A DNS response was received that contains a DS record in the
answer section. answer section.
3.1.9. Supports negative answers with NSEC records 3.1.9. Supports negative answers with NSEC records
Purpose: This tests whether a resolver properly returns NSEC records Purpose: This tests whether a resolver properly returns NSEC records
for a non-existing domain in a DNSSEC signed zone. for a non-existing domain in a DNSSEC signed zone.
Pre-requisite: "Supports the DO bit." Pre-requisite: "Supports the DO bit."
Test: Send a request to the resolver under test for an A record which Test: Send a request to the resolver under test for an A record which
is known to not existing, such as non-existent.test.dnssec-tools.org. is known to not exist in an NSEC signed zone, such as non-
Set the DO bit in the outgoing query. existent.test.example.com. Set the DO bit in the outgoing query.
SUCCESS: A DNS response was received that contains an NSEC record. SUCCESS: A DNS response was received that contains an NSEC record.
Note: The query issued in this test MUST be sent to a NSEC signed Note: The query issued in this test MUST be sent to a NSEC signed
zone. Getting back appropriate NSEC3 records does not indicate a zone. Getting back appropriate NSEC3 records does not indicate a
failure, but a bad test. failure, but a bad test.
3.1.10. Supports negative answers with NSEC3 records 3.1.10. Supports negative answers with NSEC3 records
Purpose: This tests whether a resolver properly returns NSEC3 records Purpose: This tests whether a resolver properly returns NSEC3 records
([RFC5155]) for a non-existing domain in a DNSSEC signed zone. ([RFC5155]) for a non-existing domain in a DNSSEC signed zone.
Pre-requisite: "Supports the DO bit." Pre-requisite: "Supports the DO bit."
Test: Send a request to the resolver under test for an A record which Test: Send a request to the resolver under test for an A record which
is known to be non-existent, such as non-existent.nsec3- is known to be non-existent in a zone signed using NSEC3, such as
ns.test.dnssec-tools.org. Set the DO bit in the outgoing query. non-existent.nsec3-ns.test.example.com. Set the DO bit in the
outgoing query.
SUCCESS: A DNS response was received that contains an NSEC3 record. SUCCESS: A DNS response was received that contains an NSEC3 record.
Bonus: If the AD bit is set, this validator supports algorithm 7 Bonus: If the AD bit is set, this validator supports algorithm 7
RSASHA1-NSEC3-SHA1 RSASHA1-NSEC3-SHA1
Note: The query issued in this test MUST be sent to a NSEC3 signed Note: The query issued in this test MUST be sent to a NSEC3 signed
zone. Getting back appropriate NSEC records does not indicate a zone. Getting back appropriate NSEC records does not indicate a
failure, but a bad test. failure, but a bad test.
3.1.11. Supports queries where DNAME records lead to an answer 3.1.11. Supports queries where DNAME records lead to an answer
Purpose: This tests whether a resolver can query for an A record in a Purpose: This tests whether a resolver can query for an A record in a
zone with a known DNAME referral for the record's parent. zone with a known DNAME referral for the record's parent.
Test: Send a request to the resolver under test for an A record which Test: Send a request to the resolver under test for an A record which
is known to exist in a signed zone within a DNAME referral child is known to exist in a signed zone within a DNAME referral child
zone, such as good-a.dname-good-ns.test.dnssec-tools.net. zone, such as good-a.dname-good-ns.test.example.com.
SUCCESS: A DNS response was received that contains a DNAME in the SUCCESS: A DNS response was received that contains a DNAME in the
answer section. An RRSIG MUST also be received in the answer section answer section. An RRSIG MUST also be received in the answer section
that covers the DNAME record. that covers the DNAME record.
3.1.12. Permissive DNSSEC 3.1.12. Permissive DNSSEC
Purpose: To see if a validating resolver is ignoring DNSSEC Purpose: To see if a validating resolver is ignoring DNSSEC
validation failures. validation failures.
Pre-requisite: Supports the AD bit. Pre-requisite: Supports the AD bit.
Test: ask for data from a broken DNSSEC delegation such as badsign- Test: ask for data from a broken DNSSEC delegation such as badsign-
a.test.dnssec-tools.org. a.test.example.com.
SUCCESS: A reply with the Rcode set to SERVFAIL
3.1.13. UDP size limits
Strictly speaking nothing other than using TCP can be used to SUCCESS: A reply was received with the Rcode set to SERVFAIL
overcome this. Thus the host should use TCP fallback when UDP query
times out.
3.1.14. Supports Unknown RRtypes 3.1.13. Supports Unknown RRtypes
Purpose: Some DNS Resolvers/gateways only support some RRtypes. This Purpose: Some DNS Resolvers/gateways only support some RRtypes. This
causes problems for applications that need recently defined types. causes problems for applications that need recently defined types.
Pre-requisite: "Supports UDP or TCP". Pre-requisite: "Supports UDP or TCP".
Test: Send a request for recently defined type or unknown type in the Test: Send a request for recently defined type or unknown type in the
20000-22000 range, that resolves to a server that will return answer 20000-22000 range, that resolves to a server that will return an
for all types, such as alltypes.res.dnssecready.org answer for all types, such as alltypes.example.com (a server today
that supports this: alltypes.res.dnssecready.org)
SUCCESS: A DNS response was retrieved that contains the type SUCCESS: A DNS response was retrieved that contains the type
requested in the answer section. requested in the answer section.
3.2. Direct Network Queries 3.2. Direct Network Queries
If need be, a Host Validator may need to make direct queries to If need be, a Host Validator may need to make direct queries to
authoritative servers or known Open Recursive Resolvers in order to authoritative servers or known Open Recursive Resolvers in order to
collect data. To do that, a number of key network features MUST be collect data. To do that, a number of key network features MUST be
functional. functional.
3.2.1. Support for Remote UDP Over Port 53 3.2.1. Support for Remote UDP Over Port 53
Purpose: This tests basic UDP functionality to outside the local Purpose: This tests basic UDP functionality to outside the local
network. network.
Test: A DNS request is sent to a known distant authoritative server Test: A DNS request is sent to a known distant authoritative server
for a record known to be within that server's authoritative data. for a record known to be within that server's authoritative data.
Example: send a query to the address of ns1.dnssec-tools.org for the Example: send a query to the address of ns1.test.example.com for the
www.dnssec-tools.org/A record. good-a.test.example.com/A record.
SUCCESS: A DNS response was received that contains an a A record in SUCCESS: A DNS response was received that contains an A record in the
the answer section. answer section.
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.2.2. Support for Remote UDP With Fragmentation 3.2.2. Support for Remote UDP With Fragmentation
Purpose: This tests if the local network can receive fragmented UDP Purpose: This tests if the local network can receive fragmented UDP
answers answers
Pre-requisite: Local UDP > 1500 is possible Pre-requisite: Local UDP traffic > 1500 in size is possible
Test: A DNS request is sent over UDP to a known distant DNS address Test: A DNS request is sent over UDP to a known distant DNS address
asking for a record that has answer larger than 2000 bytes. Example asking for a record that has answer larger than 2000 bytes. For
send a query for the dnssec-tools.org/DNSKEY record with the DO bit example, send a query for the test.example.com/DNSKEY record with the
set in the outgoing query. DO bit set in the outgoing query.
Success: A DNS response was received that contains the large answer. Success: A DNS response was received that contains the large answer.
Note: A failure in getting large answers over UDP is not a serious Note: A failure in getting large answers over UDP is not a serious
problem if TCP is working. problem if TCP is working.
3.2.3. Support for Outbound TCP Over Port 53 3.2.3. Support for Outbound TCP Over Port 53
Purpose: This tests basic TCP functionality to outside the local Purpose: This tests basic TCP functionality to outside the local
network. network.
Test: A DNS request is sent over TCP to a known distant authoritative Test: A DNS request is sent over TCP to a known distant authoritative
server for a record known to be within that server's authoritative server for a record known to be within that server's authoritative
data. Example: send a query to the address of ns1.dnssec-tools.org data. Example: send a query to the address of ns1.test.example.com
for the www.dnssec-tools.org/A record. for the good-a.test.example.com/A record.
SUCCESS: A DNS response was received that contains an a A record in SUCCESS: A DNS response was received that contains an A record in the
the answer section. answer section.
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 what algorithm combinations are
supported. supported.
Pre-requisite: At least one of above tests has returned AD bit Pre-requisite: At least one of above tests has returned the AD bit
proving upstream is validating set proving that the 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 test for a
a known combination of the DS number (N) and DNSKEY number (M) of the known combination of the DS algorithm number (N) and DNSKEY algorithm
form ds-N.alg-M-nsec.dnssec-test.org, for example ds-2.alg-13- number (M) of the example form ds-N.alg-M-nsec.test.example.com.
nsec.dnssec-test.org TXT or ds-4.alg-13-nsec3.dnssec-test.org TXT. Examples:
SUCCESS: a DNS response is received with AD bit set with TXT record ds-2.alg-13-nsec.test.example.com TXT
in the answer section. or
ds-4.alg-13-nsec3.test.example.com TXT.
BONUS: AD in response to the examples above demonstrates support for SUCCESS: a DNS response is received with the AD bit set and with a
Algorithm 13 and the two DS algorithm(s) with both NSEC and NSEC3 matching record type in the answer section.
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 required, similarly NSEC3 is not defined for algorithms 1, M-nsec3 is required. Similarly NSEC3 is not defined for algorithms
3 and 5. Furthermore algorithms 2, 4, 9, 11 do not have definitions 1, 3 and 5. Furthermore algorithms 2, 4, 9, 11 do not currently have
to sign zones. definitions for signed 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.
4.1. Resolver capability description 4.1. Resolver capability description
skipping to change at page 12, line 24 skipping to change at page 13, line 12
DNSSEC Aware: The resolver passes all DNSSEC tests, but does not DNSSEC Aware: The resolver passes all DNSSEC tests, but does not
appropriately set the AD bit on answers, indicating it is not appropriately set the AD bit on answers, indicating it is not
validating. A Host Validator will function fine using this validating. A Host Validator will function fine using this
resolver as a forwarder. resolver as a forwarder.
Non-DNSSEC capable: The resolver is not DNSSEC aware and will make Non-DNSSEC capable: The resolver is not DNSSEC aware and will make
it hard for a Host Validator to operate behind it. It MAY be it hard for a Host Validator to operate behind it. It MAY be
usable for querying for data that is in known insecure sections of usable for querying for data that is in known insecure sections of
the DNS tree. the DNS tree.
Not a DNS Resolver: This is a bad address and not used anymore. Not a DNS Resolver: This is a improperly behaving resolver and not
should not be used at all.
While it would be great if all resolvers fell cleanly into one of the While it would be great if all resolvers fell cleanly into one of the
broad categories above, that is not the case. For that reason it is broad categories above, that is not the case. For that reason it is
necessary to augment the classification with more descriptive result, necessary to augment the classification with more descriptive result,
this is done by adding the word "Partial" in front of Validator/ this is done by adding the word "Partial" in front of Validator/
DNSSEC Aware classifications, followed by sub-descriptors of what is DNSSEC Aware classifications, followed by sub-descriptors of what is
not working. not working.
Unknown: Failed Unknown test Unknown: Failed the Unknown test
DNAME: Failed DNAME test DNAME: Failed the DNAME test
NSEC3: Failed NSEC3 test NSEC3: Failed the NSEC3 test
TCP: TCP not available TCP: TCP not available
SlowBig: UDP is size limited but TCP fallback works SlowBig: UDP is size limited but TCP fallback works
NoBig: TCP not available and UDP is size limited NoBig: TCP not available and UDP is size limited
Permissive: Passes data known to fail validation Permissive: Passes data known to fail validation
5. Roadblock Avoidance 5. Roadblock Avoidance
The goal of this document is to tie the above tests and aggregations The goal of this document is to tie the above tests and aggregations
to avoidance practices; however the document does not specify exactly to avoidance practices; however the document does not specify exactly
how to do that. how to do that.
Once we have determined what level of support is available in the Once we have determined what level of support is available in the
neighboring network, we can determine what MUST be done in order to network, we can determine what must be done in order to effectively
effectively act as a validating resolver. This section discusses act as a validating resolver. This section discusses some of the
some of the options available given the results from the previous options available given the results from the previous sections.
sections.
The general fallback approach can be described by the following The general fallback approach can be described by the following
sequence: sequence:
If the resolver is labeled as "Validator" or "DNSSEC aware" If the resolver is labeled as "Validator" or "DNSSEC aware":
Send query through this resolver and perform local Send queries through this resolver and perform local
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 are supported:
1. try iterating from Root
1. Try iterating from the Root
2. If the answer is SECURE/BOGUS: 2. If the answer is SECURE/BOGUS:
Return the result of the iteration Return the result of the iteration
3. If the query is INSECURE:
Re-query "Non-DNSSEC capable" servers and return 3. If the answer is INSECURE:
answers from them w/o the AD bit set to the client. Re-query "Non-DNSSEC capable" servers and return
This will increase the likelihood that spit-view unsigned answers from them w/o the AD bit set to the client.
This will increase the likelihood that split-view unsigned
answers are found. answers are found.
Else return an useful error code Else:
Return an error code and log a failure
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 avoid 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.
Any transport settings that are remembered for a particular name Any transport settings that are remembered for a particular name
server MUST be periodically refreshed; they should also be refreshed server MUST be periodically refreshed; they should also be refreshed
when an error is encountered as described below. when an error is encountered as described below.
For a stub resolver, problems with the name server MAY manifest For a stub resolver, problems with the name server can manifest
themselves as the following types of error conditions: themselves under the following types of error conditions:
o No response/error response or missing DNSSEC meta-data. o No Response, error response or missing DNSSEC meta-data
o Illegal Response, which prevents the validator from fetching all o Illegal Response: An illegal response is received, which prevents
necessary records required for constructing an authentication the validator from fetching all necessary records required for
chain. This could result when referral loops are encountered, constructing an authentication chain. This could result when
when any of the antecedent zone delegations are lame, when aliases referral loops are encountered, when any of the antecedent zone
are erroneously followed for certain RRtypes (such as SOA, DNSKEYs delegations are lame, when aliases are erroneously followed for
or DS records), or when resource records for certain types (e.g. certain RRtypes (such as SOA, DNSKEYs or DS records), or when
DS) are returned from a zone that is not authoritative for such resource records for certain types (e.g. DS) are returned from a
records. zone that is not authoritative for such records.
o Bogus Response, when the cryptographic assertions in the o Bogus Response: A Bogus Response is received, when the
authentication chain do not validate properly. cryptographic assertions in the authentication chain do not
validate properly.
For each of the above error conditions a validator MAY adopt the For each of the above error conditions a validator MAY adopt the
following dynamic fallback technique, preferring a particular following dynamic fallback technique, preferring a particular
approach if it is known to work for a given name server or zone from approach if it is known to work for a given name server or zone from
previous attempts. previous attempts.
o No response, error response, or missing DNSSEC meta-data o No response, error response, or missing DNSSEC meta-data:
* Re-try with different EDNS0 sizes (4096, 1492, None) * Re-try with different EDNS0 sizes (4096, 1492, None)
* Re-try with TCP only * Re-try with TCP only
* Perform an iterative query starting from Root if the previous * Perform an iterative query starting from the Root if the
error was returned from a lookup that had recursion enabled. previous error was returned from a lookup that had recursion
enabled.
* Re-try using an alternative transport method, if this * Re-try using an alternative transport method, if this
alternative method is known (configured) to be supported by the alternative method is known (configured) to be supported by the
nameserver in question. nameserver in question.
o Illegal Response o Illegal Response
* Perform an iterative query starting from Root if the previous * Perform an iterative query starting from the Root if the
error was returned from a lookup that had recursion enabled. previous error was returned from a lookup that had recursion
enabled.
* Check if any of the antecedent zones up to the closest * Check if any of the antecedent zones up to the closest
configured trust anchor are provably insecure. configured trust anchor are provably insecure.
o Bogus Response o Bogus Response
* Perform an iterative query starting from Root if the previous
error was returned from a lookup that had recursion enabled. * Perform an iterative query starting from the Root if the
previous error was returned from a lookup that had recursion
enabled.
For each fallback technique, attempts to multiple potential name For each fallback technique, attempts to multiple potential name
servers should be skewed such that the next name server is tried when servers should be skewed such that the next name server is tried when
the previous one encounters an error or a timeout is reached, the previous one encounters an error, a timeout is reached, or
whichever is earlier. whichever is earlier.
The validator SHOULD remember, in its zone-specific fallback cache, The validator SHOULD remember, in its zone-specific fallback cache,
any broken behavior identified for a particular zone for a duration any broken behavior identified for a particular zone for a duration
of that zone's SOA negative TTL. of that zone's SOA negative TTL.
The validator MAY place name servers that exhibit broken behavior The validator MAY place name servers that exhibit broken behavior
into a blacklist, and bypass these name servers for all zones that into a blacklist, and bypass these name servers for all zones that
they are authoritative for. The validator MUST time out entries in they are authoritative for. The validator MUST time out entries in
this name server blacklist periodically, where this interval could be this name server blacklist periodically, where this interval could be
set to be the same as the DNSSEC BAD cache default TTL. set to be the same as the DNSSEC BAD cache default TTL.
5.1. Partial Resolver Usage 5.1. Partial Resolver Usage
It MAY be possible to use Non-DNSSEC Capable caching resolvers in It may be possible to use Non-DNSSEC Capable caching resolvers in
careful ways if maximum optimization is desired. This section careful ways if maximum optimization is desired. This section
describes some of the advanced techniques that could be used to use a describes some of the advanced techniques that could be used to use a
resolver in at least a minimal way. Most of the time this would be resolver in at least a minimal way. Most of the time this would be
unnecessary, except in the case where none of the resolvers are fully unnecessary, except in the case where none of the resolvers are fully
compliant and thus the choices would be to use them at least compliant and thus the choices would be to use them at least
minimally or not at all (and no caching benefits would be available). minimally or not at all (and no caching benefits would be available).
5.1.1. Known Insecure Lookups 5.1.1. Known Insecure Lookups
If a resolver is Non-DNSSEC Capable but a section of the DNS tree has If a resolver is Non-DNSSEC Capable but a section of the DNS tree has
been determined to be Provably Insecure [RFC4035], then queries to been determined to be Provably Insecure [RFC4035], then queries to
this section of the tree MAY be sent through Non-DNSSEC Capable this section of the tree MAY be sent through Non-DNSSEC Capable
caching resolver. caching resolver.
5.1.2. Partial NSEC/NSEC3 Support 5.1.2. Partial NSEC/NSEC3 Support
This is real uncommon and only affects old resolvers, that also lack Resolvers that understand DNSSEC generally, and understand NSEC but
not NSEC3 are partially usable. These resolvers generally 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 occur when Time Synchronization: Time synchronization problems can occur when
a device which has been off for a period of time and the clock is a device which has been off for a period of time and the clock is
no longer in close synchronization with "real time" or when a no longer in close synchronization with "real time" or when a
device always has clock set to the same time during start-up. device always has clock set to the same time during start-up.
This will cause problems when the device needs to resolve their This will cause problems when the device needs to resolve 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, airport and coffee-shop style networks, where DNSSEC,
functional until the user proceeds through a series of forced web validation and even DNS are not functional until the user proceeds
pages used to enable their network. The tests in through a series of forced web pages used to enable their network.
Section Section 3 will produce very different results before and The tests in Section 3 will produce very different results before
after the network authorization has succeeded. APIs exist on many and after the network authorization has succeeded. APIs exist on
operating systems to detect initial network device status changes, many operating systems to detect initial network device status
such as right after DHCP has finished, but few (none?) exist to changes, such as right after DHCP has finished, but few (none?)
detect that authentication through a pay-wall has succeeded. exist to detect that authentication through a pay-wall has
succeeded.
There are only two choices when situations like this happen: There are only two choices when situations like this happen:
Continue to perform DNSSEC processing, which will likely result in Continue to perform DNSSEC processing, which will likely result in
all DNS requests failing. This is the most secure route, but all DNS requests failing. This is the most secure route, but
causes the most operational grief for users. causes the most operational grief for users.
Turn off DNSSEC support until the network proves to be usable. Turn off DNSSEC support until the network proves to be usable.
This allows the user to continue using the network, at the This allows the user to continue using the network, at the
sacrifice of security. It also allows for a denial of security- sacrifice of security. It also allows for a denial of security-
service attack if a man-in-the-middle can convince a device that service attack if a man-in-the-middle can convince a device that
DNSSEC is impossible. DNSSEC is impossible.
6.1. What To Do 6.1. What To Do
If Host Validator detects that DNSSEC resolution is not possible it If the Host Validator detects that DNSSEC resolution is not possible
SHOULD warn user. In the case there is no user no reporting can be it SHOULD log the event and/or SHOULD report an error to the user.
performed thus the device MAY have a policy of action, like continue In the case there is no user, then no reporting can be performed and
or fail. thus the device MAY have a policy of action, like continue or fail.
Until middle boxes allow DNSSEC protected information to traverse
them consistently, software implementations may need to offer this
choice to let users pick the security level they require. Note that
continuing without DNSSEC protection in the absence of a notification
or report could lead to situations where users assume a level of
security that does not exist.
7. Quick Test 7. Quick Test
The quick tests defined below make the following assumption that the The quick tests defined below make the assumption that the questions
questions are asked of a real resolver and the only real question is: to be asked are of a real resolver and the only real question is:
"how complete is the DNSSEC support?". This quick test as been "how complete is the DNSSEC support?". This quick test as been
implemented in few programs developed at IETF hackthons at IETF-91 implemented in few programs developed at IETF hackthons at IETF-91
and IETF-92. The programs use a common grading method, for each and IETF-92. The programs use a common grading method. For each
question that returns expected answer the resolver gets a point. If question that returns expected answer the resolver gets a point. If
the AD bit is set as expected the resolver gets a second point. the AD bit is set as expected the resolver gets a second point.
7.1. Test negative answers Algorithm 5 7.1. Test negative answers Algorithm 5
Query: realy-doesnotexist.dnssec-test.org. A Query: realy-doesnotexist.test.example.com. A
Answer: RCODE= NXDOMAIN, Empty Answer, Authority: NSEC proof Answer: RCODE= NXDOMAIN, Empty Answer, Authority: NSEC proof
7.2. Test Algorithm 8 7.2. Test Algorithm 8
Query: alg-8-nsec3.dnssec-test.org. SOA Query: alg-8-nsec3.test.example.com. SOA
Answer: RCODE= 0, Answer: SOA record Answer: RCODE= 0, Answer: SOA record
7.3. Test Algorithm 13 7.3. Test Algorithm 13
Query: alg-13-nsec.dnssec-test.org. SOA Query: alg-13-nsec.test.example.com. SOA
Answer: RCODE= 0, Answer: SOA record Answer: RCODE= 0, Answer: SOA record
7.4. Really fails when DNSSEC does not validate 7.4. Fails when DNSSEC does not validate
Query: dnssec-failed.org. SOA Query: dnssec-failed.test.example.com. SOA
Answer: RCODE=SERVFAIL, empty answer, and authority, AD=0 Answer: RCODE= SERVFAIL, empty answer, and authority, AD=0
8. Security Considerations 8. Security Considerations
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 DNSSEC protocol. It describes what may be possible to help detect
detect and mitigate these problems. Following these suggestions will and mitigate these problems. Following the outlined 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.
9. IANA Considerations 9. IANA Considerations
No IANA actions are required. No IANA actions are required.
10. Acknowledgments 10. Acknowledgments
We thank Petr Spacek for extensive comments and suggestions. We thank the IESG and DNSOP working group members for their extensive
comments and suggestions.
11. Normative References 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
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, March 2008.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
152, RFC 5625, DOI 10.17487/RFC5625, August 2009, BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<http://www.rfc-editor.org/info/rfc5625>. <http://www.rfc-editor.org/info/rfc5625>.
Authors' Addresses Authors' Addresses
Wes Hardaker Wes Hardaker
Parsons Parsons
P.O. Box 382 P.O. Box 382
Davis, CA 95617 Davis, CA 95617
US US
 End of changes. 114 change blocks. 
269 lines changed or deleted 320 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/