wdiff draft-btw-add-ipsecme-ike-00.txt draft-btw-add-ipsecme-ike-01.txt

ADD M. Boucadair
Internet-Draft Orange
Intended status: Standards Track T. Reddy
Expires: October 9, 2020 March 13, 2021 McAfee
D. Wing
Citrix
V. Smyslov
ELVIS-PLUS
April 7,
September 9, 2020

Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for
Encrypted DNS
draft-btw-add-ipsecme-ike-00
draft-btw-add-ipsecme-ike-01

Abstract

This document specifies a new Internet Key Exchange Protocol Version
2 (IKEv2) Configuration Payload Attribute Type Types for encrypted DNS such
as
with a focus on DNS-over-HTTPS (DoH) and (DoH), DNS-over-TLS (DoT). (DoT), and DNS-
over-QUIC (DoQ).

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 October 9, 2020. March 13, 2021.

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Sample Deployment Scenarios . . . . . . . . . . . . . . . . . 3
3.1. Roaming Enterprise Users . . . . . . . . . . . . . . . . 3
3.2. VPN Service Provider . . . . . . . . . . . . . . . . . . 4
3.3. DNS Offload . . . . . . . . . . . . . . . . . . . . . . . 4
4. INTERNAL_ENC_DNS IKEv2 Configuration Payload Attribute . . . . . . . . . . . . . . . . . Types for Encrypted DNS 4
5. URI Template IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 6
6. URI Template . . . . . 6
6. IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . . 6 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. Configuration Payload Attribute Type . . . . . . . . . . 8
8.2. Encrypted DNS Types . . . . . . . . . . . . . . . . . . . 9 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11

1. Introduction

This document specifies encrypted DNS configuration for an IKE Internet
Key Exchange Protocol Version 2 (IKEv2) [RFC7296] initiator,
particularly the Authentication Domain Name (ADN, defined in
[RFC8310]) of DNS-over-HTTPS (DoH) [RFC8484] or [RFC8484], DNS-over-TLS (DoT)
[RFC7858] server using Internet Key Exchange Protocol Version 2
(IKEv2) [RFC7296].

Particularly, this
[RFC7858], or DNS-over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic].

This document introduces a new IKEv2 Configuration Payload Attribute
Types (Section 4) for the support of encrypted DNS
servers (e.g., DoT, DoH). DoH, and DoQ DNS servers.

This document targets the deployments discussed in Section 3.3 of
[I-D.box-add-requirements]. Sample use cases are discussed in
Section 3. The Configuration Payload Attribute Type Types defined in Section 4 is this
document are not specific to these deployments, but can also be used
in other deployment contexts.

Note that, for many years, typical designs has have often considered that
the DNS server was usually located inside the protected domain, but
could theoretically be located outside of it. With DoH or DoH, DoT, or DoQ the latter
option becomes plausible.

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

This document makes use of the terms defined in [RFC8499] and
[I-D.ietf-dnsop-terminology-ter].

Also, this document makes use of the terms defined in [RFC7296]. In
particular, readers should be familiar with "initiator" and
"responder" terms used in that document.

Do53 refers to unencrypted DNS.

'DoH/DoT'

Encrypted DNS refers to DNS-over-HTTPS and/or DNS-over-TLS. as scheme where DNS messages are sent over an
encrypted channel. Examples of encrypted DNS are DoT, DoH, and DoQ.

ENCDNS_IP*_* refers to any IKEv2 Configuration Payload Attribute
Types defined in Section 4.

ENCDNS_IP4_* refers to an IKEv2 Configuration Payload Attribute Type
that carries one or multiple IPv4 addresses of an encrypted DNS
server.

ENCDNS_IP6_* refers to an IKEv2 Configuration Payload Attribute Type
that carries one or multiple IPv6 addresses of an encrypted DNS
server.

3. Sample Deployment Scenarios

3.1. Roaming Enterprise Users

