dnsdist: cache miss when all tcp only backends are down

[pizchen]

I have setup my cache DNS A record TTL to 1 day, and created a tcp only backend.
My query (udp client) goes smoothly, first time query is sent to DNS server and received answer. Following queries are hitting cache successfully.
However, if I put the server down (the only server in the pool), while the cache still in valid state, then I see all next queries (from udp clicent) hit cache miss.

I dig into this issue and seems it is related to the cache key usage, it seems the cache key is including a bool value that indicating if the query is forwarded over UDP to backend. In my case, if downstream server is available, that flag is set to false (since tcp only is used for the selected backend). However, if server is down and no selected backend, then the flag is set to true (udp client). In this case the calculated cache key would be different, thus caused cache miss.

Any reason that we shall include such a flag into cache key calculation? Shouldn't the same cache be used no matter what transport is to be used for backend? Any suggestion to work around this?

[pizchen]

I think this might be a bug, shall I go ahead to create a bug report?

[rgacogne]

Caching is complex. A UDP result can differ from a TCP result, as the maximum sizes differ.

Maximum size and truncation policy, yes.

[pizchen]

Thanks for replies, #15337 is created

[pizchen]

Caching is complex. A UDP result can differ from a TCP result, as the maximum sizes differ. So the cache key must include a UDP/TCP bit. Still, what you are seeing does not feel right, so please open an issue.

I understand other factors for cache key calculation, while still not sure if transport type should be one. If a pool has both tcpOnly and udp servers, and if those servers are serving the same zone with the same RRs, then we'll be caching twice for the same RR.

[rgacogne]

In your example, you might get a truncated answer (TC bit set, no records in answer, authority or additional sections) from a UDP server. If the incoming query was received over UDP, we can forward that answer to the client, but if the incoming query was received over TCP the client is going to be very confused, so we can't do that. In practice it's even more complicated than that because we can forward some queries received over a TCP-based protocol (for example DoH) using UDP, making the logic quite complex. Right now the logic is that we always assume that a query received over UDP will be forwarded over UDP unless we have selected a server that is TCP-only, because it's the only safe approach.

[pizchen]

Yes, for different upstream protocol we shall take differnent actions based on received response, i.e. TC bit handling. However, I think that would be done after response is ready (received from downstream or hit cache result).
I see DoH is searching cache twice already, if no other good solution, might be an alternative.