[Doh] conflict between HTTP and DNS cache granularity

Petr Špaček <petr.spacek@nic.cz> Mon, 19 March 2018 23:21 UTC

Return-Path: <petr.spacek@nic.cz>
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 87F8C12D95E for <doh@ietfa.amsl.com>; Mon, 19 Mar 2018 16:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 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_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 WOlY_lB8ynAQ for <doh@ietfa.amsl.com>; Mon, 19 Mar 2018 16:21:53 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 7CFAC12D7EF for <doh@ietf.org>; Mon, 19 Mar 2018 16:21:53 -0700 (PDT)
Received: from [192.168.0.237] (cpc130666-camd16-2-0-cust366.know.cable.virginm.net [82.36.141.111]) by mail.nic.cz (Postfix) with ESMTPSA id 4931D62373 for <doh@ietf.org>; Tue, 20 Mar 2018 00:21:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1521501711; bh=uWqjiWyjRJ4e/BxRzevjBKPJI6kff7DxjYTvcICLn94=; h=To:From:Date; b=W2wI7C06TWcJwdxgoGiQe4mNVipdx8vX9e9BXFv4dLz/XkvR0BDpuSqEcXDUh+O2F C5ll6Vo8TQplAXsVf2zNz54DhV0tO9f+yR4HPIqEvr5PVag4Kngay9WnAHTUb034SS 4HWSJcGhvEKkwDfUsE4S7IlO3UfVQvGesVFBQpa4=
To: DoH WG <doh@ietf.org>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <f19857a4-0b55-9210-e4f5-7fb49ccda1de@nic.cz>
Date: Tue, 20 Mar 2018 00:21:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/3ObN4IsoPUYZvWhNJ6RDu1GTbZw>
Subject: [Doh] conflict between HTTP and DNS cache granularity
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: Mon, 19 Mar 2018 23:21:55 -0000

Hello doh,

section 7.1.  Cache Interaction at the moment does not mention
difference between DNS and HTTP caching granularity.

Observations:
- DNS answer might contain more than 1 RR type (CNAME + original QTYPE)
- DNS TTL is per-RRset but HTTP caching header is per request, which in
terms of DoH means per DNS message (which potentially combines multiple
RRsets)

Thus the HTTP "TTL" has to be derived somehow, most likely using minimal
value from all RRsets present in the DNS message.

Without this limit a bad things will happen when DNS message "partially"
expires, which is not handled by DoH protocol itself and will be
detected late in the process on the DoH client side.

E.g. a browser receives cached DoH answer from a caching proxy. It
contains the same DNS message as before with following RRs and headers:
; Age = 20
www.example.com. 100 CNAME srv.example.net.
srv.example.net. 10      A 192.0.2.1

Now, the srv.example.net. A RR has TTL -10 seconds so its invalid and
client has to deal with it somehow. It is up to WG to decide whether
client should re-query for expired RRs by itself or if DoH server should
handle this by shortening TTLs so the client cannot encounter this
partial expiration ...

Well, mixing DNS and HTTP semantics is fun.

-- 
Petr Špaček  @  CZ.NIC