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

Patrick McManus <pmcmanus@mozilla.com> Wed, 30 May 2018 02:19 UTC

Return-Path: <pmcmanus@mozilla.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 8EEA112E8C3 for <doh@ietfa.amsl.com>; Tue, 29 May 2018 19:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 A2eqZ1EPy35V for <doh@ietfa.amsl.com>; Tue, 29 May 2018 19:19:25 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3D743127419 for <doh@ietf.org>; Tue, 29 May 2018 19:19:25 -0700 (PDT)
Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id A75BC3A02A for <doh@ietf.org>; Tue, 29 May 2018 22:19:24 -0400 (EDT)
Received: by mail-oi0-f49.google.com with SMTP id d5-v6so11933526oib.5 for <doh@ietf.org>; Tue, 29 May 2018 19:19:24 -0700 (PDT)
X-Gm-Message-State: ALKqPwdJ/UWQHdaXb2vxhWJ02aMRbtdsjplU3JjgN8AH4k4rR2nOgKPi eXPVxRrWmC0z1vzwwnoCuUe7x+x2u6vXyUSCrso=
X-Google-Smtp-Source: ADUXVKLy4FrBxsf9WnNUGLhS/JknhF2cRgXbO6asZu94NpKSVre9UDM2YJxx9lFdDBM6UMq8QIq2mxYJiSddodRkRDE=
X-Received: by 2002:aca:1a06:: with SMTP id a6-v6mr486526oia.213.1527646764380; Tue, 29 May 2018 19:19:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Tue, 29 May 2018 19:19:23 -0700 (PDT)
In-Reply-To: <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> <20180529033519.GB18049@mx4.yitter.info>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 29 May 2018 22:19:23 -0400
X-Gmail-Original-Message-ID: <CAOdDvNrfqYXJpa8ueiYcX3FAYomc3ZPTvac3WXj_FKMY02EyDw@mail.gmail.com>
Message-ID: <CAOdDvNrfqYXJpa8ueiYcX3FAYomc3ZPTvac3WXj_FKMY02EyDw@mail.gmail.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bbb78b056d62fabd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/icn2JBXDaGm-w-HOoYXa_qLccPM>
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: Wed, 30 May 2018 02:19:28 -0000

I think my objection is that there is no assumption a client is passing
anything along - much less passing it along in dns wireformat. It might
cache it terminally, it might pass it along in http (in which case it would
modify the Age response header as 7234 defines..), etc..

what all of these cases have in common is they need to know what the TTL of
the RRset is at the time it is received, and that's what the text describes.

On Mon, May 28, 2018 at 11:35 PM, Andrew Sullivan <ajs@anvilwalrusden.com>;
wrote:

> 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
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>