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/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pdns-users mailing list [email protected] https://mailman.powerdns.com/mailman/listinfo/pdns-users
