Re: [DNSOP] RCODE and CNAME chain

Mark Andrews <marka@isc.org> Thu, 27 April 2017 09:31 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 B09E212708C for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 02:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 LCrTjUGP4D42 for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 02:31:57 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 AEB721204DA for <dnsop@ietf.org>; Thu, 27 Apr 2017 02:31:57 -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 2599934930F; Thu, 27 Apr 2017 09:31:54 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E7E25160074; Thu, 27 Apr 2017 09:31:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 92A20160067; Thu, 27 Apr 2017 09:31:53 +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 pKDuJ1H8aI2M; Thu, 27 Apr 2017 09:31:53 +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 BCEFD16003A; Thu, 27 Apr 2017 09:31:52 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 59B086D3F5C9; Thu, 27 Apr 2017 19:31:50 +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> <20170426230418.096AF6D06C7D@rock.dv.isc.org> <CAM1xaJ-+mUhqiE=TzpB_uy91bF9sxntUkd+ds019QrVvAdo3uw@mail.gmail.com>
In-reply-to: Your message of "Thu, 27 Apr 2017 11:13:46 +0200." <CAM1xaJ-+mUhqiE=TzpB_uy91bF9sxntUkd+ds019QrVvAdo3uw@mail.gmail.com>
Date: Thu, 27 Apr 2017 19:31:50 +1000
Message-Id: <20170427093150.59B086D3F5C9@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EFaGRLmjEXbWEqaCMKJI8vCu--k>
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: Thu, 27 Apr 2017 09:31:58 -0000

In message <CAM1xaJ-+mUhqiE=TzpB_uy91bF9sxntUkd+ds019QrVvAdo3uw@mail.gmail.com>
, =?UTF-8?B?SmFuIFbEjWVsw6Fr?= writes:
> On Thu, Apr 27, 2017 at 1:04 AM, Mark Andrews wrote:
> >
> > In message <CAM1xaJ8OOkxw41DzTOBV6yXVmtJVnKGu=4xsP3FWyQGFt36H1g@mail.gmailail.
> 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.
> 
> Mark, you are absolute right if you interpret the RFCs word-for-word.
> But these documents were written before we knew or cared about cache
> poisoning attacks. And when the resolvers started to ignore
> out-of-bailiwick records, authoritative server should have been
> updated as well and should have stopped sending out-of-bailiwick
> records. Because anything out-of-bailiwick is potentially dangerous.
> My advocacy for NOERROR is based on that even though we don't have a
> document that would specify that.

If you want to advocate for changes to behaviour that is fine, but
advocate for that.  Just saying "shouldn't the rcode be NOERROR"
isn't doing that.  Then there is DNSSEC.  If the target zone is
signed and DO=1 is set in the query should you include the data
from the target zone?

You also have to deal with recursive servers that should always
follow the entire chain.  Remember there is nothing wrong with
recursive server having authorative content.

Mark

> > 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.
> 
> Yes, that would be more explicit. But I don't think this is worth the
> effort. Resolvers can deal with this ambiguity already.
> 
> Jan
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org