Mukund Sivaraman <muks@isc.org> Wed, 05 April 2017 05:43 UTC

Return-Path: <muks@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5D21E126C22 for <dnsop@ietfa.amsl.com>; Tue, 4 Apr 2017 22:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id N7fNJbFq9Shd for <dnsop@ietfa.amsl.com>; Tue, 4 Apr 2017 22:43:46 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com []) by ietfa.amsl.com (Postfix) with ESMTP id CA2ED126C26 for <dnsop@ietf.org>; Tue, 4 Apr 2017 22:43:45 -0700 (PDT)
Received: from jurassic (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id AF6AF56A0447; Wed, 5 Apr 2017 05:43:43 +0000 (GMT)
Date: Wed, 5 Apr 2017 11:13:38 +0530
From: Mukund Sivaraman <muks@isc.org>
To: dnsop@ietf.org
Message-ID: <20170405054338.GA15831@jurassic>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7"
Content-Disposition: inline
User-Agent: Mutt/1.8.0 (2017-02-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yzeou8q_VGDYtWjdjEiKNt9GOIE>
Subject: [DNSOP] 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 05:43:47 -0000

Evan just pointed out a case due to a system test failure that is
interesting.. it's not clear what the behavior should be in this case,
so please discuss:

There's a nameserver that's authoritative for 2 zones example.org. and

In the example.org. zone, foo.example.org. is CNAME to bar.example.com.

In the example.com. zone, the name bar.example.com. doesn't exist (NXDOMAIN).

A query for "foo.example.org./A" is answered by the nameserver. It adds
the foo.example.org. CNAME bar.example.com. in the answer section, and
then, following RFC 1034 4.3.2. 3.(a.), sets the QNAME to
"bar.example.com" and looks into the "example.com" zone for
"bar.example.com.". It is not found.

The question is: what is the expected reply RCODE for this?

1. Is it NOERROR (0) because there is an answer section with the CNAME?

2. Is it NXDOMAIN (3) because the CNAME target was not found?

3. Does it not matter if it is either?

It seems to me that it should be NOERROR(1) because RFC 1035 defines
NXDOMAIN as "this code signifies that the domain name referenced in the
query does not exist" which in my interpretation doesn't match the
modified QNAME when following the CNAME change.

Also, if a resolver caches the NXDOMAIN against the question section
name (foo.example.org.) , then a follow-up query to the resolver for
"foo.example.org./CNAME" will return an NXDOMAIN from cache.

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.