pi-hole:development ← pi-hole:update/dnsmasq
opened 01:19PM - 07 Nov 22 UTC
**By submitting this pull request, I confirm the following:**
- [X] I have re…ad and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md).
- [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist.
- [X] I have considered, and confirmed that this submission will be valuable to others.
- [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
- [X] I give this submission freely, and claim no ownership to its content.
**How familiar are you with the codebase?:**
## 10
---
Updates the embedded `dnsmasq` to the next tagged version of `dnsmasq`. Highlights compared to the most recent version of `dnsmasq` (v2.87) released in FTL v5.18:
**New options/features**
- **Allow domain names as well is IP addresses in `server` options** - this will be especially helpful in situations where upstream destinations are primarily reachable by hostname (think of DHCP networks and `docker compose`, etc.) (***Pi-hole patch***)
- `use-stale-cache` - when set, **if a DNS name exists in the cache, but its time-to-live has expired, `dnsmasq` will return the data anyway** and attempts itself to refresh the data with an upstream query after returning the stale data.
Advantages:
- This can improve speed as we can always reply immediately to known queries, even when cached content has expired, instead of having to wait for upstream replies to arrive.
Disadvantages:
- In certain edge-cases, these out-of-data replies can lead to (intermittent) incorrect behavior on websites.
- There is no way to inform a downstream client that an answer we provided before was wrong. The client may cache wrong data for a long time until it re-sends a query to get the updated information.
- It comes at the expense of sometimes returning out-of-date replies and less efficient cache utilization, since old data cannot be flushed when its TTL expires. The cache becomes strictly least-recently-used.
- New `fast-dns-retry` option - **gives dnsmasq the ability to originate retries for upstream DNS queries itself**, rather than relying on the downstream client. This is most useful when doing DNSSEC over unreliable upstream network. Retries are generated when no reply was received for 1 second. Retries are repeated with exponential backoff until we give up after 10 seconds. Both values are configurable with millisecond accuracy.
Advantages:
- Queries without replies to will be retried earlier resulting in significantly reduced reply times on flaky upstream connections. Note that this does only apply to the connection between the Pi-hole and the upstream destination. It does not mean any improvement on unreliable connections between your Pi-hole and clients (like over a weak WiFi signal or an unreliable VPN connection).
Drawbacks:
- It comes with hard-to-quantify extra costs in memory usage and network bandwidth.
- It will only be useful if your Internet connectivity is *really* bad. You should try out any other possible remedy before relying on this one.
- New `port-limit=<#ports>` option - by default, when sending a query via random ports to multiple upstream servers or retrying a query dnsmasq will use a single random port for all the tries/retries.
Advantages:
- This option allows a larger number of ports to be used, which can increase robustness in certain network configurations.
Disadvantages:
- Note that increasing this to more than two or three can have security and resource implications and should only be done with understanding of those (the requesting port is part of the "secret").
- New `no-round-robin` option - suppresses round-robin ordering of DNS records and ensures answers are always served in the same order.
- Enhance `hostsdir` to remove outdated entries on changes. Before, this required a full `dnsmasq` restart (***Pi-hole patch***)
- Improve `hostsdir` logging to log the HOSTS file used for generating a local reply (***Pi-hole patch***)
**Bugfixes**
- Fix bug in `dynamic-host` when interface has `/16` address (***Pi-hole patch***)
- Fix in DHCPv4 `rapid-commit` - If a host had an old lease for a different address, the rapid-commit appeared to work, but the old lease was not removed and the new lease was not recorded, so the client and server had conflicting state, leading to problems later.