> On Jul 9, 2020, at 5:27 PM, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> 
> wrote:
> 
> 
> 
> On Thu, Jul 9, 2020, 8:04 PM Mark Andrews <ma...@isc.org 
> <mailto:ma...@isc.org>> 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 
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. 

> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 <tel:+61%202%209871%204742>              INTERNET: 
> ma...@isc.org <mailto:ma...@isc.org>
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop 
> <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

Reply via email to