[Pdns-users] dp.variable when changing RPZ policy action?

[MRob]

On 2018-04-17 07:00, Brian Candler wrote:
> On 17/04/2018 06:42, MRob wrote:
>> But this example for modifying policy actions does not set 
>> dq.variable:
>> https://doc.powerdns.com/md/recursor/scripting/#modifying-policy-decisions
> 
> The documentation is very clear as to what dq.variable does: in the 
> same page,
> 
> https://doc.powerdns.com/md/recursor/scripting/#the-dnsquestion-dq-object
> 
> "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
> here:
> https://doc.powerdns.com/md/recursor/performance/#recursor-caches
> 
> 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.
> 
> https://doc.powerdns.com/md/recursor/settings/#packetcache-ttl
> 
> You can also globally disable the packet cache:
> 
> https://doc.powerdns.com/md/recursor/settings/#disable-packetcache

Thank you for helping. Part of the problem for me I think was to clarify 
criteria and timing for the cache. Now I understand, it seem to be the 
based on exact query parameters and the answer sent on the wire after 
all code and policy has finished.

In continue of the scenario you describe, even if TTL expires and Lua 
code executes again to finally give correct answer, whoever makes this 
fresh query causes the cache to fill again and the same stale problem 
starts over. So unless clients are send slight different query (which 
cannot be predicted unless you have strict control of all devices) 
dq.variable is certain to be necessary here just like the other example.

THank again Brian.