Re: [DNSOP] RCODE and CNAME chain

Mark Andrews <marka@isc.org> Wed, 26 April 2017 23:04 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 59BBC128B8F for <dnsop@ietfa.amsl.com>; Wed, 26 Apr 2017 16:04:28 -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 NXDNX9G2UWKd for <dnsop@ietfa.amsl.com>; Wed, 26 Apr 2017 16:04:26 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8C71279E5 for <dnsop@ietf.org>; Wed, 26 Apr 2017 16:04:26 -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.ams1.isc.org (Postfix) with ESMTPS id ACC2424AE0D; Wed, 26 Apr 2017 23:04:19 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8D3D216009A; Wed, 26 Apr 2017 23:04:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6BECF16009B; Wed, 26 Apr 2017 23:04:20 +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 cfqG5U05nmW5; Wed, 26 Apr 2017 23:04:20 +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 1C5DE16009A; Wed, 26 Apr 2017 23:04:20 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 096AF6D06C7D; Thu, 27 Apr 2017 09:04:18 +1000 (AEST)
To: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= <jv@fcelda.cz>
Cc: Peter van Dijk <peter.van.dijk@powerdns.com>, muks@isc.org, dnsop@ietf.org
From: Mark Andrews <marka@isc.org>
References: <20170405054338.GA15831@jurassic> <73DD364E-12F0-4367-964D-6C18E37BC12B@powerdns.com> <CAM1xaJ8OOkxw41DzTOBV6yXVmtJVnKGu=4xsP3FWyQGFt36H1g@mail.gmail.com>
In-reply-to: Your message of "Thu, 27 Apr 2017 00:32:44 +0200." <CAM1xaJ8OOkxw41DzTOBV6yXVmtJVnKGu=4xsP3FWyQGFt36H1g@mail.gmail.com>
Date: Thu, 27 Apr 2017 09:04:17 +1000
Message-Id: <20170426230418.096AF6D06C7D@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Y842-ObGMj5EvQMlt4oGIqbEvcc>
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, 26 Apr 2017 23:04:28 -0000

In message <CAM1xaJ8OOkxw41DzTOBV6yXVmtJVnKGu=4xsP3FWyQGFt36H1g@mail.gmail.com>
, =?UTF-8?B?SmFuIFbEjWVsw6Fr?= writes:
> Hello,
> 
> sorry for resurrecting this thread, but this really caught my attention.
> 
> On Wed, Apr 5, 2017 at 9:03 AM, Peter van Dijk wrote:
> > On 5 Apr 2017, at 7:43, Mukund Sivaraman wrote:
> >> 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?
> >
> > NXDOMAIN is correct. The text on this on 103x is a bit weak but 2308 2.1
> > clarifies this.
> 
> I actually think NOERROR is correct. The target of the CNAME
> (bar.example.com) is not in the bailiwick of the zone (example.org).
> So the authoritative server should stop processing the CNAME chain at
> this point and send the response with RCODE=NOERROR.

Well RFC 1034 doesn't say stop processing the CNAME chain when it
points outside the original zone.  You go back to step 1 on a CNAME
(and DNAME) and look for the target zone of the *new* QNAME.

         a. If the whole of QNAME is matched, we have found the
            node.

            If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

And this whole issue was discussed and debated 2 decades ago.  RFC
1034 has a number of errors in it.  Other documents update it
including RFC 2308.

If you get to the end of the CNAME chain and the QNAME as it is at
that point does not exist you return NXDOMAIN.

If you don't get to the end of the CNAME chain then you return
NOERROR and a referral if you have one to return.  This introduces
ambiguity.

We really should allow NXRRSET to be returned for QUERY to remove this
ambiguity.  This requires that the server knows that the client supports
NXRRSET with QUERY.  Bumping the EDNS version number would be one way to
signal this.

Mark

> Or can we at least agree that both RCODEs are correct? :-)
> 
> Jan
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org