3 ms·

> servers will do 'collapsed forwarding', [...] perhaps that's just wishful thinking on my part I think it is wishful thinking, because that would basically be

> servers will do 'collapsed forwarding', [...] perhaps that's just wishful thinking on my part I think it is wishful thinking, because that would basically be caching which is not allowed by the RFC. In 2017 the BIND implementation changed to a default cache time of 1s which would certainly ease the problem. > then you have port limits, usually each request goes out on a new port, a recursive resolver can only have 64k I'm unsure if this helps or worsens the situation, depending if the 'collapsed forwarding'/1s caching is in place. If this is not the case, ephemeral port exhaustion would kick in, at which point the DNS server will not be able to server other requests. > On the authoritative side, it's not too hard to manage this load Of course not, all you need to do is just present any response which will be cached by downstream resolvers. No smartphone/end user device will query the authoritative side as long as there is just any (even stale) response.

toast0 5y ago
> If this is not the case, ephemeral port exhaustion would kick in, at which point the DNS server will not be able to server other requests. You can use the same local ip/port to contact multiple server ip/ports, so filling up connections to FB ips shouldn't prevent you from connecting to others (but there are plenty of ways to do that wrong, I guess) >> On the authoritative side, it's not too hard to manage this load > Of course not, all you need to do is just present any response which will be cached by downstream resolvers. You need to present a response before the resolver times out. One can certainly imagine a situation where the incoming packet processing results in enough delay that the responses arrive too late and are discarded. In the right conditions, this queuing delay would never clear and things just get worse. If it doesn't happen, great, but if it does, dropping most of the requests so you can timely handle the few you accept is a good way to get moving.
- haimez 5y ago
  Good ol’ CoDel - https://en.m.wikipedia.org/wiki/CoDel https://en.m.wikipedia.org/wiki/CoDel

toast0 5y ago

> If this is not the case, ephemeral port exhaustion would kick in, at which point the DNS server will not be able to server other requests. You can use the same local ip/port to contact multiple server ip/ports, so filling up connections to FB ips shouldn't prevent you from connecting to others (but there are plenty of ways to do that wrong, I guess) >> On the authoritative side, it's not too hard to manage this load > Of course not, all you need to do is just present any response which will be cached by downstream resolvers. You need to present a response before the resolver times out. One can certainly imagine a situation where the incoming packet processing results in enough delay that the responses arrive too late and are discarded. In the right conditions, this queuing delay would never clear and things just get worse. If it doesn't happen, great, but if it does, dropping most of the requests so you can timely handle the few you accept is a good way to get moving.

haimez 5y ago
Good ol’ CoDel - https://en.m.wikipedia.org/wiki/CoDel https://en.m.wikipedia.org/wiki/CoDel