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?
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.
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.
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:
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.
A random idea, I don't know if this solves your issue. What you could do is keep the response without question section and return that response instead a timeout. The advantage is that if any other reply arrives or any other resolver responds, the caller will get an an answer. And in case this is the only response, the caller gets a reason the request fails instead of a timeout.