> 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
