Re: [Dnsmasq-discuss] Bug while using address=//::
On Wed, Sep 29, 2021 at 09:15:15PM -0700, E wrote: > > IPv6 connectivity > > Why dnsmasq can't drop , > when the server has no IPv6 connectivity at all? > This doesn't make sense. No sense to those would don't understand what DNS is. (DNS is a key value database (which is distributed)) > Something like "no-ipv6" or "ipv4-only" switch > would be really nice here... Nice is how people should behave. Computers and other tools are blunt, rude, straight down and such. Please understand that querying an record is the very same as querying an TXT, MX or A record. It doesn't mather if the request travels over IPv6 or IPv4. And other please, an pretty please: Embrace evolution Embrace mental growth Groeten Geert Stappers P.S. To those who feel insulted by this posting Consider the suffering when being ignored -- Silence is hard to parse signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Bug while using address=//::
> Which dnsmasq version are you using? Latest on Debian 11. ii dnsmasq 2.85-1 all Small caching DNS proxy and DHCP/TFTP server ii dnsmasq-base 2.85-1 amd64Small caching DNS proxy and DHCP/TFTP server > src/dnsmasq -d --port 2053 --conf-file=/dev/null --log-queries --address=/./:: > This seems to do what you wanted Is it? Nope. still not blocked at all! 1. edit dnsmasq.conf, add "address=/./::" 2. restart service 3. dig .com @127.0.0.1 --- still responds results dig .com A @127.0.0.1 --- works (returning A results) My question is simple, a. How can I block certain ranges? b. Or, How can I block all ? ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Bug while using address=//::
> IPv6 connectivity Why dnsmasq can't drop , when the server has no IPv6 connectivity at all? This doesn't make sense. Something like "no-ipv6" or "ipv4-only" switch would be really nice here... dnsmasq.conf simple example server=8.8.8.8#53 no-ipv6 # will drop client's questions ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH v1] remove stale contrib/Suse
dnsmasq is included in SUSE Linux since 2004.
Signed-off-by: Olaf Hering
---
contrib/Suse/README | 6 --
contrib/Suse/README.susefirewall | 27
contrib/Suse/dnsmasq-SuSE.patch | 23 ---
contrib/Suse/dnsmasq-suse.spec | 111 ---
contrib/Suse/rc.dnsmasq-suse | 79 --
5 files changed, 246 deletions(-)
delete mode 100644 contrib/Suse/README
delete mode 100644 contrib/Suse/README.susefirewall
delete mode 100644 contrib/Suse/dnsmasq-SuSE.patch
delete mode 100644 contrib/Suse/dnsmasq-suse.spec
delete mode 100644 contrib/Suse/rc.dnsmasq-suse
diff --git a/contrib/Suse/README b/contrib/Suse/README
deleted file mode 100644
index 3fdc186..000
--- a/contrib/Suse/README
+++ /dev/null
@@ -1,6 +0,0 @@
-This packaging is now unmaintained in the dnsmasq source: dnsmasq is
-included in Suse proper, and up-to-date packages are now available
-from
-
-ftp://ftp.suse.com/pub/people/ug/
-
diff --git a/contrib/Suse/README.susefirewall b/contrib/Suse/README.susefirewall
deleted file mode 100644
index 0b94108..000
--- a/contrib/Suse/README.susefirewall
+++ /dev/null
@@ -1,27 +0,0 @@
-This is a patch against SuSEfirewall2-3.1-206 (SuSE 9.x and older)
-It fixes the dependency from the dns daemon name 'named'
-After appending the patch, the SuSEfirewall is again able to autodetect
-the dnsmasq named service.
-This is a very old bug in the SuSEfirewall script.
-The SuSE people think the name of the dns server will always 'named'
-
-
/sbin/SuSEfirewall2.orig 2004-01-23 13:30:09.0 +0100
-+++ /sbin/SuSEfirewall22004-01-23 13:31:56.0 +0100
-@@ -764,7 +764,7 @@
- echo 'FW_ALLOW_INCOMING_HIGHPORTS_UDP should be set to yes, if you are
running a DNS server!'
-
- test "$FW_SERVICE_AUTODETECT" = yes -o "$FW_SERVICE_AUTODETECT" = dmz -o
"$FW_SERVICE_AUTODETECT" = ext && {
--test "$FW_SERVICE_DNS" = no -a '!' "$START_NAMED" = no && check_srv named
&& {
-+test "$FW_SERVICE_DNS" = no -a '!' "$START_NAMED" = no && check_srv
dnsmasq && {
- echo -e 'Warning: detected activated named, enabling FW_SERVICE_DNS!
- You still have to allow tcp/udp port 53 on internal, dmz and/or external.'
- FW_SERVICE_DNS=$FW_SERVICE_AUTODETECT
-@@ -878,7 +878,7 @@
- test -e /etc/resolv.conf || echo "Warning: /etc/resolv.conf not found"
- # Get ports/IP bindings of NAMED/SQUID
- test "$FW_SERVICE_DNS" = yes -o "$FW_SERVICE_DNS" = dmz -o "$FW_SERVICE_DNS"
= ext -o "$START_NAMED" = yes && DNS_PORT=`$LSOF -i -n -P | \
--$AWK -F: '/^named .* UDP / {print $2}'| $GREP -vw 53 | $SORT -un`
-+$AWK -F: '/^dnsmasq .* UDP / {print $2}'| $GREP -vw 53 | $SORT -un`
- test "$FW_SERVICE_SQUID" = yes -o "$FW_SERVICE_SQUID" = dmz -o
"$FW_SERVICE_SQUID" = ext -o "$START_SQUID" = yes && SQUID_PORT=`$LSOF -i -n -P
| \
- $AWK -F: '/^squid .* UDP/ {print $2}'| $SORT -un`
diff --git a/contrib/Suse/dnsmasq-SuSE.patch b/contrib/Suse/dnsmasq-SuSE.patch
deleted file mode 100644
index 626245f..000
--- a/contrib/Suse/dnsmasq-SuSE.patch
+++ /dev/null
@@ -1,23 +0,0 @@
man/dnsmasq.8 2004-08-08 20:57:56.0 +0200
-+++ man/dnsmasq.8 2004-08-12 00:40:01.0 +0200
-@@ -69,7 +69,7 @@
- .TP
- .B \-g, --group=
- Specify the group which dnsmasq will run
--as. The defaults to "dip", if available, to facilitate access to
-+as. The defaults to "dialout", if available, to facilitate access to
- /etc/ppp/resolv.conf which is not normally world readable.
- .TP
- .B \-v, --version
src/config.h 2004-08-11 11:39:18.0 +0200
-+++ src/config.h 2004-08-12 00:40:01.0 +0200
-@@ -44,7 +44,7 @@
- #endif
- #define DEFLEASE 3600 /* default lease time, 1 hour */
- #define CHUSER "nobody"
--#define CHGRP "dip"
-+#define CHGRP "dialout"
- #define DHCP_SERVER_PORT 67
- #define DHCP_CLIENT_PORT 68
-
-
diff --git a/contrib/Suse/dnsmasq-suse.spec b/contrib/Suse/dnsmasq-suse.spec
deleted file mode 100644
index ff8ba8f..000
--- a/contrib/Suse/dnsmasq-suse.spec
+++ /dev/null
@@ -1,111 +0,0 @@
-###
-#
-# General
-#
-###
-
-Name: dnsmasq
-Version: 2.33
-Release: 1
-Copyright: GPL
-Group: Productivity/Networking/DNS/Servers
-Vendor: Simon Kelley
-Packager: Simon Kelley
-URL: http://www.thekelleys.org.uk/dnsmasq
-Provides: dns_daemon
-Conflicts: bind bind8 bind9
-PreReq: %fillup_prereq %insserv_prereq
-Autoreqprov: on
-Source0: %{name}-%{version}.tar.bz2
-BuildRoot: /var/tmp/%{name}-%{version}
-Summary: A lightweight caching nameserver
-
-%description
-Dnsmasq is lightweight, easy to configure DNS forwarder and DHCP server. It
-is designed to provide DNS and, optionally, DHCP, to a small network. It can
-serve the names of local machines which are not in the global DNS. The DHCP
-server integrates with the DNS server and allows machines with
Re: [Dnsmasq-discuss] dnsmasq compile error: rfc1035.c:978:56: error: 'struct dnsmasq_daemon' has no member named 'workspacename'
On 29/09/2021 02:15, John Thomson wrote: > Hi Simon, > > On Tue, 28 Sep 2021, at 22:45, Simon Kelley wrote: >> This is a dnsmasq bug. I just pushed the fix to the git repo. > > Thank you for the fast fix. > >> Question. Is there a simple way to install libubus on Ubuntu or Debian? >> I have a script which tests a large m=number of plausible build-time >> config combinations, but it doesn't test UBUS because there's no libubus >> on my dev machine. > > I found this old reference: > https://github.com/robbie-cao/note/blob/master/libubox-on-ubuntu.md > > The OpenWrt package now uses -flto for LD and C FLAGS > https://github.com/openwrt/openwrt/blob/master/package/system/ubus/Makefile > > The following process build a libubus.so without install for me on a > non-debian based distribution. > Let me know if you can build something for your test environment from this, > or if you would like me to try to demonstrate debian packages for libubox & > libubus? > > mkdir -p /tmp/openwrt > cd /tmp/openwrt > > git clone https://git.openwrt.org/project/libubox.git > cd libubox > cmake . \ > -DBUILD_LUA=OFF \ > -DBUILD_EXAMPLES=OFF > make > > cd /tmp/openwrt > git clone https://git.openwrt.org/project/ubus.git > cd ubus > LDFLAGS="-flto" CFLAGS="-flto" \ > cmake . \ > -DBUILD_LUA=OFF \ > -DBUILD_EXAMPLES=OFF \ > -DCMAKE_LIBRARY_PATH=/tmp/openwrt/libubox \ > -DCMAKE_INCLUDE_PATH=/tmp/openwrt > make > > Thanks, that worked fine once I'd installed the -dev packages for libjson-c I've added the offending build-option combinations to the automated compile testing. Cheers, Simon. ___ 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] Add nftables set support
On 29/09/2021 22:39, Olaf Hering wrote: > On Sun, Aug 22, Chen Zhenge via Dnsmasq-discuss wrote: > >> +++ b/Makefile >> +nft_libs = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_NFTSET >> $(PKG_CONFIG) --libs libnftables` > > This change lacks pkg-config --cflags, like all the other existing pkg-config > calls already have. > > Olaf > Good spot. It's not normally needed, but it might be somewhere, and then it will bite someone. Fix uploaded. Simon. ___ 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] Add nftables set support
On Sun, Aug 22, Chen Zhenge via Dnsmasq-discuss wrote: > +++ b/Makefile > +nft_libs = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_NFTSET > $(PKG_CONFIG) --libs libnftables` This change lacks pkg-config --cflags, like all the other existing pkg-config calls already have. Olaf ___ 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] Two small fixes
Hey Petr, On Wed, 2021-09-29 at 22:48 +0200, Petr Menšík wrote: > Source based response rules are in general cache unfriendly. What do you > need it for? Is the dnsmasq instance always the only source for name > resolution? We add many features on top of dnsmasq. One example is our support for blocking lists with (dozens of) millions of domains still fitting into a few megabytes of memory. We use a B-tree for this, as there is no need to know the full name if you have other means to know you have an exact match. Anohter example are regular expressions for all sort of things like blocking, enforcing specific replies (not only A/ but also NXDOMAIN/NODATA/REFUSED). And there is more. You may not want to apply the same rules to all devices so you can group them together and then associate clients to these groups. Group selectors can be IP addresses, MAC addresses, hostnames or the interface a query arrived on (for easy, say, VPN/WiFi/ethernet rules). In the latter case, we need to know the label. If it turns out keeping/using label is out of scope for dnsmasq, I will add the label variable myself into our local dnsmasq fork. One thing that is important to us, however, is to keep the difference between our fork and dnsmasq minimal. Even with all the stuff we do on top, the diff between our fork and the main project is less than 100 lines and the vast majority of patches to this mailing list applies cleanly right away. Best, Dominik ___ 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] Two small fixes
On 9/29/21 19:45, Dominik Derigs wrote:
> Hey Petr and Simon,
>
> I tried it with a temporary label and it seems to have worked. But I might
> not have tested the right things.
>
> On Wed, 2021-09-29 at 12:55 +0200, Petr Menšík wrote:
>> I think there was issue with indextoname converting arrival packet index
>> to a name. If it were not marked as label and handled special way,
>> incoming packet never matched eth0:0 interface name, because only eth0
>> got reported as incoming interface.
> Makes sense, if_indextoname() is likely not working here because labels
> have the same index as the "root" device.
>
> On Wed, 2021-09-29 at 12:55 +0200, Petr Menšík wrote:
>> Not worth changing unless we know for sure we want/need it.
> I see. However, I did just check again where "iface->name" is actually used
> and we never compare it to anything. In all cases (did I miss some?), it is
> only for displaying like
>
>> my_syslog(LOG_DEBUG|MS_DEBUG, _("listening on %s(#%d): %s port %d"),
>> iface->name, iface->index, daemon->addrbuff, port);
You are correct, used only for display anywhere.
If no --bind-interface is given, iface->name pointing to eth0 rather
than eth0:0 is correct. Alias is useful only for reading of the address
from the interface name. Otherwise it works as the interface itself.
Thas was reason behind warn_bound_listeners creation. When incoming
packet is checked for acceptance, it is compared to primary interface
identified by ifindex. I think we may even remove name from struct irec
and get the name on few places it needs to be printed. It makes
debugging more comfortable, but is not required anyway.
> or
>
>> my_syslog(LOG_ERR, s, iface->name, strerror(errno));
> so having the correct label showing up here would be helpful and I think no
> behavior should be changed when we edit warn_bound_listeners()
> and warn_wild_labels() to strip the label suffix, something like
>
>> printf("%.*s\n", strcspn(label, ":"), label);
I think : is not reserved character in any case. It can appear multiple
times. It allowed me to create:
inet 127.0.0.127/8 scope host secondary lo:1:0
Because we call indextoname on every single incoming packet, it seems ok
to me if we use it to print configuration time errors. I think we should
not have smart logic about name format but use system functions. It
should be more portable across any type of system.
I think primary issue I were solving years back around this, it should
display label only when label itself is relevant. Someone back then
reported it accepted also other addresses than specified, when label was
used. I wonder why struct server contains char interface[IF_NAMESIZE]
when it is rarely used. But struct irec seems to require name always,
yet it is only allocated runtime from heap.
> will should work without any need for a buffer variable.
>
> I should mention that this change was not started because of just the
> change but we are using the interfaces struct also somewhere else in the
> Pi-hole daemon that embedds dnsmasq to support a few interface-dependent
> things (like answering based on arriving interface). This is currently
> broken because we cannot distinguish virtual from real interfaces due to
> the missing label. Not that this should be the reason for making this
> change. This reasoning is given above (correct warnings in dnsmasq).
Source based response rules are in general cache unfriendly. What do you
need it for? Is the dnsmasq instance always the only source for name
resolution?
>
> Best,
> Dominik
>
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Bug while using address=//::
Hi Dominik, On 9/29/21 19:30, Dominik Derigs wrote: > Hey Petr, > > On Wed, 2021-09-29 at 17:49 +0200, Petr Menšík wrote: >> May I ask for your reason, why are you trying to explicitly block IPv6 in >> year 2021? > I asked the very same question when we received the reports about this bug > with the different allocated memory sized that was fixed two weeks ago. The > answer I received from independent parties was always the same. In short: > > 1. No native IPv6 connectivity > 2. Using some sort of VPN tunnel to get IPv6 > 3. Several services favor IPv6 Sure, this exactly is also my situation. We have some internal IPv6 connectivity at offices, but without global internet access. I do not have native IPv6 even at home. But if I miss IPv6 route forward, I do not care if applications try get IPv6 addresses. If default route is missing, any attempt of connection fails immediately. I don't know about application which cannot handle such situation. Okay, some applications may use -4 parameter to skip logging failed attempts, but they should work. If I have some IPv6 connectivity but want to skip it for some services, I would understand that. Some subset only makes sense, like only for netflix domains or spotify domains. Slightly better than blocking their IPv6 ranges on firewall. > > These services (I saw Netflix, Spotify and other bigger names) mentioned > that refuse to work because they think you want to cheat on their geo- > fencing with your VPN. When they use Netflix over their native IPv4, > everything works. Ok, tunnels make geolocation hard. If they do not want to serve the content to uncertain countries, sure, there may be no better way than to disable queries for those services. Especially if their servers accept a connection from those address and respond REFUSED kind of error. Is there scenario, where IPv6 communication over IP addresses should work but any names should not resolve? I could not find any. > > I was a bit surpised about this, but it does make sense. You are correct. Until we have fully supported native connectivity, some filtering might help fixing broken services. Thanks for sharing your experience. > > Best > Dominik Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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] Two small fixes
Hey Petr and Simon,
I tried it with a temporary label and it seems to have worked. But I might
not have tested the right things.
On Wed, 2021-09-29 at 12:55 +0200, Petr Menšík wrote:
> I think there was issue with indextoname converting arrival packet index
> to a name. If it were not marked as label and handled special way,
> incoming packet never matched eth0:0 interface name, because only eth0
> got reported as incoming interface.
Makes sense, if_indextoname() is likely not working here because labels
have the same index as the "root" device.
On Wed, 2021-09-29 at 12:55 +0200, Petr Menšík wrote:
> Not worth changing unless we know for sure we want/need it.
I see. However, I did just check again where "iface->name" is actually used
and we never compare it to anything. In all cases (did I miss some?), it is
only for displaying like
> my_syslog(LOG_DEBUG|MS_DEBUG, _("listening on %s(#%d): %s port %d"),
> iface->name, iface->index, daemon->addrbuff, port);
or
> my_syslog(LOG_ERR, s, iface->name, strerror(errno));
so having the correct label showing up here would be helpful and I think no
behavior should be changed when we edit warn_bound_listeners()
and warn_wild_labels() to strip the label suffix, something like
> printf("%.*s\n", strcspn(label, ":"), label);
will should work without any need for a buffer variable.
I should mention that this change was not started because of just the
change but we are using the interfaces struct also somewhere else in the
Pi-hole daemon that embedds dnsmasq to support a few interface-dependent
things (like answering based on arriving interface). This is currently
broken because we cannot distinguish virtual from real interfaces due to
the missing label. Not that this should be the reason for making this
change. This reasoning is given above (correct warnings in dnsmasq).
Best,
Dominik
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Bug while using address=//::
Hey Petr, On Wed, 2021-09-29 at 17:49 +0200, Petr Menšík wrote: > May I ask for your reason, why are you trying to explicitly block IPv6 in > year 2021? I asked the very same question when we received the reports about this bug with the different allocated memory sized that was fixed two weeks ago. The answer I received from independent parties was always the same. In short: 1. No native IPv6 connectivity 2. Using some sort of VPN tunnel to get IPv6 3. Several services favor IPv6 These services (I saw Netflix, Spotify and other bigger names) mentioned that refuse to work because they think you want to cheat on their geo- fencing with your VPN. When they use Netflix over their native IPv4, everything works. I was a bit surpised about this, but it does make sense. Best Dominik ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Bug while using address=//::
Hello E, May I ask for your reason, why are you trying to explicitly block IPv6 in year 2021? Unless you have public IPv6 route, your system should work just fine with any requests they make. src/dnsmasq -d --port 2053 --conf-file=/dev/null --log-queries --address=/./:: This seems to do what you wanted, it is recent code from dnsmasq. But my question remains. What is a problem with IPv6 if you just do not have IPv6 connectivity? Any programs or systems needing this tuning need to fix themselves, not by dnsmasq. Regards, Petr On 9/28/21 01:41, E wrote: >> https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q3/015348.html >> It can block any name by using --address=/blockedname/::1. > What I want to do: > 1. Block requests. (at first I want to block specific IPv6 ranges > but it's not possible, so) > 2. Can able to query A. > > Steps: > 1. Install dnsmasq on Debian 11 (completely disabled IPv6/IPv4 only > environment) > 2. Add below 2 line to conf and restart service. > server=8.8.8.8#53 > address=/COM/:: > 3. dig github.com A @127.0.0.1 > > Result: > No answer at all. > ;github.com.IN A > > Expected: > github.com. IN A 1.2.3.4 > > > Questions: > 1. why dnsmasq is rejecting A request? > 2. Is there any way to block ? > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] What actually happens when dnsmasq is installed on a system running systemd (with systemd-resolved)?
I cannot answer this for Ubuntu, but on Fedora installation of dnsmasq does not disable anything. I think systemd-resolved it the default and is enabled on default. Whereas dnsmasq is just a service, which has to be enabled manually. Then systemd-resolved has to be disabled manually. Then /etc/resolv.conf has to be modified to point to local dnsmasq. It can be configured by Network Manager also by dns=dnsmasq in NetworkManager.conf. dnsmasq can run on the same system with systemd-resolved, if bind-interfaces or bind-dynamic and interface is specified. But they don't interact between themselves without manual configuration. On 9/28/21 21:28, Chris Green wrote: > I run xubuntu version 21.04 on several systems. Thus the default DNS > cache and configuring of /etc/resolv.conf is done by systemd and its > minions. > > Does anyone here know what happens if/when I install dnsmasq? Is the > installation process clever enough to reconfigure and/or turn off the > right things in systemd so that dnsmasq gets to do local DNS cacheing > and so on? > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] How may is too many CNAME references?
Please note too big blocklists take significantly more memory in dnsmasq runtime than on just address=hostname.example.net in plain text file. If your router does not have enough storage, add USB drive. If it has very low memory, I think you should direct your DNS queries to better suited central server, if you have (tens of) thousands of lines in blocklist. Altough there is somehow simple way. You should be able to use zcat dnsmasq.conf.gz | dnsmasq --conf-file=/dev/stdin. But as I said, it would still take a memory during runtime, which is significantly more than just those lines. The more lines you include, the more work is has to spend PER EACH query. It has improved recently, but it might be significant work on a weak hardware. Are there public services, to which you can point your dnsmasq instead? Filtering those names already for you? What is the source of your block lists? Cheers, Petr On 9/28/21 09:55, Ercolino de Spiacico wrote: > Ok understood and very valid answer. > > Let's remember one thing the (excellent) dnsmasq is extremely common > in small routers and embedded devices where permanent storage is often > not available. > > I am ok sticking to address= syntax so working on A records only but I > was wondering if dnsmasq could go the extra mile. Let me explain here > below. > > In embedded systems with only Flash+squash-filesystem a "file" is > actually stored in RAM. In case of adblock this file can take up lots > of RAM... some adblock lists are MBs in size and contain domains only > (one per line). If we are to process the list to prefix the > "address=/" directive and even suffix the IP address the file (RAM > demand) can easily double in size. > > Is there a potential for dnsmasq to facilitate this cases? What I'm > thinking is for dnsmasq to allow e.g. a new syntax like: > > address=\file:$path_to_a_domains_list_file\IP > > and every line in that file is always prefixed/suffixed with the > information of the directive referencing the file. This would keep the > domain blocking info to a bare minimum, so essentially the file would > need to contain only a list of domains (one per line). > > Just a thought... if you google this you'll see that > ads/domain-blocking is actually relatively common on embedded devices; > opensource router-firmware in-primis: Tomato, DD-WRT, OpenWRT, etc. > > Thanks > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
It is somehow hard to guess described results for each configuration (1. 2. 3.). It is unclear to me, what you saw for each variant printed by the computer. 1. seems to have wrong pcap file or it does not use configuration attached in linked archive. It seems it offers menu items from 2. archive with custom pxe-services. Option 43 Suboption: (9) PXE boot menu Length: 41 boot menu: 8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820… Type: Unknown (32768) Length: 21 Description: PXELINUX (X86-64_EFI) Type: Unknown (32769) Length: 14 Description: PXELINUX (EFI) Above is not present in config file presented for it, but in 2. Are you sure you have killed dnsmasq and started it again? I think it might be difference between pxe-service served file chosen via menuboot. I have noticed there are two way to specify file to boot in DHCP for IPv4. One is in fixed header and first try chosen from menu is in that. pxe-service options makes it to request direct query to DHCP server, marked proxyDHCP in wireshark. This proxy ACK is followed by TFTP. I used filter in wireshark: "dhcp or (!tftp.destination_file && tftp)" However following DHCP offers boot file path ONLY in option 67 value. Fixed header boot file is all zeroed. It seems to me this is the part the snponly.efi firmware does not understand. It does not try to use path in option, but may insist only on file. Since option #52 overload is not in packet, I guess dnsmasq should have used mess->file for path and not option 67. But rules of rfc2131.c:2476 are simple. If client have requested option 67, it should handle it as option 67. I guess it is bug in snponly.efi. Either it should not include option 67 between requested options or it should actually handle the option. Dnsmasq would offer boot path in both cases. Interesting enough, dnsmasq is inconsistent with itself. It behaves a bit different way in PXE proxy mode, where file header part is always used. In normal mode unless --dhcp-no-override is used, option is used if requested. Can you please try if dhcp-no-override option would fix your issues? I think it should behave the same way in both situations. I attached patch, which would set boot file on pxe-service the same way as dhcp-boot. It may require dhcp-no-override where it did not before. Could you please try it? On 9/28/21 11:54, Shrenik Bhura wrote: > Hi Petr, > > As per your guidance, we have enabled logging (LOG_ALL in > config/consolle.h) and recompiled the ipxe binaries. Below are the > latest observations. > > Taking down the scenarios from the previous post for ease of reference - > 1. Default dnsmasq config with default ltsp's pxe-service entries - > https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing > 2. Custom pxe-service entries (just to prove that pxe-service and > dhcp-boot do seem to successfully co-exist) - > https://drive.google.com/file/d/1-CjHXxlKmYw-9aOTD7xK8m5uAdj4qyAB/view?usp=sharing > 3. Without pxe-service entries - > https://drive.google.com/file/d/1-6Q_1Fg6zVVNruzQTJjxvmKRRkRnCBmh/view?usp=sharing > > > I'll try to summarise the understanding and prevailing ambiguities > thus far to help allot responsibility of multiple things that may be > going wrong here : > > Between scenario (1) and (2), we see that ltsp.ipxe is being served in > (2) which doesn't happen in (1). > In (1), the primary issue is that EFI clients do not receive > snponly.efi, thus they do not advertise option 175 and hence are not > sent the ltsp.ipxe. Since it has not got to the iPXE stage as yet, > there are no logs available from ipxe. All that is visible > momentarily on the client side is these two lines - > *Station IP address is 192.168.67.134 > * > *PXE-E21: Remote boot cancelled.* > Quoting from an explanation herein [1] for "Remote boot cancelled" - > /" This message is also displayed when a DHCP/proxyDHCP server sends a > menu that auto-selects *Local Boot* and when a bootserver sends a > bootstrap program that returns control to the PXE LoadFile protocol. "/* > * > * > * > In scenario (2), PXE boot menu is displayed as defined in the > pxe-service lines, option 175 is received back from the client, > ltsp.ipxe is sent but is not "downloaded" by the client. There is > nothing reported in the ipxe logs. On the client, the last line says - > No more network devices.* > * > * > * > But, above all, if we simply comment out all the pxe-service lines, as > in scenario (3), including the one with tag:rpi, the EFI clients boot > up perfectly. iPXE log has - > ipxe: Downloaded "ltsp.ipxe" > ipxe: Executing "ltsp.ipxe" > ipxe: Downloaded "vmlinuz" > ipxe: Downloaded "ltsp.img" > ipxe: Downloaded "initrd.img" > ipxe: Executing "vmlinuz" > > The question thus arises that why does dnsmasq not ignore the > pxe-service lines which have an unmatched "tag:proxy" or "tag:rpi" > when dnsmasq is operating in non-proxy mode? Or does it ignore and yet
[Dnsmasq-discuss] [PATCH] Addressing hostsdir shortcomings
Dear Simon,
dnsmasq v2.73 added --hostsdir which is an efficient way of re-
loading only parts of the cache. When we tried to use hostsdir
yesterday, we identified three problems. They are described
below. Patches addressing them are attached.
--- ISSUE 1 --- Logging imprecision
Assume you have multiple files in hostsdir, dnsmasq can only log
the directory not the file that was the real source:
dnsmasq: read /home/test/hostsdir/hosts1 - 1 addresses
dnsmasq: read /home/test/hostsdir/hosts2 - 1 addresses
dnsmasq: read /home/test/hostsdir/hosts3 - 1 addresses
dnsmasq: 1 127.0.0.1/34170 query[A] aaa from 127.0.0.1
dnsmasq: 1 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.2
dnsmasq: 1 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.1
dnsmasq: 1 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.2
This happens because the cache entries all use the same index
that is the directory name.
--- ISSUE 2 --- Outdated entries are not removed
When hostsdir re-reads the file, it does not remove outdated
entries. Assume you modify "192.168.1.1 aaa" to "192.168.1.2
aaa", dnsmasq will now serve two A records for "aaa". This may be
considered okay, however, if I add "192.168.1.1 bbb", PTR
requests for this domain will still be replied with "aaa" which
might be completely outdated information.
--- ISSUE 3 --- Ever growing replies under certain situations
When a users uses an editor that creates (temporary) files during
editing (like "sed -i") or uses a script that writes files line
by line (like "echo '' >> file"), they can quickly end up with
strange things like
dnsmasq: 3 127.0.0.1/34170 query[A] aaa from 127.0.0.1
dnsmasq: 3 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.2
dnsmasq: 3 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.1
dnsmasq: 3 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.2
dnsmasq: 3 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.2
dnsmasq: 3 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.2
dnsmasq: 3 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.2
dnsmasq: 3 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.2
dnsmasq: 3 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.2
dnsmasq: 3 127.0.0.1/34170 /home/test/hostsdir aaa is 192.168.1.2
which is not very meaningful. We check for duplicates before
inserting into the cache, however, duplicate checking can be
foiled here: add_hosts_entry() calls cache_find_by_name() only
once (say it returned "192.168.1.1") so the memcmp() on the
address fails and we can add an arbitrary amount of 192.168.1.2
entries.
-
For addressing issue 1, I added a new struct *dyndir having a
linked list of struct *hostsfile. With this, cache_insert() can
get the correct index. If a file is newly added, we just add a
new *hostsfile entry to the list (index++).
Issue 2 is an easy one as we can selectively clean the cache when
we know the uid to be removed. This can be called before running
read_hostsfile() to insert new stuff. I added MOVE_FROM and
DELETE to inotify_add_watch() so we catch if a file was removed.
In this case, we only remove old entries.
Issue 3 is fixed by adding a loop over cache_find_by_name() in
add_hosts_entry() to check possible multiple records.
Best,
Dominik
From 8d012b975874d71fa39565a1acddcc65a87d27c6 Mon Sep 17 00:00:00 2001
From: Dominik Derigs
Date: Wed, 29 Sep 2021 08:22:05 +0200
Subject: [PATCH 1/3] Extend hostsdir to differentiate between individual files
in dynamic directories
Signed-off-by: DL6ER
---
src/cache.c | 9 +++--
src/dnsmasq.h | 13 ++-
src/inotify.c | 101 ++
src/option.c | 40
4 files changed, 111 insertions(+), 52 deletions(-)
diff --git a/src/cache.c b/src/cache.c
index e1d17c4..6c8cfa9 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -1837,6 +1837,7 @@ void dump_cache(time_t now)
char *record_source(unsigned int index)
{
struct hostsfile *ah;
+ struct dyndir *dd;
if (index == SRC_CONFIG)
return "config";
@@ -1848,9 +1849,11 @@ char *record_source(unsigned int index)
return ah->fname;
#ifdef HAVE_INOTIFY
- for (ah = daemon->dynamic_dirs; ah; ah = ah->next)
- if (ah->index == index)
- return ah->fname;
+ /* Dynamic directories contain multiple files */
+ for (dd = daemon->dynamic_dirs; dd; dd = dd->next)
+for (ah = dd->files; ah; ah = ah->next)
+ if (ah->index == index)
+ return ah->fname;
#endif
return "";
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index c8a918a..32bca11 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -679,10 +679,17 @@ struct hostsfile {
struct hostsfile *next;
int flags;
char *fname;
+ unsigned int index; /* matches to cache entries for logging */
+};
+
+struct dyndir {
+ struct dyndir *next;
+ struct hostsfile *files;
+ int flags;
+ char *dname;
#ifdef HAVE_INOTIFY
int wd; /* inotify watch descriptor */
#endif
- unsigned int index; /* matches to cache entries for logging */
};
/*
Re: [Dnsmasq-discuss] [PATCH] Two small fixes
I do not remember it well also. But I think it was there to allow --interface=eth0:0 on startup and do actually something, when started without --bind-interfaces. I think there was issue with indextoname converting arrival packet index to a name. If it were not marked as label and handled special way, incoming packet never matched eth0:0 interface name, because only eth0 got reported as incoming interface. Therefore it warns different interface name is in effect, which might include more listening addresses than intended. I suspect Dominik's would break some use-case, though I am not sure which. Was the change tested with existing label interface and both with --bind-interfaces parameter and without? It seems risky, I think those interfaces system is a bit fragile and small changes often break something not obvious. I doubt --no-dhcp-interface=eth0:0 may even work, DHCP is working on lower levels. Not worth changing unless we know for sure we want/need it. Cheers, Petr On 9/28/21 00:03, Simon Kelley wrote: > On 18/09/2021 19:20, Dominik DL6ER wrote: > >> Patch 1 fixes an ambiguity with interface names when virtual >> interfaces are present. >> I'm not exactly sure it has no unintended side-effects, however, >> it seems to be the right thing to do in my understanding of the >> code. Otherwise, virtual interfaces cannot really be >> distinguished from real interfaces later in the code. This may be >> a problem when there is more than one virtual interface as iface- >>> label will be non-zero for all of them. For instance, >> warn_wild_labels() will log the same string multiple times if >> more than one virtual interface is present. >> > > Petr, this code seems to have last been touched by you, in > > ad59f278c6234a416f36dfdd39143bb46f5d707a > > can you remember what that was supposed to achieve? None of it is making > much sense to me. > > Simon. > > > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] REFUSED after dropped packets
On 28/09/2021 18:08, Johannes Stezenbach wrote: > On Mon, Sep 27, 2021 at 10:45:25PM +0100, Simon Kelley wrote: >> >> I think that this is a 2.86 problem. There are two cases when dnsmasq >> will try another server with the same query: >> >> 1) When a client retries the query. >> 2) When the first server returns REFUSED. >> >> In the second case, it's important to give up when all available servers >> have returned REFUSED, otherwise the query keeps bouncing forever. 2.86 >> got the two cases mixed up and implemented that behavior for client >> retries too. That's a bug. >> >> https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=2561f9fe0eb9c0be1df48da1e2bd3d3feaa138c2 >> >> should fix it. >> >> >> Please test. > > This seems to work well. Currently my Wifi connection is stable, > thus I disconnected the antenna to simulate the problem: > > $ host kernel.org > ;; connection timed out; no servers could be reached > > Dnsmasq properly forwarded the client retry: > > Sep 28 19:00:03 dnsmasq[32598]: 4 127.0.0.1/35962 query[A] kernel.org from > 127.0.0.1 > Sep 28 19:00:03 dnsmasq[32598]: 4 127.0.0.1/35962 forwarded kernel.org to > 192.168.178.1 > Sep 28 19:00:08 dnsmasq[32598]: 5 127.0.0.1/35962 query[A] kernel.org from > 127.0.0.1 > Sep 28 19:00:08 dnsmasq[32598]: 5 127.0.0.1/35962 forwarded kernel.org to > 192.168.178.1 > > > After reattaching the antenna: > > $ host kernel.org > kernel.org has address 198.145.29.83 > kernel.org mail is handled by 10 mail.kernel.org. > > Sep 28 19:00:51 dnsmasq[32598]: 6 127.0.0.1/54047 query[A] kernel.org from > 127.0.0.1 > Sep 28 19:00:51 dnsmasq[32598]: 6 127.0.0.1/54047 forwarded kernel.org to > 192.168.178.1 > Sep 28 19:00:51 dnsmasq[32598]: 6 127.0.0.1/35962 reply kernel.org is > 198.145.29.83 > Sep 28 19:00:51 dnsmasq[32598]: 6 127.0.0.1/54047 reply query is duplicate > Sep 28 19:00:51 dnsmasq[32598]: 7 127.0.0.1/41845 query[] kernel.org from > 127.0.0.1 > Sep 28 19:00:51 dnsmasq[32598]: 7 127.0.0.1/41845 forwarded kernel.org to > 192.168.178.1 > Sep 28 19:00:51 dnsmasq[32598]: 7 127.0.0.1/41845 reply kernel.org is > NODATA-IPv6 > Sep 28 19:00:51 dnsmasq[32598]: 8 127.0.0.1/42436 query[MX] kernel.org from > 127.0.0.1 > Sep 28 19:00:51 dnsmasq[32598]: 8 127.0.0.1/42436 forwarded kernel.org to > 192.168.178.1 > Sep 28 19:00:51 dnsmasq[32598]: 8 127.0.0.1/42436 reply kernel.org is > > > Thanks, > Johannes > Working well for me too. I think we can tick that one off. Thanks for your help. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] What actually happens when dnsmasq is installed on a system running systemd (with systemd-resolved)?
On Tue, Sep 28, 2021 at 11:59:09PM +0100, Simon Kelley wrote: > On 28/09/2021 20:28, Chris Green wrote: > > I run xubuntu version 21.04 on several systems. Thus the default DNS > > cache and configuring of /etc/resolv.conf is done by systemd and its > > minions. > > > > Does anyone here know what happens if/when I install dnsmasq? Is the > > installation process clever enough to reconfigure and/or turn off the > > right things in systemd so that dnsmasq gets to do local DNS cacheing > > and so on? > > > > That's not a simple question to answer. It depends on the distro > packages for dnsmasq, systemd and possibly others. > > Systemd has a daemon called systemd-resolved which has much the same > functionality ad the DNS part of dnsmasq. > Yes, the interactions of systemd and dnsmasq are what I'm interested in. I guess the right place to ask (in my [x]ubuntu case is one of the Ubuntu support lists. I'll try there. -- Chris Green ___ 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] dnsmasq_time: avoid signed integer overflow when HAVE_BROKEN_RTC
Nice catch, and nice patch.
Patch applied.
Cheers,
Simon.
On 28/09/2021 01:44, Matt Whitlock wrote:
> The dnsmasq_time() function, in the case of HAVE_BROKEN_RTC, was calling
> times() to read the number of ticks "elapsed since an arbitrary point in
> the past" and then dividing that by sysconf(_SC_CLK_TCK) to compute the
> number of seconds elapsed since that arbitrary instant. This works fine
> until the number of ticks exceeds 2^31, beyond which time the function
> would begin erroneously returning negative times. On my system this
> happens after approximately 248 days of uptime. A symptom is that
> dnsmasq no longer populates the resolver cache with DHCP-derived names
> at startup, as the inserted cache entries immediately expire due to
> having negative expiration times that cause is_expired() to return true
> when called with now==0.
>
> This commit replaces the archaic implementation of dnsmasq_time() with a
> call to the POSIX-standardized clock_gettime(CLOCK_MONOTONIC), thereby
> eliminating the need to convert manually from ticks to seconds. The new
> implementation will yield correct results until the system uptime
> exceeds approximately 68 years.
>
> Signed-off-by: Matt Whitlock
> ---
> src/util.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/src/util.c b/src/util.c
> index 1425764..b2179d0 100644
> --- a/src/util.c
> +++ b/src/util.c
> @@ -408,13 +408,12 @@ int hostname_issubdomain(char *a, char *b)
> time_t dnsmasq_time(void)
> {
> #ifdef HAVE_BROKEN_RTC
> - struct tms dummy;
> - static long tps = 0;
> + struct timespec ts;
>
> - if (tps == 0)
> -tps = sysconf(_SC_CLK_TCK);
> + if (clock_gettime(CLOCK_MONOTONIC, ) < 0)
> +die(_("cannot read monotonic clock: %s"), NULL, EC_MISC);
>
> - return (time_t)(times()/tps);
> + return ts.tv_sec;
> #else
>return time(NULL);
> #endif
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
