Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If SRV[1] records had been a thing sooner, we could have had our cake and eaten it, too. SRV records encode the protocol into the DNS entry. If you wanted the HTTP server for example.com, for example, you'd lookup the SRV record for _http._tcp.example.com. You get back the IP and port of the host to connect to.

If you had a hosting provider, you could CNAME _http._tcp.example.com to your hosting provider. Naked domains + CNAME works as expected.

(And you can weight records, assign priorities…)

[1]: https://en.wikipedia.org/wiki/SRV_record



No. The main issue here is cookie control, or, to be exact, the complete lack of one.

You can't tell user-agents "the cookie I set must be valid for example.org and websocket.example.org but no others" (the example is crude and non-scalable, real-world semantics of this must be different), which leads to all sort of problems. Heavier static media requests, mixed cookie state if you use staging.example.org for pre-production environment, inability to provide third parties subdomains for their UGC, etc etc. All can be solved but not really convenient.

Would there be a way to have good control over cookie scoping, a lot of hacks would be gone and www/non-www distinction would be purely cosmetic for most cases. Granted, not all, SRV records are still a good idea.


Consul service registry uses SRV records in this manner and it's fantastic.

However, on the wider internet with third party services it's much easier to manage and debug dedicated port numbers.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: