Re: [DNSOP] [Ext] RCODE and CNAME chain

Edward Lewis <edward.lewis@icann.org> Wed, 05 April 2017 13:34 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3053129405 for <dnsop@ietfa.amsl.com>; Wed, 5 Apr 2017 06:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 gJKV435u3_KN for <dnsop@ietfa.amsl.com>; Wed, 5 Apr 2017 06:34:37 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B570127863 for <dnsop@ietf.org>; Wed, 5 Apr 2017 06:34:37 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 5 Apr 2017 06:34:35 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 5 Apr 2017 06:34:35 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: Mukund Sivaraman <muks@isc.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] RCODE and CNAME chain
Thread-Index: AQHSrc+er/xSohK310Ock8cYx7x68KG2+WQA
Date: Wed, 5 Apr 2017 13:34:34 +0000
Message-ID: <797A6C99-C9B7-4671-A29D-6ECFEF6A5B6D@icann.org>
References: <20170405054338.GA15831@jurassic>
In-Reply-To: <20170405054338.GA15831@jurassic>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3574229674_411370557"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xeP8TwlgeIS6IoMRVKDUFZmg_xo>
Subject: Re: [DNSOP] [Ext] RCODE and CNAME chain
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 05 Apr 2017 13:34:40 -0000

On 4/5/17, 01:43, "DNSOP on behalf of Mukund Sivaraman" <dnsop-bounces@ietf.org on behalf of muks@isc.org> wrote:

>It seems BIND currently returns NXDOMAIN in this case, and the change in
>behavior between looking-into-other-zones and
>not-looking-into-other-zones in the nameserver algorithm caused a system
>test failure, hence the question.

I don't think there is one right answer.  There may be a more efficient answer (in terms of some metric).  The goal of the RFCs was interoperability, keep that in mind.

You allude above to an implementation changing its behavior (answering from all available data vs. sticking to one zone).  This is not something that is explicitly dealt with in the original RFCs, perhaps in later ones.  Both choices have merit, have downsides, still the two are interoperable.  As far as the protocol matters, either is a valid choice, and one that influences whether the query in question results in NOERROR/CNAME chain or NXDOMAIN.

In this case, I think you don't need to worry about the querier.  Rules seem to be explicit about caching responses here.

If anything, make sure your test script is accurate.  (Back in the day of DNSSEC protocol/code development, 1 out of 3 times DNSSEC had a protocol bug, 1 out of 3 times it was a software bug, and 1 out of 3 times everything was right but the tester - me - was expecting the wrong result.)