Re: [DNSOP] Where in a CNAME chain is the QNAME?

Ólafur Guðmundsson <olafur@cloudflare.com> Mon, 26 September 2016 11:33 UTC

Return-Path: <olafur@cloudflare.com>
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 3D02712B170 for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 04:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
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 pJQUAwuky3ZR for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 04:33:41 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 24B9C12B178 for <dnsop@ietf.org>; Mon, 26 Sep 2016 04:33:41 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id r192so70672479ita.0 for <dnsop@ietf.org>; Mon, 26 Sep 2016 04:33:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tJzefKQOHFDiTPB7AgYjT6dYl79qbDuap4abkT/nOzQ=; b=Itlaprg5nE3laHHJOQgXY9+87YYr2tIXOLoofLVL/LFQ1ck1xnIjgurpxcgH0DnaAK R6aGWIyHfsElcck//Bifi2uFBmN8ne7Q4Nx780PX/rL26C7zmN5AbX3oIR07KBqC83Op pZ13hp6aeVJOc/d/ptWwMgoXMwHLdX634Sc4w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tJzefKQOHFDiTPB7AgYjT6dYl79qbDuap4abkT/nOzQ=; b=bv4RiUPNGNqvGaiMfijSyvDC/tAN2g+D1NpanP8fac9WdMHoYnehbZlPNO/SFzYqXM f0Jxl7gbfqg1E5aooXdRJli9UI4RVCwOPq+JqASiQGGxRLSUnsLEFQe2OmmfcFEgRCIq EIIaslT5Ef6VvaP908wpVGSPsYMCvYbhCRsFJJAjyogWxUDk7vE8SwHZDs6hdmufhVZW LCs7auxTwGgf9jmb5wQUF3cVvADSa9QoTuADWUFiGXpr323yYK2q1U2gBv53xdiIGiYd GygE4FwaJfUMSh9X5C3aU90LxLbbyT4wTANMIVg89Og1dTKnt63zuv6hR13ODOKqc9Tv ft/w==
X-Gm-Message-State: AA6/9RlNRTrpE1Rmt1t7PyIyGY+Lh9Yqqh6F8iMtZjtz4IADL9INjdJ+DdDBxWTWJ6lT/x2Hcj7sGYQCFFYp5qW2
X-Received: by 10.36.223.196 with SMTP id r187mr16367162itg.2.1474889620463; Mon, 26 Sep 2016 04:33:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.182.195 with HTTP; Mon, 26 Sep 2016 04:33:39 -0700 (PDT)
In-Reply-To: <7F671C9C-BEEC-479B-99FB-8618C3C75526@powerdns.com>
References: <20160920161350.GA3288@laperouse.bortzmeyer.org> <20160923082232.6j2jlr4wqp2fxs56@nic.fr> <7F671C9C-BEEC-479B-99FB-8618C3C75526@powerdns.com>
From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>
Date: Mon, 26 Sep 2016 12:33:39 +0100
Message-ID: <CAN6NTqyCuLQJ=aYCfxiLPyRgoMR2CQDwtpsSSt499wA3Y_168A@mail.gmail.com>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Content-Type: multipart/alternative; boundary=94eb2c0b170ae9355d053d677ffa
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jPCiRlUV6h7PEFOIqj2bKnTbRCg>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Where in a CNAME chain is the QNAME?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 26 Sep 2016 11:33:43 -0000

On Mon, Sep 26, 2016 at 8:33 AM, Peter van Dijk <peter.van.dijk@powerdns.com
> wrote:

> Hello,
>
> On 23 Sep 2016, at 10:22, Stephane Bortzmeyer wrote:
>
> On Tue, Sep 20, 2016 at 06:13:50PM +0200,
>>  Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote
>>  a message of 68 lines which said:
>>
>> This issue was spotted by Peter van Dijk. It is about
>>> draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The
>>> problem is the definition of "QNAME" when there is a CNAME chain.
>>>
>>
>> OK, after reading the discussion, my opinion, as an author (but I'll
>> of course defer the decision to the working group, the WG chairs, the
>> RFC editor and the flying spaghetti monster):
>>
>> The re-definition of QNAME by RFC 2308 is awkward and does not match
>> the general usage, or the previous definitions. Therefore, I prefer to
>> keep the "common sense" usage "QNAME is the owner name of the record
>> in the Question Section". Which means that, in my example, the QNAME
>> is "www.afnic.fr" and the current text of
>> draft-ietf-dnsop-nxdomain-cut-05 is correct.
>>
>
> 2308 does not “redefine” QNAME. It clarifies that the usage in 1034 4.3.2
> is the definition we use in RFCs. 1035 4.1(.2) does not conflict with this;
> the QNAME there is just the initial QNAME.
>
> Many other RFCs need 2308: 2874, 4035, 4343, 4592, 4470, 4471, 5074, 5155,
> 6147, 6672 and most likely several others rely on the 2308 definition of
> QNAME. Without 2308, each of these RFCs would need extra text such as the
> text your draft has now. It is simply not necessary.
>
>
> Peter, is right
but the root cause is the role of "CNAME" and to lesser extent "DNAME".
Both is what I have part of DNS Navigation records that act like
"rewriters".
1034 was light on detail, 2308 might have uses a better notation but the
effect would have been the same,
The RCODE applies to the RRSET pointed to by the last CNAME in answer
section (or the missing one).

In hindsight the use of single RCODE with limited enumeration is the root
cause.
If one was designing this again one would allow multiple Questions in the
header and each RRset would have a header that says what its ReturnCode is,
but that is the advantage of hindsight.

Olafur