Update embedded dnsmasq to v2.88test3 #1469

DL6ER · 2022-11-07T13:19:33Z

By submitting this pull request, I confirm the following:

I have read and understood the contributors guide.
I have checked that another pull request for this purpose does not exist.
I have considered, and confirmed that this submission will be valuable to others.
I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
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.

src/dnsmasq/forward.c

yubiuser · 2022-11-07T21:57:42Z

Maybe we can use no-round-robin to workaround

https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg16179.html

In the way to disable permutation at all. (Not sure if we want answers to be reordered)

DL6ER · 2022-11-08T19:20:43Z

Tests are currently failing as our only external dependency in the testing suite (sigok.verteiltesysteme.net) is broken:

dig sigok.verteiltesysteme.net

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> sigok.verteiltesysteme.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44236
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sigok.verteiltesysteme.net.	IN	A

;; Query time: 200 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Nov 08 20:07:52 CET 2022
;; MSG SIZE  rcvd: 55

Should be:

But is:

PromoFaux · 2022-11-09T18:17:53Z

I don't understand what the test is doing - but is it something we could move to a pihole.net controlled domain, so that we're not relying on an external lookup to pass the tests..?

DL6ER · 2022-11-09T18:27:18Z

It verifies DNSSEC validation. The two domains we used to use have been carefully set up to once pass and once fail DNSSEC. This is what we are testing for. I'll try to replace them by other domains. DNSSEC is about this only thing we cannot set up locally in the test containers and our only external dependency.

DL6ER · 2022-11-09T18:43:59Z

Tests will be restored once #1470 is merged into development and this branch is then rebased on the latter.

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. This option allows a larger number of ports to be used, which can increase robustness in certain network configurations. 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. Signed-off-by: DL6ER <dl6er@dl6er.de>

This 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. It comes with some cost in memory usage and network bandwidth. Signed-off-by: DL6ER <dl6er@dl6er.de>