wdiff rfc8027.alt-original rfc8027.txt

DNSOP
Internet Engineering Task Force (IETF) W. Hardaker
Internet-Draft Parsons
Intended status:
Request for Comments: 8027 USC/ISI
BCP: 207 O. Gudmundsson
Category: Best Current Practice O. Gudmundsson
Expires: February 12, 2017 CloudFlare
ISSN: 2070-1721 S. Krishnaswamy
Parsons
August 11,
November 2016

DNSSEC Roadblock Avoidance
draft-ietf-dnsop-dnssec-roadblock-avoidance-05.txt

Abstract

This document describes problems that a Validating DNS resolver,
stub-resolver
stub-resolver, or application might run into within a non-compliant
infrastructure. It outlines potential detection and mitigation
techniques. The scope of the document is to create a shared approach
to detect and overcome network issues that a DNSSEC software/system
may face.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working memo documents an Internet Best Current Practice.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of six months RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on February 12, 2017.
http://www.rfc-editor.org/info/rfc8027.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 ....................................................3
1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 ...................................................3
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 .................................................3
1.3. Implementation experiences . . . . . . . . . . . . . . . 4 Experiences .................................4
1.3.1. Test Zone Implementation . . . . . . . . . . . . . . 4 ............................4
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 ...........................................................4
3. Detecting DNSSEC Non-Compliance . . . . . . . . . . . . . . . 5 Non-compliance .................................5
3.1. Determining DNSSEC support Support in recursive resolvers . . . . 6 Recursive Resolvers ..........5
3.1.1. Supports UDP answers . . . . . . . . . . . . . . . . 6 Answers ................................6
3.1.2. Supports TCP answers . . . . . . . . . . . . . . . . 6 Answers ................................6
3.1.3. Supports EDNS0 . . . . . . . . . . . . . . . . . . . 7 ......................................6
3.1.4. Supports the DO bit . . . . . . . . . . . . . . . . . 7 Bit .................................7
3.1.5. Supports the AD bit Bit DNSKEY algorithm Algorithms 5 and and/or 8 . . . . 7 ....7
3.1.6. Returns RRsig RRSIG for signed answer . . . . . . . . . . . 8 Signed Answer .....................7
3.1.7. Supports querying Querying for DNSKEY records . . . . . . . . 8 Records ................8
3.1.8. Supports querying Querying for DS records . . . . . . . . . . 8 Records ....................8
3.1.9. Supports negative answers Negative Answers with NSEC records . . . . . 9 Records .........8
3.1.10. Supports negative answers Negative Answers with NSEC3 records . . . . 9 Records .......9
3.1.11. Supports queries where Queries Where DNAME records lead Records Lead
to an
answer . . . . . . . . . . . . . . . . . . . . . . . 10 Answer .......................................9
3.1.12. Permissive DNSSEC . . . . . . . . . . . . . . . . . . 10 .................................10
3.1.13. Supports Unknown RRtypes . . . . . . . . . . . . . . 10 ..........................10
3.2. Direct Network Queries . . . . . . . . . . . . . . . . . 10 ....................................10
3.2.1. Support for Remote UDP Over over Port 53 . . . . . . . . . 11 ................10
3.2.2. Support for Remote UDP With with Fragmentation . . . . . . 11 ..........11
3.2.3. Support for Outbound TCP Over over Port 53 . . . . . . . . 11 ..............11
3.3. Support for DNSKEY and DS combinations . . . . . . . . . 12 Combinations ....................11
4. Aggregating The the Results . . . . . . . . . . . . . . . . . . . 12 ........................................12
4.1. Resolver capability description . . . . . . . . . . . . . 12 Capability Description ...........................12
5. Roadblock Avoidance . . . . . . . . . . . . . . . . . . . . . 13 ............................................13
5.1. Partial Resolver Usage . . . . . . . . . . . . . . . . . 16 ....................................16
5.1.1. Known Insecure Lookups . . . . . . . . . . . . . . . 16 .............................16
5.1.2. Partial NSEC/NSEC3 Support . . . . . . . . . . . . . 16 .........................16
6. Start-Up and Network Connectivity Issues . . . . . . . . . . 16 .......................16
6.1. What To to Do . . . . . . . . . . . . . . . . . . . . . . . 17 ................................................17
7. Quick Test . . . . . . . . . . . . . . . . . . . . . . . . . 17 .....................................................17
7.1. Test negative answers Negative Answers Algorithm 5 . . . . . . . . . . . . 18 .........................17
7.2. Test Algorithm 8 . . . . . . . . . . . . . . . . . . . . 18 ..........................................18
7.3. Test Algorithm 13 . . . . . . . . . . . . . . . . . . . . 18 .........................................18
7.4. Fails when When DNSSEC does not validate . . . . . . . . . . . 18 Does Not Validate .......................18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 ........................................18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. Normative References . . . . . . . . . . . . . . . . . . . . 19 ...........................................18
Acknowledgments ...................................................19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 ................................................19

