Bugzilla – Bug 1247
unbound does not shorten source prefix length when forwarding ECS
Last modified: 2017-05-30 15:26:42 CEST
I've tested this trunk rev 4088.
I built unbound with --enable-subnet and configured it with following lines:
module-config: "subnetcache validator iterator"
If I send a query to unbound with an ECS option whose source prefix
length is larger than 24 (e.g. 31), unbound forwards the ECS option
without changing the source prefix length. Is this intentional? If
so, I think the documentation should clarify that max-client-subnet-ipv4
is different from the "server's maximum cacheable prefix length" as
described in the following part of RFC7871, Section 7.1.1:
If the triggering query included an ECS option itself, it MUST be
examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's
outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of
the incoming query's SOURCE PREFIX-LENGTH or the server's maximum
cacheable prefix length.
Also, there seems to be a typo in unbound.conf.5:
.B max\-clienti-subnet\-ipv4: \fI<number>\fR
this should be
.B max\-client-subnet\-ipv4: \fI<number>\fR
It was intentional in the initial (pre-RFC) implementation, and was never updated when that part was added to the document.
I have changed the code to be more RFC compliant, the ECS source prefix in queries is now always limited to the configured value.
Thanks for reporting.
Damn, I fixed that in #1251 around the same time..... all is not lost, I have written a unittest for it that you can add to the collection. There is also a minor unbound.conf update along with it.
*** Bug 1251 has been marked as a duplicate of this bug. ***