Internet-Draft Authenticated ADoT September 2021
Dickson Expires 21 March 2022 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-dickson-dprive-adot-auth-01
Published:
Intended Status:
Informational
Expires:
Author:
B. Dickson
GoDaddy

Authenticated DNS over TLS to Authoritative Servers

Abstract

This Internet Draft proposes a mechanism for DNS resolvers to discover support for TLS transport to authoritative DNS servers, to validate this indication of support, and to authenticate the TLS certificates involved.

This requires that the name server names are in a DNSSEC signed zone.

This also requires that the delegation of the zone served is protected by [I-D.dickson-dnsop-ds-hack], since the NS names are the keys used for discovery of TLS transport support.

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 21 March 2022.

Table of Contents

1. Introduction

The Domain Name System (DNS) predates any concerns over privacy, including the possibility of pervasive surveillance. The original transports for DNS were UDP and TCP, unencrypted. Additionally, DNS did not originally have any form of data integrity protection, including against active on-path attackers.

DNSSEC (DNS Security extensions) added data integrity protection, but did not address privacy concerns. The original DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] specifications were limited to client-to-resolver traffic.

The remaining privacy component is recursive-to-authoritative servers. This Internet Draft is designed to provide a solution to this problem.

2. Conventions and Definitions

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.

3. Background

The result is that the parental side of the zone cut has records needed for DNS resolution which are not signed and not validatable.

4. Purpose, Requirements, and Limitations

Authoritative DNS over TLS is intended to provide the following for communications from recursive resolvers to authoritative servers:

This protocol depends on correct configuration and operation of the respective components, and that those are maintained according to Best Current Practices:

There are external dependencies that impact the system security of any DNSSEC zone, which are inherently unavoidable in establishing this scheme. Specifially, the original DS record enrollment and any updates to the DS records involved in DNSSEC delegations are presumed secure and outside of the scope of the DNS protocol per se.

Other risks relate to normal information security practices, including access controls, role based access, audits, multi-factor authentication, multi-party controls, etc. These are out of scope for this protocol itself.

5. DNS Records To Publish for ADoT

5.1. Server DNS Transport Support Signaling

In order to support ADoT for a DNS server, it is necessary to publish a record specifyig explicit DoT support. This record also indicates other supported transports for the DNS server, e.g. the standard ports (TCP and UDP port 53).

The record type is "DNST", which is a specific instance of SVCB with unique RRTYPE.

The zone serving the record MUST be DNSSEC signed. The absence of the DNST RRTYPE is proven by the NSEC(3) record, or the DNST RRTYPE plus RRSIG is returned in response to a query for this record.

5.1.1. Prerequisite: New SVCB Binding for DNS and DoT

(NB: To be separated out into its own draft and expanded fully.) This SVCB binding will be given the RRTYPE value {TBD} with mnemonic name DNST ("DNS Transport"). Like any SVCB binding, there is a mandatory TargetName (which will normally be ".", indicating the target is the same as the record owner name). The default binding is the standard DNS ports, UDP/53 and TCP/53. The SVCB binding includes support for an optional ADoT port, which is the standard DoT port TCP/853. This is signaled by "alpn=dot". The actual port number may be overridden with the "port=N" SvcParam. Since DNST is a type-specific binding, it does NOT require the underscore prefix naming that the generic SVCB RRTYPE requires. It may occur anywhere, including at the apex of a DNS zone, and may co-exist with any other type that also permits other types (i.e. anything except CNAME or DNAME).

5.1.1.1. Default Ports for DNS

This scheme uses an SVCB binding for DNS Transport, DNST. The binding has default ports UDP/53 and TCP/53 as the default-alpn. These are assumed unless "no-default-alpn" is added as an optional SvcParam.

5.1.1.2. Optional Port for DoT

The DNST binding uses the defined ALPN for DNS-over-TLS with the assigned label "dot". Use of ADoT is signaled if and only if the the SvcParam of "alpn=dot" is present.

5.1.2. Example

Suppose the name server ns1.example.net supports only the normal DNS ports, and the name server ns2.example.net supports both the normal ports and ADoT. The zone example.net would include the records:

    ns1.example.net. IN DNST 1 "."
    ns2.example.net. IN DNST 1 "." alpn=dot

The first parameter is the SvcPriority, which must be non-zero (zero indicates AliasForm SVCB record type). Note that it is possible to use different SvcPriority, directing resolvers to prefer non-DoT over DoT or vice versa. This would be appropriate based on the resolver's local policy, and potentially support mandatory use of DoT if present on any server in the NS RRset.

5.2. DANE TLSA Records for ADoT

The presence of ADoT requires additionally that a TLSA [RFC6698] record be provided. A new RRTYPE is to be created for this as an alias of TLSA, with mnemonic of "ADOTC" (ADOT Certificate). This record will be published at the location NSNAME, where NSNAME is the name of the name server. Any valid TLSA RDATA is permitted. The use of Certificate Usage types PKIX-TA and PKIX-EE is NOT RECOMMENDED. The use of Certificate Usage types DANE-TA TLSA records may provide more flexibility in provisioning, including use of wild cards. Per [RFC7218][RFC6761] the RECOMMENDED Selector and Matching types for this are CERT and FULL, giving the recommended TLSA record type of DANE-TA CERT FULL, with the full encoded certificate.

Note that this ADOTC record is "wildcard friendly". Use of aggressive synthesis by resolvers (per [RFC8198]) allows RRTYPE-specific wildcards to be used, avoiding repetitive entries where the RDATA is identical.

5.2.1. Example

In the above example, ns2.example.net supports DNS over TLS, and would need to have a TLSA record. The zone would include:

    ns2.example.net. IN ADOTC DANE-TA CERT FULL (signing cert)

If there were another zone containing many DNS server names, example2.net, it would be relatively simple to apply a wildcard record and use a signing cert (rather than end-entity cert) in the ADOTC record). This would allow DNS caching to avoid repeated queries to the authoritative server for the zone containing the DNS server names, to obtain the TLSA-type information. This would look like the following:

    *.example2.net IN ADOTC DANE-TA CERT FULL (signing cert)
    ns1.example2.net IN A IP_ADDRESS1
    ns2.example2.net IN A IP_ADDRESS2
    ns3.example2.net IN A IP_ADDRESS3
    ns4.example2.net IN A IP_ADDRESS4

5.3. Signaling DNS Transport for a Name Server

This transport signaling MUST only be trusted if the name server names for the domain containing the relevant name servers' names are protected with [I-D.dickson-dnsop-ds-hack] and validated. The name servers must also be in a DNSSEC signed zone (i.e. securely delegated where the delegation has been successfully DNSSEC validated).

The specific DNS transport that a name server supports is indicated via use of an RRSet of RRTYPE "DNST". This is a SVCB binding, and normally will use the TargetName of "." (meaning the same name). The default ALPN (transport mechanisms) are TCP/53 and UDP/53. The ADoT transport support is signaled by "alpn=dot". There is an existing entry for "dot" in the ALPN table, with port TCP/853.

Note that this RRTYPE is also "wildcard friendly". If a DNS zone containing the names of many servers with identical policy (related to ADoT support), those could be managed via one or more wildcard entries.

5.3.1. Example

We re-use the same example from above, indicating whether or not individual authoritative name servers support DoT:

    ns1.example.net. IN DNST 1 "."
    ns2.example.net. IN DNST 1 "." alpn=dot

And similarly, if another zone with many name server names wanted to have a policy of all-ADoT support, this could be encoded as:

    *.example2.net DNST 1 "." alpn=dot

5.4. Signaling DNS Transport for a Domain

A domain inherits the signaled transport for the name servers serving the domain.

This transport signaling MUST only be trusted for use of ADoT if the delegated name server names for the domain are protected with [I-D.dickson-dnsop-ds-hack].

The delegation to NS names "A" and "B", along with the DS record protecting/encoding "A" and "B", results in the DNS transport that is signaled for "A" and "B" being applied to the domain being delegated. This transport will include ADoT IFF the transport for "A" and "B" has included ADoT via DNS records.

5.4.1. Example

