[dnsdist] Increasing c-hashing stickiness

Alexander Perlis aperlis at math.lsu.edu
Mon Mar 27 17:59:29 UTC 2023

In my understanding, c-hashing currently uses the entire QNAME to
choose the upstream resolver.

But don't we also want "related" QNAMEs (ones with the same SOA) to
end up at the same upstream resolver? Any needed glue or helpful
additional responses from upstream would be known to the recursive
resolver, but when a client turns around looking for that information
(if say the original client itself didn't capture and cache that
portion of the response, or if a different client happens to want that
piece of information), the client would be sending in a *different*
QNAME and thus might end up at a *different* resolver who wouldn't
already know the glue/helper information, thus unnecessarily eating
cache on that other resolver who additionally must first put
unnecessary load on origin servers.

Here might be a heuristic for identifying "related" QNAMEs: for QNAMEs
with more than 2 components (or more than 3 components when the last
component is a country code), just use those last 2 or 3 components.

Perhaps that's a dumb idea, but I thought it might be interesting to try it.

Is there an easy way to configure dnsdist to use only the last 2
components (or last 3 components when the last component is a country
code) for the QNAME hash in "c-hashing"?


More information about the dnsdist mailing list