[Unbound-users] edns client subnets

[Yuri Schaeffer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Larry,

> This creates an issue where you have a user coming in with ecs 
> 1.2.3.0/24 gets 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.

Did you test this?

I believe this is not what would happen. The final user asking for ecs
1.2.4.0/24 would get an answer from the ecs cache. In case it was not in
cache an upstream lookup would be done with ecs 1.2.4.0/24. Yielding the
most accurate response.

Also, I'd like to stress that an answer from the 'regular' cache is not
wrong, merely suboptimal. It is what a non ECS aware resolver would
answer.

Please note there is no need for the clients to 'speak' ECS. When you
whitelist a server to do ECS Unbound will ask it for the most specific
answer for its client. Relaying ECS, specially to non-whitelisted
servers is a courtesy to the client and not mandated by the draft.

> To me and for my use this is a major show stopper.

I'm interested in your usecase and what functionality you are looking
for. What do you expect from a recursor? Do you not intent to use the
whitelist functionality?

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

While possible it would affect every single incoming query. It is
assumed ECS is only communicated with a fraction of authority servers.
It would mean a significant performance hit, especially since the ECS
cache is not a straight forward key:value lookup.

Best regards,
Yuri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlNorSsACgkQI3PTR4mhavhdeACfUpkA6wiZMnzgTbgN/ZKcYL65
JdkAniIjFO1w00N3rnPU+Yy55C16Mx/X
=lk90
-----END PGP SIGNATURE-----