Re: [DNSOP] RCODE and CNAME chain

Mark Andrews <marka@isc.org> Wed, 05 April 2017 07:14 UTC

Return-Path: <marka@isc.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 A29FC128B44 for <dnsop@ietfa.amsl.com>; Wed, 5 Apr 2017 00:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 5HvEF1ZwqnZ2 for <dnsop@ietfa.amsl.com>; Wed, 5 Apr 2017 00:14:25 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F5612704A for <dnsop@ietf.org>; Wed, 5 Apr 2017 00:14:25 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 4EA043493E2 for <dnsop@ietf.org>; Wed, 5 Apr 2017 07:14:22 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3F2ED16005B; Wed, 5 Apr 2017 07:14:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2FF35160072; Wed, 5 Apr 2017 07:14:22 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JTvo48DLZ81z; Wed, 5 Apr 2017 07:14:22 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A7B4016005B; Wed, 5 Apr 2017 07:14:21 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id CF48F6A8DCB6; Wed, 5 Apr 2017 17:14:15 +1000 (AEST)
To: Mukund Sivaraman <muks@isc.org>
Cc: dnsop@ietf.org
From: Mark Andrews <marka@isc.org>
References: <20170405054338.GA15831@jurassic>
In-reply-to: Your message of "Wed, 05 Apr 2017 11:13:38 +0530." <20170405054338.GA15831@jurassic>
Date: Wed, 05 Apr 2017 17:14:15 +1000
Message-Id: <20170405071415.CF48F6A8DCB6@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vmo55DnSQXoDVwxq_y-WezXjG7k>
Subject: Re: [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 07:14:26 -0000

In message <20170405054338.GA15831@jurassic>, Mukund Sivaraman writes:
> 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
> example.com.
> 
> 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.

No. The RCODE references the end of the CNAME/DNAME chain.
 
> 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.

Then the resolver is broken.
 
> 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.
> 
> 		Mukund

If the qtype is CNAME or ANY the answer is NOERROR as the CNAME is
not followed.

If the qtype isn't CNAME or ANY the answer is NXDOMAIN as the CNAME
is followed.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org