Re: web URI method

Phil,

For the specific use case you mention, the HTTPS record's "port"
SvcParamKey [1] seems to be precisely what you are looking for.

Safari and Firefox appear to implement this today [2], but Chromium does
not.  If you'd like to see it in Chromium too, you can upvote the feature
request [3] :-)

--Ben Schwartz

[1] https://datatracker.ietf.org/doc/html/rfc9460#name-port
[2]
https://indico.dns-oarc.net/event/52/contributions/1156/attachments/1092/2234/OARC44_%20DNSHTTPSStudy.pdf
(page 13)
[3] https://issues.chromium.org/issues/40257146

On Fri, Jun 5, 2026 at 10:12 AM Piers O'Hanlon <piers.ohanlon@bbc.co.uk>
wrote:

> Maybe you’re aware but RFC9460 HTTP/SVCB DNS does some of this already and
> has been implemented to varying degrees in the major browsers with Apple
> providing more comprehensive support. Though it can be tricky getting
> fallout behaviour correct if, for example, the path doesn’t full support
> QUIC.
>
>
>
> On 4 Jun 2026, at 18:54, Phillip Hallam-Baker <phill@hallambaker.com>
> wrote:
>
> *External: *Think before clicking
> One of my big regrets with HTTP is that it does not use the DNS SRV
> mechanism for service discovery. Which is hardly surprising because SRV was
> invented later. The mx record already existed and we didn't see the need.
>
> DNS round robin is a work-around that is totally inferior. But much water
> under the bridge, I cannot see how we get SRV to work reliably as a
> discovery mechanism for http:/https: at this point.
>
> But what if we assign a completely new method and define it as using the
> full DNS service discovery mechanism? So if someone enters web://
> example.com/ it will pull the DNS TXT and SRV records and work out that
> it should be using the QUIC protocol on host1.example.com port 783 or
> host2.example.com port 834.
>
> DNS service discovery is already a standard:
>
> https://www.rfc-editor.org/info/rfc6763/
>
>
> Now this might sound like it is too late to be of use to anyone but it
> could be enormously useful for Web services. And in particular for the use
> case where Web Services go off onto their own presentation protocol rather
> than piggybacking on HTTP which is designed to support Web browsing. Almost
> everything that HTTP does for Web Services is done by QUIC. But how do we
> provide a transition path?
>
> This would be of immediate use to me because I have a rather extensive
> home network with 80 active IP addressable devices (after a cull) and five
> static IP addresses. I have multiple services in the house on their own
> proxmox vm and I can reach each of them internally on port 443. If I want
> to expose them on the Internet I have to configure a reverse proxy which
> means unnecessarily introducing another point of failure and creates a
> bottleneck if I am running jellyfin or the like.
>
> With the web: URI method, I can set up my split horizon DNS so that I can
> type web://homeassistant.hallambaker.com/ and have it work either inside
> or outside the house without having to remember any port number.
>
> Inside the house:
>
> homeassistant 10.0.0.80:443
> jellyfin: 10.0.0.81:443
>
> Outside the house
>
> homeassistant 96.237.102.38:8123
> jellyfin: 96.237.102.38:8920
>
> web:/homeassistant.hallambaker.com/ and web://jellyfin.hallambaker.com/
> to work for both.
>
> The less I have to remember, the less chance of making an administrative
> glitch that costs me half an hour of working out what went wrong. (All
> computer errors are stupid mistakes after you find them.) In the short
> term, I have to use a browser extension for the web: method but that isn't
> hard. If other people find use, it will make its way into the stock
> browsers.
>
>
> While my setup is somewhat high end, I think we can do a lot better for
> the average consumer with some slightly more intelligent DNS services. I
> also think there are a lot of companies offering DynDNS today that could
> provide a lot more value if we did a bit of usability improvement.
>
> I can write up a draft, wanted some input from here first. It seems pretty
> obvious to me that the only possible use for web is something that is going
> to be a superset of http/https. But folk might have plans.
>
>
>