What's probably most important here is that in regard to the mitigation, it's almost useless to tell apart DoS and DDoS attacks these days. No real world denial-of-service attack happens from a single fixed IP source anymore.
The only obvious exception is when an attacker generates a specially crafted packet to exploit a vulnerability with DoS potential (e.g. a
null pointer dereference somewhere in a packet handling code; here's an example of such vulnerability). But blocking a source IP address which runs an exploit isn't really a good way to mitigate that; patching a vulnerable system is.
In theory, it would be easier to handle a simple DoS attack than a distributed one. However, as those are too easy to mitigate, they are mostly extinct nowadays, and the tool you're asking about (Fail2Ban) isn't there to help against extinct attacks, it's written with real world application in mind.
Taking this into account, blocking an IP address (either with Fail2Ban or manually) only makes sense if two conditions are met at the same time:
- The DDoS attack which is ongoing affects only the performance of the server itself (or anything behind it, like a database server behind a Web application), but not the network transport in front of it;
- It can be verified somehow that all the source IP addresses involved in attack are not spoofed. E.g. a DDoS attack targets a handshake-based network service (where you can negotiate some secret towards a client and verify that the client has actually received the secret), and passes the basic handshake successfully. I can come up with another example, but the description above pretty much sums up the most frequent scenario.
Regarding a typical HTTPS server, you can use IP range blocking against, for example, TCP connection flood, SSL/TLS handshake flood, POST flood, Slowloris, and so on (it's rather hard to classify Layer 7 attacks beyond simple floods), which all in most cases satisfy both requirements.
Note that though, say, a sufficiently large POST flood could in fact affect the network transport in front of your server, IP blocking can still help you with that, because it prevents underlying TCP connections from being established, and a malicious bot won't be able to subsequently send a large POST body towards your server. This effectively limits the remaining malicious incoming traffic to a low rate SYN flood which is in most cases easy to handle.
Moreover, the main effect which an HTTP-based flood will cause on your network transport is due to outbound traffic generated by your server in response (which in today's HTTP may be about 11-12 times more than the inbound one), and blocking the IP sources of an HTTP flood eliminates this as well due to the reasons outlined above.
At the same time IP blocking is mostly useless against attacks like ICMP flood, SYN flood, UDP flood, and others which do not satisfy at least the requirement #2; and against amplification attacks which are, under most conditions, so powerful in terms of inbound traffic that they do not satisfy the requirement #1.
Note that the fact that a source IP address in a, say, SYN flood can't be verified doesn't necessarily mean it is spoofed. However, blocking a potentially spoofed IP address range may result in your service being unreachable for legitimate users. In fact, it may be an attacker's intent to trick you into starting to automatically (e.g. via the said Fail2Ban tool) block source IP addresses of a packet-based flood while there are only few sources present in the traffic, and then to spoof important IP address ranges, such as the IP ranges of largest ISPs in your country, or even the whole global IPv4 address range of ~4 billion addresses which, at an arbitrary flood rate of 100 Mbit per second, could all be enumerated in roughly an hour — I've actually seen that in my life a few times.