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

[Remi Gacogne]

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.

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.
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.




Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20170803/61cb0b4e/attachment.sig>