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

Patrick McManus <> Wed, 06 June 2018 09:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5467A130ED0 for <>; Wed, 6 Jun 2018 02:50:19 -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 EucYxYXW6Jxb for <>; Wed, 6 Jun 2018 02:50:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2DB9A130EDB for <>; Wed, 6 Jun 2018 02:50:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id B109D3A055 for <>; Wed, 6 Jun 2018 05:50:15 -0400 (EDT)
Received: by with SMTP id t22-v6so4842669oih.6 for <>; Wed, 06 Jun 2018 02:50:15 -0700 (PDT)
X-Gm-Message-State: APt69E1ldTxW5KfVY/U7wQW9R9MaAF28x4vpKf4a+VjWkyQAGMWOKp+S Ix4JRrNAMCNl9fBPP+UMwjlvVgYf+719fJUxTJQ=
X-Google-Smtp-Source: ADUXVKKkYQ5r7cJpD5RsaYsYf8DWA62le0eJm4OIvKKPXa/0UmXTYKZDbm4dqW6zEzr1PNQFZY6jxnCRsBFxPiDUe3E=
X-Received: by 2002:aca:acb:: with SMTP id k72-v6mr1174566oiy.132.1528278615406; Wed, 06 Jun 2018 02:50:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 02:50:13 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Patrick McManus <>
Date: Wed, 6 Jun 2018 11:50:13 +0200
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Andrew Sullivan <>
Cc: DoH WG <>
Content-Type: multipart/alternative; boundary="000000000000fd3d7b056df617ac"
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 09:50:20 -0000

On Wed, Jun 6, 2018 at 8:23 AM, Andrew Sullivan <>;

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