Re: [DNSOP] Should be signed

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

Return-Path: <nweaver@ICSI.Berkeley.EDU>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EF1D3A6A89 for <>; Fri, 19 Mar 2010 08:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.546
X-Spam-Status: No, score=-5.546 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 03PCqT4uDnbO for <>; Fri, 19 Mar 2010 08:40:58 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 2EE203A6A64 for <>; Fri, 19 Mar 2010 08:40:58 -0700 (PDT)
Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU []) by fruitcake.ICSI.Berkeley.EDU ( with ESMTP id o2JFfAS3029822; Fri, 19 Mar 2010 08:41:10 -0700 (PDT)
References: <2AA0F45200E147D1ADC86A4B373C3D46@localhost><><><><43FC3F50679F458A869F99D72ECD1237@localhost><20100309151726.GC5108@dul1mcmlarson-l1-2.local> <> <183BEF785A9844F186558A87848A6698@localhost> <061F30F4-E0EE-40E6-A54D-246D9E9A9D77@ICSI.Berkeley.EDU> <6D6F580F8CFB4DB5AB32566FB608088D@localhost> <57BC5F21-B1EE-4D06-BB1B-3DC8582D0D87@ICSI.Berkeley.EDU> <03CF4A3B5B374C4C858DEEB2D66C0702@localhost>
In-Reply-To: <03CF4A3B5B374C4C858DEEB2D66C0702@localhost>
Mime-Version: 1.0 (Apple Message framework v1077)
X-Priority: 3
Content-Type: text/plain; charset="us-ascii"
Message-Id: <AA116C2A-CCFC-4177-A43A-B3AA066B3C3C@ICSI.Berkeley.EDU>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Date: Fri, 19 Mar 2010 08:41:10 -0700
To: George Barwood <>
X-Mailer: Apple Mail (2.1077)
Cc:, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [DNSOP] Should be signed
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Mar 2010 15:40:59 -0000

On Mar 19, 2010, at 8:32 AM, George Barwood wrote:

>>> 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
> 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.  

And amplification attacks are overrated anyway:  DOS burns your bots, and most of your bots can't send spoofed packets anyway these days.  

So if you are going to burn your bots, do application level: its amazing how much damage SSL setups can do to your load if you don't have dedicated crypto hardware.

>> and spoofing of fragments is not likely to be happening in large responses, because large .responses will almost invariably be due to DNSSEC.
> Resolvers may set DO=1 but not validate everything ( or even anything ).
> Taking .SE as an example, by sending an open resolver that doesn't/cannot randomize ports the query [ NS SE ] ,
> if the .SE servers don't conceal the IP ID, only 1 spoof packet is needed, and poisoning is easy and certain, is it not?
> Note: the .SE example does not truncate, it's very unusual for a response to be truncated with a EDNS @ 1450.

Actually, this doesn't apply, since the reason why 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.

I really don't want to enshrine "Fragments don't work at ALL" into the infrastructure, rather I want "fragments are unreliable, so you need to detect if its YOUR side thats f-ing up and take action", thus it should be the onus on the resolver, not the authorities, to detect when this occurs and do something about it.