1. Introduction

This document describes problems observable during DNSSEC ([RFC4034], ([RFC4034]
[RFC4035]) deployment that derive from non-compliant infrastructure.
It poses potential detection and mitigation techniques.

1.1. Notation

In this document document, a "Host Validator" can either be a validating stub-
resolver, such as a 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 Forwarding 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
that make it difficult or sometimes impossible for validating
resolvers to effectively obtain the DNSSEC data they need. This can
occur for many different reasons including, but not limited to: to, the
following:

o Because recursive Recursive resolvers and DNS proxies [RFC5625] are not being fully
DNSSEC compliant

o Because resolvers are Resolvers not being DNSSEC aware

o Because "middle-boxes" "Middleboxes" actively block, modify blocking, modifying, and/or restrict restricting
outbound traffic to the DNS port (53) either UDP and/or TCP .

o In-path network components do not allow allowing UDP fragments

This document talks about ways that a Host Validator can detect the
state of the network it is attached to, and ways to hopefully
circumvent the problems associated with the network defects it
discovers. The tests described in this document may be performed on
any validating resolver to detect and prevent problems. While these
recommendations are mainly aimed at Host Validators it Validators, it is prudent to
perform these tests from regular Validating Resolvers before enabling validating resolvers, just to make
sure things work.

There are situations where a host can not cannot talk directly to a Resolver;
the tests below can not cannot address how to overcome that, and inconsistent
results can be seen in such cases. This can happen, for instance,
when there are DNS proxies/forwarders between the user and the actual
resolvers.

1.3. Implementation experiences Experiences

Multiple lessons learned from multiple implementations led to the
development of this document, including (in alphabetical order)
DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger,
and FCC_Grade.

Detecting lack of support for specified DNSKEY Domain Name System Key
(DNSKEY) algorithms and DS Delegation Signer (DS) digest algorithms is
outside the scope of this document document, but the document provides
information on how to do that, see that. See the sample test tool: https://github.com/ogud/DNSSEC_ALG_Check
<https://github.com/ogud/DNSSEC_ALG_Check>.

This document does describe compliance tests for algorithms 5, 7 7, and
13 with DS digest algorithms 1 and 2.

1.3.1. Test Zone Implementation

In this document, the "test.example.com" domain is used to refer to
DNS records which that contain test records that have known DNSSEC
properties associated with them. For example, the "badsign-
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).

At the time of this publication, the "test.dnssec-tools.org" domain
implements all of these test records. Thus, it may be possible to
replace "test.example.com" in this document with "test.dnssec-
tools.org" when performing real-world tests.

2. Goals

This document is intended to show how a Host Validator can detect the
capabilities of a recursive resolver, resolver and work around any problems
that could potentially affect DNSSEC resolution. This enables the
Host Validator to make use of the caching functionality of the
recursive resolver, which is desirable in that it decreases network
traffic and improves response times.

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
is getting from real-world queries issued to it, it or it can proactively
test for problems (Section 3) to build a work around workaround list ahead of
time (Section 5). There are pros and cons to both of these paths
that are application specific, and this document does not attempt to
provide guidance about whether proactive tests should or should not
be used. Either way, DNSSEC roadblock avoidance techniques ought to
be used when needed and if possible.

Note: Besides being useful for Host Validators, the same tests can be
used for a recursive resolver to check if its upstream connections
hinder DNSSEC validation.

3. Detecting DNSSEC Non-Compliance

A Host Validator may choose to determine early-on what roadblocks
exist that may hamper its ability to perform DNSSEC look-ups. Non-compliance

This section outlines tests that can be done a validator should perform in order
to test certain features of the surrounding network.

These tests should be performed when a resolver determines its
network infrastructure has changed. Certainly a A resolver
should perform these tests when first starting, starting but MAY also perform
these tests when they've it has detected network changes (e.g. (e.g., address
changes, or network reattachment, etc).

