dry-run DNSSEC

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 documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents 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 5 September 2022.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

DNSSEC was introduced to provide DNS with data origin authentication and data integrity. This introduced quite an amount of complexity and fragility to the DNS which in turn still hinders general adoption. When an operator decides to publish a newly signed zone there is no way to realistically check that DNS will not break for the zone.¶

This document describes a method called "dry-run DNSSEC" that gives confidence to operators to adopt DNSSEC by introducing a new DS Type Digest Algorithm. Resolvers that don't support the algorithm continue to treat the delegation as insecure [RFC6840], Section 5.2. Validating resolvers are signaled to treat the delegation as being in an intermediate test step for DNSSEC. Valid answers yield authentic data (AD) responses. Therefore, clients that expect the AD flag can already profit from the transition. Invalid answers instead of SERVFAIL yield the response that would have been answered when no dry-run DS would have been present in the parent. For zones that had only dry-run DS RRs in the parent, an invalid answer yields an insecure response. This is of course not proper data integrity but the delegation should not be considered DNSSEC signed at this point.¶

Based on DNS Error Reporting [DNS-ERROR-REPORTING], invalid answers for dry-run DNSSEC errors generate reports in order to monitor potential DNS breakage when changing the DNSSEC configuration for a zone. This is also the main purpose of dry-run DNSSEC.¶

The signed zone is publicly deployed but DNSSEC configuration errors cannot break DNS resolution yet. DNSSEC health feedback can pinpoint potential issues back to the operator. When the operator is confident that the DNSSEC adoption does not introduce DNS breakage, the real DS record can be published on the parent zone and that concludes the actual DNSSEC deployment.¶

Dry-run DNSSEC can further be used on already singed zones to test key rollovers. In this case a dry-run DS record for the future key is used next to the current DS record which itself needs to be also presented in the dry-run format. Validating resolvers that understand dry-run DNSSEC first try to validate with a dry-run DS before falling back to real DSes.¶

For further end-to-end DNS testing, a new EDNS0 option code is introduced that a client can send along with a query to a validating resolver. This signals validating resolvers that the client has opted-in to DNSSEC errors for dry-run delegations. The resolver still uses DNS Error Reporting [DNS-ERROR-REPORTING] for dry-run errors but instead of the insecure answer it provides the client with the SERVFAIL answer, same as with actual DNSSEC. These clients are called "wet-run clients".¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

dry-run DS

The DS record with the special DS type digest algorithm that signals dry-run DNSSEC for the delegation.¶

real DS

The actual DS record for the delegation. Replaces the dry-run DS to complete DNSSEC deployment.¶

dry-run zone

A zone that is DNSSEC signed but uses a dry-run DS to signal the use of the dry-run DNSSEC method.¶

wet-run client

A client that has opted-in to receive the actual DNSSEC errors from the upstream validating resolver instead of the insecure answers.¶

3. Description

TODO¶

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Key Tag             |  Algorithm    |    DRY-RUN    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest Type   |                                               /
+-+-+-+-+-+-+-+-+            Digest                             /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4. Implementation Notes

TODO tldr; validating resolvers need to keep an additional DNSSEC status for cached records that notes the DNSSEC status for the dry-run part. Responses can then be provided based on the Wet-Run DNSSEC EDNS0 option.¶

5. Security Considerations

Dry-run DNSSEC disables one of the fundamental guarantees of DNSSEC, data integrity. Bogus answers for expired/invalid data will become insecure answers providing the potentially wrong information back to the requester. This is a feature of this proposal but it also allows forged answers by third parties to still affect the zone. This should be treated as a warning that dry-run DNSSEC is not an end solution but rather a temporarily intermediate test step of a zone going secure.¶

Parent zones that provide signed delegations to child zones should be aware that by using dry-run DNSSEC (e.g., testing a key roll to a stronger algorithm key) they risk the DNSSEC status of the child zones. If the trust chain becomes invalid between parent and child because of dry-run DNSSEC the child zone will be treated as insecure.¶

6. IANA Considerations

7. Acknowledgements

Martin Hoffmann contributed the idea of using the DS record of an already signed zone also as a dry-run DS in order to facilitate testing key rollovers.¶

Appendix A. Implementation Status

Note to the RFC Editor: please remove this entire section before publication.¶

In the following implementation status descriptions, "dry-run DNSSEC" refers to dry-run DNSSEC as described in this document.¶

• TODO¶

Appendix B. Change History (to be removed before final publication)

• draft-yorgos-dnsop-dry-run-dnssec-00¶

Initial public draft.¶

Authors' Addresses