[dns-resolver-tf] DNS Resolver Recommendations

Hank,

On 01/05/2024 15.27, Hank Nussbacher wrote:
> 
> Under the section discussing Ingress Filtering you failed to discuss the 
> issue of fragment filtering.
> 
> A very common and powerful DDoS attack is UDP fragment attack:
> 
> https://ddos-guard.net/en/terms/ddos-attack-types/udp-fragmentation-flood
> 
> The common thing many ISPs as well as enterprises do to mitigate the 
> attack is to block all fragments which on most servers has almost no 
> effect.  But on DNS and VPN servers, blocking fragments is fatal and 
> therefore a warning needs to be put into the doc that UDP fragments 
> should *never* be blocked to DNS servers - even when under fragment 
> attack.  See:
> 
> https://puck.nether.net/pipermail/cisco-nsp/2023-December/108992.html
> 
> for further details.

Thanks for this!

As mentioned in the thread there, using fragmentation avoidance should 
limit the need for fragments, which means blocking them should be 
basically okay. Fragmentation in DNS and how to avoid is is discussed in 
some detail in this IETF draft, which is referenced in the DNS Resovler 
Recommendations document:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/

Clients of resolvers will basically never send any large packets; 
although it is theoretically possible to build a valid query larger than 
1232 bytes, in practice this is never seen. So no fragmented packets 
will arrive from there.

Responses from authority servers should respect the EDNS0 buffer size 
and not fragment, although I suppose it is possible for some networks to 
have a smaller MTU than 1280 and want to fragment replies. In practice 
this should never happen either.

So I think the right answer is to tune your DNS to avoid fragments, and 
then you can block them at will. 😄

IMHO, fragments in general are a badly designed and terribly insecure 
feature of IPv4 which was made worse when dragged into IPv6 and then 
made worse by removing the ability to fragment in the network itself. 
Blocking them seems like a good idea!

Cheers,

--
Shane

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x3732979CF967B306.asc
Type: application/pgp-keys
Size: 11519 bytes
Desc: OpenPGP public key
URL: </ripe/mail/archives/dns-resolver-tf/attachments/20240501/c448ecbe/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/dns-resolver-tf/attachments/20240501/c448ecbe/attachment-0001.sig>