[Unbound-users] edns client subnets

[Larry Havemann]

>
> 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 <yuri at nlnetlabs.nl> 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-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20140505/1df0bc0d/attachment.htm>