RFC 8027

DNSSEC Roadblock Avoidance

📅 published November 2016, from ietf

DNSSEC Roadblock Avoidance 🦋

okay bestie, so this is RFC 8027 💅 It's a Best Current Practice (that's BCP 207) from November 2016, published on the IETF stream with ISSN 2070-1721. The authors are W. Hardaker (USC/ISI), O. Gudmundsson (CloudFlare), and S. Krishnaswamy (Parsons). The header doesn't list any Obsoletes or Updates entries, so this one isn't replacing or patching anything else. 🎀

Abstract 💖

okay so this doc is about the problems a validating DNS resolver, a stub-resolver, or an application can run into when the network around it is non-compliant 😭 It walks through ways to detect those problems and some mitigation techniques. The big goal is a shared approach for spotting and getting around network issues that DNSSEC software or systems might hit. it's giving teamwork 🫶

Status of This Memo 🌸

This memo documents an Internet Best Current Practice.

This doc is a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on BCPs, check Section 2 of RFC 7841 🧚

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8027 🔗

Copyright Notice 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read these, bestie, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🍓

Table of Contents 🧾

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

1. Introduction ✨

okay so this doc describes the problems you can notice while deploying DNSSEC ([RFC4034] [RFC4035]) that come from non-compliant infrastructure 😤 It also suggests possible ways to detect those problems and mitigate them 🦋

1.1. Notation 🎀

So in this doc, a "Host Validator" can be either a validating stub-resolver (like a library an app has linked in) or a validating resolver daemon running on the same machine. It may or may not be using upstream caching resolvers during its own resolution, and both cases are covered by the tests in this document 💅

There's also a sub-variant called a "Validating Forwarding Resolver". That's a resolver configured to use upstream resolvers when it can. A Validating Forwarding Resolver also needs to run the tests in this document before it uses 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 🌸

DNSSEC validation deployment keeps getting blocked by network components that make it hard, or sometimes impossible, for validating resolvers to actually get the DNSSEC data they need 😭 There are a bunch of reasons this can happen, including (but not limited to) these:

Recursive resolvers and DNS proxies [RFC5625] that aren't fully DNSSEC compliant
Resolvers that aren't DNSSEC aware
"Middleboxes" that block, modify, and/or restrict outbound traffic to the DNS port (53), either UDP and/or TCP
In-path network components that don't allow UDP fragments

This doc talks about how a Host Validator can check the state of the network it's attached to, and about ways to hopefully get around the problems tied to whatever network defects it finds 🔥 The tests here can be run against any validating resolver to spot and prevent problems. These recommendations are mainly aimed at Host Validators, but it's prudent to run these tests from regular validating resolvers too, just to make sure everything works 💖

Sometimes a host can't talk directly to a resolver. The tests below can't tell you how to fix that, and you might see inconsistent results in those cases. For example, this can happen when there are DNS proxies or forwarders sitting between the user and the actual resolvers 🙈

1.3. Implementation Experiences 🍓

Lots of lessons learned from different implementations went into this doc. In alphabetical order, they include DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger, and FCC_Grade 🌈

Detecting lack of support for specified Domain Name System Key (DNSKEY) algorithms and Delegation Signer (DS) digest algorithms is outside this doc's scope, but the doc does give info on how to do it anyway. There's a sample test tool here: https://github.com/ogud/DNSSEC_ALG_Check 🧪

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

1.3.1. Test Zone Implementation 🎀

In this doc, the test.example.com domain is used to point at DNS records with known DNSSEC properties. For example, badsign-a.test.example.com is used below to refer to a DNS A record whose published signatures are invalid. (They're "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. So when you're doing real-world tests, you can swap test.example.com in this doc for test.dnssec-tools.org 🦋

2. Goals 👑

This doc is meant to show how a Host Validator can detect what a recursive resolver is capable of, and how it can work around any problems that could affect DNSSEC resolution. That lets the Host Validator use the recursive resolver's caching, which is great because it cuts down network traffic and speeds up response times ⭐

A Host Validator has two choices. It can wait until it runs into problems with a recursive resolver, based on the results it gets from real-world queries sent to it. Or it can proactively test for problems (Section 3) to build a workaround list ahead of time (Section 5). Both paths have pros and cons that depend on the application, and this doc doesn't try to say whether proactive tests should or shouldn't be used. Either way, DNSSEC roadblock avoidance techniques ought to be used when needed and when possible 💅

Note: Besides being useful for Host Validators, the same tests can be used by a recursive resolver to check whether its upstream connections are getting in the way of DNSSEC validation 🫶

3. Detecting DNSSEC Non-compliance 🔍

This section outlines the tests a validator should run to check certain features of the network around it. A resolver should perform these tests when it first starts up, but it MAY also perform them when it detects network changes (for example, address changes, network reattachment, or etc.) 🌸

Note: When running these tests against an address, we assume the address is either a unicast address or an anycast [RFC4786] cluster where all servers have identical configuration and connectivity 🧚

Note: When running these tests, we also assume the path is clear of "DNS-interfering" middleboxes, like firewalls, proxies, or forwarders. Having that kind of infrastructure around can easily make a recursive resolver look like it's misbehaving. How to work around that kind of interference is beyond this doc's scope, although the tests defined here may point out when misbehaving middleware is causing the trouble 😤

Note: This document specifies two sets of tests: a comprehensive one and a fast one. The fast one will catch most common problems, so if the fast one passes, the comprehensive one MAY be considered passed as well ⭐

3.1. Determining DNSSEC Support in Recursive Resolvers ✨

Okay so, ideally a Host Validator can borrow the caching that lives in recursive resolvers 💅 This section goes through the tests a recursive resolver MUST pass before it's fully usable as a DNS cache 🫶

Unless stated otherwise, bestie:

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 🦋
the tests MUST NOT have the DNSSEC OK (DO) bit set or use any of the other DNSSEC-related requirements, like Extension Mechanisms for DNS (EDNS0) 🙈

The tests are designed to check for support of one feature at a time, so each one is laser-focused 🔥

3.1.1. Supports UDP Answers

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 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 implementation MAY chose 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

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 🎀

Prerequisite: Supports UDP or 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

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

Prerequisite: Supports EDNS0.

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. Set the DO bit in the outgoing query.

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

Note: This only tests that the resolver 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. 🙈 not the vibe