[Pdns-users] dp.variable when changing RPZ policy action?
b.candler at pobox.com
Tue Apr 17 07:00:09 UTC 2018
On 17/04/2018 06:42, MRob wrote:
> But this example for modifying policy actions does not set dq.variable:
The documentation is very clear as to what dq.variable does: in the same
"variable - a boolean which, if set, indicates the recursor should not
packet cache this answer."
If you are not familiar with the packet cache, it is described briefly
Aside: you should be aware that the packet cache can result in some
slightly odd behaviour when an authoritative record changes. I have
seen two different clients sending queries with two different versions
of the "dig" utility: for a while, one client consistently sees the old
record and one consistently sees the new record. This is because the
two different versions of dig were sending queries with slightly
different options in the query, so there were two different entries in
the packet cache. Of course, everything eventually sorts itself out
when the packet cache entries expire.
Anyway, you would only set dq.variable to true if you want to return
*different* answers to the *same* query - for example, you want to
return different answers depending on which client makes the query.
Without this, the packet cache layer would mean that the subsequent
queries don't even arrive at your LUA code for a while, which is very
good for efficiency, but means that all clients sending identical
queries will see the same answer.
If you leave dq.variable as false, then of course you can still change
your responses in your LUA code or policy files; but the packet cache
will continue to serve the old answers for a while, so there may be a
delay before clients start seeing the updated responses.
I believe that packet cache will serve the old answer for as long as the
TTL in the original response, or for packetcache-ttl (default 3600),
whichever is the smaller.
You can also globally disable the packet cache:
More information about the Pdns-users