[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.
- [DNSOP] avoiding fragmented DNS-over-UDP Tony Finch
- Re: [DNSOP] avoiding fragmented DNS-over-UDP Mukund Sivaraman
- Re: [DNSOP] avoiding fragmented DNS-over-UDP Tony Finch
- Re: [DNSOP] avoiding fragmented DNS-over-UDP Tony Finch
- Re: [DNSOP] avoiding fragmented DNS-over-UDP Davey Song
- Re: [DNSOP] avoiding fragmented DNS-over-UDP ietf-dnsops
- Re: [DNSOP] avoiding fragmented DNS-over-UDP Tony Finch