Unbound generates header-only REFUSED responses

Florian Weimer fweimer at redhat.com
Wed Jul 10 11:13:33 UTC 2024


* Yorgos Thessalonikefs via Unbound-users:

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

It's certainly useful for testing, thanks.

It doesn't really move me closer to a decision whether we should merge
the glibc change to match error responses without a question section.

Previously I would have thought that for a stub resolver, off-path
spoofing isn't a problem because the ISP is able to validate source
addresses of the recursive resolvers (because they are not many hops
away from the ISP's own network), but emprically, that isn't the case.
As noted on the dns-operations list earlier this year,
adjacent-source-address spoofing is usually possible:

  [dns-operations] Destination-adjacent source address spoofed DNS queries
  <https://lists.dns-oarc.net/pipermail/dns-operations/2024-March/022488.html>

But maybe the packet volume required (due to query ID and source port
randomization) is so high that this doesn't matter because you can drown
the target in junk traffic at that rate anyway, no need to get creative
with spoofed DNS responses.

Thanks,
Florian



More information about the Unbound-users mailing list