It would be interesting to set up an http/https server on an alternate port, as documented in section 7.2, and see how many connections it gets. Of course you would need a control using some other http/https server on an undocumented port, so you could tell the difference between connections from port scanners vs. DNS lookups.
Assuming you're running your own DNS server, you could also check the logs to see how many queries you get for the "port" SvcParamKey.
> Assuming you're running your own DNS server, you could also check the logs to see how many queries you get for the "port" SvcParamKey.
Any DNS responses for an HTTPS/SVCB record will always include all parameters, so you can't really test things that way. But I do run my own DNS server, and in the past 90 days, it issued 206 071 A responses, 122 314 AAAA responses, and 4 426 HTTPS responses, so HTTPS RR requests are still fairly rare.
Interesting. I also run my own DNS servers (for about two dozen domains). Over the past seven days, my servers logged 91923 A responses, 39667 AAAA responses, and 162 HTTPS responses, which comes to ~0.123%. I'm surprised it's that high.
Your numbers are more than 10 times higher than mine.
I have observed WWW browsers doing HTTPS lookups in my server logs, in 2025. Bad actors do them as well.
The sad thing is that the HTTPS resource record type will not upgrade HTTP directed to one domain into HTTPS directed to another domain. The RFC's examples (in section 10 and elsewhere) indicate that this should work. I made one of my WWW sites inaccessible to several modern WWW browsers for a day learning that in practice it does not.
One could view this as malicious compliance with section 9, as WWW browser writers have a decades long history, including the famous Chrome, Mozilla, and WebKit bugs, of fighting against DNS mechanisms that fix the apex problem.
A more charitable view is that, this being the 2020s, they simply did not give much attention to the case of HTTP. The idea exists on paper in the RFC, but in practice I wonder whether I am one of just a few people who has actually tried apex aliasing from HTTP to HTTPS (as opposed to aliasing from HTTPS to HTTPS).
It would be interesting to set up an http/https server on an alternate port, as documented in section 7.2, and see how many connections it gets. Of course you would need a control using some other http/https server on an undocumented port, so you could tell the difference between connections from port scanners vs. DNS lookups.
Assuming you're running your own DNS server, you could also check the logs to see how many queries you get for the "port" SvcParamKey.
My guess is it will be a very small number.
> Assuming you're running your own DNS server, you could also check the logs to see how many queries you get for the "port" SvcParamKey.
Any DNS responses for an HTTPS/SVCB record will always include all parameters, so you can't really test things that way. But I do run my own DNS server, and in the past 90 days, it issued 206 071 A responses, 122 314 AAAA responses, and 4 426 HTTPS responses, so HTTPS RR requests are still fairly rare.
Interesting. I also run my own DNS servers (for about two dozen domains). Over the past seven days, my servers logged 91923 A responses, 39667 AAAA responses, and 162 HTTPS responses, which comes to ~0.123%. I'm surprised it's that high.
Your numbers are more than 10 times higher than mine.
I have observed WWW browsers doing HTTPS lookups in my server logs, in 2025. Bad actors do them as well.
The sad thing is that the HTTPS resource record type will not upgrade HTTP directed to one domain into HTTPS directed to another domain. The RFC's examples (in section 10 and elsewhere) indicate that this should work. I made one of my WWW sites inaccessible to several modern WWW browsers for a day learning that in practice it does not.
One could view this as malicious compliance with section 9, as WWW browser writers have a decades long history, including the famous Chrome, Mozilla, and WebKit bugs, of fighting against DNS mechanisms that fix the apex problem.
* https://jdebp.uk/FGA/dns-srv-record-use-by-clients.html#HTTP...
A more charitable view is that, this being the 2020s, they simply did not give much attention to the case of HTTP. The idea exists on paper in the RFC, but in practice I wonder whether I am one of just a few people who has actually tried apex aliasing from HTTP to HTTPS (as opposed to aliasing from HTTPS to HTTPS).
These days it's often fine to not have anything on port 80 at all, just 443 is sufficient for browsers to discover / reach a website.
36 comments back in 2023: https://news.ycombinator.com/item?id=38420555