Recommendations for DNSSEC Resolvers Operators
draft-ietf-dnsop-dnssec-validator-requirements-06

dnsop                                                         D. Migault
Internet-Draft                                                  Ericsson
Intended status: Informational                                  E. Lewis
Expires: 30 December 2023                                          ICANN
                                                                 D. York
                                                        Internet Society
                                                            28 June 2023

             Recommendations for DNSSEC Resolvers Operators
           draft-ietf-dnsop-dnssec-validator-requirements-06

Abstract

   The DNS Security Extensions (DNSSEC) defines a process for validating
   received data and assert them authentic and complete as opposed to
   forged.

   This document provides recommendations for DNSSEC Resolver Operators
   (DRO) to operate a DNSSEC resolver.

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 30 December 2023.

Copyright Notice

   Copyright (c) 2023 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

Migault, et al.         Expires 30 December 2023                [Page 1]
Internet-Draft             DRO Recommendations                 June 2023

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overall View of DNSSEC Validating Resolver  . . . . . . . . .   4
   4.  Time Recommendations  . . . . . . . . . . . . . . . . . . . .   6
   5.  Trust Anchor Related Recommendations  . . . . . . . . . . . .   6
   6.  Negative Trust Anchors Related Recommendations  . . . . . . .   8
   7.  Cached RRset Recommendations  . . . . . . . . . . . . . . . .   9
   8.  Cryptography Deprecation Recommendations  . . . . . . . . . .   9
   9.  Invalid Reporting Recommendations . . . . . . . . . . . . . .  10
   10. Transport Recommendations . . . . . . . . . . . . . . . . . .  10
   11. Secure Transport Recommendations  . . . . . . . . . . . . . .  11
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  12
     13.1.  DNSSEC and TLS Trust Models  . . . . . . . . . . . . . .  13
   14. Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . .  14
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     15.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   A DNS resolver is a service that locates and returns information
   pertaining to a query issued by some other service, such as an
   application.  By its nature, a DNS resolver is inquisitive,
   susceptible to misleading information it may receive.  To address
   this, DNS Security (DNSSEC) extensions [RFC9364] were defined to
   provide authenticity and integrity to responses, as well as to
   provide an authenticated notice for data that does not exist.

   A DNS resolver operator is an organization or individual that runs a
   DNS resolver.  The resolver may be for a small set of relying
   parties, for a large but bounded collection of customers, or it may
   be operated with no restriction on who or what may make use of it.
   To enhance the value of the service, a DNS resolver operator
   implements various security controls, including the use of DNSSEC
   validation.  For the sake of this document, the term DNSSEC Resolver
   Operator (DRO) is defined as the responsible operator of a DNS
   resolver that makes use of DNSSEC validation.

Migault, et al.         Expires 30 December 2023                [Page 2]
Internet-Draft             DRO Recommendations                 June 2023

   Operating DNSSEC validation involves making use of digital signatures
   generated by a DNSSEC signer.  Besides the simple cryptographic
   process of validating digital signatures there are a number of checks
   required due to the nature of the DNS protocol.  A well-written
   DNSSEC validating resolver will faithfully implement the DNSSEC
   processes needed, leaving an operator to manage a few items.

   The items that a DRO needs to attend to are:

   *  Time of day (current, wall-clock time)

   *  Trust anchors (positive and negative)

   *  Monitoring of the service, including abuse

   This document will list recommended actions for DNSSEC validating
   resolver operators that will help achieve the goals of DNSSEC
   validation.  First, the goals ought to be stated.

   The primary goal of any operations endeavor is to provide a service
   within service level agreements intended to make relying parties
   happy with the performance of the service.  For DNSSEC, this breaks
   into two parts, one of accurately achieving the protections offered
   by DNSSEC, the other, to avoid DNSSEC from accidentally being an
   impediment.

   The recommendations will focus on preparation of the elements of a
   DNSSEC validating resolver, as described earlier in the diagram.  In
   particular, there are recommendations related to service monitoring,
   time source, Trust Anchor Manager/Store, and DNS Resolver.  The
   recommendations are categorized as at initialization, during runtime,
   and upon demand.

