IETF Logo Mail Archive

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

fujiwara@jprs.co.jp Thu, 06 March 2014 17:58 UTC

Return-Path: <fujiwara@jprs.co.jp>
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 84C381A010A for <dnsop@ietfa.amsl.com>; Thu, 6 Mar 2014 09:58:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.061
X-Spam-Level:
X-Spam-Status: No, score=0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no
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 29dFuYuXztYB for <dnsop@ietfa.amsl.com>; Thu, 6 Mar 2014 09:58:11 -0800 (PST)
Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 1B52A1A00C3 for <dnsop@ietf.org>; Thu, 6 Mar 2014 09:58:11 -0800 (PST)
Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s26HvxgI005388; Fri, 7 Mar 2014 02:57:59 +0900
X-AuditID: ac120820-b7f196d00000167f-1c-5318b7240f71
Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 89.75.05759.427B8135; Fri, 7 Mar 2014 02:57:56 +0900 (JST)
Date: Fri, 07 Mar 2014 02:57:55 +0900
Message-Id: <20140307.025755.193698548.fujiwara@jprs.co.jp>
To: dot@dotat.at
In-Reply-To: <B3EC68DF-8A61-4A68-924D-0A8C14070BF4@dotat.at>
References: <20140305.192356.183042919.fujiwara@jprs.co.jp> <B3EC68DF-8A61-4A68-924D-0A8C14070BF4@dotat.at>
From: fujiwara@jprs.co.jp
X-Mailer: Mew version 6.5 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsWyRoiFT1d1u0SwQc82fou7by6zWGzrucjm wOSx73gDq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDK+TDjDVrCbteJ5P3sD4zqWLkZODgkBE4lt H1qhbDGJC/fWs3UxcnEICZxklPi4/SErSIJFQFvi2uvFzF2MHBy8AtYSh7pDQMIiAgISH+ZO ZQSxmQWEJG43HmUDsYUF7CT655wDi3MK2EjcuLiEGcQWEsiV+HJ2JlgNm4CkxObPrcwQe4FG XvnJBDFeUOLvDmGIkVoSPTMes0PY8hLb385hnsDIPwuhahaSqllIqhYwMq9ilMlPS9MtTs1L Kc5NNzDUK6nM18sqKCrWSwbRmxjBQcihsINxximDQ4wCHIxKPLzTFkkEC7EmlhVX5h5ilORg UhLlTV8PFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCuwiknDclsbIqtSgfJiXNwaIkznv8z5lA IYH0xJLU7NTUgtQimKwMB4eSBK/hFqBGwaLU9NSKtMycEoQ0EwcnyHAeoOG3QWp4iwsSc4sz 0yHypxglpcR5l4IkBEASGaV5cL2vGMWBXhDmfQ6S5QEmFLiuV0ADmYAGRvOJgwwsSURISTUw 5vGePdi3K0J9e26Mea+P7d6I1qxQha2MW6cGPDj12ufwJfEs25NsTh38UTbN/zKs+vezSicW s4q67UmaEM3DFaoz6S1vzOXEjqsPHvkcTWmaPUP29uNVfjMtp9+/eHDZOabokkCz5GCtq3JR Fu/2ltY8eP79Y5PjBD9RtqzwEzt1OP/3Hw9UYinOSDTUYi4qTgQAsYnAiOUCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/swng-lN74cV-WmTXfLkAO29fL0U
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 17:58:12 -0000

> 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>

v2.23.0 | Report a Bug | By Email