Re: [Doh] Draft -09 and WGLC #2

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 29 May 2018 03:35 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F4F12DA15 for <doh@ietfa.amsl.com>; Mon, 28 May 2018 20:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=GfUmbeSP; dkim=pass (1024-bit key) header.d=yitter.info header.b=JPYidV5+
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 5sQF7Y7DuGHo for <doh@ietfa.amsl.com>; Mon, 28 May 2018 20:35:24 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1235B12D945 for <doh@ietf.org>; Mon, 28 May 2018 20:35:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 54A24BDEF9 for <doh@ietf.org>; Tue, 29 May 2018 03:35:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527564923; bh=52pPK49dARdkzTrg5rWs2n/U8UcmsiAnnJ1SLWEN8LE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=GfUmbeSPjYzjVfPNesQ2a5+AbCv7YnRnxbwU1+gcqBgsutuml25URI+Z+G8IFVFzg HUpwxV1FXSLVKl1eUrgPCthSNM7arhM4F7qrFzekeFx76MHziJNiJf8bm4hgpu05V6 haueluT2QbAb4+e2xEKJxOiSaXpRc/DYKV7nzthA=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP50NzTZc_AZ for <doh@ietf.org>; Tue, 29 May 2018 03:35:22 +0000 (UTC)
Date: Mon, 28 May 2018 23:35:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527564922; bh=52pPK49dARdkzTrg5rWs2n/U8UcmsiAnnJ1SLWEN8LE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=JPYidV5+JJ1IGKmVpugPk29bT0DT8TEj+IuG6MZav1Qf4gbM9W9er8dlwuOr9+kMW 1cIIZi1NL6hW9FsUR+bQIAk3nDdMBEu+qXcuJZE/ydmi9JhnApqxgaD+pmAweErtjj 9nzt8BkmC/II6qva7qavfrDwjwW6NqIc3/p7rYyQ=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: doh@ietf.org
Message-ID: <20180529033519.GB18049@mx4.yitter.info>
References: <CAHbrMsCxkogJ-fzubf7cPgvbeGAhWUFKV3crrmn4ee6=fDnqwQ@mail.gmail.com> <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <CAOdDvNrpLwF5jpn1YA4-HXsfGxVkdds+xHVd6Bxy0Ux+3nrcrA@mail.gmail.com> <CA9BEE64-9F16-4CCC-A1E0-4C7FD45C455C@icann.org> <20180528161043.GB12038@mx4.yitter.info> <CAOdDvNoE_UT9Lb1sng3GkC3nKSqSqSvh0oOKxaMYv9DsNj=Ldg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAOdDvNoE_UT9Lb1sng3GkC3nKSqSqSvh0oOKxaMYv9DsNj=Ldg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/wOTSozmE0vJOg0S4lfPKi_1UBJ8>
Subject: Re: [Doh] Draft -09 and WGLC #2
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2018 03:35:26 -0000

On Mon, May 28, 2018 at 09:40:02PM -0400, Patrick McManus wrote:
> ,
> 
> 
>        DNS API clients MUST account for the Age response header's value
>        ([RFC7234]) when calculating the DNS TTL of a response.  For example,
>        if a RRset is received with a DNS TTL of 600, but the Age header
>        indicates that the response has been cached for 250 seconds, the
>        remaining lifetime of the RRset is 350 seconds.
> 
> 
>     the TTL.  What this passage means is that the data that comes in to a
>     DNS API client _is not_ suitable to hand straight to the local stub
>     subsystem: instead, some additional processing MUST be performed in
>     order to ensure that TTLs are not accidentally extended by accident.
> 
> 
> That's not only what it means, it seems to me that's what it says :)

No, that's what it implies, but it's not what it says.  That's
actually what I'm complaining about.  The DNS is the swamp it is
partly because of the number of places in STD13 that depend on
implication rather than instruction for people to do the right thing.
A contract programmer with an alloted 18 hours will spend exactly 18
hours, at most, to do this.  So let's make it explicit.

Perhaps this: "remaining lifetime …seconds.  DNS API clients SHOULD
NOT pass along the received DNS RRset without decrementing the TTL to
match the remaining lifetime.  Doing so may accidentally prolong the
lifetime of a cached DNS RRset, and therefore ought not to be passed
along without strong evidence that the requesting client will process
the resulting cached entries correctly."

That's awkward and needs some work.  But it's at least explicit.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com