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

Edward Lewis <edward.lewis@icann.org> Wed, 05 April 2017 14:33 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 BFC4012947A for <dnsop@ietfa.amsl.com>; Wed, 5 Apr 2017 07:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.211
X-Spam-Level:
X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, 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 4al80XrLrxpj for <dnsop@ietfa.amsl.com>; Wed, 5 Apr 2017 07:33:18 -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 E8CFD129420 for <dnsop@ietf.org>; Wed, 5 Apr 2017 07:33:16 -0700 (PDT)
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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 5 Apr 2017 07:33:14 -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 07:33:14 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: Donald Eastlake <d3e3e3@gmail.com>, Mukund Sivaraman <muks@isc.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] RCODE and CNAME chain
Thread-Index: AQHSrhQorn01rkS3SEWBbXgga5ZK6KG3CUGA
Date: Wed, 5 Apr 2017 14:33:14 +0000
Message-ID: <FCAB344C-2374-45C6-B638-40B8A89AD306@icann.org>
References: <20170405054338.GA15831@jurassic> <797A6C99-C9B7-4671-A29D-6ECFEF6A5B6D@icann.org> <CAF4+nEHqyDdRYC7Mv-v+W9Q1sTVke-TXieEc--ao_tm9oG09nQ@mail.gmail.com>
In-Reply-To: <CAF4+nEHqyDdRYC7Mv-v+W9Q1sTVke-TXieEc--ao_tm9oG09nQ@mail.gmail.com>
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_3574233195_532983771"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Xisfwlw0F3LH0uf5c8rxdMCiC-8>
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 14:33:24 -0000

Since you mentioned RFC 6604 "xNAME RCODE Clarification", here's a relevant quote from Section 3 ("RCODE Clarification"):

 

>When an xNAME chain is followed, all but the last query cycle necessarily had no error.  The RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that response.  If the xNAME chain was terminated by an error, it will be that error code.  If the xNAME chain terminated without error, it will be zero.

 

I tried a small set up, zone example with two CNAME sets.  name1 CNAME name.example.com (zone also on the server, with nothing at name.example.com) and name2 CNAME name.example.xx (zone not on the server) and recursion disabled.

 

dig for name1.example. returns the single CNAME record in the Answer, the AA bit, SOA in Authority, and NXDOMAIN in the RCODE.

dig for name2.example. returns the single CNAME record in the Answer, the AA bit, no SOA, and NOERROR in the RCODE.

 

The first is a "final" answer - NXDOMAIN looking for the last name in the chain.  There's also an SOA record in the Authority indicating the negative TTL to use.  The latter is a non-final answer (i.e., it's up to the querier to keep asking), a "CNAME referral" - no SOA record and no hints as to where to go because it's outside any domain of the name server (or that it is willing to admit to having).

 

The two (final and CNAME referral) are rather hard to tell apart, it's possible to determine that is the "last query cycle" as mentioned in the RFC, but it takes a trained eye.  How?  Well, a querier ought to realize that, if it didn't ask for a CNAME set and there's no error (yet), you simply haven't gotten a final answer yet.

 

On 4/5/17, 09:54, "DNSOP on behalf of Donald Eastlake" <dnsop-bounces@ietf.org on behalf of d3e3e3@gmail.com> wrote:

 

See RFC 6604.

 

Donald

 

from iPhone

 

On Wed, Apr 5, 2017 at 09:34 Edward Lewis <edward.lewis@icann.org> wrote:

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.)

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop[ietf.org]

-- 

Sent from Gmail Mobile