NOTE: when or etc.).

Note: When performing these tests against an address, we make the
following assumption about that address: It it is a uni-cast unicast address or
an any-cast anycast [RFC4786] cluster where all servers have identical
configuration and connectivity.

NOTE: when

Note: When performing these tests tests, we also assume that the path is
clear of "DNS interfering" middle-boxes, "DNS-interfering" middleboxes, like firewalls, proxies, or
forwarders. Presence The presence of such infrastructure can easily make a
recursive resolver appear to be improperly performing. functioning improperly. It is beyond
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 middleware is causing interference.

NOTE:

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 problems; thus, if the fast one passes passes, then the comprehensive
one MAY be considered passed as well.

3.1. Determining DNSSEC support Support in recursive resolvers Recursive Resolvers

Ideally, a Host Validator can make use of the caching present in
recursive resolvers. This section discusses the tests that a
recursive resolver MUST pass in order to be fully usable as a DNS
cache.

Unless stated otherwise, otherwise:

o all of the following tests SHOULD have the Recursion Desired (RD)
flag set when sending out a query and queries SHOULD be sent over
UDP. Unless otherwise stated,

o the tests MUST NOT have the DO DNSSEC OK (DO) bit set or utilize any
of the other DNSSEC related DNSSEC-related requirements, like EDNS0, unless otherwise specified. Extension
Mechanisms for DNS (EDNS0).

The tests are designed to check for support of one feature at a time.

3.1.1. Supports UDP answers Answers

Purpose: This tests basic DNS over UDP DNS-over-UDP functionality to a resolver.

Test: A DNS request is sent to the resolver under test for an A
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.)

Note: an An implementation MAY chose to not to perform the rest of the
tests if this test fails, as it is highly unlikely that the resolver
under test will pass any of the remaining tests.

3.1.2. Supports TCP answers Answers

Purpose: This tests basic TCP functionality to a resolver.

Test: A DNS request is sent over TCP to the resolver under test for
an A 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.)

3.1.3. Supports EDNS0

Purpose: Test whether a resolver properly supports the EDNS0
extension option.

Pre-requisite: "Supports

Prerequisite: Supports UDP or TCP". TCP.

Test: Send a request to the resolver under test for an A record for a
known existing domain, such as good-a.test.example.com, with an EDNS0
OPT record in the additional section.

SUCCESS: A DNS response was received that contains an EDNS0 option
with version number 0.

3.1.4. Supports the DO bit Bit

Purpose: This tests whether a resolver has minimal support of the DO
bit.

Pre-requisite: "Supports EDNS0".

Prerequisite: Supports EDNS0.

Test: Send a request to the resolver under test for an A record for a
known existing domain domain, such as good-a.test.example.com. Set the DO
bit in the outgoing query.

SUCCESS: A DNS response was received that contains the DO bit set.

Note: this This only tests that the resolver sets set the DO bit in the
response. Later tests will determine if the DO bit was actually made
use of. Some resolvers successfully pass this test because they
simply copy the unknown flags into the response. These resolvers
will fail the later tests.

3.1.5. Supports the AD bit Bit DNSKEY algorithm Algorithms 5 and and/or 8

Purpose: This tests whether the resolver is a validating resolver.

Pre-requisite: "Supports

Prerequisite: Supports the DO bit". bit.

Test: Send requests to the resolver under test for an A record for a
known existing domain in a DNSSEC signed DNSSEC-signed zone which that is verifiable to 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
bit in the outgoing query. This test should be done twice, twice: once for
a zone that contains algorithm 5 (RSASHA1) and another again for algorithm 8
(RSASHA256).

SUCCESS: A DNS response was received that contains the AD Authentic Data
(AD) bit set for algorithm 5 (RSASHA1).

BONUS: The AD bit is set for a resolver that supports Algorithm algorithm 8
RSASHA256
(RSASHA256).

3.1.6. Returns RRsig RRSIG for signed answer Signed Answer

Purpose: This tests whether a resolver will properly return RRSIG Resource
Record Signature (RRSIG) records when the DO bit is set.

Pre-requisite: "Supports

Prerequisite: Supports the DO bit". bit.

Test: Send a request to the resolver under test for an A record for a
known existing domain in a DNSSEC signed DNSSEC-signed zone, such as good-
a.test.example.com. Set the DO bit in the outgoing query.