In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming
user connects to the Enterprise network through an IPsec tunnel. The
split-tunnel Virtual Private Network (VPN) configuration allows the
endpoint to access hosts that resides in the Enterprise network
[RFC8598] using that tunnel; other traffic not destined to the
Enterprise does not traverse the tunnel. In contrast, a non-split-
tunnel VPN configuration causes all traffic to traverse the tunnel
into the enterprise.

For both split- and non-split-tunnel configurations, the use of DoT/
DoH
encrypted DNS instead of Do53 provides privacy and integrity
protection along the entire path (rather than just to the VPN
termination device) and can communicate the DoT/DoH encrypted DNS server
policies.

For split-tunnel VPN configurations, the endpoint uses the
Enterprise-provided DoT/DoH encrypted DNS server to resolve internal-only
domain names.

For non-split-tunnel VPN configurations, the endpoint uses the
Enterprise-provided DoT/DoH encrypted DNS server to resolve both internal and
external domain names.

Enterprise networks are susceptible to internal and external attacks.
To minimize that risk all enterprise traffic is encrypted
(Section 2.1 of [I-D.arkko-farrell-arch-model-t]).

3.2. VPN Service Provider

Legacy VPN service providers usually preserve end-users' data
confidentiality by sending all communication traffic through an
encrypted tunnel. A VPN service provider can also provide guarantees
about the security of the VPN network by filtering malware and
phishing domains.

Browsers and OSes support DoH/DoT; VPN providers may no longer expect
DNS clients to fallback to Do53 just because it is a closed network.

The DoT/DoH encrypted DNS server hosted by the VPN service provider can be
securely discovered by the endpoint using the IKEv2 Configuration
Payload Attribute Type.

3.3. DNS Offload

VPN service providers typically allow split-tunnel VPN configuration
in which users can choose applications that can be excluded from the
tunnel. For example, users may exclude applications that restrict
VPN access.

VPN service providers can also offer publicly accessible DoH/DoT
servers.

The split-tunnel VPN configuration allows the client to
access the DoH/DoT servers hosted by the VPN provider without
traversing the tunnel.

The DoT/DoH encrypted DNS server hosted by the VPN service provider can be
securely discovered by the endpoint using the IKEv2 Configuration
Payload Attribute Type.

4. INTERNAL_ENC_DNS IKEv2 Configuration Payload Attribute Types for Encrypted DNS

The INTERNAL_ENC_DNS ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Type is Types are used
to configure an encrypted a DoT, DoH, or DoQ DNS server. The All these attributes
share the format of this
attribute is shown in Figure 1.

1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-----------------------------+-------------------------------+
|R| Attribute Type | Length |
+-+-------------+---------------+-------------------------------+
|S|Enc DNS Type
+-+-----------------------------+---------------+---------------+
| Port Number | RESERVED | Num addresses Addresses |
+-------------------------------+---------------+---------------+
|
+-+-------------+---------------+ + | IPv6 Addresses
~
| +-------------------------------+ IP Addresses ~
| |
+-------------------------------+ |
+---------------------------------------------------------------+
| |
~ DNS Authentication Domain Name ~
| |
+---------------------------------------------------------------+

Figure 1: INTERNAL_ENC_DNS Attribute Attributes Format

The fields of the attribute shown in Figure 1 are as follows:

o R: Reserved bit; refer R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be
ignored on receipt (see Section 3.15.1 of [RFC7296]. [RFC7296] for details).

o Attribute Type: MUST be Type (15 bits) - Identifier for Configuration Attribute
Type; is set to TBA (Section 8.1). one of the values listed in Section 8.1.

o Length: Length (2 octets, unsigned integer) - Length of the data in
octets. It MUST be In particular, this field is set to 1 to:

* 0 if the Configuration payload has types CFG_REQUEST or CFG_ACK or to
CFG_ACK.

