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.
- [DNSOP] Last Call: <draft-ietf-dnsop-serve-stale-… The IESG
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Viktor Dukhovni
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Tony Finch
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Viktor Dukhovni
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Stephane Bortzmeyer
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Viktor Dukhovni
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-serve-st… Puneet Sood