Re: [DNSOP] Should root-servers.net be signed
- Original Message - From: Nicholas Weaver nwea...@icsi.berkeley.edu To: Matt Larson mlar...@verisign.com Cc: dnsop@ietf.org; Nicholas Weaver nwea...@icsi.berkeley.edu Sent: Tuesday, March 09, 2010 3:31 PM Subject: Re: [DNSOP] Should root-servers.net be signed On Mar 9, 2010, at 7:17 AM, Matt Larson wrote: On Mon, 08 Mar 2010, George Barwood wrote: It's interesting to note that currently dig any . @a.root-servers.net +dnssec truncates, leading to TCP fallback but dig any . @l.root-servers.net +dnssec does not truncate ( response size is 1906 bytes ). a.root-servers.net's six anycast instances currently all run BIND 9 configured with max-udp-size 1472 to avoid sending responses larger than the Ethernet MTU. This was a conscious conservative choice and the infrastructure is capable of handling the resulting increased TCP load. I'd set it at 1450 personally, because you do have some encapulation over ethernets (eg, PPPoE, IPSEC) which occur, so if the goal is almost guarenteed no fragments, you need to leave a little additional headroom. +1 But given the current observed difficulty that resolvers have with fragments, this is, IMO, a very good decision. +1 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
- Original Message - From: Nicholas Weaver nwea...@icsi.berkeley.edu To: George Barwood george.barw...@blueyonder.co.uk Cc: Nicholas Weaver nwea...@icsi.berkeley.edu; Matt Larson mlar...@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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mar 19, 2010, at 6:09 AM, George Barwood wrote: - Original Message - From: Nicholas Weaver nwea...@icsi.berkeley.edu To: George Barwood george.barw...@blueyonder.co.uk Cc: Nicholas Weaver nwea...@icsi.berkeley.edu; Matt Larson mlar...@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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
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. 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 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. George ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mar 19, 2010, at 12:20 PM, Nicholas Weaver wrote: 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. Stuff gets updated when its brokenness becomes obvious to the person who owns it. So revealing its brokenness is a mitzvah. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
On Mar 19, 2010, at 12:01 PM, George Barwood wrote: Anyway, do we yet agree that 1450 is the best default for max-udp-size, and that higher values are dangerous?\ No: I agree it is the proper default for the TLD authorities and roots, but for everything else, the higher value should be what the resolver requests. Enshrining tho shalt never fragment into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which regularly exercises fragmentation as critical to the infrastructure and we wouldn't have this problem where 10% of the resolvers are broken WRT fragmentation. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
From: Nicholas Weaver nwea...@icsi.berkeley.edu Date: Fri, 19 Mar 2010 12:48:24 -0700 ... Enshrining tho shalt never fragment into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which regularly exercises fragmentation as critical to the infrastructure and we wouldn't have this problem where 10% of the resolvers are broken WRT fragmentation. +1. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
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: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02996.html -Doug ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
