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

Martin Thomson <> Fri, 08 June 2018 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67931130EA4 for <>; Fri, 8 Jun 2018 05:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hlonwC_rdH1i for <>; Fri, 8 Jun 2018 05:57:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F97C124C04 for <>; Fri, 8 Jun 2018 05:57:21 -0700 (PDT)
Received: by with SMTP id 101-v6so15554409oth.4 for <>; Fri, 08 Jun 2018 05:57:21 -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=hakalB80Y/kaqxvbE5kVRPAk9Uk7vwioQrzf/F3Pufw=; b=HYHp8JIgpTZMMerAA6cy6+yRq5Qy6mj+vKzZztYuhuLhMQ/nFzqI4qh7T50FnlVS6i 00yq+xoyUOQ03YybVVDCqgWjlRYyhWh2AfPrrZIIZXGFW5VYd5cl+Wcu8SjlPtHjbSZD ygjs36MRJhgXmBZ4v8m9MyrK/FJyp02jrLvMnbgZaEPv/2wUjVPtTryvBfTXNsbYPKAk na1XjDfcs8UlKhUloByyUb7UOFIv1RPO20u7zbxOrIO/53krPtrvYO/ADNZx4QThPZI1 OYhafgYIwa6zwiaJL0mu8xxnr5+3OwLGiuGxTMAVaXiONlvpqYpFBiBJCREuPXFD9l+q QR2Q==
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=hakalB80Y/kaqxvbE5kVRPAk9Uk7vwioQrzf/F3Pufw=; b=s18RSbaUv9+/wakbw6Aeos2+BWsKSBPDb0tf+9At/gNo3tRvj48lL78ErPOQVM2m/q kkqcDK8tPvcvK72BOPDcILvooRqgxWsP5WaOlK++Uqa5NNcaQUoyi9z83qnBdEJT2UAM cWwBPhMp9HI2/KdV09drsIxHgqz72RvytuFhNg6zGF1iQsDTr8mMMS9LSOd5SjYrROVe G8v9usHuMrohHtLhG+VPsMYaxZLlMi15IPEMOc/Vyc3s5G8exU7zpNGdFHv2PmnRAYUh Ikl27j0EwbK6DoBH5qEJMajCNj16VtFSelH6r9o2OKNdeQl/nPdLY1QWDjyJCgBVuS65 w+gg==
X-Gm-Message-State: APt69E2Mi9XYUE7RFN5jp0L1l2aNhH3nIaMkDvD4E+Pw7I9vRj8z+Myt z8wzJEY2ySpohWok3JLz4A56L3R7dRTS2dLnme+QUNom
X-Google-Smtp-Source: ADUXVKJgoTHQX1oIaXkzdvU1Ykcr6nFYKiudFBEVoOGv/uUnSR8KJNaMrmoD/oaRsfJN918G7sHKSLxIPT0DbRsoEEw=
X-Received: by 2002:a9d:4044:: with SMTP id o4-v6mr3328121oti.283.1528462640718; Fri, 08 Jun 2018 05:57:20 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <20180608101102.GA12334@jurassic>
In-Reply-To: <20180608101102.GA12334@jurassic>
From: Martin Thomson <>
Date: Fri, 8 Jun 2018 14:57:09 +0200
Message-ID: <>
Cc: patrick mcmanus <>, DoH WG <>,,
Content-Type: text/plain; charset="UTF-8"
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:57:24 -0000

Have we agreed that limiting DOH (which might use multiple encodings)
is nonsensical?  And that this is just a discussion about the

On Fri, Jun 8, 2018 at 12:11 PM Mukund Sivaraman <>; wrote:
> for a long time implementations have assumed
> 64kB for message formats and these are implicit assumptions

OK, if this is correct, let's examine the consequences.

If we limit the size, that's an artificial limit that will be hard to
remove.  But it is easy to understand.  And future versions of
ourselves will be smarter and more experienced than current us, so
it's really tempting to have them deal with any problems.  YAGNI and
all that.

On the other hand, if we fail to limit the size, it's a little harder
to reason about, but I haven't seen anything significant on the thread
to suggest that this would be a genuine problem.

Implementations that aren't prepared to receive very large messages
will break.  But we have to consider that all DOH implementations will
be new even if they use an existing parser.  Those implementations can
therefore check that they don't break.

And I can't see any way for a message larger than 64k to end up in DNS
over UDP or TCP.  Both contain length fields that just don't permit

So the consequences seem limited to those implementations that copy
queries and answers from DOH (copying *to* DOH would obviously be safe
if the limit were higher).  This isn't materially different from
moving from TCP to UDP in that sense.  Requests that go from a DOH leg
to a non-DOH leg and won't fit can be immediately turned around with
an error code; responses that go from a DOH leg to a non-DOH leg and
won't fit can be truncated, or turned into an error response.

So I'm not seeing any need to change text here.  I can see how putting
some fluff in about how it might be sensible to allow for limitations
of decoders and so forth might seem attractive, but it doesn't appear
to be *necessary*.  Of course, I wouldn't object if someone wanted to


[1] Absent an implementation of RFC 2675, which I believe is not
relevant on the internet and probably needs to be made Historic.