SUCCESS: A DNS response was received that contains at least one RRSIG
record.

3.1.7. Supports querying Querying for DNSKEY records Records

Purpose: This tests whether a resolver can query for and receive a
DNSKEY record from a signed zone.

Pre-requisite: "Supports

Prerequisite: Supports the DO bit." bit.

Test: Send a request to the resolver under test for an a DNSKEY record
which
that is known to exist in a signed zone, such as test.example.com/
DNSKEY. Set the DO bit in the outgoing query.

SUCCESS: A DNS response was received that contains a DNSKEY record in
the answer section.

Note: Some DNSKEY RRset's Resource Record Sets (RRsets) are large and and, if the
network path has problems with large answers answers, this query may result
in either a false positive or a false negative. In general general, the
DNSKEY queried for should be small enough to fit into a 1220 byte answer, 1220-byte
answer to avoid a false negative result when TCP is disabled.
However, querying many zones will result in answers greater than 1220 bytes
bytes, so DNS over TCP MUST be available for DNSSEC use in general.

3.1.8. Supports querying Querying for DS records Records

Purpose: This tests whether a resolver can query for and receive a DS
record from a signed zone.

Pre-requisite: "Supports

Prerequisite: Supports the DO bit." bit.

Test: Send a request to the resolver under test for an a DS record
which that
is known to exist in a signed zone, such as test.example.com/
DS. test.example.com/DS. Set
the DO bit in the outgoing query.

SUCCESS: A DNS response was received that contains a DS record in the
answer section.

3.1.9. Supports negative answers Negative Answers with NSEC records Records

Purpose: This tests whether a resolver properly returns NSEC NextSECure
(NSEC) records for a non-existing nonexisting domain in a DNSSEC signed DNSSEC-signed zone.

Pre-requisite: "Supports

Prerequisite: Supports the DO bit." bit.

Test: Send a request to the resolver under test for an A record which that
is known to not exist in an NSEC signed NSEC-signed zone, such as non-
existent.test.example.com.
nonexistent.test.example.com. Set the DO bit in the outgoing query.

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 an NSEC-signed
zone. Getting back appropriate NSEC3 records does not indicate a
failure, but a bad test.

3.1.10. Supports negative answers Negative Answers with NSEC3 records Records

Purpose: This tests whether a resolver properly returns NSEC3 records
([RFC5155]) for a non-existing nonexisting domain in a DNSSEC signed DNSSEC-signed zone.

Pre-requisite: "Supports

Prerequisite: Supports the DO bit." bit.

Test: Send a request to the resolver under test for an A record which that
is known to be non-existent nonexistent in a zone signed using NSEC3, such as
non-existent.nsec3-ns.test.example.com.
nonexistent.nsec3-ns.test.example.com. Set the DO bit in the
outgoing query.

SUCCESS: A DNS response was received that contains an NSEC3 record.

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 an NSEC3-signed
zone. Getting back appropriate NSEC records does not indicate a
failure, but a bad test.

3.1.11. Supports queries where Queries Where DNAME records lead Records Lead to an answer Answer

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.

Test: Send a request to the resolver under test for an A record which that
is known to exist in a signed zone within a DNAME referral DNAME-referral child
zone, such as good-a.dname-good-ns.test.example.com.

SUCCESS: A DNS response was received that contains a DNAME in the
answer section. An RRSIG MUST also be received in the answer section
that covers the DNAME record.

3.1.12. Permissive DNSSEC

Purpose: To see if a validating resolver is ignoring DNSSEC
validation failures.

Pre-requisite:

Prerequisite: Supports the AD bit.

Test: ask Ask for data from a broken DNSSEC delegation delegation, such as badsign-
a.test.example.com.

SUCCESS: A reply was received with the Rcode set to SERVFAIL SERVFAIL.

3.1.13. Supports Unknown RRtypes

Purpose: Some DNS Resolvers/gateways only support some RRtypes. Resource
Record Types (RRtypes). This causes problems for applications that
need recently defined types.

Pre-requisite: "Supports

Prerequisite: Supports UDP or TCP". TCP.

Test: Send a request for a recently defined type or an unknown type
in the 20000-22000 range, that resolves to a server that will return
an answer for all types, such as alltypes.example.com (a server today
that supports this: alltypes.res.dnssecready.org) this is alltypes.res.dnssecready.org).

SUCCESS: A DNS response was retrieved that contains the type
requested in the answer section.

3.2. Direct Network Queries

If need be, needed, a Host Validator may need to make direct queries to
authoritative servers or known Open Recursive Resolvers in order to
collect data. To do that, a number of key network features MUST be
functional.

3.2.1. Support for Remote UDP Over over Port 53

Purpose: This tests basic UDP functionality to outside the local
network.

Test: A DNS request is sent to a known distant authoritative server
for a record known to be within that server's authoritative data.
Example: send a query to the address of ns1.test.example.com for the
good-a.test.example.com/A record.

SUCCESS: A DNS response was received that contains an A record in the
answer section.

Note: an An implementation can use the local resolvers for determining
the address of the name server that is authoritative for the given
zone. The recursive bit MAY be set for this request, but it does not
need to be.

3.2.2. Support for Remote UDP With with Fragmentation

Purpose: This tests if the local network can receive fragmented UDP
answers

Pre-requisite:
answers.

Prerequisite: Local UDP traffic > 1500 bytes in size is possible possible.

Test: A DNS request is sent over UDP to a known distant DNS address
asking for a record that has an answer larger than 2000 bytes. For
example, send a query for the test.example.com/DNSKEY record with the
DO bit set in the outgoing query.

Success:

SUCCESS: A DNS response was received that contains the large answer.

Note: A failure in getting large answers over UDP is not a serious
problem if TCP is working.

3.2.3. Support for Outbound TCP Over over Port 53

Purpose: This tests basic TCP functionality to outside the local
network.

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
data. Example: send a query to the address of ns1.test.example.com
for the good-a.test.example.com/A record.

SUCCESS: A DNS response was received that contains an A record in the
answer section.

3.3. Support for DNSKEY and DS combinations Combinations

Purpose: These tests This test can check what algorithm combinations are
supported.

Pre-requisite: At least one of above tests has returned

Prerequisite: Supports the AD bit
set proving that the upstream is validating for Algorithms 5 and/or 8.

Test: A DNS request is sent over UDP to the resolver under test for a
known combination of the DS algorithm number (N) and DNSKEY algorithm
number (M) of the example form ds-N.alg-M-nsec.test.example.com.
Examples:

ds-2.alg-13-nsec.test.example.com TXT
or
ds-4.alg-13-nsec3.test.example.com TXT. TXT

SUCCESS: a A DNS response is received with the AD bit set and with a
matching record type in the answer section.

Note: for For algorithms 6 and 7, NSEC is not defined thus defined; thus, a query for alg-
M-nsec3
alg-M-nsec3 is required. Similarly Similarly, NSEC3 is not defined for
algorithms 1, 3 3, and 5. Furthermore Furthermore, algorithms 2, 4, 9, and 11 do
not currently have definitions for signed zones.

4. Aggregating The the Results

Some conclusions can be drawn from the results of the above tests in
an "aggregated" form. This section defines some labels to assign to
a resolver under test given the results of the tests run against
them.

4.1. Resolver capability description Capability Description

This section will group and label certain common results results.

Resolvers are classified into the following broad behaviors:

Validator: The resolver passes all DNSSEC tests and had the AD bit
appropriately set.

DNSSEC Aware:

DNSSEC-Aware: The resolver passes all DNSSEC tests, but it does not
appropriately set the AD bit on answers, indicating it is not
validating. A Host Validator will function fine using this
resolver as a forwarder.

Non-DNSSEC capable:

Non-DNSSEC-Capable: The resolver is not DNSSEC aware DNSSEC-aware and will make
it hard for a Host Validator to operate behind it. It MAY be
usable for querying to query for data that is in known insecure sections of the
DNS tree.

Not a DNS Resolver: This is a an 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
broad categories above, that is not the case. For that reason reason, it is
necessary to augment the classification with a more descriptive result,
this
result. This is done by adding the word "Partial" in front of Validator/
DNSSEC Aware
Validator/DNSSEC-aware classifications, followed by sub-descriptors
of what is not working.

Unknown: Failed the Unknown unknown test

DNAME: Failed the DNAME test

NSEC3: Failed the NSEC3 test

TCP: TCP not available

SlowBig: UDP is size limited limited, but TCP fallback works

NoBig: TCP not available and UDP is size limited

Permissive: Passes data known to fail validation

5. Roadblock Avoidance

The goal of this document is to tie the above tests and aggregations
to avoidance practices; however however, the document does not specify
exactly how to do that.

