Subject: [DNSOP] HTTPS and SVBC client support measurement.

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jul 2020 10:03:38 +1000

It would be useful if there was a way to measure client support for HTTPS and SVBC even when they are not in use.  Perhaps a HTTP header could be added to signal that the client supports HTTPS? This will provide server administrators information about their client population to decide when it is safe to remove support for legacy clients.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 9 Jul 2020 20:27:44 -0400

On Thu, Jul 9, 2020, 8:04 PM Mark Andrews <[email-masked]> wrote:

> It would be useful if there was a way to measure client support for HTTPS
> and SVBC even when they are not in use.  Perhaps a HTTP header could be
> added to signal that the client supports HTTPS? This will provide server
> administrators information about their client population to decide when it
> is safe to remove support for legacy clients.

I don't foresee anyone removing support for non-SVCB-aware clients (I
wouldn't call them "legacy") any time soon.  That sounds like a change that
would take many decades, if it even proves desirable.

However, I think your purpose here is already well-served by the current
draft.  If you publish SVCB records that point to a different server IP
address or port from the non-SVCB connections, you can easily observe what
fraction of users are SVCB-enabled.

-- 
> PHONE: +61 2 9871 4742 <+61%202%209871%204742>              INTERNET:
> [email-masked]
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jul 2020 10:51:16 +1000

> On 10 Jul 2020, at 10:27, Ben Schwartz <[email-masked]> wrote:
> 
> 
> 
> I don't foresee anyone removing support for non-SVCB-aware clients (I wouldn't call them "legacy") any time soon.  That sounds like a change that would take many decades, if it even proves desirable.

Well it proved desirable for SMTP. A records used to exist at zone apexes simply to support email to that name for many years after MX support was effectively universal simply because it was next to impossible to measure client support for MX.

Having a A or AAAA pointing at a third party introduces risks of other protocols being processed by the third party beyond those that party is supposed to accept.  Even when it isn’t a third party the servers often need to know the name used to connect to them to make sensible decisions about how to respond. Reducing the number A and AAAA records with different names helps here.

> However, I think your purpose here is already well-served by the current draft.  If you publish SVCB records that point to a different server IP address or port from the non-SVCB connections, you can easily observe what fraction of users are SVCB-enabled.

but those mechanisms don’t help people deciding whether to publish HTTPS/SVBC in the first place.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 9 Jul 2020 21:06:01 -0400

> HTTPS/SVBC in the first place.

Publishing a SVCB record is free, and if the operator is considering
publishing _only_ a SVCB record, surely they should first be willing to
publish it in addition to their current configuration.

As in your example, the difficulty was not in publishing the MX record in
the first place, but in safely removing the apex address records.

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 09 Jul 2020 18:41:43 -0700

> On Jul 9, 2020, at 5:27 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 
> 
> On Thu, Jul 9, 2020, 8:04 PM Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:

Yes, this seems like the simplest way to track this from the server standpoint. That does require having a server listening on another port/address, but presumably if you’re getting benefit from SVCB, you probably have something you’re pointing to.

We can imagine a world once most clients are HTTPS/SVCB-aware that the A and AAAA records stop being used for load balancing, but just point to the “fallback” configuration, and servers can detect support for HTTPS/SVCB in client by detecting the use of those services. 

> PHONE: +61 2 9871 4742 <tel:+61%202%209871%204742>              INTERNET: [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>