Internet-Draft CoRE DNR March 2024
Lenders, et al. Expires 20 September 2024 [Page]
Constrained RESTful Environments
Intended Status:
M. S. Lenders
TU Dresden
C. Amsüss
T. C. Schmidt
HAW Hamburg
M. Wählisch
TU Dresden & Barkhausen Institut

Discovery of Network-designated CoRE Resolvers


This document specifies solutions to discover DNS resolvers that support encrypted DNS resolution in constrained environments. The discovery is based DNS SVCB records, Router Advertisements, or DHCP. In particular, the proposed specification allows a host to learn DNS over CoAP (DoC) servers, including configurations to use DoC over TLS/DTLS, OSCORE, and EDHOC when resolving names.

About This Document

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

The latest revision of this draft can be found at Status information for this document may be found at

Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (, which is archived at Subscribe at

Source for this draft and an issue tracker can be found at

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

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 20 September 2024.

Table of Contents

1. Introduction

[RFC9461], [RFC9462] and [RFC9463] specify options to discover DNS resolvers that allow for encrypted DNS resolution, using either DNS or, in a local network, Router Advertisements or DHCP. These specifications use Service Binding (SVCB) resource records or Service Parameters (SvcParams) to carry information required for configuration of such resolvers. So far, however, only DNS transfer protocols based on Transport Layer Security (TLS) are supported, namely DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) [RFC8484], and DNS over Dedicated QUIC (DoQ) [RFC9250]. This document discusses and specifies options to discover DNS resolvers in constrained environments, mainly based on DNS over CoAP (DoC) [I-D.ietf-core-dns-over-coap].

DoC provides a solution for encrypted DNS in constrained environments. In such scenarios, the usage of DoT, DoH, DoQ, or similar TLS-based solutions is often not possible. The Constrained Application Protocol (CoAP) [RFC7252], the transfer protocol for DoC, is mostly agnostic to the transport layer, i.e., CoAP can be transported over UDP, TCP, or WebSockets [RFC8323], and even less common transports such as Bluetooth GATT [I-D.amsuess-core-coap-over-gatt] or SMS [lwm2m] are discussed.

CoAP offers three security modes, which would need to be covered by the SvcParams:

To discover a DoC server via Discovery of Designated Resolvers (DDR) [RFC9462] and Discovery of Network-designated Resolvers (DNR) [RFC9463], the SvcParams field needs to convey both transfer protocol and type and parameters of the security parameters. We will specify extensions of SvcParams in this document.

2. Terminology

The terms “DoC server” and “DoC client” are used as defined in [I-D.ietf-core-dns-over-coap].

The terms “constrained node” and "constrained network" are used as defined in [RFC7228].

SvcParams denotes the field in either DNS SVCB/HTTPS records as defined in [RFC9460], or DHCP and RA messages as defined in [RFC9463]. SvcParamKeys are used as defined in [RFC9460].

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. Problem Space

The first and most important question to ask for the discoverability of DoC resolvers is if and what new SvcParamKeys need to be defined.

[RFC9460] defines the “alpn” key, which is used to identify the protocol suite of a service binding using its Application-Layer Protocol Negotiation (ALPN) ID [RFC7301]. While this is useful to identify classic transport layer security, the question is raised if this is needed or even helpful for when there is only object security. There is an ALPN ID for CoAP over TLS that was defined in [RFC8323]. As using the same ALPN ID for different transport layers is not recommended, an ALPN for CoAP over UDP is being requested in Section 6. Object security may be selected in addition to transport layer security, so defining an ALPN ID for each combination might not be viable or scalable. For some ways of setting up object security, additional information is needed for the establishment of an encryption context and for authentication with an authentication server (AS). Orthogonally to the security mechanism, the transfer protocol needs to be established.

Beyond the SvcParamKeys, there is the question of what the field values of the Encrypted DNS Options defined in [RFC9463] might be with EDHOC or ACE EDHOC. While most fields map, “authentication-domain-name” (ADN) and its corresponding ADN length field may not matter in ACE driven cases.

Out of scope of this document are related issues adjacent to its problem space. they are listed both for conceptual delimitation, and to aid in discussion of more comprehensive solutions:

4. Solution Sketches

To answer the raised questions, we first look at the general case then 4 base scenarios, from which other scenarios might be a combination of:

In the general case, we mostly need to answer the question for additional SvcParamKeys. [RFC9460] defines the keys “mandatory”, “alpn”, “no-default-alpn”, “port”, “ipv4hint”, and “ipv6hint” were defined. Additionally, [RFC9461] defines “dohpath” which carries the URI template for the DNS resource at the DoH server in relative form.

For DoC, the DNS resource needs to be identified as, so a corresponding “docpath” key should be provided that provides either a relative URI or CRI [I-D.ietf-core-href]. Since the URI-Path option in CoAP may be omitted (defaulting to the root path), this could also be done for the “docpath”.

4.1. Unencrypted DoC

While unencrypted DoC is not recommended by [I-D.ietf-core-dns-over-coap] and might not even be viable using DDR/DNR, it provides additional benefits not provided by classic unencrypted DNS over UDP, such as segmentation block-wise transfer [RFC7959]. However, it provides the simplest DoC configuration and thus is here discussed.

At minimum for a DoC server a way to identify the following keys are required. “docpath” (see above), an optional “port” (see [RFC9460]), the IP address (either with an optional “ipv6hint”/“ipv4hint” or the respective IP address field in [RFC9463]), and a yet to be defined SvcParamKey for the CoAP transfer protocol, e.g., “coaptransfer”. The latter can be used to identify the service binding as a CoAP service binding.