Once we have determined what level of support is available in the
network, we can determine what must be done in order to effectively
act as a validating resolver. This section discusses some of the
options available given the results from the previous sections.

The general fallback approach can be described by the following
sequence:

If the resolver is labeled as "Validator" or "DNSSEC aware": "DNSSEC-aware":

Send queries through this resolver and perform local
validation on the results.

If validation fails, try the next resolver

Else resolver.

Else, if the resolver is labeled "Not a DNS Resolver" or
"Non-DNSSEC capable":
"Non-DNSSEC-capable":

Mark it as unusable and try the next resolver resolver.

Else if no more resolvers are configured and if direct queries
are supported:

1. Try iterating from the Root Root.

2. If the answer is SECURE/BOGUS:
Return the result of the iteration iteration.

3. If the answer is INSECURE:
Re-query "Non-DNSSEC capable" "Non-DNSSEC-capable" servers and return
answers from them w/o without the AD bit set to the client.

This will increase the likelihood that split-view unsigned
answers are found.

Else:

Return an error code and log a failure failure.

While attempting resolution through a particular recursive name
server with a particular transport method that worked, any transport-
specific parameters MUST be remembered in order to avoid any
unnecessary fallback attempts.

Transport-specific parameters MUST also be remembered for each
authoritative name server that is queried while performing an
iterative mode lookup.

Any transport settings that are remembered for a particular name
server MUST be periodically refreshed; they should also be refreshed
when an error is encountered as described below.

For a stub resolver, problems with the name server can manifest
themselves under the following types of error conditions:

o No Response, error response response, or missing DNSSEC meta-data metadata

o Illegal Response: An illegal response is received, which prevents
the validator from fetching all the necessary records required for
constructing an authentication chain. This could result when
referral loops are encountered, when any of the antecedent zone
delegations are lame, when aliases are erroneously followed for
certain RRtypes (such as SOA, DNSKEYs Start of Authority (SOA), DNSKEYs, or DS
records), or when resource records for certain types (e.g. (e.g., DS)
are returned from a zone that is not authoritative for such
records.

o Bogus Response: A Bogus Response is received, when the
cryptographic assertions in the authentication chain do not
validate properly.

For each of the above error conditions conditions, a validator MAY adopt the
following dynamic fallback technique, preferring a particular
approach if it is known to work for a given name server or zone from
previous attempts.

o No response, error response, or missing DNSSEC meta-data: metadata:

* Re-try Retry with different EDNS0 sizes (4096, 1492, None) or None).

* Re-try Retry with TCP only only.

* Perform an iterative query starting from the Root if the
previous error was returned from a lookup that had recursion
enabled.

* Re-try Retry using an alternative transport method, if this
alternative method is known (configured) to be supported by the
nameserver
name server in question.

o Illegal Response

* Perform an iterative query starting from the Root if the
previous error was returned from a lookup that had recursion
enabled.

* Check if any of the antecedent zones up to the closest
configured trust anchor are provably insecure. Insecure.

o Bogus Response

* 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 reach multiple potential
name servers should be skewed such that the next name server is tried
when the previous one encounters returns an error, error or a timeout is reached, or
whichever is earlier. reached.

The validator SHOULD remember, in its zone-specific fallback cache,
any broken behavior identified for a particular zone for a duration
of that zone's SOA negative SOA-negative TTL.

The validator MAY place name servers that exhibit broken behavior
into a blacklist, blacklist and bypass these name servers for all zones that
they are authoritative for. The validator MUST time out entries in
this name server blacklist periodically, where this interval could be
set to be the same as the DNSSEC BAD cache default TTL.

5.1. Partial Resolver Usage

It may be possible to use Non-DNSSEC Capable Non-DNSSEC-Capable caching resolvers in
careful ways if maximum optimization is desired. This section
describes some of the advanced techniques that could be used implemented
to use a resolver in at least a minimal way. Most of the time time, this
would be
unnecessary, except in unnecessary; the exception being the case where none of the
resolvers are fully compliant and thus and, thus, the choices choice would be to use
them at least minimally or not at all (and no caching benefits would
be available).

5.1.1. Known Insecure Lookups

If a resolver is Non-DNSSEC Capable Non-DNSSEC-Capable but a section of the DNS tree has
been determined to be Provably Insecure [RFC4035], then queries to this
section of the tree MAY be sent through Non-DNSSEC Capable the Non-DNSSEC-Capable
caching resolver.

