It's actually interesting how we didn't go there for the web, although it is likely that we will in the next decade or so.
By the time Tim built his toy hypermedia system ("the World Wide Web"), DNS had a sensible mechanism which could have been used to deploy it cleanly. But that wasn't done. So, first HTTP means "just look up the A record for the name and connect on TCP port 80" and then HTTPS meant "look up the A record, connect TCP 443". Today you also need to check AAAA (for IPv6) and you need to use ALPN to say what kind of HTTPS you speak, but otherwise things remain much the same.
However we have a pile of things we want to do in the near future that don't fit this model very well. HTTP/3 support (ie HTTP over QUIC) would ideally be discovered as early as possible for best performance, and Encrypted Client Hello (technology to a void revealing the names of sites you're visiting to an eavesdropper) really wants to fetch from DNS quite a lot of information too.
So there will likely be a new DNS record for basically "I want to connect over HTTPS to this DNS name" the same way the MX record means "I want to send email to this DNS name".
Ordinarily this would be a huge deployment nightmare, because we know crap DNS implementations can't do new DNS features. The specification for DNS is clear that if somebody asks "What's the WONKABAR for some.name you control?" and you've got no idea what a WONKABAR is you say there isn't one. But lots of bad software has been written that will break out, and either crash, silently drop the question or reply by reporting that there was a server error, none of which is correct.
However, fortunately the DNS privacy protocols give us a chance to reset expectations. Comcast's deal to get their DoH servers used in Chrome (for Comcast customers obviously) requires that they implement DNS properly, not half-arse it. So that's millions of customers brought on board by contractual obligation just for one example.
By the time Tim built his toy hypermedia system ("the World Wide Web"), DNS had a sensible mechanism which could have been used to deploy it cleanly. But that wasn't done. So, first HTTP means "just look up the A record for the name and connect on TCP port 80" and then HTTPS meant "look up the A record, connect TCP 443". Today you also need to check AAAA (for IPv6) and you need to use ALPN to say what kind of HTTPS you speak, but otherwise things remain much the same.
However we have a pile of things we want to do in the near future that don't fit this model very well. HTTP/3 support (ie HTTP over QUIC) would ideally be discovered as early as possible for best performance, and Encrypted Client Hello (technology to a void revealing the names of sites you're visiting to an eavesdropper) really wants to fetch from DNS quite a lot of information too.
So there will likely be a new DNS record for basically "I want to connect over HTTPS to this DNS name" the same way the MX record means "I want to send email to this DNS name".
Ordinarily this would be a huge deployment nightmare, because we know crap DNS implementations can't do new DNS features. The specification for DNS is clear that if somebody asks "What's the WONKABAR for some.name you control?" and you've got no idea what a WONKABAR is you say there isn't one. But lots of bad software has been written that will break out, and either crash, silently drop the question or reply by reporting that there was a server error, none of which is correct.
However, fortunately the DNS privacy protocols give us a chance to reset expectations. Comcast's deal to get their DoH servers used in Chrome (for Comcast customers obviously) requires that they implement DNS properly, not half-arse it. So that's millions of customers brought on board by contractual obligation just for one example.