Maintained by: NLnet Labs

[Unbound-users] ends client subnet testing

DeJong, Steve
Fri May 8 15:53:40 CEST 2015

On 5/8/15, 1:23 AM, "Yuri Schaeffer" <yuri at> wrote:

>> 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).

Yes, that behavior is specified clearly in the draft.

"If the edns-client-subnet option in the request is not used at all, a
   server supporting edns-client-subnet MUST indicate that no bits of
   the ADDRESS in the request have been used by specifying a SCOPE
   NETMASK of 0, equivalent to the networks or ::/0.²
>> Probably not the result the owner of 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.

That may be a decent solution as well.

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

Agreed, there needs to be some clarity as there are multiple options for
behavior in this case.  And the Unbound implementation is currently
different than the observed behavior of

Thank you for taking a look and the responses.