IETF Logo Mail Archive

CNAME/DNAME - Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME

Edward Lewis <Ed.Lewis@neustar.biz> Mon, 13 October 2008 13:58 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF4D28C10B; Mon, 13 Oct 2008 06:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.577
X-Spam-Level:
X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQrO31RsFPVT; Mon, 13 Oct 2008 06:58:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6B133A67E3; Mon, 13 Oct 2008 06:58:12 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KpNr6-0006h4-57 for namedroppers-data@psg.com; Mon, 13 Oct 2008 13:53:04 +0000
Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Ed.Lewis@neustar.biz>) id 1KpNqt-0006eD-1B for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 13:52:57 +0000
Received: from [192.168.1.101] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9DDoq66004694; Mon, 13 Oct 2008 09:52:35 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06240801c518fed0b4c7@[192.168.1.101]>
In-Reply-To: <STNTEXCH128BYXifWoq0000431f@stntexch12.cis.neustar.com>
References: <Your message of "Mon, 22 Sep 2008 15:12:44 -0400." <E1KhqqB-000CE1-QD@psg.com> <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <E1Khwdp-000J3V-QJ@psg.com> <a06240804c4ffc42abc16@[10.122.105.108]> <E1KicTm-000ANO-PO@psg.com> <a06240800c50fd3decd5b@[192.168.1.101]> <48F2DE42.1060209@links.org> <STNTEXCH128BYXifWoq0000431f@stntexch12.cis.neustar.com>
Date: Mon, 13 Oct 2008 09:45:20 -0400
To: Michael StJohns <mstjohns@comcast.net>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: CNAME/DNAME - Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME
Cc: Ben Laurie <ben@links.org>, Edward Lewis <Ed.Lewis@neustar.biz>, namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

At 7:38 -0400 10/13/08, Michael StJohns wrote:

>...CNAME and DNAME do not have any way of indicating the expected security
>state of the zone to which they point.  ...

Yes they do.  For X CNAME Y, you can determine the security state of 
X by flowing down from the root and you can tell the security state 
of Y by flowing down from the root.  Just as X is not "delegating" to 
Y in the sense of NS's, X is not transferring any security state to 
Y.  X is simply referring to Y. Ditto if this is a DNAME situation.


                                      .               (assume a "signed" root)
                              ------/ | \------
                             /        |        \
                             S        S        S      (S=secure zone)
                             |        |        |
                             S        S        S
                             |        |        |
                             S        U        S      (U=insecure zone)
                             |        |        |
                             X CNAME  Y DNAME  Z
                                               |
                                               W

In this case, X has a secured reference to Y.  Y isn't protected and 
has a rewrite rule to Z.  Z is secured.  You see from inspection from 
a (signed) root down that there is no break in the chain to X and Z, 
but there is the break to Y.

DNSSEC is protecting the querier in that you get to validate what you 
can (where there is data).  But does that help the application?  Not 
really.  This is why I think DNSSEC is there just to benefit the DNS, 
not the application.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

v2.23.0 | Report a Bug | By Email