Ignore Path MTU Discovery on UDP server socket

[rgacogne]

Short description

It might help prevent Path MTU poisoning attacks.
Untested, don't merge it yet!

Checklist

I have:

• read the CONTRIBUTING.md document
• compiled this code
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[rgacogne]

We should check that IP_MTUDISC_DONT is defined. Note that unbound sets the don't fragment flag on systems that don't have IP_MTUDISC_DONT: https://github.com/NLnetLabs/unbound/blob/master/services/listen_dnsport.c#L571

[rgacogne]

Bind is doing the same: https://gitlab.isc.org/isc-projects/bind9/blob/master/lib/isc/unix/socket.c#L2396

[rgacogne]

Added the missing check for IP_MTUDISC_DONT. I'm still undecided about setting DF=1.

[rgacogne]

As a datapoint, Knot decided against doing this: https://gitlab.labs.nic.cz/knot/knot-dns/issues/467

[mnordhoff]

Knot decided against it in 2016 when fragmentation attacks weren't in vogue, though.

[rgacogne]

Rebased to fix a conflict.

[rgacogne]

As pointed out by @hdais NSD did bite the bullet as well recently: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4235

[rgacogne]

Move this PR into the rec-4.2.0-beta1 milestone. Now is the time to speak if you are against this change ;-)

[jedisct1]

Hi Remi,

That change seems to be what made DNSCrypt servers running dnsdist unreliable after they upgraded to version 1.4.0.

As you know since you implemented the protocol, DNSCrypt requires questions sent over UDP to be as large as responses, using padding.

Blocking fragmented questions prevents large responses from being received.

Ignoring fragments in responses from authoritative servers is fine, but even with unencrypted queries, I'm not sure that there is any value in dropping fragments on the server socket. A fragment attack would just allow the question to be modified, but a stub resolver would ignore a response for a different query.

[rgacogne]

Hi Frank,

Thanks a lot for reporting this! I have to admit I had completely forgotten that propriety of DNSCrypt when I submitted this change, sorry about that!
I'll re-evaluate whether it makes sense to keep setting setSocketIgnorePMTU() on our incoming sockets. At the very least I'll disable it for DNSCrypt binds.

[jedisct1]

Thank you so much Remi!

/cc @welwood08