[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

dnsop                                                           T. April
Internet-Draft                                       Akamai Technologies
Intended status: Informational                              13 July 2020
Expires: 14 January 2021


         Parameterized Nameserver Delegation with NS2 and NS2T
                          draft-tapril-ns2-01

Abstract

   Within the DNS, there is no mechanism for authoritative servers to
   advertise which transport methods they are capable of.  If secure
   transport methods are adopted by authoritative operators, transport
   signaling would be required to negotiate how authoritative servers
   would be contacted by resolvers.  This document provides two new
   Resource Record Types, NS2 and NS2T, to facilitate this negotiation
   by allowing zone owners to signal how the authoritative nameserver(s)
   for their zone(s) may accept queries.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/timapril/ns2 (https://github.com/timapril/ns2).

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 14 January 2021.

Copyright Notice

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



April                    Expires 14 January 2021                [Page 1]


Internet-Draft                     NS2                         July 2020


   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 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
     1.1.  Introductory Examples . . . . . . . . . . . . . . . . . .   3
     1.2.  Goal of the NS2 and NS2T Records  . . . . . . . . . . . .   4
     1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  NS2 and NS2T Record Types . . . . . . . . . . . . . . . . . .   5
     2.1.  Difference between the records  . . . . . . . . . . . . .   5
     2.2.  AliasForm Record Type . . . . . . . . . . . . . . . . . .   6
       2.2.1.  Multiple Service Providers  . . . . . . . . . . . . .   6
       2.2.2.  Loop Prevention . . . . . . . . . . . . . . . . . . .   7
     2.3.  ServiceForm Record Type . . . . . . . . . . . . . . . . .   7
       2.3.1.  SvcFieldPriority  . . . . . . . . . . . . . . . . . .   7
       2.3.2.  SvcDomainName . . . . . . . . . . . . . . . . . . . .   7
       2.3.3.  SvcParamKeys  . . . . . . . . . . . . . . . . . . . .   8
     2.4.  Deployment Considerations . . . . . . . . . . . . . . . .  10
       2.4.1.  AliasForm and ServiceForm in the Parent . . . . . . .  10
       2.4.2.  Rollout . . . . . . . . . . . . . . . . . . . . . . .  11
       2.4.3.  Availability  . . . . . . . . . . . . . . . . . . . .  11
       2.4.4.  Multiple ServiceForm records for the same host or IP
               address . . . . . . . . . . . . . . . . . . . . . . .  11
   3.  Responses with NS2  . . . . . . . . . . . . . . . . . . . . .  12
     3.1.  Response Size Considerations  . . . . . . . . . . . . . .  12
     3.2.  When to include glue  . . . . . . . . . . . . . . . . . .  13
   4.  DNSSEC and NS2  . . . . . . . . . . . . . . . . . . . . . . .  13
   5.  Privact Considerations  . . . . . . . . . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     6.1.  Availability of zones without NS  . . . . . . . . . . . .  13
     6.2.  Reflection Attacks  . . . . . . . . . . . . . . . . . . .  13
     6.3.  Parsing . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.4.  Availability  . . . . . . . . . . . . . . . . . . . . . .  14
     6.5.  Connetion Failures  . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  New registry for NS2 transports . . . . . . . . . . . . .  14
       7.1.1.  Procedure . . . . . . . . . . . . . . . . . . . . . .  14
       7.1.2.  Initial Contents  . . . . . . . . . . . . . . . . . .  14
     7.2.  New SvcParamKey Values  . . . . . . . . . . . . . . . . .  15
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  16
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  17



April                    Expires 14 January 2021                [Page 2]


Internet-Draft                     NS2                         July 2020


   Appendix B.  TODO . . . . . . . . . . . . . . . . . . . . . . . .  17
   Appendix C.  Change Log . . . . . . . . . . . . . . . . . . . . .  18
   Appendix D.  Discussions  . . . . . . . . . . . . . . . . . . . .  19
     D.1.  Port Numbers  . . . . . . . . . . . . . . . . . . . . . .  19
     D.2.  CNS2  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
     D.3.  Second Record Name  . . . . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   Resolvers currently rely on the NS records in the parent and child
   zones to provide and confirm the nameservers that are authoritative
   for each zone.  The Nameserver version 2 (NS2) record extends the
   functionality of the NS record to include additional information
   about how authoritative zone information can be queried, whether that
   be over alternate protocols or by using alternate protocol
   parameters.  The NS2 record may be present at zone cuts but can also
   redirect resolvers to other nameservers for further redirection via
   the Nameserver Version 2 Target (NS2T) record, which does not
   indicate a zone cut.

   The NS2 and NS2T records uses the SVCB record format defined in
   [I-D.draft-ietf-dnsop-svcb-https-00], using a subset of the already
   defined service parameters as well as new parameters described in
   this document.  Some, but not all, of the existing service parameters
   will also be available for NS2 and NS2T records.  This document will
   outline the available parameters and their usage.

1.1.  Introductory Examples

   To introduce the NS2 and NS2T records, this example shows a possible
   response from an authoritative in the authority section of the DNS
   response when delegating to another nameserver.

   example.com.  86400  IN NS2    2 ns2.example.com. ( transports=dot,
                   dnsTlsFingerprints=["MIIS987SSLKJ...123===",
                       "MII3SODKSLKJ...456==="] )
   example.com.  86400  IN NS2    3 ns3.example.com. ( transports=doh,
                   dnsDohURITemplate="https://ns.example.net/q/{?dns}" )
   example.com.  86400  IN NS     ns1.example.com.
   ns1.example.com.    86400   IN  NS  192.0.2.1
   ns2.example.com.    86400   IN  NS  192.0.2.2
   ns3.example.com.    86400   IN  NS  192.0.2.3








April                    Expires 14 January 2021                [Page 3]


Internet-Draft                     NS2                         July 2020


   In this example, the authoritative nameserver is delegating to both a
   DNS-over-TLS and DNS-over-HTTPS service running on ns2.example.net
   and ns3.example.com respectively, for resolvers that support NS2, and
   also delegating to ns1.example.com which will serve unencrypted DNS
   over port 53 for those that do not.

   Like in SVCB, NS2 and NS2T also offer the ability to use the Alias
   form delegation.  The example below shows an example where
   example.com is being delegated with a NS2 AliasForm record which can
   then be further resolved to locate the authroitative nameserver(s).

   example.com.  86400  IN NS2 0   ns2.example.net.
   example.com.  86400  IN NS     ns1.example.com.
   ns1.example.com.    86400   IN  NS  192.0.2.1

   The example.net authoritative server may return the following NS2T
   records in response to a query as deirected by the above records.

   ns2.example.net 3600    IN NS2T ns2.example.org. ( transports=dot,
                   dnsTlsFingerprints=["MIIS987SSLKJ...123==="] )
   ns2.example.net 3600    IN NS2T ns3.example.org. ( transports=doh,
                   ddnsDohURITemplate="https://ns.example.net/q/{?dns}")

   The avbove records indicate to the client that the authoritative
   nameservers for zones that Alias to ns2.example.net are
   ns1.example.org and ns2.example.rg with the configuration provided.

   Later sections of this document will go into more detail on the
   resolution process using these records.

1.2.  Goal of the NS2 and NS2T Records

   The primary goal of the NS2 and NS2T records is to provide zone
   owners a way to signal to clients how they may receive queries for
   the records for which they are authoritative.  The NS2 and NS2T
   records are machine readable, can coexist with NS records in the same
   zone, and do not break software that does not support them.

   NS2 and NS2T are designed to allow child zones to publish NS2 and
   NS2T records, even without support in the parent zone.  Lack of
   parent zone support for NS2 records may arise for technical or policy
   reasons.









April                    Expires 14 January 2021                [Page 4]


Internet-Draft                     NS2                         July 2020


1.3.  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.

2.  NS2 and NS2T Record Types

   The SVCB record allows for two types of records, the AliasForm and
   the ServiceForm.  The NS2 record takes advantage of both and each
   will be described below in depth.

2.1.  Difference between the records

   This document introduces two different resource record types.  Both
   records have the same functionality, with the difference between them
   being that the NS2 record MUST only be used at a delegation point
   while the NS2T, is NS2 Target, record does not indicate that the
   label is being delegated.  For example, take the following NS2
   record:

   example.com.  86400  IN NS2 1   ns2.example.net. ( transports=dot )

   When a client receives the above record, the resolver should send
   queries for any name under example.com to the nameserver at
   ns2.example.com unless further delegated.  By contrast, when
   presented with the records below:

example.com.  86400  IN NS2 0   customer.example.org.
customer.example.org.  86400  IN NS2T 1   ns2.example.net. ( transports=dot )

   A resolver trying to resolve a name under example.com would get the
   first record above from the parent authoritative server, .COM,
   indicating that the NS2T records found at customer.example.org should
   be used to locate the authoritative nameservers of example.com.  The
   second record above dictates that the authoritative nameserver from
   records that have aliased to customer.example.org is ns2.example.net,
   which only accepts queries over DNS-over-TLS.  The primary difference
   between the two records is that the NS2 record means that anything
   under the record label should be queried at the delegated server
   while the NS2T record is just for redirection purposes, and any names
   under the record's label should still be resolved using the same
   server unless otherwise delegated.

   It should be noted that both NS2 and NS2T records may exist for the
   same label.  Below is an example of this:



April                    Expires 14 January 2021                [Page 5]


Internet-Draft                     NS2                         July 2020


 example.com.  86400  IN NS2 0   c1.example.org.
 c1.example.org.  86400  IN NS2T 1   ns2.example.net. ( transports=dot )
 c1.example.org.  86400  IN NS2  1   ns3.example.net. ( transports=dot )
 test.c1.example.org. 600 IN A 192.0.2.1

   In the above case, the NS2 record for c1.example.org would only be
   used when trying to resolve names below c1.example.org.  This reason
   is why when an AliasForm NS2 or NS2T record is encountered, the
   resolver MUST query for the NS2T record associated with the given
   name.

   Since the NS2 record is indicative of a zone cut while NS2T is not,
   names MUST NOT have but NS2 and NS2T records at the same time.

2.2.  AliasForm Record Type

   In order to take full advantage of the AliasForm of NS2 and NS2T, the
   parent, child and resolver must support these records.  When
   supported, the use of the AliasForm will allow zone owners to
   delegate their zones to another operator with a single record in the
   parent.  AliasForm NS2 records SHOULD appear in the child zone when
   used in the parent.  If a resolver were to encounter an AliasForm NS2
   or NS2T record, it would then resolve the name in the SvcDomainName
   of the original record using NS2T RR type to receive the either
   another AliasForm record or a ServiceForm NS2T record.

   For example, if the name www.example.com was being resolved, the .com
   zone may issue a referral by returning the following record:

   example.com.    86400    IN  NS2     0   customer1.example.net.

   The above record would indicate to the resolver that in order to
   obtain the authoritative nameserver records for example.com, the
   resolver should resolve the RR type NS2T for the name
   customer1.example.net.

2.2.1.  Multiple Service Providers

   Some zone owners may wish to use multiple providers to serve their
   zone, in which case multiple NS2 AliasForm records can be used.  In
   the event that multiple NS2 AliasForm records are encountered, the
   resolver SHOULD pick one of the records at random.  For example, to
   split traffic between two providers, the zone owner for example.com
   could have the following NS2 records:

   example.com.    86400    IN  NS2     0   customer1.example.net.
   example.com.    86400    IN  NS2     0   customer1.example.org.




April                    Expires 14 January 2021                [Page 6]


Internet-Draft                     NS2                         July 2020


   DRAFT NOTE: SVCB says that there "SHOULD only have a single RR".
   This ignores that but keep the randomization part.  Section 2.5p1 of
   SVCB

2.2.2.  Loop Prevention

   Special care should be taken by both the zone owner and the delegated
   zone operator to ensure that a lookup loop is not created by having
   two AliasForm records rely on each other to serve the zone.  Doing so
   may result in a resolution loop, and likely a denial of service.  Any
   clients implementing NS2 and NS2T SHOULD implement a per-resolution
   limit of how many AliasForm records may be traversed when looking up
   a delegation to prevent infinite looping.  When a loop is detected,
   like with the handling of CNAME or NS, the server should respond to
   the client with SERVFAIL.

2.3.  ServiceForm Record Type

   The ServiceForm of the NS2 and NS2T records are likely to be the more
   popular of the two.  They work the same way as the SVCB or HTTPSSVC
   records do by providing a priority and list of parameters associated
   with the SvcDomainName.  In addition to being able to identify which
   protocols are supported by the authoriatative server, the ServiceForm
   record will also allow providers to operate different protocols on
   different addresses.

2.3.1.  SvcFieldPriority

   As defined in the DNS SVCB document
   [I-D.draft-ietf-dnsop-svcb-httpssvc-00], the SvcFieldPriority values
   SHOULD be used to dictate the priority when multiple NS2 or NS2T
   records are returned.

2.3.2.  SvcDomainName

   As defined in the SVCB document
   [I-D.draft-ietf-dnsop-svcb-httpssvc-00], the SvcDomainName provides
   the hostname to which the NS2 or NS2T record refers.  The wire format
   must be the a-label format of the name.  When presented, the u-label
   may be presented, but the the a-label should also be displayed
   displaying the u-label.  The SvcDomainName field MUST be set and MUST
   NOT be "." for NS2 records.  Records with a SvcDomainName of "."
   SHOULD be discarded.

   DRAFT NOTE: Should u-label and a-label be expanded?  I'm leaning
   towards not expanding.





April                    Expires 14 January 2021                [Page 7]


Internet-Draft                     NS2                         July 2020


2.3.3.  SvcParamKeys

   The following DNS SVCB parameters are defined for the NS2 and NS2T
   ServiceForms.

2.3.3.1.  "transports"

   The "transports" SvcParamKey defines the list of transports offered
   by the nameserver named in the SvcDomainName.

   The existing "alpn" SvcParamKey was not reused for NS2 and NS2T due
   to the restriction that the "alpn" SvcParamValues are limited to
   those defined in the TLS Application-Layer Protocol Negotiation
   (ALPN) Protocol IDs registry.  Plaintext DNS traffic is not, and
   should not be listed in that registry, but is required to support the
   transition to encrypted transport in NS2 and NS2T records.

   Below is a list of the transport values defined in this document:

   *  "do53": indicates that a server supports plaintext, unencrypted
      DNS traffic over UDP or UDP as defined in [RFC1035] and [RFC1034]
      and the updates to those RFCs.

   *  "dot": indicates that the server supports encrypted DNS traffic
      over DNS-over-TLS as defined in [RFC7858].

   *  "doh": indicates that the server supports encrypted DNS traffic
      over DNS-over-HTTPS as defined in [RFC8484].  Records that use the
      DoH service form may be further redirected with HTTPSSVC records
      in the delegated zone.

   *  "doq": indicates that the server supports encrypted DNS traffic
      over DNS over Dedicated QUIC Connections
      [I-D.draft-huitema-quic-dnsoquic-07]

   The order of the keys in the list dictate the order which the
   nameserver SHOULD be contacted in.  The client SHOULD compare the
   order of available transports with the set of transports it supports
   to determine how to contact the selected nameserver.

   The presentation format of the SvcParamValue is a comma delimited
   quoted string of the available transport names.  The wire format for
   the SvcParamValue is a string of 16-bit integers representing the
   TransportKey values as described in the "NS2/NS2T Transport Parameter
   Registry".






April                    Expires 14 January 2021                [Page 8]


Internet-Draft                     NS2                         July 2020


2.3.3.2.  "dnsDotEarlyData"

   The "dnsDotEarlyData" SvcParamKey indicates if the server will accept
   requests with TLS 1.3 Early Data as described in
   [I-D.draft-ghedini-dprive-early-data-01].  If the "dot" transport is
   enabled on the record but this value is not present, the default
   value is that the server will not accept early data.

   The presentation format of the SvcParamValue is the string "true" or
   "false".  The wire format of the SvcParamValue is to not have the key
   present or a single octet with the value of 0x00 when early data is
   not allowed and a 0x01 value when early data is allowed.  All other
   values should be treated as an error and revert the value to the
   default of not supported.

   DRAFT NOTE: Should this be "ns2flags" and just have a 16 bit field
   for boolean values?

2.3.3.3.  "dnsDohURITemplate"

   The "dnsDohURITemplate" SvcParamKey defines the URI template to be
   used for issuing DNS-over-HTTPS queries to the nameserver defined in
   the record.  The host portion of the "dnsDohURITemplate" value SHOULD
   match the SvcDomainName field.

   In the event that the host portion of the "dnsDohURITemplate"
   SvcParamValues and SvcDomainName field do not match, the
   SvcDomainName value SHOULD be used for resolving the host and provide
   host portion of the "dnsDohURITemplate" template SvcParamValue for
   the TLS ServerNameIndication header and the HTTP Host header.  For
   example, in the below NS2 delegation, the client SHOULD resolve the
   name ns.example.net and provide the host header and TLS
   ServerNameIndication header of doh.example.org:

   example.com.  86400 IN NS2 3 ns.example.net. ( transports=doh,
   dnsDohURITemplate="https://doh.example.org/q/{?dns}" )

   The presentation format of the SvcParamValue is a quoted string.  The
   wire form of the SvcParamValue is an octet string of the URI template
   as defined in [RFC8484].











April                    Expires 14 January 2021                [Page 9]


Internet-Draft                     NS2                         July 2020


2.3.3.4.  "esniconfig"

   The "esnikeys" SvcParamKey is defined in
   [I-D.draft-ietf-dnsop-svcb-httpssvc-00].  It can be used to provide
   the ESNI key for DoT, DoH and/or future protocols which may make use
   of ESNI for session establishment.  See
   [I-D.draft-ietf-dnsop-svcb-httpssvc-00] for the usage, wire, and
   display formatting for this SvcParamKey.

2.3.3.5.  "dnsTlsFingerprints"

   The "dnsTlsFingerprints" SvcParamKey is a list of fingerprints for
   the TLS certificates that may be presented by the nameserver.  This
   record SHOULD match the TLSA record as described in [RFC6698].  Due
   to bootstrapping concerns, this SvcParamKey has been added to the NS2
   record as the TLSA records would only be resolveable after the
   initial connetion to the delegated nameserver was established.  When
   this field is not present, certificate validation should be performed
   by either DANE or by traditional TLS certification validation using
   trusted root certification authorities.

   The presentation and wire format of the SvcParamValue is the same as
   the presentation and wire format described for the TLSA record as
   defined in [RFC6698], sections 2.1 and 2.2 respectively.

2.4.  Deployment Considerations

   The NS2 and NS2T records intends to replace the NS record while also
   adding additional functionality in order to support additional
   transports for the DNS.  Below are discussions of considerations for
   deployment.

2.4.1.  AliasForm and ServiceForm in the Parent

   Both the AliasForm and ServiceForm records MUST NOT be returned for
   the same record when not in delegated zone.  In the case where both
   are present, the ServiceForm MUST be used and the AliasForm ignored.

   DRAFT NOTE: This is in direct conflict with SVCB.  I'm currently of
   the opinion that it should stay as it is for reliability reasons.  If
   it is decided that this should contradict SVCB, maybe we should try
   to change SVCB.









April                    Expires 14 January 2021               [Page 10]


Internet-Draft                     NS2                         July 2020


2.4.2.  Rollout

   When introduced, the NS2 and NS2T record will likely not be supported
   by the Root or second level operators, and may not be for some time.
   In the interim, zone owners may place these records into their zones,
   both for their own zone and any of their child zones.  If a resolver
   supports alternative transports, it MAY, when delegated to another
   server, issue a query for NS2 or NS2T records and potentially use
   those records for further query processing.

   DRAFT NOTE: Should we include something here that an authoritative
   MAY include NS2 records in the additionals section of responses to
   encourage resolvers to upgrade?  What about an ECS option from the
   authority to signal that it is capable of alternat transports?

2.4.3.  Availability

   If a zone operator removes all NS records before NS2 and NS2T records
   are implemented by all clients, the availability of their zones will
   be impacted for the clients that are using non-supporting resolvers.
   In some cases, this may be a desired quality, but should be noted by
   zone owners and operators.

2.4.4.  Multiple ServiceForm records for the same host or IP address

   As described in the "transport" SvcParamKey section above, a host or
   IP address may support multiple different transport methods.  This
   can be represented in two ways.  The first is to list all supported
   transports in the order of diminishing desire in the same record.
   The second is to use multiple NS2 or NS2T records.

   When those records have different SvcFieldPriority values, as in
   [I-D.draft-ietf-dnsop-svcb-httpssvc-00], lower-numbered priorities
   express a higher preference for that record.

   NS2 and NS2T records may have multiple values for the
   "dnsTlsFingerprints" SvcParamKey.  Records that are identical other
   than the "dnsTlsFingerprints" SvcParamValues may be joined together
   including multiple "dnsTlsFingerprints" as seen in this example:

  example.com.  86400  IN NS2    2 ns.example.net. ( transports=dot,
                  dnsTlsFingerprints="MIIS987SSLKJ...123===" )
  example.com.  86400  IN NS2    2 ns.example.net. ( transports=dot,
                  dnsTlsFingerprints="MII3SODKSLKJ...456===" )
  example.com.  86400  IN NS2    3 ns.example.net. ( transports=doh,
                  dnsDohURITemplate="https://dns.example.org/q/{?dns}" )

   are the same as:



April                    Expires 14 January 2021               [Page 11]


Internet-Draft                     NS2                         July 2020


  example.com.  86400  IN NS2    2 ns.example.net. ( transports=dot,
                  dnsTlsFingerprints=["MIIS987SSLKJ...123===",
                      "MII3SODKSLKJ...456==="] )
  example.com.  86400  IN NS2    3 ns.example.net. ( transports=doh,
                  dnsDohURITemplate="https://dns.example.org/q/{?dns}" )

3.  Responses with NS2

   The NS2 and NS2T records are intended to supersede the NS record.  As
   such, the NS2 records should be included in the response in the
   following situations, assuming the records exist in the servers zone:

   1) If the qtype is for NS2 or NS2T, the server should respond with
   NS2 or NS2T respectively in the authority section of the response.

   2) For queries over unencrypted TCP port 53, any of the NS2 and NS2T
   records SHOULD be included in the additional section of the response.

   3) For queries over unencrypted UDP port 53, any of the NS2 and NS2T
   records SHOULD be included in the additional section of the response
   unless doing so would result in a truncated response.  For responses
   that would require truncation, the resolver operator and/or
   implementor may decide to truncate the response or exclude the
   records from the response.

   4) If encrypted transports are supported on the authority, the any
   NS2 and NS2T records should be included in the authority section of
   the respose.

   DRAFT NOTE: It is unknown how resolvers will handle multiple
   authoritative RRTypes in the authority section of the response,
   leaving 2 and 3 as the additional section until either testing is
   done or a consensus is determined in DNSOP/DPRIVE.

   DRAFT NOTE: Suggesting authority for encrypted transport since it
   would more closely align with the NS record.

