Comment by c45y

5 days ago

I would love it if more systems just understood SRV records, hostname.xyz = 10.1.1.1:2222

So far it feels like only LDAP really makes use of it, at least with the tech I interact with

5 comments

c45y

Reply
otterley  4 days ago

Even with SRV records, there’s still the problem of middleboxes restricting protocol traffic to certain ports. (There’s another comment thread in which we discuss this.) In practice, SRV records work much better inside network borders than on the larger Internet.

geocar  5 days ago

This has history: https://egopoly.com/2008/02/ssh-slow-on-leopard.html

I also know of https://github.com/Crosse/sshsrv and other tricks

I agree more SRV records would have helped with a tremendous number of unnecessary proxies and wasted heat energy from unnecessary computing, but in this day and age, I think ECH/ESNI-type functions should be considered for _every_ new protocol.

  • ComputerGuru  4 days ago

    SRV is essentially a simple layer of abstraction that provides (via one approach) the required end result (reachability + UX) that is easy to add to any $PROTO client without. Supporting ESNI would complicate the actual lib/protocol, increase the amount of dev and maintenance work required all around, significantly increase complexity, and require more infrastructure and invasive integration than any DNS-enabled service already uses.

jiehong  5 days ago

It’s also similar with mDNS on local networks. It’s actually nice!

Overall, DNS features are not always well implemented on most software stack.

A basic example is the fact that DNS resolution actually returns a list of IPs, and the client should be trying them sequentially or in parallel, so that one can be down without impact and annoying TTL propagation issues. Yet, many languages have a std lib giving you back a single IP, or a http client assuming only one, the first.