Re: [Doh] [Ext] DNS Camel thoughts: TC and message size

Patrick McManus <> Sun, 10 June 2018 23:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37970130F28 for <>; Sun, 10 Jun 2018 16:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MpCuECD4f-CA for <>; Sun, 10 Jun 2018 16:10:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 580C8130EDE for <>; Sun, 10 Jun 2018 16:10:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 271F83A019 for <>; Sun, 10 Jun 2018 19:10:20 -0400 (EDT)
Received: by with SMTP id 188-v6so2952871oid.12 for <>; Sun, 10 Jun 2018 16:10:20 -0700 (PDT)
X-Gm-Message-State: APt69E02JWPASgK9b+t/3hHStobuH1JHN53h1mLxCTtszv2uCSO2e2WN MFBbzHixG+v34XzzFfgnAP3AhALi0La7TMmHm+0=
X-Google-Smtp-Source: ADUXVKJ3eatE/OiqnqQsgFKWdZTLxoWfdO4ILPXNlmGnwQm+hV9oKTvCWmBS4IwGV2TyE8ibOr8WbuF91rmoJLWikhw=
X-Received: by 2002:aca:a88b:: with SMTP id r133-v6mr7784355oie.213.1528672219842; Sun, 10 Jun 2018 16:10:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Sun, 10 Jun 2018 16:10:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Patrick McManus <>
Date: Sun, 10 Jun 2018 19:10:18 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Andrew Sullivan <>
Cc: DoH WG <>
Content-Type: multipart/alternative; boundary="000000000000a45137056e51bc6f"
Archived-At: <>
Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Jun 2018 23:10:24 -0000

On Sun, Jun 10, 2018 at 12:16 PM, Andrew Sullivan <>;

> I think if we can come up with the right words, then it'll make things
> less risky, but I also worry about the deployment story unless we can
> figure out what to do if something in the pipeline can't take the
> "jumbo" messages.
After having re-read the related threads, I think it might be helpful to
talk about how content negotiation works in the http pipeline.

let's assume we have 2 message formats - wireformat-64 and traditional
wireformat. And that we define traditional wireformat to be limited to 16
bits (its not clear to me whether or not that is really true in practice,
but let's say we determine that it is.).

I believe the concern is "traditional -> doh -> doh" where the doh -> doh
link could use wireformat-64 and then the initial traditional client cannot
consume wireformat-64 but ends up with it anyhow. Is that right?

That shouldn't happen. The middle node realizes it is a gateway for a
traditional client and only indicates to the final server that it knows how
to speak traditional wireformat for the request it is making. The fact that
it is over DoH does not add new media types to the request by default, the
middle node needs to (essentially) opt-in to that via the Accept: request
header and it wouldn't do that here.

making the middle node a doh http cache makes things a little more
complicated for the cache, but not in a way that is unusual for an http
cache. If in that scenario it had previously done a transaction for a doh
client that supported wireformat-64 it could certainly cache that (modulo
all the other caching rules) and then when the traditional client came
along, the cache just needs to recognize that the variant it has in cache
is not one that the client recognizes. At which point it makes a new
upstream request for traditional-wireformat-only. This works ok even if
there is a non-doh aware http cache in the chain as long as the server
marks the response "Vary: Accept" (which it should do if it creates
different variants based on the accept header.. that's not something DoH
needs to specify, 723x has it covered - pure http behavior).

So if traditional wireformat consumers are limited to 16 bit sizes we
definitely should document that as part of the wireformat definition. The
next question is are they, or are we just at a point where we are concerned
they might be? I'm really not sure on that one.

in either case, I don't see a reason to restrict protocol beyond the
wireformat definition.