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

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Fri, 19 March 2010 16:20 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 8E7B23A684C for <dnsop@core3.amsl.com>; Fri, 19 Mar 2010 09:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.543
X-Spam-Level:
X-Spam-Status: No, score=-5.543 tagged_above=-999 required=5 tests=[AWL=-0.074, 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 rxedWonlg4aA for <dnsop@core3.amsl.com>; Fri, 19 Mar 2010 09:20:40 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 0AA0F3A67F0 for <dnsop@ietf.org>; Fri, 19 Mar 2010 09:20:40 -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 o2JGKnSq007077; Fri, 19 Mar 2010 09:20:49 -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> <57BC5F21-B1EE-4D06-BB1B-3DC8582D0D87@ICSI.Berkeley.EDU> <03CF4A3B5B374C4C858DEEB2D66C0702@localhost> <AA116C2A-CCFC-4177-A43A-B3AA066B3C3C@ICSI.Berkeley.EDU> <7F872C0CAA544F9480BF49438AAFA3BF@localhost>
In-Reply-To: <7F872C0CAA544F9480BF49438AAFA3BF@localhost>
Mime-Version: 1.0 (Apple Message framework v1077)
X-Priority: 3
Content-Type: text/plain; charset="us-ascii"
Message-Id: <68584293-648A-4F4E-8731-785E8F4D38B7@ICSI.Berkeley.EDU>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Date: Fri, 19 Mar 2010 09:20:49 -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 16:20:46 -0000

On Mar 19, 2010, at 9:10 AM, George Barwood wrote:

> 
>>> It cuts the response from 4K to 1.5K, and I think fragmentation that contributes
>>> to these attacks being damaging.
> 
>> All I need to do is find a set of open resolvers which don't have such limits to do juuust fine.  
> 
> Eventually the open resolvers will get updated, and thus these attacks will be effectively limited.
> I don't think anyone has conclusively proved they are not a risk.

HAHAHA.  Not bloodly likely IMO: a lot of the "open resolvers" are broken end-user NATS and similar.  Those will only be updated sometime around when hell freezes over.
> 
>> Actually, this doesn't apply, since the reason why ns.se is 2700B is all the RRSIGs in the additional section, which are after the A and AAAA records.  So spoofing this part of the datagrams is pointless anyway, since that only has meaning if DNSSEC validation IS performed.
> 
> Hold on - can't the spoofer can put whatever he likes in the fragment!? He is not limited to RRSIGs.

Hmm, you're right, IF the A records are accepted in the additional section, true, A records could be added to the RRSET for some of the names.  But frankly speaking, thats "ADDITIONAL", and shouldn't really be accepted at all, and if the resolver DOES cache it, I'd personally call it a bug.