[Pdns-users] pdns recursor edns-client-subnet caching problems

[Shawn Zhou]

> On Aug 3, 2017, at 1:23 PM, Remi Gacogne <remi.gacogne at powerdns.com> wrote:
> 
> On 08/03/2017 07:38 PM, Shawn Zhou wrote:
>> Your explanation makes sense but that still doesn't explain the original
>> problems I see with pdns. see [1]. When pdns received the response for
>> the 1st query, it should have a cache entry for scope prefix-length of
>> 16 (btw, why don't I have that information when I dig against pdns?).
>> When the 2nd query was fired against pdns, it recurses and get a
>> response. Shouldn't it has a different cache entry as there is no edns
>> client in the lookup so there is no scope prefix-length return at all?
>> The 3rd query should've returned the same IP as the 1st query as subnet
>> provided was the same.
> 
> Yes, you are right, this is known behavior in 4.0.x, we don't use
> subnet-specific entries as soon as we get an entry usable for all subnets.
> 

Will 4.0.x be updated to address the problem?

> 4.1.0 handles its subnet-specific cache entries differently, and uses
> the existing subnet-specific entries it has in cache even if it also has
> an entry usable for all subnets. However it will not try to get a more
> specific entry since the one it has is already valid, so if you get an
> entry usable for all subnets first we won't try to get subnet-specific
> one until it expires.

The 4.1 release from "http://repo.powerdns.com/ubuntu xenial-rec-41 main" didn’t work well for me because
I was getting timed outs. Maybe my configs need updates but they work for 4.0.

root at DFW01-CPS01:~# /etc/init.d/pdns-recursor restart
 * Restarting PowerDNS recursor pdns-recursor
Aug 03 20:58:14 PowerDNS Recursor 4.1.0-alpha1 (C) 2001-2017 PowerDNS.COM BV
Aug 03 20:58:14 Using 64-bits mode. Built using gcc 5.4.0 20160609 on Jul 18 2017 13:15:53 by root at 24d7ea40a89f.
Aug 03 20:58:14 PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2.
Aug 03 20:58:14 Reading random entropy from '/dev/urandom'
Aug 03 20:58:14 If using IPv6, please raise sysctl net.ipv6.route.max_size, currently set to 4096 which is < 16384
Aug 03 20:58:14 NOT using IPv6 for outgoing queries - set 'query-local-address6=::' to enable
Aug 03 20:58:14 Only allowing queries from: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fc00::/7, fe80::/10
Aug 03 20:58:14 Will not send queries to: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fc00::/7, fe80::/10, 0.0.0.0/8, 192.0.0.0/24, 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 240.0.0.0/4, ::/96, ::ffff:0:0/96, 100::/64, 2001:db8::/32, 0.0.0.0, ::
Aug 03 20:58:14 PowerDNS Recursor itself will distribute queries over threads
Aug 03 20:58:14 Inserting rfc 1918 private space zones
Aug 03 20:58:14 Listening for UDP queries on 127.0.0.1:53
Aug 03 20:58:14 Enabled TCP data-ready filter for (slight) DoS protection
Aug 03 20:58:14 Listening for TCP queries on 127.0.0.1:53
Aug 03 20:58:14 Calling daemonize, going to background
   ...done.
root at DFW01-CPS01:~# dig @localhost +subnet=52.57.28.138 morpheus-ien.insnw.net

; <<>> DiG 9.11.0-P3 <<>> @localhost +subnet=52.57.28.138 morpheus-ien.insnw.net
; (2 servers found)
;; global options: +cmd
;; connection timed out; no servers could be reached
root at DFW01-CPS01:~# grep -v \# /etc/powerdns/recursor.conf | sed '/^$/d'
config-dir=/etc/powerdns
ecs-ipv4-bits=16
edns-subnet-whitelist=insnw.net
local-address=127.0.0.1
loglevel=9
setgid=pdns
setuid=pdns
use-incoming-edns-subnet=yes


> But IMHO this is a bug in the authoritative server and not in PowerDNS
> recursor, because I don't think the authoritative server should ever
> send a scope 0 answer if it has subnet-specific entries for that
> qname/qtype. Otherwise there is no way for the recursor to know whether
> more specific entries might exist, meaning it would have to try to get
> one even if it has an entry valid for all subnets in cache. For obvious
> performance reasons, we want to avoid doing that as much as possible.
> 

I think your points are valid. Does PowerDNS authoritative server handles
this probably? If so, I like to try it out.


> 
> 
> 
> Best regards,
> -- 
> Remi Gacogne
> PowerDNS.COM BV - https://www.powerdns.com/
> 
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users