* (2 + Length of the ADN + N * 16) 4) for ENCDNS_IP4_* attributes if
the Configuration payload of a has types CFG_REPLY or CFG_SET;
N being the number of included IP IPv4 addresses ('Num
addresses').

o S: Scope bit. This bit controls whether

* (2 + Length of the DNS queries are sent
within ADN + N * 16) for ENCDNS_IP6_* attributes if
the tunnel Configuration payload has types CFG_REPLY or outside. If set, this bit instructs the
initiator to send encrypted DNS queries outside the tunnel. If
the bit is unset, the queries are sent inside CFG_SET; N
being the tunnel. The
default value number of this bit is "0". included IPv6 addresses ('Num addresses').

o Encrypted DNS Type: Port Number (2 octets, unsigned integer) - Indicates the type of port
number to be used for the encrypted DNS server
conveyed in this attribute. The following values are defined:

0: Reserved

1: DNS. As a reminder, the
default port number is 853 for DoT

2: DoH

See Section 8.2 and 443 for DoH.

o RESERVED (1 octet) - These bits are reserved for future assignment considerations. use.
These bits MUST be set to zero by the sender and MUST be ignored
by the receiver.

o Num addresses: If Length > 1, it indicates Addresses (1 octet) - Indicates the number of enclosed
IP IPv4
(for ENCDNS_IP4_* attribute types) or IPv6 (for ENCDNS_IP6_*
attribute types) addresses.

o IPv6 Address(es): IP Address(es) (variable) - One or more IPv4 or IPv6 addresses to
be used to reach the encrypted DNS identified by the name in the
DNS Authentication Domain Name.

IPv4 addresses MUST be encoded using the IPv4-Mapped IPv6 Address
format defined in [RFC4291].

o Authentication Domain Name: Name (variable) - A fully qualified domain
name of the
DoT (or DoH) DoT, DoH, or DoQ DNS server following the syntax
defined in [RFC5890]. The name MUST NOT contain any terminators
(e.g., NULL, CR).

An example of valid ADN for DoH server is "doh1.example.com".

5. URI Template

DoH servers may support more than one URI Template [RFC8484]. The
following sub-sections discuss some candidate solutions for a DoH
client to retrieve the list of supported templates by a DoH server.
Also, if the resolver hosts several DoH services (e.g., no-filtering,
blocking adult content, blocking malware), these services can be
discovered as templates.

This section will be updated to reflect the outcome of the discussion
in [I-D.btw-add-home].

How a DoH client makes use of the configured DoH services is out of
the scope of this document.

6. IKEv2 Protocol Exchange

This section describes how an initiator can be configured with an
encrypted DNS server (e.g., DoH, DoT) using IKEv2.

Initiators indicate the support of an encrypted DNS in the
CFG_REQUEST payloads by including INTERNAL_ENC_DNS attribute, one or multiple ENCDNS_IP*_*
attributes, while responders supply the encrypted DNS configuration
in the CFG_REPLY payloads. Concretely:

If the initiator supports encrypted DNS, it includes one or more
INTERNAL_ENC_DNS
ENCDNS_IP*_* attributes in the CFG_REQUEST with the "Encrypted
DNS "Attribute
Type" set to the requested encrypted DNS type (Section 4). For
each supported encrypted DNS type the initiator MUST include
exactly one INTERNAL_ENC_DNS attribute with the Length field set to 1.

If an INTERNAL_ENC_DNS attribute 0, so that no
data is included in the CFG_REQUEST,
the INTERNAL_ENC_DNS attribute MUST NOT include an ADN and list of
IP addresses. for these attributes.

For each INTERNAL_ENC_DNS ENCDNS_IP*_* attribute from the CFG_REQUEST, if the
responder supports the corresponding encrypted DNS type, then it
MAY send and
absent any policy, the responder sends back an INTERNAL_ENC_DNS ENCDNS_IP*_*
attribute in the CFG_REPLY with this encrypted DNS type and an
appropriate list of IP addresses addresses, a port number, and an ADN. The
list of IP addresses MUST NOT be empty. Multiple instances of the
same ENCDNS_IP*_* attribute MAY be returned if distinct ADNs (or
port numbers) are to be returned by the responder.

If the CFG_REQUEST includes an INTERNAL_ENC_DNS ENCDNS_IP*_* attribute but the
CFG_REPLY does not include an INTERNAL_ENC_DNS, ENCDNS_IP*_* matching the requested
encrypted DNS type, this is an indication that requested encrypted
DNS type(s) is not supported by the responder. responder or the responder is
not configured to provide corresponding server addresses.

The behavior of the responder if it receives both INTERNAL_ENC_DNS ENCDNS_IP*_* and
INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-
based policy-based
and deployment-specific. However, it is RECOMMENDED that if the
responder includes at least one INTERNAL_ENC_DNS ENCDNS_IP*_* attribute in the
reply, it should not include any of INTERNAL_IP4_DNS/
INTERNAL_IP6_DNS attributes.

The DNS client establishes a DoH/DoT an encrypted DNS session (e.g., DoT, DoH,
DoQ) with the address(es) conveyed in INTERNAL_ENC_DNS ENCDNS_IP*_* and uses the
mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS
server certificate using the authentication domain name conveyed in INTERNAL_ENC_DNS.
ENCDNS_IP*_*.

If the IPsec connection is a split-tunnel configuration and the
initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS
client MUST resolve the internal names using INTERNAL_ENC_DNS ENCDNS_IP*_* DNS
servers.

Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS)
attribute to be mandatory present when INTERNAL_DNS_DOMAIN is
included. This specification relaxes that constraint in the
presence of INTERNAL_ENC_DNS attribute. ENCDNS_IP*_* attributes.

