Re: [DNSOP] Call for Adoption: draft-fujiwara-dnsop-avoid-fragmentation

Mukund Sivaraman <muks@mukund.org> Wed, 15 April 2020 00:41 UTC

Return-Path: <muks@mukund.org>
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 3FD6E3A138F; Tue, 14 Apr 2020 17:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mukund.org
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 QDOaigKEDtdG; Tue, 14 Apr 2020 17:41:30 -0700 (PDT)
Received: from jupiter.mukund.org (jupiter.mukund.org [IPv6:2a01:4f8:231:3f69::9e]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B7B3A1392; Tue, 14 Apr 2020 17:41:29 -0700 (PDT)
Received: from localhost (unknown [27.5.222.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by jupiter.mukund.org (Postfix) with ESMTPSA id 74855E204AC; Wed, 15 Apr 2020 00:41:27 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mukund.org; s=mail; t=1586911288; bh=02OQEqHdqWlVm8bNjaWuP0VZ4OG92jNxfOTj0jG4Fq8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hgTdqLSeF44KJPvVz0epVc0v/sq0a8CNALgk6KC9LSYrr7XOdEFls+/iTfjZ7vCBD B97uWp6PkNkUaBjvAE/xBG20HhnO62ANQQM1CEO9b8oVSGwqmz+wM1af+7oaZr1Jhb /b2AiHuT2Zp8MBxsHg1KiEnPIvpdPfnxKVoC6h18=
Date: Wed, 15 Apr 2020 06:11:24 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Tim Wicinski <tjw.ietf@gmail.com>
Cc: dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
Message-ID: <20200415004124.GA478442@jurassic.vpn.mukund.org>
References: <CADyWQ+GECV6aaeKxp-ObgsK0Ax3KN_5hAaYgmXQhssJ1A00Ttw@mail.gmail.com> <20200414215855.GA464850@jurassic.vpn.mukund.org> <20200414234146.GA471121@jurassic.vpn.mukund.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200414234146.GA471121@jurassic.vpn.mukund.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6EuuKwKbA7E6xRGv3DfCEMMo2Co>
Subject: Re: [DNSOP] Call for Adoption: draft-fujiwara-dnsop-avoid-fragmentation
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: Wed, 15 Apr 2020 00:41:31 -0000

On Wed, Apr 15, 2020 at 05:11:46AM +0530, Mukund Sivaraman wrote:
> One more question:
> 
> > 3.  Proposal to avoid IP fragmentation in DNS
> 
> >    o  UDP requestors and responders SHOULD send DNS responses with
> >       IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] options, which will yield
> >       either a silent timeout, or a network (ICMP) error, if the path
> >       MTU is exceeded.  Upon a timeout, UDP requestors may retry using
> >       TCP or UDP, per local policy.
> 
> If the IP_DONTFRAG/IP_DF/IP_PMTUDISC_DO option is available and can be
> used to set the DF flag on DNS over UDP over IPv4 PDUs, why are any of
> the following maximum-size mitigations (the next 3 items after the above
> quoted item) necessary?

Possibly this is client-driven mitigation, right? A client which does
not know if the server will set DF=1 can still avoid fragmentation of
the reply by using a smaller EDNS UDP payload size.

		Mukund