Re: NOTIMP for unrecognized qtypes
Petr Špaček via Unbound-users wrote: > Well, the spec is from 1987. Even the meaning of MUST/SHOULD etc. was > not standardized yet back then ... Even worse, this language appears to have been copied verbatim from RFC 883, which is even older (1983) :-) -- Robert Edmonds edmo...@debian.org
Re: NOTIMP for unrecognized qtypes
On 28.7.2017 00:15, Jacob Hoffman-Andrews via Unbound-users wrote: > 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 1035Domain Implementation and SpecificationNovember 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. Well, the spec is from 1987. Even the meaning of MUST/SHOULD etc. was not standardized yet back then ... Anyway, I will try to give you some examples to help you understand this: Imagine that term "query" in OPCODE decription refers to "type of request", i.e. the term "query" here means "packet sent to server". In other words, OPCODE affects semantics of the DNS message. Exaple: One of OPCODEs is UPDATE which modifies data on authoritative server. RCODE=NOTIMP is suitable e.g. for situation when a resolver got UPDATE request etc. I.e. the resolver is replying with "I have no idea what you operation are requesting from me". On the other hand, RR type in general do not affect message semantics, so there is no reason to return NOTIMP based on RR type. I hope it helps. -- Petr Špaček @ CZ.NIC
Re: NOTIMP for unrecognized qtypes
{this isn't really unbound specific}
On Thu, Jul 27, 2017 at 12:52:01PM -0700, Jacob Hoffman-Andrews via
Unbound-users wrote:
> CAA. I believe it's the case that standards-conformant authoritative
> resolvers should return NOERROR for qtypes they don't recognize, rather
there are multiple functions for "name servers", but "authoritative
resolver" is just the one that doesn't exist - see RFC 7719.
> 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,
RFC 3597 states
To enable new RR types to be deployed without server changes, name
servers and resolvers MUST handle RRs of unknown type transparently.
So, there is no special handling for unrecognized TYPEs (well, maybe
some meta QTYPE's are a necessary exception, but CAA would not fall
into this category).
-Peter
Re: NOTIMP for unrecognized qtypes
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 1035Domain Implementation and SpecificationNovember 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. -- Robert Edmonds edmo...@debian.org
NOTIMP for unrecognized qtypes
Hi all, 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. Thanks, Jacob
