Subject: [Add] Encrypted DNS support in iOS and macOS

From: Tommy Pauly <[email-masked]>
Date: Fri, 26 Jun 2020 14:28:40 -0700

Hello,

I want to share some relevant updates with the ADD working group about encrypted DNS support in iOS and macOS.

In the iOS 14 and macOS 11 betas, DoH and DoT are both natively supported by the system DNS resolvers. These are technologies that many apps have already been using on iOS and macOS via VPN provider APIs or by embedding application-specific DNS resolver code. Now that these protocols are built into the operating system, these use cases can move over to a system-provided path that provides greater efficiency and tighter integration with built-in APIs that provide Happy Eyeballs and other features.

These videos released as part of the Worldwide Developer Conference cover details of how encrypted DNS can be used by app developers:

Build trust through better privacy: https://developer.apple.com/videos/play/wwdc2020/10676 <https://developer.apple.com/videos/play/wwdc2020/10676> (Timestamps 11:55-13:50)
Enable encrypted DNS: https://developer.apple.com/videos/play/wwdc2020/10047/ <https://developer.apple.com/videos/play/wwdc2020/10047/>

One of the key goals of integrating encrypted DNS into the operating system is ensuring that when users get the privacy and security benefits of encrypted DNS, they don’t have to face breakages for key use cases that require interaction with local DNS providers and private/enterprise DNS servers. Beyond that, the APIs are designed to make it easy to migrate to automatic use of encrypted DNS—the goal of the ADD working group.

To summarize the WWDC videos, there are three different ways that encrypted DNS is being used in the iOS and macOS betas:
Provide a system-wide encrypted DNS resolver selection, as an alternative to providing a “VPN” configuration that just configures DNS
Require encrypted DNS within an app (along with a resolver to prefer if no encrypted resolver is otherwise available), as an alternative to apps embedding their own DNS resolution code
Start automatically discovering designated resolvers for domains that advertise a DoH URI
I’m including details for each of these three mechanisms below.

Best,
Tommy

