Re: [Dnsmasq-discuss] [PATCH] Fix potential memory leak
-- Original Message -- From "Brian Haley" To "Geert Stappers" ; dnsmasq-discuss@lists.thekelleys.org.uk Date 3/18/2024 6:59:21 AM Subject Re: [Dnsmasq-discuss] [PATCH] Fix potential memory leak As an attempt to express that proposed patches get human attention. I'm not sure what that means... It means Geert doesn't think Simon is running `dnsmasq` to his (Geert's) liking so Geert is doing yet another passive aggressive attack on the list. You'll notice how Geert likes to change the email address he sends from with what he thinks are witty and creative names, like his monthly rules to post reminders. Would be nice to just blanket ban anything from @stappers.nl but until then it's easier to just set a rule to send anything from that address to spam. Geert has no authority to do anything in the `dnsmasq` project and this latest game with him setting up a patch repository is just a game. Simon is the sole gateway to getting any code in, much to Geert's dismay. Best, Dan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Possible to reuse Cache over restats?
Geert, Can you keep the political holy war crap off this list? Thanks! -- Original Message -- From "Bottom Post Request via Dnsmasq-discuss" To dnsmasq-discuss@lists.thekelleys.org.uk Date 7/2/2022 12:30:25 PM Subject Re: [Dnsmasq-discuss] Possible to reuse Cache over restats? > Visit website that is NOT ours Nice, very helpful. We realize this is not an easy task; GitHub is ubiquitous. Through their effective marketing, GitHub has convinced Free and Open Source Software (FOSS) developers that GitHub is the best (and even the only) place for FOSS development. However, as a proprietary, trade-secret tool, GitHub itself is the very opposite of FOSS. By contrast, Git was designed specifically to replace a proprietary tool (BitKeeper), and to make FOSS development distributed — using FOSS tools and without a centralized site. GitHub has warped Git — creating add-on features that turn a distributed, egalitarian, and FOSS system into a centralized, proprietary site. And, all those add-on features are controlled by a single, for-profit company. By staying on GitHub, established FOSS communities bring newcomers to this proprietary platform — expanding GitHub's reach. and limiting the imaginations of the next generation of FOSS developers. See the whole text at website of one of ours: https://sfconservancy.org/GiveUpGitHub/ ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Request to have an official Dnsmasq mirror on GitHub
Geert, What the hell are you babbling about? Best, Dan -Original Message- From: Dnsmasq-discuss On Behalf Of Geert Stappers Sent: Thursday, January 21, 2021 1:24 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Request to have an official Dnsmasq mirror on GitHub On Thu, Jan 21, 2021 at 06:14:49PM +0800, Wang Shanker wrote: > > 2021年01月21日 17:46，- Neustradamus - 写道： > > > > Hello all, > > > > I wish you a Happy New Year! > > > > To have a perfect development of Dnsmasq, > > it is possible to create an official mirror on GitHub? Fairly ignorant the sell a cold website to a community that is nicely floating on the waves. It is not important how vague the definition of the dnsmasq community is, important is that we have contact. Contact about what does hold us together: dnsmasq. Handing ourselfs over to a website that doesn't give fuck about us, is like putting your own head on the chopping block. > > > > For example, there is a fork here: > > - https://github.com/guns/dnsmasq > > > > A search: > > - https://github.com/search?o=desc=dnsmasq=updated=Repositories > > > > There are several organizations which have done mirror on GitHub: > > - https://github.com/kde <- https://invent.kde.org/ > > - https://github.com/gnome <- https://gitlab.gnome.org/GNOME > > Seen the "You must come the cold website that I deem cool". No, I haven't visited the infamous website. Same as I resist tobacco commurcials. > > Thanks in advance. > > > > Regards, > > Neustradamus > > > > It seems that someone has already built one, > and the owner is willing to give the ownership. > https://github.com/dnsmasq/dnsmasq URL not visited, but claiming anyway: The "owner" understands that a succesfull project is made by people with common interests. > Cheers, > Miao Wang And yes, we, this project, should discuss what we can improve. I think I haven't told before that there is https://salsa.debian.org/debian/dnsmasq Regards Geert Stappers -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss smime.p7s Description: S/MIME cryptographic signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] How to contact Simon Kelley
Resent: Original message was encrypted without plaintext inclusion. -Original message- Riccardo, I'm Dan Schaper, one of the maintainers for Pi-hole (https://github.com/pi-hole/ftl.git). We use dnsmasq quite heavily in our project code and I am concerned that there may be potential security issues to address. We are very conscious of protecting our users. Would you please get in contact with me and the Pi-hole team? We have a standing practice to provide patches and updates to the upstream dnsmasq codebase and have a few patches for things currently outstanding. Any information that is discovered will be provided to Simon without delay. You can reach me at dan.scha...@pi-hole.net and we can find the best method of responsible disclosure. Best regards, Dan Message signed S/MIME PGP available upon request. -Original Message- From: Dnsmasq-discuss On Behalf Of Riccardo Schirone Sent: Thursday, October 1, 2020 1:00 AM To: Nudge Cc: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] How to contact Simon Kelley On 09/28, Nudge wrote: > On Mon, Sep 28, 2020 at 01:59:04PM +0200, Riccardo Schirone wrote: > > Hello, > > > > I'm trying to reach out to Simon Kelley about dnsmasq, however he is > > not answering direct emails and he has not been active on this list > > for few months now. > > > > Does anybody have a way to contact him or know anything about him? > > Could you ping him if you have other means to reach him apart from public email? > > > > Thank you, > > > The why is left out ... We need to discuss some possible security issues. Is he the only one with commit-access to the upstream git repository? Is he the only one able to do a new release for the project? Thanks, -- Riccardo Schirone Email: rschi...@redhat.com PGP-Key ID: CF96E110 smime.p7s Description: S/MIME cryptographic signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] How to contact Simon Kelley
smime.p7m Description: S/MIME encrypted message ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Mac Darwin confusion
Geert, Can you go find another hobby or somewhere else to troll? I have yet to see any kind of usefulness to your belittling users and their questions. And the cutesy changing of your name along with the witty only to you signatures are quite draining. Dan No Yes No Questions wrote on 8/3/2020 10:04 AM: > On Mon, Aug 03, 2020 at 10:44:07PM +0700, Bernd Prager wrote: >> Hi all, >> >> I got something I can't wrap my head around. I have a QNAP NAS that I >> thought would be nice for hosting a DNSMASQ service for DNS and DHCP. Setup >> went smooth and all my Linux clients behave wonderfully, except my Mac >> client: >> >> Querying a host from Linux goes perfect: >> >> -=[22:29:35][bernd@hoenir ~]=- >> dig @qnap freyja >> >> ; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> @qnap freyja >> ; (1 server found) >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24213 >> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;freyja. IN A >> >> ;; ANSWER SECTION: >> freyja. 0 IN A 192.168.1.7 >> >> ;; Query time: 0 msec >> ;; SERVER: 192.168.1.5#53(192.168.1.5) > .5 > > >> ;; WHEN: Mon Aug 03 22:29:37 +07 2020 >> ;; MSG SIZE rcvd: 51 >> >> -=[22:29:37][bernd@hoenir ~]=- >> ping -c 1 freyja >> PING freyja.prager.homeip.net (192.168.1.7) 56(84) bytes of data. >> 64 bytes from freyja.prager.homeip.net (192.168.1.7): icmp_seq=1 ttl=64 >> time=131 ms >> >> --- freyja.prager.homeip.net ping statistics --- >> 1 packets transmitted, 1 received, 0% packet loss, time 0ms >> rtt min/avg/max/mdev = 131.374/131.374/131.374/0.000 ms >> >> Now the same query from my Mac sees the host but still can't connect to it: >> >> [bernd@loki ~$ dig @qnap freyja >> >> ; <<>> DiG 9.10.6 <<>> @qnap freyja >> ; (1 server found) >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54217 >> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;freyja. IN A >> >> ;; ANSWER SECTION: >> freyja. 0 IN A 192.168.1.7 >> >> ;; Query time: 7 msec >> ;; SERVER: 192.168.1.5#53(192.168.1.5) > The same .5 > > >> ;; WHEN: Mon Aug 03 22:29:25 +07 2020 >> ;; MSG SIZE rcvd: 51 >> >> [bernd@loki ~$ ping -c 1 freyja >> ping: cannot resolve freyja: Unknown host >> >> Does anybody have an idea what I am missing? > Yes > > >> Thank you for any help. > You are welcome > I'm looking forward to better questions > > > Regards > Geert Stappers smime.p7s Description: S/MIME Cryptographic Signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] multiple upstream servers
What DNS server does the client MOEDW1CKH5 think is it's DNS? If it's a linux client then check /etc/resolv.conf to see or sniff the wire for the DHCP request/response. You've told dnsmasq to send a lease with option 6 (DNS) set to 10.88.13.3. Where dnsmasq forwards the queries to is not relevant to your issue, you only have one upstream server configured. S Irlapati wrote on 7/29/2020 3:29 PM: > Yes, that was a cut and paste error. I have simplified the file to > make things easier to debug. > > Here is what it looks like now, I will paste the whole file here > > port=53 > bogus-priv > no-resolv > local=/localnet/ > user=dnsmasq > group=dnsmasq > interface=enp5s0 > listen-address=127.0.0.1,192.168.13.1 > expand-hosts > domain=irlanet.org > dhcp-range=192.168.13.224,192.168.13.255,2h > dhcp-authoritative > cache-size=0 > cname=win-sji,MOEDW1CKH5 > log-queries > log-dhcp > > dhcp-host=00:68:eb:3b:32:33,MOEDW1CKH5,set:red,192.168.13.192 > > dhcp-option=tag:red,option:dns-server,10.88.13.3 > dhcp-option=tag:green,option:dns-server,10.88.13.4 > dhcp-option=option:dns-server,10.88.13.4 > server=10.88.13.4#53 > > Here is how dnsmasq is tested from MODEW1CKH5 > > [si@MOEDW1CKH5 593]>curl ident.me > 97.90.236.142 > > Here is what shows up in the log files > > Jul 29 17:26:16 xroads dnsmasq[2612016]: query[A] ident.me from > 192.168.13.192 > Jul 29 17:26:16 xroads dnsmasq[2612016]: forwarded ident.me to 10.88.13.4 > Jul 29 17:26:16 xroads dnsmasq[2612016]: query[] ident.me from > 192.168.13.192 > Jul 29 17:26:16 xroads dnsmasq[2612016]: forwarded ident.me to 10.88.13.4 > Jul 29 17:26:16 xroads dnsmasq[2612016]: reply ident.me is 176.58.123.25 > Jul 29 17:26:16 xroads dnsmasq[2612016]: reply ident.me is > 2a01:7e00::f03c:91ff:fe70:2b9d > > Does the order of the statements in the config files matter? > > On 7/29/2020 2:42 PM, Daryl Richards wrote: >> On 2020-07-29 2:40 p.m., S Irlapati wrote: >>> Thanks for the quick reply. >>> >>> I have changed it to >>> >>> dhcp-host=00:a1:b0:08:61:67,floater,tag:red,192.168.13.109 >>> dhcp-host=00:c0:a8:be:ed:d0,Ziong,tag:green,192.168.13.110 >>> >>> dhcp-option=tag:red,option:dns-server,10.88.13.3 >>> dhcp-option=tag:green,option:dns-server,10.88.13.4 >>> server=10.88.13.4#53 >>> >>> It still does the same thing. >>> >>> When querying from machine floater, it get forwarded it to 10.88.13.4 >>> >>> Any other suggestions? Could there be something else that is being >>> missed? >> >> I'm not sure if this is a cut/paste error - but the line looks the >> same as before with tag: instead of set:.. Also looking at the man >> page it shows the options in a slighty different order (don't know if >> that matters). So, it should be: >> >> dhcp-host=00:a1:b0:08:61:67,set:red,192.168.13.109,floater >> dhcp-host=00:c0:a8:be:ed:d0,set:green,192.168.13.110,Ziong >> > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss smime.p7s Description: S/MIME Cryptographic Signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] multiple upstream servers
dhcp-host=00:a1:b0:08:61:67,floater,set:red,192.168.13.109 > The set: construct sets the tag whenever this *--dhcp-host* > directive is in use. This can be used to selectively send DHCP options > just for this host. More than one tag can be set in a *--dhcp-host* > directive (but not in other places where "set:" is allowed). When > a host matches any *--dhcp-host* directive (or one implied by > /etc/ethers) then the special tag "known" is set. This allows dnsmasq > to be configured to ignore requests from unknown machines using > *--dhcp-ignore=tag:!known* If the host matches only a *--dhcp-host* > directive which cannot be used because it specifies an address on > different subnet, the tag "known-othernet" is set. > > The tag: construct filters which dhcp-host directives are used. > Tagged directives are used in preference to untagged ones. > S Irlapati wrote on 7/29/2020 11:40 AM: > Thanks for the quick reply. > > On 7/29/2020 1:02 PM, Daryl Richards wrote: >> >> The proper syntax on the dhcp-host lines is 'set:red' and 'set:green' >> to set the tags that you then use on the options.. >> > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss smime.p7s Description: S/MIME Cryptographic Signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Fwd: dnsmasq localise-queries + addn-hosts
Jake Howard wrote on 4/5/2020 6:48 AM: >> >> Dnsmasq uses the _destination_ address of the query. I'm not familiar >> with Docker. Is it using NAT? > > Can't say i'm especially familiar with Docker's networking stack, but > it definitely looks and feels like something NAT-ish to me! > Interestingly enough, the log entry for where the query came from is > correctly detected, but I guess it's not using that address to localise? > > Thanks, > - Jake Howard Default Docker iptables chains (for containers running published services on 80/443) # Generated by xtables-save v1.8.2 on Sun Apr 5 20:00:11 2020 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :DOCKER - [0:0] -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE -A POSTROUTING -s 172.17.0.4/32 -d 172.17.0.4/32 -p tcp -m tcp --dport 443 -j MASQUERADE -A POSTROUTING -s 172.17.0.4/32 -d 172.17.0.4/32 -p tcp -m tcp --dport 80 -j MASQUERADE -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER -A DOCKER -i docker0 -j RETURN -A DOCKER ! -i docker0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.17.0.4:443 -A DOCKER ! -i docker0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.17.0.4:80 COMMIT # Completed on Sun Apr 5 20:00:11 2020 # Generated by xtables-save v1.8.2 on Sun Apr 5 20:00:11 2020 *filter :INPUT ACCEPT [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] :DOCKER - [0:0] :DOCKER-ISOLATION-STAGE-1 - [0:0] :DOCKER-ISOLATION-STAGE-2 - [0:0] :DOCKER-USER - [0:0] -A FORWARD -j DOCKER-USER -A FORWARD -j DOCKER-ISOLATION-STAGE-1 -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -o docker0 -j DOCKER -A FORWARD -i docker0 ! -o docker0 -j ACCEPT -A FORWARD -i docker0 -o docker0 -j ACCEPT -A DOCKER -d 172.17.0.4/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 443 -j ACCEPT -A DOCKER -d 172.17.0.4/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 80 -j ACCEPT -A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2 -A DOCKER-ISOLATION-STAGE-1 -j RETURN -A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP -A DOCKER-ISOLATION-STAGE-2 -j RETURN -A DOCKER-USER -j RETURN COMMIT # Completed on Sun Apr 5 20:00:11 2020 Dan > > On Sat, 4 Apr 2020, at 19:01, Simon Kelley wrote: >> On 31/03/2020 13:51, Jake Howard wrote: >> > Hello! >> > >> > Had a breakthrough on what's going on, and it's down to a caveat I >> > missed when reading the man page on localise-queries: >> > >> >> Return answers to DNS queries from /etc/hosts and *--interface-name* >> > which depend on the interface over which the query was received. >> > >> > And of course, this issue has to do with docker. With Docker, even >> > though the container is listening on 2 different interfaces, and 2 >> > different IPs, the inner container, and thus dnsmasq, only sees 1 >> > interface, with all addresses coming from it. Hence localisation isn't >> > quite working. >> > >> > If I run dnsmasq with the exact same config but on the host, where it >> > can see the different interfaces, works perfectly! >> > >> > Testing was done in 2.79 and 2.76, with a config file practically >> > identical to your CLI arguments. >> > >> > Technically, there's not a bug here per-say, but it'd be really >> handy if >> > there was a way of looking at the source IP when determining which >> > record to return rather than just the interface? >> >> Dnsmasq uses the _destination_ address of the query. I'm not familiar >> with Docker. Is it using NAT? >> >> >> Simon. >> >> >> > >> > Thanks! >> > >> > On Mon, 30 Mar 2020, at 20:42, Simon Kelley wrote: >> >> On 28/03/2020 20:38, Jake Howard wrote: >> >> > Hi, >> >> > >> >> > My intention is to have 1 dnsmasq instance, accessible over 2 >> interfaces >> >> > (listening on all), and have the response to a query differ >> based on the >> >> > interface, and therefore its incoming IP. From what i've read, >> that's >> >> > exactly what localise-queries is meant to do, but it doesn't >> appear to >> >> > be unless I put the entries into /etc/hosts directly. >> >> >> >> >> >> OK, what you're expecting to happen and what I'm expecting to >> happen are >> >> the same. That's good. >> >> >> >> I just did a quick test, and it seems to work fine for me. The >> >> example.com addresses are in /tmp/hosts. >> >> >> >> >> >> srk@holly:~/dnsmasq/dnsmasq$ src/dnsmasq -d --log-queries >> >> --localise-queries -p 1 --addn-hosts=/tmp/hosts >> >> dnsmasq: started, version 2.81rc4-5-gd162bee cachesize 150 >> >> dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n >> >> no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC >> >> loop-detect inotify dumpfile >> >> dnsmasq: reading /etc/resolv.conf >> >> dnsmasq: using nameserver 127.0.1.1#53 >> >> dnsmasq: read /etc/hosts - 9 addresses >> >> dnsmasq: read /tmp/hosts - 2 addresses >> >> dnsmasq: query[A] example.com from 127.0.0.1 >> >> dnsmasq:
