As reported by Arnaud Gavara on the mailing-list 1, dnsdist currently drops queries that have a qdcount of zero. That used to be fine (it was used by rfc7873 but it seems that nobody cared about it) but now that it is described as a conformance test in rfc8906 we might need to think about how to handle that.
The issue is that a lot of our rules, and likely a lot of custom Lua code, expect that a query has a qname, a qtype and a qclass, and I'm not sure how to deal with that in a compatible way. I don't want to break setups on an upgrade, even a major one, if I don't have to.
A good start might be to reply with FORMERR or NOTIMP instead of dropping the packet, at least until we can figure out a way to actually pass that query to the backend.
The text was updated successfully, but these errors were encountered:
Short description
As reported by Arnaud Gavara on the mailing-list 1, dnsdist currently drops queries that have a
qdcount
of zero. That used to be fine (it was used by rfc7873 but it seems that nobody cared about it) but now that it is described as a conformance test in rfc8906 we might need to think about how to handle that.The issue is that a lot of our rules, and likely a lot of custom Lua code, expect that a query has a qname, a qtype and a qclass, and I'm not sure how to deal with that in a compatible way. I don't want to break setups on an upgrade, even a major one, if I don't have to.
A good start might be to reply with
FORMERR
orNOTIMP
instead of dropping the packet, at least until we can figure out a way to actually pass that query to the backend.The text was updated successfully, but these errors were encountered: