Re: [Doh] [Ext] a tad confused on response sizes

Massimiliano Fantuzzi <> Wed, 06 June 2018 11:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 363A3130EEA for <>; Wed, 6 Jun 2018 04:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZnS3pUkU-adt for <>; Wed, 6 Jun 2018 04:57:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFEC0130E39 for <>; Wed, 6 Jun 2018 04:57:58 -0700 (PDT)
Received: by with SMTP id y72-v6so8671628lfd.2 for <>; Wed, 06 Jun 2018 04:57:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MHe8zdDBP2SOpT5ppQRj0WJFsmzn62oqyFyksb72k6M=; b=KeadDgB7bGDaZGUnyOf2ms8AixpbChevxri4we7mNkBykyC3qzGJ3Gb3Ab5tnMn4FK XWy9d0470VFRWTw8wTLU1+FydMgj7s37av4YNnv/jNCZUZyigw8vitAhZPhCiZr9yN87 QEya0NlH9u5UWU+oGR8EGBfWcSsSf0q24uUiLaciEZjfyRjYA9Lan5UxH2dbJxG8yACB VGkHpKtNgDgXvLkdnKyABP9mOrK5Q4faE1F/8l7/I91vNxj5AYqa1eQedAGdi7gWy9Nx LqPeU4deD4VX9mDkgNoGyg1ie2DDQGannX2xjx6GCq8VfnuNk3h2dIx5J9fzmaKu9kjF Mmgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MHe8zdDBP2SOpT5ppQRj0WJFsmzn62oqyFyksb72k6M=; b=j6NMOPD3Ao6+ajV81KmTCxIjpOGEqEKX6rdJfq1Wp6exsH5DZsezb7Ewo5AJ6Cb1JZ LDgZwC3kdUZoWrhnoRhjKSXF2gVdIdU1AL/uAaEWQNJP6wO0Ab7QnBgyCu1mp6QAevWp B6k0DQoRo5JTZUZJk78uTDdEAMAjE4V4NXRulP3Vz3RtmYGmMBjtAN+FgA+5vkMJIB/X kV1q7PwR0RRccuVQd8sEdg+FiT6AFON075WfLuqt6EHHEquy1I0zENP35SYrR8HIuoZf Rh/plENfFQhMp1gUe91pfvKrQ3WKfBH/dNOdXdfFTFI8OMfg0hINKLkALvtvB+SaB6rm HWkQ==
X-Gm-Message-State: APt69E3w5SPlaTNNLwbPLlUUNeRWTh3fOLrPFqdwpJsgBqOY0k3nNSvu PTfFmjAIUbSaeQ7pZ//U4gqw1/7eYAaRPnLOg1o=
X-Google-Smtp-Source: ADUXVKL84Ri/aUpzjsK/s7XP8FT4P+RAlQOxPtrc+jL/OaWEKZGAVN+DMUtrWkL2ZATQhutds5TsTIJkaPISeFlnDb8=
X-Received: by 2002:a2e:7a0f:: with SMTP id v15-v6mr2001294ljc.68.1528286276883; Wed, 06 Jun 2018 04:57:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Massimiliano Fantuzzi <>
Date: Wed, 6 Jun 2018 13:57:43 +0200
Message-ID: <>
To: Patrick McManus <>
Cc: Andrew Sullivan <>,
Content-Type: multipart/alternative; boundary="000000000000a61981056df7e021"
Archived-At: <>
Subject: Re: [Doh] [Ext] a tad confused on response sizes
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: Wed, 06 Jun 2018 11:58:04 -0000

Dear memebers of the WG and/or DoH list

Similar questions arose in 1995 and 1996 IETF meetings,

TC can have multiple origins.

I guess we:

- cannot fix what is broken (configurations)
- cannot establish a new concept of "best effort" answer, not better than
the one clarified in the 2181 section 9
- can live with broken answers, broken servers...

We shall though, agree on mechanisms to:
- clear, ignore or warn about TC bit and implications.. Let's reason on how
to switch protocol, and why TC was set.
- clarify the need to process (proxy) the ADDITIONAL section ? (the TC bit
could be set as effect of that section being too big, not the RR queried
- make clearer who has to go and try TCP query, as we need to support both.
Is it the DoH client or DoH server ? how is this preference expressed from
a client perspective (do we still have two content types, i forgot) ?
- can we say that TC + minimal + TCP is a FAIL ? (or create an universal
URI) ?

I want to mention also "minimal-responses" option in BIND.
Overhead/overkill from a DoH point of view (certificates, sessions,
perceived speed), but that might be a benefit for a DNS server... nowhere
in RFC is written than a client needs more than what it queried for
(recursion) !!

Another important nuance we should agree on... HTTP is stateless, are we
discussing about building a stateful API server ? One that works with
"states" before giving out answer? A server able to judge the quality of a
given set????? because i do not see how a single API call can drive
multiple "interpretation" of the same message (received upstream).
Otherwise as usual, the intelligence must reside on client (aka retry,
fallback or fail).

DNS clients do already "suffer" from the same issues, as also mentioned,
many firewalls in between...

I think the "retry intelligence" should reside on client, as a DoH server
is by definition a proxy (eventually offering options to
minimise/alter/complete responses if you want).

On Wed, Jun 6, 2018, 11:50 Patrick McManus <> wrote:

> On Wed, Jun 6, 2018 at 8:23 AM, Andrew Sullivan <>
> wrote:
>> TC-bit-containing DOH message is almost certainly garbage that needs
>> to be resolved via a different path, and it's therefore pretty hard
>> for me to see why this isn't just an error condition.
> It is my understanding that the TC bearing response is the best one that
> the DOH Server could generate. The assumption is that this is better than
> returning no response at all (i.e. just an error) because the client might
> be able to make use of it. If it has no value, then it should be an error
> (which probably means must not send and if received must be treated as
> error). But my understanding is it may have value to some clients. Set me
> straight as necessary.
> It is what it is - if you need more information and have another path
> available then try and resolve it that way assuming it meets whatever
> security requirements you have - but beware that some clients won't have
> another path.. for example javascript clients have only access to http, and
> the servers they may connect to are constrained via same origin policy.
> In practice DoH isn't constrained by size - so shifting to another
> transport with the same recursive isn't likely to improve things; I would
> think using a different recursive would be more likely to bear fruit.
> There's obviously no way to say that definitely.
> _______________________________________________
> Doh mailing list