2.  Terminology

   This document uses the following terminology:

   DNSSEC validator:  the entity that performs DNS resolution and
      performs signature validation.

   Accurate validation:  validation that avoids false positives and
      catches true negatives.

   Trust Anchor Data Store:  a module (of code) implementing functions
      related to the trust anchors used by the validator.  This is
      essentially a database allowing access, monitoring of, and changes
      to trust anchors.

Migault, et al.         Expires 30 December 2023                [Page 3]
Internet-Draft             DRO Recommendations                 June 2023

   DNSSEC Resolver Operator (DRO):  The operator or anyone providing
      DNSSEC validation service and managing DNSSEC Validators.

3.  Overall View of DNSSEC Validating Resolver

   To help orient this document, the following schematic is offered to
   show some of the interrelationships among the elements of a DNSSEC
   validating resolver.  This drawing is merely a cartoon summary, not
   an implementation guide.

     +--------------+  +------------+ +---------------+ +--------------+
     |              |  |            | |               | |              |
     |   Service    |  |    Time    | | Cryptographic | | Trust Anchor |
     |   Monitoring |  |    Source  | |   Libraries   | | Manager/Store|
     |              |  |            | |               | |              |
     +--------------+  +------------+ +---------------+ +--------------+
             |                |               |              ^    ^
             v                v               v              |    |
     +--------------+  +------------------------------+      |    |
     |              |  |                              |      |    |
     |              |  |                              |      |    |
   ->| DNS Resolver |->|   DNSSEC Validation Engine   |<-----+    |
   -<|              |<-|                              |           |
     |              |  |                              |           |
     +--------------+  +------------------------------+           |
             ^               ^ |             ^                    |
             |               | v             |                    |
             |         +------------+ +---------------+           |
             |         |            | |               |           |
             +---------| DNS Caches | | DNS Messages  |<----------+
                       |            | |               |
                       +------------+ +---------------+

              Figure 1: DNSSEC Validating Resolver Description

   Across the top row are elements that an operator needs to address to
   properly run a DNSSEC Validating Resolver.

   Service Monitoring:  Enforces acceptable use policy and enables
      management of the service This is a generic module for all
      services, here featuring some DNS and DNSSEC specific concerns.

   Time Source:  Provides the wall clock or absolute, time DNS has
      always used relative time to manage the TTL of resource record
      sets in caches, DNSSEC introduced the need for absolute time to
      thwart replay attacks and to manage the lifetime of signatures.

   Cryptographic Libraries:  Software library or a Hardware Security

Migault, et al.         Expires 30 December 2023                [Page 4]
Internet-Draft             DRO Recommendations                 June 2023

      Module (HSM) implementing cryptography providing Due to the nature
      of cryptography, the implementation of this module may evolve over
      time or at least be subject to technical refresh.

   Trust Anchor Manager/Store:  The database of trust anchors used as
      the basis from which DNSSEC operates This module contains the
      foundation upon which DNSSEC evaluates received data sets.  The
      contents of this module are essential for proper operation.  For a
      general-purpose validator running on a public Internet, it may
      have a single entry, for the very top of the DNS name space (the
      root).  Management of this may be left to automated processes that
      are carefully designed to address vulnerabilities related to
      automated trust management.  For specific situations, the Trust
      Anchor Manager/Store will also manage local-policy supporting
      trust anchors as well.  Careful operation of this module is
      crucial to the value of the DNSSEC validating resolver.

   The other modules fill out the diagram to give the above context:

   DNS Resolver:  The service interface offered to other
      services/applications/users This is the generic DNS resolution
      service, consulting the cache for hits, and seeking new answers
      for misses.

   DNSSEC Validation Engine:  This implements the DNSSEC validation
      process The validation engine is assumed to faithfully implement
      the DNSSEC validation algorithm, relying on the information from
      the Time Source, Cryptographic Libraries, Trust Anchor Management/
      Store as well as what is held in the local cache or gained through
      messages.

   DNS Caches:  Include positive and negative caches.  These are the
      ordinary caches used in DNS operations, including DNSSEC extended
      record types and management.

   DNS Messages:  Existing DNS message passing This covers the proper
      implementation and operation of DNS and DNSSEC message exchanges.

   Note that there may be other elements involved in a DNSSEC validating
   resolver.

Migault, et al.         Expires 30 December 2023                [Page 5]
Internet-Draft             DRO Recommendations                 June 2023

4.  Time Recommendations

   As DNSSEC uses wall-clock time to temporally limit the validity of
   RRSIG resource records, a DNSSEC validator needs a reliable time
   source.  If a validator can be fooled into believing that the time is
   a point well into the past, an incorrect RRSIG resource record may be
   replayed and used, or an old key whose private component has since
   been exposed may be able to forge a falsified answer.

   The range of these recommendations include devices that do not have
   an embedded Real Time Clock.  Such devices need to have their system
   clocks updated upon power up before starting the DNSSEC validator.

   At initialization: a DNSSEC validator needs to be able to establish
   reliable time without relying on DNSSEC validation.  The latter
   clause is needed as the initialization step is being carried out to
   start DNSSEC validation, it is not assumed to be up and running at
   this point.  One way to interpret this is that a time source (Network
   Time Protocol) ought to be identified by a numerical IP address and
   not a fully qualified domain name (which would require a DNS lookup).

   During runtime: a DNSSEC validator operator ought to have controls in
   place to monitor the current time of a validator as well as monitor
   the number of validation failures that can be attributed to temporal
   violations.  Updates to the current time ought to make use of secure
   environments, whether secure channels for NTP or as appropriate for
   the installation.  Updates ought to be part of an automated process,
   running at appropriately frequent intervals.

   Upon demand: a DNSSEC validator operator ought to be able to perform
   any of the runtime actions upon demand, for instance, to help
   diagnose a service failure.

5.  Trust Anchor Related Recommendations

   The TA store implements a trust model.  The default trust model
   consists in trusting a single TA which is the KSK of the root zone.

Migault, et al.         Expires 30 December 2023                [Page 6]
Internet-Draft             DRO Recommendations                 June 2023

   While not generally recommended, a DRO may consider alternative TAs,
   for example, when the secure delegation to these RRsets may not be
   validated for any reasons.  The trust model should at least ensure
   that any domain name in the DNS be covered by at least one TA.  As
   the number of top level domains is evolving overtime, it remains safe
   to keep the root zone as a security entry point in order to cover the
   full domain name space.  Upon considering TA, the DRO should
   carefully ensure that the TA meets all necessary operational
   criterias.  This includes for example, having a bootstrapping
   mechanism, or having their signers committed to respect the [RFC5011]
   timing - at least when the DRO relies on automatic updates (see
   below).

   TAs are usually represented by a DNSKEY or DS RRset and are involved
   in the signature validation process to determine whether the
   validation is successful or not.

   At initialization: The DRO needs to ensure the resolver can only be
   started with a TA store that matches the trust model and that is up-
   to-date.  The DRO needs to securely retrieve and check the TA upon
   starting the resolver.  For the default trust model, for example,
   [UNBOUND-ANCHOR] or [ta-fetcher] implements [RFC7958] and ensures the
   resolver is configured with the up-to-date TA of the root zone.
   Similarly, the up-to-date default trust model is very commonly
   implemented by the software release in which case the DRO may simply
   rely on software update.

   During runtime: The DRO needs to ensure the TA is up-to-date.  This
   is achieved by enabling TA to be updated automatically as well as
   being able to check the status of the TA.  TA updates are not
   expected to be handled manually as this introduces a potentially huge
   vector for configuration errors as well as potential misunderstanding
   of ongoing operations.  Instead, the DRO should rely on automated
   procedures such as, for example, Automated Updates to DNSSEC Trust
   Anchors" [RFC5011] [I-D.ietf-dnsop-rfc5011-security-considerations]
   or software updates.  As [RFC5011] is an in-band mechanism, the DRO
   is expected to understand these risks [RFC5011], Section 8.  Software
   update or other mechanisms may also be used.

   Upon demand: The DRO should be able to check the status of the TA
   within its resolvers on a regular basis or when it is aware a TA roll
   over is ongoing.  This includes the TA stored in the running resolver
   as well as potential configuration files.  The TA used by the
   resolver is expected to be retrieved using "Signaling Trust Anchor
   Knowledge in DNS Security Extensions (DNSSEC)" [RFC8145], and may re-
   use similar software as those used at the initialisation to retrieve
   and check the expected value of the TA.  The TA health check should
   associate a status to the TA - as defined in Section 3 of [RFC7583] -

Migault, et al.         Expires 30 December 2023                [Page 7]
Internet-Draft             DRO Recommendations                 June 2023

   to ease the TA monitoring and potential analysis.  When an unexpected
   (old) TA is found, the health check should evaluate if the mismatch
   resulted from an ongoing normal roll over, a potential emergency key
   roll over, failed roll over or any other envisioned cases.  In any
   case restarting the resolver is expected to address any situation
   that cannot be addressed otherwise, which reinforces the
   recommendation to rely on TA bootstrapping mechanisms.

   Note also that [RFC8145] also enables any authoritative server to
   check how the TA roll over is performed.  Such cooperation is
   expected to be useful and benefit the overall operation of the DNS
   system.

6.  Negative Trust Anchors Related Recommendations

   When the DNSSEC Resolver is not able to validate signatures because a
   key or DS has been published with an error, the DRO may temporarily
   disable the signature check for that key until the time the error is
   addressed.  Negative Trust Anchor (NTA) represents the only permitted
   intervention in the resolving process for a DRO.

   The designation of NTA might be misleading, but NTA is not expected
   to be part of the trust model even though the NTA belongs to the TA
   store.

   At initialization: Similarly to TA, the DRO is expected to
   automatically configure the resolver with the NTA.

   Upon demand: the DRO is expected to automatically determine the used
   NTA and handle NTA as described in [RFC7646].

   A signature validation failure is either an attack or a failure in
   the signing operation on the authoritative servers.  The DRO is
   expected to confirm this offline before introducing the NTA.  This is
   likely to happen via a human confirmation which is based on
   information collected during running time.

   At running time: The DRO should monitor the number of signature
   failures associated with each DNSKEY.  These numbers are only hints
   and must not trigger automated insertion of NTA.

Migault, et al.         Expires 30 December 2023                [Page 8]
Internet-Draft             DRO Recommendations                 June 2023

7.  Cached RRset Recommendations

   During runtime: A DRO is not expected to perform any operations over
   the cached RRSet.  A common concern DRO has is the consistency
   between the cached RRset with those published by the DNS system.  DRO
   should not implement or deploy any non standard mechanism.
   [I-D.ietf-dnsop-ns-revalidation] is one of these mechanisms, for
   example.  Section 8.1 of [RFC4033] also mentions the ability by the
   resolver to set the upper bound of the TTL to the remaining signature
   validity period.  This value has usually a default value set by the
   resolver and the DRO may change that default value.

   Upon demand: a DRO may have been informed that a rogue or unwilling
   DNSKEY has been published.  In such a situation, the DRO should be
   able to remove the RRsets validated by the rogue DNSKEY - which may
   be done by flushing the full cache.

8.  Cryptography Deprecation Recommendations

   As mentioned in [RFC8247] and [RFC8221] cryptography used one day is
   expected over time to be replaced by new and more robust
   cryptographic mechanisms.  In the case of DNSSEC signature protocols
   are likely to be updated over time.  In order to anticipate the
   sunset of one of the signature schemes, a DNSSEC validator may be
   willing to estimate the impact of deprecating one signature scheme.

   Currently, interoperability and security are enforced via
   cryptographic recommendations [RFC8624] that are followed by both
   resolvers and authoritative servers.  The implementation of such
   guidance is ensured by the software vendors and the compliance of
   their releases.

   At initialization: The DRO is expected to ensure recent software
   releases are used and that this release complies with the most recent
   cryptographic guidelines.

   During runtime: a DRO may regularly request and monitor the signature
   scheme supported by an authoritative server.  In addition, when a
   validation fails because a deprecated algorithm is used, the DRO
   should return an "Unsupported DNSKEY Algorithm" as defined in
   [RFC8914] to the DNS client.

   Note that one inconvenience to such a strategy is that it does not
   let one DRO take advantage of more recent cryptographic algorithms.
   While currently not being widely used, a DRO may announce an
   authoritative server the supported signature schemes to the
   authoritative server [RFC6975] in the hope that future deployment of
   authoritative servers will be able to leverage it.

Migault, et al.         Expires 30 December 2023                [Page 9]
Internet-Draft             DRO Recommendations                 June 2023

9.  Invalid Reporting Recommendations

   A DNSSEC validator receiving a DNS response cannot make the
   difference between receiving an non-secure response versus an attack.
   Dropping DNSSEC fields by misconfigured middle boxes, such as DS,
   RRRSIG is considered as an attack.  A DNSSEC validator is expected to
   perform secure DNS resolution and as such protects its stub client.
   An invalid response may be the result of an attack or a
   misconfiguration, and the DRO may play an important role in sharing
   this information with the authoritative server or domain name owner.

   At runtime: a DRO should monitor and report DNSSEC validation errors
   and inform the DNS client with "Extended DNS Errors" [RFC8914].

10.  Transport Recommendations

   DNSSEC validation requires that the validator is able to reliably
   obtain necessary records, especially DNSKEY records.  This should be
   done at initial configuration, and tested periodically.

   This means the validator must ensure it is configured so that the UDP
   and TCP transports, and DNS resolver components, are compatible with
   the network paths that the majority of DNS queries traverse - which
   includes compatibility between DNS and transport parameters with the
   Maximum Transmission Unit (MTU).

   In other words, make sure that:

   1.  DNS UDP bufsize (EDNS parameter) is set to a value compatible
       with network MTUs the queries and responses will encounter.  If
       the validator advertises a bufsize >> MTU, responses with the
       IPv4 Don't Fragment (DF) bit set whose size R where MTU < R <=
       bufsize exceeds the MTU will be dropped by the router with MTU <
       R.

   2.  The validator's OS TCP configuration has its advertised Maximum
       Segment Size (MSS) set to a value compatible with network MTUs
       the queries and responses will encounter.

   *  Having an advertised MSS set to a value < MTU ensures that Path
      MTU Discovery is not required

   *  If PMTUD fails for any reason, or if the server responding does
      not maintain or use PMTUD, and advertised MSS > MTU at any point
      in the path, TCP may encounter problems caused by IP fragmentation
      and reassembly.

Migault, et al.         Expires 30 December 2023               [Page 10]
Internet-Draft             DRO Recommendations                 June 2023

   *  This is particularly relevant if there are any NAT type devices in
      the path, as those may not properly handle fragmentation and
      reassembly

   *  If all TCP segments are smaller than the path MTU, TCP will work
      reliably.

   The avoidance of fragmentation in order to address known
   fragmentation-related security issues with DNS (leading to cache
   poisoning, for example) has resulted in the need to set the DF bit on
   UDP.  Validators will need to ensure their local environment can
   reliably get any critical DNSSEC records (notably DNSKEY) over UDP,
   or reliably get responses with TC=1 if overly large responses cannot
   be sent over UDP due to answers not fitting within the advertised
   bufsize payload.  Validators also need to ensure TCP works if it is
   needed, for the same situations.

11.  Secure Transport Recommendations

   A DRO should consider secure transport as a complementary element of
   its trust model.  Such resolvers are usually designated as encrypted
   resolvers and their presence is usually discovered by the DNS client
   via a discovery mechanisms.  That discovery mechanism may require the
   resolver to respond to specific DNS requests.

   In many cases, a DRO enables DNSSEC to ensure the cached RRset have
   not been modified on-path and corresponds to those published by the
   owner of the zone.  To ensure RRsets are protected against on-path
   modification from the resolver to the DNS client, the DRO may enable
   a secure transport such as DNS over TLS (DoT) [RFC7858], DNS over
   HTTPS [RFC8484] (DoH) or DNS over QUIC (DoQ) [RFC9250].  The TLS
   termination may be supported by the running resolver software or via
   a TLS front end and TLS should follow its own TLS recommendations
   [RFC9325].

   A DRO should consider how the DNS client will discover the encrypted
   resolver.  A DNS client may be provisioned with all the necessary
   parameters via specific mechanisms such as DHCP and Router
   Advertisement Options for the Discovery of Network-designated
   Resolvers [I-D.ietf-add-dnr] or 3GPP TS 24.008 mechanisms.
   Alternatively, a DNS client configured with an unencrypted resolver
   may discover the encrypted resolvers operated by the same entity as
   the unencrypted resolver using the Discovery of Designated Resolvers
   (DDR) [I-D.ietf-add-ddr].  The relation between the unencrypted
   resolver and the encrypted resolvers is indicated during the TLS key
   exchange via a certificate that contains a subjectAltName extension
   with the IP address of the unencrypted resolver.  To ease the (even
   future) deployment of DDR, it is recommended that a DRO uses a global

