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

Manu Bretelle <> Sat, 27 June 2020 06:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA0EB3A0D9C for <>; Fri, 26 Jun 2020 23:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PMbHSZYo2IiY for <>; Fri, 26 Jun 2020 23:10:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 282C93A0D7E for <>; Fri, 26 Jun 2020 23:10:41 -0700 (PDT)
Received: by with SMTP id k6so10285845ili.6 for <>; Fri, 26 Jun 2020 23:10:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xyg8X8VEthzCcIvwETHEXtaaXetKDUzGwuBmjDZ/pmc=; b=Icf4m53W+tECPufLooaPjaTvNIwhhuHpe9gNyHe0QxFAxibT1c4zzKLv9DPzYVrC7I Zewy9sUmA58wRIrJzKY7VUnEq5n7SpNMH1mxq+GgCJLaBQEjoyWUg/j1NENTksmi4isi iWRVwVY3tUlOCeDlfcWnC2dU2Xuw87fdSE6Zp+1W/dvihpGmiwafP5kY5zdHdtjiM7gr UEg+BW3LAVLzPAyjl+5BtKJljPSf+rXzoWFxDAi1Om+rrhQVt5IrdHO8md9uOAgS8/no UP0QLi7XEf9ACehnCzWOgIkHoYE6eQMGA8CAJod8oNkLZrvru98Y+tUcvNGeNxvOpVaf GrwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xyg8X8VEthzCcIvwETHEXtaaXetKDUzGwuBmjDZ/pmc=; b=UxAsj9ZrYFdkLLLGVwozgda5KYtFIoa1H8kKDOiAXkGdQWbFlf3mN+L9F4F6lmZkqC FSRqic3bX7+3irJx1I9Y2V/2RrEq6xbghJkKyYU91pTlGd4npVp5V+J6/6TJF6w+30VW WCaRn3BIUBVOyZgZ7UeIQrVFuMXPKes1g5NY/3a/QXRxuvHZpXlmNLOTioMy0qiCExWh O9+JeD/ld3il3J7rrmQTp6ceT6b4G53zTAhirc+DV2iy6WGn32KzCJivjjlZlpS5ANy1 W9c02kBQTKtqqvDC3QSG3ziMCdUUmIgXx9LfErHhuxk+rR+iWjkhEsELiXh3UlXyYgbx lagg==
X-Gm-Message-State: AOAM531RfQmHzH0V8iJgeIvT3JmayeUHTeoFTpWbuhwhu2OFaBp/MAfA tbUELwQGmwcnJyAYIP5xXXmd0Tl7B6Vyyr7fMy/slQ==
X-Google-Smtp-Source: ABdhPJy32tQasFX0LPgthGp4RPRY7JCnMZqRkvpXO5RR4Kj6NYles5qEUSDexBCnO2IuuSF/ZMr+BpekKeHEk1SeYBc=
X-Received: by 2002:a92:a04e:: with SMTP id b14mr6692896ilm.261.1593238240175; Fri, 26 Jun 2020 23:10:40 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Manu Bretelle <>
Date: Fri, 26 Jun 2020 23:10:29 -0700
Message-ID: <>
To: Tommy Pauly <>
Cc: ADD Mailing list <>
Content-Type: multipart/alternative; boundary="000000000000592a1405a90aaf4c"
Archived-At: <>
Subject: Re: [Add] Encrypted DNS support in iOS and macOS
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 27 Jun 2020 06:10:51 -0000

Thanks Tommy for providing more on the technical details behind the
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.


On Fri, Jun 26, 2020 at 2:28 PM Tommy Pauly <tpauly=> 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:
> (Timestamps
> 11:55-13:50)
> Enable encrypted DNS:
> 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:
> (
> (
> 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:
> (
> )
> 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
> <>.
> 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 (
> for a very limited set of names
> within 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
>, and the confirmation
> is performed by checking
> 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