[Dnsmasq-discuss] Monthly Posting
Hi, "How To Ask Questions The Smart Way" has immediately after the introduction an advice on before you ask. http://www.catb.org/esr/faqs/smart-questions.html#before Following that advice is still no guarantee for a (good) response. So when you are still stuck with something that you think it is dnsmasq related, you have to make more effort. Greatest challenge is most likely being persistent in solving the problem. ( Not being persistent in demanding an answer. ) The dnsmasq manual page is feature complete. And known as "hard to read" for those who are new to it. But still do read it and try to understand it. Reading it again is known being effective for getting better understanding. Find a copy of it in source code of dnsmasq and read it by `man man/dnsmasq.8`, or when installed by `man dnsmasq` or at https://dnsmasq.org/docs/dnsmasq-man.html Pattern seen on the mailing list is unawareness of network-server-client-model. Expressing such problems is indeed hard, but also the road to a solution. Know that you are the main stake holder of the problem that you are facing. The highest reward for finding a solution goes to you. Keep the eco system that you are consulting healthy by sharing also your success stories. Avoid "DNS doesn't work", make it "My DNS client gets odd replies from dnsmasq", "My DNS requests don't get forwarded" or another non-generic issue. Use real DNS client tools like `dig` or `host` (instead of `ping`). Set the configuration --log-queries. That will allow you to see if the queries are getting to dnsmasq, and it will give you a full dump of the DNS cache (including DHCP derived names) if you send the dnsmasq process SIGUSR1. Both of these will help in diagnosing the problem. For non-biased views is networksniffing recommented. When `tcpdump` or `wireshark` is used for such examinations, provide the mailinglist with an URL to `.pcap`-file. Karma bonus points for providing an URL that can be `wget`. So prevent that your community members get exposed to websites that scream advertisements or the need for JavaScript. Text version output of network sniffs don't show up well after being put in an email. Please take the pain of uploading an .pcap file instead of multipling pain by sending malformed netsniffer output. By the way, did you notice in the manual of dnsmasq the options `--dumpfile` and `--dumpmask`? In case you got stuck in finding a solution, describe also the original problem you wanted to solve. ( See also https://xyproblem.info/ which starts with: The XY problem is asking about your attempted solution rather than your actual problem. This leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help. ) Dnsmasq is a mature project, meaning not often a release. However we constantly want to improve. Yes, patches welcome. Patches are not always reviewed within three days. Retransmit of your review request after four days is not too pushy. So feel OK to make more effort on the patch you already put effort in. Aim for common interest. If you find it here, fine. If you cannot find it here, you might found a clue for looking elsewhere on "common interest". Do know there are real humans behind the email addresses. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Update DNS records after pruning DHCP leases
Hi everyone,
Does anyone have something to say about this patch? I sent it for the first
time about 6 months ago but the discussion quickly died down and it seems
to have been forgotten about since then.
To elaborate a bit about the rationale behind it the issue was discovered
by analyzing core dumps from live customer installations which I for
obvious confidentiality/privacy reasons cannot share. The core dumps showed
a use after free of crecp->name.namep in cache_scan_free for records
derived from DHCP. The core dumps also showed that the value of dns_dirty
was 1 which is indicative of the fact that lease_update_dns needs to be run
but has not been run.
For the issue to reproduce with default configuration I think you need at
least two DHCP derived names which share the same domain (otherwise the
issue is masked by the is_expired logic). One of them has to expire
followed by a request for either the domain itself or something with a
coinciding hash before any DHCP requests are handled. Additionally for an
actual crash to happen the memory has to be unmapped as opposed to just
returned to the free list. In most cases rather than crashing garbage data
will be returned, something which may or may not go unnoticed. So, it is a
bit of a corner case issue but a very real one as evidenced by the core
dumps.
>From analysis of the code and especially other places where lease_prune is
used it also seems to be evident that lease_update_dns is needed
afterwards. The only place where this is not done is async_event and this
is what the patch is addressing.
In addition when use-stale-cache is enabled the issue seems to reproduce
more easily, something which has been reported by the Pi-hole community:
https://discourse.pi-hole.net/t/host-name-of-client-xxx-contains-at-least-one-invalid-character-at-position-0/69132
The patch was subsequently applied to Pi-hole with seemingly favourable
outcome:
https://github.com/pi-hole/FTL/pull/1965
Best regards,
Erik
Den tis 1 okt. 2024 11:01Erik Karlsson skrev:
> From: Erik Karlsson
>
> Not doing so can result in a use after free since the name for DHCP
> derived DNS records is represented as a pointer into the DHCP lease
> table. Update will only happen when necessary since lease_update_dns
> tests internally on dns_dirty and the force argument is zero.
>
> Signed-off-by: Erik Karlsson
> ---
> src/dnsmasq.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/dnsmasq.c b/src/dnsmasq.c
> index a9f26ae..1be3b82 100644
> --- a/src/dnsmasq.c
> +++ b/src/dnsmasq.c
> @@ -1518,6 +1518,7 @@ static void async_event(int pipe, time_t now)
> {
> lease_prune(NULL, now);
> lease_update_file(now);
> + lease_update_dns(0);
> }
> #ifdef HAVE_DHCP6
> else if (daemon->doing_ra)
> --
> 2.46.2
>
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] socket activation support (systemd)
> What even worse as top quoting? Mixing top qouting with inline qouting On Wed, Oct 02, 2024 at 01:13:03AM +0200, Petr Menšík wrote: > I am not sure systemd.socket can listen both on UDP and TCP, to pass both > sockets into dnsmasq when it starts. For a properly initialized dnsmasq it > is needed to listen on both. Most other services I have seen with socket > activation use it with TCP socket only. It is much easier with that. I have > not found systemd-resolved.socket for example on Fedora 40. > > socket activation cannot work well with bind-dynamic. If bind-dynamic style > is enough, it should be okay. But it kind of allows only --listen-address > alternative, I think. Which often might would be useful enough. > > I think what would need to be added is accepting open listening sockets from > daemon and install them instead of creating own socket. Probably would need > libsystemd linking at compile time. sd_notify support might be useful > addition too. > > But systemd socket handling has also limitations. For example it rate limits > connections over limit, which may DoS the service. That were I think > motivation for disabling sshd.socket activation in Fedora about a year ago. > Triggering the limit for some time disabled temporarily the service for > everyone, which is not ideal also for DNS. It should be carefully tested. > > Cheers, > Petr > > On 01/10/2024 17:49, kuehn.michael--- via Dnsmasq-discuss wrote: > > Hi, > > > > i found the some threads discussing this already (in 2023 and decades > > before that), including: > > - > > https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg17151.html > > > > Disclaimer: i won’t get into the philosophical stance reg. uselessness > > or “overblown”-ness of systemd, as this often is religious, tedious and > > out of scope and also i think mailing-lists are not a good format for > > those long back-and-forth takes) - but systemd becomes more and more > > ubiquitous and this is for good reasons and what ever your gripes with > > systemd are, it’s not a niche. In fact it’s the default in most > > mainstream distributions already > > (https://en.wikipedia.org/wiki/Systemd#Adoption) > > > > There was one reply from Simon that he desires to better understand > > systemd and/or socket activation, which i’m not sure is still needed but > > if it is, i think this talk is very good as a starting point: > > https://youtu.be/TyMLi8QF6sw (socket activation part starts at 18:07). > > > > In previous threads here were often some questions about use-cases. My > > personal one is #4 but i think they are all valid on their own. > > > > > > Having systemd managing the socket has multiple benefits: > > > > 1) restarts of dnsmasq.service would not loose DNS queries as the > > dnsmasq.socket is not restarted and would buffer those messages until > > the service is back up again and can process those. This means less > > frictions for users when maintenance is done by admins reg. dnsmasq > > upgrades etc. > > Okay. I never understood motivation for starting DNS caching service by > socket activation. But avoiding lost messages during update sounds like not > bad idea. Although retries should be common for client applications, so fast > restart should not cause significant regressions. > > But there need to be cases how to reopen listening sockets anyway. I expect > it just moves to systemd daemon service or something similar. But some race > condition cannot completely disappear during updates. > > > > > 2) .socket in systemd has a lot of options for administration: > > https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html > > incl. resource control, security, behavior, etc. > > > > 3) having the socket managed by systemd allows capabilities from the > > binaries dropped to open ports <1024 (DNS w/ port 53 definitely falls > > under that). So security minded admins could drop the > > CAP_NET_BIND_SERVICE from dnsmasq > This of course applies only when dnsmasq is used only for DNS and if it > should listen only on. Suggestion: Start the "socket adventure" with "only DNS". > > 4) and finally, what motivated me to bring this up here _again_: better > > support for (rootless) containerization. For example in podman: If you > > want to run dnsmasq completely rootless with a container, current > > rootless networks provided by podman loose the source IPs. See > > https://github.com/containers/podman/issues/8193#issuecomment-2386247390 > > This is a “problem" when using pi-hole (pi-hole FTL is based on > > dnsmasq), as you loose a lot of visibility about the clients on the > > network (and it breaks features that rely on a correct source-ip). Right > > now, this limitation prevents users from running pi-hole/dnsmasq in a > > rootless mode. > Right, If podman avoids privilege requirement by making proxy, then it would > need to support some proxy protocol and dnsmasq would need to understand as > well. Passing pre-created lis
