Adding upstream version 1.46.3.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

2 files changed, 88 insertions, 0 deletions

diff --git a/src/health/guides/unbound/unbound_request_list_dropped.md b/src/health/guides/unbound/unbound_request_list_dropped.md
new file mode 100644
index 000000000..deed815ee
--- /dev/null
+++ b/src/health/guides/unbound/unbound_request_list_dropped.md
@@ -0,0 +1,38 @@
+### Understand the alert
+
+The `unbound_request_list_dropped` alert indicates that the Unbound DNS resolver is dropping new incoming requests because its request queue is full. This situation may be caused by a high volume of DNS queries, possibly from a Denial of Service (DoS) attack or poor server optimization.
+
+### Troubleshoot the alert
+
+1. **Check the request queue length**: Inspect the Unbound configuration file (usually located at `/etc/unbound/unbound.conf`) and check the `num-queries-per-thread` setting. If the value is too low for your system, you may encounter issues with dropped requests.
+
+2. **Increase the queue length**: If necessary, increase the `num-queries-per-thread` value in the Unbound configuration file. For example, if the current value is 1024, you can try setting it to a higher value, such as 2048 or 4096. Save the changes and restart the Unbound service:
+
+   ```
+   sudo systemctl restart unbound
+   ```
+
+3. **Monitor dropped requests**: Use the `unbound-control` command to monitor the number of dropped requests in real-time:
+
+   ```
+   sudo unbound-control stats_noreset | grep num.requestlist.dropped
+   ```
+
+   If you see the dropped requests decreasing, your changes to the `num-queries-per-thread` value may have resolved the issue.
+
+4. **Inspect server logs**: Check the Unbound log file (usually located at `/var/log/unbound.log`) for any suspicious activity or error messages that may indicate the cause of the increased DNS queries.
+
+5. **Check for potential DoS attacks**: Use tools like `iftop`, `nload`, or `nethogs` to monitor network traffic and identify any potential DoS attacks or unusual traffic patterns.
+
+   If you believe your server is experiencing a DoS attack:
+
+   - Investigate the source IP addresses of the high-volume traffic
+   - Block malicious traffic using firewall tools like `iptables` or `ufw`
+   - Contact your hosting provider, ISP, or network administrator for assistance
+
+6. **Optimize Unbound**: Review the [official Unbound documentation](https://nlnetlabs.nl/documentation/unbound/) and tune the settings in the Unbound configuration file to ensure optimal performance for your specific environment.
+
+### Useful resources
+
+1. [Unbound Official Documentation](https://nlnetlabs.nl/documentation/unbound/)
+2. [How to set up a DNS Resolver with Unbound](https://calomel.org/unbound_dns.html)
diff --git a/src/health/guides/unbound/unbound_request_list_overwritten.md b/src/health/guides/unbound/unbound_request_list_overwritten.md
new file mode 100644
index 000000000..fd74a1632
--- /dev/null
+++ b/src/health/guides/unbound/unbound_request_list_overwritten.md
@@ -0,0 +1,50 @@
+### Understand the alert
+
+The `unbound_request_list_overwritten` alert is triggered when Unbound, a popular DNS resolver, overwrites old queued requests because its request queue is full. This alert can indicate a Denial of Service (DoS) attack or network saturation.
+
+### What does request list overwritten mean?
+
+When the request queue is full, Unbound starts overwriting the oldest requests in the queue with newer incoming requests. This is done to handle increasing load, but it may also lead to dropped or lost queries.
+
+### Troubleshoot the alert
+
+- Check the Unbound log file for any unusual events or error messages. The default log file location is `/var/log/unbound.log`. You may find more information about the cause of the request queue overload, such as a high number of incoming queries or sudden spikes in traffic.
+
+- Monitor Unbound's real-time statistics using the `unbound-control` command, which allows you to view various metrics related to the performance of the Unbound server:
+
+  ```
+  sudo unbound-control stats_noreset
+  ```
+
+  Look for the `num.query.list` and `num.query.list.overwritten` values to determine how many queries are in the request queue and how many of them are being overwritten.
+
+- Analyze the incoming DNS queries to check for suspicious patterns, such as high query rates from specific clients or repeated queries for the same domain. You can use tools like `tcpdump` to capture and inspect DNS traffic:
+
+  ```
+  sudo tcpdump -i any -nn -s0 -w dns_traffic.pcap 'port 53'
+  ```
+
+  You can then analyze the captured data using packet analyzers like Wireshark or tshark.
+
+- Increase the request queue length by adjusting the `num-queries-per-thread` value in the Unbound configuration file (`/etc/unbound/unbound.conf`), which determines the maximum number of queries that can be queued per thread before overwriting begins. Increasing this value may help to accommodate higher incoming query loads:
+
+  ```
+  server:
+      num-queries-per-thread: 4096
+  ```
+
+  Remember to restart the Unbound service for the changes to take effect (`sudo systemctl restart unbound`).
+
+- Consider implementing rate limiting to prevent a single client from overloading the server. Unbound supports rate limiting using the `ratelimit` configuration option:
+
+  ```
+  server:
+      ratelimit: 1000
+  ```
+
+  This example sets a limit of 1000 queries per second, but you should tune it according to your environment.
+
+### Useful resources
+
+1. [Unbound Configuration Guide](https://nlnetlabs.nl/documentation/unbound/unbound.conf/)
+2. [Unbound Rate Limiting](https://calomel.org/unbound_dns.html#ratelimit)