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