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

Mark Nottingham <> Fri, 08 June 2018 12:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8E67130EB0 for <>; Fri, 8 Jun 2018 05:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=a+qpJzqH; dkim=pass (2048-bit key) header.b=FfjgXaQu
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qc0NDZoFKxkn for <>; Fri, 8 Jun 2018 05:46:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F28D124C04 for <>; Fri, 8 Jun 2018 05:46:39 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id E9BBA20F60; Fri, 8 Jun 2018 08:46:38 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Fri, 08 Jun 2018 08:46:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=J+PkM1G2Ub8Ix38nW46NZOUrsJHHy u/ao9YGXXFvjpA=; b=a+qpJzqHBPSK1fJd3+GZmXCq/6wII4igwSEAtikzhHZRW YnhAI3c31HZbOkrouSZGWMLgo/ibaG373f9qtOq9W5oJoHDXHvY96qvt6UNsIp85 vpilZeD4b8WCuPbVwA01ODVhv7Vk6R+F/bEMBmpIjCKhM57gRk275/r5EkoPuHyA GviX/HhoGWe+jVfc74d5qdZ5qsmmTvPE1gtwhfwzj1BmaWXtrcWAQ8AAYCKwP1PH MqpdqF3k4fdCJNsOPwMwiAR3UBX2ZzhsD/G9yHrC7EUIujgZfElyt28tNDQrIAce l5DKmcgHjeTro6hD36jJy9WZvjhJeeW+Pc5Q12brA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=J+PkM1 G2Ub8Ix38nW46NZOUrsJHHyu/ao9YGXXFvjpA=; b=FfjgXaQuQ/nxGhQUdXz3FZ oKK4fm/Jd/Goe/bNdFTJyYOJc2yAbUyvcfRluhyMLqFIYBEuRqQLe3rOZ4qRdwxS ORw/TfPIWJI7vycUgbbwDoCX+O+ewpcCF/4O1vTvMnTX2cEyqDXb44Vy+3l7mqAx OP+tZVCmcVjsHFbyDyDYHM546uBuhoWTPB1xSr+kWul/PzvZRmmMc+ilX4XM2BlD amLDqAS0n7pMO1GdLd9u1qL/TSP8zgiUXG8Z2snhVNp7x1NSbi22wpw0QadFGJmV DtZkg/7h1tosFEtx2Xy6+6M7Bbs4FWMLb+WP3nySa7xBSa/1Ies6htdU0WHLutbA ==
X-ME-Proxy: <xmx:rnoaW_axJhhG6xfXNRe1hvlooXROvQPAToDBW2i3wMQf10pojviVqQ>
X-ME-Proxy: <xmx:rnoaW3MG5Xl2NkhOKfSNIZYSRai3GYt_h19ylN1j-snhRGPJlvjQKQ>
X-ME-Proxy: <xmx:rnoaW4RZvOkrk_hTafYsHQqgUzikslXuQN7XnQop-bdX4yhrq8hDVQ>
X-ME-Proxy: <xmx:rnoaW8Qq26wKfdz49AMu2R7mMIe1x0uTkJLgZ5pnvB_baeuz5GXeGw>
X-ME-Proxy: <xmx:rnoaW5DuaUV67pGS4_A2kv0r-ysqJYCs_m1KhDKGnxegcRTuYc1qwA>
X-ME-Proxy: <xmx:rnoaWxDaxbvWUNmvRl0VyUWYS-p6pQWXcEF_fBgHotQT3KARwRUX5A>
X-ME-Sender: <xms:rnoaWw3ZUgx0Hn4RNLgTSRD8WZAdvJg4DaF_gngM0dqAQQsJemgxOA>
Received: from [] (unknown []) by (Postfix) with ESMTPA id AF7AA10268; Fri, 8 Jun 2018 08:46:37 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Fri, 8 Jun 2018 14:46:35 +0200
Cc: bert hubert <>, DoH WG <>, Dave Lawrence <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Patrick McManus <>
X-Mailer: Apple Mail (2.3445.8.2)
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: Fri, 08 Jun 2018 12:46:49 -0000

AFAICT there are two of situations that might be relevant here:

1. A DOH request is gatewayed to "normal" DNS
2. A DOH response is gatewayed to "normal" DNS

Could the folks who are concerned about this explain if there are any others (with detail)?

For #1, the DOH gateway should know the limitations of the protocol it's gatewaying (in this case, DNS over UDP), and can generate a 413 or 414 status code as appropriate (see <>). That's the correct way to express "that request is too big" in HTTP. Some non-normative advice in the spec about DOH servers generating appropriate status codes and clients understanding them might help here.

For #2, it seems like people are claiming that a client library is going to implement DOH but *not* update itself to take arbitrary-sized responses. Is anyone actually saying that's their implementation strategy, or is this just "what if"-ism?

If it's necessary to support those clients, it would be easy enough to define a preference <> that allows them to say "please give me small* responses", and require DOH servers to honour that preference.


* Where "small" is defined as "able to be expressed in less than N bytes in the UDP wire format" or similar. Limiting *all* DOH messages using Content-Length is not what we want to do here.

> On 8 Jun 2018, at 11:34 am, Patrick McManus <>; wrote:
> I'm not on board with limiting a 2018 protocol to 64KB variants because some parser of some some format might have a bug. At the very least we need to be more specific so we can assess the scope of the interoperability issue. DoH opens up new things - that's a good property. Not everything will be gatewayed back and forth into wireformat, and the wireformat isn't inherently limited to 16bit either. AXFR is an especially interesting case for DoH because it supports multiplexing and priority between streams, it might actually be the best way to carry it.
> as for other formats they are coming. Paul has an informational draft that has been sent to the IESG: and I've heard rumors of others in the works - even from the dns community :)
> If there is a known problem with gatewaying between formats, that's worth some non normative text to mention - but the notion that 64KB is enough for anybody is one I want to push back on. Even for that I would appreciate a citation of where the problem lays - there isn't agreement that wireformat actually has such a limit (though its existing transports do and maybe that's what should be noted), and no particular implementation choices, much less widely deployed and hard to upgrade implementations, have been cited (again - I'm not saying they don't exist.).
> -Patrick
> On Thu, Jun 7, 2018 at 11:58 PM, bert hubert <>; wrote:
> On Thu, Jun 07, 2018 at 11:39:16PM +0200, Patrick McManus wrote:
> > > "Sort of".  Wire format itself does not have the limitation.  Its use
> > > on certain transports does.  This distinction needs to keep being
> > > made.
> > tale has convinced me of this point.
> In the interest of reaching consensus, can we park this discussion until
> another message type is invented and standardised that is not a DNS message
> in "wire format"?
> Whenever we make life harder on the whole DNS implementation community, we
> had better have a very good reason for that. 
> To put it bluntly, a significant part of the DNS implementation community
> (ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit is
> here to stay for now, so I don't see a viable consensus for expanding DNS -
> especially given the lack of concrete usecases.
> Finally, I note that the DOH charter contains the following:
> "The working group will coordinate with the DNSOP and INTAREA working groups
> for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics,
> respectvely.
> In particular, DNSOP will be consulted for guidance on the operational
> impacts that result from traditional host behaviors (i.e., stub-resolver to
> recursive-resolver interaction) being replaced with the specified mechanism..
> Specification of how DNS-formatted data may be used for use cases beyond
> normal DNS queries is out of scope for the working group."
> It may be good to point out that 'normal DNS queries' have never involved
> getting >64KB responses. We might also have to consult DNSOP about changing
> DNS semantics, an activity they aren't stimulated to explore. 
> Finally, I do really understand how much fun it would be to liberate DNS
> from its pedestrian 64KB shackles. It is an arbitrary limitation, and
> perhaps one day we'd love to put gigantic post-quantum cryptographical keys
> in DNS. But given the amount of developer cycles in DNS, please also
> understand my (our) reticence in overhauling this ancient protocol. 
>         Bert
> _______________________________________________
> Doh mailing list

Mark Nottingham