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

[Manu Bretelle <[e-mail]>]

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=
[e-mail]> wrote:

> 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 (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
>
> 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/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.
>
> 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) 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>