Don't get me wrong, I think stub resolver logic is stuck in the 1980s!
If your app or device doesn't have such a history, and no way to obtain it, then maybe the server can do it based on what it knows about its history with IP addresses "close" to yours (the EDNS kludge).
> It doesn't respond. What do I do now? Tell the user ycombinator.com is down? Try another one? All of this could be defined by a standard
I would argue the DNS is clear about this from its own behavior: it tries another one.
Although it's not clear from `pydoc3 socket.create_connection`, it's pretty clear from https://docs.python.org/3/library/socket.html#creating-socke... that socket.create_connection() that it will "...try to connect to all possible addresses in turn until a connection succeeds."
So I would say that the correct action would be to try all possible addresses until one succeeds.
Well, there was an RFC (found it, RFC 3484) that told you to pick the one closest to your network (which wouldn't make a difference in this case, unless you were in say 13.225.214.0/27 or so). But that's not actually helpful, because given two destination IPs, one in the same /8 as me, and one not, I don't have any information that would help me determine which is a better choice.
From experience, most browsers will try a couple IPs before showing an error message, but that's not standard. If you have a fancy authoritative server, a lot of traffic, and a bunch of server IPs, you can get OK balancing by telling some clients some IPs and some clients other IPs; but it depends on having enough diversity in recursive servers; if all of your users are coming from one mobile ISP, chances are you won't get a lot of balancing.
(And I'm sure you already know all this :)
Better to have clients with a bit of intelligence. :)
If you're talking about subprotocols/versions of HTTP like HTTP2 then you can define subservices, so you could have _http2._http. But no one has proposed that yet :)
Of course with anycast, multiple A records can be redundant :)
For example, consider the case where you resolve ycombinator.com. You get:
Which of those hosts should I open a TCP connection to to begin speaking TLS/ALPN/HTTP2? The standard doesn't say. I would like a standard that says what to do. (The more interesting case is, say I pick 13.225.214.21 at random. It doesn't respond. What do I do now? Tell the user ycombinator.com is down? Try another one? All of this could be defined by a standard ;)