Unbound generates header-only REFUSED responses

[Yorgos Thessalonikefs]

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 at lists.nlnetlabs.nl 
> <mailto:unbound-users at 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
>