Comment by teddyh | Hacker News Reader

Comment by teddyh | Hacker News Reader

Reasons this is significant, IMHO:

• Most importantly, it makes fallback and load-balancing available for regular people; just spin up an extra web server somewhere else and add it to the DNS, just like a secondary MX. Mostly no need for a CDN anymore.

• The importance of SNI is lessened, since the DNS can now point to a port number as well as a host name. This makes it possible to have web server configurations without an enumeration of all server names; just have the web server use a certificate from a file and listen to the correct port number – no need to configure host names.

• The possibility to have separate web sites use different ports makes process isolation easier without having to go through a gateway host.

• It frees the apex DNS domain name from having to have an IP address; an IP address is harder to keep updated than a simple host name of a web server.

In summary, these things either make it easier to live on today’s internet without Google, Cloudflare, or other centralizing actors, or they make it easier for the smaller web hosting providers, or both.

I don't get your first point. CDNs are about content distribution, not load balancing. And you can already add multiple web servers to your A/AAAA record, that is still available to regular people. I believe different DNS providers even shuffle the order of the result to get clients to change up their connections

The different port thing is something that won't ever happen because the big players in the industry are petrified of the "middlebox bogeyman" and they won't allow any changes to web infrastructure that would make their jobs difficult, even if it would work fine for everyone else. We are doomed to use 443 for eternity.

We could just change the DNS spec to stop the apex madness. I don't know why nobody ever did, other than keeping the status quo.

I’m assuming the op is referring to relying on a commercial CDN provider’s anycast implementation but I could be mistaken.

> We could just change the DNS spec to stop the apex madness. I don't know why nobody ever did

If you mean changing how CNAME works, that can't be done in a backwards compatible way. If you mean adding a new record type, well that is exactly what this RFC does. There have been previous attempts to make RFCs that fix the apex problem, but this is the only one to get beyond a draft. I do think it is odd that it was grouped together with a bunch of other functionality instead of having a dedicated ANAME record type.

I don't know why it took so long to fix the apex problem.

> CDNs are about content distribution, not load balancing.

For you, maybe, but many people use a CDN and related services as a form of protection from web server overload.

> We are doomed to use 443 for eternity.

Do you write your applications for Win32? There have been many such proclamations made in the past, and they have all, slowly but surely, mostly gone away. Just try to browse the web using a really old browser or operating system. You can’t do anything, since most web sites require TLS1.0 or later.

> We could just change the DNS spec to stop the apex madness.

We did. This is the RFC which did it.

I'm not convinced about the port stuff.

Until support is well over 99%, using a custom port will mean your website is simply inaccessible to some visitors. Even worse, a link which works perfectly fine on one computer will simply be completely broken on another, without any kind of warning or explanation. It's like trying to host a website on IPv6-only in 2023: nice idea, just not viable in practice.

Besides, weren't the issues with SNI supposed to be solved with ESNI and Encrypted ClientHello?

Of course you have to maintain a backwards-compatible gateway proxy. But since most clients will not use it, and since it is obvious that it will be possible to remove it at some time in the future, this is, IMHO, acceptable.

> Besides, weren't the issues with SNI supposed to be solved with ESNI and Encrypted ClientHello?

Has that been implemented and/or standardized yet?

AFAIK that proposal got dropped in favor of ECH, which isn't standardized yet [0].

[0] https://blog.cloudflare.com/announcing-encrypted-client-hell...

Although it is not fully standardised, Firefox 119 and later should have it work [1]. It's now up to server implementations to get there as well.

[1] https://defo.ie/ech-check.php

It seems to me this could also be an advantage for websites which want to make themself inaccessible in these circumstances. An enterprise which firewalls things so only port 443 is allowed out is also more likely to do corporate MitM of all traffic. Historically I was definitely annoyed that browsers chose to make custom root CAs an implicit exemption from HPKP (even if HPKP is now history). I'd certainly consider DoSing my own site under likely MitM conditions. Using a different port also makes it harder for organisations to successfully do this kind of filtering in the future if it becomes widespread.

Another advantage is to prevent other kinds of blocking, which are based on blacklisting specific ports rather than only allowing port 443. Many residential ISPs and even hosting providers now engage in the flagrant net neutrality violation of blocking port 25; if use of SVCB records became common to allow a different port to be used, it would let other ports be used for site-to-site email, allowing email domains to contribute to rendering this blocking ineffective. Of course I'm not aware of any plan to adopt SVCB for email yet. But TBQH as someone who's always lamented the Internet's lack of a decent service lookup mechanism and the limitations (and lack of adoption) of SRV records, I'd like to see SVCB adopted for pretty much everything in future.

Fundamentally the use of well known ports was always a mistake, and really was just a crutch which was entirely the product of the internet's lack of any real service discovery mechanism, aside from the late, extremely underused and very limited DNS SRV mechanism. Ports are a mere implementation/routing detail and should not have any semantic meaning whatsoever. The time when organisations can do port-based filtering is coming to an end, fortunately. (Even if they do continue with it, the ability to now move practically everything to port 443 makes it increasingly meaningless in terms of achieving whatever they thought they were hoping to achieve.)

> Until support is well over 99%, using a custom port will mean your website is simply inaccessible to some visitors. Even worse, a link which works perfectly fine on one computer will simply be completely broken on another, without any kind of warning or explanation.

Welcome to my world. Some websites are blocked by my provider. Some websites are blocking my provider and inaccessible to me. And I'm not talking about something weird, things like w3c.com and istio.io were blocked at some periods of time for me.

You want a working Internet? You need to use VPN. I don't think that anyone will evade that.

The RFC generally looks to be so substantially useful that I'd expect pretty swift adoption in platforms/browsers, so while the custom port thing may not be useful immediately, that will probably change within a few years (which is the blink of an eye in RFC time ;)

I am not that optimistic.

HTTP have lots of embedded usage.

> I'd expect pretty swift adoption in platforms/browsers

I am hopeful but sceptical. No browser implements it fully yet, AFAIK.

> • Most importantly, it makes fallback and load-balancing available for regular people; just spin up an extra web server somewhere else and add it to the DNS, just like a secondary MX. Mostly no need for a CDN anymore.

That's IF browsers implement this. Browser devs are typically very reticent to add yet more DNS lookups (latency!) to the page loading process.

That was the argument against SRV records. But SVCB/HTTPS records can have extra information in them which can shortcut the HTTP/3 handshake, which will save time.

Reply on news.ycombinator.com