Re: [DNSOP] Should root-servers.net be signed

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Fri, 19 March 2010 14:25 UTC

Return-Path: <nweaver@ICSI.Berkeley.EDU>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09313A685A for <dnsop@core3.amsl.com>; Fri, 19 Mar 2010 07:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.55
X-Spam-Level:
X-Spam-Status: No, score=-5.55 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQUseyyvIt4M for <dnsop@core3.amsl.com>; Fri, 19 Mar 2010 07:25:52 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id DD3FE3A6A29 for <dnsop@ietf.org>; Fri, 19 Mar 2010 07:25:49 -0700 (PDT)
Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2JEQ17o019878; Fri, 19 Mar 2010 07:26:01 -0700 (PDT)
References: <2AA0F45200E147D1ADC86A4B373C3D46@localhost><0E169711-92DC-4AEA-AA81-718F298D1645@hopcount.ca><alpine.LSU.2.00.1003081614480.1897@hermes-2.csi.cam.ac.uk><A2D7C5EE-9937-4529-A28F-23296485A8B2@hopcount.ca><43FC3F50679F458A869F99D72ECD1237@localhost><20100309151726.GC5108@dul1mcmlarson-l1-2.local> <6C56581E-D4F4-4A49-A3B4-CB7F1CF42E29@icsi.berkeley.edu> <183BEF785A9844F186558A87848A6698@localhost> <061F30F4-E0EE-40E6-A54D-246D9E9A9D77@ICSI.Berkeley.EDU> <6D6F580F8CFB4DB5AB32566FB608088D@localhost>
In-Reply-To: <6D6F580F8CFB4DB5AB32566FB608088D@localhost>
Mime-Version: 1.0 (Apple Message framework v1077)
X-Priority: 3
Content-Type: text/plain; charset="us-ascii"
Message-Id: <57BC5F21-B1EE-4D06-BB1B-3DC8582D0D87@ICSI.Berkeley.EDU>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Date: Fri, 19 Mar 2010 07:26:01 -0700
To: George Barwood <george.barwood@blueyonder.co.uk>
X-Mailer: Apple Mail (2.1077)
Cc: dnsop@ietf.org, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [DNSOP] Should root-servers.net be signed
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Fri, 19 Mar 2010 14:25:53 -0000

On Mar 19, 2010, at 6:09 AM, George Barwood wrote:

> 
> ----- Original Message ----- 
> From: "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU>
> To: "George Barwood" <george.barwood@blueyonder.co.uk>
> Cc: "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU>; "Matt Larson" <mlarson@verisign.com>; <dnsop@ietf.org>
> Sent: Friday, March 19, 2010 12:33 PM
> Subject: Re: [DNSOP] Should root-servers.net be signed
> 
>> On Mar 19, 2010, at 12:21 AM, George Barwood wrote:
>>> I suggest the default value in BIND for max-udp-size should be 1450.
>>> This appears to be best practice.
>>> Since few zones are currently signed, it's not too late to make this change.
>>> Later on it may be more difficult.
> 
> 
>> Actually, I'd say this ONLY for the root and TLDs.  For the rest, the onus should be on the resolver to discover that it can't handle fragmentation and >adjust the MTU appropriately.
> 
> There are advantages besides messages being lost.
> It also prevents spoofing of fragments, and limits amplification attacks.

It doesn't limit amplification attacks by much if at all, and spoofing of fragments is not likely to be happening in large responses, because large responses will almost invariably be due to DNSSEC.

Since 90% CAN handle fragments, those 90% SHOULD be able to use fragments, especially since the broken 10% will see higher lookup latency, NOT full failure to resolve.