Re: [DNSOP] Fw: New Version Notification for draft-arnt-yao-dnsop-root-data-caching-00.txt
Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Fri, 15 February 2019 12:48 UTC
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C11130F82 for <dnsop@ietfa.amsl.com>; Fri, 15 Feb 2019 04:48:59 -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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 FduJX-R_lTUb for <dnsop@ietfa.amsl.com>; Fri, 15 Feb 2019 04:48:58 -0800 (PST)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B1F128AFB for <dnsop@ietf.org>; Fri, 15 Feb 2019 04:48:57 -0800 (PST)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 29C38C05EA; Fri, 15 Feb 2019 12:50:40 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1550235040; bh=sZ8/eyqzkdrbvrTC/j+/q+xKKzETgAkaN94vKOhffto=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TUUqzFDCQdrSlYKm3SM56UV7CpC67TGCb8rNQHPDTrdJzw81Skd+DFXtHKwHWqmgE DWjhGisDI6gc9kqKbegMT10VKQdPxfb4HhGYdHaUyF8vJCX+Ekx08jvjDE4a0/QpU/ pKUz6FD2r27nUN11mNA1d/53tHRhbzo00+TvQt3s=
Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1550235039-26265-2661/9/24; Fri, 15 Feb 2019 12:50:39 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: Bob Harold <rharolde@umich.edu>
Cc: Tony Finch <dot@dotat.at>, Jiankang Yao <yaojk@cnnic.cn>, IETF DNSOP WG <dnsop@ietf.org>
Date: Fri, 15 Feb 2019 13:48:53 +0100
Mime-Version: 1.0
Message-Id: <a3ef79a2-5efd-47e2-aa0c-1be5412ffcfc@gulbrandsen.priv.no>
In-Reply-To: <CA+nkc8Bkpr7PDSyWjGQftaODj7pffmzWJUeYghGScFLi0CyHpw@mail.gmail.com>
References: <4d51e683.32d.168ea651be8.Coremail.yaojk@cnnic.cn> <alpine.DEB.2.20.1902141349060.18720@grey.csi.cam.ac.uk> <587d85ee-73bc-40f4-aae8-550d877ca6d1@gulbrandsen.priv.no> <CA+nkc8Bkpr7PDSyWjGQftaODj7pffmzWJUeYghGScFLi0CyHpw@mail.gmail.com>
User-Agent: Trojita/0.7; Qt/5.7.1; xcb; Linux; Devuan GNU/Linux 2.0 (ascii)
Content-Type: text/plain; charset="utf-8"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qAAq7qPVkufCVk3DMiDGVKjLQxM>
Subject: Re: [DNSOP] Fw: New Version Notification for draft-arnt-yao-dnsop-root-data-caching-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 15 Feb 2019 12:49:00 -0000
On Thursday 14 February 2019 22:41:56 CET, Bob Harold wrote: > The draft assumes typical TTL is a week, but what I see in the root zone is: ... I hoped noone would notice. It's good rather than bad, overall, but it complicates the description. A good resolver verifies DNSSEC, so the two-day RRs tend to be kept alive for as long as the six-day RRs are. Once the six-day RRs are discarded from the resolver's cache, the two-day RRs are no longer needed for verification, and after about a month they cease being refreshed. In effect, the six-day RRs (typically NS records) have an average lifetime of slightly less than three months after the last use, and the supporting DNSSEC RRs of slightly more than four months after the last time the NS is needed. The SOA record is a special case, but IMO too minor to matter. The focus here is to eliminate root-zone queries as a significant delay factor for day-to-day DNS use, without introducing additional moving parts such as humans or crontabs downloading zone files. Caching one SOA too long or too short won't make much difference. Arnt
- [DNSOP] Fw: New Version Notification for draft-ar… Jiankang Yao
- Re: [DNSOP] Fw: New Version Notification for draf… Tony Finch
- Re: [DNSOP] Fw: New Version Notification for draf… Warren Kumari
- Re: [DNSOP] Fw: New Version Notification for draf… Benno Overeinder
- Re: [DNSOP] Fw: New Version Notification for draf… Arnt Gulbrandsen
- Re: [DNSOP] Fw: New Version Notification for draf… Bob Harold
- Re: [DNSOP] Fw: New Version Notification for draf… Arnt Gulbrandsen
- Re: [DNSOP] Fw: New Version Notification for draf… Bob Harold