In that stage (refusing/dropping based on ACL) Unbound wants to refuse
as early as possible and skipping any unnecessary steps like parsing
more than the header. Since the request is coming from an unwanted
client, explicitly configured in Unbound with access control.
With the support for Extended DNS Errors (RFC8914), Unbound now has to
add an EDNS option to the packet, meaning a full DNS packet is required.
So setting 'ede: yes' would return the QUESTION section since now
Unbound has to parse more than the header to be able to attach the EDNS
record. Don't know if it is useful in your case though.
Best regards,
-- Yorgos
On 09/07/2024 20:28, Frank Cusack via Unbound-users wrote:
From the bugzilla:
> This is tough situation
Well I'm not understanding what's tough. You have the ip:port as well.
Client txn ID should be random so within a small timeout this should be
easily and reliably matched?
I'm just a user not an unbound dev but IMO I wish the RFC (and its
updates) were more clear on this.
The only important aspect on response size (wrt best practice) is that
the response payload fits within a single UDP datagram. Since the
question is guaranteed to fit in 512 bytes, unbound is wrong here.
As a reference point, Windows Server stub resolver does the same thing
-- ignores header-only responses. Windows Desktop however will match.
On Mon, Jul 8, 2024 at 6:52 AM Florian Weimer via Unbound-users
<unbound-users@lists.nlnetlabs.nl
<mailto:unbound-users@lists.nlnetlabs.nl>> wrote:
It's been reported that glibc does not recognize REFUSED responses
generated by Unbound with this configuration:
server:
interface: 0.0.0.0
access-control: 0.0.0.0/0 <http://0.0.0.0/0> refuse
Our bug report is here:
DNS stub resolver ignores header-only error responses
<https://sourceware.org/bugzilla/show_bug.cgi?id=31890
<https://sourceware.org/bugzilla/show_bug.cgi?id=31890>>
I've got a fix, but it goes somewhat against what I think are current
stub resolver practices: do not ignore the question section for response
matching. Are my expectations just wrong? Is it more important for
servers to produce smaller responses?
Thanks,
Florian