3.1.  Response Size Considerations

   For latency-conscious zones, the overall packet size of the
   delegation records from a parent zone to child zone should be taken
   into account when configuring the NS, NS2 and NS2T records.
   Resolvers that wish to receive NS2 and NS2T records in response
   SHOULD advertise and support a buffer size that is as large as
   possible, ideally 4096 bytes, to allow the authoritative server to
   respond without truncating whenever possible.





April                    Expires 14 January 2021               [Page 12]


Internet-Draft                     NS2                         July 2020


3.2.  When to include glue

   Like with NS, when a parent is delegating to a child that is in
   bailiwick, glue records should be included with responses to enable
   the client to continue to resolve the names.

   The ServiceForm version of NS2 returnes sufficent information to the
   client communicate with the delegated nameserver over a transport
   other than Do53, but the AliasForm does not.  For this reason, the
   most common use of the AliasForm record would be to alias to a name
   that is out of bailiwick to the requested zone, which SHOULD be
   resolveable without relying on the originally queried zone.  In the
   event of an in-bailiwick AliasForm record, the client must either
   have a pre-agreed upon configuration for the server or attempt
   opprotunisitic upgrade of the connection to use non-Do53 for the
   initial setup.

4.  DNSSEC and NS2

   Like with NS records, the NS2 records in the child zone SHOULD be
   signed when the zone is DNSSEC signed.  The NS2 records that appear
   in the parent zone are glue and would not be signed, as is the case
   with NS records.

   NS2T records, SHOULD be signed in a zone which is signed by DNSSEC.

