dnsop T. April
Internet-Draft Akamai Technologies
Intended status: Informational March 9, 2020
Expires: September 10, 2020
Parameterized Nameserver Delegation with NS2 and NS2T
draft-tapril-ns2-00
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, protocol
negotiation would be required. This document provides two new
Resource Record Types, NS2 and NS2T, to facilitate that negotiation
by allowing zone owners to signal how the authoritative nameserver(s)
for their zone(s) may accept queries.
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 September 10, 2020.
Copyright Notice
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of
April Expires September 10, 2020 [Page 1]
Internet-Draft NS2 March 2020
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 . . . . . . . . . . . . . . . . . . . . . . . 4
2. NS2 and NS2T Record Types . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . 6
2.3. ServiceForm . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. SvcFieldPriority . . . . . . . . . . . . . . . . . . 7
2.3.2. SvcDomainName . . . . . . . . . . . . . . . . . . . . 7
2.3.3. SvcParamKeys . . . . . . . . . . . . . . . . . . . . 7
2.4. Deployment Considerations . . . . . . . . . . . . . . . . 11
2.4.1. AliasForm and ServiceForm in the Parent . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . 12
4. DNSSEC and NS2 . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.1. Availability of zones without NS . . . . . . . . . . . . 13
5.2. Reflection Attacks . . . . . . . . . . . . . . . . . . . 13
5.3. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. Availability . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Connetion Failures . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. New registry for NS2 transports . . . . . . . . . . . . . 14
6.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 14
6.1.2. Initial Contents . . . . . . . . . . . . . . . . . . 14
6.2. New SvcParamKey Values . . . . . . . . . . . . . . . . . 15
7. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Appendix B. TODO . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Appendix D. Discussions . . . . . . . . . . . . . . . . . . . . 18
D.1. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 19
D.2. Second Record Name . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
April Expires September 10, 2020 [Page 2]
Internet-Draft NS2 March 2020
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-httpssvc-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
In this example, the authoritative nameserver is delegating to both a
DNS-over-TLS and DNS-over-HTTPS service running on ns.example.net for
resolvers that support NS2, and also delegating to a nameserver that
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 NS2 to an AliasForm which can
then be further resolved.
April Expires September 10, 2020 [Page 3]
Internet-Draft NS2 March 2020
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 ns1.example.org. ( transports=dot,
dnsTlsFingerprints=["MIIS987SSLKJ...123==="] )
ns2.example.net 3600 IN NS2T ns2.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 when parent zones only publish NS records. Lack
of parent zone support for NS2 records may arise for technical or
policy reasons.
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.
April Expires September 10, 2020 [Page 4]
Internet-Draft NS2 March 2020
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:
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.
April Expires September 10, 2020 [Page 5]
Internet-Draft NS2 March 2020
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.
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,
April Expires September 10, 2020 [Page 6]
Internet-Draft NS2 March 2020
like with the handling of CNAME or NS, the server should respond to
the client with SERVFAIL.
2.3. ServiceForm
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.
2.3.3. SvcParamKeys
The following DNS SVCB parameters are defined for the NS2 and NS2T
ServiceForms.
2.3.3.1. "ipv4hint" and "ipv6hint"
The "ipv4hint" and "ipv6hint" SvcParamKeys are defined in
[I-D.draft-ietf-dnsop-svcb-httpssvc-00]. The NS2 and NS2T records
can makes use of the same keys to indicate the IP address(es) of the
server referenced in the SvcDomainname field. "ipv4hint" and
"ipv6hint" supersede existing glue records for a name but not A or
AAAA records in the child. When not present, glue records MAY be
used to locate the delegated nameserver.
April Expires September 10, 2020 [Page 7]
Internet-Draft NS2 March 2020
See [I-D.draft-ietf-dnsop-svcb-httpssvc-00] for the usage, wire and
display formatting for this SvcParamKey.
2.3.3.2. "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:
o "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.
o "dot": indicates that the server supports encrypted DNS traffic
over DNS-over-TLS as defined in [RFC7858].
o "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.
o "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 September 10, 2020 [Page 8]
Internet-Draft NS2 March 2020
2.3.3.3. "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.4. "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].
2.3.3.5. "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
April Expires September 10, 2020 [Page 9]
Internet-Draft NS2 March 2020
[I-D.draft-ietf-dnsop-svcb-httpssvc-00] for the usage, wire, and
display formatting for this SvcParamKey.
2.3.3.6. "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.3.3.7. "ds" or "dnskey"
The "ds" and "dnskey" SvcParamKey contain a list of hashes of the
public key(s) used to sign the zone and the public key(s) for the
zone respectively. Unline the DS and DNSKEY RRTypes, the "ds" and
"dnskey" SvcParamKey values apply to the referenced resolver only,
but the same values may be advertised for all records. For secure
delegation, only one of these SvcParamKey is required in the NS2 or
NS2T record, but both may be provided. The "ds" and "dnskey"
SvcParamKey will supersede any DS or DNSKEY records available in the
parent zone, but in the absence of these SvcParamKeys in the NS2
record, clients should defer to the DS or DNSKEY records if present.
Having these keys in the NS2 record may reduce the number of queries
that are required to delegate to the child nameserver, but can result
in larger packet sizes. These larger packets could result in UDP
fragmentation, forcing clients to upgrade the connection to
unencrypted DNS over TCP.
Multiple "ds" or "dnskey" SvcParamKeys MAY exist to provide multiple
valid public keys for key rollovers or when using multiple signing
methods.
The wire format of the SvcParamValues is a list of values defined in
[RFC4034] for both the SvcParamValue for the "ds" SvcParamKey
matching the DS RRType and the SvcParamValue for the "dnskey"
SvcParamKey matching the DNSKEY RRType. The presentation format for
both records is a quoted string list using the same presentation
format defined in [RFC4034] for both records.
April Expires September 10, 2020 [Page 10]
Internet-Draft NS2 March 2020
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.
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.
April Expires September 10, 2020 [Page 11]
Internet-Draft NS2 March 2020
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.
In the case where there are identical records other than the "ds" or
"dnskey" fields, the records can be combined. In the below example,
there are two records that have the same SvcDomainName,
SvcFieldPriority, and SvcParamValues (other than "ds"). As a result,
the NS2 records here:
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:
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
NS2 and NS2T are intended to supersede the NS record. When an
authoritative nameserver receives a query for a name that it intendes
to refer to another server, the nameserver SHOULD be provided NS2
records in addition to NS records in the delegation.
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.
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.
April Expires September 10, 2020 [Page 12]
Internet-Draft NS2 March 2020
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
When NS2 and NS2T records exist in a zone (parent, child or
unrelated) and the zone is signed, the records SHOULD be included in
the DNSSEC signing. NS2 and NS2T records for the same label may have
different SvcParamValues for the "ds" or "dnskey" SvcParamKeys.
Validating resolvers need to carefully track which keying information
corresponds to which (zones, resolver) tuple.
5. Security Considerations
TODO: Fill this section out
5.1. Availability of zones without NS
5.2. Reflection Attacks
5.3. Parsing
5.4. Availability
5.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.
April Expires September 10, 2020 [Page 13]
Internet-Draft NS2 March 2020
6. IANA Considerations
6.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.
6.1.1. Procedure
A registration MUST include the following fields:
o Name: The transport type key name
o TransportKey: A numeric identifier (range 0-65535)
o Meaning: a short description
o Protocol Specification
o Pointer to specification text
6.1.2. Initial Contents
The "NS2/NS2T Transport Parameter Registry" shall initially be
populated with the registrations below:
April Expires September 10, 2020 [Page 14]
Internet-Draft NS2 March 2020
+----------+-------+-----------+--------------------------+---------+
| Transpor | Name | Meaning | Protocol Specification | Referen |
| tKey | | | | ce |
+----------+-------+-----------+--------------------------+---------+
| 0 | key0 | Reserved | Reserved | (This D |
| | | | | ocument |
| | | | | ) |
| | | | | |
| 1 | do53 | Unencrypt | RFC1035 | (This D |
| | | ed, | | ocument |
| | | Plaintext | | ) |
| | | DNS over | | |
| | | UDP or | | |
| | | TCP | | |
| | | | | |
| 2 | dot | DNS-over- | RFC7858 | (This D |
| | | TLS | | ocument |
| | | | | ) |
| | | | | |
| 3 | doh | DNS-over- | RFC8484 | (This D |
| | | HTTPS | | ocument |
| | | | | ) |
| | | | | |
| 4 | doq | DNS over | [I-D.draft-huitema-quic- | |
| | | Dedicated | dnsoquic-07] | |
| | | QUIC Conn | | |
| | | ections | | |
| | | | | |
| 65280-65 | keyNN | Private | Private Use | (This D |
| 534 | NNN | Use | | ocument |
| | | | | ) |
| | | | | |
| 65535 | key65 | Reserved | Reserved | (This D |
| | 535 | | | ocument |
| | | | | ) |
+----------+-------+-----------+--------------------------+---------+
6.2. New SvcParamKey Values
This document defines new SvcParamKey values in the "Service Binding
(SVCB) Parameter Registry".
April Expires September 10, 2020 [Page 15]
Internet-Draft NS2 March 2020
+-------------+--------------------+---------+-----------------+
| SvcParamKey | NAME | Meaning | Reference |
+-------------+--------------------+---------+-----------------+
| TBD1 | transports | | (This Document) |
| | | | |
| TBD2 | dnsDotEarlyData | | (This Document) |
| | | | |
| TBD3 | dnsDohURITemplate | | (This Document) |
| | | | |
| TBD4 | dnsTlsFingerprints | | (This Document) |
| | | | |
| TBD5 | ds | | (This Document) |
| | | | |
| TBD6 | dnskey | | (This Document) |
+-------------+--------------------+---------+-----------------+
7. Informative References
[I-D.draft-ghedini-dprive-early-data-01]
Ghedini, A., "Using Early Data in DNS over TLS", draft-
ghedini-dprive-early-data-01 (work in progress), July
2019.
[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", draft-huitema-quic-dnsoquic-07 (work in
progress), September 2019.
[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)", draft-ietf-dnsop-svcb-httpssvc-00 (work in
progress), October 2019.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[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>.
April Expires September 10, 2020 [Page 16]
Internet-Draft NS2 March 2020
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[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>.
[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>.
[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>.
[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>.
Appendix A. Acknowledgements
Thank you to 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.
o Discussion about TTLs and what they should be and how that might
impact performance
o Discuss the cacheability of the Alias form records.
o Remove all "DRAFT NOTES:" in the document.
o Write a security considerations section
o add prohibition of AliasForm referring to AliasForm
o add out-of-bailiwick requirement for AliasForm
o worked out resolution example including alias form delegation
April Expires September 10, 2020 [Page 17]
Internet-Draft NS2 March 2020
o DoH URI teamplte does not include post
o 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
o Initial draft.
o Wire and Presentation formats for all new SvcParamKeys and
SvcParamValues
o IANA considerations first pass
o Added a section about SvcFieldPriority
o Added the "ds" and "dnskey" SvcParamKey options to support the
deprecation of the DS in the parent.
o Added notes on DNSSEC signing of NS2
o Removed multi-provider sharding example, with performance
measurements the distribution probably wouldn't work
o Reworked the introduction to try and make it easier to parse
o Removed the port fields for each transport option
o Added a discussion about when to include NS2 records.
o Add an example early in the draft. Introduction area
o Add section about port numbers discussion
o collapse udp and tcp to the do53
o added a second record (NS2 and NS2T)
Appendix D. Discussions
Editor Note: Remove this full section before publication.
April Expires September 10, 2020 [Page 18]
Internet-Draft NS2 March 2020
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. Second Record Name
Selected NS2T for Nameserver 2 Target since the record defines the
target authoritative servers.
~~~ 01234567890123456789012345678901234567890123456789012345678901234
5678912
Author's Address
Tim April
Akamai Technologies
Email: ietf@tapril.net
April Expires September 10, 2020 [Page 19]