Re: [dnsext] CNAME check Re: [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16]
"Yao Jiankang" <yaojk@cnnic.cn> Thu, 02 February 2012 01:46 UTC
Return-Path: <yaojk@cnnic.cn>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB3B11E80B0 for <dnsext@ietfa.amsl.com>; Wed, 1 Feb 2012 17:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.584
X-Spam-Level:
X-Spam-Status: No, score=-100.584 tagged_above=-999 required=5 tests=[AWL=1.414, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgL9vBHfb8ZY for <dnsext@ietfa.amsl.com>; Wed, 1 Feb 2012 17:46:14 -0800 (PST)
Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 8833611E808A for <dnsext@ietf.org>; Wed, 1 Feb 2012 17:46:11 -0800 (PST)
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown127.0.0.1 (HELO computer) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 02 Feb 2012 09:46:04 +0800
Message-ID: <002c01cce14c$6c0e91c0$cb01a8c0@computer>
From: Yao Jiankang <yaojk@cnnic.cn>
To: dnsext@ietf.org
References: <4f292fa5.a874ec0a.330e.28b4SMTPIN_ADDED@mx.google.com><002101cce0e8$71676de0$cb01a8c0@computer><20120201151613.GE22825@crankycanuck.ca><006c01cce0f7$d22250f0$cb01a8c0@computer> <20120201160500.GA23020@mail.yitter.info>
Date: Thu, 02 Feb 2012 09:46:02 +0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="ISO-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
Subject: Re: [dnsext] CNAME check Re: [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16]
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2012 01:46:14 -0000
----- Original Message ----- From: "Andrew Sullivan" <ajs@anvilwalrusden.com> To: <dnsext@ietf.org> Sent: Thursday, February 02, 2012 12:05 AM Subject: Re: [dnsext] CNAME check Re: [WGLC: draft-ietf-dnsext-dnssec-bis-updates-16] > Hi, > > No hat. > > On Wed, Feb 01, 2012 at 11:40:23PM +0800, Yao Jiankang wrote: > >> >Now, imagine a FOO-unaware validating resolver that follows the advice >> >you suggest. It queries a signed zone with a FOO record. The >> >resolver doesn't know about FOO. Therefore, it doesn't know that >> >there could be a synthetic CNAME at that name, resulting from the FOO >> >record. Therefore, it will treat the unsigned CNAME as bogus, and the >> >backwards compatibility doesn't happen. >> >> My suggested word is that "this CNAME should be neglected". It means >> that the FOO-unaware validating resolver(when doing DNSSEC checking) >> will see this unsigned CNAME as nothing, not accept it, and also not >> report it as bogus. When a unsigned CNAME appears, the FOO-unaware >> validating resolver(when doing DNSSEC checking) just sees nothing >> and negelcts this CNAME. So I do not think that it will cause any >> hole in DNSSEC. > > Ok, so the resolver ignores the unsigned CNAME (i.e. it's as though it > wasn't received), and returns what to the initiator of the query > (i.e. the originating resolver or the application or whatever)? > NOERROR with an empty answer? I don't understand how this is any > better than treating the result as bogus; the originator of the query > still can't get to the destination it was querying for, right? > For example, Assume that the DNSEXT supports BNAME in the future. the FOO-unaware validating resolver(when doing DNSSEC checking) will not regard the BNAME's CNAME synthesis as bogus. So the section 5.2. " BNAME alias algorithm identifiers" is not needed. the FOO-unaware validating resolver(when DNSSEC check is not enabled) can use the CNAME.(unsigned CNAME is only neglected when DNSSEC check is enabled) Jiankang Yao Otherwise, the > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >
- [dnsext] CNAME check Re: [WGLC: draft-ietf-dnsext… Yao Jiankang
- Re: [dnsext] CNAME check Re: [WGLC: draft-ietf-dn… Andrew Sullivan
- Re: [dnsext] CNAME check Re: [WGLC: draft-ietf-dn… Andrew Sullivan
- Re: [dnsext] CNAME check Re: [WGLC: draft-ietf-dn… Yao Jiankang