Migault, et al.         Expires 30 December 2023               [Page 11]
Internet-Draft             DRO Recommendations                 June 2023

   IP address for its unencrypted resolver.  When the DRO deploys
   encrypted resolvers, it is recommended that the DRO enables DNS
   clients to discover the encrypted resolvers using DDR and use a
   certificate authority that belongs to the Web PKI.

12.  IANA Considerations

   There is no IANA consideration for this document.

13.  Security Considerations

   Security consideration of DNSSEC operations are described in
   [RFC6781].  However, most DNSSEC operations are performed by the
   owner of the zone as opposed to the DRO.  In addition, DRO are
   largely relying on the software vendor as well as automated procedure
   as to limit potential intervention from the DRO.  This section
   emphases on DRO related security considerations.

   Regarding time inaccuracy, a RRSIG is only valid between the
   inception and expiration time.  As a result, when the time is outside
   this period validation is disabled, and this could be used by an
   attacker to disable validation for example to poison the cache.

   Trust anchors are the root of the trust in DNSSEC and potentially, an
   attacker being able to provide a rogue trust anchor is potentially
   able to hijack any RRset below that Trust Anchor.  On the other hand,
   mishandling Trust Anchor is likely resulting in a validator unable to
   validate most of the traffic under the TA.  The use by a DRO of a
   common trust model shared by many DRO and implemented by multiple
   vendors reduces these risks.

   Negative trust anchors by definition disable validation, and as such
   must be handled very cautiously by the DRO.  This could be used by an
   attacker, for example, to disable validation and poison the resolver.

   Using weak cryptography reduces the strength in the trust implemented
   by DNSSEC as it relied on cryptographic signatures.  A weak
   cryptographic algorithm may be used by an attacker to forge a
   signature.  It is probably something the DRO may observe as use as an
   indicator, but there is little action the DRO can actually do, as the
   cryptographic algorithms to be used are defined by the owner of the
   zone or the RRSet.

   The DRO is operating one part of the DNS system.  While a DRO
   operates independently, it is believed that communication between the
   different actors involved in the DNS system will enhance the global
   resiliency of the system.  As a result, this document encourages the
   DRO to provides some information to the stub client when a signature

Migault, et al.         Expires 30 December 2023               [Page 12]
Internet-Draft             DRO Recommendations                 June 2023

   validation fails.  It also encourages the DRO to authorize third
   parties to request what trust anchor or more generally DNSKEY are
   being used, so concerned party may be able to contact the DRO if
   needed.  This is expected, for example when a authoritative server is
   performing a key roll over to check the update has been performed
   properly before removing the old key.  The same considerations for
   communications also holds between DRO as well as with software
   vendors.

   As the software used for the DNSSEC validator is not immune to bugs
   [ENT] and may become vulnerable independently of how it is operated,
   it is recommended a DRO relies on different vendors.

13.1.  DNSSEC and TLS Trust Models

   While the document is essentially focused on the security implemented
   by DNSSEC, it also mentions the combination of TLS and DNSSEC.
   DNSSEC is essentially a protocol focused on authenticating the DNS
   data, but is not addressing confidentiality of the data nor the
   privacy of the user requesting that data.  TLS provides
   authentication and confidentiality of a communication.

   As a result, TLS is necessary wherever privacy is needed.  In the
   current model a DNS client is using TLS to protect the communication
   with the resolver.  If that resolver is trusted and believed to host
   trustworthy RRsets - that is unmodified RRsets validated by the
   DNSSEC - the TLS communication enables the DNS client to trust the
   RRSets without performing a DNSSEC validation.  If that resolver is
   expected to perform some operations agreed by the DNS client that may
   change the RRsets, DNSSEC cannot be performed by the DNS client and
   TLS is used to carried these trusted RRsets to the DNS client.
   On the other hand, if the DNS client does not fully trust the
   resolver, than the DNS client must authenticate the received RRsets
   with DNSSEC.  In that case, TLS is only providing privacy protection.

   The trust in a DNS resolver depends on multiple factors, but one
   significant concern is the ability of the DRO to perform a man in the
   middle attack and change on the fly the RRsets without the stub
   client being aware of it.  Confidential computing
   [I-D.arkko-dns-confidential] may be one way to address such attacks.
   Another concern, related to privacy, is the ability of a resolver to
   track a certain user and log every sites requested by the user.
   Confidential Computing [I-D.arkko-dns-confidential] or oblivious DNS
   [RFC9230] are means to address such issues.

   A model where TLS would be used to protect the transactions between
   the DNS client and the authoritative server is unlikely in a near
   future for scalability reasons.  A compromise to this model may

