NOTIMP for unrecognized qtypes

Jacob Hoffman-AndrewsFri Jul 28 00:15:48 CEST 2017

On 07/27/2017 01:28 PM, Robert Edmonds wrote:
> Jacob Hoffman-Andrews via Unbound-users wrote:
>> I'm trying to write some documentation for users of Let's Encrypt about
>> CAA. I believe it's the case that standards-conformant authoritative
>> resolvers should return NOERROR for qtypes they don't recognize, rather
>> than NOTIMP. Is this correct? If so, what is the relevant standard? I
>> haven't been able to find a citation in
>>https://tools.ietf.org/html/rfc3597,>>https://tools.ietf.org/html/rfc6895, or https://tools.ietf.org/html/rfc1035.>> RFC 1035 seems to be pretty clear that NOTIMP applies to the OPCODE, not
> the QTYPE.
>> Mockapetris [Page 25]
>> RFC 1035 Domain Implementation and Specification November 1987
>>> 4.1.1. Header section format
>> […]
>> OPCODE A four bit field that specifies kind of query in this
> message. This value is set by the originator of a query
> and copied into the response. The values are:
>> 0 a standard query (QUERY)
> […]
>> RCODE Response code - this 4 bit field is set as part of
> responses. The values have the following
> interpretation:
> […]
> 4 Not Implemented - The name server does
> not support the requested kind of query.
> […]
>> That is, OPCODE specifies the "kind of query", and NOTIMP indicates that
> the "kind of query" (= OPCODE) isn't supported.
Thanks, this is very helpful! Adding in a little more from RFC 1035:
QTYPE a two octet code which specifies the type of the query.
The values for this field include all codes valid for a
TYPE field, together with some more general codes which
can match more than one type of RR.
So I take it the distinction is that QTYPE represents the "type of" the
query, while OPCODE represents the "kind of" the query, and since RCODE
refers to "kind of" it only affects OPCODE? I can sort of see the
distinction, but since "type of" and "kind of" have almost identical
colloquial meanings I'm surprised that the distinction is not called out
in more detail.