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

Tony Finch <dot@dotat.at> Wed, 11 September 2019 19:22 UTC

Return-Path: <dot@dotat.at>
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 973BC1208AB; Wed, 11 Sep 2019 12:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=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 EBY3pdobzacr; Wed, 11 Sep 2019 12:22:39 -0700 (PDT)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4EBC12006E; Wed, 11 Sep 2019 12:22:39 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:45506) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1i88CL-001e5z-1S (Exim 4.92.2) (return-path <dot@dotat.at>); Wed, 11 Sep 2019 20:22:37 +0100
Date: Wed, 11 Sep 2019 20:22:37 +0100
From: Tony Finch <dot@dotat.at>
To: ietf@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-serve-stale@ietf.org
In-Reply-To: <91411A04-4DD6-47D6-A4CC-AD8747B21361@dukhovni.org>
Message-ID: <alpine.DEB.2.20.1909112006550.5352@grey.csi.cam.ac.uk>
References: <156821841762.13409.15153693738152466982.idtracker@ietfa.amsl.com> <91411A04-4DD6-47D6-A4CC-AD8747B21361@dukhovni.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_aR3DMf9WnKmmXsl0lWWYMplfrA>
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:22:43 -0000

Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>
> I am a bit puzzled by the lack of text that motivates treating TTLs
> with the high bit set as positive?  Why is this desirable, and why
> in this draft?  What is the connection between TTLs with the high
> bit set and Serve Stale?  If some resolver inadvertently returns
> stale data whose TTL has expired, it might return a negative TTL,
> and treating that as "0" seems safer than as 137 years (likely
> then capped to 7 days).

I guess this change is a result of trying to fill in the missing parts of
what a TTL means. I don't think this change is necessary: the draft could
be a bit less fussy without it.

The draft says:

   [RFC2181] aimed to provide "the precise definition of the Time to
   Live", but in Section 8 was mostly concerned with the numeric range
   of values and the possibility that very large values should be
   capped.  (It also has the curious suggestion that a value in the
   range 2147483648 to 4294967295 should be treated as zero.)

Which implies to me that the authors didn't spot the TTL bug in RFC 1035
that RFC 2181 was fixing with the curious suggestion.

RFC 1035 is inconsistent about the signedness of TTLs, so RFC 2181 fixed
it by specifying that TTLs are to be treated as unsigned (as usual for DNS
data) but must only use the range of positive signed 32 bit numbers.

Quoting from RFC 1035 to point out the curious copy and paste bug:

[ snip ]

3.2. RR definitions

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.

[ snip ]

4.1.3. Resource record format

The answer, authority, and additional sections all share the same
format: a variable number of resource records, where the number of
records is specified in the corresponding count field in the header.
Each resource record has the following format:

[ snip a second copy of the same info ]

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.

[ snip ]

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Rattray Head to Berwick upon Tweed: Southwesterly veering northwesterly later,
4 or 5, increasing 6 at times, becoming variable 3 or 4 for a time in south.
Slight or moderate, occasionally smooth in south. Rain later, otherwise mainly
fair. Good, occasionally poor later.