The socket interface using IP addresses instead of DNS names is widely considered to be a major mistake.

asveikau 4 hours ago | parent | next [-]

I disagree with this. Separating lookup from connect(2) or sendmsg(2) is cleaner. If an application doesn't care about the difference, most people are using higher level APIs built on top anyway, and most of those will provide a quick way to hide DNS details from you.

▲

UltraSane 3 hours ago | parent [-]

https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/

A DNS name can have a LOT of A records associated but a socket has to pick one. This is a severe limitation.

	▲	drdexebtjl 3 hours ago \| parent \| next [-]
		A socket has to pick one, but your application doesn’t. You can hedge your bets and open a connection and send data to _all_ of them, and pick whichever returns faster. This of course requires you to know about the application-layer protocol. For HTTP, you need to restrict this strategy to GET methods, for example. Hence why it can’t be part of the socket interface. You can always build higher level abstractions on top of sockets if you need them.
	▲	jruohonen 3 hours ago \| parent \| prev [-]
		> This is a severe limitation. Rather, it is a feature.

▲

drdexebtjl 3 hours ago | parent | prev | next [-]

Absolutely not.

You can have sockets without DNS. You can pick whatever strategy you want when there are multiple A records. You can use SRV records instead. And most importantly imo, it mirrors the listening API.

▲

lelanthran 4 hours ago | parent | prev [-]

By who? I haven't seen this argument before.

▲

UltraSane 3 hours ago | parent [-]

https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/

	▲	ReactiveJelly 3 hours ago \| parent [-]
		Wouldn't this add a ton of complexity for anything that extends DNS, like DoH, DoT, VPNs, firewalls, etc., and you'd still need to connect by IP for LAN connections or P2P? Cause what you're asking is not just to do the regular DNS lookup inside `connect`, but to have the OS manage roaming and continuously updating DNS while the connection stays up? I don't know about that. I don't know. That's a lot of complexity deep in the kernel and ossified. I'm happy with the QUIC solution that allows you to migrate IPs and it's all userspace. It would be very hard to evolve a network protocol that had to be crammed into 3+ different kernels.