Re: [Doh] meta qtypes

Patrick McManus <> Mon, 19 March 2018 10:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7EEAA12DA08 for <>; Mon, 19 Mar 2018 03:13:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.102
X-Spam-Level: **
X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z7pdrY3v4AuW for <>; Mon, 19 Mar 2018 03:13:09 -0700 (PDT)
Received: from ( [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by (Postfix) with ESMTP id 95005126DEE for <>; Mon, 19 Mar 2018 03:13:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 0A9A43A052 for <>; Mon, 19 Mar 2018 06:13:09 -0400 (EDT)
Received: by with SMTP id q5-v6so6093479oth.12 for <>; Mon, 19 Mar 2018 03:13:09 -0700 (PDT)
X-Gm-Message-State: AElRT7ErGZ/OdwUAUM1tdiozc3+y2LqKDG4vgn0uHVKcAvlU7TzPFxXJ ZUwx+4KTpIYnvsQfNqc7scHj0u9VZ59ugGsJe/E=
X-Google-Smtp-Source: AG47ELulleiHwK0M8WZUmKgCQXNi6gSNCB2yyobcdcoEdFpamkpaT94SosFuUVEv2IZDb0/DhlNv16drqFJohAJ0oAk=
X-Received: by 2002:a9d:17e3:: with SMTP id j90-v6mr7738491otj.2.1521454388727; Mon, 19 Mar 2018 03:13:08 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Mar 2018 03:13:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Patrick McManus <>
Date: Mon, 19 Mar 2018 10:13:08 +0000
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Miek Gieben <>
Cc: Stephane Bortzmeyer <>, Patrick McManus <>, DoH WG <>
Content-Type: multipart/alternative; boundary="00000000000061d66c0567c1342c"
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:13:14 -0000

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)?

On Mon, Mar 19, 2018 at 9:49 AM, Miek Gieben <> wrote:

> [ Quoting <> in "Re: [Doh] meta qtypes..." ]
>> I think this draft should say "MUST not cache these responses".
>> I have a less radical proposal:
>> "DoH servers SHOULD return a Cache-Control header (RFC 7234, section
>> 5.2.2). They MAY send "Cache-control: no-cache" in all cases [if
>> they're lazy]. For positive
>> answers (ANCOUNT>0), if the DoH server returns "Cache-control:
>> max-age=N", the maximum age MUST be the TTL of the answer seen by the
>> Doh server. For negative answers (NXDOMAIN), if the DoH server returns
>> "Cache-control:
>> max-age=N", the maximum age MUST be calculated from the SOA record of
>> the zone (RFC 2308, section 3) [note it allows a server to return
>> "Cache-control: no-cache" only for NXDOMAIN]"
> I agree that this works (but still leaves out RRSIGs).
> The (major) downside is that a DoH server doesn't just ship bytes anymore;
> it need to fully inspect the payload to make an informed cache TTL decision.
> Note: I'm fine with either - nocache or something along the lines Stephane
> proposes.
> /Miek
> --
> Miek Gieben