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

Warren Kumari <warren@kumari.net> Tue, 20 September 2016 17:09 UTC

Return-Path: <warren@kumari.net>
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 3B57E12B413 for <dnsop@ietfa.amsl.com>; Tue, 20 Sep 2016 10:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 V_ANIL68OjNs for <dnsop@ietfa.amsl.com>; Tue, 20 Sep 2016 10:09:43 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 1ABC112B40F for <dnsop@ietf.org>; Tue, 20 Sep 2016 10:09:43 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id w204so21400974qka.0 for <dnsop@ietf.org>; Tue, 20 Sep 2016 10:09:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aqjlL7rGkAZWpookTrLWpOrn2H5VnzSUBNhpFBd8fA4=; b=LdpGaQD9yYPxqxdtt/6wLxOALFwBIbrRfhyJp2ed+97C+VWh97PxeRzWX9CkcztZ1g +Z2pK8GYH8b3AO2Fv476Yq6yTmlWqw2D/+7TUJSX+sMBTXPPkIqcQgWvp2WV/Pxvptbm wE5LZreikkyrQSzsM0VVEAGoS3iTyTJX4wj0MHb5G9IRmCTKBmHoG6MKm5f26Z0y/RsA VgyyFqmgWNFLCLnWAtqbd/Mx+2rnGMP2ovl6pthTJrn+i3q23R70l7SGjLSu4LE9epKr 24GcfHwnxq+oWdBMAlZqxHAeKfrcJVx5L/X1ZpOCUfo7s1xA68Fqd2bZ0qkbPOKYItwF ZgWA==
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:content-transfer-encoding; bh=aqjlL7rGkAZWpookTrLWpOrn2H5VnzSUBNhpFBd8fA4=; b=T9klXXPecrumIQ709zbw3erWxaP6sJ1vtsNW+WNm+AzS8wfDQoTwyDj5hx2vrex7Zi EyfFd3HSXUFG53eIDJG6OziSbjD0jbK/i80R9rFmOxwqy5dQ55k9bBEa6KJVru+Uey53 QmJ6Z3DaZp2WIy6Hg+XCxanMGajWgnqZVJvjezpijBIlQi6X9GjprPaBpUHW5qBPnZzC a+NR8/PdD4C0Gs7ek9uG0HaWe98YwFY7FKYWfRws6iAdvls3yHn/5X+Y4N1Pww+XhMjX t3786QmrrQNWB5pIfA5qGIvzV6L7w7KRJkMT3z2um/eK5ODmFGLYQ0tRmCtKCGZC1IZv Llpw==
X-Gm-Message-State: AE9vXwNM1nNL3cPzCUbINkO5YndDSBg8mas+2N1OOANUzOeYms2LyaahSoze8/Fr9Vm4BJ97SeSlXl8pJSxad6wL
X-Received: by 10.233.237.201 with SMTP id c192mr35645496qkg.29.1474391382081; Tue, 20 Sep 2016 10:09:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Tue, 20 Sep 2016 10:09:11 -0700 (PDT)
In-Reply-To: <20160920163753.5k4h4cvrtdkt4pjh@mycre.ws>
References: <20160920161350.GA3288@laperouse.bortzmeyer.org> <20160920163753.5k4h4cvrtdkt4pjh@mycre.ws>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 20 Sep 2016 13:09:11 -0400
Message-ID: <CAHw9_iJApVDTn7P2mCyqzByGJXH2nwOaEWzmQCs0HXV82BW2Bw@mail.gmail.com>
To: Robert Edmonds <edmonds@mycre.ws>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BV4h7HvVW5JzurzX9ObZuBueG24>
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: Tue, 20 Sep 2016 17:09:45 -0000

On Tue, Sep 20, 2016 at 12:37 PM, Robert Edmonds <edmonds@mycre.ws> wrote:
> Stephane Bortzmeyer wrote:
>> Do you like long terminology discussions, backed by a dozen RFC, where
>> people disagree on what's written in these RFC? If so, read on.
>
> Yes, please!
>
>> RFC 1034 had a different definition of QNAME but is not clear on the
>> specific case of CNAME chains:
>>
>> > A standard query specifies a target domain name (QNAME)
>
> RFC 1034 gives an "algorithm" (§4.3.2):
>
>     […] Search the available zones for the zone which is the nearest
>     ancestor to QNAME. […]
>
>         […] 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.
>
>             […]
>
> It seems the use of QNAME for anything other than the question resource
> record name is due to this "variable reuse" in the §4.3.2 "algorithm".
>
> RFC 1035 gives a definition of QNAME in §4.1.
>
>     All communications inside of the domain protocol are carried in a
>     single format called a message. […]
>
>     The names of the sections after the header are derived from their
>     use in standard queries.  The question section contains fields that
>     describe a question to a name server.  These fields are a query type
>     (QTYPE), a query class (QCLASS), and a query domain name (QNAME).
>     […]
>
> So, this implies that QNAME means the same thing regardless of whether
> the message is a query or response.
>
> Also see §4.1.2 which is even more graphic about where the QNAME is.
>
>> So, which is right? In this DNS query:
>>
>> % dig A www.afnic.fr
>>
>> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> A www.afnic.fr
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35551
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 1280
>> ;; QUESTION SECTION:
>> ;www.afnic.fr.                IN A
>>
>> ;; ANSWER SECTION:
>> www.afnic.fr.         213 IN CNAME www.nic.fr.
>> www.nic.fr.           213 IN CNAME lb01-1.nic.fr.
>> lb01-1.nic.fr.                213 IN A 192.134.5.24
>>
>> ;; Query time: 875 msec
>> ;; SERVER: 192.168.43.1#53(192.168.43.1)
>> ;; WHEN: Tue Sep 20 18:11:06 CEST 2016
>> ;; MSG SIZE  rcvd: 100
>>
>> Is the QNAME "www.afnic.fr" or "lb01-1.nic.fr" ("the data field of the
>> last CNAME")???
>
> "www.afnic.fr", because that is the domain name in the question section.

+1.
The QNAME is (or, should be :-)) the name which is in the question.
Things get tricky when chasing CNAMEs because there can be multiple
questions, and so "the" QNAME changes. But, in your example above, I
believe it is www.afnic.fr.

I think the RFC2308 definition is only true in the negative caching
context... or something...

W


>
> --
> Robert Edmonds
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf