IETF Logo Mail Archive

Re: [DNSOP] Some distinctions and a request - Have some class?

P Vixie <paul@redbarn.org> Sun, 05 July 2015 12:14 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5413A1A1BA9 for <dnsop@ietfa.amsl.com>; Sun, 5 Jul 2015 05:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 aQy11k8mS5x2 for <dnsop@ietfa.amsl.com>; Sun, 5 Jul 2015 05:14:24 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87251A1BAC for <dnsop@ietf.org>; Sun, 5 Jul 2015 05:14:23 -0700 (PDT)
Received: from [192.168.2.172] (unknown [195.11.186.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 9F782184D7; Sun, 5 Jul 2015 12:14:22 +0000 (UTC)
User-Agent: K-9 Mail for Android
In-Reply-To: <5598D9EF.7000006@bellis.me.uk>
References: <6CB05D82CE245B4083BBF3B97E2ED470C2759F@ait-pex01mbx01.win.dtu.dk> <6CB05D82CE245B4083BBF3B97E2ED470C275B2@ait-pex01mbx01.win.dtu.dk> <E225C721-7279-4053-97A2-2D63A155DA14@karoshi.com> <6CB05D82CE245B4083BBF3B97E2ED470C27602@ait-pex01mbx01.win.dtu.dk> <88E49F4B-64BD-4832-BD02-D1A882874E92@karoshi.com> <20150702234423.GB23022@mycre.ws> <EBDBDD70-046F-4E31-BDAC-A619EECD4F13@karoshi.com> <20150703012146.GA29948@mycre.ws> <DC13E07F-2203-4FE9-A67F-B5851A54298F@karoshi.com> <986E07DA-B174-4F81-BFB5-F5EAD46C506F@karoshi.com> <20150705003514.GD48722@mx2.yitter.info> <5598D9EF.7000006@bellis.me.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----0OLVF4CKI1MCDUNAA00GZII7UZABWP"
Content-Transfer-Encoding: 8bit
From: P Vixie <paul@redbarn.org>
Date: Sun, 05 Jul 2015 13:14:16 +0100
To: Ray Bellis <ray@bellis.me.uk>, Andrew Sullivan <ajs@anvilwalrusden.com>
Message-ID: <B4EED81D-1BFF-41AD-8515-00F35A8FAF30@redbarn.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/f2L89H1lWDzKtpoG47kokk8Pz7M>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Some distinctions and a request - Have some class?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 05 Jul 2015 12:14:26 -0000

Right. Cname does not cross classes.

In original DNS, class was incoherently sometimes an attribute of zone data and sometimes a namespace selector. In modern DNS it is coherently always the latter.

On July 5, 2015 8:17:03 AM GMT+01:00, Ray Bellis <ray@bellis.me.uk> wrote:
>
>
>On 05/07/2015 01:35, Andrew Sullivan wrote:
>
> > Classes don't work in the general case, because CNAME (and following
> > it, DNAME) is class-independent.  This is arguably a bug in the
> > protocol, but it's a fact nevertheless.  As a result, different
> > classes aren't really different namespaces.
>
>Andrew,
>
>Can you please elaborate on what you mean there?
>
>Sure, CNAME is *defined* for all classes, but AFAIK there's no way to 
>"jump" out of one class into another using a CNAME.  If you've queried 
>in class FOO and see a CNAME then the resolution of the target of the 
>CNAME should continue in class FOO.
>
>RFC 1034 §3.6.2:
>
>"CNAME RRs cause special action in DNS software. When a name server 
>fails to find a desired RR in the resource set associated with the 
>domain name, it checks to see if the resource set consists of a CNAME 
>record with a matching class. If so, the name server includes the CNAME
>
>record in the response and restarts the query at the domain name 
>specified in the data field of the CNAME record."
>
>kind regards,
>
>Ray
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

v2.23.0 | Report a Bug | By Email