You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Uh oh!
There was an error while loading. Please reload this page.
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: