[DNSOP] avoiding fragmented DNS-over-UDP

Tony Finch <dot@dotat.at> Wed, 21 March 2018 16:10 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C801126FB3 for <dnsop@ietfa.amsl.com>; Wed, 21 Mar 2018 09:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLOomPBgBLVH for <dnsop@ietfa.amsl.com>; Wed, 21 Mar 2018 09:10:17 -0700 (PDT)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BFA8126D45 for <dnsop@ietf.org>; Wed, 21 Mar 2018 09:10:17 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:39599) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eygJb-000kgr-eN (Exim 4.89_2) for dnsop@ietf.org (return-path <dot@dotat.at>); Wed, 21 Mar 2018 16:10:15 +0000
Date: Wed, 21 Mar 2018 16:10:15 +0000
From: Tony Finch <dot@dotat.at>
To: dnsop@ietf.org
Message-ID: <alpine.DEB.2.11.1803211607160.16357@grey.csi.cam.ac.uk>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xnJjuOFRE4IiT7uqEFyqhYKKT7c>
Subject: [DNSOP] avoiding fragmented DNS-over-UDP
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2018 16:10:19 -0000

In the intarea meeting, there was some discussion of
"IP fragmentation considered fragile"
https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile

That draft correctly calls out the DNS as particularly problematic wrt
fragmentation, so I think it might be worth writing a dnsop draft that
explains how to reduce the amount that the DNS causes fragmented packets
and relies on them working.

I think this draft should provide advice to implementers about how
their code should behave in its default configuration. I think a lot
of the advice should be basically writing down things that we (or some
of us) already know.

I don't know if we need different flavours of advice for stub -> recursive
and for recursive -> authoritative.

Here are some sketchy notes on what this might say...

* client side

    * implement PMTUD by probing with diferent EDNS buffer sizes

    * needs to be per-server

    * start with small buffer size and work upwards

    * probe sizes (not necessarily in this order)

        * 512
        * 1280 - tunnel headers
        * 1280
        * 1500 - tunnel headers
        * 1500
        * 4096

* server side

    * avoid putting too many records in a response

        * when the client has a small buffer size, try to avoid truncating

        * when the client has a large buffer size, still return a small
          sub-MTU response, e.g. with unilateral minimized responses,

    * does it make sense to provide partial glue instead of truncating,
      to avoid fallback to TCP?

    * does it make sense for a server to try to work out if the client is
      doing PMTUD, or is that too much complexity for too little benefit?

    * recommend minimal-any :-)

* security considerations

    * reflection / amplification ddos is bad, mmmkay?

    * risks of excess TC leading to overload

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire, Forties, Cromarty, Forth: Westerly or southwesterly, veering
northwesterly for a time, 5 to 7, decreasing 4 or 5 later. Slight or moderate
in Cromarty and Forth, otherwise moderate or rough. Occasional rain. Good,
occasionally poor.