None
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07
Query DNS for HTTPS records (alongside traditional A and AAAA queries). When a website has deployed an HTTPS DNS record and Chrome receives it, Chrome will always connect to the website via HTTPS.
Design doc for all Chrome DNS HTTPS plans: https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ
This feature covers just the basic query and HTTP->HTTPS upgrade part of those plans, and only for simpler cases that do not require followup DNS queries by the Chrome DNS stack.
Not applicable. No direct changes to web platform APIs. Change is to underlying DNS infrastructure, following an IETF spec, with only indirect web-facing side effects.
Not applicable
Not directly part of the web API surface; only has indirect behavior implications on the web platform in the form of the HTTP->HTTPS redirect triggered by DNS signals.
HTTPS DNS records are a feature of DNS. The spec is a draft of the IETF DNSOP working group, and while not yet a published RFC, it is widely considered stable and ready for implementation. IANA has designated HTTPS as DNS resource record type 65.
Gecko: No signal
WebKit: Safari has been querying HTTPS DNS records since late 2020. Unclear if Safari has yet implemented HTTP->HTTPS redirect behavior of such records.
Web developers: No signals
No specific DevTools support. Changes not directly part of the web API surface. Chrome is not generally used as a development tool for changing DNS records besides testing/developing the indirect behavior effects on visiting websites.
No
None
False
Desktop 96
Android 96
https://www.chromestatus.com/feature/5485544526053376
This intent message was generated by Chrome Platform Status.
Contact emails
Explainer
None
Specification
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07
Summary
Query DNS for HTTPS records (alongside traditional A and AAAA queries). When a website has deployed an HTTPS DNS record and Chrome receives it, Chrome will always connect to the website via HTTPS.
Design doc for all Chrome DNS HTTPS plans: https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ
This feature covers just the basic query and HTTP->HTTPS upgrade part of those plans, and only for simpler cases that do not require followup DNS queries by the Chrome DNS stack.
Blink component
TAG review
Not applicable. No direct changes to web platform APIs. Change is to underlying DNS infrastructure, following an IETF spec, with only indirect web-facing side effects.
TAG review status
Not applicable
Risks
Interoperability and Compatibility
Not directly part of the web API surface; only has indirect behavior implications on the web platform in the form of the HTTP->HTTPS redirect triggered by DNS signals.
HTTPS DNS records are a feature of DNS. The spec is a draft of the IETF DNSOP working group, and while not yet a published RFC, it is widely considered stable and ready for implementation. IANA has designated HTTPS as DNS resource record type 65.
Gecko: No signal
WebKit: Safari has been querying HTTPS DNS records since late 2020. Unclear if Safari has yet implemented HTTP->HTTPS redirect behavior of such records.
Web developers: No signals
Debuggability
No specific DevTools support. Changes not directly part of the web API surface. Chrome is not generally used as a development tool for changing DNS records besides testing/developing the indirect behavior effects on visiting websites.
Is this feature fully tested by web-platform-tests?
No
Flag name
None
Requires code in //chrome?
False
Tracking bug
Launch bug
Estimated milestones
Desktop 96
Android 96
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5485544526053376
This intent message was generated by Chrome Platform Status.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcEJF4%3D7zU16oki_m0vYqfX2_%2BXgH2Fxf51RnMv9ipx63w%40mail.gmail.com.
Hey Eric!On Thu, Sep 23, 2021 at 10:36 PM Eric Orth <eric...@chromium.org> wrote:Contact emails
Explainer
None
Specification
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07
Summary
Query DNS for HTTPS records (alongside traditional A and AAAA queries). When a website has deployed an HTTPS DNS record and Chrome receives it, Chrome will always connect to the website via HTTPS.
Design doc for all Chrome DNS HTTPS plans: https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ
This feature covers just the basic query and HTTP->HTTPS upgrade part of those plans, and only for simpler cases that do not require followup DNS queries by the Chrome DNS stack.
Blink component
TAG review
Not applicable. No direct changes to web platform APIs. Change is to underlying DNS infrastructure, following an IETF spec, with only indirect web-facing side effects.
This seems like an overly narrow take on the feature: it seems like this needs to be wired up to Fetch in order to explain how the DNS assertion turns into a decision about how to connect to sites (similar to HSTS's integration), and that upgrade will have web-visible impacts.
Can I assume that you'll be following the same algorithm (e.g. shifting from 80 to 443 by switching the protocol, but not altering non-standard ports)?
TAG review status
Not applicable
Risks
Interoperability and Compatibility
Not directly part of the web API surface; only has indirect behavior implications on the web platform in the form of the HTTP->HTTPS redirect triggered by DNS signals.
HTTPS DNS records are a feature of DNS. The spec is a draft of the IETF DNSOP working group, and while not yet a published RFC, it is widely considered stable and ready for implementation. IANA has designated HTTPS as DNS resource record type 65.
Gecko: No signal
WebKit: Safari has been querying HTTPS DNS records since late 2020. Unclear if Safari has yet implemented HTTP->HTTPS redirect behavior of such records.
It would be helpful to ask both Gecko and WebKit developers for more clear signals as described in https://bit.ly/blink-signals.
Web developers: No signals
Are there any folks lined up to use this? Presumably there are if Safari is already making these queries?
Debuggability
No specific DevTools support. Changes not directly part of the web API surface. Chrome is not generally used as a development tool for changing DNS records besides testing/developing the indirect behavior effects on visiting websites.
We represent HSTS to developers in devtools. Presumably we'd want to do the same for this mechanism, and signal in some way to developers _why_ a particular request was upgraded?
On Tue, Sep 28, 2021 at 6:09 AM Mike West <mk...@chromium.org> wrote:Hey Eric!On Thu, Sep 23, 2021 at 10:36 PM Eric Orth <eric...@chromium.org> wrote:Contact emails
Explainer
None
Specification
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07
Summary
Query DNS for HTTPS records (alongside traditional A and AAAA queries). When a website has deployed an HTTPS DNS record and Chrome receives it, Chrome will always connect to the website via HTTPS.
Design doc for all Chrome DNS HTTPS plans: https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ
This feature covers just the basic query and HTTP->HTTPS upgrade part of those plans, and only for simpler cases that do not require followup DNS queries by the Chrome DNS stack.
Blink component
TAG review
Not applicable. No direct changes to web platform APIs. Change is to underlying DNS infrastructure, following an IETF spec, with only indirect web-facing side effects.
This seems like an overly narrow take on the feature: it seems like this needs to be wired up to Fetch in order to explain how the DNS assertion turns into a decision about how to connect to sites (similar to HSTS's integration), and that upgrade will have web-visible impacts.Seems accurate to me. All the signals and triggering happen in DNS, outside web platform APIs, with no direct web-platform-API interaction, e.g. a header like was done for HSTS. Then the result is a redirect, which yes, is web-visible, hence the "indirect web-facing side effects".
But I think you are right that this should get at least a mention in the Fetch spec, and I think the ideal situation would be a single additional sentence in that point about HSTS upgrade ("[...] or a DNS lookup for the request's current URL per [link to section 8.5 of SVCB RFC] returns an HTTPS DNS record." or something like that). Does that sound reasonable to you, or do you think this will take more comprehensive updates to Fetch?
Can I assume that you'll be following the same algorithm (e.g. shifting from 80 to 443 by switching the protocol, but not altering non-standard ports)?Correct. Non-standard ports result in a redirect to https with the same non-standard port.
Also noteworthy that non-standard ports would require the HTTPS DNS record to be specific to that non-standard port, e.g. if the request URL were "http://example.com:1234", the redirect will only happen if there is an HTTPS record for DNS queries for "_1234._https.example.com", not merely at "example.com" as would be sufficient if the request URL were "http://example.com[:80]".
TAG review status
Not applicable
Risks
Interoperability and Compatibility
Not directly part of the web API surface; only has indirect behavior implications on the web platform in the form of the HTTP->HTTPS redirect triggered by DNS signals.
HTTPS DNS records are a feature of DNS. The spec is a draft of the IETF DNSOP working group, and while not yet a published RFC, it is widely considered stable and ready for implementation. IANA has designated HTTPS as DNS resource record type 65.
Gecko: No signal
WebKit: Safari has been querying HTTPS DNS records since late 2020. Unclear if Safari has yet implemented HTTP->HTTPS redirect behavior of such records.
It would be helpful to ask both Gecko and WebKit developers for more clear signals as described in https://bit.ly/blink-signals.Okay. I'll send off those requests.
Web developers: No signals
Are there any folks lined up to use this? Presumably there are if Safari is already making these queries?Most of the general interest I have heard for HTTPS records is for the ECH and upgrade-to-QUIC functionalities that are not part of this specific planned launch. So it would be fair to say there is a lot of interest from various parties for HTTPS record support in general, and this HTTP->HTTPS redirect functionality is a part of that standard, and it is by design that you cannot get those other functionalities without also getting the HTTP->HTTPS functionality.Debuggability
No specific DevTools support. Changes not directly part of the web API surface. Chrome is not generally used as a development tool for changing DNS records besides testing/developing the indirect behavior effects on visiting websites.
We represent HSTS to developers in devtools. Presumably we'd want to do the same for this mechanism, and signal in some way to developers _why_ a particular request was upgraded?I wouldn't describe it as rising to the level of "support", but DNS-triggered redirect will display similarly to other artificial redirect responses, e.g. HSTS or extension delegates. That is that DevTools will show a 307 redirect response with a "Non-Authoritative-Reason" field with a short string to describe the reason, e.g. "HSTS", "delegate", or for DNS-triggered redirects, "DNS". I've added a note on this into the the chromestatus entry.
https://www.mozilla.org/en-US/firefox/92.0/releasenotes/
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcH4nkQuyH4TxsMoHOXRqLSOLrxNkQv0WYTt2d7LC98VgA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcFFMkuhWjP-cMg%2BAH_Sr_DdHESEowQgDkh_tnF7Fy1t8A%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcEJF4%3D7zU16oki_m0vYqfX2_%2BXgH2Fxf51RnMv9ipx63w%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcH4nkQuyH4TxsMoHOXRqLSOLrxNkQv0WYTt2d7LC98VgA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcEJF4%3D7zU16oki_m0vYqfX2_%2BXgH2Fxf51RnMv9ipx63w%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcH4nkQuyH4TxsMoHOXRqLSOLrxNkQv0WYTt2d7LC98VgA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMOjQcHTz_PWTUQG_7LyQORzB9s4x5AVMp9QGRTLSQADe%2B1kqA%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcEJF4%3D7zU16oki_m0vYqfX2_%2BXgH2Fxf51RnMv9ipx63w%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcH4nkQuyH4TxsMoHOXRqLSOLrxNkQv0WYTt2d7LC98VgA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcFFMkuhWjP-cMg%2BAH_Sr_DdHESEowQgDkh_tnF7Fy1t8A%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcEJF4%3D7zU16oki_m0vYqfX2_%2BXgH2Fxf51RnMv9ipx63w%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcH4nkQuyH4TxsMoHOXRqLSOLrxNkQv0WYTt2d7LC98VgA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcFFMkuhWjP-cMg%2BAH_Sr_DdHESEowQgDkh_tnF7Fy1t8A%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMOjQcHTz_PWTUQG_7LyQORzB9s4x5AVMp9QGRTLSQADe%2B1kqA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d43a48a1-16fc-4d57-bbe9-8c054f27e851n%40chromium.org.
Moin!
On 23 Sep 2021, at 22:36, Eric Orth wrote:
> Estimated milestones
>
> Desktop 96
>
> Android 96
>
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/5485544526053376
Sorry to maybe ask obvious questions, but I am new to this group and
just been tracking it for this specific feature.
Now if I read the above correct the current Chrome Dev channel build (
for me 96.0.4664.9 on Intel MacOS) should have this feature, however I
don’t see HTTPS (DNS Type 65) queries send even if I set a DoH
resolver. Am I missing something or is this not yet implemented?
TIA and so long
-Ralf
—--
Ralf Weber
Moin!
On 15 Oct 2021, at 20:51, Eric Orth wrote:
> The feature is implemented as of 96.0.4645.0, but whether or not it runs is
> controlled by experiment flags. We currently have those flags enabled for
> 50% of Canary/Dev users to allow comparison against a disabled control.
> Sounds like you might be in the "control" 50%.
>
> To force the experiment:
> chrome.exe
> --enable-features="UseDnsHttpsSvcb<DnsHttpsSvcbSchemeUpgrade.ForcedOn_UseDnsHttpsSvcb:UseDnsHttpsSvcbEnableInsecure/true/UseDnsHttpsSvcbHttpUpgrade/true/UseDnsHttpsSvcbExtraTimeAbsolute/500ms/UseDnsHttpsSvcbExtraTimePercent/50"
Thanks a lot that did work and I got a better understanding of the traffic now. Will the experiment also be done in beta and stable? The actual question is when and at what rate will operators of DNS resolvers see traffic increases because of this?