3 ms·

> Curl also works correctly. First time it might not, but if you run the command twice, it always corrects to the nearest server. I always assumed curl was sta

> Curl also works correctly. First time it might not, but if you run the command twice, it always corrects to the nearest server. I always assumed curl was stateless between invocations. What's going on here?

barrkel 2y ago
My hypothesis: he's running on macOS and he's seeing the same behavior from Safari as from curl because they're both using OS-provided name resolution which is doing the lowest-latency selection. Firefox and Chrome use DNS over HTTPS by default I believe, which may mean they use a different name resolution path. The above is entirely conjection on my part, but the guess is heavily informed by the surprise of curl's behavior.
- hyperknot 2y ago
  Correct. I'm on macOS and I tried turning off DoH in Firefox and then it worked like Safari.
- plagiat0r 2y ago
  But this does not make sense. How Mac operating system resolver are supposed to test the latency of (A)ddress records? Browser use this network address to actually make a tcp connection on 443 and measure latency here. Or udp/443 when using http3/quic. But operating system resolver only speak with DNS servers. It does not make https connections to calculate latency which would pick "the closest server". Also dns had no way to tell what port you will be using, maybe service is on 8443 or something. For geo DNS I've built a custom backed for powerdns with geo DNS capabilities and healthckecks to quickly remove a broken vps from the DNS responses.
  - barrkel 2y ago
    If I had to hypothesize further, I'd say that macOS may let its DNS resolver cache interact with its TCP stack. It's not inconceivable that the TCP handshake is used to make a rough estimate of network latency.
    - plagiat0r 2y ago
      A bold hypothesis. The problem is, nowhere in the tcp handshake you will find the string, a.k.a fqdn. And one IP can host hundreds of fqdns. No way MacOS parse tls clienthello looking for SNI. Also I doubt a DNS resolver runs in the Mac kernel, ring 0 to pull this off. The thing with DNS is that it works on layer 3. Hold on, what? Yes, layer 3 because you obtain network address for layer 3 (ip4, ipv6) but latency can be measured only in layer4 (tcp, quic). Of course I know that common wisdom says DNS is a layer 7 but from functional perspective, you are yet to establish your destination network address, therefore functionally it's like layer 3 to me. Or even lower, because without destination, you can't even start creating a packet and inspecting your routing table entries figuring out if you can even reach it ;) There is zero chance Mac resolver libraries can connect you to the fastest responding server - unless there is no Berkeley sockets but something that allows you to do a connect(char * fqdn) and system library return you two pipes, one for write, other for read, and that you can close them independently. I doubt it there is such a thing, but don't know Mac os API.

barrkel 2y ago

My hypothesis: he's running on macOS and he's seeing the same behavior from Safari as from curl because they're both using OS-provided name resolution which is doing the lowest-latency selection. Firefox and Chrome use DNS over HTTPS by default I believe, which may mean they use a different name resolution path. The above is entirely conjection on my part, but the guess is heavily informed by the surprise of curl's behavior.

hyperknot 2y ago
Correct. I'm on macOS and I tried turning off DoH in Firefox and then it worked like Safari.
plagiat0r 2y ago
But this does not make sense. How Mac operating system resolver are supposed to test the latency of (A)ddress records? Browser use this network address to actually make a tcp connection on 443 and measure latency here. Or udp/443 when using http3/quic. But operating system resolver only speak with DNS servers. It does not make https connections to calculate latency which would pick "the closest server". Also dns had no way to tell what port you will be using, maybe service is on 8443 or something. For geo DNS I've built a custom backed for powerdns with geo DNS capabilities and healthckecks to quickly remove a broken vps from the DNS responses.
- barrkel 2y ago
  If I had to hypothesize further, I'd say that macOS may let its DNS resolver cache interact with its TCP stack. It's not inconceivable that the TCP handshake is used to make a rough estimate of network latency.
  - plagiat0r 2y ago
    A bold hypothesis. The problem is, nowhere in the tcp handshake you will find the string, a.k.a fqdn. And one IP can host hundreds of fqdns. No way MacOS parse tls clienthello looking for SNI. Also I doubt a DNS resolver runs in the Mac kernel, ring 0 to pull this off. The thing with DNS is that it works on layer 3. Hold on, what? Yes, layer 3 because you obtain network address for layer 3 (ip4, ipv6) but latency can be measured only in layer4 (tcp, quic). Of course I know that common wisdom says DNS is a layer 7 but from functional perspective, you are yet to establish your destination network address, therefore functionally it's like layer 3 to me. Or even lower, because without destination, you can't even start creating a packet and inspecting your routing table entries figuring out if you can even reach it ;) There is zero chance Mac resolver libraries can connect you to the fastest responding server - unless there is no Berkeley sockets but something that allows you to do a connect(char * fqdn) and system library return you two pipes, one for write, other for read, and that you can close them independently. I doubt it there is such a thing, but don't know Mac os API.