Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

"Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com> Mon, 09 March 2015 23:27 UTC

Return-Path: <kevin.darcy@fcagroup.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EE51A88A6 for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 16:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.3
X-Spam-Level:
X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShFPTQDPtMRy for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 16:27:45 -0700 (PDT)
Received: from odbmap02.extra.chrysler.com (odbmap02.out.extra.chrysler.com [129.9.40.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955651A01F7 for <dnsop@ietf.org>; Mon, 9 Mar 2015 16:27:45 -0700 (PDT)
Received: from odbmap04.oddc.chrysler.com (Unknown_Domain [53.28.32.58]) by odbmap02.extra.chrysler.com (Symantec Messaging Gateway) with SMTP id 24.01.01442.76C2EF45; Mon, 9 Mar 2015 19:27:35 -0400 (EDT)
X-AuditID: 8109281a-b7f776d0000005a2-16-54fe2c679249
Received: from mail.chrysler.com (Unknown_Domain [151.171.240.19]) by odbmap04.oddc.chrysler.com (Symantec Messaging Gateway) with SMTP id 41.D8.23439.76C2EF45; Mon, 9 Mar 2015 19:27:35 -0400 (EDT)
Received: from 038-CH1MPN1-043.038d.mgd.msft.net ([169.254.3.90]) by 038-CH1MMR1-007.038d.mgd.msft.net ([151.171.240.19]) with mapi id 14.03.0224.003; Mon, 9 Mar 2015 23:27:35 +0000
From: "Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>, "dns-operations@dns-oarc.net" <dns-operations@dns-oarc.net>
Thread-Topic: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Thread-Index: AdBavfE1MYKXzjSRRTWturovuayxtA==
Date: Mon, 09 Mar 2015 23:27:34 +0000
Message-ID: <49DEE35910F1A6438E9805F4DEBBA30712751CE9@038-CH1MPN1-043.038d.mgd.msft.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.143.13.209]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsViKqNgpVug8y/EYNE3QYv98w8zWdx9c5nF gcnjadMhZo8lS34yBTBFcdmkpOZklqUW6dslcGW8PGpacEKyomenfgPjd5EuRk4OCQETieZp uxghbDGJC/fWs3UxcnEICZxnlNgy6zsjTNHaAy2MEIkTjBKnVuxkhnB2MkosmHWFCaSKDahq 4ZW7QAkODhGBFImpzcwgYWGBYIk5/XfASkQEQiReTV/AAmHrSRyaeAAsziKgIrFq3hx2kFZe gQiJK33hIGFGoIO+n1oDVsIsIC5x68l8Joh7BCSW7DnPDGGLSrx8/I8VwlaU2LRoMyNEvY7E gt2f2CBsbYllC1+D1fMKCEqcnPmEBeR8CYGfrBK3Lz1hmsAoNgvJjllI+mch6Z+FpH8BI8sq Run8lKTcxAIDI73UipKiRL3kjKLK4pzUIr3k/NxNjMBIauTUkNrB+HQu7yFGaQ4WJXHeiC+e gUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYq835Zf+uf3nrrsKu+WWTPpm+4nWdz/vjjsKP +Y8vyN9yztzQ6Xxdstj+RMrHrIJ5q1NKFIV4HVe3GCg1hLllzP1zn2nD7hNsW1KvTz1sZ12x /tNCVaOzC00vleh//H7fuDDgA5fBzDCVLTIOkxO0bmg+f6UcODHy8mmpJglZmbL9bn/nO3Js UmIpzkg01GIuKk4EAHbnAG5yAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyffUHYd10nX8hBn8ma1vsn3+YyeLum8ss DkweT5sOMXssWfKTKYApissmJTUnsyy1SN8ugSvj5VHTghOSFT079RsYv4t0MXJySAiYSKw9 0MIIYYtJXLi3nq2LkYtDSOAEo8SpFTuZIZydjBILZl1hAqliA+pYeOUuUIKDQ0QgRWJqMzNI WFggWGJO/x2wEhGBEIlX0xewQNh6EocmHgCLswioSKyaN4cdpJVXIELiSl84SJgRaO/3U2vA SpgFxCVuPZnPBHGPgMSSPeeZIWxRiZeP/7FC2IoSmxZtZoSo15FYsPsTG4StLbFs4Wuwel4B QYmTM5+wTGAUnoVk7CwkLbOQtMxC0rKAkWUVo1R+SlJuYoGBiV5+SkqyXnJGUWVxTmqRXnJ+ 7iZGYOibyihY7mCce0P+EKM0B4uSOO+2vEMhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgj epgcFkoUtXSH3prP/oFp27H9pQ9/Pv0kJxkQf/DHpg9v/Xxubjuqdigx44eZ+iVN5qcpTafN bvdtMZlhIHfO5M8sI2POfZc1C1T/e5yI4944ycr4/VU36Rnq+klVW8PvOiot3rksZ77c1RcF 6xtXm4foM3ZufikzI3rXIf/uj62RhWfyQu8rsRRnJBpqMRcVJwIAhtE6wUsCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Pp6gIlM1vX8-M7YF80HI8wIyTjM>
Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2015 23:27:47 -0000

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-bounces@ietf.org] On Behalf Of David C Lawrence
Sent: Monday, March 09, 2015 12:24 PM
To: dnsop@ietf.org; dns-operations@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