Re: [Doh] meta qtypes

Miek Gieben <> Mon, 19 March 2018 10:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 605A9126CBF for <>; Mon, 19 Mar 2018 03:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.735
X-Spam-Status: No, score=0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gNNFGm8dQ_SG for <>; Mon, 19 Mar 2018 03:27:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CAA07126DC2 for <>; Mon, 19 Mar 2018 03:26:59 -0700 (PDT)
Received: by with SMTP id f125so6168465wme.4 for <>; Mon, 19 Mar 2018 03:26:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Q4xzypKhF3Jjeo/p5k315P4vPKeQEOwV0seuPO6BiRo=; b=Oe6iPTLCCla/YJJ5Vskh8NEboptrWZL74bDMzXNKNjem0dw4d5CzkMYEbC5tfU1a1m UMOO8bqFD8SQ4hdCxAq9ajzNA7GrUPExomuH7TOwaT+3she5ye5gK9PS6e1XhTE9Ytls AcXeef5mLDcY+hUHl8cA1HDyeCvuT05iuZM1Y4cWyG1zfBefn5TZtHs+LcXjD8m7xxLP b2IN6ZKhK0Fds9qXBEvqTeDDaK2OTNavr42GLFD7l+B4KbptYnLbq8TX24EplP1hljYC nk0FwGkKlyRaMBn3MuVN5mb2EEtMPa02ztdFRjrUTC/jy1s6Ej4+bmF7GVAid1KlwHLR UUZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Q4xzypKhF3Jjeo/p5k315P4vPKeQEOwV0seuPO6BiRo=; b=pRZSbIX/SUPzpI6PhdcyoSnpUKWwqrRiD5wfocA+AjklLxPWenSxDFH6Miz+PkORsA l+TM6BXcc6EvukVm+duJI9GdSrsyEPBxYE38PUW093dTL5/5vhGwNd6k/24AFvBgWlev hCM0Yzofm/VJaN7Q4HPTXdKB/PjlTlb6iunXVNLRrmcT1BGd1ym8uDrYOE4aGC77tZBx 27HXPvS7G3v6/aZ/y/9mLIwzBDGEhSzj+y4j7JyP07FOp/RwNWEnyNijeds/Njo5aLTO yXdS2JVpVjvYDro/vKDKNffzAXvGQ9WnwFEfT4FCyOCPxlbHby/hemn1wUr8zZWMa1mx UkkQ==
X-Gm-Message-State: AElRT7H+3vdu3yLLu0DCsTxl+lZCXEaQuC+dOTWRttfgjcsk2mCzZAJL pG1tPHgExPVacNFthSc/GGI3sQ==
X-Google-Smtp-Source: AG47ELvIAFJc24HSCAzib4i0HtHdFD4MNYivl881nK9uJ9baNzLCLAH+Nnj7XEhCDMmOHNIr/9SonA==
X-Received: by with SMTP id c83mr7892705wmd.37.1521455218041; Mon, 19 Mar 2018 03:26:58 -0700 (PDT)
Received: from ([2a01:7e00::f03c:91ff:fe79:234c]) by with ESMTPSA id y42sm12618214wry.97.2018. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 19 Mar 2018 03:26:57 -0700 (PDT)
Date: Mon, 19 Mar 2018 10:26:56 +0000
From: Miek Gieben <>
To: Patrick McManus <>
Cc: Stephane Bortzmeyer <>, DoH WG <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Vim/Mutt/Linux
Archived-At: <>
Subject: Re: [Doh] meta qtypes
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Mar 2018 10:27:01 -0000

[ Quoting <> 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.

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 Gieben