Perfect example. :-) There's not enough information to make a considered response, unless you've got a history of opening TCP connections to them to base a deci

Perfect example. :-) There's not enough information to make a considered response, unless you've got a history of opening TCP connections to them to base a decision on. 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-sockets 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.