5.1.2. Partial NSEC/NSEC3 Support

Resolvers that understand DNSSEC generally, and understand NSEC but
not NSEC3 NSEC3, are partially usable. These resolvers generally also lack
support for Unknown unknown types, rendering them mostly useless and to be
avoided.

6. Start-Up and Network Connectivity Issues

A number of scenarios will produce either short-term or long-term
connectivity issues with respect to DNSSEC validation. Consider the
following cases:

Time Synchronization: Time synchronization problems can occur when
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 device
always has the clock set to the same time during start-up. This
will cause problems when the device needs to resolve their its source of
time synchronization, such as "ntp.example.com".

Changing Network Properties: A newly established network
connection may change state shortly after a an HTTP-based pay-wall paywall
authentication system has been used. This is especially common in
hotel, airport airport, and coffee-shop style networks, networks where DNSSEC,
validation validation,
and even DNS are not functional until the user proceeds through a
series of forced web pages used to enable their network. The
tests in Section 3 will produce very different results before and
after the network authorization has succeeded. APIs exist on many
operating systems to detect initial network device status changes,
such as right after DHCP has finished, but few (none?) exist to
detect that authentication through a pay-wall paywall has succeeded.

There are only two choices when situations like this happen:

Continue to perform DNSSEC processing, which will likely result in
all DNS requests failing. This is the most secure route, but
causes the most operational grief for users.

Turn off DNSSEC support until the network proves to be usable.
This allows the user to continue using the network, at the
sacrifice cost of
security. It also allows for a denial of security-
service denial-of-service attack if a man-in-the-middle man-
in-the-middle can convince a device that DNSSEC is impossible.

6.1. What To to Do

If the Host Validator detects that DNSSEC resolution is not possible possible,
it SHOULD log the event and/or SHOULD report an error to the user.
In the case where there is no user, then no reporting can be performed and
thus performed;
thus, the device MAY have a policy of action, like continue or fail.
Until middle boxes middleboxes allow DNSSEC protected 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

The quick tests defined below make the assumption that the questions
to be asked are of a real resolver resolver; and the only real question is:
"how
"How complete is the DNSSEC support?". This quick test as has been
implemented in a few programs developed at IETF hackthons hackathons at IETF-91 IETF 93
and IETF-92. IETF 94. The programs use a common grading method. For each
question that returns an expected answer answer, the resolver gets a point.
If the AD bit is set as expected expected, the resolver gets a second point.

7.1. Test negative answers Negative Answers Algorithm 5

Query: realy-doesnotexist.test.example.com. A

Answer: RCODE= NXDOMAIN, Empty Answer, Authority: NSEC proof NSEC-proof

7.2. Test Algorithm 8

Query: alg-8-nsec3.test.example.com. SOA

Answer: RCODE= 0, Answer: SOA record

7.3. Test Algorithm 13

Query: alg-13-nsec.test.example.com. SOA

Answer: RCODE= 0, Answer: SOA record

7.4. Fails when When DNSSEC does not validate Does Not Validate

Query: dnssec-failed.test.example.com. SOA

Answer: RCODE= SERVFAIL, empty answer, and authority, AD=0

8. Security Considerations

This document discusses problems that may occur while deploying the
DNSSEC protocol. It describes what may be possible to help detect
and mitigate these problems. Following the outlined suggestions will
result in a more secure DNSSEC operational DNSSEC-operational environment than if DNSSEC
was simply disabled.

9. IANA Considerations

No IANA actions are required.

11. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005. 2005,
<http://www.rfc-editor.org/info/rfc4034>.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005. 2005,
<http://www.rfc-editor.org/info/rfc4035>.

[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
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008. 2008,
<http://www.rfc-editor.org/info/rfc5155>.

[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<http://www.rfc-editor.org/info/rfc5625>.

10.

Acknowledgments

We thank the IESG and DNSOP working group members for their extensive
comments and suggestions.

Authors' Addresses

Wes Hardaker
Parsons
USC/ISI
P.O. Box 382
Davis, CA 95617
US
United States of America

Email: ietf@hardakers.net

Olafur Gudmundsson
CloudFlare
San Francisco, CA 94107
USA
United States of America

Email: olafur+ietf@cloudflare.com

Suresh Krishnaswamy
Parsons
7110 Samuel Morse Dr
Columbia, MD 21046
US
United States of America

Email: suresh@tislabs.com