The “authenticator-domain-name” field should remain empty as it does not serve a purpose without encryption.

See this example for the possible values of a DNR option:

authenticator-domain-name: ""
ipv6-address: <DoC server address>
 - coaptransfer="tcp"
 - docpath="/dns"
 - port=61616

4.2. DoC over TLS/DTLS

In addition to the SvcParamKeys proposed in Section 4.1, this scenario needs the “alpn” key. While there is a “coap” ALPN ID defined, it only identifies CoAP over TLS [RFC8323]. As such, a new ALPN ID for CoAP over DTLS is required.

See this example for the possible values of a DNR option:

authenticator-domain-name: ""
ipv6-address: <DoC server address>
 - alpn="co"
 - docpath="/dns"

Note that “coaptransfer” is not needed, as it is implied by the ALPN ID; thus, no values for it would be allocated for transfer protocols that use transport security.

4.3. DoC over OSCORE using EDHOC

While the “alpn” SvcParamKey is needed for the transport layer security (see Section 4.2), we can implement a CA-style authentication with EDHOC when using object security with OSCORE using the authenticator-domain-name field.

A new key SvcParamKey “objectsecurity” identifies the type of object security, using the value "edhoc" in this scenario.

See this example for the possible values of a DNR option:

authenticator-domain-name: ""
ipv6-address: <DoC server address>
 - coaptransfer="udp",
 - objectsecurity="edhoc",
 - docpath="/dns",
 - port=61616

The use of objectsecurity="edhoc" with an authenticator-domain-name and no further ACE details indicates that the client can use CA based authentication of the server.

4.4. DoC over ACE-OSCORE

Using ACE, we require an OAuth context to authenticate the server in addition to the “objectsecurity” key. We propose three keys “oauth-aud” for the audience, “oauth-scope” for the OAuth scope, and “auth-as” for the authentication server. “oauth-aud” should be the valid domain name of the DoC server, “oauth-scope” a list of identifiers for the scope, and “oauth-as” a valid URI or CRI.

TBD: should oauth-scope be expressed at all?

Since authentication is done over OAuth and not CA-style, the “authenticator-domain-name” is not needed. There might be merit, however, to use it instead of the “oauth-aud” SvcParamKey.

See this example for the possible values of a DNR option:

authenticator-domain-name: ""
ipv6-address: <DoC server address>
 - coaptransfer="tcp"
 - objectsecurity="edhoc" /* TBD: or ace-edhoc? */
 - docpath="/dns",
 - port=61616,
 - oauth-aud="",
 - oauth-scope="resolve DNS"
 - oauth-as="coap://"

5. Security Considerations

TODO Security

6. IANA Considerations

6.1. TLS ALPN for CoAP

The following entry has been added to the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry, which is part of the "Transport Layer Security (TLS) Extensions" group.

  • Protocol: CoAP (over DTLS)

  • Identification sequence: 0x63 0x6f ("co")

  • Reference: [RFC7252] and [this document]

Note that [RFC7252] does not prescribe the use of the ALPN TLS extension during connection the DTLS handshake. This document does not change that, and thus does not establish any rules like those in Section 8.2 of [RFC8323].

7. References

7.1. Normative References

Lenders, M. S., Amsüss, C., Gündoğan, C., Schmidt, T. C., and M. Wählisch, "DNS over CoAP (DoC)", Work in Progress, Internet-Draft, draft-ietf-core-dns-over-coap-06, , <>.
Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and G. Selander, "Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE)", Work in Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-10, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, , <>.
Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, , <>.
Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, , <>.
Schwartz, B., "Service Binding Mapping for DNS Servers", RFC 9461, DOI 10.17487/RFC9461, , <>.
Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, "Discovery of Designated Resolvers", RFC 9462, DOI 10.17487/RFC9462, , <>.
Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., and T. Jensen, "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", RFC 9463, DOI 10.17487/RFC9463, , <>.

7.2. Informative References

Amsüss, C., "CoAP over GATT (Bluetooth Low Energy Generic Attributes)", Work in Progress, Internet-Draft, draft-amsuess-core-coap-over-gatt-06, , <>.
Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund, "Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-edhoc-oscore-profile-04, , <>.
Bormann, C. and H. Birkholz, "Constrained Resource Identifiers", Work in Progress, Internet-Draft, draft-ietf-core-href-14, , <>.
Amsüss, C. and M. S. Lenders, "CoAP Transport Indication", Work in Progress, Internet-Draft, draft-ietf-core-transport-indication-05, , <>.
OMA SpecWorks, "White Paper – Lightweight M2M 1.1", , <>.
Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, , <>.
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, , <>.
Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, , <>.
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, , <>.
Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, , <>.
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9203, DOI 10.17487/RFC9203, , <>.
Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, , <>.

Appendix A. Change Log

A.1. Since draft-lenders-core-dnr-00

  • IANA has processed the "co" ALPN and it is now added to the registry


TODO acknowledge.

Authors' Addresses

Martine Sophie Lenders
TUD Dresden University of Technology
Helmholtzstr. 10
D-01069 Dresden
Christian Amsüss
Thomas C. Schmidt
HAW Hamburg
Matthias Wählisch
TUD Dresden University of Technology & Barkhausen Institut
Helmholtzstr. 10
D-01069 Dresden