Re: [DNSOP] RCODE and CNAME chain

Jan Včelák <jv@fcelda.cz> Thu, 27 April 2017 09:14 UTC

Return-Path: <jv@fcelda.cz>
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 C92EA128896 for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 02:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.cz
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 F8DSX4fhs4oX for <dnsop@ietfa.amsl.com>; Thu, 27 Apr 2017 02:14:07 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 8E8611204DA for <dnsop@ietf.org>; Thu, 27 Apr 2017 02:14:07 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id 110so15707116uas.3 for <dnsop@ietf.org>; Thu, 27 Apr 2017 02:14:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5W5Cns36n0cyMYxgp7VKAuVmAFhH+P/0DVGcoaziqAA=; b=XSJBLbiP3/FSBZKkUUQMBQ7/kuuGUN9nFNEmdXZDkwRs2fouhMKtjBsQVlxxjus3iJ IbG4VcPVEreNq0qWolvLTKe9Bxxvb9ASM8cMsgW0bD5mCHtqiIgAy3/5udWyrGc5wEtd 3CsLjNQ+F8qKN7jdMsWxktknnNOnQ5NXHufj8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5W5Cns36n0cyMYxgp7VKAuVmAFhH+P/0DVGcoaziqAA=; b=KIZmk3zquIpetu4UJ6tEx2jHXv7TEiOJwRf8dWXStMblogpqMkOxdD81SKDsv9jiz3 clUcB8zRovSk1oxTXw6obxCkbRS+Hh5STd/KD2ApTSyrT2nke2zOs0UYfPu5kAA+U0rW r5APRUnfzS+vpsWZ3IJM9dq2nrHMqll8Fv8ezuBs5IElDHdUlvsRmLUCkMadDIA1HJVR ZV69WG7wVULiOjSn0sFBWU5SFPydju8vqRyahbe4dD3ZX+THpdCbodUbcFxWMFDMOx8d UD+GWNiNCC2Dvigo+cUVNfq316AZl6WFqs2f+mX0AaWcmnj+sHxe9WnISevk/zN58QKW geGQ==
X-Gm-Message-State: AN3rC/5s2cQlOSZvjeMRiAKbWcStYqMdETy1F/X6E9MqvIVRiPQpo9cU ODTi1VQz2teSEnNSg9+R1FwE8UbFRLRq
X-Received: by 10.159.55.229 with SMTP id q92mr2024514uaq.40.1493284446670; Thu, 27 Apr 2017 02:14:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.69 with HTTP; Thu, 27 Apr 2017 02:13:46 -0700 (PDT)
X-Originating-IP: [89.103.145.110]
In-Reply-To: <20170426230418.096AF6D06C7D@rock.dv.isc.org>
References: <20170405054338.GA15831@jurassic> <73DD364E-12F0-4367-964D-6C18E37BC12B@powerdns.com> <CAM1xaJ8OOkxw41DzTOBV6yXVmtJVnKGu=4xsP3FWyQGFt36H1g@mail.gmail.com> <20170426230418.096AF6D06C7D@rock.dv.isc.org>
From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= <jv@fcelda.cz>
Date: Thu, 27 Apr 2017 11:13:46 +0200
Message-ID: <CAM1xaJ-+mUhqiE=TzpB_uy91bF9sxntUkd+ds019QrVvAdo3uw@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: Peter van Dijk <peter.van.dijk@powerdns.com>, muks@isc.org, dnsop@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FZAhcOqtxwlBfsCFCHS9Ysbpmeo>
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:14:10 -0000

On Thu, Apr 27, 2017 at 1:04 AM, Mark Andrews wrote:
>
> 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.

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.

> 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