Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02

Tim Wicinski <tjw.ietf@gmail.com> Thu, 06 March 2014 18:00 UTC

Return-Path: <tjw.ietf@gmail.com>
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 E30461A0048 for <dnsop@ietfa.amsl.com>; Thu, 6 Mar 2014 10:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 2wW6Ehur6t-A for <dnsop@ietfa.amsl.com>; Thu, 6 Mar 2014 10:00:37 -0800 (PST)
Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id EF95E1A0040 for <dnsop@ietf.org>; Thu, 6 Mar 2014 10:00:36 -0800 (PST)
Received: by mail-bk0-f48.google.com with SMTP id mx12so772168bkb.21 for <dnsop@ietf.org>; Thu, 06 Mar 2014 10:00:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KYJ/qLGH4+eZyRAhBDoCXRPWT/a24Mnn6es4y0FVPXk=; b=PiXoUQqhBhto+SNwVFf3Ddn8wInXsCVKL3PO5OvCVE16DmOWXKxNoSH5D0Y4GAtLYA tXXxj8hF6Zi1liyWrjRS8tSNFcHkKdrD0z2IGiBGzcIv4bZWYnqHSwglE7SyZuB7A3nk YtuBMlfsAjAmO5aMTcmAwMfJu5HPzi8xIRN6TdD2HirbdOECISjHCUL6nx2WmKJBaW6N mJbFIxoPnTjX0TV37PdZsaZJSfgVz/6x/W6iEmlOzrfKDHFRidudZaKTVkpTq5bpdKEW o+tQqi0LcKaY0g0Uq2gOQ+jenV+jFWmDj2a3Wa9jNAt3sqjm+G0RxlYBjYNJT6YM9FHh Cj3g==
X-Received: by 10.204.102.7 with SMTP id e7mr654064bko.84.1394128832360; Thu, 06 Mar 2014 10:00:32 -0800 (PST)
Received: from dhcp-a2ca.meeting.ietf.org (dhcp-a2ca.meeting.ietf.org. [31.133.162.202]) by mx.google.com with ESMTPSA id dj6sm10307932bkc.5.2014.03.06.10.00.30 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Mar 2014 10:00:31 -0800 (PST)
Message-ID: <5318B7BE.1020302@gmail.com>
Date: Thu, 06 Mar 2014 18:00:30 +0000
From: Tim Wicinski <tjw.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Thunderbird/29.0a2
MIME-Version: 1.0
To: fujiwara@jprs.co.jp, dot@dotat.at
References: <20140305.192356.183042919.fujiwara@jprs.co.jp> <B3EC68DF-8A61-4A68-924D-0A8C14070BF4@dotat.at> <20140307.025755.193698548.fujiwara@jprs.co.jp>
In-Reply-To: <20140307.025755.193698548.fujiwara@jprs.co.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/Ll69Y03PJ3isqXk-vhtK5aRB7cw
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02
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: <http://www.ietf.org/mail-archive/web/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: Thu, 06 Mar 2014 18:00:39 -0000

Hi,

I believe there may of been some take away from Vancouver on direction. 
I have a hand written note on this, but it was lost in the discussion on 
Key Exchanges.

I will followup with you after tonight's meeting, and apologies for 
dropping this.

tim

On 3/6/14, 5:57 PM, fujiwara@jprs.co.jp wrote:
>> From: Tony Finch <dot@dotat.at>
>> It is an interesting draft and I can see why the problem concerns you. The dummy DS is a clever work-around, but it is a pity about the validation bug in Google public DNS.
> Thanks. I'm not sure that the validation error is a bug or not.
>
>> I wonder about the possibility of adjusting the rules for caching delegations. Would it make sense to remember that a referral is insecure for the lifetime of the NS RRset, instead of the lifetime of the negative DS answer?
> This idea requires updating RFC 2308.
>
> I'm afraid that when newly registered DS RR will be used if the
> negative DS answer is cached.
>
> --
> Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop