Re: [DNSOP] Should be signed

Douglas Otis <> Fri, 19 March 2010 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC31D3A683D for <>; Fri, 19 Mar 2010 14:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.576
X-Spam-Status: No, score=-4.576 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HwrAnmzepW6c for <>; Fri, 19 Mar 2010 14:32:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A693F3A6783 for <>; Fri, 19 Mar 2010 14:32:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 04A21A94858 for <>; Fri, 19 Mar 2010 21:32:58 +0000 (UTC)
Message-ID: <>
Date: Fri, 19 Mar 2010 14:32:57 -0700
From: Douglas Otis <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
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>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 21:32:49 -0000

On 3/19/10 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.
>>   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.
> I think it's best to have a conservative value as the default setting, and that is 1450 bytes.
1450 is not a conservative value anymore.

See RFC2460 Section 5.
(dealing with IPv6/1280 ->  IPv4/<1280)
  In response to an IPv6 packet that is sent to an IPv4 destination
  (i.e., a packet that undergoes translation from IPv6 to IPv4), the
  originating IPv6 node may receive an ICMP Packet Too Big message
  reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
  is not required to reduce the size of subsequent packets to less than
  1280, but must include a Fragment header in those packets so that the
  IPv6-to-IPv4 translating router can obtain a suitable Identification
  value to use in resulting IPv4 fragments.  Note that this means the
  payload may have to be reduced to 1232 octets (1280 minus 40 for the
  IPv6 header and 8 for the Fragment header), and smaller still if
  additional extension headers are used.
This should guide the recommended DNS message size fallback of say
1232 or less, depending upon other extension headers being used.

Bill Manning suggested 1220B, see: