Handle caching with EDNS options better.

If we add the EDNS client subnet option, or the client's
MAC address, then the reply we get back may very depending on
that. Since the cache is ignorant of such things, it's not safe to
cache such replies. This patch determines when a dangerous EDNS
option is being added and disables caching.

Note that for much the same reason, we can't combine multiple
queries for the same question when dangerous EDNS options are
being added, and the code now handles that in the same way. This
query combining is required for security against cache poisoning,
so disabling the cache has a security function as well as a
correctness one.
This commit is contained in:
Simon Kelley
2020-11-25 21:17:52 +00:00
parent 15b60ddf93
commit 25e63f1e56
4 changed files with 78 additions and 45 deletions

View File

@@ -692,8 +692,8 @@ still marks the request so that no upstream nameserver will add client
address information either. The default is zero for both IPv4 and
IPv6. Note that upstream nameservers may be configured to return
different results based on this information, but the dnsmasq cache
does not take account. If a dnsmasq instance is configured such that
different results may be encountered, caching should be disabled.
does not take account. Caching is therefore disabled for such replies,
unless the subnet address being added is constant.
For example,
.B --add-subnet=24,96