Subject: DNS HTTPS/SVCB record type support in iOS 14

From: Tommy Pauly <[email-masked]>
Date: Fri, 25 Sep 2020 12:58:26 -0700

Hello DNSOP & QUIC,

I wanted to provide an update that the production version of iOS 14, which shipped last week, includes support for sending HTTPS (SVCB) DNS queries (RR type 65) for applications using our system networking APIs.

The implementation status has been updated here: https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md <https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md>

For those with HTTP/3 QUIC deployments, this means that (when HTTP/3 experimental support is enabled) iOS will use the ALPN indication in the HTTPS record to enable HTTP/3 prior to receiving an Alt-Svc indication. As previously noted on the DNSOP list, Cloudflare is already supporting publishing these records, and we’d encourage other server deployments that support QUIC to do the same.

To note, this behavior is the same in the betas of macOS 11.

Best,
Tommy

---

From: David Schinazi <[email-masked]>
Date: Fri, 25 Sep 2020 13:12:25 -0700

Hi Tommy,

Thanks for the announcement! It's really exciting to see this deployed in
the wild.
Clarification question: your email mentioned support for the HTTPS DNS
query,
but it didn't mention when iOS makes those queries. For example, do you
query
this record every single time you perform A/AAAA queries? (in the context of
a Network.framework connection to port 443)

David

On Fri, Sep 25, 2020 at 12:59 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hello DNSOP & QUIC,
>
> I wanted to provide an update that the production version of iOS 14, which
> shipped last week, includes support for sending HTTPS (SVCB) DNS queries
> (RR type 65) for applications using our system networking APIs.
>
> The implementation status has been updated here:
> https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md
>
> For those with HTTP/3 QUIC deployments, this means that (when HTTP/3
> experimental support is enabled) iOS will use the ALPN indication in the
> HTTPS record to enable HTTP/3 prior to receiving an Alt-Svc indication. As
> previously noted on the DNSOP list, Cloudflare is already supporting
> publishing these records, and we’d encourage other server deployments that
> support QUIC to do the same.
>

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 25 Sep 2020 13:18:33 -0700

Hi David,

Sorry for the lack of clarity! The HTTPS query will be made alongside A/AAAA queries for all connections that use Network.framework/NSURLSession for URL schemes “http://“ and “https://“, or TCP port 80 or port 443.

Thanks,
Tommy

> On Sep 25, 2020, at 1:12 PM, David Schinazi <[email-masked]> wrote:
> 
> Hi Tommy,
> 
> Thanks for the announcement! It's really exciting to see this deployed in the wild.
> Clarification question: your email mentioned support for the HTTPS DNS query,
> but it didn't mention when iOS makes those queries. For example, do you query
> On Fri, Sep 25, 2020 at 12:59 PM Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>> wrote:
> Hello DNSOP & QUIC,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 25 Sep 2020 18:07:33 -0700

Thanks for sharing this, Tommy -- this is exciting indeed.
Can you share if Safari uses this information for deciding when to race a
QUIC connection?

- jana

On Fri, Sep 25, 2020 at 1:19 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hi David,
>
> Sorry for the lack of clarity! The HTTPS query will be made alongside
> A/AAAA queries for all connections that use Network.framework/NSURLSession
> for URL schemes “http://“ and “https://“, or TCP port 80 or port 443.
>
> Thanks,
> Tommy
>
>> I wanted to provide an update that the production version of iOS 14,
>> which shipped last week, includes support for sending HTTPS (SVCB) DNS
>> queries (RR type 65) for applications using our system networking APIs.
>>

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 25 Sep 2020 19:07:57 -0700

Hi Jana,

Currently, HTTP/3 support in Safari needs to be enabled by the user (under Experimental Features). When it is enabled, the ALPN hint in the HTTPS record causes the stack to race QUIC first (assuming we have no history of QUIC failures), even when no previous connections had been made to the host. 

Thanks,
Tommy

> On Sep 25, 2020, at 6:08 PM, Jana Iyengar <[email-masked]> wrote:
> 
> 
> Can you share if Safari uses this information for deciding when to race a QUIC connection?
> 
> - jana
> 
>> On Fri, Sep 25, 2020 at 1:19 PM Tommy Pauly <tpauly=[email-masked]> wrote:
>> Hi David,
>> 
>>> On Fri, Sep 25, 2020 at 12:59 PM Tommy Pauly <tpauly=[email-masked]> wrote:
>>>> Hello DNSOP & QUIC,
>>>> 
>>>> The implementation status has been updated here: https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md
>>>>

---

From: Ian Swett <[email-masked]>
Date: Sat, 26 Sep 2020 08:00:03 -0400

On Fri, Sep 25, 2020 at 10:09 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hi Jana,
>
> Currently, HTTP/3 support in Safari needs to be enabled by the user (under
> Experimental Features). When it is enabled, the ALPN hint in the HTTPS
> record causes the stack to race QUIC first (assuming we have no history of
> QUIC failures), even when no previous connections had been made to the
> host.
>

What if there is a history of QUIC failures and what constitutes a
failure?  And is the history per-host, per-user or some combination thereof?

I'm curious how this logic compares to Chrome's current logic.

Thanks, Ian

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 26 Sep 2020 09:02:25 -0700

> On Sep 26, 2020, at 5:01 AM, Ian Swett <ianswett=[email-masked]> wrote:
> 
> 
> 
>> On Fri, Sep 25, 2020 at 10:09 PM Tommy Pauly <tpauly=[email-masked]> wrote:
>> Hi Jana,
>> 
> What if there is a history of QUIC failures and what constitutes a failure?  And is the history per-host, per-user or some combination thereof?
> 

We store a history of success/failure/losing the race on a per-host basis. This is based on our logic for racing IPv6 and IPv4 for happy eyeballs. If we have no successful QUIC connections within a certain period of time, but have a number of failures or lost races above a threshold (~10), we’ll race with TCP first. If a failure is detected at the H3 layer (not in the race or in the QUIC handshake), we have a lower threshold before swapping the race order. 

Thanks,
Tommy