Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-stale-07.txt> (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 11 September 2019 19:41 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 23A9B120812; Wed, 11 Sep 2019 12:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CfeowzG18b0H; Wed, 11 Sep 2019 12:41:22 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23261201E4; Wed, 11 Sep 2019 12:41:22 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 014B02A4E8E; Wed, 11 Sep 2019 15:41:21 -0400 (EDT)
Date: Wed, 11 Sep 2019 15:41:21 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org, dnsop@ietf.org
Message-ID: <20190911194121.GI21772@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
References: <156821841762.13409.15153693738152466982.idtracker@ietfa.amsl.com> <91411A04-4DD6-47D6-A4CC-AD8747B21361@dukhovni.org> <alpine.DEB.2.20.1909112006550.5352@grey.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1909112006550.5352@grey.csi.cam.ac.uk>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ey0yIYiI2uPdpgKlugG5afrbnAs>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-stale-07.txt> (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard
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: Wed, 11 Sep 2019 19:41:25 -0000

On Wed, Sep 11, 2019 at 08:22:37PM +0100, Tony Finch wrote:

> 3.2.1. Format
> 
> All RRs have the same top level format shown below:
> 
> [ snip ]
> 
> TTL             a 32 bit signed integer that specifies the time interval
>                 that the resource record may be cached before the source
>                 of the information should again be consulted.
> [...]
>
> 4.1.3. Resource record format
> 
> TTL             a 32 bit unsigned integer that specifies the time
>                 interval (in seconds) that the resource record may be
>                 cached before it should be discarded.

These are the wire format for "TTLs in motion" (on the wire, in DNS
*messages*), where the residual TTL of a cached record could perhaps
become negative (and yet, sent in an answer).  Yes, it is unfortunate
the RFC1035 has two conflicting definitions.

If we allow unsigned TTLs in excess of 68 years for "TTLs at rest"
(in authoritative zone files), then I guess we're compelled to
tolerate them when copied into "TTLs in motion" in messages on the
wire, but my preference (had I the cycles to follow the WG phase
of this draft) would have been to make TTLs signed both at rest and
in motion, at the cost of ruling out use of TTLs >= 2^31s in zone
files.

That is, it may be safer to treat 68+ year TTLs (don't do that!)
as already expired, than to treat potentially "negative" TTLs as
large positive TTLs.

-- 
	Viktor.