My 2 cents...
It is commonplace, these days, to clearly enumerate "MANDATORY TO IMPLEMENT"
elements of a protocol specification. But, this was not the typical practice at
the time RFCs 1034/1035 was written, and I don't think we can apply modern
standards-parlance retroactively. RFC 1034/1035 certainly marked some protocol
elements as "optional" or "experimental", e.g.
- inverse query opcode ("optional")
- the MG, MINFO, MR and NULL RR types ("experimental")
- negative-caching via the inclusion of an SOA RR in the Additional Section of
the response ("optional")
yet, none of the QTYPEs defined in the RFCs are so labelled.
In the face of such circumstantial evidence, I would say that conformance to
RFCs 1034/1035 requires implementation, to some degree, of all QTYPEs defined
in those RFCs, That, to me, is a reasonable reading of the document.
"RCODE=NOTIMP exists, ergo any/all QTYPEs which aren't also RR types[1], are
optional to implement" is not, IMO, a reasonable reading, but admittedly, the
"MANDATORY TO IMPLEMENT" construct probably came into vogue in the first place,
to forestall any such shaky interpretations.
Now, having said that, I think it would be standards-conforming for an
implementation to always answer with RCODE=REFUSED, always answer with NODATA,
or to pick only certain RR types, more-or-less arbitrarily, (e.g. A and AAAA)
and only answer with RRs matching those RR types (as a way to minimize the
amplification effect), in response to QTYPE=* queries. None of those would be
violations of the standard, which in no way usurps local administrative control
over what queries get substantive responses, versus those which do not, nor
commits an implementation to rigorously tracking down *every* RRset owned by
the QNAME of a given QTYPE=* query. But, I have to agree with Dan: NOTIMP in
response to QTYPE=* is not standards-conforming. As for his meta-argument that
DNSOP cannot make changes to the protocol, I'm still mulling that one over, in
light of the charter language.
- Kevin
[1] The reason for the "which aren't also RR types" qualification is that RFC
1123, Section 6.1.3.5 states that "DNS software MUST support all well-known,
class-independent formats [sic]". While 1123 is silent on QTYPEs, _per_se_, at
least the set of [QTYPEs that are also well-known, class-independent RR types],
as of the date of 1123's publication, fall within mandatory-to-implement, and
there is no need to debate over those.
-----Original Message-----
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of David C Lawrence
Sent: Monday, March 09, 2015 12:24 PM
To: dnsop@ietf.org; dns-operati...@dns-oarc.net
Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS
standards
RFC 1035 explicitly allows for a server to indicate that a kind of query is not
implemented.
Whether it is a good idea to respond to ANY this way is a separate argument
that is worth having. You just won't win on the foundation that it is a
violation of the standard.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
