-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > At this point Unbound has a CNAME that is ECS specific and an A > that is not. It will use the 0 scope for the CNAME as well as the A > and cache the response.
Well, you say that. But the trace shows that the A answer was in fact ECS specific. (it indicated a scope of /0). > Probably not the result the owner of example.com was intending. Indeed and I'm sure ignoring the ECS option from the A response would solve your problem. But I don't think that is the right thing to do. A middle ground _could_ be taking the maximum scopemask from the whole cname chain. This will tell you how many bits where used/asked to come to this final answer. I find it quite elegant and makes sense. Changing this one 'small' thing however will result in a completely different behaviour and answer. Since the draft does not cover this topic at all I worry we are introducing something that might be incompatible with other (future) implementations. If you base your setup on Unbound with ECS you'll break it horribly if you try to replace it with something else even tough that something implements the very same protocol. For me that last part is a red flag and makes me reluctant to start coding a solution right away. I'd be much happier when the document would include text on this matter. //Yuri -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVMcmgACgkQI3PTR4mhavibqwCghQajbdkucAe8A9Ewa5nq9lE3 hz0AoIMu1Ly10J9NcGDh5Yh7ZSgV255w =pgLQ -----END PGP SIGNATURE----- _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