Migault, et al.         Expires 30 December 2023               [Page 13]
Internet-Draft             DRO Recommendations                 June 2023

   consists in having the TLS communications between the resolvers and
   the authoritative servers.  In such scenario, the privacy requirement
   might be questionable as the resolver aggregates the traffic of
   multiple DNS clients which may be considered to provide sufficient
   privacy.  However, a model involving a communication composed of
   multiple TLS segments is only trusted if all involved nodes are
   trusted (DNS client, resolver, authoritative server).  In practice,
   it is unlikely to have all these intermediary nodes trusted, in which
   case trust will rely on DNSSEC.

14.  Acknowledgment

   The need to address DNSSEC issues on the resolver occurred during
   multiple discussions including among others Ted Lemon, Ralph Weber,
   Normen Kowalewski, Mikael Abrahamsson, Jim Gettys, Paul Wouters, Joe
   Abley, Michael Richardson, Vladimír Čunát, James Gannon, Andrew
   McConachie, Peter Thomassen, Florian Obser, Brian Dickson and
   Christian Huitema.

   We also appreciated the support of the DNSOP chairs Tim Wicinski,
   Suzanne Woolf and Benno Overeinder.

15.  References

15.1.  Normative References

   [I-D.ietf-add-ddr]
              Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
              Jensen, "Discovery of Designated Resolvers", Work in
              Progress, Internet-Draft, draft-ietf-add-ddr-10, 5 August
              2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
              add-ddr-10>.

   [I-D.ietf-add-dnr]
              Boucadair, M., Reddy.K, T., Wing, D., Cook, N., and T.
              Jensen, "DHCP and Router Advertisement Options for the
              Discovery of Network-designated Resolvers (DNR)", Work in
              Progress, Internet-Draft, draft-ietf-add-dnr-16, 27 April
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              add-dnr-16>.

   [I-D.ietf-dnsop-ns-revalidation]
              Huque, S., Vixie, P. A., and R. Dolmans, "Delegation
              Revalidation by DNS Resolvers", Work in Progress,
              Internet-Draft, draft-ietf-dnsop-ns-revalidation-04, 13
              March 2023, <https://datatracker.ietf.org/doc/html/draft-
              ietf-dnsop-ns-revalidation-04>.

Migault, et al.         Expires 30 December 2023               [Page 14]
Internet-Draft             DRO Recommendations                 June 2023

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
              Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
              September 2007, <https://www.rfc-editor.org/info/rfc5011>.

   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781,
              DOI 10.17487/RFC6781, December 2012,
              <https://www.rfc-editor.org/info/rfc6781>.

   [RFC7583]  Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
              "DNSSEC Key Rollover Timing Considerations", RFC 7583,
              DOI 10.17487/RFC7583, October 2015,
              <https://www.rfc-editor.org/info/rfc7583>.

   [RFC7646]  Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
              and R. Weber, "Definition and Use of DNSSEC Negative Trust
              Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
              <https://www.rfc-editor.org/info/rfc7646>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8145]  Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
              Anchor Knowledge in DNS Security Extensions (DNSSEC)",
              RFC 8145, DOI 10.17487/RFC8145, April 2017,
              <https://www.rfc-editor.org/info/rfc8145>.

   [RFC8221]  Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
              Kivinen, "Cryptographic Algorithm Implementation
              Requirements and Usage Guidance for Encapsulating Security
              Payload (ESP) and Authentication Header (AH)", RFC 8221,
              DOI 10.17487/RFC8221, October 2017,
              <https://www.rfc-editor.org/info/rfc8221>.

   [RFC8247]  Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
              "Algorithm Implementation Requirements and Usage Guidance
              for the Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 8247, DOI 10.17487/RFC8247, September 2017,
              <https://www.rfc-editor.org/info/rfc8247>.

