[DNSOP] DNS without Fragmentation (UDP and DF bit set)

fujiwara@jprs.co.jp Sun, 04 November 2018 16:36 UTC

Return-Path: <fujiwara@jprs.co.jp>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C894612D4EA for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 08:36:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YwdndBV3O-Qm for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 08:36:12 -0800 (PST)
Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (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 9AACA1292F1 for <dnsop@ietf.org>; Sun, 4 Nov 2018 08:36:11 -0800 (PST)
Received: from off-sendsmg01.osa.jprs.co.jp (off-sendsmg01.osa.jprs.co.jp []) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id wA4Ga9L7013655 for <dnsop@ietf.org>; Mon, 5 Nov 2018 01:36:09 +0900
Received: from off-sendsmg01.osa.jprs.co.jp (localhost []) by postfix.imss71 (Postfix) with ESMTP id A86041800B6 for <dnsop@ietf.org>; Mon, 5 Nov 2018 01:36:07 +0900 (JST)
Received: from localhost (off-cpu05.osa.jprs.co.jp []) by off-sendsmg01.osa.jprs.co.jp (Postfix) with ESMTP id 9137D1800B2 for <dnsop@ietf.org>; Mon, 5 Nov 2018 01:36:07 +0900 (JST)
Date: Mon, 05 Nov 2018 01:36:07 +0900
Message-Id: <20181105.013607.854519297338098286.fujiwara@jprs.co.jp>
To: dnsop@ietf.org
From: fujiwara@jprs.co.jp
X-Mailer: Mew version 6.6 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--4.198-5.0-31-10
X-imss-scan-details: No--4.198-5.0-31-10
X-TMASE-MatchedRID: RowX92bJu8RCXIGdsOwlUh5+URxv1WlBcmEcOlx1H4QtWyi3YZaESQSI qbVzaI9GKhBzgHs2P84tR209PVFBNUhz7X71rimzDB+ErBr0bAP2acON9Q+rntISDeMx1p60G2Y FBPfYvn2UFote6E2bhLaC7xW06AoXu01WPagMcjkX2N9OpwN26B5wkWJVFHWCQUXtBnfmVnckRf lDeL4JIKQvo4OL7+X5xBynaHya4R8M8jMXjBF+sDl/1fD/GopdyJ1gFgOMhOnrpxhAaj4pfqRJi L+iL2tOC24oEZ6SpSmcfuxsiY4QFMhZqIrS1vRBck/fYFY2PVe3bVjLhOwUKT+UQljhVFpfxTmD +LH2yUaxqL8a0O4g0sBC1lNuSdWBmyRGiZLRfjInCrHmiZ6FwMUPIui1kiiMomDSBjYsAHCEY0E n2JI6nUctviHZbfNAlExlQIQeRG0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8YJ0LT2iR_e50pYNvM5W4mshM6E>
Subject: [DNSOP] DNS without Fragmentation (UDP and DF bit set)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 04 Nov 2018 16:36:14 -0000

It is time to drop fragmentation (and pMTU discovery) in DNS.

A research paper showed that there are many authoritative servers that
accept any ICMP destination unreachable / fragmentation needed and DF
set (pMTU response packets) and reduce packet size up to 296 bytes.
Path MTU discovery is controlled by any attacker.  Then the authors
sent trigger queries and did second fragmentation attack to CA's

  Domain Validation++ For MitM-Resilient PKI
  Markus Brandt, Tianxiang Dai, Amit Klein, Haya Shulman, Michael Waidner
  Fraunhofer SIT, TU Darmstadt

Proposed solution is not good. DNS with TCP transport is enough, I think.

I would like to propose to drop fragmentation and pMTU discovery in DNS.

Authoritative servers should drop ICMP fragmentation needed,
set static EDNS buffsize 1220, and set DF bit in responses.

On resolver machines, I would like to drop fragmented response packets.
We can write IP filter that drop fragmented packet to resolvers,
but it is not beautiful.

Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>