3 ms·

I remember looking into why A/AAAA is still used over SRV, and it would seem performance is one of the big concerns; browsers do not want to make more DNS looku

I remember looking into why A/AAAA is still used over SRV, and it would seem performance is one of the big concerns; browsers do not want to make more DNS lookups than necessary. I think they'd end up with 4 lookups; A, AAAA, SRV (_http2._tls), and SRV (_http._tls). Though perhaps you are suggesting DoH could mean the resolver also returns SRV records if you request A or AAAA? i.e. proactively point out there's an HTTP server?

SahAssar 6y ago
IIRC chrome is now racing QUIC and HTTP(2) connections instead of doing negotiation/upgrade to detect QUIC support. So this argument (if true) has fallen apart just a few years later.
- tptacek 6y ago
  Isn't that because QUIC doesn't overload 443/tcp, and sending a UDP packet is extremely cheap? It's not the packets that kill you, it's the round trip latency.
  - SahAssar 6y ago
    My point was that they could just as well race the DNS lookups, right?
    - yencabulator 6y ago
      That doesn't solve all the problems listed in https://news.ycombinator.com/item?id=23648497 https://news.ycombinator.com/item?id=23648497 and likely makes the buggy DNS resolver issue worse.
jiggawatts 6y ago
This debate comes up a lot, and it's hilarious how misguided it was. I regularly work with load-balancers such as Citrix ADC (NetScaler) or F5 BIG IP. These do DNS-based load-balancing, dynamically returning "A" records to that the browsers so that they can get the "single working IP address" they're expecting. The browsers don't try very hard to fail over to secondary IPs because this is the established standard architecture, but they don't need to because of this common setup. Sounds like an optimal solution, right? It does at first glance anyway, as long as you ignore the eye-watering price tag on those load balancer boxes. The subtle but critical issue is that by returning "A" records, the load balancers have to use a short time to live (TTL)! This is because there's a trade-off: You can have fast failover, OR long-lived DNS caching. With A records you can't have both! Typical response TTL times are 5-30 seconds, 5 minutes tops if you hate your users. This means that many browsers will be forced to repeatedly re-query the DNS servers on every page load for typical end-user workflows. It also means that for all but the biggest, most popular sites, the ISP DNS cache does practically nothing for these records. Meanwhile with SRV records the TTL times can be much higher, hours even. This is how Active Directory works, for example, all of the Domain Controllers add themselves to various SRV records so that if you query "_ldap._tcp.dc._msdcs.test.com" you get back all the DCs. These records include priorities and weightings, so you can pull tricks like incrementally demote a DC or prioritise the shiny new one. If you watch the AD connection traffic in WireShark, it's incredible. It very quickly steps through alternate services and then reorders the successful hits in front of the failures so that subsequent queries are lightning fast. It is astonishingly tolerant of partial networking failures, yet still fast to connect despite that! The key mistake made by the original DNS design working groups was that SRV records should have returned a list of IP addresses instead of a list of host names.
- deleted 6y ago
  [deleted]
- diroussel 6y ago
  Yes, there does seem to be something missing in the semantics of IP lookup. It ought to be a user agent can look up an IP with "keep using until it stops working" sematics. Or "choose one of these 3 IPs, can keep using the one you chose until there is a problem. Or something more similar to how we want client side site availablity logic to work.

SahAssar 6y ago

IIRC chrome is now racing QUIC and HTTP(2) connections instead of doing negotiation/upgrade to detect QUIC support. So this argument (if true) has fallen apart just a few years later.

tptacek 6y ago
Isn't that because QUIC doesn't overload 443/tcp, and sending a UDP packet is extremely cheap? It's not the packets that kill you, it's the round trip latency.
- SahAssar 6y ago
  My point was that they could just as well race the DNS lookups, right?
  - yencabulator 6y ago
    That doesn't solve all the problems listed in https://news.ycombinator.com/item?id=23648497 https://news.ycombinator.com/item?id=23648497 and likely makes the buggy DNS resolver issue worse.

jiggawatts 6y ago

This debate comes up a lot, and it's hilarious how misguided it was. I regularly work with load-balancers such as Citrix ADC (NetScaler) or F5 BIG IP. These do DNS-based load-balancing, dynamically returning "A" records to that the browsers so that they can get the "single working IP address" they're expecting. The browsers don't try very hard to fail over to secondary IPs because this is the established standard architecture, but they don't need to because of this common setup. Sounds like an optimal solution, right? It does at first glance anyway, as long as you ignore the eye-watering price tag on those load balancer boxes. The subtle but critical issue is that by returning "A" records, the load balancers have to use a short time to live (TTL)! This is because there's a trade-off: You can have fast failover, OR long-lived DNS caching. With A records you can't have both! Typical response TTL times are 5-30 seconds, 5 minutes tops if you hate your users. This means that many browsers will be forced to repeatedly re-query the DNS servers on every page load for typical end-user workflows. It also means that for all but the biggest, most popular sites, the ISP DNS cache does practically nothing for these records. Meanwhile with SRV records the TTL times can be much higher, hours even. This is how Active Directory works, for example, all of the Domain Controllers add themselves to various SRV records so that if you query "_ldap._tcp.dc._msdcs.test.com" you get back all the DCs. These records include priorities and weightings, so you can pull tricks like incrementally demote a DC or prioritise the shiny new one. If you watch the AD connection traffic in WireShark, it's incredible. It very quickly steps through alternate services and then reorders the successful hits in front of the failures so that subsequent queries are lightning fast. It is astonishingly tolerant of partial networking failures, yet still fast to connect despite that! The key mistake made by the original DNS design working groups was that SRV records should have returned a list of IP addresses instead of a list of host names.

deleted 6y ago
[deleted]
diroussel 6y ago
Yes, there does seem to be something missing in the semantics of IP lookup. It ought to be a user agent can look up an IP with "keep using until it stops working" sematics. Or "choose one of these 3 IPs, can keep using the one you chose until there is a problem. Or something more similar to how we want client side site availablity logic to work.