5.  Privact Considerations

   All of the information handled or transmitted by this protocol is
   public information published in the DNS.

   While the records are transmitting public infomration, resolvers
   which are making use of records may be attemping to keep the
   information they are querying private from on-path observers.
   Privacy consious resolvers should query for this record at the apex
   of a zone when delegated from the parent to help establish an
   encrypted channel to the authority.

6.  Security Considerations

   TODO: Fill this section out

6.1.  Availability of zones without NS

6.2.  Reflection Attacks

6.3.  Parsing




April                    Expires 14 January 2021               [Page 13]


Internet-Draft                     NS2                         July 2020


6.4.  Availability

6.5.  Connetion Failures

   When a resolver attempts to access nameserver delegated by a NS2 or
   NST2 record, if a connection error occurs, such as a certificate
   mismatch or unreachable server, the resolver SHOULD attempt to
   connect to the other nameservers delegated to until either exhausting
   the list or the resolver's policy indicates that they should treat
   the resoltion as failed.

   The failure action when failing to resolve a name with NS2/NS2T due
   to connection erros is dependant on the resolver operators policies.
   For resolvers which strongly favor privacy, the operators may wish to
   return a SERVFAIL when the NS2/NS2T resoltion process completes
   without successfully contacting a delegated nameserver(s) while
   opportunisitic privacy resolvers may wish to attempt resolution using
   any NS records that may be present.