No additional configutation is needed, beyond use of authority servers which signal DoT support. The following example assumes the previous DNS records are provisioned:

example.comm NS ns1.example.net.
example.comm NS ns2.example.net.

In this example, ns1 does not have ADoT support (since the DNS record excludes the "alpn=dot" parameter), while ns2 does support ADoT (since it includes "alpn=dot").

6. Validation Using DS Records, DNS Records, TLSA Records, and DNSSEC Validation

These records are used to validate corresponding delegation records, DNS records, and TLSA records, as follows:

6.1. Complete Example

Suppose a client requests resolution for the IP address of "sensitive-name.example.com". Suppose the client's resolver has a "cold" cache without any entries beyond the standard Root Zone and relevant TLD name server records.

Suppose the following entries are present at their respective TLD authority servers, delegating to the respective authority servers:

FIXME

7. Signaling Support and Desire for ADoT

The following presume some new OPT sub-types, to be added to the IANA action section or to be split out as separate drafts. The sub-type mnemonics are "ADOTA" (available) and "ADOTD" (desired), each with an enumerated set of values and mnemonic codes. Respectively those are: "Always", "Upon Request", and "Never"; and "Force", "If Available", and "Never".

7.1. Server Side Support Signaling

A DNS server (e.g. recursive resolver or forwarder) MAY signal to clients that it offers the use of ADoT. The mechanism used is to set the EDNS option "ADOTA". The values for this option are "Always", "Upon Request", and "Never". The value "Always" indicates the server will always attempt to use ADoT without regards to client requests for ADoT. The value "Upon Request" indicates that the server will ONLY use ADoT for upstream queries if the client requests that ADoT be used. These values have no effect on answers served from the resolver's cache. (The "Never" case is unusual, in that it signals the server understands the option, but does not perform ADoT. Generally this would be used to allow a client to track changes in the status, if the client is interested in uses of ADoT.)

7.2. Client Side Desire Signaling

A DNS client (e.g. stub or forwarder) MAY signal the desire to have the resolver use ADoT. The mechanism used is to set the EDNS option "ADOTD". The values for this option are "Force", "If Available", and "Never". The value "Force" indicates the server should attempt to use ADoT, and return a failure code of XXXX and an EDE value of YYYY if the authoritative server does not offer ADoT, or any other ADoT failure occurs. The value "If Available" indicates that the server should use ADoT for upstream queries if it is availble, but SHOULD NOT allow any downgrades if the authoritative server signals that ADoT is available. These values have no effect on answers served from the resolver's cache. (The "Never" case is unusual, in that it signals the client understands the option, but does not perform ADoT. Generally this would be used to allow a server to track changes in the client base, so the server operator can make informed decisions about enabling ADoT.)

8. Security Considerations

As outlined above, there could be security issues in various use cases.

9. IANA Considerations

This document may or many not have any IANA actions. (e.g. if the RRTYPEs, EDNS subtypes, DNSKEY algorithms, etc., are defined in other documents, no IANA actions are needed.)

10. Normative References

[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, , <https://www.rfc-editor.org/info/rfc6698>.
[RFC6761]
Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, , <https://www.rfc-editor.org/info/rfc6761>.
[RFC7218]
Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, , <https://www.rfc-editor.org/info/rfc7218>.
[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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8198]
Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, , <https://www.rfc-editor.org/info/rfc8198>.
[RFC8484]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, , <https://www.rfc-editor.org/info/rfc8484>.

11. Informative References

[I-D.dickson-dnsop-ds-hack]
Dickson, B., "DS Algorithms for Securing NS and Glue", Work in Progress, Internet-Draft, draft-dickson-dnsop-ds-hack-00, , <https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-ds-hack-00>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.

Appendix A. Acknowledgments

Thanks to everyone who helped create the tools that let everyone use Markdown to create Internet Drafts, and the RFC Editor for xml2rfc.

Thanks to Dan York for his Tutorial on using Markdown (specificially mmark) for writing IETF drafts.

Thanks to YOUR NAME HERE for contributions, reviews, etc.

Author's Address

Brian Dickson
GoDaddy