[GH-ISSUE #2723] Defer FORMERR when QDCOUNT=0 #1048

New issue

Closed

opened 2026-03-16 01:25:44 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 01:25:44 +03:00

Owner

Originally created by @divergentdave on GitHub (Jan 14, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2723

Currently the unknown opcode tests from RFC 8906 are failing because of an unexpected RCODE of FORMERR (instead of NOTIMP). This is caused by the call to Queries::try_into_query() when decoding a MessageRequest. We do not match on the opcode until later, inside Catalog's implementation of RequestHandler.

We should move this requirement that QDCOUNT=1 until later for a few reasons. First, it'll allow fixing this particular test failure. Secondly, different opcodes assign different meanings to the query section, so it is incorrect to treat QDCOUNT!=1 as a format error without considering the opcode as well. Third, even when OPCODE=0 (for QUERY), there are situations where we may see QDCOUNT=0. For example, RFC 7873, DNS Cookies, says that clients may prefetch a cookie by making a query with OPCODE=0, QDCOUNT=0, and an OPT pseudo-record with a COOKIE option. (note that we don't fully support COOKIE now, but I think it would be good to do so in the future. See #2075)

According to RFC 9619, we can expect that QDCOUNT will not be greater than 1 for OPCODE=0. The same may not hold for other opcodes.

The assumption that there is exactly one query is embedded in the MessageRequest struct, which contains a WireQuery, and in turn a Query. I think we'll have to replace this with a Queries field, and reshuffle related accessors. For example, we could move the Queries::try_into_query() call into a fallible method, and then only call that after we have matched on the opcode.

Originally created by @divergentdave on GitHub (Jan 14, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2723 Currently the unknown opcode tests from RFC 8906 are failing because of an unexpected RCODE of FORMERR (instead of NOTIMP). This is caused by the call to `Queries::try_into_query()` when decoding a `MessageRequest`. We do not match on the opcode until later, inside `Catalog`'s implementation of `RequestHandler`. We should move this requirement that QDCOUNT=1 until later for a few reasons. First, it'll allow fixing this particular test failure. Secondly, different opcodes assign different meanings to the query section, so it is incorrect to treat QDCOUNT!=1 as a format error without considering the opcode as well. Third, even when OPCODE=0 (for QUERY), there are situations where we may see QDCOUNT=0. For example, [RFC 7873](https://www.rfc-editor.org/rfc/rfc7873.html), DNS Cookies, says that clients may prefetch a cookie by making a query with OPCODE=0, QDCOUNT=0, and an OPT pseudo-record with a COOKIE option. (note that we don't fully support COOKIE now, but I think it would be good to do so in the future. See #2075) According to [RFC 9619](https://www.rfc-editor.org/rfc/rfc9619.html), we can expect that QDCOUNT will not be greater than 1 for OPCODE=0. The same may not hold for other opcodes. The assumption that there is exactly one query is embedded in the `MessageRequest` struct, which contains a `WireQuery`, and in turn a `Query`. I think we'll have to replace this with a `Queries` field, and reshuffle related accessors. For example, we could move the `Queries::try_into_query()` call into a fallible method, and then only call that after we have matched on the opcode.