| 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
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.
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 (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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
The following DNS SVCB parameters are defined for the NS2 and NS2T ServiceForms.
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.
See [I-D.draft-ietf-dnsop-svcb-httpssvc-00] for the usage, wire and display formatting for this SvcParamKey.
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:
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”.
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?
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].
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.
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.
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.
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.
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.
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?
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.
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.
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}" )
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.
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.
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.
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.
TODO: Fill this section out
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.
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.
A registration MUST include the following fields:
The “NS2/NS2T Transport Parameter Registry” shall initially be populated with the registrations below:
| TransportKey | Name | Meaning | Protocol Specification | Reference |
|---|---|---|---|---|
| 0 | key0 | Reserved | Reserved | (This Document) |
| 1 | do53 | Unencrypted, Plaintext DNS over UDP or TCP | RFC1035 | (This Document) |
| 2 | dot | DNS-over-TLS | RFC7858 | (This Document) |
| 3 | doh | DNS-over-HTTPS | RFC8484 | (This Document) |
| 4 | doq | DNS over Dedicated QUIC Connections | [I-D.draft-huitema-quic-dnsoquic-07] | |
| 65280-65534 | keyNNNNN | Private Use | Private Use | (This Document) |
| 65535 | key65535 | Reserved | Reserved | (This Document) |
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) | |
| TBD5 | ds | (This Document) | |
| TBD6 | dnskey | (This Document) |
| [I-D.draft-ghedini-dprive-early-data-01] | Ghedini, A., "Using Early Data in DNS over TLS", Internet-Draft draft-ghedini-dprive-early-data-01, 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", Internet-Draft draft-huitema-quic-dnsoquic-07, 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)", Internet-Draft draft-ietf-dnsop-svcb-httpssvc-00, October 2019. |
| [RFC1034] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987. |
| [RFC1035] | Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [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. |
| [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. |
| [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. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [RFC8484] | Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018. |
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.
pre-00
Editor Note: Remove this full section before publication.
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.
Selected NS2T for Nameserver 2 Target since the record defines the target authoritative servers.
~~~ 012345678901234567890123456789012345678901234567890123456789012345678912