Migault, et al.         Expires 30 December 2023               [Page 15]
Internet-Draft             DRO Recommendations                 June 2023

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

   [RFC8624]  Wouters, P. and O. Sury, "Algorithm Implementation
              Requirements and Usage Guidance for DNSSEC", RFC 8624,
              DOI 10.17487/RFC8624, June 2019,
              <https://www.rfc-editor.org/info/rfc8624>.

   [RFC8914]  Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
              Lawrence, "Extended DNS Errors", RFC 8914,
              DOI 10.17487/RFC8914, October 2020,
              <https://www.rfc-editor.org/info/rfc8914>.

   [RFC9250]  Huitema, C., Dickinson, S., and A. Mankin, "DNS over
              Dedicated QUIC Connections", RFC 9250,
              DOI 10.17487/RFC9250, May 2022,
              <https://www.rfc-editor.org/info/rfc9250>.

   [RFC9325]  Sheffer, Y., Saint-Andre, P., and T. Fossati,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
              2022, <https://www.rfc-editor.org/info/rfc9325>.

   [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
              RFC 9364, DOI 10.17487/RFC9364, February 2023,
              <https://www.rfc-editor.org/info/rfc9364>.

15.2.  Informative References

   [ENT]      Levigneron, V., "ENT was here !!!", n.d.,
              <https://indico.dns-
              oarc.net/event/25/contributions/403/attachments/378/647/
              AFNIC_OARC_Dallas.pdf>.

   [I-D.arkko-dns-confidential]
              Arkko, J. and J. Novotny, "Privacy Improvements for DNS
              Resolution with Confidential Computing", Work in Progress,
              Internet-Draft, draft-arkko-dns-confidential-02, 2 July
              2021, <https://datatracker.ietf.org/doc/html/draft-arkko-
              dns-confidential-02>.

Migault, et al.         Expires 30 December 2023               [Page 16]
Internet-Draft             DRO Recommendations                 June 2023

   [I-D.ietf-dnsop-rfc5011-security-considerations]
              Hardaker, W. and W. A. Kumari, "Security Considerations
              for RFC5011 Publishers", Work in Progress, Internet-Draft,
              draft-ietf-dnsop-rfc5011-security-considerations-13, 16
              July 2018, <https://datatracker.ietf.org/doc/html/draft-
              ietf-dnsop-rfc5011-security-considerations-13>.

   [RFC6975]  Crocker, S. and S. Rose, "Signaling Cryptographic
              Algorithm Understanding in DNS Security Extensions
              (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,
              <https://www.rfc-editor.org/info/rfc6975>.

   [RFC7958]  Abley, J., Schlyter, J., Bailey, G., and P. Hoffman,
              "DNSSEC Trust Anchor Publication for the Root Zone",
              RFC 7958, DOI 10.17487/RFC7958, August 2016,
              <https://www.rfc-editor.org/info/rfc7958>.

   [RFC9230]  Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
              Wood, "Oblivious DNS over HTTPS", RFC 9230,
              DOI 10.17487/RFC9230, June 2022,
              <https://www.rfc-editor.org/info/rfc9230>.

   [ta-fetcher]
              Davies, J. S. and K., "DNSSEC Trust Anchor Fetcher", n.d.,
              <https://github.com/iana-org/get-trust-anchor>.

   [UNBOUND-ANCHOR]
              "unbound-anchor - Unbound anchor utility", n.d.,
              <https://nlnetlabs.nl/documentation/unbound/unbound-
              anchor/>.

Authors' Addresses

   Daniel Migault
   Ericsson
   8275 Trans Canada Route
   Saint Laurent, QC  4S 0B6
   Canada
   Email: daniel.migault@ericsson.com

   Edward Lewis
   ICANN
   United States of America
   Email: edward.lewis@icann.org

Migault, et al.         Expires 30 December 2023               [Page 17]
Internet-Draft             DRO Recommendations                 June 2023

   Dan York
   Internet Society
   United States of America
   Email: york@isoc.org

Migault, et al.         Expires 30 December 2023               [Page 18]