IETF Logo Mail Archive

Re: [Doh] meta qtypes

Ben Schwartz <bemasc@google.com> Mon, 19 March 2018 10:44 UTC

Return-Path: <bemasc@google.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 3051F126E64 for <doh@ietfa.amsl.com>; Mon, 19 Mar 2018 03:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 twYn37F64QZG for <doh@ietfa.amsl.com>; Mon, 19 Mar 2018 03:44:07 -0700 (PDT)
Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FBA3126DEE for <doh@ietf.org>; Mon, 19 Mar 2018 03:44:07 -0700 (PDT)
Received: by mail-it0-x244.google.com with SMTP id v194-v6so9739858itb.0 for <doh@ietf.org>; Mon, 19 Mar 2018 03:44:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1fGRcZDkLekociHZhlK5t4jCJ/qm+2vtUtsVLoTdtcs=; b=mkcjBKucdCztyjpk3goAZkt7LF2nkS4mKDVgXmt9DQ44XbvamMBHL0zBMwHQqKMmrr P3jaNpLgtktzch+119tMtl2WO/oYVnfmGF6uI7biNdzJVJe6DHkw85hiV80P/GwUsBur UDoSsokqNnCJyfSvAK4KgwE54hkEWLd8p2EXiau788myhtWRvl2kMhanA9BiQTSjn5Kn lhNa8NsWJwDA0XH/Lnr2y8YHoegvo68eanBcynibxN9t/2o6Dptyi8M41fJ7tmxypKtY ocLptSE9Hv+iAqtb2vPwub3GaLW596X9BCZs7SKcUlzwvyON/2ZkA1yzjnCxy3l/X9BL Pupw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1fGRcZDkLekociHZhlK5t4jCJ/qm+2vtUtsVLoTdtcs=; b=Dl0Mkb81HymemQDXKJXJ9VXzhi4rFMOKaDpNOz9qozucrBtOkyRB0lviN1C1cXdCnC I8hWZB9/7ryhi1VKdRDHDsMyljePjRPCbgO1z5s5uxlUmhaf1n8/oDusuBaZfbFXjR9e u7YugK0xg68FLfUcGkOgYivQQpDwUnIulp0mocKjoZOmvA5FB5uLjRWazX+ngcQYTgYq bfJkdhIcX/z1T9gDt5JBppmBT1qHo+C4hg/UvmtRAnUCju7IdZdvhyLuDExWiHTGKVwZ it9/uJ69xUNf+bB5dVVnzcM+RmMZL635tpHvaf4kR576o1saDw2WtZLmIiwAkHOFUA8a KaVQ==
X-Gm-Message-State: AElRT7HSLVB2iwNVICuNMRiAgmKMEsBgAUXjRoiT0RQgSZu4mvF4UzOr IsAJ2vdHWREbML8l0/Mo8T9hMOHM1n6xrPGDVUU9ZA==
X-Google-Smtp-Source: AG47ELuzAknC7cOnH1238uAkb64K+l3QQPEaOvoG80DjLh2BkARwsUFH3Dt5UUoV95OVL2YzXkmb/j06CvCyrwSmTdo=
X-Received: by 2002:a24:3093:: with SMTP id q141-v6mr10968903itq.21.1521456246232; Mon, 19 Mar 2018 03:44:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.168.210 with HTTP; Mon, 19 Mar 2018 03:44:05 -0700 (PDT)
In-Reply-To: <20180319102656.vgmu645h6bfjj3wr@miek.nl>
References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <CAOdDvNoNN98zOuPAepS0=0Nt06+UAGV1ZCrxs0J2TzQaVnJz8w@mail.gmail.com> <20180318190804.5mgxarazepfut56i@miek.nl> <20180319091634.GC16151@laperouse.bortzmeyer.org> <20180319094912.46fts2zxxlk6o2jx@miek.nl> <CAOdDvNo1TRNssGMRZMdr-Q3OfYhpQ2oquo6WEPoMjhWbnpGnQQ@mail.gmail.com> <20180319102656.vgmu645h6bfjj3wr@miek.nl>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 19 Mar 2018 06:44:05 -0400
Message-ID: <CAHbrMsBu5tMFRjvydUuhSJ9qn4StpQeNdjV1jjH-_4hZih0sJg@mail.gmail.com>
To: Miek Gieben <miek@miek.nl>
Cc: Patrick McManus <pmcmanus@mozilla.com>, DoH WG <doh@ietf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000025aaf10567c1a3a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/305YZxlQNHFw550b4jPfS1MNkAI>
Subject: Re: [Doh] meta qtypes
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 10:44:09 -0000

On Mon, Mar 19, 2018 at 6:26 AM, Miek Gieben <miek@miek.nl> wrote:

> [ Quoting <pmcmanus@mozilla.com> in "Re: [Doh] meta qtypes..." ]
>
>> we need to be careful about recommending a blind tunnel (aspect) of using
>> HTTP by just disabling caches. That's not really great and doesn't meet
>> the
>> DoH goals - HTTP has a rich language to control caching at its level which
>> I think can be well aligned with the DNS TTL architecture (and if no-cache
>> plays a role for some small part, that's fine.). There is document text
>> that already tries to discuss that in Section 6. Hopefully we can revise
>> that if necessary.
>>
>> The text already contains a normative MUST NOT about using a http
>> freshness
>> lifetimes that exceeds DNS based TTL lifetimes of the response. A DOH
>> server that cannot figure this out can comply with a freshness lifetime of
>> 0 - but the goal here is not that a DOH server is a non-DNS-aware tunnel.
>>
>> Please note the draft uses language about freshness lifetime instead of
>> normatively referencing cache-control for a reason (cc is used in "such
>> as"
>> and in an example). There are a number of ways in HTTP to express this
>> concept and you want to be compatible with the existing definitions.
>>
>> Perhaps it just needs an additional para indicating a response bearing a
>> negative answer needs a more pessimal algorithm (e.g. either not cachable
>> or the SOA approach)?
>>
>
> I think it should. I really wish we could point to one DNS RFC that tells
> implementers on how to determine the cache TTL, but afaik that does not
> exist.
>

Could you expand on this?  NXDOMAIN has an explicit TTL, so I don't
understand why the "negative answer" case requires a different algorithm.
What are you thinking of?  Could you suggest some text?


> So, yes, either new text in this I-D or referencing a whole slew of DNS
> RFCs that say things about TTL in relation to caching.
>
>
> /Miek
>
> --
> Miek Gieben
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>

v2.23.0 | Report a Bug | By Email