7.  IANA Considerations

7.1.  New registry for NS2 transports

   The "NS2/NS2T Transport Parameter Registry" defines the namespace for
   parameters, including string representations and numeric values.
   This registry applies to the "transports" DNS SVCB format, currently
   impacting the NS2 RR Type.

   ACTION: create and include a reference to this registry.

7.1.1.  Procedure

   A registration MUST include the following fields:

   *  Name: The transport type key name

   *  TransportKey: A numeric identifier (range 0-65535)

   *  Meaning: a short description

   *  Protocol Specification

   *  Pointer to specification text

7.1.2.  Initial Contents

   The "NS2/NS2T Transport Parameter Registry" shall initially be
   populated with the registrations below:



April                    Expires 14 January 2021               [Page 14]


Internet-Draft                     NS2                         July 2020


   +==============+========+================+===============+==========+
   | TransportKey | Name   | Meaning        | Protocol      |Reference |
   |              |        |                | Specification |          |
   +==============+========+================+===============+==========+
   | 0            | key0   | Reserved       | Reserved      | (This    |
   |              |        |                |               |Document) |
   +--------------+--------+----------------+---------------+----------+
   | 1            | do53   | Unencrypted,   | RFC1035       | (This    |
   |              |        | Plaintext DNS  |               |Document) |
   |              |        |over UDP or TCP |               |          |
   +--------------+--------+----------------+---------------+----------+
   | 2            | dot    | DNS-over-TLS   | RFC7858       | (This    |
   |              |        |                |               |Document) |
   +--------------+--------+----------------+---------------+----------+
   | 3            | doh    | DNS-over-HTTPS | RFC8484       | (This    |
   |              |        |                |               |Document) |
   +--------------+--------+----------------+---------------+----------+
   | 4            | doq    | DNS over       | [DOQ-I-D]     |          |
   |              |        | Dedicated QUIC |               |          |
   |              |        | Connections    |               |          |
   +--------------+--------+----------------+---------------+----------+
   | 65280-65534  |keyNNNNN| Private Use    | Private Use   | (This    |
   |              |        |                |               |Document) |
   +--------------+--------+----------------+---------------+----------+
   | 65535        |key65535| Reserved       | Reserved      | (This    |
   |              |        |                |               |Document) |
   +--------------+--------+----------------+---------------+----------+

                                  Table 1

