[dns-operations] DNS Attack over UDP fragmentation

Ondřej Surý ondrej.sury at nic.cz
Wed Sep 4 14:04:13 UTC 2013


On 4. 9. 2013, at 15:47, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:

> On Wed, Sep 04, 2013 at 03:08:55PM +0200,
> Ondřej Surý <ondrej.sury at nic.cz> wrote 
> a message of 81 lines which said:
> 
>> So what are the views of other people on this list?
> 
> [Total noob just going back from holidays and therefore even less
> competent as usual.]
> 
> Isn't is a good idea to limit the maximum size of the response, like
> .com/.net (and may be other TLD: examples welcome) do? This will make
> the attack more difficult.

That could work, but what EDNS0 buffer size to pick?  And how to push this to end users?

> With IPv6, limiting to 1280 bytes completely prevent fragmentation.

That would definitely help with IPv6.

> With IPv4, limiting to the minimum size of IPv4 datagrams is really
> too harsh and the attacker may trigger fragmentation by sending
> spoofed ICMP "packet too big".

JFTR the minimum for IPv4 is 48 bytes.  We are currently looking at our DNS data for fragments (and their sizes), so it might give us some hints.

> A possible solution is simply to deploy IPv6 faster :-)


Yeah :), but what should we do in the eternity meanwhile?

We will be adding the options to set maximum EDNS0 buffer size and to set DF on UDP to Knot DNS, but since we cannot pick one correct value it will be probably turned off by default.

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:ondrej.sury at nic.cz    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130904/c6666c08/attachment.sig>


More information about the dns-operations mailing list