[OCN 5] Clarify requirement and assessment for DoT

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (e).

As confidentiality protection is a fundamental aspect of any VPNs' functionality regardless of use case, the requirements in this clause are extensive. Some of these requirements fall into subcategories; the existence of subcategories is purely informative—applicability is detailed along with each requirement as well as being mapped out at the end of 5.7 just as any other clause.

As confidentiality protection is a fundamental aspect of any VPN’s functionality regardless of use case, the requirements in this clause are extensive. Some of these requirements fall into subcategories; the existence of subcategories is purely informative—applicability is detailed along with each requirement as well as being mapped out at the end of 5.7 just as any other clause.

#### 5.7.1.2 VPN traffic routing (MI-ROUT-1, MI-ROUT-2, MI-ROUT-3, MI-ROUT-4)

From the moment the user activates the VPN connection until the user knowingly deactivates the VPN connection, no network traffic intended for the VPN connection should exit the endpoint via anything other than the VPN connection, whether or not it is functioning.

From the moment the user activates the VPN connection until the user knowingly deactivates the VPN connection, no network traffic intended for the VPN connection should exit the endpoint via anything other than the VPN connection, whether or not the VPN connection is functioning.

Out of scope for routing-related requirements are other software on the user's endpoint with elevated privileges, users with administrator privileges, as well as the operating system itself that could change relevant network configuration (network interfaces, routes, DNS) or circumvent the VPN tunnel due to elevated privileges.

Out of scope for routing-related requirements are other software on the user’s endpoint with elevated privileges, users with administrator privileges, as well as the operating system itself that could change relevant network configuration (network interfaces, routes, DNS) or circumvent the VPN tunnel due to elevated privileges.

#### 5.7.1.3 DNS query leaks (MI-DNSL-1, MI-DNSL-2, MI-DNSL-3, MI-DNSL-5, MI-DNSL-6, MI-DNSL-7)

Special attention to DNS queries is required, because DNS requests are usually transmitted in plaintext and could be eavesdropped on by an attacker on the wire or the DNS server itself and disclose which domains to which the user is trying to connect.

Special attention to DNS queries is required because DNS requests are usually transmitted in plaintext. These requests could be eavesdropped on by an attacker on the wire or the DNS server itself, which could disclose the domains to which the user is trying to connect.

DNS leaks occur if the client does not or only partially tunnels cleartext DNS traffic through the VPN connection. This could either happen due to misconfiguration, system overwrites, or by design for example in case only partial traffic is tunnelled, so-called split tunnelling.

DNS leaks occur if the client does not or only partially tunnels cleartext DNS traffic through the VPN connection. This could either happen due to misconfiguration, system overwrites, or by design—for example in case only partial traffic is tunnelled, so-called split tunnelling.

Further, the user might want to set special DNS configuration either configured by the enterprise or custom configured in a consumer context. The VPN provider then must honour this DNS configuration.

Further, the user might want to set special DNS configuration, either configured by the enterprise or custom configured in a consumer context. The VPN provider then must honour this DNS configuration.

A DNS server is authorized if:

1. the DNS server is configured by administrating user, or

2. the DNS server is provided by the VPN manufacturer

2. the DNS server is provided by the VPN manufacturer.

> NOTE: is an evolution away plaintext DNS to secure DNS, with platforms, browsers and/or applications increasingly using “secure DNS” that is transported over TLS or HTTPS. Unlike cleartext DNS that uses port 53, use of secure DNS can be harder to identify, inhibiting the enforcement of specific policies to use a specifically configured DNS server.

> NOTE: networks and devices are evolving away from plaintext DNS to “secure DNS”, with platforms, browsers and/or applications increasingly making DNS queries via TLS or HTTPS requests. Unlike cleartext DNS that uses port 53, use of secure DNS can be harder to identify, inhibiting the enforcement of specific policies to use a specifically configured DNS server.

The following requirements apply to DNS traffic intended for the VPN connection. DNS queries for connection establishment, maintenance or restoration of the VPN tunnel are excluded.

#### 5.7.9.2 Applicability

This requirement is only applicable if changes in the local DNS configuration would affect the plaintext DNS query visibility outside the tunnel to third parties of the system, and the product falls within the following use cases

This requirement is only applicable if changes in the local DNS configuration would affect the plaintext DNS query visibility outside the tunnel to third parties of the system, and the product falls within the following use cases.

* UC-1: not required

* UC-2: not required

#### 5.7.10.1 Requirement

The VPN client shall block or notify users of potential VPN bypass via encrypted DNS protocols, including when using the dedicated port for DNS over TLS (DoT), if the traffic is routed via the VPN connection based on DNS policies.

The VPN client shall block or notify users of potential VPN bypass via encrypted DNS protocols, including requests which use the dedicated port for DNS over TLS (DoT), if the traffic is routed via the VPN connection based on DNS policies.

#### 5.7.10.2 Applicability

1. Start the VPN connection, then

2. configure DNS-based policy routing, then

3. for each of DNS over TLS (DoT), configure the operating system or an application to use a well-known public DNS provider for that protocol using the well-known port 853, then

3. configure the operating system or an application to use a well-known public DNS provider for DNS over TLS (DoT) using the well-known port 853, then

4. generate DNS requests while capturing traffic on all network interfaces.

5. If using notifications rather than blocking, observe the client UI or documentation for static warnings regarding encrypted DNS protocols.