6. URI Template

DoH servers may support more than one URI Template [RFC8484]. Also,
if the resolver hosts several DoH services (e.g., no-filtering,
blocking adult content, blocking malware), these services can be
discovered as templates.

Upon discovery of a DoH resolver (Section 5), the DoH client contacts
that DoH resolver to retrieve the list of supported DoH services
using the well-known URI defined in
[I-D.btw-add-rfc8484-clarification]. DoH clients re-iterates that
request regularly to retrieve an updated list of supported DoH
services.

How a DoH client makes use of the configured DoH services is out of
the scope of this document.

7. Security Considerations

This document adheres to the security considerations defined in
[RFC7296]. In particular, this document does not alter the trust on
the DNS configuration provided by a responder.

Networks are susceptible to internal attacks as discussed in
Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting DoH/DoT encrypted
DNS server even in case of split-VPN configuration minimizes the
attack vector (e.g., a compromised network device cannot monitor/modify monitor/
modify DNS traffic). This specification describes a mechanism to
restrict access to the DNS messages to only the parties that need to
know.

In most deployment scenarios, the initiator expects that it is using
the DoH/DoT encrypted DNS server hosted by a specific organization or
enterprise. The DNS client can validate the signatory (i.e.,
cryptographically attested by the organization hosting the DoH/DoT encrypted
DNS server) using, for example,
[I-D.reddy-add-server-policy-selection], and the user can review
human-readable privacy policy information of the DNS server and
assess whether the DNS server performs DNS-based content filtering.
This helps to protect from a compromised IKE server advertising a
malicious DoH/DoT encrypted DNS server.

The initiator may trust the DoH/DoT encrypted DNS servers supplied by means
of IKEv2 from a trusted responder more than the locally provided DNS
servers, especially in the case of connecting to unknown or untrusted
networks (e.g., coffee shops or hotel networks). In addition, the
initiator may prefer IKEv2-supplied DoH/DoT servers if they provide
additional features (e.g., malware filtering) compared to the pre-
configured DNS servers and meets the privacy preserving data policy
requirements of the user.

If the DoH/DoT encrypted DNS server that was discovered by means of IKEv2
does not meet the privacy preserving data policy and filtering
requirements of the user, the user can instruct the DNS client to
take appropriate actions. For example, the action can be to use the
local DoH/DoT encrypted DNS server only to access internal-only DNS names and
use another DNS server (that addresses his/her expectations) for
public domains. Such actions and their handling is out of scope.

If IKEv2 is being negotiated with an anonymous or unknown endpoint
(such as for Opportunistic Security [RFC7435]), responder has used NULL Authentication method [RFC7619] to
authenticate itself, the initiator MUST NOT use INTERNAL_ENC_DNS returned ENCDNS_IP*_*
servers configuration unless it is pre-configured in the OS or the
browser.

