Internet-Draft DS Glue August 2021
Schwartz Expires 7 February 2022 [Page]
Workgroup:
dprive
Internet-Draft:
draft-schwartz-ds-glue-00
Published:
Intended Status:
Standards Track
Expires:
Author:
B. Schwartz
Google LLC

Authenticated delegation information using DS records

Abstract

This draft describes a mechanism for conveying arbitrary authenticated DNS data from a parent nameserver to a recursive resolver as part of a delegation response.

Discussion Venues

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

Discussion of this document takes place on the mailing list (ds@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ds/.

Source for this draft and an issue tracker can be found at https://github.com/bemasc/ds-glue.

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 7 February 2022.

Table of Contents

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

2. Background

The DPRIVE working group has been pursuing designs for authenticated encryption of recursive-to-authoritative communication. Recursive resolvers could enable authenticated encryption most easily and efficiently if they received authenticated information about the target nameserver's configuration during the in-bailiwick delegation that precedes the direct connection. However, there are several obstacles to this.

2.1. Obstacle 1: Authentication

Glue records in DNS referral responses are unauthenticated. Parents do not generally provide RRSIGs for these records in their responses, and resolvers do not expect such signatures to be present. An in-path attacker can modify or remove records in the delegation response without detection.

If the parent zone also implements authenticated encryption, this provides sufficient protection for the glue records, but many important parent zones seem unlikely to implement authenticated encryption in the near future.

2.2. Obstacle 2: Flexibility

Existing nameserver deployments assume that the delegation response includes only a fixed set of existing RR types (NS, A, AAAA, DS, RRSIG, etc.). These systems are slow to upgrade, and the working group would like to be able to begin deploying authenticated encryption without first requiring a significant change in these parents.

3. Proposal

This draft proposes a way to convey glue RRs in DS records, enabling authenticated delivery of arbitrary RR types as part of the delegation response.

There are three main records involved in this process:

3.1. Encoding

To encode a Source Record, a zone operator first transforms it into a Virtual DNSKEY Record as follows:

  • Owner Name = The Owner Name of the Source Record relative to the child zone apex.
  • Flags = 0x0001, i.e. only SEP (bit 15) is set.
  • Protocol = 3
  • Algorithm = DS Glue (see IANA registration in Section 7)
  • Public Key = The RR type and canonicalized RDATA of the Source Record ([RFC4034], Section 6.2).

For example, these Source Records:

$ORIGIN example.com.
@ 3600 IN NS ns1
       IN NS ns2
       IN NS NS.OTHER.EXAMPLE.

would be represented as the following Virtual DNSKEY Records:

; Public Key = \000\002 \003ns1\007example\003com\000
. 300 IN DNSKEY 1 3 $DSGLUE_NUM AAIDbnMxB2V4YW1wbGUDY29tAA==
; Public Key = \000\002 \003ns2\007example\003com\000
. 300 IN DNSKEY 1 3 $DSGLUE_NUM AAIDbnMyB2V4YW1wbGUDY29tAA==
; Public Key = \000\002 \002ns\005other\007example\000
. 300 IN DNSKEY 1 3 $DSGLUE_NUM AAICbnMFb3RoZXIHZXhhbXBsZQA=

Note that:

  • The NS Source Records are "real" records that appear in authoritative Answers and/or delegation glue, but the DNSKEY records are "virtual records" because they do not appear in any zone or response (in this form).
  • The Virtual DNSKEY Records' owner name is "." because the Source Records appear at the zone apex.
  • The NS RDATA has been converted to lowercase as specified by the canonicalization algorithm.

Having constructed a Virtual DNSKEY Record, the DSGLUE Record is constructed as usual, but always using the VERBATIM digest type [I-D.draft-vandijk-dnsop-ds-digest-verbatim]. Thus, the DSGLUE Record's wire format RDATA forms the following concatenation:

Key Tag | Algorithm = DSGLUE | Digest Type = VERBATIM | Digest = (
  DNSKEY owner name = name prefix | DNSKEY RDATA = (
    Flags = 1 | Protocol = 3 | Algorithm = DSGLUE | Public Key = (
      RR Type | RDATA
    )
  )
)

The DSGLUE record is a real DS record that appears in the usual DS RRSet, whose owner name is the child apex.

  • QUESTION: Should we skip the virtual DNSKEY record, and construct the fake DS directly? This would save 4-6 bytes per RR, but would lose the ability to reuse DNSKEY->DS construction codepaths (unchanged except for a new digest type).

3.2. Interpretation

Upon receiving the DS RRSet, the recipient will first verify the DS RRSIGs as normal, and abort the resolution as Bogus if DNSSEC validation fails.

Resolvers implementing this specification SHALL reverse the encoding process of any DSGLUE records to reconstruct the source RRSets, all carrying the TTL of the DS RRSet. The resolver SHALL add each of these reconstructed RRSets to the delegation responses, replacing any RRSet with the same owner name and type. Resolution then proceeds as normal.

Resolvers that do not implement this specification will ignore the DSGLUE records due to the unrecognized algorithm. Thus, these records are safe to use for both signed and unsigned child zones.

As with ordinary glue records, Source Records reconstructed from DSGLUE MAY be cached for use in future delegations, but MUST NOT be returned in any responses.

3.3. Special case: RR Type = NSEC or NSEC3

Normally, the absence of a particular record in a delegation response is not informative to a resolver. The corresponding record might still exist in the child zone. To inform the resolver that a particular RRSet is nonexistent for the purposes of delegation, the zone owner MAY place an NSEC or NSEC3 record in the delegation response.

As with other glue records, an NSEC glue record only affects behavior during delegation following (see example in Section 4.3).

4. Examples

For these examples, the macro $DSGLUE(prefix, source RR type, source RDATA) constructs a DSGLUE DS record as described in Section 3.1.

4.1. Out-of-bailiwick referral

An out-of-bailiwick referral contains only NS records, e.g.

$ORIGIN com.
example 3600 IN NS ns1.example.net.
             IN NS ns2.example.net.

These Source Records would be encoded in DSGLUE as:

$ORIGIN com.
example 3600 IN DS $DSGLUE(., NS, ns1.example.net.)
             IN DS $DSGLUE(., NS, ns2.example.net.)

4.2. In-bailiwick referral

An in-bailiwick referral contains NS records and at least one kind of address record.

$ORIGIN com.
example    3600 IN NS    ns1.example
                IN NS    ns2.example
ns1.example 600 IN A     192.0.2.1
                IN AAAA  2001:db8::1
ns2.example 600 IN A     192.0.2.2
                IN AAAA  2001:db8::2

These records would be encoded in DSGLUE as:

$ORIGIN com.
example 600 IN DS $DSGLUE(., NS, ns1.example.com.)
            IN DS $DSGLUE(., NS, ns2.example.com.)
            IN DS $DSGLUE(ns1., A, 192.0.2.1)
            IN DS $DSGLUE(ns1., AAAA, 2001:db8::1)
            IN DS $DSGLUE(ns2., A, 192.0.2.1)
            IN DS $DSGLUE(ns2., AAAA, 2001:db8::2)

Note that the differing TTL between RRSets is lost.

4.3. In-bailiwick referral without IPv4

Consider a delegation to a nameserver that is only reachable with IPv6:

$ORIGIN com.
example    3600 IN NS    ns1.example
ns1.example 600 IN AAAA  2001:db8::1

A zone in this configuration can optionally use an NSEC DSGLUE record to indicate that there is no IPv4 address:

$ORIGIN com.
example 600 IN DS $DSGLUE(., NS, ns1.example.com.)
            IN DS $DSGLUE(ns1., AAAA, 2001:db8::1)
            IN DS $DSGLUE(*., NSEC, *.example.com. A SVCB)

This arrangement prevents an adversary from inserting their own A or SVCB records into the delegation response.

Note that although this NSEC record denies the existence of any A records in *.example.com, it is treated as a glue record that only applies during delegation, so such records can still be resolved if they exist.

4.4. Delegation with authenticated encryption

Assuming a SVCB-based signaling mechanism similar to [I-D.draft-schwartz-svcb-dns], an in-bailiwick referral with support for authenticated encryption is indicated as follows:

$ORIGIN com.
example 600 IN DS $DSGLUE(., NS, ns1.example.com.)
            IN DS $DSGLUE(ns1., A, 192.0.2.1)
            IN DS $DSGLUE(ns1., AAAA, 2001:db8::1)
            IN DS $DSGLUE(_dns.ns1., SVCB,
                          1 ns1.example.com. alpn=dot)

4.4.1. Disabling DANE

Resolvers check whether a nameserver supports DANE by resolving a TLSA record during the delegation process. However, this adds unnecessary latency to the delegation if the nameserver does not implement DANE. As an optimization, such nameservers can add an NSEC record to indicate that there is no such TLSA record:

IN DS $DSGLUE(*._tcp., NSEC, *._tcp.ns1.example.com. TLSA)

5. Security Considerations

Resolvers that process DSGLUE MUST perform DNSSEC validation.

Source Records published as DSGLUE have owner names within the child zone, but are signed only by the parent. This makes them fully authenticated, but provides different cryptographic guarantees than a direct signature by the child. For example, these records might not appear in any key use logs maintained by the child.

6. Operational Considerations

6.1. Publishing DSGLUE records

In order for the child to publish DSGLUE records, the parent must allow the child to publish arbitrary DS records or have specific support for this specification.

If the parent supports CDS [RFC8078], child zones MAY use CDS to push DSGLUE records into the parent. Note that CDNSKEY records cannot be used, because (1) the child cannot publish CDNSKEY records with the required owner name and (2) the child cannot guarantee that the parent will use the VERBATIM digest to produce the DS record.

Child zones SHOULD publish all Source Records as ordinary records of the specified type at the indicated owner name, in order to enable revalidation [I-D.draft-ietf-dnsop-ns-revalidation] and simplify debugging.

6.2. Referral response size

When records are present in both ordinary glue and DSGLUE, the response size is approximately doubled. This could cause performance issues due to response truncation when the initial query is over UDP.

6.3. PKI and DANE for Authenticated Encryption

  • TODO: Move some of this text into a different draft.

Nameservers supporting authenticated encryption MAY indicate any DANE mode, or none at all.

As an optimization, nameservers using DANE MAY place a TLSA record in the DSGLUE to avoid the latency of a TLSA lookup during delegation. However, child zones should be aware that this adds complexity and delay to the process of TLSA key rotation.

Nameservers that do not support DANE SHOULD add an NSEC or NSEC3 record denying the TLSA record to the DSGLUE, as shown in Section 4.4.1, to avoid an unnecessary delay.

Resolvers that support authenticated encryption MAY implement support for PKI-based authentication, DANE, or both. PKI-only resolvers MUST nonetheless resolve TLSA records, and MUST NOT require authentication if the DANE mode is DANE-TA(2) or DANE-EE(3) [RFC7671]. DANE-only resolvers MUST NOT require authentication if the TLSA record does not exist.

7. IANA Considerations

IANA is requested to add a new entry to the DNS Security Algorithm Numbers registry:

Table 1
Number Description Mnemonic Zone Signing Trans. Sec. Reference
$DSGLUE_NUM Authenticated Glue DSGLUE N ? (This document)

8. References

8.1. Normative References

[I-D.draft-vandijk-dnsop-ds-digest-verbatim]
Dijk, P. V., "The VERBATIM Digest Algorithm for DS records", Work in Progress, Internet-Draft, draft-vandijk-dnsop-ds-digest-verbatim-00, , <https://datatracker.ietf.org/doc/html/draft-vandijk-dnsop-ds-digest-verbatim-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/rfc/rfc2119>.
[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, , <https://www.rfc-editor.org/rfc/rfc4034>.
[RFC7671]
Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, , <https://www.rfc-editor.org/rfc/rfc7671>.
[RFC8078]
Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, , <https://www.rfc-editor.org/rfc/rfc8078>.
[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/rfc/rfc8174>.

8.2. Informative References

[I-D.draft-ietf-dnsop-ns-revalidation]
Huque, S., Vixie, P., and R. Dolmans, "Delegation Revalidation by DNS Resolvers", Work in Progress, Internet-Draft, draft-ietf-dnsop-ns-revalidation-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation-01>.
[I-D.draft-schwartz-svcb-dns]
Schwartz, B., "Service Binding Mapping for DNS Servers", Work in Progress, Internet-Draft, draft-schwartz-svcb-dns-04, , <https://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns-04>.

Acknowledgments

Thanks to Paul Hoffman for detailed comments.

Author's Address

Benjamin Schwartz
Google LLC