[konklone]

Subdomains generally get automatically included when a second-level domain is preloaded. So, for .gov domains that fall under scope here, their subdomains will all have HTTPS enforced by modern web browsers.

Web browsers enforce preloading by considering each domain as having HTTP Strict Transport Security (HSTS) set, and so it gets the strict treatment: only https:// connections, and no clicking through certificate warnings.

Some more detail on all this here: https://https.cio.gov/hsts/

[prodtorok]

I've contracted for a few of the larger agencies and that's just not true. Their DNS's can route sub-domains to several (hundreds) different sites/servers where there is no, and continues to be no, https

[konklone]

@prodtorok - This is one of the nice things about HSTS. The includeSubDomains directive can create automatic client enforcement for all subdomains. If some component of an agency ignores this and doesn't configure HTTPS, they'll find that users of modern browsers won't be able to access the site.

The one downside of includeSubDomains is that, with dynamic HSTS (without preloading), you have to get the user to visit https://agency.gov to "see" the HSTS header once to get that coverage. Visiting https://www.agency.gov or http://agency.gov won't do it.

So another benefit of preloading is that you remove that problem from the table -- browsers will enforce HTTPS for all subdomains, even if the user has never visited the root site. It's a powerful tool, and there is no analogue for other protocols (like IPv6 or DNSSEC) to set policies for an entire zone that you can expect most clients to enforce.

[prodtorok]

thanks, ill look into it!

[pfg]

HSTS preloading enforces "includeSubDomains" for all domains that are submitted[1]. It's certainly possible to use HSTS without includeSubDomains, but not preloaded HSTS, and since all new executive branch domains will be preloaded, that means all subdomains will have to support HTTPS as well.

[1]: https://hstspreload.org/