This specification does not extend the scope of accepting DNSSEC
trust anchors beyond the usage guidelines defined in Section 6 of
[RFC8598].

8. IANA Considerations

8.1. Configuration Payload Attribute Type Types

This document requests IANA to assign the following new IKEv2
Configuration Payload Attribute Types from the "IKEv2 Configuration
Payload Attribute Types" namespace available at
https://www.iana.org/assignments/ikev2-parameters/
ikev2-parameters.xhtml#ikev2-parameters-21.

Multi-
Value Attribute Type Valued Length Reference
------ ------------------- ------ ---------- ------------
TBA INTERNAL_ENC_DNS
TBA1 ENCDNS_IP4_DOT YES 1 0 or more RFC XXXX

8.2. Encrypted DNS Types

This document requests IANA to create a new registry called
"Encrypted DNS Types" under "Internet Key Exchange Version 2 (IKEv2)
Parameters" available at https://www.iana.org/assignments/ikev2-
parameters/ikev2-parameters.xhtml#ikev2-parameters-21. The initial
values of the registry is as follows:

New values are assigned on a First Come, First Served (FCFS) basis
(Section 4.4 of [RFC8126]).

9. Acknowledgements

Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy
Pauly for the review and comments.

Yoav and Paul suggested the use of one single attribute carrying both
the name and an IP address instead of depending on the existing
INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes.

Christian Huitema suiggested to return a port number in the
attributes.

10. References

10.1. Normative References

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

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.

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

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

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

[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>.

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

10.2. Informative References

[I-D.arkko-farrell-arch-model-t]
Arkko, J. and S. Farrell, "Challenges and Changes in the
Internet Threat Model", draft-arkko-farrell-arch-model-
t-03
t-04 (work in progress), March July 2020.

[I-D.box-add-requirements]
Box, C., Pauly, T., Wood, C., and T. Reddy.K,
"Requirements for Adaptive DNS Discovery", draft-box-add-
requirements-00 (work in progress), September 2020.

[I-D.btw-add-home]

[I-D.btw-add-rfc8484-clarification]
Boucadair, M., Cook, N., Reddy.K, T., Wing, D., and N. Cook, "DNS-
over-HTTPS and DNS-over-TLS Server Discovery and
Deployment Considerations D. Wing,
"Supporting Redirection for Home and Mobile Networks",
draft-btw-add-home-04 DNS Queries over HTTPS (DoH)",
draft-btw-add-rfc8484-clarification-02 (work in progress), March
July 2020.

[I-D.ietf-dnsop-terminology-ter]
Hoffman, P., "Terminology for DNS Transports and
Location", draft-ietf-dnsop-terminology-ter-01 draft-ietf-dnsop-terminology-ter-02 (work in
progress), August 2020.

[I-D.ietf-dprive-dnsoquic]
Huitema, C., Mankin, A., and S. Dickinson, "Specification
of DNS over Dedicated QUIC Connections", draft-ietf-
dprive-dnsoquic-00 (work in progress), February April 2020.

[I-D.reddy-add-server-policy-selection]
Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair,
"DNS Server Selection: DNS Server Information with
Assertion Token", draft-reddy-add-server-policy-
selection-00
selection-04 (work in progress), March July 2020.

[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of

[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Time", Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7435, 7619, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>. 10.17487/RFC7619, August 2015,
<https://www.rfc-editor.org/info/rfc7619>.

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

[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.

[RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the
Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8598, DOI 10.17487/RFC8598, May 2019,
<https://www.rfc-editor.org/info/rfc8598>.

Authors' Addresses

Mohamed Boucadair
Orange
Rennes 35000
France

Email: mohamed.boucadair@orange.com

Tirumaleswar Reddy
McAfee, Inc.
Embassy Golf Link Business Park
Bangalore, Karnataka 560071
India

Email: TirumaleswarReddy_Konda@McAfee.com

Dan Wing
Citrix Systems, Inc.
USA

Email: dwing-ietf@fuggles.com

Valery Smyslov
ELVIS-PLUS
RU

Email: svan@elvis.ru