Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL?

Mark Nottingham <mnot@mnot.net> Tue, 08 May 2018 00:11 UTC

Return-Path: <mnot@mnot.net>
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 10D8812D7F7 for <doh@ietfa.amsl.com>; Mon, 7 May 2018 17:11:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=QXhctSnr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E+55XHmh
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 Hl4sf2c3MnRV for <doh@ietfa.amsl.com>; Mon, 7 May 2018 17:10:59 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4A712708C for <doh@ietf.org>; Mon, 7 May 2018 17:10:59 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A99BD224DE; Mon, 7 May 2018 20:10:58 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 07 May 2018 20:10:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=OSOv4ZivPsiluGRAvc4/rKQcL6zep 7uU+ZxJBJMVpf4=; b=QXhctSnr1Fdi/aDfBKAomI5T1UFJw9C/gTBuKk4r7pLOw uSR+PhqoylAaT6cwNFdhtCkML5URChA55+7oqy+kkIlijW8OS2An6TzasiDQEmHI IXwPcvj3Nul0BAjk+LfkFfEa7DiCTsD1fcLR+SlLsAteSE9m1fD3ZY6d1vDYC29F 1m8CgMBrdS0KstC6k8h4kh/T/KhDokZ4ihz7c465WSDC4D7/P0Sor8gWeIrcyA02 B/ye5g6VAYWMmYgTm0BTLxoT9/VixJzqZd7q1T4lNdyOm98eRt96qskO0x0pwREt u/27fknQ7cyzKhWIyzVxGd/dti34vnCk3mybDxWcA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=OSOv4Z ivPsiluGRAvc4/rKQcL6zep7uU+ZxJBJMVpf4=; b=E+55XHmhSvvg/MO/CqL0Z3 8X9dwRfYpR6L2rp0OZ0oQbB6spcz2WiF05srS7X3bJG04k6mvGltIRMliaFZHvPQ qEvqpLJ0uHnDEYZ256DMcZxPOB6f4/Ii63gQPfDhIVQAMxqsfAGhfbx0d4u2Jbe7 wzAmc6oMamxYFRG3zH3hKFk9M7qROLPD+GZSX9aJOTZbo5kI7F1hyfq/DF5CrZOW zUbZAjp4jinvTzerx8RFgh9Zu+QaecGUnXCZJh0rjDxP1M+R2/SUUYmpetqfvbcz 6w8Ymlz7+vKtqf/+Ua30WrWV9pPFcLiexGf1bFocL2ZldHgeGaDoh/aYIWKocDZA ==
X-ME-Sender: <xms:EuvwWmBPZjYzqHTAJfjYzSDlGoh35YRhg9pcMZ1IogX43uPq3EcJFA>
Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 0E7A6E491A; Mon, 7 May 2018 20:10:56 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org>
Date: Tue, 8 May 2018 10:10:53 +1000
Cc: DoH WG <doh@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net>
References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org>
To: Paul Hoffman <paul.hoffman@icann.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/eL977NfBS5K3zIukJ5408-yNS_E>
Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL?
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, 08 May 2018 00:11:02 -0000

On 3 May 2018, at 8:23 am, Paul Hoffman <paul.hoffman@icann.org> wrote:
> 
> I'm going to re-up this here on the list. Please see the discussion on
>   https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153
> 
> It would be handy if people who disagree with each other offer text *on the list*, not pull requests, specifying what they want the text in the draft to say. Then, people to try to come to consensus on this. (Yes, some people are more comfortable with editing pull requests; I feel that this issue is too important to not have the discussion here on the list.)

Proposal:

Cache Interaction {#caching}

A DNS API request can pass through a hierarchy of caches that include both HTTP and DNS specific caches. HTTP caches are by design generic; that is, they do not understand this protocol. Even if a DNS API client has modified its cache implementation to be aware of DOH semantics, it does not follow that all upstream caches (for example, in proxies, server-side gateways and Content Delivery Networks) will be.

As a result, DNS API servers need to carefully consider the HTTP caching metadata they send in response to GET requests (POST requests are not cacheable unless specific response headers are sent; this is not widely implemented, and not advised for DOH). 

In particular, they are encouraged to assign an explicit freshness lifetime (Section 4.2 of {{RFC7234}}), since HTTP caches can assign heuristic freshness otherwise (Section x.x of {{RFC7234}}), thereby taking control out of the hands of the DNS API server.

Typically, the assigned freshness lifetime of a given DOH HTTP response will use the smallest TTL in the Answer section of the DNS response as a maximum. For example, if a HTTP response carries three RRsets with TTLs of 30, 600 and 300, the HTTP freshness lifetime usually ought to be no more than 30 seconds (e.g., "Cache-Control: max-age=30"), so that the RRset with the smallest TTL is not stale when retrieved from cache.

This assures that none of the RRsets contained within are served stale from an HTTP cache.

If the DNS response has no records in the Answer section, and the DNS response has an SOA record in the Authority section, the response freshness lifetime typically ought not be greater than the MINIMUM field from that SOA record (see {{RFC2308}}).

The stale-while-revalidate and stale-if-error Cache-Control directives ({{?RFC5861}}) could be well suited to a DOH implementation when allowed by server policy. Those mechanisms allow a client, at the server's discretion, to reuse a cache entry that is no longer fresh.

DNS API servers also need to consider caching when generating responses that are not globally valid. For instance, if a DNS API server customizes a response based on the client's identity, it would not want to allow global reuse of that response. This could be accomplished through a variety of HTTP techniques such as a Cache-Control max-age of 0, or by using the Vary response header ({{RFC7231}}, Section 7.1.4) to establish a secondary cache key ({{RFC7234}}, Section 4.1).

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. 

DNS API clients that encounter stale responses (either because the HTTP freshness lifetime has passed, or because one or more RRset's lifetime has passed) can request a fresh copy by using the "no-cache" request cache control directive ({{RFC7234}}, Section 5.2.1.4) and similar controls. Note that some caches might not honour these directives, depending upon their configuration.

HTTP conditional requests ({{RFC7232}}) may be of limited value to DOH, as revalidation provides only a bandwidth benefit and DNS transactions are normally latency bound. Furthermore, the HTTP response headers that enable revalidation (such as "Last-Modified" and "Etag") are often fairly large when compared to the overall DNS response size, and have a variable nature that creates constant pressure on the HTTP/2 compression dictionary {{RFC7541}}. Other types of DNS data, such as zone transfers, may be larger and benefit more from revalidation.


--
Mark Nottingham   https://www.mnot.net/