Re: [dnsext] TTL on DS records

Andrew Sullivan <ajs@anvilwalrusden.com> Sun, 22 February 2015 03:14 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9521A005D for <dnsext@ietfa.amsl.com>; Sat, 21 Feb 2015 19:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.758
X-Spam-Level: *
X-Spam-Status: No, score=1.758 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 KL4k3rTGIryu for <dnsext@ietfa.amsl.com>; Sat, 21 Feb 2015 19:14:00 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6961A0039 for <dnsext@ietf.org>; Sat, 21 Feb 2015 19:13:59 -0800 (PST)
Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A8F1A8A031 for <dnsext@ietf.org>; Sun, 22 Feb 2015 03:13:58 +0000 (UTC)
Date: Sat, 21 Feb 2015 22:13:57 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsext@ietf.org
Message-ID: <20150222031357.GY13877@mx1.yitter.info>
References: <FB3C26C9-BC39-4819-9BE8-167E2A3711B7@verisign.com> <54E862FF.1080808@blipp.com> <CFE90DD0-9AD1-469F-8272-20C9443056FD@frobbit.se> <20150221122103.GJ13877@mx1.yitter.info> <20150221191934.GA43112@PorcupineTree.Speedport_W_724V_01011601_00_009> <20150221205034.GT13877@mx1.yitter.info> <8025FA20-9C5D-4CB9-9A6F-C43080C35229@ogud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8025FA20-9C5D-4CB9-9A6F-C43080C35229@ogud.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/lXoOXLxGjKxG9IibZMc8mJmKKbQ>
Subject: Re: [dnsext] TTL on DS records
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 22 Feb 2015 03:14:02 -0000

On Sat, Feb 21, 2015 at 08:42:38PM -0500, Olafur Gudmundsson wrote:
> 
> No Andrew it effectively is the MAX( DS TTL, DNSKEY TTL) 

I suppose it's true that, having validated the DNSKEY once, you're not
going to check it again.  It does still entail that the parent zone
gets to make TTL decisions that affect the lookups necessary for use
of child-side data.

> Long TTL are artifacts of decisions taken long time ago
> and they need to be reexamined. 

I don't have any trouble with the idea that most caches aren't going
to keep anything for a week, and I know lots of zones that have very
short TTLs.  But as I said, it's almost completely novel in the DNS
that the parent-side decisions affect things for the child in this
way, and I think we shouldn't be cavalier about that change.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com