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
>