Getting Nameservers in the New Delegation Protocol
draft-hoffman-deleg-getting-names-06

Network Working Group                                         P. Hoffman
Internet-Draft                                                     ICANN
Intended status: Informational                             22 April 2025
Expires: 24 October 2025

           Getting Nameservers in the New Delegation Protocol
                  draft-hoffman-deleg-getting-names-06

Abstract

   The DELEG Working Group is soon going to be choosing a base protocol
   that describes how resolvers will be able to get a new DNS resource
   record to create a new process for DNS delegation.  After a resolver
   gets this new type of record, it needs to know how to process the
   record in order to get a set of nameservers for a zone.  This
   document lists many of the considerations for that process, including
   many open questions for the DELEG Working Group.  More considerations
   and open questions might be added in later versions of this draft.

   Note that this draft is _not_ intended to become an RFC.  It is being
   published so that the DELEG Working Group has a place to point its
   efforts about how resolvers get nameservers for a zone while it
   continues to work on choosing a base protocol.  The work that results
   from this might be included in the base protocol specification, or in
   a new draft authored by some of the many people who have done earlier
   work in this area.

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 24 October 2025.

Hoffman                  Expires 24 October 2025                [Page 1]
Internet-Draft             Getting Nameservers                April 2025

Copyright Notice

   Copyright (c) 2025 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Assumptions about the Eventual Base Protocol  . . . . . .   3
     1.2.  BCP 14 Language . . . . . . . . . . . . . . . . . . . . .   3
   2.  Getting Nameserver Names for a Zone . . . . . . . . . . . . .   4
     2.1.  How a Resolver Processes the DD Record  . . . . . . . . .   4
   3.  Addresses and Transports  . . . . . . . . . . . . . . . . . .   5
     3.1.  Addresses . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Transports  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Authentication of Secure Transports . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The DELEG Working Group (https://datatracker.ietf.org/group/deleg/
   about/) is choosing a base protocol for "a new DNS signaling
   mechanism that allows parents to return additional DNS delegation
   information about their children".  This document specifies how that
   information will appear in the new resource records from the base
   protocol, and what resolvers that receive those records will do with
   them.

   According to the working group charter, after it has chosen the base
   protocol, it will specify "new DNS authoritative signaling mechanisms
   for alternative DNS transports".  Section 3 of this document gives
   some ideas for what those extensions might include, and how they
   related to the mechanisms in this document.

Hoffman                  Expires 24 October 2025                [Page 2]
Internet-Draft             Getting Nameservers                April 2025

1.1.  Assumptions about the Eventual Base Protocol

   The WG has tentatively made a choice of [I-D.wesplaap-deleg] (called
   "W" here); it is now in the call for adoption of that draft.  After
   the WG adopts W as the base protocol, it will work on fixes and
   clarifications for many topics that came up during the consensus
   process, such as for root zone priming and interactions with DNSSEC.

   W uses the same display and wire format as SVCB [RFC9460] for records
   returned to the resolver in delegation responses.  In SVCB, the first
   field in the RR is called the "SvcPriority", and different values
   cause the resolver to go into "AliasMode" or "ServiceMode".  The
   result of using this field in resolution is a set of "alternative
   endpoints".  The second field is called "TargetName".  The third
   field is optional, and is called "SvcParams"; it has a lot of sub-
   fields, some of which are useful for the DNS delegation use cases.

   In order to not confuse this with specifics that W gives beyond the
   base protocol, the new record type returned in delegation responses
   is called "DD" here.  (Of course, the name can be whatever the WG
   chooses in the eventual base protocol.)  DD has different semantics
   from SVCB because SCVB assumed a base protocol of HTTPS.  W gives
   different names to values for the first field in the RR, and for sub-
   fields in the optional third field.  Other names from W and SVCB are
   renamed here for clarity; the eventual names might be completely
   different.

   The base protocol will allow for later extensions in the third field.
   Those extensions might reuse entries in the IANA SVCB registry
   (https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml), they
   might add new extensions to that registry, or there might be a new
   registry for the DD record.

1.2.  BCP 14 Language

   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.

Hoffman                  Expires 24 October 2025                [Page 3]
Internet-Draft             Getting Nameservers                April 2025

2.  Getting Nameserver Names for a Zone

   The goal of the DELEG Working Group effort is to give resolvers a
   better way create a set of nameservers for a zone when making DNS
   queries to authoritative servers.  In W, when a resolver makes a
   query that get a delegation response, the resolver may get back one
   or more DD records and NS records that it can further process to
   create the set of nameservers for the zone.  This eventual set of
   nameservers can be called the "DD_nameservers"; this is quite
   different from the set of DD records it received.

   In DD, the first field can be thought of as indicating the _action_
   to find names for the DD_nameservers other than the NS records that
   might be at the apex, using the second field as a domain name _where_
   to look.  The first field can be called "DD_action" and the second
   "DD_where".  The third field, which holds metadata about the
   DD_where, can be called "DD_metadata"

2.1.  How a Resolver Processes the DD Record

   W specifies that a DD_action of value 0 means an action like "find
   the DD_nameservers elsewhere based on the value in the DD_where", and
   a value of 1 means something like "the name in DD_where is an entry
   in DD_nameservers".  Thus, when a resolver receives one or more DD
   records with a DD_action of 0, it needs to do more processing.  When
   it receives one or more DD records with a DD_action of 1, it takes
   the DD_where from those records and puts them into the DD_nameservers
   (possibly with additional information from the DD_metadata, such as
   from Section 3).

   What action does a resolver take when it gets a DD_action of 0?  W
   describes actions for finding eventual additions to the
   DD_nameservers.  W follows chains of CNAME, DNAME, and SVCB records,
   with some limits to prevent loops or excessive processing. %% The
   previous sentence might be wrong; it's the best I could determine
   from the draft. %% Does chasing DD_action of 0 need to change the
   query to SVCB, or would "just send the same request, but send it to
   the DD_where" suffice?  That is, why change to SVCB when the resolver
   already knows how to get DD records just by resolution requests?

   Should the resolver follow CNAME and DNAME, or are straight chains
   sufficient?

   Is the addition to the DD_nameservers different if following a
   DD_action of 0 leads to signed vs. unsigned responses?  Asked another
   way, if the DD_nameservers contains some results that were signed and
   some that were unsigned, does the DD_nameservers become an ordered
   list or are the unsigned results discarded?

Hoffman                  Expires 24 October 2025                [Page 4]
Internet-Draft             Getting Nameservers                April 2025

   What is the TTL of the records in DD_nameservers?  A likely answer
   (but not the only posslbe one) is the TTL on the DD record that had a
   DD_action of 1.  If so, this could mean that different delegation
   records in the DD_nameservers for the same zone might have differnt
   TTLs.

   The resolver [[ MAY / SHOULD / SHOULD NOT / MUST / MUST NOT ]] use
   the NS records that were returned with the query to expand the
   DD_nameservers.  (If SHOULD or SHOULD NOT is chosen by the WG, the
   exceptions need to be listed.)

   If there are DD records but the resolver ends up with nothing in the
   DD_nameservers, does it fall back to using the NS records in the
   original query?

   Can the DD RRset contain records with different values for DD_action?
   SVCB says no, but W says yes.

3.  Addresses and Transports

   According to the working group charter, after it has chosen the base
   protocol, it will specify "new DNS authoritative signaling mechanisms
   for alternative DNS transports".  This section has some brief ideas
   about what those might entail and what questions might need to be
   answered.

3.1.  Addresses

   The DD_metadata field in the DD record will have a subfield to
   indicate the IPv4 and IPv6 address(es) associated with the DD_where.
   The subfield can be called "DD_ips".

   Can a DD with a DD_action of 0 have a DD_ips in the record?  In SVCB
   they cannot, but the SVCB spec allows other specs to allow them.

   Is the value for the DD_ips a single address or potentially a list?
   If the former, how are multiple DDs with the same DD_action and
   DD_where combined?

   What happens if some of the discovered name/address pairs have
   different addresses?  Does that disagreement in the DD_nameservers
   cause the removal of something from the DD_nameservers?

3.2.  Transports

   The DD_metadata field in the DD record will have a subfield to
   indicate the transport(s) associated with the DD_where.  The subfield
   can be called "DD_transports".

Hoffman                  Expires 24 October 2025                [Page 5]
Internet-Draft             Getting Nameservers                April 2025

   Can a DD with a DD_action of 0 have a DD_transports in the record?
   In SVCB they cannot, but the SVCB spec allows other specs to allow
   them.

   Some specific DNS transports will be allowed or required with
   DD_transports.  Which secure transport(s), if any, will be mandory to
   implement?

   Does supporting both TLS and QUIC make operational or security sense?

   Does supporting DOH make operational or security sense if other
   secure transport is allowed?

   If either or both TLS and DoH are allowed, which versions of TLS are
   allowed?

   Does Do53 need to be specified every time it is available?

3.3.  Authentication of Secure Transports

   How will clients deal with authenticating TLS?  Should they just use
   the web PKI pile of CAs, or will something else be specified?

   Should certificates with IP addresses be supported?

   Should clients ignore PKIX Extended Key Usage settings?

   Should clients fall back to unauthenticated encrypted transport, all
   the way to Do53, or fail to resolve?

4.  IANA Considerations

   %% There may be IANA considerations when the working group finishes
   this work. %%

5.  Security Considerations

   %% There will certainly be security considerations when the working
   group finishes this work. %%

6.  Normative References

   [I-D.wesplaap-deleg]
              April, T., Špaček, P., Weber, R., and Lawrence,
              "Extensible Delegation for DNS", Work in Progress,
              Internet-Draft, draft-wesplaap-deleg-02, 18 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-wesplaap-
              deleg-02>.

Hoffman                  Expires 24 October 2025                [Page 6]
Internet-Draft             Getting Nameservers                April 2025

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

Author's Address

   Paul Hoffman
   ICANN
   Email: paul.hoffman@icann.org

Hoffman                  Expires 24 October 2025                [Page 7]