[DNSOP] HTTPS and SVBC client support measurement.

[Mark Andrews]

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: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 10 Jul 2020, at 10:27, Ben Schwartz  wrote:
> 
> 
> 
> On Thu, Jul 9, 2020, 8:04 PM Mark Andrews  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.

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  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  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.

> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tommy Pauly]

> On Jul 9, 2020, at 5:27 PM, Ben Schwartz  
> wrote:
> 
> 
> 
> On Thu, Jul 9, 2020, 8:04 PM Mark Andrews  > 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.

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 
 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. 

> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742   INTERNET: 
> ma...@isc.org 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop