[Pdns-users] Workaround for PowerDNS Security Advisory 2014-02

[sthaug at nethelp.no]

> You can update auth-zones using 'rec_control reload-zones' at runtime
> without restarting the recursor, which will discover new zones to be blocked
> or no no longer blocked.

A couple of questions regarding reload-zones:

- Is PowerDNS recursor meant to have a coherent cache? The observed
behavior on my 3.6.2/FreeBSD 9.3 installation is that I have as many
caches as I have threads (as configured with "threads=..." in
recursor.conf). This is clearly visible on the TTL of the replies,
e.g. (querying the recursor rapidly about the same A):

% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7026    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7098    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7063    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7063    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7062    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7062    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7022    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7021    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7144    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7020    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7019    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7058    IN      A       10.0.0.1
% dig test4.nethelp.no @slam | grep 10.0.0.1
test4.nethelp.no.       7057    IN      A       10.0.0.1

Here we can see 4 different caches, each counting down the TTL. I can
also see it on the master name server, receiving a new query each time
I hit a thread which doesn't have this info cached.

- Is 'rec_control reload-zones' meant to reload zones defined with
forward-zones-file= in recursor.conf? The observed behavior is that
the change in forwarding only happens after TTL expires (and thus can
happen at different times for different threads, see also the point
above), e.g.:

% dig test4.nethelp.no @slam | egrep '10.0.0.1|127.0.0.1'
test4.nethelp.no.       23      IN      A       127.0.0.1
% dig test4.nethelp.no @slam | egrep '10.0.0.1|127.0.0.1'
test4.nethelp.no.       577     IN      A       10.0.0.1
% dig test4.nethelp.no @slam | egrep '10.0.0.1|127.0.0.1'
test4.nethelp.no.       20      IN      A       127.0.0.1
% dig test4.nethelp.no @slam | egrep '10.0.0.1|127.0.0.1'
test4.nethelp.no.       20      IN      A       127.0.0.1
% dig test4.nethelp.no @slam | egrep '10.0.0.1|127.0.0.1'
test4.nethelp.no.       576     IN      A       10.0.0.1
% dig test4.nethelp.no @slam | egrep '10.0.0.1|127.0.0.1'
test4.nethelp.no.       19      IN      A       127.0.0.1
% dig test4.nethelp.no @slam | egrep '10.0.0.1|127.0.0.1'
test4.nethelp.no.       575     IN      A       10.0.0.1
% dig test4.nethelp.no @slam | egrep '10.0.0.1|127.0.0.1'
test4.nethelp.no.       575     IN      A       10.0.0.1
% dig test4.nethelp.no @slam | egrep '10.0.0.1|127.0.0.1'
test4.nethelp.no.       574     IN      A       10.0.0.1
% dig test4.nethelp.no @slam | egrep '10.0.0.1|127.0.0.1'
test4.nethelp.no.       18      IN      A       127.0.0.1

where 127.0.0.1 comes from a forwarded zone, 10.0.0.1 is cached from
the authoritative name server, and I have recently done "rec_control
reload-zones" in order to remove test4.nethelp.no as a forwarded
zone.

This behavior is reproducible.

Steinar Haug, AS 2116