System-wide:
(https://developer.apple.com/documentation/networkextension/dns_settings <https://developer.apple.com/documentation/networkextension/dns_settings>)
(https://developer.apple.com/documentation/devicemanagement/dnssettings <https://developer.apple.com/documentation/devicemanagement/dnssettings>)
A system-wide DNS configuration can be provided either by an app that uses the NetworkExtension framework, or a configuration profile that can be installed by the user or by an enterprise Mobile Device Management solution. These configurations can select an encrypted DNS server for all domains or only a subset of domains; and can apply to all networks or a subset of networks and network types.

System-wide configurations require an explicit opt-in by a user through Settings, or configuration of a managed device by an enterprise or similar organization. To this end, it is equivalent to how a VPN applies on the operating system.

System-wide configurations are meant to not interfere with critical services that need to use the local network resolver. Captive network interaction and cellular network services continue to use the resolver configured by the local network. Similarly, if a VPN is active, the VPN resolver takes precedence for whichever domains it handles. Note that VPN providers can now indicate that an encrypted DNS resolver should be used within the VPN tunnel as well.

Since these system-wide configurations are based on a user opt-in, there is no mechanism for a local network to disable them. If the connections are blocked, resolution will fail rather than sending out in the clear. This is because these configurations are equivalent to using a VPN—they represent a security policy that the system enforces on behalf of the user.

App opt-in:
(https://developer.apple.com/documentation/network/nwparameters/privacycontext/3548851-requireencryptednameresolution <https://developer.apple.com/documentation/network/nwparameters/privacycontext/3548851-requireencryptednameresolution>)
An app can choose to opt into encrypted DNS for resolution within its process. This is compatible with any system API that does name resolution, whether a connect-by-name API or in standard APIs like getaddrinfo().

The opt-in here is specifically about requiring that specific DNS resolutions use some encrypted DNS protocol (DoH or DoT). Since many devices at first won’t be using encrypted DNS, the app can provide a DNS resolver config to use as a “fallback”. This config indicates a DoH or DoT server to use if and only if the resolution wouldn’t otherwise use DoH or DoT. If there is a system-wide configuration, or a VPN configuration, or automatic detection of DoH or DoT, then the app will use those resolvers instead.

It is important that applications can enable a policy to require encrypted DNS without needing to rewrite their connection logic or adopt entirely different APIs for name resolution. It is also important that as they require encrypted DNS, they have a path forward to be compatible with user preferences around DNS and mechanisms for automatic use of encrypted DNS. If the efforts of ADD are successful in defining standard ways to make encrypted DNS more universal, any app that adopts these APIs should be ready.

Automatic discovery:

The iOS and macOS betas also start going down the road of automatic discovery by implementing some of the mechanisms described in https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html <https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html>. I’m including the details below to explain any traffic you see being generated by these betas, and to explain how to interact with the system if you want to experiment. The system isn’t doing any automatic use of locally-hosted DoH/DoT servers at this point.

Specifically, the system:
Starts sending out requests for HTTPS(HTTPSSVC) records along with A and AAAA queries. This is currently using the testing RR type of 65479. The plan is to use the official allocation once that is made after the wire format is finalized. It parses out a DoH URI template with a key value of 7. This value will also change to one in the correct first-come-first-served range when we change RR type numbers.
Relies on validating that a given zone allows designation to a DoH server using the mechanism described in Section 3.3, Mutual Confirmation with PvD JSON.
Along with the client support, Apple is running a DoH server (https://doh.dns.apple.com/dns-query <https://doh.dns.apple.com/dns-query>) for a very limited set of names within apple.com <http://apple.com/>. This is not a general-purpose DoH resolver, but one that is only meant to be used as a designated resolver for Apple properties. The configuration is at https://doh.dns.apple.com/.well-known/pvd/dns-query <https://doh.dns.apple.com/.well-known/pvd/dns-query>, and the confirmation is performed by checking https://apple.com/.well-known/pvd <https://apple.com/.well-known/pvd>.

If connections to the automatically discovered DoH resolvers fail, the system currently fails over to use traditional DNS.

If the user has selected a system-wide DoH resolver, that will take precedence. However, any app opt-in prefers using the discovered resolver to the app-provided resolver.

---

From: Manu Bretelle <[email-masked]>
Date: Fri, 26 Jun 2020 23:10:29 -0700

Thanks Tommy for providing more on the technical details behind the
implementation.
The implementation looks solid and will take care of a lot of the edge
cases (captive portal, administered device, vpn, happy eyeball), lifting a
lot from the application developpers.

There is one case that I did not see mentioned yet and I wonder if it is
already supported or if there is any plan in supporting/detecting it, which
is NAT64/DNS64.

Thanks!
Manu

On Fri, Jun 26, 2020 at 2:28 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> In the iOS 14 and macOS 11 betas, DoH and DoT are both natively supported
> by the system DNS resolvers. These are technologies that many apps have
> already been using on iOS and macOS via VPN provider APIs or by embedding
> application-specific DNS resolver code. Now that these protocols are built
> into the operating system, these use cases can move over to a
> system-provided path that provides greater efficiency and tighter
> integration with built-in APIs that provide Happy Eyeballs and other
> features.
>
> These videos released as part of the Worldwide Developer Conference cover
> details of how encrypted DNS can be used by app developers:
>
> Build trust through better privacy:
> https://developer.apple.com/videos/play/wwdc2020/10676 (Timestamps
> 11:55-13:50)
> Enable encrypted DNS:
> https://developer.apple.com/videos/play/wwdc2020/10047/
>
> One of the key goals of integrating encrypted DNS into the operating
> system is ensuring that when users get the privacy and security benefits of
> encrypted DNS, they don’t have to face breakages for key use cases that
> require interaction with local DNS providers and private/enterprise DNS
> servers. Beyond that, the APIs are designed to make it easy to migrate to
> automatic use of encrypted DNS—the goal of the ADD working group.
>
> To summarize the WWDC videos, there are three different ways that
> encrypted DNS is being used in the iOS and macOS betas:
>
>    1. Provide a system-wide encrypted DNS resolver selection, as an
>    alternative to providing a “VPN” configuration that just configures DNS
>    2. Require encrypted DNS within an app (along with a resolver to
>    prefer if no encrypted resolver is otherwise available), as an alternative
>    to apps embedding their own DNS resolution code
>    3. Start automatically discovering designated resolvers for domains
>    that advertise a DoH URI
>
> (https://developer.apple.com/documentation/networkextension/dns_settings)
> (https://developer.apple.com/documentation/devicemanagement/dnssettings)
> A system-wide DNS configuration can be provided either by an app that uses
> the NetworkExtension framework, or a configuration profile that can be
> installed by the user or by an enterprise Mobile Device Management
> solution. These configurations can select an encrypted DNS server for all
> domains or only a subset of domains; and can apply to all networks or a
> subset of networks and network types.
>
> System-wide configurations require an explicit opt-in by a user through
> Settings, or configuration of a managed device by an enterprise or similar
> organization. To this end, it is equivalent to how a VPN applies on the
> operating system.
>
> System-wide configurations are meant to not interfere with critical
> services that need to use the local network resolver. Captive network
> interaction and cellular network services continue to use the resolver
> configured by the local network. Similarly, if a VPN is active, the VPN
> resolver takes precedence for whichever domains it handles. Note that VPN
> providers can now indicate that an encrypted DNS resolver should be used
> within the VPN tunnel as well.
>
> Since these system-wide configurations are based on a user opt-in, there
> is no mechanism for a local network to disable them. If the connections are
> blocked, resolution will fail rather than sending out in the clear. This is
> because these configurations are equivalent to using a VPN—they represent a
> security policy that the system enforces on behalf of the user.
>
> App opt-in:
> (
> https://developer.apple.com/documentation/network/nwparameters/privacycontext/3548851-requireencryptednameresolution
> )
> An app can choose to opt into encrypted DNS for resolution within its
> process. This is compatible with any system API that does name resolution,
> whether a connect-by-name API or in standard APIs like getaddrinfo().
>
> The opt-in here is specifically about requiring that specific DNS
> resolutions use some encrypted DNS protocol (DoH or DoT). Since many
> devices at first won’t be using encrypted DNS, the app can provide a DNS
> resolver config to use as a “fallback”. This config indicates a DoH or DoT
> server to use if and only if the resolution wouldn’t otherwise use DoH or
> DoT. If there is a system-wide configuration, or a VPN configuration, or
> automatic detection of DoH or DoT, then the app will use those resolvers
> instead.
>
> It is important that applications can enable a policy to require encrypted
> DNS without needing to rewrite their connection logic or adopt entirely
> different APIs for name resolution. It is also important that as they
> require encrypted DNS, they have a path forward to be compatible with user
> preferences around DNS and mechanisms for automatic use of encrypted DNS.
> If the efforts of ADD are successful in defining standard ways to make
> encrypted DNS more universal, any app that adopts these APIs should be
> ready.
>
> Automatic discovery:
>
> The iOS and macOS betas also start going down the road of automatic
> discovery by implementing some of the mechanisms described in
> https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00..html
> <https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html>.
> I’m including the details below to explain any traffic you see being
> generated by these betas, and to explain how to interact with the system if
> you want to experiment. The system isn’t doing any automatic use of
> locally-hosted DoH/DoT servers at this point.
>
>    - Starts sending out requests for HTTPS(HTTPSSVC) records along with A
>    and AAAA queries. This is currently using the testing RR type of 65479. The
>    plan is to use the official allocation once that is made after the wire
>    format is finalized. It parses out a DoH URI template with a key value of
>    7. This value will also change to one in the correct
>    first-come-first-served range when we change RR type numbers.
>    - Relies on validating that a given zone allows designation to a DoH
>    server using the mechanism described in Section 3.3, Mutual Confirmation
>    with PvD JSON.
>
> Along with the client support, Apple is running a DoH server (
> https://doh.dns.apple.com/dns-query) for a very limited set of names
> within apple.com. This is not a general-purpose DoH resolver, but one
> that is only meant to be used as a designated resolver for Apple
> properties. The configuration is at
> https://doh.dns.apple.com/.well-known/pvd/dns-query, and the confirmation
> is performed by checking https://apple.com/.well-known/pvd.
>
> If connections to the automatically discovered DoH resolvers fail, the
> system currently fails over to use traditional DNS.
>
> If the user has selected a system-wide DoH resolver, that will take
> precedence. However, any app opt-in prefers using the discovered resolver
> to the app-provided resolver.
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "Chris Box (BT)" <[email-masked]>
Date: Sat, 27 Jun 2020 07:58:13 +0100

Tommy,

These details are incredibly helpful so I appreciate you sharing them.

I’m uncertain about automatic discovery though. You say:

>
> The system isn’t doing any automatic use of locally-hosted DoH/DoT servers
> at this point.
>

> system currently fails over to use traditional DNS.

In the beta, are automatically discovered resolvers used, or ignored?

Thanks
Chris

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 27 Jun 2020 08:35:53 -0700

> On Jun 26, 2020, at 11:11 PM, Manu Bretelle <[email-masked]> wrote:
> 
> 
> Thanks Tommy for providing more on the technical details behind the implementation.
> The implementation looks solid and will take care of a lot of the edge cases (captive portal, administered device, vpn, happy eyeball), lifting a lot from the application developpers.
> 
> There is one case that I did not see mentioned yet and I wonder if it is already supported or if there is any plan in supporting/detecting it, which is NAT64/DNS64.

Good point, I should have mentioned this! When the local network is NAT64, we will still request A and AAAA from any DoH/DoT server, and if we get only A answers, we synthesize an IPv6 address using the NAT64 prefix before using it. 

Thanks,
Tommy
> 
> Thanks!
> Manu
> 
>> On Fri, Jun 26, 2020 at 2:28 PM Tommy Pauly <tpauly=[email-masked]> wrote:
>> Hello,
>> 
>> Build trust through better privacy: https://developer.apple.com/videos/play/wwdc2020/10676 (Timestamps 11:55-13:50)
>> Enable encrypted DNS: https://developer.apple.com/videos/play/wwdc2020/10047/
>> 
>> (https://developer.apple.com/documentation/network/nwparameters/privacycontext/3548851-requireencryptednameresolution)
>> The iOS and macOS betas also start going down the road of automatic discovery by implementing some of the mechanisms described in https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00..html. I’m including the details below to explain any traffic you see being generated by these betas, and to explain how to interact with the system if you want to experiment. The system isn’t doing any automatic use of locally-hosted DoH/DoT servers at this point.
>> 
>> Starts sending out requests for HTTPS(HTTPSSVC) records along with A and AAAA queries. This is currently using the testing RR type of 65479. The plan is to use the official allocation once that is made after the wire format is finalized.. It parses out a DoH URI template with a key value of 7. This value will also change to one in the correct first-come-first-served range when we change RR type numbers.
>> Along with the client support, Apple is running a DoH server (https://doh.dns.apple.com/dns-query) for a very limited set of names within apple.com. This is not a general-purpose DoH resolver, but one that is only meant to be used as a designated resolver for Apple properties. The configuration is at https://doh.dns.apple.com/.well-known/pvd/dns-query, and the confirmation is performed by checking https://apple.com/.well-known/pvd.
>> 
>> If the user has selected a system-wide DoH resolver, that will take precedence. However, any app opt-in prefers using the discovered resolver to the app-provided resolver..
>> 
>> -- 
>> Add mailing list
>> [email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 27 Jun 2020 08:40:33 -0700

> On Jun 26, 2020, at 11:58 PM, Chris Box (BT) <[email-masked]> wrote:
> 
> 
> Tommy,
> 
>> The system isn’t doing any automatic use of locally-hosted DoH/DoT servers at this point.
> 

The system doesn’t yet do any automatic DoH for *local* resolvers, such as upgrading from the ISP UDP resolver to an ISP DoH resolver. 

The automatic behavior the betas do have is for designating resolvers for specific domains using HTTPS RR. 

However, I’d expect that behavior for local discovery would be similar. Based on our draft, we’d like to explore using the same HTTPS RR format for local resolver upgrade. 

Best,
Tommy

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Mon, 29 Jun 2020 15:48:58 +0000

Hi,

Thanks for the excellent video explaining the new capabilities.

One thing that was unclear -
I understand that VPN and Captive Portal settings take precedence.

Does this mean that if VPN intentionally sets Do53 configuration for the 
tunnel DNS-settings that legacy DNS will be used over that interface in all 
cases?
Will per-app secure-DNS settings be used in that case or not?

I looked at various documentation, but was not clear to me what the behavior 
was.
https://developer.apple.com/documentation/devicemanagement/dnssettings/dnssettings
https://developer.apple.com/documentation/networkextension/nednssettingsmanager
https://developer.apple.com/documentation/networkextension/nednssettings

Thx
-Vinny