Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size)

Puneet Sood <> Thu, 14 June 2018 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92AB0130F67 for <>; Thu, 14 Jun 2018 13:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -18.21
X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Iv7lIYNK_ZUO for <>; Thu, 14 Jun 2018 13:00:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DAF44130F69 for <>; Thu, 14 Jun 2018 13:00:58 -0700 (PDT)
Received: by with SMTP id 200-v6so4421425vkc.0 for <>; Thu, 14 Jun 2018 13:00:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=E1SUJ2fUnd+ONLvv75CEfd87i8e3wQ+MqQsQpxGmzp0=; b=nIpL1+M26vtuNcVJSgZEMBFmIcWmqaIGAPeqZVC7nQQ+XRl18nGydsF8VQcE0zZXdI SFknO90ZdbLlhYyAVNJt+mxHZFLs3tIg3f+oPfB7OsUiDiPPcUO1qd60s4onmePVFrnr nqKgcqz8cUSpEoXdAgjZ1q/u+t+aFTKH4a69YSzAN0Yy5aCwSVrITTiGmesUipZpdivN YQdrlndsfYCdSdUQaJ8kLWWVDIKSLQbHtLIzxq0dZZW/55TbvbUWBVpLQ4ddiz4my3Tm R9P+CjOlZUIaTshbbwdPhM9feB5xvuqocOHT+kS+XxWTyhPVtQKdgD03u4KtNcD/naym Ozuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=E1SUJ2fUnd+ONLvv75CEfd87i8e3wQ+MqQsQpxGmzp0=; b=HABKVDFsiQspU/0NWooqX7YLRF0b1Hs2wJTa6z+QcVbZec+5283MP27SZ8XsgVMFwA zSmnHVRi4nGAy3K/Fs0i0pcuWzX9In0crgrcvHJA8VCzX3usLb3qDOMEypakAkNsxEBp qUzsag3QZ+8Beu5SC0H0zgyPMnHGogrYpwaFp9nYlJWJhqEqq/eIjLrsExspYdWwmGup JmqvPDSrNnMIBKmtRLXyJBT6v713DoEWArMpx/qgPbjh5SfeSTuSIK0JDp3zM9q+TNLA Gvo3SgD+d2+rG0+0eepczKJaaoJgFRJMZxZWtkrZCKGFGvsYhe+02i5tNq27i4weYFAh xASg==
X-Gm-Message-State: APt69E06vspNR/ljJAB9mJPVU13ooVBajWN5k1AlcpCmzwT+s9qhRQWE jpnoTDG4BhWU86Mnn+2i1mH2v7LB7JdHeD9jWJJB16I3/64=
X-Google-Smtp-Source: ADUXVKL928ZUTky6gG4WkjMak+gXPlfF/sFu7IiP3WSOVBlTNduIfju92X1Xxu/dCWvghV16hmlMoWSMNXMqKoacaZM=
X-Received: by 2002:a1f:3697:: with SMTP id d145-v6mr2473390vka.79.1529006456024; Thu, 14 Jun 2018 13:00:56 -0700 (PDT)
MIME-Version: 1.0
From: Puneet Sood <>
Date: Thu, 14 Jun 2018 16:00:43 -0400
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: 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: Thu, 14 Jun 2018 20:01:10 -0000

New to the list, quoting the relevant message manually

Dave Lawrence wrote:
> I believe that makes not imposing a 64k limit on DNS fall within the
> bounds of the charter.  In fact, I could make a case that it goes
> right to the first paragraph:
>   This working group will standardize encodings for DNS queries and
>   responses that are suitable for use in HTTPS. This will enable the
>   domain name system to function over certain paths where existing DNS
>   methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094]) experience
>   problems.
> ... in addressing cases where existing methods experience problems.
> I'm not going to get too hung up on rules-lawyering that argument
> though, it's a sideshow.
> Per our out-of-band conversation, I will later this week (new $dayjob
> intrudes) be offering text for the proposal I made in another message
> about using two mandatory-to-implement media types right out of the
> gate, differing only in that one has a Content-Length limit.
> Implementers can then choose to make it plainly explicit that they
> are sticking to legacy TCP limits.

Having two distinct media types (one with the limit, one without) will
allow a doh server to determine if a larger response is safe to send
and respond accordingly. So I am in favor of your proposal to define
two media types. The RFC should not mandate length limits for media
types other than the existing wire format media type. That should be
entirely up to the specification of the new media types. Barring a
clear indication in the client request, a doh server should
conservatively limit responses to 64K for the existing wire format
media type.

Reading draft 10 section 6.1, I do not see any text addressing
interaction of the message size with the cache behavior in a recursive
resolver.  This is mostly theoretical right now because the transports
(UDP, TCP) between recursive and authoritative servers are constrained
by the 64K limit. However when recursive resolvers start receiving >
64K responses, this will need to be addressed. Couple of points:
1. Will a caching resolver be expected to cache very large responses?
An implementation may decide to put an upper limit on the size of a
message it will cache.
2. Will a caching resolver need to cache different answers
corresponding to the 64K limit and the "unlimited" case?