> > I'm aware of this and don't consider it an issue. It is doing best > > effort for ECS queries to non whitelisted servers, but does not go the > > extra mile to get an optimal answer. A quick explanation on what is > > happening: > > >> at 1) the query is not in the cache, a full recurse is started. Since > > you don't have the particular authority whitelisted no ECS is passed > > to it. The answer will end up in the regular cache. Subsequent queries > > are looked up in that cache directly without going to the whole module > > chain, making it cheap. > > >> at 2) ECS is passed in the query, this time the initial cache lookup > > is skipped as ECS queries are in a secondary cache. Of course this > > cache is empty and thus a full recurse is started. This recurse grabs > > records from the cache as much as possible and indeed, the record is > > in the cache and no packets need to go over the wire. > > This creates an issue where you have a user coming in with ecs 1.2.3.0/24gets the correct answer, then user coming without ecs get the default answer and finally user with ecs 1.2.4.0/24 get default instead of the correct answer. To me and for my use this is a major show stopper. Is there anyway the look up order could be reversed if ecs is enabled? So that all queries first try ecs then goto normal cache?
Thanks, Larry -Larry On Fri, May 2, 2014 at 4:55 PM, Yuri Schaeffer <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Larry, > > Thank you, this is very useful indeed! > > > 1) The returned record does not update based on geoip when using > > different subnets. This happen only when the first request a given > > name does not have a client subnet passed with it: > > > > 1) dig: answer x 2) dig +client: answer x (110.232.0.0/24/0) 3) > > flush cache 4) dig +client: answer y (110.232.0.0/24/19) > > I'm aware of this and don't consider it an issue. It is doing best > effort for ECS queries to non whitelisted servers, but does not go the > extra mile to get an optimal answer. A quick explanation on what is > happening: > > at 1) the query is not in the cache, a full recurse is started. Since > you don't have the particular authority whitelisted no ECS is passed > to it. The answer will end up in the regular cache. Subsequent queries > are looked up in that cache directly without going to the whole module > chain, making it cheap. > > at 2) ECS is passed in the query, this time the initial cache lookup > is skipped as ECS queries are in a secondary cache. Of course this > cache is empty and thus a full recurse is started. This recurse grabs > records from the cache as much as possible and indeed, the record is > in the cache and no packets need to go over the wire. > > Had the server been whitelisted, unbound would have sent ECS to it in > step 1). And the answer would not end up in the regular cache. > > > 2) The TTL returned when edns-subnet is passed does not change over > > time: 3) unbound-control marks all edns-subnet hits as misses: > > Indeed! I had not considered this before. I see what I can do after > the weekend. Thanks for reporting your findings. > > Regards, > Yuri > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Icedove - http://www.enigmail.net/ > > iEYEARECAAYFAlNkMGIACgkQI3PTR4mhavhdhwCgwFqfYZUtbUJhNrZ2bljhOqJA > 9zoAnRnmH3FAA25iclZIQ0RdlyqbZYoy > =HPAS > -----END PGP SIGNATURE----- >
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