7.2.  New SvcParamKey Values

   This document defines new SvcParamKey values in the "Service Binding
   (SVCB) Parameter Registry".

     +=============+====================+=========+=================+
     | SvcParamKey | NAME               | Meaning | Reference       |
     +=============+====================+=========+=================+
     | TBD1        | transports         |         | (This Document) |
     +-------------+--------------------+---------+-----------------+
     | TBD2        | dnsDotEarlyData    |         | (This Document) |
     +-------------+--------------------+---------+-----------------+
     | TBD3        | dnsDohURITemplate  |         | (This Document) |
     +-------------+--------------------+---------+-----------------+
     | TBD4        | dnsTlsFingerprints |         | (This Document) |
     +-------------+--------------------+---------+-----------------+

                                 Table 2



April                    Expires 14 January 2021               [Page 15]


Internet-Draft                     NS2                         July 2020


8.  Informative References

   [I-D.draft-ietf-dnsop-svcb-https-00]
              Schwartz, B., Bishop, M., and E. Nygren, "Service binding
              and parameter specification via the DNS (DNS SVCB and
              HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-
              dnsop-svcb-https-00, 12 June 2020, <http://www.ietf.org/
              internet-drafts/draft-ietf-dnsop-svcb-https-00.txt>.

   [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/info/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/info/rfc8174>.

   [I-D.draft-ietf-dnsop-svcb-httpssvc-00]
              Schwartz, B., Bishop, M., and E. Nygren, "Service binding
              and parameter specification via the DNS (DNS SVCB and
              HTTPSSVC)", Work in Progress, Internet-Draft, draft-ietf-
              dnsop-svcb-httpssvc-00, 31 October 2019,
              <http://www.ietf.org/internet-drafts/draft-ietf-dnsop-
              svcb-httpssvc-00.txt>.

   [RFC1035]  Mockapetris, P.V., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC1034]  Mockapetris, P.V., "Domain names - concepts and
              facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034,
              November 1987, <https://www.rfc-editor.org/info/rfc1034>.

   [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>.

   [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>.









April                    Expires 14 January 2021               [Page 16]


Internet-Draft                     NS2                         July 2020


   [I-D.draft-huitema-quic-dnsoquic-07]
              Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
              Iyengar, "Specification of DNS over Dedicated QUIC
              Connections", Work in Progress, Internet-Draft, draft-
              huitema-quic-dnsoquic-07, 7 September 2019,
              <http://www.ietf.org/internet-drafts/draft-huitema-quic-
              dnsoquic-07.txt>.

   [I-D.draft-ghedini-dprive-early-data-01]
              Ghedini, A., "Using Early Data in DNS over TLS", Work in
              Progress, Internet-Draft, draft-ghedini-dprive-early-data-
              01, 6 July 2019, <http://www.ietf.org/internet-drafts/
              draft-ghedini-dprive-early-data-01.txt>.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <https://www.rfc-editor.org/info/rfc6698>.

   [DOQ-I-D]  Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
              Iyengar, "Specification of DNS over Dedicated QUIC
              Connections", Work in Progress, Internet-Draft, draft-
              huitema-quic-dnsoquic-07, 7 September 2019,
              <http://www.ietf.org/internet-drafts/draft-huitema-quic-
              dnsoquic-07.txt>.

Appendix A.  Acknowledgements

   Thank you to John Levine, Erik Nygren, Ralf Weber, Jon Reed, Ben
   Kaduk, Mashooq Muhaimen, Jason Moreau, Jerrod Wiesman, Billy Tiemann,
   Gordon Marx and Brian Wellington for their comments and suggestions
   on this draft.

Appendix B.  TODO

   RFC EDITOR:  PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION.

   *  Discussion about TTLs and what they should be and how that might
      impact performance

   *  Discuss the cacheability of the Alias form records.

   *  Remove all "DRAFT NOTES:" in the document.

   *  Write a security considerations section

   *  add prohibition of AliasForm referring to AliasForm




April                    Expires 14 January 2021               [Page 17]


Internet-Draft                     NS2                         July 2020


   *  add out-of-bailiwick requirement for AliasForm

   *  worked out resolution example including alias form delegation

   *  DoH URI teamplte does not include post

   *  If NS2 is authoritative in the parent, does that mean that it will
      not be a referral anymore?  Probably a question for the working
      group

Appendix C.  Change Log

   RFC EDITOR:  PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION.

   pre-00

   *  Initial draft.

   *  Wire and Presentation formats for all new SvcParamKeys and
      SvcParamValues

   *  IANA considerations first pass

   *  Added a section about SvcFieldPriority

   *  Added the "ds" and "dnskey" SvcParamKey options to support the
      deprecation of the DS in the parent.

   *  Added notes on DNSSEC signing of NS2

   *  Removed multi-provider sharding example, with performance
      measurements the distribution probably wouldn't work

   *  Reworked the introduction to try and make it easier to parse

   *  Removed the port fields for each transport option

   *  Added a discussion about when to include NS2 records.

   *  Add an example early in the draft.  Introduction area

   *  Add section about port numbers discussion

   *  collapse udp and tcp to the do53

   *  added a second record (NS2 and NS2T)

   -01



April                    Expires 14 January 2021               [Page 18]


Internet-Draft                     NS2                         July 2020


   *  Removed DS and DNSKEY SvcParamFields.  Avoids issues with DNSSEC
      signing in the parent.

   *  Removed IPv{4,6}Hints SvcParamFields.  There was a discussion on
      DNSOP about how glue is required

   *  Updating when to sign the NS2 / NS2T records (removed signing in
      the parent)

   *  Attempting to clean up the introduction, goals and motivations of
      the document

   *  Adding a privacy considerations section

   *  Adding more clairty around when to include/expect the NS2/NS2T
      records

   *  Adding this note that CNS2 will not be included in this draft

   *  Prohibiting NS2 and NS2T from existing at the same name

   *  Making the statement about the parent records being glue and
      should not be signed

Appendix D.  Discussions

   Editor Note: Remove this full section before publication.

D.1.  Port Numbers

   Originally, I had added SvcParamKeys for port numbers for each of the
   protocols.  There was a discussion that resulted in removing the port
   numbers, since it was added complexity that had little perceived use
   in the wild.  These can be added back if there is a desire to have
   them.  The original author included them as a way to provide the
   nameserver operator a way to differentiate incoming traffic when
   using the aliasform with lower TTLs and intelligent responses based
   on the client IP.

D.2.  CNS2

   Client NS2, similar to CDS might be a way to provide support for
   getting NS2 records into the parent zone before going through the
   registrars, but that might be a tough thing to agree on at this
   point.






April                    Expires 14 January 2021               [Page 19]


Internet-Draft                     NS2                         July 2020


D.3.  Second Record Name

   Selected NS2T for Nameserver 2 Target since the record defines the
   target authoritative servers.

   ~~~ 01234567890123456789012345678901234567890123456789012345678901234
   567891

Author's Address

   Tim April
   Akamai Technologies

   Email: ietf@tapril.net





































April                    Expires 14 January 2021               [Page 20]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/