Re: [Dnsmasq-discuss] Noisy DHCPv6 DHCPADVERTISE

[Simon Kelley]

The message can be important (think a mismatch between the address of 
the receiving interface and a dhcp-range, so I wouldn't like to suppress it.


It might be sensible to detect the situation you have (static range in 
scope, no host configured) and suppress it then. It's slightly more 
complicated since there can be more than one address request from the 
client, but that's a detail.



Simon.

> On 29/02/2024 11:04, Ian Dall wrote:

I know this is an old thread, but I too find these messages annoying.

I have:
dhcp-range=set:lan,::,static,constructor:br-lan,slaac,ra-names,12h

which as far as I can tell is perfectly valid. My unknown IPv6 clients
get configured with SLAAC/RA, but clients which are known via dhcp-host
get a DNS record so can be referenced by name (and the same name as
their IPv4 address). Unfortunately the unknown clients do a DHCPv6
SOLICIT and get back "no addresses available".

With "static" mode "no addresses available" is a lower priority error,
although it could still be of interest because perhaps we expect a
(known) address to be allocated, but is failing due to different DUID
types or something (and you would want to know about that).

So, it would be really nice to be able to optionally quieten these
messages (with quiet-dhcp6 would be simplest).

Regards,
Ian


On Sun, 2019-06-02 at 09:57 +0200, stappers at stappers.nl wrote:

On Sat, Jun 01, 2019 at 08:02:27PM -0700, Sam Edwards wrote:

Hello,

I have dnsmasq set up to provide IPv6 RAs with the SLAAC bit set,
and also serve select static DHCPv6 leases. Everything is set up and
working correctly, but because only some devices have a static lease
set up, and there is no DHCPv6 pool, my logs fill up with entries from
devices that don't get a lease, reporting that there is no address
available for them.

Jun  1 19:46:56 dnsmasq-dhcp[4798]: DHCPADVERTISE(switch0.5) 
00:02:00:00:01:57:72:f6:40:68:e8:c6:6d:4e:8e:bd:fc:34:65:xx:xx:xx,no addresses 
available
Jun  1 19:47:33 dnsmasq-dhcp[4798]: DHCPADVERTISE(switch0.5) 
00:01:00:01:1d:b7:03:73:3c:07:54:xx:xx:xx,no addresses available
Jun  1 19:48:12 dnsmasq-dhcp[4798]: DHCPADVERTISE(switch0.5) 
00:01:00:01:21:4c:7f:01:08:66:98:xx:xx:xx,no addresses available
Jun  1 19:48:57 dnsmasq-dhcp[4798]: DHCPADVERTISE(switch0.5) 
00:02:00:00:01:57:72:f6:40:68:e8:c6:6d:4e:8e:bd:fc:34:65:xx:xx:xx,no addresses 
available
Jun  1 19:49:24 dnsmasq-dhcp[4798]: DHCPADVERTISE(switch0.5) 
00:01:00:01:1d:b7:03:73:3c:07:54:xx:xx:xx,no addresses available
Jun  1 19:50:04 dnsmasq-dhcp[4798]: DHCPADVERTISE(switch0.5) 
00:01:00:01:21:4c:7f:01:08:66:98:xx:xx:xx,no addresses available
Jun  1 19:50:57 dnsmasq-dhcp[4798]: DHCPADVERTISE(switch0.5) 
00:02:00:00:01:57:72:f6:40:68:e8:c6:6d:4e:8e:bd:fc:34:65:xx:xx:xx,no addresses 
available
Jun  1 19:51:15 dnsmasq-dhcp[4798]: DHCPADVERTISE(switch0.5) 
00:01:00:01:1d:b7:03:73:3c:07:54:xx:xx:xx,no addresses available
Jun  1 19:51:17 dnsmasq-dhcp[4798]: DHCPADVERTISE(switch0.5) 
00:01:00:01:23:38:5f:28:e0:33:8e:xx:xx:xx,no addresses available
Jun  1 19:51:54 dnsmasq-dhcp[4798]: DHCPADVERTISE(switch0.5) 
00:01:00:01:21:4c:7f:01:08:66:98:xx:xx:xx,no addresses available

I see in the source, around line 899 of src/rfc3315.c that there is
code to suppress these messages when dnsmasq is operating strictly in
stateless IPv6 mode, but that of course doesn't apply to me.

The question I guess I'm really asking here then, is if the log entry
that's emitted on line 905 of src/rfc3315.c shouldn't be a log6_quiet
instead of a log6_packet, or if there's a feeling that this log line
is important enough to be present at all times.

Here's the relevant part of my configuration for reference:

quiet-dhcp
quiet-dhcp6
quiet-ra
enable-ra
ra-param=*,mtu:tun0,high,60


At http://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html is
  
dhcp-range=[tag:[,tag:],][set:,][,|constructor:][,][,][,]

  ...

  The optional  keyword may be static which tells dnsmasq to enable
  DHCP for the network specified, but not to dynamically allocate IP
  addresses: only hosts which have static addresses given via --dhcp-host
  or from /etc/ethers will be served. A static-only subnet with address
  all zeros may be used as a "catch-all" address to enable replies to all
  Information-request packets on a subnet which is provided with
  stateless DHCPv6, ie --dhcp-range=::,static


dhcp-range=set:Clients-v6,::,constructor:switch0.5,static,slaac,64,24h


There is no mode 'static,slaac'.  And mode 'static' is most likely
the reason for the reported "no addresses available".

If so we, dnsmasq project, have to discuss this manual page snippet

  A static-only subnet with address all zeros may be used as a "catch-all"
  address to enable replies to all Information-request packets on a subnet
  which is provided with stateless DHCPv6, ie --dhcp-range=::,static

further. Or maybe not, an Information-request is another request
as a request for an address.



dhcp-option=tag:Clients-v6,option6:dns-server,[::]

Re: [Dnsmasq-discuss] DHCPv6 Not Working on Linux 6.6.13

[Simon Kelley]

On 28/02/2024 10:29, Robert Sharp wrote:
I have been using Dnsmasq for many years and I am now trying to include 
ipv6. Unfortunately, I cannot seem to get DHCPv6 to work, which I 
believe I need in order to be able to look up hosts using DNS.


My ISP has allocated me with a /48 prefix and I am using dhcpcd to 
delegate a /64 prefix to the LAN interface. This all seems to work fine. 
My dnsmasq.conf settings are:


--

filterwin2k
domain-needed
bogus-priv

#ipv6 stuff

enable-ra
dhcp-range=::1,constructor:enp3s0,24h




dhcp-host=fc:aa:14:c8:9c:3e,hadrian,[::5]

except-interface=ppp0
except-interface=enp4s0
interface=enp3s0
expand-hosts
bind-interfaces
domain=osburn-sharp.ath.cx
local=/osburn-sharp.ath.cx/
no-resolv
server=127.0.0.1#553
address=...
cname=...
dhcp-range=192.168.0.64,192.168.0.127,24h
read-ethers
bogus-nxdomain=212.82.32.48
dhcp-option=252,"\n"
dhcp-option=121,...
dhcp-option=3,192.168.0.1
mx-host=...



I have included everything but truncated some entries where the info is 
unlikely to be relevant. Some things are historical and probably could 
be removed but they are not the issue.


I have tried various combinations of dhcp-range and dhcp-host and I have 
tried it without the enable-ra.


I have a firewall in place that allows ipv6 on 546/7, which is needed 
anyway for the ISP side to work. I log dropped packets. I do have a rule 
for accepting broadcast packets for dhcpv4 but I am not sure if it is 
needed, given that 67/8 are open anyway:


-

-A INPUT -i enp3s0 -p udp -m addrtype --src-type UNSPEC --dst-type 
BROADCAST --dport 67 -j ACCEPT
-A In-from-main-lan -i enp3s0 -s 192.168.0.0/24 -p tcp -m multiport 
--dports 53,67,68,123 -j ACCEPT


-

The dhcpcd on a client logs that it is soliciting a DHCPv6 lease but all 
I get is either a SLAAC address or just local link if I have disabled 
slaac. Using tcpdump I can see the dhcpv6 requests on the router's LAN 
interface but there is no response. There are no dropped packets either. 
Using lsof I cannot see that dnsmasq is listening on 547 but then I 
cannot see it listening for DHCPv4 either.


My instinct suggests a routing problem? I know this can cause packets to 
simply disappear. The DHCPv6 request appears to be multicast to ff08. 
The routing table on the router is:


-

2001:8b0:17a2::/64 dev enp3s0 proto dhcp metric 1002 pref medium
unreachable 2001:8b0:17a2::/48 dev lo proto dhcp metric 1001 pref medium
fe80::203:97ff:fe41:c000 dev ppp0 proto kernel metric 256 pref medium
fe80::b47c:2ce7:fc94:2eb0 dev ppp0 proto kernel metric 256 pref medium
fe80::/64 dev enp3s0 proto kernel metric 256 pref medium
fe80::/64 dev enp4s0 proto kernel metric 256 pref medium
default via fe80::203:97ff:fe41:c000 dev ppp0 proto ra metric 1006 pref 
medium




I don't have multicast forwarding enabled but I dont think that is 
relevant. I am not doing anything explicit with the ipv6 routes - as I 
understand it, they sort themselves out?


I would be very grateful if anyone can help. I have been searching 
google for clues for weeks now to little avail. If you need any more 
info I can provide it.


Thanks,

Robert Sharp






I think you probably need start and end addresses in the dhcp range

dhcp-range=::1,::400,constructor:enp3s0,24h

without a range of addresses, dnsmasq can't lease addresses and will 
only do stateless DHCPv6 and RA.


There's loads more information out there that will help if you set 
--log-dhcp in your dnsmasq config and look in the syslog. That will tell 
you is dnsmasq has managed to construct an actual dhcp range from the 
address on enp3s0 and allow you to see if it's getting SOLICIT packets 
and what it's doing in response.


The output from ip addr show dev enp3s0 would be useful too. Look at the 
address, prefix length and lifetimes.



Simon.

___
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] dhcp-script and netboot pi

[Simon Kelley]

On 25/02/2024 23:24, Carl Karsten wrote:

Either dhcp-script isn't doing what it is expected, or I'd like it to do more.

I am netbooting raspberry pi.  so some dhcp client in the pi firmware
get's an IP and netboot params, then tftp client gets files.

the dhcp traffic happens and is shown in the logs, but not dhcp-script:

sudo journalctl --follow -u dnsmasq.service
Feb 25 16:49:44 base dnsmasq-dhcp[47924]: DHCPDISCOVER(eth-local)
b8:27:eb:2f:5d:08
Feb 25 16:49:44 base dnsmasq-dhcp[47924]: DHCPOFFER(eth-local)
10.21.0.102 b8:27:eb:2f:5d:08
Feb 25 16:49:50 base dnsmasq-tftp[47924]: file /srv/tftp/bootsig.bin
not found for 10.21.0.102
Feb 25 16:49:50 base dnsmasq-tftp[47924]: sent /srv/tftp/bootcode.bin
to 10.21.0.102
Feb 25 16:49:50 base dnsmasq-dhcp[47924]: DHCPDISCOVER(eth-local)
b8:27:eb:2f:5d:08
Feb 25 16:49:50 base dnsmasq-dhcp[47924]: DHCPOFFER(eth-local)
10.21.0.102 b8:27:eb:2f:5d:08
Feb 25 16:49:50 base dnsmasq-tftp[47924]: error 0 Early terminate
received from 10.21.0.102
Feb 25 16:49:50 base dnsmasq-tftp[47924]: failed sending
/srv/tftp/042f5d08/start.elf to 10.21.0.102
Feb 25 16:49:50 base dnsmasq-tftp[47924]: file
/srv/tftp/042f5d08/autoboot.txt not found for 10.21.0.102
Feb 25 16:49:50 base dnsmasq-tftp[47924]: error 0 Early terminate
received from 10.21.0.102
Feb 25 16:49:50 base dnsmasq-tftp[47924]: failed sending
/srv/tftp/042f5d08/start.elf to 10.21.0.102
Feb 25 16:49:50 base dnsmasq-tftp[47924]: sent
/srv/tftp/042f5d08/config.txt to 10.21.0.102

log from
https://github.com/CarlFK/pici/blob/main/ansible/roles/site/files/pib/pistat/scripts/send_stat.py#L83

Namespace(action='tftp', mac='52476', ip='10.21.0.102',
hostname='/srv/tftp/bootcode.bin') dsh='(none)'
Namespace(action='tftp', mac='2545', ip='10.21.0.102',
hostname='/srv/tftp/042f5d08/config.txt') dsh='(none)'
Namespace(action='tftp', mac='2979264', ip='10.21.0.102',
hostname='/srv/tftp/042f5d08/start.elf') dsh='(none)'

I suspect the problem is with the client not DHCPREQUEST and so the
server doesn't ACK and thus I guess an IP hasn't actually be
allocated, thus no "add" event has happened which calls the script.
if this is the case, can we add an "offer" action?



You're right that the script actions are triggered by changes in the 
DHCP lease database, and DISCOVER/OFFER doesn't change the database so 
there's no action. Because of the link with the lease database and the 
lack of a lease at OFFER stage, adding a new action there is severely 
non trivial.


I'd suggest that the the Pi netboot code is pretty buggy: a client 
shouldn't use IP address until it gets a lease, and it doesn't get the 
lease until it gets a DHCPACK message. It's perfectly possible to have a 
two-message interaction: just set the rapid-commit option in the 
DISCOVER packet and the server will go straight to DHCPACK and 
committing a lease. Buggy netboot code is far from uncommon, in my 
experience.


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] Fwd: no-ping

[Simon Kelley]

OK I committed to patch to this effect.


https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=9adbf009a6df76d9ae5be2b93a90e210e9aa8216


Cheers,

Simon.


On 21/02/2024 00:13, Martin Ivičič wrote:

I tested all the combinations:
  - just --no-ping: dnsmasq: process is missing required capability 
NET_ADMIN
  - --no-ping + --dhcp-broadcast=mgmt: dnsmasq: process is missing 
required capability NET_ADMIN

  - --no-ping + --dhcp-broadcast: works fine

Best regards,
Martin

On Wed, Feb 21, 2024 at 1:07 AM Simon Kelley <mailto:si...@thekelleys.org.uk>> wrote:


That would work, I think. Please try it and report back.

Simon.

On 20/02/2024 23:53, Martin Ivičič wrote:
 > Our intent is to run tests in CI where we can't use root user or
set any
 > capabilities (eventually we'll be running with
 > --dhcp-alternate-port=1067,1068 as well)
 > What do you think about the following?
 >
 > diff --git a/src/dnsmasq.c b/src/dnsmasq.c
 > index 30fb419..5969e01 100644
 > --- a/src/dnsmasq.c
 > +++ b/src/dnsmasq.c
 > @@ -315,7 +315,8 @@ int main (int argc, char **argv)
 >   #   ifdef HAVE_LINUX_NETWORK
 >         if (!option_bool(OPT_NO_PING))
 >      need_cap_net_raw = 1;
 > -      need_cap_net_admin = 1;
 > +      if (!option_bool(OPT_NO_PING) || daemon->force_broadcast
== NULL
 > || daemon->force_broadcast->list != NULL)
 > +        need_cap_net_admin = 1;
 >   #   endif
 >       }
 >
 > Best regards,
 > Martin
 >
 > On Tue, Feb 20, 2024 at 10:21 AM Simon Kelley
mailto:si...@thekelleys.org.uk>
 > <mailto:si...@thekelleys.org.uk
<mailto:si...@thekelleys.org.uk>>> wrote:
 >
 >     Ah, this is working because you include --dhcp-broadcast,
which avoids
 >     the ARP-cache access.
 >
 >     I'm not clear why you want to avoid CAP_NET_ADMIN, but a
correct patch
 >     to do that would only not set need_cap_netadmin when
--broadcast is
 >     set,
 >     and only when it's set unconditionally, without tags.
 >
 >     Cheers,
 >
 >     Simon.
 >
 >
 >     On 20/02/2024 00:50, Martin Ivičič wrote:
 >      > I'm currently running dnsmasq (with my patch applied)
using the
 >     following script and everything seems to work fine actually - no
 >     errors reported.
 >      > (I have only added CAP_NET_BIND_SERVICE in order to be able to
 >     bind to port 67.)
 >      >
 >      > #!/bin/bash
 >      > set -euo pipefail
 >      > SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" &>
/dev/null
 >     && pwd )"
 >      >
 >      > PID_FILE=$SCRIPT_DIR/dnsmasq.pid
 >      >
 >      > dnsmasq \
 >      > --pid-file=$PID_FILE \
 >      > --dhcp-leasefile=$SCRIPT_DIR/dnsmasq.leases \
 >      > --strict-order \
 >      > --bind-interfaces \
 >      > --dhcp-authoritative \
 >      > --no-ping \
 >      > --dhcp-broadcast \
 >      > --port=0  \
 >      > --conf-file= \
 >      > --no-hosts  \
 >      > --interface=br-mgmt \
 >      > --listen-address=10.0.0.254 \
 >      >
--dhcp-range=net:mgmt,10.0.0.1,10.0.0.250,255.255.255.0,10.0.0.255 \
 >      > --dhcp-option=mgmt,option:router \
 >      > --dhcp-host=52:54:00:00:00:01,id:*,net:mgmt,10.0.0.1 \
 >      > --dhcp-host=52:54:00:00:00:02,id:*,net:mgmt,10.0.0.2 \
 >      > --dhcp-host=52:54:00:00:00:03,id:*,net:mgmt,10.0.0.3 \
 >      > \
 >      > --interface=br-dth \
 >      > --listen-address=10.0.1.254 \
 >      >
--dhcp-range=net:dth,10.0.1.1,10.0.1.250,255.255.255.0,10.0.1.255 \
 >      > --dhcp-option=dth,option:router \
 >      >
 >   
  --dhcp-option=dth,option:classless-static-route,10.235.0.0/16,10.0.1.254 <http://10.235.0.0/16,10.0.1.254> <http://10.235.0.0/16,10.0.1.254 <http://10.235.0.0/16,10.0.1.254>>  <http://10.235.0.0/16,10.0.1.254 <http://10.235.0.0/16,10.0.1.254> <http://10.235.0.0/16,10.0.1.254 <http://10.235.0.0/16,10.0.1.254>>>  \

 >      > --dhcp-host=52:54:00:00:01:01,id:*,net:dth,10.0.1.1 \
 >      > --dhcp-host=52:54:00:00:01:02,id:*,net:dth,10.0.1.2 \
 >      > --dhcp-host=52:54:00:00:01:03,id:*,net:dth,10.0.1.3 \
 >      > \
 >      > --interface=br-inet \
 >      > --listen-address=10.0.2.254 \
 >      >
--dhcp-range=net:inet,10.0.2.1,10.0.2.250,255.255.

Re: [Dnsmasq-discuss] erroneously filtering A records after calling "SetFilterA false" over dbus

[Simon Kelley]

On 20/02/2024 19:06, Clayton Craft via Dnsmasq-discuss wrote:

Using dnsmasq 2.90 + the patch to fix the infinite loop, it seems like filtering is 
applied when calling e.g., "SetFilterA false" over dbus. In the script below, 
the first lookup succeeds but subsequent lookups after the initial application of the 
filter fail to return anything.



It looks like I had a severe attack of "it compiles, ship it!" when the 
RR filtering code got generalised to filter any RR type, and broke the 
DBus methods entirely.


https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=4c590320ec5442d431c5e059c890077ec6d67575

Should fix things, and I did test this time :)


Cheers,

Simon.





#!/bin/sh

dnsmasq -p 5353 --enable-dbus=uk.org.thekelleys.dnsmasq

while true; do
 echo "Trying..."
 dig @127.0.0.1 -p 5353 +nocmd +noall +answer postmarketos.org

 busctl call uk.org.thekelleys.dnsmasq \
 /uk/org/thekelleys/dnsmasq \
 uk.org.thekelleys.dnsmasq \
 SetFilterA b false

 busctl call uk.org.thekelleys.dnsmasq \
 /uk/org/thekelleys/dnsmasq \
 uk.org.thekelleys.dnsmasq \
 ClearCache

 echo "Trying again..."

 dig @127.0.0.1 -p 5353 +nocmd +noall +answer postmarketos.org
 echo "Done"

done


The output is something like:

enchilada:~$ doas ./foo.sh
Trying...
postmarketos.org.   5   IN  A   95.216.1.254
Trying again...
Done
Trying...
Trying again...
Done


dnsmasq logs this:

[Feb 20 11:03:28] daemon dnsmasq[30672]: query[A] postmarketos.org from 
127.0.0.1
[Feb 20 11:03:28] daemon dnsmasq[30672]: forwarded postmarketos.org to 1.1.1.1
[Feb 20 11:03:28] daemon dnsmasq[30672]: config postmarketos.org is NODATA-IPv4


I can try to bisect this, but thought I'd ask on here if this looks familiar 
since bisecting dnsmasq isn't as easy :)


-Clayton

___
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] Fwd: no-ping

[Simon Kelley]

That would work, I think. Please try it and report back.

Simon.

On 20/02/2024 23:53, Martin Ivičič wrote:
Our intent is to run tests in CI where we can't use root user or set any 
capabilities (eventually we'll be running with 
--dhcp-alternate-port=1067,1068 as well)

What do you think about the following?

diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 30fb419..5969e01 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -315,7 +315,8 @@ int main (int argc, char **argv)
  #   ifdef HAVE_LINUX_NETWORK
        if (!option_bool(OPT_NO_PING))
     need_cap_net_raw = 1;
-      need_cap_net_admin = 1;
+      if (!option_bool(OPT_NO_PING) || daemon->force_broadcast == NULL 
|| daemon->force_broadcast->list != NULL)

+        need_cap_net_admin = 1;
  #   endif
      }

Best regards,
Martin

On Tue, Feb 20, 2024 at 10:21 AM Simon Kelley <mailto:si...@thekelleys.org.uk>> wrote:


Ah, this is working because you include --dhcp-broadcast, which avoids
the ARP-cache access.

I'm not clear why you want to avoid CAP_NET_ADMIN, but a correct patch
to do that would only not set need_cap_netadmin when --broadcast is
set,
and only when it's set unconditionally, without tags.

Cheers,

Simon.


On 20/02/2024 00:50, Martin Ivičič wrote:
 > I'm currently running dnsmasq (with my patch applied) using the
following script and everything seems to work fine actually - no
errors reported.
 > (I have only added CAP_NET_BIND_SERVICE in order to be able to
bind to port 67.)
 >
 > #!/bin/bash
 > set -euo pipefail
 > SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" &> /dev/null
&& pwd )"
 >
 > PID_FILE=$SCRIPT_DIR/dnsmasq.pid
 >
 > dnsmasq \
 > --pid-file=$PID_FILE \
 > --dhcp-leasefile=$SCRIPT_DIR/dnsmasq.leases \
 > --strict-order \
 > --bind-interfaces \
 > --dhcp-authoritative \
 > --no-ping \
 > --dhcp-broadcast \
 > --port=0  \
 > --conf-file= \
 > --no-hosts  \
 > --interface=br-mgmt \
 > --listen-address=10.0.0.254 \
 > --dhcp-range=net:mgmt,10.0.0.1,10.0.0.250,255.255.255.0,10.0.0.255 \
 > --dhcp-option=mgmt,option:router \
 > --dhcp-host=52:54:00:00:00:01,id:*,net:mgmt,10.0.0.1 \
 > --dhcp-host=52:54:00:00:00:02,id:*,net:mgmt,10.0.0.2 \
 > --dhcp-host=52:54:00:00:00:03,id:*,net:mgmt,10.0.0.3 \
 > \
 > --interface=br-dth \
 > --listen-address=10.0.1.254 \
 > --dhcp-range=net:dth,10.0.1.1,10.0.1.250,255.255.255.0,10.0.1.255 \
 > --dhcp-option=dth,option:router \
 >
--dhcp-option=dth,option:classless-static-route,10.235.0.0/16,10.0.1.254 
<http://10.235.0.0/16,10.0.1.254>  <http://10.235.0.0/16,10.0.1.254 
<http://10.235.0.0/16,10.0.1.254>>  \
 > --dhcp-host=52:54:00:00:01:01,id:*,net:dth,10.0.1.1 \
 > --dhcp-host=52:54:00:00:01:02,id:*,net:dth,10.0.1.2 \
 > --dhcp-host=52:54:00:00:01:03,id:*,net:dth,10.0.1.3 \
 > \
 > --interface=br-inet \
 > --listen-address=10.0.2.254 \
 > --dhcp-range=net:inet,10.0.2.1,10.0.2.250,255.255.255.0,10.0.2.255 \
 > --dhcp-option=inet,option:router,10.0.2.254 \
 > --dhcp-host=52:54:00:00:02:01,id:*,net:inet,10.0.2.1 \
 > --dhcp-host=52:54:00:00:02:02,id:*,net:inet,10.0.2.2 \
 > --dhcp-host=52:54:00:00:02:03,id:*,net:inet,10.0.2.3 \
 > \
 > --no-daemon
 >
 >
 > this is the output:
 >
 > dnsmasq: started, version 2.90deb2-1-g1ed783b DNS disabled
 > dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus
no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-nftset
auth no-cryptohash no-DNSSEC loop-detect inotify dumpfile
 > dnsmasq-dhcp: DHCP, IP range 10.0.2.1 -- 10.0.2.250, lease time 1h
 > dnsmasq-dhcp: DHCP, IP range 10.0.1.1 -- 10.0.1.250, lease time 1h
 > dnsmasq-dhcp: DHCP, IP range 10.0.0.1 -- 10.0.0.250, lease time 1h
 > dnsmasq-dhcp: DHCPDISCOVER(br-mgmt) 52:54:00:00:00:01
 > dnsmasq-dhcp: DHCPOFFER(br-mgmt) 10.0.0.1 52:54:00:00:00:01
 > dnsmasq-dhcp: DHCPDISCOVER(br-dth) 52:54:00:00:01:01
 > dnsmasq-dhcp: DHCPOFFER(br-dth) 10.0.1.1 52:54:00:00:01:01
 > dnsmasq-dhcp: DHCPDISCOVER(br-inet) 52:54:00:00:02:01
 > dnsmasq-dhcp: DHCPOFFER(br-inet) 10.0.2.1 52:54:00:00:02:01
 > dnsmasq-dhcp: DHCPREQUEST(br-mgmt) 10.0.0.1 52:54:00:00:00:01
 > dnsmasq-dhcp: DHCPACK(br-mgmt) 10.0.0.1 52:54:00:00:00:01
 > dnsmasq-dhcp: DHCPREQUEST(br-inet) 10.0.2.1 52:54:00:00:02:01
 > dnsmasq-dhcp: DHCPACK(br-inet) 10.0.2.1 52:54:00:00:02:01
 > dnsmasq-dhcp: DHCPREQUEST(br-dth) 10.0.1.1 52:54:00:00:01:01
 > dnsmasq-dhcp: DHCPACK(br-dth) 10.0.1.1 52:54:00:00:01:01
 >
 >
 > 

Re: [Dnsmasq-discuss] Similar to bfefd6e38c6e, fix error introduced in 51471cafa5a4

[Simon Kelley]

Patch applied. Thanks.

Simon.


On 20/02/2024 08:32, renmingshuai via Dnsmasq-discuss wrote:

 From 81ed4df0eb1d70fc1ac5f94b5839f8cb45602ed0 Mon Sep 17 00:00:00 2001

From: renmingshuai 

Date: Tue, 20 Feb 2024 16:13:11 +0800

Subject: [PATCH] Fix error introduced in

51471cafa5a4fa44d6fe490885d9910bd72a5907

Signed-off-by: renmingshuai 

---

src/dnssec.c | 4 ++--

1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/dnssec.c b/src/dnssec.c

index ed2f53f..291b43f 100644

--- a/src/dnssec.c

+++ b/src/dnssec.c

@@ -1547,7 +1547,7 @@ static int prove_non_existence_nsec3(struct 
dns_header *header, size_t plen, uns


    nsecs[i] = NULL; /* Speculative, will be restored if OK. */

    if (!(p = skip_name(nsec3p, header, plen, 15)))

-   return 0; /* bad packet */

+   return DNSSEC_FAIL_BADPACKET; /* bad packet */

    p += 10; /* type, class, TTL, rdlen */

@@ -1640,7 +1640,7 @@ static int prove_non_existence_nsec3(struct 
dns_header *header, size_t plen, uns


    if (!wildname)

  {

    if (!(wildcard = strchr(next_closest, '.')) || wildcard == 
next_closest)


-   return 0;

+   return DNSSEC_FAIL_NONSEC;

    wildcard--;

    *wildcard = '*';

--

2.33.0


___
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] Fwd: no-ping

[Simon Kelley]

Ah, this is working because you include --dhcp-broadcast, which avoids 
the ARP-cache access.


I'm not clear why you want to avoid CAP_NET_ADMIN, but a correct patch 
to do that would only not set need_cap_netadmin when --broadcast is set, 
and only when it's set unconditionally, without tags.


Cheers,

Simon.


On 20/02/2024 00:50, Martin Ivičič wrote:

I'm currently running dnsmasq (with my patch applied) using the following 
script and everything seems to work fine actually - no errors reported.
(I have only added CAP_NET_BIND_SERVICE in order to be able to bind to port 67.)

#!/bin/bash
set -euo pipefail
SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )"

PID_FILE=$SCRIPT_DIR/dnsmasq.pid

dnsmasq \
--pid-file=$PID_FILE \
--dhcp-leasefile=$SCRIPT_DIR/dnsmasq.leases \
--strict-order \
--bind-interfaces \
--dhcp-authoritative \
--no-ping \
--dhcp-broadcast \
--port=0  \
--conf-file= \
--no-hosts  \
--interface=br-mgmt \
--listen-address=10.0.0.254 \
--dhcp-range=net:mgmt,10.0.0.1,10.0.0.250,255.255.255.0,10.0.0.255 \
--dhcp-option=mgmt,option:router \
--dhcp-host=52:54:00:00:00:01,id:*,net:mgmt,10.0.0.1 \
--dhcp-host=52:54:00:00:00:02,id:*,net:mgmt,10.0.0.2 \
--dhcp-host=52:54:00:00:00:03,id:*,net:mgmt,10.0.0.3 \
\
--interface=br-dth \
--listen-address=10.0.1.254 \
--dhcp-range=net:dth,10.0.1.1,10.0.1.250,255.255.255.0,10.0.1.255 \
--dhcp-option=dth,option:router \
--dhcp-option=dth,option:classless-static-route,10.235.0.0/16,10.0.1.254  
<http://10.235.0.0/16,10.0.1.254>  \
--dhcp-host=52:54:00:00:01:01,id:*,net:dth,10.0.1.1 \
--dhcp-host=52:54:00:00:01:02,id:*,net:dth,10.0.1.2 \
--dhcp-host=52:54:00:00:01:03,id:*,net:dth,10.0.1.3 \
\
--interface=br-inet \
--listen-address=10.0.2.254 \
--dhcp-range=net:inet,10.0.2.1,10.0.2.250,255.255.255.0,10.0.2.255 \
--dhcp-option=inet,option:router,10.0.2.254 \
--dhcp-host=52:54:00:00:02:01,id:*,net:inet,10.0.2.1 \
--dhcp-host=52:54:00:00:02:02,id:*,net:inet,10.0.2.2 \
--dhcp-host=52:54:00:00:02:03,id:*,net:inet,10.0.2.3 \
\
--no-daemon


this is the output:

dnsmasq: started, version 2.90deb2-1-g1ed783b DNS disabled
dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN 
DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-nftset auth no-cryptohash 
no-DNSSEC loop-detect inotify dumpfile
dnsmasq-dhcp: DHCP, IP range 10.0.2.1 -- 10.0.2.250, lease time 1h
dnsmasq-dhcp: DHCP, IP range 10.0.1.1 -- 10.0.1.250, lease time 1h
dnsmasq-dhcp: DHCP, IP range 10.0.0.1 -- 10.0.0.250, lease time 1h
dnsmasq-dhcp: DHCPDISCOVER(br-mgmt) 52:54:00:00:00:01
dnsmasq-dhcp: DHCPOFFER(br-mgmt) 10.0.0.1 52:54:00:00:00:01
dnsmasq-dhcp: DHCPDISCOVER(br-dth) 52:54:00:00:01:01
dnsmasq-dhcp: DHCPOFFER(br-dth) 10.0.1.1 52:54:00:00:01:01
dnsmasq-dhcp: DHCPDISCOVER(br-inet) 52:54:00:00:02:01
dnsmasq-dhcp: DHCPOFFER(br-inet) 10.0.2.1 52:54:00:00:02:01
dnsmasq-dhcp: DHCPREQUEST(br-mgmt) 10.0.0.1 52:54:00:00:00:01
dnsmasq-dhcp: DHCPACK(br-mgmt) 10.0.0.1 52:54:00:00:00:01
dnsmasq-dhcp: DHCPREQUEST(br-inet) 10.0.2.1 52:54:00:00:02:01
dnsmasq-dhcp: DHCPACK(br-inet) 10.0.2.1 52:54:00:00:02:01
dnsmasq-dhcp: DHCPREQUEST(br-dth) 10.0.1.1 52:54:00:00:01:01
dnsmasq-dhcp: DHCPACK(br-dth) 10.0.1.1 52:54:00:00:01:01


inside the VM:

root@localhost:~# ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet127.0.0.1/8  <http://127.0.0.1/8>  scope host lo
        valid_lft forever preferred_lft forever
2: enp0s1:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
     link/ether 52:54:00:00:00:01 brd ff:ff:ff:ff:ff:ff
     inet10.0.0.1/24  <http://10.0.0.1/24>  metric 1024 brd 10.0.0.255 scope 
global dynamic enp0s1
        valid_lft 3525sec preferred_lft 3525sec
3: enp0s2:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
     link/ether 52:54:00:00:01:01 brd ff:ff:ff:ff:ff:ff
     inet10.0.1.1/24  <http://10.0.1.1/24>  metric 1024 brd 10.0.1.255 scope 
global dynamic enp0s2
        valid_lft 3525sec preferred_lft 3525sec
4: enp0s3:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
     link/ether 52:54:00:00:02:01 brd ff:ff:ff:ff:ff:ff
     inet10.0.2.1/24  <http://10.0.2.1/24>  metric 1024 brd 10.0.2.255 scope 
global dynamic enp0s3
        valid_lft 3525sec preferred_lft 3525sec


Best regards,
Martin


On Tue, Feb 20, 2024 at 1:46 AM Simon Kelley <mailto:si...@thekelleys.org.uk>> wrote:


If you're doing DHCP, even if you're not sending ICMP ping packets, you
still need CAP_NET_ADMIN, because the DHCP server has to be able to
manipulate the ARP table.

I guess you're starting dnsmasq without CAP_NET_ADMIN, dnsmasq is
determining that it needs CPA_NET_ADMIN to run the DHCP server, and
erroring out because it doesn't have it.


Simon.


On 19/02/2024 15:32, Martin Ivičič wrote:
 > Hello,
 >
 > I might have stu

Re: [Dnsmasq-discuss] Fwd: no-ping

[Simon Kelley]

If you're doing DHCP, even if you're not sending ICMP ping packets, you 
still need CAP_NET_ADMIN, because the DHCP server has to be able to 
manipulate the ARP table.


I guess you're starting dnsmasq without CAP_NET_ADMIN, dnsmasq is 
determining that it needs CPA_NET_ADMIN to run the DHCP server, and 
erroring out because it doesn't have it.



Simon.


On 19/02/2024 15:32, Martin Ivičič wrote:

Hello,

I might have stumbled upon a minor bug in dnsmasq which causes NET_ADMIN 
capability being required even if it's actually not needed (according to 
provided command line arguments).


diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 30fb419..cef42f6 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -313,9 +313,10 @@ int main (int argc, char **argv)
      {
        dhcp_init();
  #   ifdef HAVE_LINUX_NETWORK
-      if (!option_bool(OPT_NO_PING))
-   need_cap_net_raw = 1;
-      need_cap_net_admin = 1;
+      if (!option_bool(OPT_NO_PING)) {
+        need_cap_net_raw = 1;
+        need_cap_net_admin = 1;
+      }
  #   endif
      }

Without this patch, with following arguments, dnsmasq ends with 
"dnsmasq: process is missing required capability NET_ADMIN"


src/dnsmasq  \
--strict-order \
--bind-interfaces \
--interface=br-mgmt \
--listen-address=10.0.0.254 \
--dhcp-range=10.0.0.1,10.0.0.250 \
--dhcp-authoritative \
--no-ping \
--dhcp-broadcast \
--port=0 \
--conf-file= \
--pid-file=/tmp/dnsmasq.pid \
--dhcp-leasefile=/tmp/dnsmasq.leases \
--dhcp-no-override \
--no-daemon

After applying the patch dnsmasq starts and runs fine.

Best regards,
Martin


___
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] rr_on_list stuck in infinite loop, dnsmasq unresponsive

[Simon Kelley]

Wow, excellent bug report, thank you.

Took me straight to the stupid error.

src/dbus.c around line 834. The code block controlled by "if (!done)" 
should include the line "done = 1;" Same thing below for filter .


I'll push the patch directly.

Cheers,

Simon.


On 19/02/2024 21:29, Clayton Craft wrote:

It seems like sometimes the rrlist given to rr_on_list can be a circular linked
list:

 0xbbf57044 in rr_on_list (list=0xbbfe1990 , rr=5) at 
util.c:120
 120   while (list)
 (gdb) p list
 $1 = (struct rrlist *) 0xbbfe1990 
 (gdb) p list.next
 $3 = (struct rrlist *) 0xbbfe1980 
 (gdb) p list.next.next
 $4 = (struct rrlist *) 0xbbfe1990 

This causes rr_on_list to get stuck in an infinite loop, and dnsmasq to consume
100% CPU and be completely unresponsive. I generated a flamegraph of dnsmasq and
found that it was stuck here, then attached gdb to confirm.

The conditions to trigger this aren't well understood by me... it seems to
happen when we use dnsmasq's dbus interface to toggle filtering ("set_filter A
bool"). But I've had trouble reproducing it manually. We hit it a lot when using
a NetworkManager dispatcher script to apply filtering in dnsmasq conditionally.

The issue does *not* go away when I revert 3de7289.

If rrlist is a circular list, then rr_on_list should have an escape if head was
already visited or ? I don't understand the dnsmasq code enough to have any real
suggestions for how to proceed with fixing this :)

Full bt:

(gdb) bt full
#0  0xd9077028 in rr_on_list (
 list=0xd9101990 , rr=5) at util.c:120
No locals.
#1  0xd90cd718 in rrfilter (header=0xa56e3580,
 plen=0xf663bc80, mode=2) at rrfilter.c:233
 pstart = 0xa56e35ac "\300\f"
 type = 5
 class = 1
 rrs = 0xa5566b40
 rr_sz = 12
 p = 0xa56e35c0 "\3008"
 rr_found = 0
 i = 0
 rdlen = 8
 qtype = 28
 qclass = 1
 chop_an = 0
 chop_ns = 0
 chop_ar = 0
#2  0xd9089c40 in process_reply (
 header=0xa56e3580, now=1708377610,
 cache_secure=0, bogusanswer=0, ad_reqd=0, do_bit=0, added_pheader=0, 
query_source=0xa56d1240,
 limit=0xa56e3a50 "", ede=-1) at forward.c:848
 pheader = 0x0
 sizep = 0x0
 ipsets = 0x0
 nftsets = 0x0
 is_sign = 0
 rcode = 0
 plen = 281473457238616
#3  0xd908b68c in return_reply (now=1708377610, forward=0xa56d1240, 
header=0xa56e3580, n=92, status=524288)
 at forward.c:1382
 check_rebind = 0
 no_cache_dnssec = 0
 cache_secure = 0
 bogusanswer = 0
 nn = 187650762387748
 ede = -1
#4  0xd908b21c in reply_query (fd=10, now=1708377610) at forward.c:1301
 header = 0xa56e3580
 serveraddr = {sa = {sa_family = 2, sa_data = 
"\0005\300\000\000\001\000\000\000\000\000\000\000"}, in = {
 sin_family = 2, sin_port = 13568, sin_addr = {s_addr = 16777408}, sin_zero = 
"\000\000\000\000\000\000\000"},
   in6 = {sin6_family = 2, sin6_port = 13568, sin6_flowinfo = 16777408, 
sin6_addr = {__in6_union = {
 __s6_addr = 
"\000\000\000\000\000\000\000\000\224\202\t٪\252\000", __s6_addr16 = {0, 0, 0, 
0, 33428, 55561,
   43690, 0}, __s6_addr32 = {0, 0, 3641279124, 43690}}}, 
sin6_scope_id = 0}}
 forward = 0xa56d1240
 addrlen = 16
 n = 92
 server = 0xa5566e70
 hash = 0xa55059b0
 first = 32
 last = 33
 c = 32
#5  0xd90982c4 in check_dns_listeners (now=1708377610) at dnsmasq.c:1831
 serverfdp = 0x0
 listener = 0xe0af57cb29b80071
 rfl = 0xf663bf80
 i = 0
 pipefd = {-653704516, 43690}
#6  0xd9096c84 in main (argc=12, argv=0xf663c1d8) at dnsmasq.c:1269
 timeout = -1
 now = 1708377610
 sigact = {__sa_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, 
sa_mask = {__bits = {0, 187651085026544,
   281473457229824, 281474815476000, 281473456612332, 
187651085026504, 281473457229824, 281474815476032,
   281473456612716, 187651085026504, 281473457238016, 
281474815476096, 281473456885404, 281473457238016,
   281474815476184, 224}}, sa_flags = 0, sa_restorer = 0xa56eb000 
}
 if_tmp = 0x0
 piperead = 7
 pipefd = {7, 8}
 err_pipe = {0, -1}
 ent_pw = 0xa56eb4e0 
 script_uid = 0
 script_gid = 0
 gp = 0xa56eb4a0 
 i = 20
 max_fd = 1024
 baduser = 0x0
 log_err = 0

-Clayton


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


___

Re: [Dnsmasq-discuss] rr_on_list stuck in infinite loop, dnsmasq unresponsive

[Simon Kelley]

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=89aad014685161318318737dc0e350ee4dae982d

should fix this.


Simon.

On 19/02/2024 23:16, Simon Kelley wrote:

Wow, excellent bug report, thank you.

Took me straight to the stupid error.

src/dbus.c around line 834. The code block controlled by "if (!done)" 
should include the line "done = 1;" Same thing below for filter .


I'll push the patch directly.

Cheers,

Simon.


On 19/02/2024 21:29, Clayton Craft wrote:
It seems like sometimes the rrlist given to rr_on_list can be a 
circular linked

list:

 0xbbf57044 in rr_on_list (list=0xbbfe1990 , 
rr=5) at util.c:120

 120   while (list)
 (gdb) p list
 $1 = (struct rrlist *) 0xbbfe1990 
 (gdb) p list.next
 $3 = (struct rrlist *) 0xbbfe1980 
 (gdb) p list.next.next
 $4 = (struct rrlist *) 0xbbfe1990 

This causes rr_on_list to get stuck in an infinite loop, and dnsmasq 
to consume
100% CPU and be completely unresponsive. I generated a flamegraph of 
dnsmasq and

found that it was stuck here, then attached gdb to confirm.

The conditions to trigger this aren't well understood by me... it 
seems to
happen when we use dnsmasq's dbus interface to toggle filtering 
("set_filter A
bool"). But I've had trouble reproducing it manually. We hit it a lot 
when using
a NetworkManager dispatcher script to apply filtering in dnsmasq 
conditionally.


The issue does *not* go away when I revert 3de7289.

If rrlist is a circular list, then rr_on_list should have an escape if 
head was
already visited or ? I don't understand the dnsmasq code enough to 
have any real

suggestions for how to proceed with fixing this :)

Full bt:

(gdb) bt full
#0  0xd9077028 in rr_on_list (
 list=0xd9101990 , rr=5) at util.c:120
No locals.
#1  0xd90cd718 in rrfilter (header=0xa56e3580,
 plen=0xf663bc80, mode=2) at rrfilter.c:233
 pstart = 0xa56e35ac "\300\f"
 type = 5
 class = 1
 rrs = 0xa5566b40
 rr_sz = 12
 p = 0xa56e35c0 "\3008"
 rr_found = 0
 i = 0
 rdlen = 8
 qtype = 28
 qclass = 1
 chop_an = 0
 chop_ns = 0
 chop_ar = 0
#2  0xd9089c40 in process_reply (
 header=0xa56e3580, now=1708377610,
 cache_secure=0, bogusanswer=0, ad_reqd=0, do_bit=0, 
added_pheader=0, query_source=0xa56d1240,

 limit=0xa56e3a50 "", ede=-1) at forward.c:848
 pheader = 0x0
 sizep = 0x0
 ipsets = 0x0
 nftsets = 0x0
 is_sign = 0
 rcode = 0
 plen = 281473457238616
#3  0xd908b68c in return_reply (now=1708377610, 
forward=0xa56d1240, header=0xa56e3580, n=92, status=524288)

 at forward.c:1382
 check_rebind = 0
 no_cache_dnssec = 0
 cache_secure = 0
 bogusanswer = 0
 nn = 187650762387748
 ede = -1
#4  0xd908b21c in reply_query (fd=10, now=1708377610) at 
forward.c:1301

 header = 0xa56e3580
 serveraddr = {sa = {sa_family = 2, sa_data = 
"\0005\300\000\000\001\000\000\000\000\000\000\000"}, in = {
 sin_family = 2, sin_port = 13568, sin_addr = {s_addr = 
16777408}, sin_zero = "\000\000\000\000\000\000\000"},
   in6 = {sin6_family = 2, sin6_port = 13568, sin6_flowinfo = 
16777408, sin6_addr = {__in6_union = {
 __s6_addr = 
"\000\000\000\000\000\000\000\000\224\202\t٪\252\000", __s6_addr16 = 
{0, 0, 0, 0, 33428, 55561,
   43690, 0}, __s6_addr32 = {0, 0, 3641279124, 
43690}}}, sin6_scope_id = 0}}

 forward = 0xa56d1240
 addrlen = 16
 n = 92
 server = 0xa5566e70
 hash = 0xa55059b0
 first = 32
 last = 33
 c = 32
#5  0xd90982c4 in check_dns_listeners (now=1708377610) at 
dnsmasq.c:1831

 serverfdp = 0x0
 listener = 0xe0af57cb29b80071
 rfl = 0xf663bf80
 i = 0
 pipefd = {-653704516, 43690}
#6  0xd9096c84 in main (argc=12, argv=0xf663c1d8) at 
dnsmasq.c:1269

 timeout = -1
 now = 1708377610
 sigact = {__sa_handler = {sa_handler = 0x1, sa_sigaction = 
0x1}, sa_mask = {__bits = {0, 187651085026544,
   281473457229824, 281474815476000, 281473456612332, 
187651085026504, 281473457229824, 281474815476032,
   281473456612716, 187651085026504, 281473457238016, 
281474815476096, 281473456885404, 281473457238016,
   281474815476184, 224}}, sa_flags = 0, sa_restorer = 
0xa56eb000 }

 if_tmp = 0x0
 piperead = 7
 pipefd = {7, 8}
 err_pipe = {0, -1}
 ent_pw = 0xa56eb4e0 
 script_uid = 0
 script_gid = 0
 gp = 0xa56eb4a0 
  

Re: [Dnsmasq-discuss] dhcp-ignore with tags from ranges

[Simon Kelley]

On 16/02/2024 13:24, Matthias Lay via Dnsmasq-discuss wrote:


Hi List,

I am trying to set the *dhcp-ignore* option for a single dhcp-range
only. after reading the manpage my setup is like this:

dhcp-range=set:8,22.22.22.1,22.22.22.100
dhcp-ignore=tag:8,tag:!known

this doesnt seem to work. the tags are there and logged, but the
request is not ignored. it works without the "tag:8".

is this a timing problem? set:8 executed after the ignore handling?
any hint how this could be achieved otherwise?


Yes, this is a timing problem: the workflow is

determine tags
ignore is tags permit
use tags to pick dhcp-range, and add tags from that range
use new tag set to pick dhcp options.

does a simple

dhcp-range=tag:!known,22.22.22.1,22.22.22.100

not achieve what you want?

Simon.


thx in advance

Matze


___
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

[Dnsmasq-discuss] Announce: dnsmasq-2.90.

[Simon Kelley]

I've just released 2.90.

The motivation for this a security announcement today of an attack known 
as keytrap, which is a generic attack on all DNSSEC validators - it's a 
failure of the specification rather than of the implementations. If 
DNSSEC validation is enabled, then an attacker who can force a DNS 
server to validate a specially crafted signed domain can use a lot of 
CPU in the validator. This only affects dnsmasq installations with 
DNSSEC enabled.


The solution for dnsmasq is to impose hard limits on a few measures of 
the amount of "work" a DNSSEC validation is taking. The new code 
remembers how close to the limits it has come, and will log that 
information when it receives a SIGUSR1. The default limits have been set 
with significant headroom over the maximums that have been achieved in 
my testing, but the only testing has been done by me, because of embargo 
on the security disclosure. In the event that I've set the limits too 
small, there is a new option that allows them to be overridden. Hitting 
the limits logs an error message.


The security cases which refer to this are CVE-2023-50387 and 
CVE-2023-50868.


I'm aware both that a release is well overdue, and that there are 
outstanding patches and issues which I'd hoped to get to before making a 
release and thus far failed to do so. The security issue has forced my 
hand, so we do at least now have a release. I'll continue working in the 
backlog.


The security fixes are conceptually complex, but they ended up touching 
a lot of code, so backporting them is going to be difficult. I'd 
encourage anyone who can to upgrade rather than backporting.


CHANGELOG below, for reference.

Cheers,

Simon.




version 2.90
Fix reversion in --rev-server introduced in 2.88 which
caused breakage if the prefix length is not exactly divisible
by 8 (IPv4) or 4 (IPv6).

Fix possible SEGV when there server(s) for a particular
domain are configured, but no server which is not qualified
for a particular domain. Thanks to Daniel Danzberger for
spotting this bug.

Set the default maximum DNS UDP packet sice to 1232. This
has been the recommended value since 2020 because it's the
largest value that avoid fragmentation, and fragmentation
is just not reliable on the modern internet, especially
for IPv6. It's still possible to override this with
--edns-packet-max for special circumstances.

Add --no-dhcpv4-interface and --no-dhcpv6-interface for
better control over which inetrfaces are providing DHCP service.

Fix issue with stale caching: After replying with stale data,
dnsmasq sends the query upstream to refresh the cache
asynchronously and sometimes sends the wrong packet: packet
length can be wrong,
and if an EDE marking stale data is added to the answer that can
end up in the query also. This bug only seems to cause problems
when the upstream server is a DOH/DOT proxy. Thanks to Justin He
for the bug report.

Add configurable caching for arbitrary RR-types.

Add --filter-rr option, to filter arbitrary RR-types.
--filter-rr=ANY has a special meaning: it filters the
answers to queries for the ANY RR-type.

Add limits on the resources used to do DNSSEC validation.
DNSSEC introduces a potential CPU DoS, because a crafted domain
can force a validator to a large number of cryptographic
operations whilst attempting to do validation. When using TCP
transport a DNSKEY RRset contain thousands of members and any
RRset can have thousands of signatures. The potential number
of signature validations to follow the RFC for validation
for one RRset is the cross product of the keys and signatures,
so millions. In practice, the actual numbers are much lower,
so attacks can be mitigated by limiting the amount of
cryptographic "work" to a much lower amount. The actual
limits are number a signature validation fails per RRset(20),
number of signature validations and hash computations
per query(200), number of sub-queries  to fetch  DS and DNSKEY
RRsets per query(40), and the number of iterations in a
NSEC3 record(150). These values are sensible, but there is, as  
yet, no standardisation on the values for a "conforming" domain,
so a new option --dnssec-limit is provided should they need to  
be altered. The algorithm to validate DS records has also been
altered to reduce the maximum work from cross product of the
number of DS records and number of DNSKEYs to the cross product
of the number of DS records and supported DS digest types. As
the number of DS digest types is in single figures, this reduces
the exposure.

Credit is due to Elias Heftrig, Haya Schulmann, 

Re: [Dnsmasq-discuss] New option --no-ANY

[Simon Kelley]

On 08/02/2024 12:01, Petr Menšík wrote:
I do not think this is good approach. One thing is any queries need to 
be handled by upstream resolver somehow. Whatever it is, dnsmasq will 
reply whatever upstream resolvers chosen to do that. The only exception 
is local data, for example authoritative services.


I would prefer sending just A or  queries, whatever from them comes 
first. Or maybe excluding other types and using just A and  records, 
if they are in cache. Reference 4.3 
. Alternatively do 
what unbound does, return NOTIMPL error.




Tend to agree. I just pushed something which I think works. It leaves 
replies from local data unaltered and filters all except A, , MX and 
CNAME from upstream replies to ANY queries, as 4.3 suggests.


Use

--filter-rr=ANY

to enable.


Simon.


Shown localhost example:

; <<>> DiG 9.18.21 <<>> @localhost -p 2053 -t any localhost
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60904
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;localhost.            IN    ANY

;; ANSWER SECTION:
localhost.        0    IN    A    127.0.0.1
localhost.        0    IN        ::1

With --no-ANY, it returns empty response. I have changed continue; to 
return 0; That gives incorrect results and should not be used. But your 
patch did not apply to my master, on top of commit 
762a3f243099d26b1e87aad2b1b4b696cd8c33ac.


; <<>> DiG 9.18.21 <<>> @localhost -p 2053 -t any localhost
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48980
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;localhost.            IN    ANY

;; AUTHORITY SECTION:
localhost.        10800    IN    SOA    localhost. nobody.invalid. 1 
3600 1200 604800 10800


I think we can modify ANY type query to provide just single type or 
synthetized answer, but empty response seems wrong. I think || qtype == 
T_ANY should be removed from most of types, to make answer smaller. 
Unlike mDNS ANY is not specified in DNS to provide all answers known. If 
anyone relies on it, that would be wrong too.


I disagree with current proposal.

On 06. 02. 24 18:00, Dominik Derigs via Dnsmasq-discuss wrote:

RFC 8482


--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.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] DHCPv6 with multiple IA

[Simon Kelley]

On 06/02/2024 22:29, Bertrand Jacquin wrote:

Hi,

As per RFC8415 section 21.6, IA Address option 5 offered by the server
specifying (temporary or not) address, may appear more than once so the
client can be offered more than one address to use.

This is supported by AWS EC2 (aws ec2 assign-ipv6-addresses
--ipv6-address-count), allowing to segment IP address for different
usage (container, application specific ..) where DHCP reply look like
the following (full pcap attached):

 Identity Association for Non-temporary Address
 Option: Identity Association for Non-temporary Address (3)
 Length: 96
 IAID: 16092fc9
 T1: 70
 T2: 112
 IA Address
 Option: IA Address (5)
 Length: 24
 IPv6 address: 2a05:d018:c28:1a00::e564
 Preferred lifetime: 140
 Valid lifetime: 450
 IA Address
 Option: IA Address (5)
 Length: 24
 IPv6 address: 2a05:d018:c28:1a00::3504
 Preferred lifetime: 140
 Valid lifetime: 450
 IA Address
 Option: IA Address (5)
 Length: 24
 IPv6 address: 2a05:d018:c28:1a00::3501
 Preferred lifetime: 140
 Valid lifetime: 450

Looking at replicating such setup with dnsmasq, --dhcp-host
documentation specifies "A single --dhcp-host may contain an IPv4
address or one or more IPv6 addresses, or both" by providing a prefix
length. However it appears dnsmasq only ever assign a single address to
the client based on DUID.

Is my understand correct ? How could dnsmasq be configured to return
multiple IA option 5 for a given client ?




Good question.


Looking at the code, a DHCPADVERTISE packet ought to have the following 
addresses in it.


1) All the addresses suggested by the client in the SOLICIT packet which 
are usable with the configuration (mainly, which have suitable 
dhcp-range declarations.


2) All addresses from --dhcp-host declaration which are usable, as above.

3) Addresses of any existing leases held by the DUID/IAID supplied.

4) A randomly assigned address for any in-scope dhcp-range declaration 
which doesn't have a address in one of the preceding classes.




Which would appear to do what you want. I would not be very surprised if 
this sort of functionality has never been thoroughly tested. only a few 
percent of dnsmasq installations will use DHCPv6, and a smaller 
percentage will do radical things like multiple addresses.



[LATER]

Indeed, I just added a dhcp-host declaration for a host on my network, 
with two fixed IPv6 addresses. dnsmasq returns the address it already 
has a lease for, and one of the configured addresses. I think I can see 
the problem.



Simon.





Thanks,


___
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] [PATCH] Easier custom lua version

[Simon Kelley]

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=summary


On 03/02/2024 08:56, Geert Stappers wrote:

On Wed, Jan 24, 2024 at 11:41:57AM +0100, Petr Menšík wrote:

Date: Wed, 24 Jan 2024 11:28:38 +0100
Subject: [PATCH] Make lua version more easy to customize

If distribution making lua-enabled binary does not use default lua5.4,
make it possible to use make LUA=lua5.1 or make LUA=lua.

Fedora provides just lua-devel with pkg-config lua, this change would
make it easier to build it.
---
  Makefile | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 4c5401e..7a6aac6 100644
--- a/Makefile
+++ b/Makefile
@@ -36,6 +36,7 @@ LIBS  =
  
  PKG_CONFIG = pkg-config

  INSTALL= install
+LUA= lua5.4
  MSGMERGE   = msgmerge
  MSGFMT = msgfmt
  XGETTEXT   = xgettext
@@ -60,8 +61,8 @@ idn2_cflags =   `echo $(COPTS) | $(top)/bld/pkg-wrapper 
HAVE_LIBIDN2 $(PKG_CONFI
  idn2_libs = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LIBIDN2 
$(PKG_CONFIG) --libs libidn2`
  ct_cflags = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_CONNTRACK 
$(PKG_CONFIG) --cflags libnetfilter_conntrack`
  ct_libs =   `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_CONNTRACK 
$(PKG_CONFIG) --libs libnetfilter_conntrack`
-lua_cflags =`echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LUASCRIPT 
$(PKG_CONFIG) --cflags lua5.4`
-lua_libs =  `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LUASCRIPT 
$(PKG_CONFIG) --libs lua5.4`
+lua_cflags =`echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LUASCRIPT 
$(PKG_CONFIG) --cflags $(LUA)`
+lua_libs =  `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LUASCRIPT 
$(PKG_CONFIG) --libs $(LUA)`
  nettle_cflags = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_DNSSEC 
$(PKG_CONFIG) --cflags 'nettle hogweed' \
  HAVE_CRYPTOHASH 
$(PKG_CONFIG) --cflags nettle \
  HAVE_NETTLEHASH 
$(PKG_CONFIG) --cflags nettle`


Looks good to me.



Groeten
Geert Stappers


In an attempt to get more attention to proposed patches.


___
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] d/rules: Install D-Bus policy in /usr instead of /etc

[Simon Kelley]

On 23/01/2024 19:55, Sven Geuer wrote:


On Mon, 2024-01-22 at 12:58 +0100, Gioele Barabucci wrote:

On 22/01/24 00:09, Simon Kelley wrote:

I've just committed a major overhaul to the Debian packaging which
eliminates the very ancient and crusty scripts in favour of
debhelper.
Debhelper, predictably, gets this right, so the problem is moot


That's great, thanks.

A minor note: if you rename `d/tmpfiles.conf` to
`d/dnsmasq.tmpfiles`,
then dh_installtmpfiles will automatically pick it up (and add the
necessary maintscript snippets) and you can remove from
`dnsmasq.install` the following line:

  debian/tmpfiles.conf => /usr/lib/tmpfiles.d/dnsmasq.conf



Well spotted, Gioele!

@Simon: I support the change Gioele suggests. It would be great if you
could include this in the 2.90-1 debian release.



'tis done.

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] d/rules: Install D-Bus policy in /usr instead of /etc

[Simon Kelley]

Thanks for the patch, and apologies for taking so long to reply.

I've just committed a major overhaul to the Debian packaging which 
eliminates the very ancient and crusty scripts in favour of debhelper. 
Debhelper, predictably, gets this right, so the problem is moot.



Cheers,

Simon.


On 23/12/2023 14:47, Gioele Barabucci wrote:

Dear dnsmasq maintainer,

could you please merge this small patch related to the Debian packaging, 
or point out any flaw that needs to be addressed?


Regards,

On 14/10/23 13:33, Gioele Barabucci wrote:

dnsmasq installs its D-Bus policy file in `/etc/dbus-1`.
Since Debian 9 the standard directory for package-installed
D-Bus policies is `/usr/share/dbus-1`.

See: https://bugs.debian.org/1006631

Fixes: lintian: dbus-policy-in-etc

Closes: #1040923
---
  debian/dnsmasq-base.conffiles | 2 +-
  debian/rules  | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/dnsmasq-base.conffiles 
b/debian/dnsmasq-base.conffiles

index 2f19194..04ca726 100644
--- a/debian/dnsmasq-base.conffiles
+++ b/debian/dnsmasq-base.conffiles
@@ -1 +1 @@
-/etc/dbus-1/system.d/dnsmasq.conf
+remove-on-upgrade /etc/dbus-1/system.d/dnsmasq.conf
diff --git a/debian/rules b/debian/rules
index 2354ea9..8d47449 100755
--- a/debian/rules
+++ b/debian/rules
@@ -112,7 +112,7 @@ define build_tree
  rm -rf $1
  install -m 755 \
  -d $1/DEBIAN \
-    -d $1/etc/dbus-1/system.d \
+    -d $1/usr/share/dbus-1/system.d \
  -d $1/usr/share/doc/$(package) \
  -d $1/usr/share/doc/$(package)/examples \
  -d $1/usr/share/$(package) \
@@ -153,7 +153,7 @@ define add_files
  gzip -9n $1/usr/share/doc/$(package)/changelog.Debian
  install -m 644 debian/readme 
$1/usr/share/doc/$(package)/README.Debian
  install -m 644 debian/copyright 
$1/usr/share/doc/$(package)/copyright

-    install -m 644 debian/dbus.conf $1/etc/dbus-1/system.d/dnsmasq.conf
+    install -m 644 debian/dbus.conf 
$1/usr/share/dbus-1/system.d/dnsmasq.conf

  endef
  clean:





___
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] Minor typo fix in the man page

[Simon Kelley]

Patch applied. Thanks.

Simon.

On 19/10/2023 22:07, Geert Stappers wrote:

The manual page had "list or RR-types",
changed it into "list of RR-types".

Reported-by: Justin 
---
  man/dnsmasq.8 | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 30429df..d131bbe 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -390,7 +390,7 @@ Remove records of the specified type(s) from answers.
  By default, dnsmasq caches A, , CNAME and SRV DNS record types.
  This option adds other record types to the cache. The RR-type can be given
  as a name such as TXT or MX or a decimal number. A single --cache-rr option
-can take a comma-separated list or RR-types and more than one --cache-rr option
+can take a comma-separated list of RR-types and more than one --cache-rr option
  is allowed. Use --cache-rr=ANY to enable caching for all RR-types.
  .TP
  .B \-r, --resolv-file=


___
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] Introduce local-service=host specialization

[Simon Kelley]

Apologies for the delay. Patch applied.

Simon.


On 09/01/2024 14:45, Petr Menšík wrote:

Kind reminder for this change.

There seems to be no opposition for this change. Can it get merged then, 
please?


Cheers,
Petr

On 12/3/23 19:29, Simon Kelley wrote:
Looks sensible to me. Very much in the spirit of the original 
--local-service option flag.


I'm minded to commit this unless anyone has an objection.


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] Occasional "communications error", how to diagnose?

[Simon Kelley]

On 13/12/2023 15:25, Chris Green wrote:

I run dnsmasq version 2.89 on my laptop which is running [x]ubuntu
23.04.

I have systemd.resolvd disabled.

I'm occasionally seeing the following error when getting a host's IP:-

 chris$ host homepi
 ;; communications error to 127.0.0.1#53: timed out
 homepi has address 192.168.1.113
 chris$ ps -ef | grep dnsmasq
 dnsmasq  933   1  0 Dec06 ?00:00:22 /usr/sbin/dnsmasq -x 
/run/dnsmasq/dnsmasq.pid -u dnsmasq -7 
/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service 
--trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
 chris  865413774  0 15:05 pts/100:00:00 grep --color=auto 
dnsmasq
 chris$

As can be seen dnsmasq is running and subsequent queries work without any
error (or delay).  The above timeout is a few seconds, maybe five or a bit
less.

There's no dnsmasq related error message in syslog (nothing for today at
all).  The system homepi is a Raspberry Pi on the same LAN as the laptop
running dnsmasq, The error isn't only for one particular host, I've seen
it for other systems on my LAN.

Can anyone suggest what might be causing the error and/or how to diagnose
what's wrong?



It looks like the first query (or its reply) was dropped, host retried, 
and it worked second time around.


Since DNS transport is normally across UDP, which is defined as 
unreliable, this is completely normal. Except that the UDP packets are 
not actually traversing a network, they're going via the lo interface 
within one machine. I'm sure there are circumstances where UDP packets 
can get dropped in the kernel when going via the lo interface, but it 
shouldn't happen very often. Is the machine under heavy load or memory 
pressure? Maybe a network reconfiguration event could drop packets?


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] Dnsmasq IPv6 NXDOMAIN issue when using synth-domain for IPv4

[Simon Kelley]

The problem is well known, and the solution (rewrite NXDOMAIN replies 
from upstream to NODATA) has been done for a long time. Unfortunately, 
an oversight missed out --synth-domain from the code which determines if 
a query for another rr-type is capable of eliciting an answer and 
triggers the re-write.


https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=63ba726e1f8d1ac53db260110657bc82539b2d97

should fix things.


Cheers,

Simon.



On 02/12/2023 21:17, Matt Wong wrote:

Hi,

I encountered the following issue and would like some guidance on a 
solution. My dnsmasq config looks like the following:


listen-address=127.0.0.1
synth-domain=custom.domain ,10.0.0.0/16,ip- 



The servers associated with the 'ip-*.custom.domain' custom domains do 
not have ipv6 addresses associated with them so we cannot configure the 
synth domain for ipv6 addresses. Now when I do a 'nslookup 
ip-10-0-0-16-custom.domain ', it 
seems like dnsmasq does the following:


1. Dnsmasq tries to resolve the domain for 
ipv4:ip-10-0-0-16-custom.domain 
 and it will return 10.0.0.16 due 
to the synth-domain config.
2. Dnsmasq will also try to resolve the domain for ipv6. It will forward 
the query to an upstream nameserver which will return NXDOMAIN (since we 
do not configure the upstream nameservers to return ipv4 or ipv6 
addresses for any of the custom domains). It seems like dnsmasq will 
then cache NXDOMAIN for both ipv4 and ipv6 queries. As a result, any 
subsequent ipv4 queries for this domain will result in NXDOMAIN rather 
than using the value returned from our synth-domain config.


I have the following questions:
1. Currently, is there a way we can configure dnsmasq to resolve to 
NODATA for ipv6 when an ipv4 synth-domain config is present even though 
the ipv6 resolution might be NXDOMAIN? I have tried using the 
'--no-negcache' option which solves this issue. However, we do not want 
to disable negative caching as it could increase outbound network 
activity greatly.

2. Is this issue expected? If not, can we have a fix for this?

___
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] [PATCH] Introduce local-service=host specialization

[Simon Kelley]

Looks sensible to me. Very much in the spirit of the original 
--local-service option flag.


I'm minded to commit this unless anyone has an objection.


Simon.


On 30/11/2023 17:59, Petr Menšík wrote:

Hello!

I have sent similar proposal already in year 2021 [1]. But I have 
reworked that a bit to reuse existing --local-service option and just 
add new parameter to it. If --local-service=host is used, dnsmasq will 
bind to addresses on lo interface only. It will not even open port on 
other interfaces, preventing possible scanning of running service from 
outside.


It roughly becomes similar default like other resolvers without 
configuration use. BIND9 or unbound will listen also on localhost only.


To avoid regressions, it still becomes inactive when any --interface, 
--listen-address or similar is specified at least once. Then you have to 
explicitly use --interface=lo to listen *also* on localhost.


The change is related to Fedora bug #1852373 [2], also newly re-opened 
CVE-2020-14312 issue for RHEL8 [3]. Having explicitly specified 
bind-interfaces & interface=lo in dnsmasq default configuration has 
resulted in multiple regressions across different packages, which did 
not rewrite distribution provided configuration. I think it could be 
useful also for others.


What do you think?

Looking for any feedback!

Regards,
Petr

1. 
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q4/015749.html

2. https://bugzilla.redhat.com/show_bug.cgi?id=1852373
3. https://issues.redhat.com/browse/RHEL-9516


___
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] Domain not applied correctly when reading DHCP lease file

[Simon Kelley]

You're pretty much correct. the code that reads the leases file runs 
(for good reasons) before the code which looks at the addresses of the 
local interfaces, so domain configs which are predicated on the 
interface come out wrong.


thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=f1beb79429338d35d3b7f821ea33053ab980ccf5

reorders things and should fix this.


Cheers,

Simon.


On 24/11/2023 01:34, xeyr...@gmail.com wrote:

I have the following config:

dhcp-fqdn
domain=example.com
domain=eth1.example.com,eth1
dhcp-range=10.0.1.100,10.0.1.200

eth1 is 10.0.1.1/24.

When a client, e.g. host1, makes a DHCP request on eth1, it is
correctly assigned host1.eth1.example.com as its FQDN. Lease file is
written correctly, and DNS resolution works as expected.

However, after dnsmasq is restarted, IP assignment is read correctly
from the lease file, but FQDN now becomes host1.example.com, which is
obviously wrong. The original host1.eth1.example.com FQDN does not
resolve anymore. The problem persists until the client renews its DHCP
lease.

If I use address range in config file instead of interface name
("domain=eth1.example.com,10.0.1.0/24"), the problem does not occur.
FQDN is preserved correctly on restart.

Doing some cursory debugging, the problem appears to be here:
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/domain.c;h=ca3931de13d74db0efdaf4f49a0d0187026d602b;hb=HEAD#l236
. "c->al" is empty at the time lease file is being read, so no domains
match, and default domain gets incorrectly assigned.

___
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] [PATCH] Add number of forks for TCP to metrics and dump

[Simon Kelley]

Looks good. Patch applied.


Cheers,

Simon.

On 24/11/2023 11:13, Damian Sawicki via Dnsmasq-discuss wrote:

Hello dnsmasq experts,

Following up on the recent addition of the flag --max-tcp-connections, I'd like 
to propose a patch with monitoring of the number of TCP connections. This way, 
a user can actually estimate their usage and adjust --max-tcp-connections 
accordingly to prevent overload.

The patch adds the relevant information to the metrics and to the output of 
dump_cache() (which is called when dnsmasq receives SIGUSR1). Hence, users not 
collecting metrics will still be able to troubleshoot with SIGUSR1. In addition 
to the current usage, dump_cache() contains the information on the highest 
usage since it was last called.

Please kindly let me know what you think.

Best regards,

Damian Sawicki

*

Add to the metrics and dump_cache() the info on the utilisation of
the limit on concurrent TCP connections (the variable
daemon->max_procs, customisable via  --max-tcp-connections).
---
  man/dnsmasq.8 |  2 +-
  src/cache.c   |  5 +
  src/dnsmasq.c | 11 ++-
  src/dnsmasq.h |  1 +
  src/metrics.c |  1 +
  src/metrics.h |  1 +
  src/option.c  |  1 +
  7 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 6d37360..1b5ebda 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -2303,7 +2303,7 @@ they expired in order to make room for new names and the 
total number
  of names that have been inserted into the cache. The number of cache hits and
  misses and the number of authoritative queries answered are also given. For 
each upstream
  server it gives the number of queries sent, and the number which
-resulted in an error. In
+resulted in an error. It also gives information on the number of forks for TCP 
connections. In
  .B --no-daemon
  mode or when full logging is enabled (\fB--log-queries\fP), a complete dump 
of the
  contents of the cache is made.
diff --git a/src/cache.c b/src/cache.c
index 5342ce2..b95e3c7 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -1895,6 +1895,11 @@ void dump_cache(time_t now)
  #endif
  
blockdata_report();

+  my_syslog(LOG_INFO, _("child processes for TCP requests: in use %zu, highest 
since last SIGUSR1 %zu, max %zu."),
+  daemon->metrics[METRIC_TCP_CONNECTIONS],
+  daemon->max_procs_used,
+  daemon->max_procs);
+  daemon->max_procs_used = daemon->metrics[METRIC_TCP_CONNECTIONS];
  
/* sum counts from different records for same server */

for (serv = daemon->servers; serv; serv = serv->next)
diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 65ba334..39aaf19 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -1534,7 +1534,11 @@ static void async_event(int pipe, time_t now)
  else if (daemon->port != 0)
for (i = 0 ; i < daemon->max_procs; i++)
  if (daemon->tcp_pids[i] == p)
-   daemon->tcp_pids[i] = 0;
+{
+ daemon->tcp_pids[i] = 0;
+  if (daemon->tcp_pipes[i] == -1)
+daemon->metrics[METRIC_TCP_CONNECTIONS]--;
+}
break;

  #if defined(HAVE_SCRIPT)  
@@ -1844,6 +1848,8 @@ static void check_dns_listeners(time_t now)
{
  close(daemon->tcp_pipes[i]);
  daemon->tcp_pipes[i] = -1; 
+if (daemon->tcp_pids[i] == 0)
+  daemon->metrics[METRIC_TCP_CONNECTIONS]--;
}

for (listener = daemon->listeners; listener; listener = listener->next)
@@ -1972,6 +1978,9 @@ static void check_dns_listeners(time_t now)
  /* i holds index of free slot */
  daemon->tcp_pids[i] = p;
  daemon->tcp_pipes[i] = pipefd[0];
+  daemon->metrics[METRIC_TCP_CONNECTIONS]++;
+  if (daemon->metrics[METRIC_TCP_CONNECTIONS] > daemon->max_procs_used)
+daemon->max_procs_used = daemon->metrics[METRIC_TCP_CONNECTIONS];
}
  close(confd);
  
diff --git a/src/dnsmasq.h b/src/dnsmasq.h

index 67c083b..3d85b73 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -1314,6 +1314,7 @@ extern struct daemon {
int dumpfd;
  #endif
int max_procs;
+  uint max_procs_used;
  } *daemon;
  
  struct server_details {

diff --git a/src/metrics.c b/src/metrics.c
index 050ccb3..1a9a4d3 100644
--- a/src/metrics.c
+++ b/src/metrics.c
@@ -39,6 +39,7 @@ const char * metric_names[] = {
  "leases_pruned_4",
  "leases_allocated_6",
  "leases_pruned_6",
+"tcp_connections",
  };
  
  const char* get_metric_name(int i) {

diff --git a/src/metrics.h b/src/metrics.h
index 22e9e48..e1cdd87 100644
--- a/src/metrics.h
+++ b/src/metrics.h
@@ -38,6 +38,7 @@ enum {
METRIC_LEASES_PRUNED_4,
METRIC_LEASES_ALLOCATED_6,
METRIC_LEASES_PRUNED_6,
+  METRIC_TCP_CONNECTIONS,

__METRIC_MAX,

  };
diff --git a/src/option.c b/src/option.c
index 9423582..3eeda18 100644
--- a/src/option.c
+++ b/src/option.c
@@ -5855,6 +5855,7 @@ void read_opts(int argc, char **argv, char *compile_opts)
daemon->randport_limit = 

Re: [Dnsmasq-discuss] Does the --interface option to dnsmasq also apply to incoming broadcast DHCP requests?

[Simon Kelley]

On 29/11/2023 23:09, Chris Friesen via Dnsmasq-discuss wrote:

Hi,

I was just wondering whether the --interface and --except-interface 
options to dnsmasq would also apply to messages like DHCPDISCOVER and 
DHCPREQUEST which are broadcast to 255.255.255.255.


In my particular case I have an existing dnsmasq instance that is 
running, and I want to add a second dnsmasq instance to handle DHCP 
requests coming from a specific subset of interfaces.   I don't want the 
primary dnsmasq instance to see the requests coming in on those 
interfaces, and I don't want the second dnsmasq instance to see requests 
coming in on the other interfaces.


As a concrete example, suppose I have network interfaces eth0/eth1/eth2 
and I have instance A of dnsmasq which is run as "dnsmasq 
--except-interface eth2", and instance B of dnsmasq which is run as 
"dnsmasq --interface eth2 --except-interface lo".


If a broadcast DHCPDISCOVER or DHCPREQUEST comes in on eth0/eth1 which 
dnsmasq instance(s) will see it?


If a broadcast DHCPDISCOVER or DHCPREQUEST comes in on eth2 which 
dnsmasq instance(s) will see it?


If a broadcast DHCPDISCOVER or DHCPREQUEST is emitted by an entity on 
the local host which dnsmasq instance(s) will see it?


Thanks,

Chris Friesen



As you've surmised, making more than one dnsmasq/DHCP instance on a 
server work is tricky.


It can be done, but only in a very specific way.

Each dnsmasq instance must be configured to serve exactly one interface, 
using the --interface config option.


Under these circumstances, dnsmasq will log

DHCP, sockets bound exclusively to interface 

at startup.

Your example will not work, because your instance A is binding to more 
than one interface. To fix this you need to start separate dnsmasq 
instances for eth0 and eth1, or you need to bridge eth0 and eth1 to 
single bridge interface and configure dnsmasq to listen on that.



The reason behind this is that the dnsmasq DHCP subsystem uses one 
socket, which listens on the wildcard address (so that broadcasts to 
255.255.255.255 arrive, amongst other reasons.) In the "exactly one 
interface" state, dnsmasq can also bind that socket to a physical 
interface, using the SO_BINDTODEVICE socket option, which allows  the 
multiple-server setup to work. SO_BINDTODEVICE only allows one device, 
hence the one interface limitation.



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] Re: Issues with dnsmasq under NM and domain redirection: REFUSED

[Simon Kelley]

On 31/10/2023 16:39, Petr Menšík wrote:
I am still not sure what exactly causes this problem, but I have hit it 
again. I am sure it happens sometimes, when I disconnect from my Lenovo 
docking station and then connect back to it.


Interesting thing I have found is it gets unblocked by sending a simple 
dig -4 @localhost +tcp fedoraproject.org query. TCP query seems to do 
enumerate_interfaces(0) on every query, which fixes incorrect ifindex 
and unblocks the dnsmasq.


I am not sure why check_servers(0); called from dbus.c does not fix this 
reliably. It seems to me it should. It may be just delayed or run too 
soon. I think we can afford enumerating interface on fatal error, which 
results in REFUSED response anyway.


It runs with these parameters:

/usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts 
--bind-interfaces --pid-file=/run/NetworkManager/dnsmasq.pid 
--listen-address=127.0.0.1 --cache-size=400 --clear-on-reload 
--conf-file=/dev/null --proxy-dnssec 
--enable-dbus=org.freedesktop.NetworkManager.dnsmasq 
--conf-dir=/etc/NetworkManager/dnsmasq.d


But it seems to me local_bind would bind interface whether 
--bind-interfaces or --bind-dynamic is present. So I think no condition 
should be for enumerate_interfaces(0); call in this case as well.


If that's sufficient to fix this bug, then I can't see a reason not to 
make the change. The other way to fix it is to 
s/--bind-interfaces/--bind-dynamic/  That's maybe a better fix, since 
there are platforms which can't enumerate interfaces, so the problem 
will still be there. At least if you set --bind-dynamic on such a 
platform it will warn you as it falls back to bind-interfaces behaviour.


Cheers,

Simon.



I have created for it bug #2247269 [1] for tracking this.

1. https://bugzilla.redhat.com/show_bug.cgi?id=2247269

On 16. 10. 23 15:02, Petr Menšík wrote:

Hello everyone.

Today I have returned to work, where I am running dnsmasq 2.89 on my 
Fedora 27 laptop. It is configured by Network Manager by its 
dns=dnsmasq plugin. But when I returned today, I have found our 
internal network refused to resolve any name. I dug into dnsmasq what 
it does. Problem is it did not fix itself after a while, but 
stubbornly failed without later fix.


It were failing quite often on random_sock() local_bind call. The 
errno returned 99. I have noticed it failed to notice change of 
ifindex in interface it should be bound to.


(gdb) bt
#0  0x7f53305e7020 in strerror () from /lib64/libc.so.6
#1  0x5557a3ec2c4b in random_sock (s=s@entry=0x5557a43fef50) at 
/usr/src/debug/dnsmasq-2.89-5.fc37.x86_64/src/forward.c:2511
#2  0x5557a3ec62f2 in allocate_rfd 
(fdlp=fdlp@entry=0x5557a43f5280, serv=serv@entry=0x5557a43fef50)

    at /usr/src/debug/dnsmasq-2.89-5.fc37.x86_64/src/forward.c:2607
#3  0x5557a3ec72dc in forward_query (udpfd=4, 
udpaddr=0x7ffdb6bfbd30, dst_addr=0x7ffdb6bfbd00, dst_iface=0, 
header=0x5557a43e03d0, plen=51,
    limit=0x5557a43e0880 "", now=1697453089, forward=0x5557a43f5230, 
ad_reqd=1, do_bit=0, fast_retry=0)

    at /usr/src/debug/dnsmasq-2.89-5.fc37.x86_64/src/forward.c:498
#4  0x5557a3ed0ebd in receive_query (now=1697453089, 
listen=0x5557a43e0cc0) at 
/usr/src/debug/dnsmasq-2.89-5.fc37.x86_64/src/forward.c:1869
#5  check_dns_listeners (now=1697453089) at 
/usr/src/debug/dnsmasq-2.89-5.fc37.x86_64/src/dnsmasq.c:1845
#6  0x5557a3eac9ef in main (argc=, argv=out>) at /usr/src/debug/dnsmasq-2.89-5.fc37.x86_64/src/dnsmasq.c:1266


(gdb) p *$d->servers->next->next->next->next->next->next
$8 = {flags = 800, domain_len = 14, domain = 0x5557a43f5eb0 
"brq.redhat.com", next = 0x5557a43ffa10, serial = 6, arrayposn = 23,
  last_server = -1, addr = {sa = {sa_family = 2, sa_data = 
"\0005\n&\005\032\226\r\2170S\177\000"}, in = {sin_family = 2, 
sin_port = 13568,
  sin_addr = {s_addr = 436545034}, sin_zero = 
"\226\r\2170S\177\000"}, in6 = {sin6_family = 2, sin6_port = 13568, 
sin6_flowinfo = 436545034,
  sin6_addr = {__in6_u = {__u6_addr8 = 
"\226\r\2170S\177\000\\275\001\a\220\000\000", __u6_addr16 = 
{3478, 12431, 32595, 0, 48432, 1793,
    144, 0}, __u6_addr32 = {814681494, 32595, 117554480, 
144}}}, sin6_scope_id = 3446832640}}, source_addr = {sa = {sa_family = 2,
  sa_data = "\000\000\000\000\000\000@\274\277\266\375\177\000"}, 
in = {sin_family = 2, sin_port = 0, sin_addr = {s_addr = 0},
  sin_zero = "@\274\277\266\375\177\000"}, in6 = {sin6_family = 2, 
sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {
  __u6_addr8 = 
"@\274\277\266\375\177\000\000@\274\277\266\375\177\000", __u6_addr16 
= {48192, 46783, 32765, 0, 48192, 46783, 32765, 0},
  __u6_addr32 = {3066018880, 32765, 3066018880, 32765}}}, 
sin6_scope_id = 814672583}},
  interface = "enp9s0u1\000\000\000\000\000\000\000\000", ifindex = 7, 
sfd = 0x0, tcpfd = 0, edns_pktsz = 1232, pktsz_reduced = 0, queries = 
446,
  failed_queries = 0, nxdomain_replies = 0, retrys = 4, query_latency 
= 0, mma_latency 

Re: [Dnsmasq-discuss] [PATCH] Refuse to start with EADDRINUSE in --bind-dynamic mode

[Simon Kelley]

On 25/11/2023 16:51, Petr Menšík wrote:
Yes, the problem is 3) has a condition we wait until it changes then 
retry. But for a lot (most?) of errors we lack any indication from the 
system it has changed.


For example insufficient memory or insufficient file descriptors. It may 
change, but unlike watching up and down interfaces, there is no hook 
which would retry listener creation. It fails once and then just maybe 
retries on explicit reload. That is why I think it is absolutely 
necessary to log any failure we pass somewhere, unless we know we will 
retry later.


You're right, the only error from bind() that should be ignored is 
EADDRNOTAVAIL. everything else should be a fatal error during startup or 
logged once  the daemon is running.


I've just pushed a patch to that effect.

Cheers,

Simon.



More below...

On 11/23/23 13:47, Simon Kelley wrote:
That's a good point, but I don't think there needs to be any non-fatal 
error logging. There are three situations during startup.


1) bind() succeeds.
2) bind fails for a reason which won't change - fatal error.
3) bind fails for a reason which may change - startup and wait until 
it does change and try again.


The canonical example of 3) is the one I gave before, 
--listen-address=1.2.3.4 but not local interface has address 1.2.3.4. 
The intention is that when a new interface comes up with address 
1.2.3.4 then a new socket will be created and bound. This is long 
after startup, so the only option if it fails then is to log the event.
Of course, this is very special case somehow well handled. I agree there 
is not much else to do. We could only make the error fatal, but I don't 
think that is desired.


If the only situation where we want to wait is the one above, then the 
solution to to make EADDRNOTAVAIL at startup the only one where we 
keep waiting, and all the others are fatal. I think when I originally 
wrote this I wasn't sure if that was the only non-fatal error which is 
why the code is as it is.


This is not a complete solution to your original problem of enforcing 
only one dnsmasq daemon process in any case. For example if you 
configure a single listen-address which doesn't exist on the machine, 
then you can start as many dnsmasq processes as you like and they'll 
all start up and be waiting for the interface with that address to be 
created. Once it is, all will try and bind it, and all but one will 
fail, but they'll all still exist. Managing daemon processes is really 
the job of sysvinit or systemd, but the authors of the bug seem to 
sant protection from just running the binary from the command line.


We at Fedora support only services managed by systemd. But even for 
that, it needs to get some feedback of failure. If the process 
terminates with non-zero status code, unit will be marked failed. We 
*need* that. Alternative might be support for libsystemd with notify 
socket, which would work with Type=notify services. Now it will report 
failed startup only with Type=forking. Later failure is logged only as a 
warning regardless of type of the error. I think we want unexpected 
error types to be logged as errors, especially for insufficient 
resources errors like ENOMEM. Or made them fatal. With systemd unit 
Restart=on-failure, it might be able to recover from memory leaks if 
such errors were fatal. Not sure we want that, might break a lot of 
deployments, but also fix some.




TLDR;

We either pick a set of errors which are Ok to continue 
(EADDRNOTAVAIL, what others?) and fail fatally at startup for all 
others, or we pick a set of errors to fail fatally at startup 
(EADDRINUSE, EACCESS, what others?) and continue for all others.



Cheers,

Simon.


I would say safer would be to fatal error everything except explicitly 
waived, for now just EADDRNOTAVAIL and EINTR? I think most of these 
errors means incomplete degraded service anyway, without reliable 
self-repair code present. If it had repeat timer with exponentially 
increasing time of retry (with some upper bound), then we might want it 
to start anyway. But I think it is safer to prevent half-initialized 
service. Systemd can provide autorecovery with smart settings. Do we 
have a way to specify I do not require TCP listening socket for DNS? It 
should be clearly discouraged, but for some kinds of tests it might be 
acceptable.


Cheers,
Petr




On 23/11/2023 11:13, Petr Menšík wrote:
To fix problem with multiple instances correctly refusing running on 
the same machine and namespaces, yes, it would be sufficient.


But I think part of the problem is hiding all problems during startup 
and not showing them at all, in any source. I think that is okay for 
EADDRNOTAVAIL to not be printed. But I think in other cases we want 
at least warning somewhere. This way you also get exact error message 
printed. For example selinux policy hardening may prevent your 
process to listen on port 53, even though it has NET_BIND_SERVICE.


With my modification it will print

Re: [Dnsmasq-discuss] [PATCH] Refuse to start with EADDRINUSE in --bind-dynamic mode

[Simon Kelley]

That's a good point, but I don't think there needs to be any non-fatal 
error logging. There are three situations during startup.


1) bind() succeeds.
2) bind fails for a reason which won't change - fatal error.
3) bind fails for a reason which may change - startup and wait until it 
does change and try again.


The canonical example of 3) is the one I gave before, 
--listen-address=1.2.3.4 but not local interface has address 1.2.3.4. 
The intention is that when a new interface comes up with address 1.2.3.4 
then a new socket will be created and bound. This is long after startup, 
so the only option if it fails then is to log the event.


If the only situation where we want to wait is the one above, then the 
solution to to make EADDRNOTAVAIL at startup the only one where we keep 
waiting, and all the others are fatal. I think when I originally wrote 
this I wasn't sure if that was the only non-fatal error which is why the 
code is as it is.


This is not a complete solution to your original problem of enforcing 
only one dnsmasq daemon process in any case. For example if you 
configure a single listen-address which doesn't exist on the machine, 
then you can start as many dnsmasq processes as you like and they'll all 
start up and be waiting for the interface with that address to be 
created. Once it is, all will try and bind it, and all but one will 
fail, but they'll all still exist. Managing daemon processes is really 
the job of sysvinit or systemd, but the authors of the bug seem to sant 
protection from just running the binary from the command line.


TLDR;

We either pick a set of errors which are Ok to continue (EADDRNOTAVAIL, 
what others?) and fail fatally at startup for all others, or we pick a 
set of errors to fail fatally at startup (EADDRINUSE, EACCESS, what 
others?) and continue for all others.



Cheers,

Simon.


On 23/11/2023 11:13, Petr Menšík wrote:
To fix problem with multiple instances correctly refusing running on the 
same machine and namespaces, yes, it would be sufficient.


But I think part of the problem is hiding all problems during startup 
and not showing them at all, in any source. I think that is okay for 
EADDRNOTAVAIL to not be printed. But I think in other cases we want at 
least warning somewhere. This way you also get exact error message 
printed. For example selinux policy hardening may prevent your process 
to listen on port 53, even though it has NET_BIND_SERVICE.


With my modification it will print errors for listeners used. Note 
10.1.2.3 is hidden at that phase. You would not know it without strace 
analysis. I expect there can be different errors, for example running 
out of file descriptors or memory. Hiding something non-standard 
happened during startup is quite a bad design. Only some kinds of errors 
are okay during startup.


$ sudo -u nobody fedora-like/dnsmasq -d --bind-dynamic 
--listen-address=10.1.2.3

dnsmasq: failed to create listening socket for 127.0.0.1: Permission denied
dnsmasq: failed to create listening socket for 127.0.0.1: Permission denied
dnsmasq: failed to create listening socket for ::1: Permission denied
dnsmasq: failed to create listening socket for ::1: Permission denied

dnsmasq: process is missing required capability NET_BIND_SERVICE

# Compare this with:

$ sudo -u nobody fedora-like/dnsmasq -d --bind-interfaces 
--listen-address=10.1.2.3

dnsmasq: failed to create listening socket for 127.0.0.1: Permission denied

I think we want any errors printed, even if they are not made fatal. 
Except carefully chosen type of errors, which are expected and would 
raise just false alarms. Not sure how to trigger other types of errors, 
but I am sure I would like to see them, even if they did not cause the 
process to die. That is why I have used more complicated approach, which 
should print everything unexpected, even when dnsmasq is not stopped. In 
order to investigate you first have to know something unusual has happened.


On 23. 11. 23 0:29, Simon Kelley wrote:

Isn't this sufficient to fix the problem?

Not calling die() when bind-dynamic is set is intended to handle the 
case that  bind returns EADDRNOTAVAIL because you've configured 
--listen-address=1.2.3.4 but there's not a local interface with that 
address. dnsmasq runs anyway in the expectation that such an interface 
will appear in the future and a socket will be bound then.


I don't think there's a die()/syslog() conflict at all.


diff --git a/src/network.c b/src/network.c
index ca9fada..db1d528 100644
--- a/src/network.c
+++ b/src/network.c
@@ -924,7 +924,7 @@ static int make_sock(union mysockaddr *addr, int 
type, int dienow)

    {
  /* failure to bind addresses given by --listen-address at 
this point

 is OK if we're doing bind-dynamic */
- if (!option_bool(OPT_CLEVERBIND))
+ if (!option_bool(OPT_CLEVERBIND) || errno == EADDRINUSE)
    die(s, daemon->addrbuff, EC_BADNET);
    }
   else

Cheers,

Simon.

On

Re: [Dnsmasq-discuss] [PATCH] Refuse to start with EADDRINUSE in --bind-dynamic mode

[Simon Kelley]

Isn't this sufficient to fix the problem?

Not calling die() when bind-dynamic is set is intended to handle the 
case that  bind returns EADDRNOTAVAIL because you've configured 
--listen-address=1.2.3.4 but there's not a local interface with that 
address. dnsmasq runs anyway in the expectation that such an interface 
will appear in the future and a socket will be bound then.


I don't think there's a die()/syslog() conflict at all.


diff --git a/src/network.c b/src/network.c
index ca9fada..db1d528 100644
--- a/src/network.c
+++ b/src/network.c
@@ -924,7 +924,7 @@ static int make_sock(union mysockaddr *addr, int 
type, int dienow)

{
  /* failure to bind addresses given by --listen-address at 
this point

 is OK if we're doing bind-dynamic */
- if (!option_bool(OPT_CLEVERBIND))
+ if (!option_bool(OPT_CLEVERBIND) || errno == EADDRINUSE)
die(s, daemon->addrbuff, EC_BADNET);
}
   else

Cheers,

Simon.

On 22/11/2023 19:27, Petr Menšík wrote:

Hello everyone,

I have received error report RHEL-16398 [1], which I think makes sense 
to fix even in the lastest version. I believe it allows non-intentional 
another instance running without error. What is worse, it does not even 
show any warning that initialization is incomplete.


Of course the problem at start is those errors happen in time when no 
log is available. I think that can be fixed easily by using stderr at 
that time. That is patch #1.


Second makes EADDRNOTAVAIL bind errors still hidden, but prints all 
other errors at least to stderr. On a system with systemd that should 
make it present in journalctl -u dnsmasq anyway. EADDRINUSE is made 
fatal, because that would not be usually handled by new addresses added 
later. If there is a need to start another dnsmasq instance without TCP 
listeners, I think that should be specified more explicitly. Makes 
EADDRINUSE fatal the same way as with --bind-interfaces.


Would you find any other errors, which should be hidden or made fatal? 
What would you think of those changes?


1. https://issues.redhat.com/browse/RHEL-16398


___
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] runtime error: left shift of 128 by 24 places cannot be represented in type 'int'

[Simon Kelley]

Thanks for that. I don't think this bug has any practical effect. If the 
hash is calculated wrongly, it's only ever compared to another has 
calculated the same way, so the code will still work as designed.


I think that this patch fixes things. Please could you test?

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=65c2d6afd67a032f45f40d7e4d620f5d73e5f07d

Cheers,

Simon.


On 22/11/2023 06:44, 吴非凡 wrote:

Hello dnsmasq experts,

There is a runtime error in the latest version of dnsmasq. If we
compile dnsmasq with UBSan. and send it with

```
echo -n 'c97b0101047465737403636f6d020001' | xxd
-r -p | nc -u target_addr target_port
```

And then we'll get a error message:

```
hash-questions.c:168:21: runtime error: left shift of 128 by 24 places
cannot be represented in type 'int'
#0 0x6f0252 in sha256_transform /root/dnsmasq/src/hash-questions.c:168:21
#1 0x6eea82 in sha256_final /root/dnsmasq/src/hash-questions.c:267:3
#2 0x6eea82 in hash_questions /root/dnsmasq/src/hash-questions.c:127:3
#3 0x56d2e9 in forward_query /root/dnsmasq/src/forward.c:179:16
#4 0x580327 in receive_query /root/dnsmasq/src/forward.c:1877:12
#5 0x5c977f in check_dns_listeners /root/dnsmasq/src/dnsmasq.c:1838:2
#6 0x5c0c95 in main /root/dnsmasq/src/dnsmasq.c:1259:7
#7 0x7f3e2ec1dd8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f)
#8 0x7f3e2ec1de3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f)
#9 0x4206d4 in _start (/root/dnsmasq/src/dnsmasq+0x4206d4)
```

here is my conf and cli args:

```
no-daemon
no-resolv
interface=lo
bind-interfaces
no-hosts
server=/baidu.com/223.5.5.5
server=/thekelleys.org.uk/114.114.114.114
address=/test.com/233.233.233.233
cache-size=150
```

```
dnsmasq -p 5355 -d -N -q -R -h -n -y -C config.conf
```

Kind regards,

Feifan Wu

___
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] dnsmasq page fault

[Simon Kelley]

I just pushed a putative fix. Apologies for missing this.

Simon.


On 10/11/2023 19:46, e9hack wrote:

Hi,

I think tcp_init() must be execute outside of if (daemon->port != 0) {}. 
I've two instances running. The crashing instance acts as dhcp server only.


Regards,
Hartmut

Am 10.11.2023 um 20:15 schrieb Geert Stappers:

On Fri, Nov 10, 2023 at 07:41:59PM +0100, e9hack wrote:

Hi,

it looks like that commit 416390f9962e455769aa8ab6df0e105cae07ae55 (Add
--max-tcp-connections option to make this dynamically configurable.) is
incomplete.


https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=416390f9962e455769aa8ab6df0e105cae07ae55;hp=24804b7431f6ace109e91876aef859a751bf3147


It occurs a page fault in dnsmasc.c line 1050 (initialisation of
daemon->tcp_pipes with -1).



Oops.


Regards,
Hartmut



Thanks for reporting.


Groeten
Geert Stappers



___
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] Having dnsmasq coexist with other dhcp server

[Simon Kelley]

On 18/10/2023 08:58, Luigi Baldoni via Dnsmasq-discuss wrote:

   Hello,
I'm having a hard time making dnsmasq run together with kea-dhcp4-server on the 
same machine.
Even though they listen on different interfaces, the first one prevents the 
other from starting.
With the old isc-dhcp-server, "bind-interfaces" was enough. But now strace shows
'bind(4, {sa_family=AF_INET, sin_port=htons(67), 
sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)'
no matter how much I tinker with the configuration.

Any ideas?


This is tricky. Making DHCP work for IPv4 really requires binding the 
wildcard address, 0.0.0.0 and this makes running multiple servers on 
different interface of the same machine problematic. Dnsmasq does its 
best, and pretty much works for multiple dnsmasq instances. There are 
two different actions needed: 1) Set the socket option SO_REUSEPORT on 
the DHCP socket: this allows multiple processes to bind the same port 
number. Dnsmasq always does this when bind-interfaces is set. 2) Bind 
the socket to a physical interface, so that packets send to 
255.255.255.255 get send to the correct dnsmasq instance based on which 
interface they arrive on. Dnsmasq does this when bind-interfaces is set, 
and it's configured using --interface to listen on exactly one interface.


The problem you have, I think, is that Kea is not sharing nicely in the 
same way. The Kea code on github doesn't set SO_REUSEPORT for DHCPv4 (it 
does for DHCPv6) The old ISC server does raw packet IO to avoid the 
problems with the kernel IP stack for DHCPv4, and that's probably why it 
works. I've not looked at Kea in detail, but it's likely that it uses 
the same approach to making DHCPv4 work using the kernel IP stack that 
dnsmasq does, but it looks like it's not had the time that dnsmasq has 
to accrete the workarounds needed to run multiple DHCP servers in one 
kernel.


I'd suggest that this is a Kea problem, not a dnsmasq one.


Cheers,

Simon.




___
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] DHCPv6 doesn't work on Linux interfaces enslaved to a VRF

[Simon Kelley]

On 10/10/2023 11:25, Luci Stanescu wrote:

Hi Simon,


On 10 Oct 2023, at 00:17, Simon Kelley  wrote:

I've implemented option 1 here and it's currently running and dogfood 
on my home network. There are no VRF interfaces there: this is a test 
mainly to check that nothing breaks. So far, so good.


The patch I used is attached. It would be interesting to see if it 
solves the problem for you.


Many thanks for this! I can confirm that it works as expected with 
VRF-enslaved interfaces now.


Excellent. I've elaborated the patch slightly so that it logs when doing 
the fixup. If it turns out that there are cases where it's doing that 
inappropriately, the log will make it easier to see what's going on.


The patch is in the git public repo master branch now, so if anyone on 
the lists starts seeing "Working around kernel bug." messages, 
please reply here ASAP.




2. Finding authoritative information that the interface index from 
IPV6_PKTINFO is always set to the L3 interface on which a datagram 
was received. The kernel mailing list might be start? I'd certainly 
be happy to help think about and test various scenarios.


Please enquire about 2.


I've tested chains of bond- and bridge-enslaved interfaces (e.g. veth in 
bond in bridge in bond) and ipi6_ifindex seems to be set to the 
highest-up master, excluding VRF devices, so that seems promising and 
should cover the empirical bit. Joining a multicast group on an enslaved 
interface (if the master isn't a VRF) doesn't seem to work anyway.


I'll ask on the netdev kernel mailing list and see if I can get any 
assurances, but I'll have to wait for my DMARC record to expire first.




Thanks for that.


Simon.


Cheers,
Luci

--
Luci Stanescu
Information Security Consultant



___
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] Fix DHCPv6 "NotOnlink" response which previously failed to set the message type correctly

[Simon Kelley]

Thanks for finding that.

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3868066085f4f73055d303ad2af59ad66245cf27

is basically the same fix, but does logging right.

Cheers,

Simon.

On 10/10/2023 11:23, renmingshuai via Dnsmasq-discuss wrote:
My dhclient process received a Confirm message from dnsmasq-dhcp, when 
the dhclient process sent a Confirm message which contains a ip address 
that is not appropriate for the link to the dnsmasq-dhcp.


# tcpdump -i veth1 port 547

dropped privs to tcpdump

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode

listening on veth1, link-type EN10MB (Ethernet), snapshot length 262144 
bytes


15:12:51.998726 IP6 fe80::b0bb:d2ff:fea6:138d.dhcpv6-client > 
ff02::1:2.dhcpv6-server: dhcp6 confirm


15:12:51.998942 IP6 fe80::cb1:2aff:fe23:593f.dhcpv6-server > 
fe80::b0bb:d2ff:fea6:138d.dhcpv6-client: dhcp6 confirm


The reason is that dnsmasq-dhcp does not set the message type correctly.

---

src/rfc3315.c | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/rfc3315.c b/src/rfc3315.c

index c2e2692..3a52d0e 100644

--- a/src/rfc3315.c

+++ b/src/rfc3315.c

@@ -1101,7 +1101,7 @@ static int dhcp6_no_relay(struct state *state, int 
msg_type, unsigned char *inbu


     put_opt6_string(_("confirm failed"));

     end_opt6(o1);

     log6_quiet(state, "DHCPREPLY", _addr, 
_("confirm failed"));


-       return 1;

+   goto done;

   }

     good_addr = 1;

--

2.33.0


___
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] DHCPv6 doesn't work on Linux interfaces enslaved to a VRF

[Simon Kelley]

On 09/10/2023 11:40, Luci Stanescu wrote:

Hi Simon,

Thank you for your response and your openness to this issue! My thoughts 
below, inline (and apologies for the rather long email).



On 9 Oct 2023, at 01:05, Simon Kelley  wrote:
1) Even if this is a kernel bug, kernel bugs fixes take a long time to 
spread, so working around them in dnsmasq is a good thing to do, as 
long as it doesn't leave us with long-term technical debt. This 
wouldn't be the first time a kernel bug has been worked around.


I agree, that's why I've opened this discussion here.


2) https://docs.kernel.org/networking/vrf.html says:

Applications that are to work within a VRF need to bind their socket 
to the VRF device:

setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);
or to specify the output device using cmsg and IP_PKTINFO.

Which kind of implies that this might not be a kernel bug, rather 
we're just not doing what's required to work with VRF.


I'm not convinced this isn't a kernel bug. The VRF implementation has 
been developed in stages over several years. It is indeed the case that 
initially the sockets had to be bound to the VRF device or to specify it 
via IP_PKTINFO/IPV6_PKTINFO. But then came support for 
net.ipv4.*_l3mdev_accept sysctls (which confusingly also affect AF_INET6 
sockets) as well as a series of patches in 2018 that allowed specifying 
a VRF slave device for several operations. Before that series of 
patches, it certainly made sense for sin6_scope_id in msg_name for 
recvmsg() to be the VRF device (it had to be) – but I'm not convinced it 
shouldn't have been changed after the rules for connect() and sendmsg() 
were relaxed. The thing is, as it stands, the kernel code works well for 
everything except IPv6 link-local communication, so it wouldn't be 
surprising for this to be a simple oversight.


I had tracked this down while trying to figure out what's going on here 
and detailed a bit in the kernel bug report, which you can find here:


https://lore.kernel.org/netdev/06798029-660d-454e-8628-3a9b9e1af...@safebits.tech/T/#u
 
<https://lore.kernel.org/netdev/06798029-660d-454e-8628-3a9b9e1af...@safebits.tech/T/#u>

Setting the device to send to using IP_PKTINFO rather than relying on 
the flowinfo field in the destination address would be quite possible, 
and the above implies that it will work.


Apologies for being pernickety, but it's the scope_id field which is 
relevant here, rather than flowinfo. And since we're talking AF_INET6, 
shouldn't it be IPv6_PKTINFO?


My bad. I meant scope_id. It was late :(




I *think* it should work. I have been unable to find a situation where 
the scope received in the IPV6_PKTINFO cmsg to recvmsg() cannot be used 
to reliably send a response out the same interface (which I believe is 
exactly what DHCPv6 code will always want to do), but my word is 
certainly no guarantee. More about this towards the end of the email.


However, it'll only work as long as you do NOT specify a scope in the 
destination of the sendmsg() call or that scope specified is exactly the 
same as in the IPV6_PKTINFO ancillary message. Specifically, you cannot 
specify the VRF master device index. I've adapted my earlier scripts to 
test this and I've pasted them at the end of this email.



This brings us on to

3) IPv4. Does DHCPv4 work with VRF devices? It would be nice to test, 
and fix any similar problems in the same patch. Interestingly, the 
DHCPv4 code already sets the outgoing device via IP_PKTINFO (there 
being no flowinfo field in an IPv4 sockaddr) so it stands a chance of 
just working.


DHCPv4 works just fine. My dnsmasq configuration uses 'interface' to 
specify the VRF slave interface (which in my case is a bridge) and 
DHCPv4 messages are sent out correctly.


Copying the inferface index into the flowinfo of the destination or 
setting IP_PKTINFO are both easy patches to make and try. The 
difficult bit is being sure that they won't break existing installations.


My tests seem to imply that leaving the received scope_id field (which 
is the VRF master device index) unchanged and setting IPV6_PKTINFO won't 
work. Three options seem to work:
1. Overwrite scope_id of source address from recvmsg() with the 
interface index from the received IPV6_PKTINFO.
         2. When performing the sendmsg(), set the scope_id of the 
destination to 0 and add IPV6_PKTINFO with the the empty address (since 
the received IPV6_PKTINFO specifies the multicast address and that won't 
do as a source) and the interface index from the received IPV6_PKTINFO.
3. If the socket is bound to an L3 interface (not the VRF master 
device), just set the scope_id in the destination to 0 and IPV6_PKTINFO 
is not required. I'm not sure this'll work for dnsmasq, but I thought of 
including it for the sake of completeness.




This is good information.

I've implemented option 1 here and it's currently running and dogfood on 
my home network. There are no VRF interfaces there: this is 

Re: [Dnsmasq-discuss] [PATCH] Set pointers to NULL after memory is freed

[Simon Kelley]

On 08/10/2023 09:44, renmingshuai via Dnsmasq-discuss wrote:
Set pointers to NULL after memory is freed to reduce dangling pointers, 
although they are later set to new values.


 From 5567d99099191f0cdb2922555e6ade2634f94f30 Mon Sep 17 00:00:00 2001

From: renmingshuai 

Date: Sun, 8 Oct 2023 16:06:46 +0800

Subject: [PATCH] Set pointers to NULL after memory is freed

---

src/option.c | 3 +++

1 file changed, 3 insertions(+)

diff --git a/src/option.c b/src/option.c

index 286f06b..23601e1 100644

--- a/src/option.c

+++ b/src/option.c

@@ -5732,6 +5732,7 @@ static void clear_dynamic_conf(void)

    else

     up = >next;

  }

+  daemon->dhcp_conf = NULL;

}

static void clear_dhcp_opt(struct dhcp_opt **dhcp_opts)

@@ -5755,8 +5756,10 @@ static void clear_dhcp_opt(struct dhcp_opt 
**dhcp_opts)


static void clear_dynamic_opt(void)

{

    clear_dhcp_opt(>dhcp_opts);

+  daemon->dhcp_opts = NULL;

#ifdef HAVE_DHCP6

    clear_dhcp_opt(>dhcp_opts6);

+  daemon->dhcp_opts6 = NULL;

#endif

}




This doesn't work. The daemon->dhcp_opts etc linked lists have a mixture 
of dynamic (re-readable) and static (from command line and dnsmasq.conf) 
entries. After clearing the re-readable entries, there may be static 
ones left in the linked list, so NULLing the pointers will leak those 
and stop them working.



Cheers,

Simon.


--

2.33.0


___
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] Memory leak for SRV records with TTL=0 in v2.88

[Simon Kelley]

On 05/10/2023 16:56, Damian Sawicki via Dnsmasq-discuss wrote:

Hello dnsmasq experts,

There seems to be a memory leak in v2.88. The reproduction steps are
as follows: insert an SRV record with TTL=0 in an upstream DNS server
and query dnsmasq for this record. I inserted a record with name
"dnsmasq-reproduction.entirelynew.com." and 20 almost identical
entries of the form "0 1 587 mail.example.com." and queried dnsmasq at
12 qps: after an hour, the memory consumption increased by about 32
MB.

AFAIU, the leaking memory is allocated in rfc1035.c in


  if (!(addr.srv.target = blockdata_alloc(name, addr.srv.targetlen)))


(line 825 in v2.88). When the following insertion fails (and it fails
when ttl == 0 and daemon->min_cache_ttl == 0 in cache_insert)


  newc = cache_insert(name, , C_IN, now, attl, flags | F_FORWARD | 
secflag);


(line 867 in v2.88), the memory is never freed. I haven't reproduced a
leak in this scenario, but lines 829-830 also don't include
deallocation.


  if (!extract_name(header, qlen, , name, 1, 0))
return 2;


The relevant code hasn’t changed much between 2.81 and 2.89, so the
entire range might potentially be affected.

I’ve noticed the relevant part is currently being rewritten. Until a
new version is ready, the patch (not tested!) pasted below should
solve the problem. The default behaviour of Unbound is to serve stale
records with TTL=0 (see
https://unbound.docs.nlnetlabs.nl/en/latest/topics/core/serve-stale.html),
so this leak may affect many users.

I would be grateful if you could possibly let me know when the release
of v2.90 is planned. If something is not clear, or I could be of any
assistance regarding the leak, please don't hesitate to let me know!

Kind regards,

Damian Sawicki, 




That all makes sense.

You're right that this code being re-written: it's been generalised to 
cache any RR-type. That hasn't fixed the memory leak :( just generalized 
it. Now you can leak memory with TTL=0 records of almost any type!


I shall port your fix to the new code forthwith.

The 2.90 release is planned just as soon as I can tidy up all the loose 
ends. It's not hanging on any big upgrades and insoluble bugs, just on 
my finding time.


I think your patch misses one thing: you need to check that the address 
being inserted is a SRV record: it's a big union, and may be something 
completely different, so you can't rely on addr.srv.target without checking


if (!newc && (flags & F_SRV) && addr.srv.target)
  blockdata_free(addr.srv.target);


Cheers,

Simon.



-

The patch is identical for v2.88 and v2.89.

diff --git a/src/rfc1035.c b/src/rfc1035.c
index 5c0df56..e85fe2e 100644
--- a/src/rfc1035.c
+++ b/src/rfc1035.c
@@ -826,8 +826,10 @@ int extract_addresses(struct dns_header *header,
size_t qlen, char *name, time_t
 return 0;

   /* we overwrote the original name, so get it back here. */
- if (!extract_name(header, qlen, , name, 1, 0))
+ if (!extract_name(header, qlen, , name, 1, 0)){
+   blockdata_free(addr.srv.target);
 return 2;
+ }
 }
   else if (flags & (F_IPV4 | F_IPV6))
 {
@@ -865,6 +867,8 @@ int extract_addresses(struct dns_header *header,
size_t qlen, char *name, time_t
   if (insert)
 {
   newc = cache_insert(name, , C_IN, now, attl,
flags | F_FORWARD | secflag);
+ if (!newc && addr.srv.target)
+   blockdata_free(addr.srv.target);
   if (newc && cpp)
 {
   next_uid(newc);

___
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] DHCPv6 doesn't work on Linux interfaces enslaved to a VRF

[Simon Kelley]

On 07/10/2023 14:02, Luci Stanescu via Dnsmasq-discuss wrote:

Hi,

I've discovered that DHCPv6 doesn't work on Linux interfaces enslaved to 
a VRF. Now, I believe this to be a bug in the kernel and I've reported 
it, but in case you'd like to implement a workaround in dnsmasq, this is 
quite trivial, as I'll explain in a bit.


The issue is that when a datagram is received from an interface enslaved 
to a VRF device, the sin6_scope_id of the msg_name field returned from 
recvmsg() points to the interface index of the VRF device, instead of 
the enslaved device. Unfortunately, this is completely useless when the 
source address is a link-local address, as a subsequent sendmsg() which 
specifies that scope will fail with ENETUNREACH, as expected, 
considering the interface index of the enslaved device would have to be 
specified as the scope (there can of course be multiple interfaces 
enslaved to a single VRF device).


With DHCPv6, a DHCPSOLICIT is received from a link-local address and 
DHCPADVERTISE is sent to the source of that address, with a scope 
specified according to the scope from the msg_name field returned by 
recvmsg(). I've debugged this using strace, as dnsmasq doesn't print any 
errors when the send fails. Here is the recvmsg() call:


recvmsg(6, {msg_name={sa_family=AF_INET6, sin6_port=htons(546), 
sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "fe80::216:3eff:fed0:4e7d", 
_addr), sin6_scope_id=if_nametoindex("myvrf")}, msg_namelen=28, 
msg_iov=[{iov_base="\1\203\273\n\0\1\0\16\0\1\0\1,\262\320k\0\26>\320N}\0\6\0\10\0\27\0\30\0'"..., iov_len=548}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_IPV6, cmsg_type=0x32}], msg_controllen=40, msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 56


and the sending of the response later on:

sendto(6, 
"\2\203\273\n\0\1\0\16\0\1\0\1,\262\320k\0\26>\320N}\0\2\0\16\0\1\0\1,\262"..., 114, 0, {sa_family=AF_INET6, sin6_port=htons(546), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "fe80::216:3eff:fed0:4e7d", _addr), sin6_scope_id=if_nametoindex("myvrf")}, 28) = -1 ENETUNREACH (Network is unreachable)


Please notice that the scope is the index of the VRF master device, so 
the sendto() call is certain to fail.


When reporting the issue as a kernel bug, I reproduced the issue using 
local communication with unicast and a couple of simple Python scripts. 
Here's reproduction using local communication, but with multicast, to 
make it closer to home:


First, set up a VRF device and a veth pair, with one end enslaved to the 
VRF master (on which we'll be receiving datagrams) and the other end 
used to send datagrams.


ip link add myvrf type vrf table 42
ip link set myvrf up
ip link add veth1 type veth peer name veth2
ip link set veth1 master myvrf up
ip link set veth2 up

# ip link sh dev myvrf
110: myvrf:  mtu 65575 qdisc noqueue state UP 
mode DEFAULT group default qlen 1000

     link/ether da:ca:c9:2b:6e:02 brd ff:ff:ff:ff:ff:ff
# ip addr sh dev veth1
112: veth1@veth2:  mtu 1500 qdisc 
noqueue master myvrf state UP group default qlen 1000

     link/ether 32:63:cf:f5:08:35 brd ff:ff:ff:ff:ff:ff
     inet6 fe80::3063:cfff:fef5:835/64 scope link
        valid_lft forever preferred_lft forever
# ip addr sh dev veth2
111: veth2@veth1:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000

     link/ether 1a:8f:5a:85:3c:c0 brd ff:ff:ff:ff:ff:ff
     inet6 fe80::188f:5aff:fe85:3cc0/64 scope link
        valid_lft forever preferred_lft forever

The receiver:
import socket
import struct

s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
s.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_RECVPKTINFO, 1)
s.setsockopt(socket.SOL_SOCKET, socket.SO_BINDTODEVICE, b'veth1')
s.bind(('', 2000, 0, 0))
mreq = struct.pack('@16sI', socket.inet_pton(socket.AF_INET6, 
'ff02::1:2'), socket.if_nametoindex('veth1'))

s.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_JOIN_GROUP, mreq)

while True:
     data, cmsg_list, flags, source = s.recvmsg(4096, 4096)
     for level, type, cmsg_data in cmsg_list:
         if level == socket.IPPROTO_IPV6 and type == socket.IPV6_PKTINFO:
             dest_address, dest_scope = struct.unpack('@16sI', cmsg_data)
             dest_address = socket.inet_ntop(socket.AF_INET6, dest_address)
             dest_scope = socket.if_indextoname(dest_scope)
             print("PKTINFO destination {} {}".format(dest_address, 
dest_scope))

     source_address, source_port, source_flow, source_scope = source
     source_scope = socket.if_indextoname(source_scope)
     print("name source {} {}".format(source_address, source_scope))

And the sender:
import socket

s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
dest = ('ff02::1:2', 2000, 0, socket.if_nametoindex('veth2'))
s.sendto(b'foo', dest)

The receiver will print:
PKTINFO destination ff02::1:2 veth1
name source fe80::188f:5aff:fe85:3cc0 myvrf

Please notice that the receiver gets the right address, the one 
associated to veth2, but the scope identifies the VRF 

Re: [Dnsmasq-discuss] IPv6 addresses are (almost) immediately deprecated

[Simon Kelley]

On 22/09/2023 21:48, Graham Leggett via Dnsmasq-discuss wrote:

On 22 Sep 2023, at 20:27, Geert Stappers  wrote:


I have a dnsmasq config on a development machine that looks like this:

dhcp-range=fd33:::1::, ra-only, 24h

The intention is for this development machine to announce to anyone
directly connected that the development machine exists, and can be
connected to. No routing, no DNS, only “I exist”.

This almost works. On MacOS I’m getting an IP address allocated on
the expected interface, but almost immediately the address is declared
“deprecated”.


Why?


I was today-years-old when I learned there was such a thing as a 
deprecated IPv6 address. I am as confused as you are :)



This causes MacOS to ignore the direct connection and to route packets
to the router, which in turn has no idea what to do with the packets
and (correctly) drops them.

How do I get dnsmasq to tell anyone who cares that the IPv6 addresses
are valid and not deprecated?


I would start with only two computers: One being dnsmasq doing radvd,
the other one being told "you exist".


I am somewhat limited in the hardware I have available to me.

The development machine is currently running in virtualbox. Virtualbox 
local only networks appear to ignore IPv6 on the host, there is talk of 
setting /etc/vbox/networks.conf but this does not appear to work. 
Ignoring this side-quest for now.


Virtualbox bridging the development machine directly to the network 
works - but the IPv6 addresses are deprecated soon after being assigned, 
and so stop working after a short while.


The end goal is ease of use - deploy the development machine and off you 
go, but this seems to be weirdly difficult. Does anyone know what would 
trigger a deprecated IPv6 address to be created, and how to make it stop?




An IPv6 address gets deprecated if the subnet it's on gets advertised 
with a preferred lifetime of zero. I quick look  through the dnsmasq 
shows ways that this can happen when dnsmasq is doing the advertising. 
The first is setting the lifetime in dhcp-range to "deprecated", which 
isn't the case here, unless you've got other configuration hiding. The 
second is if the relevant address on the advertising machine is 
deprecated, so if the local address in the fd33:::1::/64 subnet 
on development machine that's running dnsmasq and send the adverts is 
deprecated, then dnsmasq will copy that state into it's advertisments.


This is quite sensible, especially when using the "constructed address" 
configuration. As new addresses appear on the advertising machine's 
interface, they get advertised, and as old one's start to die, that gets 
advertised too.


TL/DR; Looks at the network interface config on the machine running 
dnsmasq. That could be the source of the problem.


Cheers,

Simon.



Regards,
Graham
—


___
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] [PATCH] Fix DHCPv6 options memory leaks

[Simon Kelley]

Patch applied. The problem is clear and the fix is good.

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=d16b995756dc079b1fdc2e63665793979f766a26

Thanks for your contribution.

Cheers,

Simon.


On 28/09/2023 09:28, renmingshuai via Dnsmasq-discuss wrote:
When I repeatedly reloaded the dnsmasq process, I found a memory leak. 
To reproduce the problem, perform the following steps:


(1)Run dnsmasq as follows:

# dnsmasq --no-hosts --no-resolv --dhcp-optsfile=/tmp/opts 
--dhcp-range=set:subnet-368e344f-8862-46f5-897e-02602d2e0eaa,2003:0:0:1499::,static,64,2h


# cat /tmp/opts

tag:subnet-368e344f-8862-46f5-897e-02602d2e0eaa,option6:domain-search,openstacklocal

tag:subnet-368e344f-8862-46f5-897e-02602d2e0eaa,option6:dns-server,[2003:0:0:1499::2],[2003:0:0:1499::3]

(2) Send SIGHUP to dnsmasq repeatedly

# cat send.sh

#!/bin/bash

while true

do

    kill -HUP `pidof dnsmasq`

    sleep

done

# sh send.sh

After a period of time, the vmRss value of the dnsmasq process keeps 
increasing.


# date

Fri Sep 29 12:43:27 AM CST 2023

[root@localhost home]# ps -aux|grep dnsmasq

dnsmasq  3322571  0.0  0.0   9044  2456 ?    S    00:43   0:00 
dnsmasq --no-hosts --no-resolv --dhcp-optsfile=/tmp/opts 
--dhcp-range=set:subnet-368e344f-8862-46f5-897e-02602d2e0eaa,2003:0:0:1499::,static,64,infinite


# date

Fri Sep 29 01:09:28 AM CST 2023

# ps -aux|grep dnsmasq

dnsmasq  3322571  0.1  0.0   9772  3280 ?    S    00:43   0:02 
dnsmasq --no-hosts --no-resolv --dhcp-optsfile=/tmp/opts 
--dhcp-range=set:subnet-368e344f-8862-46f5-897e-02602d2e0eaa,2003:0:0:1499::,static,64,infinite


When we configure DHCPv6 option information by using –dhcp-optsfile, 
dnsmasq process allocates memory to store those information. However, 
when dnsmasq receives SIGHUP and reread the –dhcp-optsfile, it does not 
release the memory that store DHCPv6 options information as it does for 
DHCPv4 options.


The following patch could fix this problem.

---

src/option.c | 12 ++--

1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/option.c b/src/option.c

index 8322725..1cf2796 100644

--- a/src/option.c

+++ b/src/option.c

@@ -5734,11 +5734,11 @@ static void clear_dynamic_conf(void)

  }

}

-static void clear_dynamic_opt(void)

+static void clear_dhcp_opt(struct dhcp_opt **dhcp_opts)

{

    struct dhcp_opt *opts, *cp, **up;

-  for (up = >dhcp_opts, opts = daemon->dhcp_opts; opts; opts = cp)

+  for (up = dhcp_opts, opts = *dhcp_opts; opts; opts = cp)

  {

    cp = opts->next;

@@ -5752,6 +5752,14 @@ static void clear_dynamic_opt(void)

  }

}

+static void clear_dynamic_opt(void)

+{

+  clear_dhcp_opt(>dhcp_opts);

+#ifdef HAVE_DHCP6

+  clear_dhcp_opt(>dhcp_opts6);

+#endif

+}

+

void reread_dhcp(void)

{

     struct hostsfile *hf;

--

2.33.0


___
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] [PATCH] Fix DHCPv6 options memory leaks

[Simon Kelley]

On 01/10/2023 18:55, Geert Stappers wrote:



That looks good to me.  However:
|$ git am
|Applying: Fix DHCPv6 options memory leaks
|error: corrupt patch at line 11
|Patch failed at 0001 Fix DHCPv6 options memory leaks
|hint: Use 'git am --show-current-patch=diff' to see the failed patch
|When you have resolved this problem, run "git am --continue".
|If you prefer to skip this patch, run "git am --skip" instead.
|To restore the original branch and stop patching, run "git am --abort".
|$

See https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2023q3/017238.html
and make another attempt.






No need to make another attempt. The patch looks good to me and is 
running in my local tree now. It's be in the public repo before I finish 
for the day tonight.



Simon.




Groeten
Geert Stappers


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Blockdata SIGSEGV on master

[Simon Kelley]

On 05/09/2023 06:46, Geert Stappers wrote:

On Sun, Sep 03, 2023 at 08:38:00PM +0100, Simon Kelley wrote:

On 01/09/2023 20:28, Dominik Derigs wrote:

Dear Simon, CC mailing list,

today I've received a report of latest dnsmasq embedded into Pi-hole
crashing when www.facebook.com is visited (but only when logged in). I
was able to reproduce this myself after creating a (fake) account.

The hit/miss ratio is not 100% but it should be possible to trigger the
crash within a couple of tries. I tried Google Chrome on Linux for
reproducing the crash (the report was Chrome on Windows). For this test,
I used only one upstream server: 8.8.8.8



Dear list,

Offline, we've found this one. The patch is in git now. It needs arbitrary
RR caching to be enabled, and some fairly bad luck in what actually gets
cached, but Facebook obliges every once in a while.


Is it worth a next release?


Soon. But note that this problem is with new code added since the last 
stable release, so it's not needed to fix the current stable release.


Simon.





Groeten
Geert Stappers


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Blockdata SIGSEGV on master

[Simon Kelley]

Dear list,

Offline, we've found this one. The patch is in git now. It needs 
arbitrary RR caching to be enabled, and some fairly bad luck in what 
actually gets cached, but Facebook obliges every once in a while.



Cheers,

Simon.


On 01/09/2023 20:28, Dominik Derigs wrote:

Dear Simon, CC mailing list,

today I've received a report of latest dnsmasq embedded into Pi-hole
crashing when www.facebook.com is visited (but only when logged in). I
was able to reproduce this myself after creating a (fake) account.

The hit/miss ratio is not 100% but it should be possible to trigger the
crash within a couple of tries. I tried Google Chrome on Linux for
reproducing the crash (the report was Chrome on Windows). For this test,
I used only one upstream server: 8.8.8.8

A PCAP I recorded using dumpmask=0x is attached.

When the SIGSEGV happens, it can happen in a few different but related
code places, let me summarize the two location I found most often below:

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/blockdata.c;h=444a03a6798fce5da839f199df4a9326ab17188a;hb=HEAD#l217

Thread 1 "pihole-FTL" received signal SIGSEGV, Segmentation fault.
blockdata_retrieve (block=, len=13, data=0x556b98069ac0,
data@entry=0x0) at /app/FTL/src/dnsmasq/blockdata.c:217
217   memcpy(d, b->key, blen);
(gdb) where
#0  blockdata_retrieve (block=, len=13,
data=0x556b98069ac0, data@entry=0x0) at
/app/FTL/src/dnsmasq/blockdata.c:217
#1  0x556b95cd2092 in answer_request
(header=header@entry=0x556b9800e290, limit=limit@entry=0x556b9800e490
"", qlen=qlen@entry=31, local_addr=..., local_addr@entry=...,
local_netmask=...,
 local_netmask@entry=..., now=now@entry=1693587354,
ad_reqd=, do_bit=,
have_pseudoheader=, stale=,
filtered=)
 at /app/FTL/src/dnsmasq/rfc1035.c:2175
#2  0x556b95cac02d in receive_query
(listen=listen@entry=0x556b98002d60, now=now@entry=1693587354) at
/app/FTL/src/dnsmasq/forward.c:1921
#3  0x556b95c99b61 in check_dns_listeners (now=now@entry=1693587354)
at /app/FTL/src/dnsmasq/dnsmasq.c:1864
#4  0x556b95c9bd2d in main_dnsmasq (argc=,
argv=) at /app/FTL/src/dnsmasq/dnsmasq.c:1271
#5  0x556b95bfaf76 in main (argc=,
argv=0x76ee9598) at /app/FTL/src/main.c:152

sometimes the crash happens in

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/blockdata.c;h=444a03a6798fce5da839f199df4a9326ab17188a;hb=HEAD#l177

Thread 1 "pihole-FTL" received signal SIGSEGV, Segmentation fault.
blockdata_free (blocks=0x3368023268020600) at
/app/FTL/src/dnsmasq/blockdata.c:177
177 void blockdata_free(struct blockdata *blocks)
(gdb) where
#0  blockdata_free (blocks=0x3368023268020600) at
/app/FTL/src/dnsmasq/blockdata.c:177
#1  0x560c710c9715 in cache_scan_free
(name=name@entry=0x560c7272f6d0 "star.c10r.facebook.com",
addr=addr@entry=0x7ffe4bdaa9a0, class=class@entry=1,
now=now@entry=1693587879, flags=flags@entry=1082130440,
 target_crec=target_crec@entry=0x7ffe4bdaa870,
target_uid=0x7ffe4bdaa86c) at /app/FTL/src/dnsmasq/cache.c:541
#2  0x560c710cd43e in really_insert (name=0x560c7272f6d0
"star.c10r.facebook.com", addr=0x7ffe4bdaa9a0, class=1, now=1693587879,
ttl=60, flags=1082130440) at /app/FTL/src/dnsmasq/cache.c:657
#3  0x560c7110aa6e in extract_addresses
(header=header@entry=0x560c7273f290, qlen=,
name=0x560c7272f6d0 "star.c10r.facebook.com", now=now@entry=1693587879,
ipsets=ipsets@entry=0x0,
 nftsets=nftsets@entry=0x0, is_sign=0, check_rebind=0,
no_cache_dnssec=0, secure=0, doctored=0x7ffe4bdaaa9c) at
/app/FTL/src/dnsmasq/rfc1035.c:921
#4  0x560c710e39b6 in process_reply
(header=header@entry=0x560c7273f290, now=now@entry=1693587879,
server=0x560c7273d6d0, n=, n@entry=157, check_rebind=0,
no_cache=no_cache@entry=0,
 cache_secure=0, bogusanswer=0, ad_reqd=0, do_bit=0,
added_pheader=128, query_source=0x560c7278e150, limit=0x560c7273f760 "",
ede=) at /app/FTL/src/dnsmasq/forward.c:833
#5  0x560c710e86c0 in return_reply (now=now@entry=1693587879,
forward=forward@entry=0x560c7278e150,
header=header@entry=0x560c7273f290, n=157, n@entry=140730171042832,
status=)
 at /app/FTL/src/dnsmasq/forward.c:1397
#6  0x560c710e8c70 in dnssec_validate
(forward=forward@entry=0x560c7278e150,
header=header@entry=0x560c7273f290, plen=140730171042832,
status=, status@entry=524288, now=now@entry=1693587879)
 at /app/FTL/src/dnsmasq/forward.c:1109
#7  0x560c710e8c1a in dnssec_validate
(forward=forward@entry=0x560c72731a70,
header=header@entry=0x560c7273f290, plen=plen@entry=855,
status=status@entry=524288, now=now@entry=1693587879)
 at /app/FTL/src/dnsmasq/forward.c:1124
#8  0x560c710e9674 in reply_query (fd=,
now=now@entry=1693587879) at /app/FTL/src/dnsmasq/forward.c:1319
#9  0x560c710d5dff in check_dns_listeners (now=now@entry=1693587879)
at /app/FTL/src/dnsmasq/dnsmasq.c:1836
#10 0x560c710d7d2d in main_dnsmasq (argc=,
argv=) at /app/FTL/src/dnsmasq/dnsmasq.c:1271
#11 0x560c71036f76 in main (argc=,
argv=0x7ffe4bdab088) at 

Re: [Dnsmasq-discuss] Corrupted query causing FORMERR?

[Simon Kelley]

On 17/08/2023 18:08, John Horne wrote:

Hello,

We have for some time had reports of intermittent DNS query failures. For the
servers concerned, a client on the server causes a query to be sent (via
resolv.conf) to 127.0.0.1 which is the dnsmasq process. If the query is not in
the cache, then it is forwarded to a DNS resolver server running Unbound.

I have been running a short script which runs 'dig' every 10 seconds on a name.

The unbound servers shows entries such as:


Aug 16 21:08:48 unbound[1837198:1] query: 10.121.16.84
sauopprdwebsite1.blob.core.windows.net. A IN
Aug 16 21:08:48 unbound[1837198:1] reply: 10.121.16.84 - - - FORMERR - - -


The script/dig output shows


; <<>> DiG 9.11.36-RedHat-9.11.36-8.el8_8.1 <<>>
sauopprdwebsite1.blob.core.windows.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 59752
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sauopprdwebsite1.blob.core.windows.net.IN A

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 16 21:08:48 BST 2023
;; MSG SIZE  rcvd: 67



In running tcpdump (at a different time) showed that the query seemed to become
corrupted. It was still seen as a DNS query, but as can be seen it contains
part of a CNAME at the end, which in itself seems to be part of a reply to the
query. That is, the CNAME 'blob.dub08' is actually part of a CNAME that is part
of the reply for the DNS name 'sauopprdwebsite1.blob.core.windows.net'.
Very odd!

The tcpdump output was:

===
17:30:19.344158 IP (tos 0x0, ttl 64, id 53147, offset 0, flags [DF], proto UDP
(17), length 107)
10.121.16.84.38190 > 10.120.16.9.domain: [bad udp cksum 0x35b6 -> 0x96f9!]
32966+ [1au] A? sauopprdwebsite1.blob.core.windows.net. ar:
sauopprdwebsite1.blob.core.windows.net. CNAME[|domain]
0x: 4500 006b cf9b 4000 4011 3599 0a79 1054 E..k..@.@.5..y.T
0x0010: 0a78 1009 952e 0035 0057 35b6 80c6 0120 .x.5.W5.
0x0020: 0001   0001 1073 6175 6f70 7072 .sauoppr
0x0030: 6477 6562 7369 7465 3104 626c 6f62 0463 dwebsite1.blob.c
0x0040: 6f72 6507 7769 6e64 6f77 7303 6e65 7400 ore.windows.net.
0x0050: 0001 0001 c00c 0005 0001  0012 002d ...-
0x0060: 0462 6c6f 620f 6475 6230 38 .blob.dub08

17:30:29.357617 IP (tos 0x0, ttl 64, id 54580, offset 0, flags [DF], proto UDP
(17), length 107)
10.121.16.84.37068 > 10.120.16.9.domain: [bad udp cksum 0x35b6 -> 0xfd34!]
62988+ [1au] A? sauopprdwebsite1.blob.core.windows.net. ar: . OPT UDPsize=4096
(79)
0x: 4500 006b d534 4000 4011 3000 0a79 1054 E..k.4@.@.0..y.T
0x0010: 0a78 1009 90cc 0035 0057 35b6 f60c 0120 .x.5.W5.
0x0020: 0001   0001 1073 6175 6f70 7072 .sauoppr
0x0030: 6477 6562 7369 7465 3104 626c 6f62 0463 dwebsite1.blob.c
0x0040: 6f72 6507 7769 6e64 6f77 7303 6e65 7400 ore.windows.net.
0x0050: 0001 0001  2910    0c00 ..).
0x0060: 0a00 0820 2475 1b72 25a1 0e $u.r%..
===

The second tcpdump query output above correctly shows the 'OPT' record, and
resolves the query with no problems.


So, for some reason we are seeing corrupted DNS queries coming from dnsmasq to
the Unbound server. Anyone any ideas as to what could be causing this or what
could be checked?

For additional info, the client servers are typically running Rocky 8 Linux in
Azure with dnsmasq version 2.79. The Unbound server is a Rocky 9 Linux server
in Azure running Unbound version 1.16.
I have run the test script on Azure servers, a local VMware server and a local
physical server. The Azure servers show many FORMERR failures, the VMware has
only shown a few, and so far we had none from the physical server.

Things tried include, disabling the 'edns0' option in the /etc/resolv.conf
file; setting the max UDP packet size to 1232; setting the max UDP packet size
to 512; using dnsmasq version 2.89. These all failed in that we still received
FORMERR replies.
The only option so far that has worked is to disable the use of dnsmasq via
127.0.0.1, and let each server send queries direct to the Unbound server. This
has caused no FORMERR replies.




To recap:

Dnsmasq is somehow mangling a query before sending it to the upstream 
server.


This behaviour is not consistent: it doesn't always happen.

I'm not clear if this is just for the particular query in the example, 
or happens for others.


It seems to be associated with virtual servers.


What would be useful is to get packet dumps of the relevant packets: the 
query going into dnsmasq, the query going upstream from dnsmasq to 
unbound, the reply from unbound and the reply from dnsmasq to the 
original requestor. Possibly the easiest way to do that would be use the 
packet-dump facility built in to dnsmasq


--dumpfile=
--dumpmask=0x000F

and send me the resulting file.

Cheers,


Simon.








Thanks,

John.

Re: [Dnsmasq-discuss] Do we have good way to register SLAAC clients?

[Simon Kelley]

Dnsmasq has a feature, enabled by "ra-names" which attempts to solve 
this problem for dual-stack hosts.


It works like this.

When a host gets a DHCPv4 address, dnsmasq calculates the address that 
the client would assign itself using SLAAC, and pings that address. If 
it gets a reply it adds the address and the name derived from the DHCPv4 
transaction to the DNS.


This used to work for Android, but modern Android seems to have 
implemented SLAAC privacy extensions, which makes it impossible for 
dnsmasq to predict which SLAAC address  the host will chose (by design) 
and therefore breaks the hack.


Looking at the logs on my network, it's still working for a Chromecast 
and Nest Audio, but not the Android phones.


This isn't a good solution, but it's the best I've come up with.

Simon.



On 07/06/2023 15:46, Petr Menšík wrote:

Hello everyone.

I have attended IPv6 seminar yesterday (it was IPv6 day they said), 
where I have asked how to make similar registration of IPv6 address 
obtained by SLAAC with hostname of a client. They have said there 
Android is serious about not supporting DHCPv6 and that is not going to 
change except for Prefix Delegation.


Anyway, I have claimed on Fedora list [1] that the user friendly way to 
type IPv6 address is to type a name instead. Which is the best feature 
of dnsmasq I think, it provides DHCP clients registration in the dns 
out-of-the-box. Problem is SLAAC do not have any DHCP transaction, where 
they will tell us their name. So what works nicely on IPv4 networks, it 
does not on IPv6-only network. Or at least usually.


I thought whether a client on trusted network should try to use DNS 
UPDATE message  [2] on servers configured. Especially if the dns server 
is on the same network as the client, that might allow to "register" its 
name temporarily. If the client used domain sent over router 
advertisement message, would it be good idea to insert a limited time 
record just like for DHCP? Since there is no strong authentication in 
DHCP either, maybe we could accept update coming from the IP used in the 
record. And create also PTR record for it.


Is there any better way, how to provide more friendly names for IPv6 
devices? Sometime we want privacy instead, but that is not needed in 
trusted network like our own network. Apple devices use Multicast DNS to 
announce themselves anyway. Since IPv6 addresses are longer, they should 
have name resolution working by default. But they don't.


Do you know any best practice, how something similar is solved by other 
vendors? How should that be improved?


Cheers,
Petr

1. 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/Y4FBSNAO2NRWB3YAY6YWE5767ORZRSOY/

2. https://www.rfc-editor.org/rfc/rfc2136



___
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] TCP client timeout setting

[Simon Kelley]

On 26/05/2023 17:19, Simon Kelley wrote:

The long delay awaiting a connection from a non-responsive server may be 
improved by reducing the value of the TCP_SYNCNT socket option, at least 
on Linux.




Setting TCP_SYNCNT to 2 limits the delay for a non responsive address to 
about 8 seconds, which is mouch more sensible.


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] TCP client timeout setting

[Simon Kelley]

On 25/05/2023 20:32, Petr Menšík wrote:
This problem is best tested by an example, taken from [2] but a bit 
modified.


Let's create hepothetical network issue with one forwarder, which worked 
fine a while ago.


$ sudo iptables -I INPUT -i lo -d 127.0.0.255 -j DROP

Now start dnsmasq and send tcp query to it

$ dnsmasq -d --log-queries --port 2053 --no-resolv --conf-file=/dev/null 
--server=127.0.0.255 --server=127.0.0.1

$ dig +tcp @localhost -p 2053 test

;; communications error to ::1#2053: timed out
;; communications error to ::1#2053: timed out
;; communications error to ::1#2053: timed out
;; communications error to 127.0.0.1#2053: timed out

; <<>> DiG 9.18.15 <<>> +tcp @localhost -p 2053 test
; (2 servers found)
;; global options: +cmd
;; no servers could be reached

Because dig waits much shorter time than dnsmasq does, it never receives 
any reply. Even when the other server is responding just fine. That is 
main advantage of having local cache running, isn't it? It should 
improve things!


Now lets be persistent and keep trying:

$ time for TRY in {1..6}; do dig +tcp @localhost -p 2053 test; done

After few timeouts, it will finally notice something is wrong and tries 
also the second server, which will answer fast. However this works only 
with dnsmasq -d, which is not used in production. If I replace it with 
dnsmasq -k, it will not answer at all!


$ dnsmasq -k --log-queries --port 2053 --no-resolv --conf-file=/dev/null 
--server=127.0.0.255 --server=127.0.0.1

$ time for TRY in {1..8}; do dig +tcp @localhost -p 2053 test; done

...
;; communications error to ::1#2053: timed out
;; communications error to ::1#2053: timed out
;; communications error to ::1#2053: timed out
;; communications error to 127.0.0.1#2053: timed out

; <<>> DiG 9.18.15 <<>> +tcp @localhost -p 2053 test
; (2 servers found)
;; global options: +cmd
;; no servers could be reached


real    5m20,602s
user    0m0,094s
sys    0m0,115s

This is because with -k it spawns tcp workers, which start always with 
whatever last_server prepared by last UDP. And until any UDP query 
arrives to save the day, it will stubbornly try non-responding server 
first. Even when the other one answers in miliseconds. Notice it have 
been trying 5 minutes without success.


I think this has to be fixed somehow. This is corner case, because TCP 
queries are usually caused by UDP queries with TC bit set. But there 
exist real-world examples, where TCP only query makes sense. But dnsmasq 
does not handle them well. Summarized this at [3].


My proposal would be sending UDP query + EDNS0 header in case sending 
query failed to the main process, which can then trigger forwarders 
responsiveness and change the last_server to a working one. So 
subsequent attempts do not fall into the blackhole again and again. 
EDNS0 header would be there to increase chance for a positive reply from 
upstream, which can be cached.


Would you have other ideas, how to solve this problem?

Cheers,
Petr




The long delay awaiting a connection from a non-responsive server may be 
improved by reducing the value of the TCP_SYNCNT socket option, at least 
on Linux.



I think it's pretty easy to pass back the identity of a server which is 
responding to TCP connections to the main process using the same 
mechanism that passes back cache entries. The only wrinkle is if the 
list of servers changes between forking the child process and is sending 
back data about which server worked, for instance is the srever list 
gets reconfigured. Detecting that just needs an "epoch" counter to be 
included. It's rare, so just rejecting a "use this server" update from a 
child that was spawned in a different epoch from the current one should 
avoid problems. Provided the epoch is the same, indices into the 
server[] array are valid to send across the pipe.


I like the idea of using a different valid server for TCP and UDP.

Note that the TCP code does try to pick a good server. It's not 
currently much good with long connection delays, but it does cope with 
ignoring a server which accepts connections and then immediately closes 
them. I guess that must have been a real-world problem sometime.


Cheers,

Simon.

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2160466#c6
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2160466#c13

On 19. 05. 23 13:40, Petr Menšík wrote:
When analysing report [1] for non-responding queries over TCP, I have 
found forwarded TCP connections have quite high timeout. If for 
whatever reason the forwarder currently set as a last used forwarder 
is dropping packets without reject, the TCP will timeout for about 120 
seconds on my system. That is way too much, I think any TCP clients 
will give up far before that. This is just quick workaround to improve 
the situation, not final fix.


...

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2160466


___
Dnsmasq-discuss mailing list

Re: [Dnsmasq-discuss] DNSMASQ DHCP Options for CAPPORT or RFC8908 [PATCH]

[Simon Kelley]

What I can't get from a quick reading of the RFCs it how the 
captive-portal URI is derived from the client characteristics. The RFCs 
imply that the final, encoded part of the URI is an opaque identifier 
that's returned by the DHCP part of the captive portal and then accepted 
by the http part. It's not even clear to me that it needs to be unique 
to a client. Enlightenment on this matter would be appreciated.


One thing that should be done and it very easy is to add the RA option 
in the same way that others are just derived from the corresponding 
DHCPv6 option.


Simon.



On 26/05/2023 13:20, Florian Baaske via Dnsmasq-discuss wrote:

Hi Pert,

thanks for the help. Much appreciated.

I found something in regards to ISC as the DHCP server and thought that 
DNSMASQ might have the same feature.


BR
Florian

On Fri, May 26, 2023 at 12:26 PM Petr Menšík > wrote:


Added captive-portal DHCP option to database.

But I am afraid dnsmasq can serve different URLs only for explicitly
registered clients with separate options. It cannot make the url
dynamically based on incoming request. There is no script able to
customize offered options online.

On 5/26/23 09:16, Florian Baaske via Dnsmasq-discuss wrote:


Hi,
I would like to setup a Guest network with DNSMASQ. For that Guest
network, I would like to use CAPPORT or RFC8908.
To make this work, the DHCP server needs to send option 114, which
should not be a problem, but option 114 should have the URL to the
CAPPORT server including the MAC address of the client.
So, my questions would be, is it possible to include the clients
MAC address in the DHCP response?
I have found a solution for ISC DHCP but was not able to find
anything for DNSMASQ. If someone could help, this would be much
appreciated.

BR
Florian


___
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, RHEL
Red Hat,https://www.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 



___
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] dhcp-lease-max is only for DHCPv4?

[Simon Kelley]

In DHCPv6, the unique identifier for a client is NOT the MAC address, 
it's a client ID which sometimes contains the MAC address.


I suspect that dhclient is using the exact same client-id for each 
trial, and just renewing the existing lease. You will need to delete all 
the dhclient state after killing the process.


Simon.


On 23/05/2023 08:43, Linyih Teng wrote:

For the test.. i'm just curious, there is no other reason.

However, On the client side, I wrote simple scripts to run the dhclient, 
and this script will sequentially run 512 dhclient.(the number 512 is 
not a magic value, other values will happen same situation.)


steps of the script:

1. create macvlan interface(It will make different MAC address for
clients)

2. run dhclient with macvlan interface

3. get an IP from DHCPv6 server

4. kill the dhclient and remove the macvlan interface

5. back to step 1. and go on.


Results:

After scripts, if the 513th client comes, the server will serve the
IP to the 513th client.  but it is not just lease max + 1 th client
getting this issue, all after the 512th client can get IP from the
server.
At this time,  the lease entries are remaining at 512, and all after
clients will not appear in the lease file.



Thanks,
Lin



Geert Stappers mailto:stapp...@stappers.nl>> 於 
2023年5月23日 週二 下午1:59寫道：


On Tue, May 23, 2023 at 12:05:08AM +0100, Simon Kelley wrote:
 > On 22/05/2023 12:18, Linyih Teng wrote:
 > > In the manual page is written:
 > > > -X, --dhcp-lease-max=
 > > >        Limits  dnsmasq  to  the  specified  maximum number of
DHCP
 > > >        leases. The default is 1000. This limit is to 
prevent  DoS

 > > >        attacks from hosts which create thousands of leases
and use
 > > >        lots of memory in the dnsmasq process.
 > >
 > > Hello,
 > >
 > > I'm using dnsmasq2.89 and testing the maximum lease count of
the DHCPv6
 > > server with the *dhcp-lease-max* option.
 > >
 > > For the testing, I'm using below configuration:
 > >
 > >     *dhcp-lease-max* = 512
 > >     *dhcp-range*=tag:pool0,2022::1,2022::1f:::fffe,64,120m
 > >     tag-if=set:pool0,tag:intfv0
 > >
 > >
 > > However, when the number of clients reaches the maximum number, the
 > > server still provides IPs to clients. Is this the expected
behavior of
 > > DHCPv6?
 > >
 > There's a possible difference between the number of clients and
the number
 > of DHCP leases, since leases can expire to be deleted by the client.
 >
 > Are you saying that the number of simultaneous DHCP leases
increases without
 > bound, or that the 513th client gets a lease? Have you checked
the number of
 > leases in the dnsmasq.leases file?

Original Poster has yet to say what the expected behaviour should be.

Thing I am saying: Why limit dhcp-range by dhcp-lease-max?


Regards
Geert Stappers
-- 
Silence is hard to parse


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
<mailto:Dnsmasq-discuss@lists.thekelleys.org.uk>
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss 
<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


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dhcp-lease-max is only for DHCPv4?

[Simon Kelley]

There's a possible difference between the number of clients and the 
number of DHCP leases, since leases can expire to be deleted by the client.


Are you saying that the number of simultaneous DHCP leases increases 
without bound, or that the 513th client gets a lease? Have you checked 
the number of leases in the dnsmasq.leases file?



Simon.

On 22/05/2023 12:18, Linyih Teng wrote:

Hello,

I'm using dnsmasq2.89 and testing the maximum lease count of the DHCPv6 
server with the *dhcp-lease-max* option.


For the testing, I'm using below configuration:

*dhcp-lease-max* = 512
*dhcp-range*=tag:pool0,2022::1,2022::1f:::fffe,64,120m
tag-if=set:pool0,tag:intfv0


However, when the number of clients reaches the maximum number, the 
server still provides IPs to clients. Is this the expected behavior of 
DHCPv6?



Best Regards,
Lin

___
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] use-stale-cache may failed to refresh record from certain upstream

[Simon Kelley]

On 30/04/2023 20:42, Justin wrote:

Hello devs

in order to use DOH/DOT, a proxy upstream is configured, when dnsmasq 
enables use-stale-cache, some upstream may return error when dnsmasq 
tries to refresh the record from upstream after stale cache is sent to 
client.


i reported the issue here in dnsproxy project, as this is the DOH proxy 
i am currently using. however i've tried many other Go/Rust DOH proxy ( 
namely doh-client, dns-over-https, dnss, cloudflared) , they all return 
error when dnsmasq tries to refresh the record.


https://github.com/AdguardTeam/dnsproxy/issues/328 



only reproducible :  if the requesting client is macOS and the upstream 
is a DOH proxy, Linux does not have this issue. using a udp upstream 
like 1.1.1.1 does not have this issue either.


hope you could take a look at the issue posted.



I think I've found and fixed the problem, but I don't have a macOS 
machine to test with, nor have a I configured a DOH proxy, so I'd 
appreciate it if you could re-run your tests and see if it works with 
the patch in place.



https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=d774add784d01c8346b271e8fb5cbedc44d7ed08

Thanks for the very useful bug report.


Cheers,

Simon.




--

Regards
Justin He
--

Regards
Justin He

___
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] dnsmasq sending advertise packets for the packet containing server id

[Simon Kelley]

On 24/04/2023 05:41, shashikumar Shashi wrote:

Hi,

I am using dnsmasq-2.80, IN this I am observing dnsmasq sending the 
advertising packets for the packet containing the Server id.
This is a violation of the RFC - 
https://www.rfc-editor.org/rfc/rfc3315#section-15.2 



Below is my packet:
0x:  0001 0002 0050 5696 5000 86dd 6000
0x0010:  003a 11ff fe80    0250
0x0020: 56ff fe96 5000 ff02    
0x0030:  0001 0002 0222 0223 003a ac9b 01ac
0x0040: 1a04 0002 0012 554e 5553 4544 2d53 4552
0x0050: 5645 522d 4455 4944 0001 0004 3e74 dd1b
0x0060: 0003 000c 6848 70e4    


Is there any known issue??




Thanks for the report. I've just pushed a code change which improves the 
checking of received packets to conform better with section 15.


https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=7500157cff8ea28ab03e6e62e0d1575e4d01746b

Out of interest, did this cause problems in a real installation, or were 
you running a test suite?



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] Confusion about "no address range available for DHCPv6 request via ..."

[Simon Kelley]

On 18/04/2023 09:40, Daniel Farina wrote:

Hello everyone,

I have been trying to set up an IPv6-only network for a virtual machine 
with route advertisements and DHCP configuration. I've had some success, 
but I have a question.


I have a dnsmasq.conf that looks like this, to delegate a /80 chunk of a 
/64 network to a virtual machine:


interface=tapvm4qyj3a
enable-ra
dhcp-authoritative
leasefile-ro
ra-param=tapvm4qyj3a,mtu:1280,high,60,1200
dhcp-range=2a01:4f9:2b:35a:7df2::2,2a01:4f9:2b:35a:7df2::2,80

If I have an address configuration like this on the host outside the 
virtual machine, it works well:


3: tapvm4qyj3a:  mtu 1500 qdisc 
fq_codel state UP group default qlen 1000

     link/ether 82:d6:93:69:72:82 brd ff:ff:ff:ff:ff:ff
     inet6 2a01:4f9:2b:35a:7df2::1/80 scope global
        valid_lft forever preferred_lft forever
     inet6 fe80::80d6:93ff:fe69:7282/64 scope link
        valid_lft forever preferred_lft forever

The thing I find dissatisfying about this is that the VM is not able to 
listen on 2a01:4f9:2b:35a:7df2::1 anymore once I've done this, is my 
understanding: the host will process the traffic, right? If I remove the 
address on the guest's network, dnsmasq warns me repeatedly, and does 
not work:


ip addr del 2a01:4f9:2b:35a:7df2::1/80  dev tapvm4qyj3a

dnsmasq-dhcp: no address range available for DHCPv6 request via tapvm4qyj3a
dnsmasq-dhcp: no address range available for DHCPv6 request via tapvm4qyj3a
dnsmasq-dhcp: no address range available for DHCPv6 request via tapvm4qyj3a
...

My question is partially that of norms: is it normal to squat on a bit 
of the guest's address space like this? Is there a preferred way that 
avoids this, or does something different still? I know that a number of 
non-SLAAC configurations tend to sit on ::2 as the first unicast 
address, is this related to the reason why?


I will be expanding my use of dnsmasq to DNS, so this may figure in the 
answer.



Interesting question.

The short answer is no. Dnsmasq relies on matching the addresses in a 
dhcp-range with the address on an interface to map from an arrival 
interface to a suitable address range. This design started when the DHCP 
support only handled IPv4, and DHCPv4 requires that the server has a 
globally routable address, so there was no conflict. The same system was 
adopted for IPv6 for consistency.


DHCPv6 uses link-local multicast, so I think you're right, a DHCPv6 
server can issue leases for addresses on a subnet without having an 
address on that subnet. Dnsmasq can't do it because it has no way to 
associate the subnet with the address on which the request arrived, 
because of the configuration design inherited from the DHCPv4 server.


I'm not sure there's much incentive to change this: it's not as if 
addresses are scarce in the IPv6 world.



Cheers,


Simon.



Thank you for considering my question.

___
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] --server=/#/1.2.3.4 behavior

[Simon Kelley]

On 26/04/2023 12:26, Aleksey Vasenev wrote:

I found some information in the changelog:

"Of course --server=/#/1.2.3.4 is exactly equivalent to 
--server=1.2.3.4. Special request from Josh Howlett."


But this is not true. --server=/#/1.2.3.4 takes precedence over 
--server=1.2.3.4. Moreover, other servers are ignored.


Is this a bug or undocumented behavior?




In the latest code?

Can you demonstrate this?


Simon.

___
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] Behavior on DHCP denied

[Simon Kelley]

On 18/04/2023 16:35, 0zl wrote:

Hello,

This is an issue I've experienced with ESP8266 and proxy ARP on my WiFi 
network. I was able to work around it by assigning the devices an 
infinite lease, however I think dnsmasq's behavior is undesirable.


In short, ESP8266 is on a network with proxy ARP setup; getting the 
initial lease works fine, however once proxy ARP kicks in it fails to 
renew. This is the chain of events leading up to the issue:


  * MCU tries to renew the address
  * dnsmasq properly renews its address
  * MCU sends an ARP request to check if the address is in use and
receives an ARP reply from the router because of proxy ARP
  * MCU mistakenly believes that the address was assigned already even
though it was not, sends a DENIED message back to dnsmasq and tries
again
  * dnsmasq then allocates the exact same address that the MCU just rejected

I think in this scenario, dnsmasq should try to allocate a different 
address because MCU has rejected it already.


Not sure what people in this mailing list think, but it feels like 
dnsmasq shouldn't be doing this.


This situation was considered and there should be sensible behaviour.

Dnsmasq uses a hash of the MAC address to determine which the address to 
offer to the client, which would cause the same address always to be 
offered to the client. But if a client returns a DHCPDECLINE reply then 
a global variable is incremented. That variable is also used as an input 
to the hash function, so when the client asks again for an address it 
should get offered a different one.


So, this situation has been considered, but something is going wrong in 
your setup. Please could you post more details of the configuration you 
are using and logs of what happens so we can try and work out what is 
going wrong?



Cheers,

Simon.




All the best,
0zl.


___
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] [PATCH] DBus watchers change can trigger crash

[Simon Kelley]

Both patches applied.

Cheers,

Simon.

On 17/04/2023 12:30, Petr Menšík wrote:

Hi!

Interesting crash in dnsmasq were reported to me. I can reproduce it 
reliably on RHEL9, but not anymore on the most recent Fedora. But the 
difference seems to be based on used dbus library, not depending on 
dnsmasq code. RHEL9 dbus libraries installs 2 daemon->watchers, Fedora 
rawhide version does not. If those watchers are present and dbus system 
instance is restarted, dnsmasq crashes. RHEL9 uses 
dbus-libs-1.12.20-7.el9_1.x86_64.


If I configure dnsmasq to use dbus and then restart dbus.service with 
watchers present, it crashes dnsmasq. The reason is simple, it uses loop 
to walk over watchers to call dbus handling code. But from that code the 
same list can be modified and watchers removed. But the list iteration 
continues anyway.


In my first patch I fixed that problem by restarting the loop if list 
were modified.


Second patch is just optimization of socket events handling of dbus. 
Reduces calls to locate the file descriptor structure. Should lower CPU 
usage when monitoring dbus watches. It is not directly related to the 
issue, I just noticed repeated function calls where just one were needed.


Red Hat bug: https://bugzilla.redhat.com/show_bug.cgi?id=2185878

Cheers,
Petr


___
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] Add more dhcp log about finding dhcp-config failed

[Simon Kelley]

I've committed an alternative patch which does the same thing, but only 
in the DHCPv6 code path.



Cheers,

Simon.


On 17/04/2023 12:56, renmingshuai via Dnsmasq-discuss wrote:

Hi !

When dnsmasq attempts to search for the configured DHCPv6 address based 
on the MAC address, it will send NS packets to obtain the client MAC 
address. If dnsmasq fails to obtain the MAC address because any net 
reason, it cannot find the configured DHCPv6 address. As a result, the 
client cannot obtain the MAC address as expected. Adding some dhcp logs 
about finding dhcp-config failure will help users to find the cause more 
quickly.



___
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] proxy-dnssec, how does it work (with unbound as upstream)

[Simon Kelley]

On 17/04/2023 01:10, Petr Menšík wrote:
I do not understand why should be proxy-dnssec caching unreliable. It 
should be as simple as storing AD bit from the reply in cache entry. I 
expect just extra bit is something we can afford. 



I explained this somewhere up-thread. The problem is that there's one AD 
per reply, but possibly more than one RR per reply. The AD bit is only 
set if ALL the RRs are validated.


The canonical example is a reply which is a CNAME to an A or  where 
the CNAME is DNSSEC protected but the A or  is not. The AD bit will 
be clear, leading to the CNAME getting cached without its validated 
status. See www.comcast.com for a real world  example.




Network Manager should
stop passing dnssec-proxy in case it is configured via DBus however. I 
think this is not what people really want and definitely not when remote 
resolvers addresses are provided and not really protected. 



Far better 
would be ability to configure DNSSEC validation per connection. I hope I 
will find time to prepare a change allowing to do that soon. Would need 
just DBus interface to turn validation on and off. Trust anchor can stay 
present always.


Are you talking about upstream connections? If so, there's something 
like that in position already.


Something like

server=/example.com/1.2.3.4

will suppress DNSSEC validation when forwarding *.example.com to 1.2.3.4 
UNLESS there's a trust anchor configured for example.com.


That covers the most obvious case, and I can't think of others that need 
more explicit control. DO you have any?



Cheers,

Simon.



On 4/13/23 23:15, Simon Kelley wrote:

I'm not clear where the EDE in a reply fits in to this.

I agree, it seems to be all about AD bit in reality.


--proxy-dnssec does only one thing: it stops dnsmasq from zeroing the 
authenticated data (AD) bit in replies before returning them to 
clients. This means that clients can rely on the AD bit to tell if the 
answer is secure, with a couple of caveats.


1) The path  between dnsmasq and it's upstream servers is trusted. 
There's nothing to stop an attacker spoofing answers with the AD bit 
set since there's no cryptographic validation being done by dnsmasq.


2) Dnsmasq caching must be off. The AD bit is NOT cached, so replies 
from the dnsmasq cache will always have the AD bit set to zero. Only 
replies coming direct from upstream queries potentially have the AD 
bit set. This is why the man page tells you to set the cache size to 
zero.
This seems somehow easy to fix. Just save AD bit when proxy-dnssec is 
enabled. Or save it always, but after AD bit is reset when not using 
proxy-dnssec.


The reason why caching the AD bit isn't done is that it doesn't work 
because the AD bit refers to ALL the answers in to answer section: 
it's set only if they are all validated. If only some of the answers 
are validated, AD will be zero, and when a validated answer is cached, 
the validation status will be wrong.
It seems to be just small corner case, which does not matter usually. If 
we do not mark the response with AD bit which still was, it is not a big 
deal. A problem it would be if we marked response which had not it in 
the original answer.


A real world example is www.comcast.com comcast.com is DNSSEC signed, 
and www.comcast.com is a CNAME to a CDN which is not validated. If you 
lookup the CNAME www.comcast.com you'll get an AD bit set.



; <<>> DiG 9.16.1-Ubuntu <<>> CNAME www.comcast.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41970
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, 
ADDITIONAL: 1


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.comcast.com.    IN    CNAME

;; ANSWER SECTION:
www.comcast.com.    6962    IN    CNAME www.comcast.com.edgekey.net.

;; Query time: 0 msec
;; SERVER: 192.168.8.129#53(192.168.8.129)
;; WHEN: Thu Apr 13 22:00:40 IST 2023
;; MSG SIZE  rcvd: 85

But if you lookup the A record for www.comcast.com you'll get the same 
CNAME and A record it points to.


; <<>> DiG 9.16.1-Ubuntu <<>> www.comcast.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6633
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 03 ("..")
;; QUESTION SECTION:
;www.comcast.com.    IN    A

;; ANSWER SECTION:
www.comcast.com.    6901    IN    CNAME www.comcast.com.edgekey.net.
www.comcast.com.edgekey.net. 11680 IN    CNAME e523.dscb.akamaiedge.net.
e523.dscb.akamaiedge.net. 0    IN    A    23.40.214.165

;; Query time: 0 msec
;; SERVER: 192.168.8.129#53(192.168.8.129)
;; WHEN: Thu Apr 13 22:01:41 IST 2023
;; MSG SIZE  rcvd: 145


Now either edgekey.net or akamaiedge.net or both are not signed, so 
the AD bit is zero. Caching the www.comcast.com CNAME from t

Re: [Dnsmasq-discuss] proxy-dnssec, how does it work (with unbound as upstream)

[Simon Kelley]

I'm not clear where the EDE in a reply fits in to this.

--proxy-dnssec does only one thing: it stops dnsmasq from zeroing the 
authenticated data (AD) bit in replies before returning them to clients. 
This means that clients can rely on the AD bit to tell if the answer is 
secure, with a couple of caveats.


1) The path  between dnsmasq and it's upstream servers is trusted. 
There's nothing to stop an attacker spoofing answers with the AD bit set 
since there's no cryptographic validation being done by dnsmasq.


2) Dnsmasq caching must be off. The AD bit is NOT cached, so replies 
from the dnsmasq cache will always have the AD bit set to zero. Only 
replies coming direct from upstream queries potentially have the AD bit 
set. This is why the man page tells you to set the cache size to zero.


The reason why caching the AD bit isn't done is that it doesn't work 
because the AD bit refers to ALL the answers in to answer section: it's 
set only if they are all validated. If only some of the answers are 
validated, AD will be zero, and when a validated answer is cached, the 
validation status will be wrong.


A real world example is www.comcast.com comcast.com is DNSSEC signed, 
and www.comcast.com is a CNAME to a CDN which is not validated. If you 
lookup the CNAME www.comcast.com you'll get an AD bit set.



; <<>> DiG 9.16.1-Ubuntu <<>> CNAME www.comcast.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41970
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.comcast.com.   IN  CNAME

;; ANSWER SECTION:
www.comcast.com.6962IN  CNAME   www.comcast.com.edgekey.net.

;; Query time: 0 msec
;; SERVER: 192.168.8.129#53(192.168.8.129)
;; WHEN: Thu Apr 13 22:00:40 IST 2023
;; MSG SIZE  rcvd: 85

But if you lookup the A record for www.comcast.com you'll get the same 
CNAME and A record it points to.


; <<>> DiG 9.16.1-Ubuntu <<>> www.comcast.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6633
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 03 ("..")
;; QUESTION SECTION:
;www.comcast.com.   IN  A

;; ANSWER SECTION:
www.comcast.com.6901IN  CNAME   www.comcast.com.edgekey.net.
www.comcast.com.edgekey.net. 11680 IN   CNAME   e523.dscb.akamaiedge.net.
e523.dscb.akamaiedge.net. 0 IN  A   23.40.214.165

;; Query time: 0 msec
;; SERVER: 192.168.8.129#53(192.168.8.129)
;; WHEN: Thu Apr 13 22:01:41 IST 2023
;; MSG SIZE  rcvd: 145


Now either edgekey.net or akamaiedge.net or both are not signed, so the 
AD bit is zero. Caching the www.comcast.com CNAME from this answer will 
cache it as unvalidated, so a subsequent query which answers from the 
dnsmasq cache will give the wrong value for the AD bit. Caching AD bits 
from upstream is impossible to do correctly, so dnsmasq doesn't try.


There's not much reason not to do DNSSEC validation in dnsmasq in this 
case. The cost is extra DNS records that dnsmasq needs to do the 
validation, but by the time dnsmasq gets an answer it needs to validate, 
those records are necessarily cached in knot or unbound because they've 
already done validation.


I'd like to know how EDE replies are being used, and what the changes 
referred to in this statement by Peter are.


"Note that the changes made by the pi-hole developers have been
implemented in pi-hole-FTL, the dnsmasq code for proxy-dnssec hasn't
been changed, so using EDE only works with pi-hole, not with the
official dnsmasq v2.89"


Cheers,

Simon.


On 13/04/2023 11:15, Peter Russel wrote:

Hi

Simon, you question (summary of what you're trying to achieve)

Obviously, I'm running pihole-FTL, which is dnsmasq + pi-hole features.

- dnsmasq is configured with unbound as upstream
- dnsmasq cache-size= 0
- dnsmasq DNSSEC not enabled
- unbound (latest master compiled) as recursive resolver with DNSSEC
- unbound uses cachedb module (redis)
- unbound is configured to use response policy zones (RPZ)
- knot-resolver used for entries like "server=/v.firebog.net/127.10.10.5#"
- knot resolver has DNSSEC capabilities.

A lot of websites are hosted at cloud providers, this implies some
regular websites have the same IP as known DOH servers, that are
listed in one of my RPZ zones.

The RPZ zone looks like (example):
dns.opendns.com CNAME .
32.220.220.67.208.rpz-ip CNAME .
32.222.222.67.208.rpz-ip CNAME .
128.35.zz.35.119.2620.rpz-ip CNAME .
128.53.zz.53.119.2620.rpz-ip CNAME .

Both the domain and the IP are blocked by unbound RPZ.
In order to allow me to visit regular sites, sharing the same IP as
the known DOH server, I use knot-resolver (server= entries), this to
bypass the RPZ config for known regular sites.

Since, in my opinion, it isn't very efficient to have 

Re: [Dnsmasq-discuss] proxy-dnssec, how does it work (with unbound as upstream)

[Simon Kelley]

On 13/04/2023 07:37, Peter Russel wrote:

Hi Simon

Unfortunately, it looks like I've been shouting victory a little soon.

The results are perfect when using dig, however, when using a browser
(firefox, edge) the results are unreliable / inconsistent.

The assumption is that adding the setting "add-cpe-id=01234" ensures
dnsmasq will ALWAYS request EDE information from upstream (unbound).
Can you confirm this?


Assuming that by "request EDE information" you mean, "add an EDNS0 RR to 
the query so that unbound has somewhere to return the EDE record" then
the only obvious condition where this won't happen as a result of 
configuring "add-cpe" is if doing so would make the UDP packet too 
large. Since we're talking about queries and not answers here, that's 
very unlikely. It does raise the question of what Unbound does when 
adding EDE information pushes an answer over the packet size limit. Does 
it ditch the EDE, or set the truncated bit to force a retry over TCP?




There are currently 2 possible causes why it doesn't work perfectly.

1. the dnsmasq setting "add-cpe-id=01234" doesn't do what is expected
(always request EDE)

2. unbound doesn't store the EDE information in it's cache. Apparently
there are two PRs that haven't been merged in to master yet, that
would accomplish this, see the unbound issue
https://github.com/NLnetLabs/unbound/issues/873, comment from gthess.

Note that I also have knot-resolver installed on my system (using it
for script related tasks - normally inactive).
The pi-hole scripts will use knot-resolver as upstream (configured
using server= dnsmasq setting, example
"server=/v.firebog.net/127.10.10.5#"). The results from queries
with knot-resolver as upstream are also inconsistent. I have no idea
if knot-resolver caches EDE info, there is a lot less info available
for knot-resolver...

I'm waiting for the unbound PR's to be merged in to master, so I can
compile unbound with these changes, possibly excluding or confirming
this as the cause.

Could you confirm the setting "add-cpe-id=01234" does instruct dnsmasq
to always request EDE, if NOT, is it possible to do this in another
way?

Note that the changes made by the pi-hole developers have been
implemented in pi-hole-FTL, the dnsmasq code for proxy-dnssec hasn't
been changed, so using EDE only works with pi-hole, not with the
official dnsmasq v2.89

Don't know if you have a direct line with the pi-hole developer, if
you do, you could discuss this directly, I'm just the middle man here,
knowledgeable enough to test, not to change the code...



I'm in contact with the pi-hole people.


Can  I ask a favour? Could you post here a summary of what you're trying 
to achieve, what the problem(s) are and what the solutions are? The 
thread you posted no doubt has that information, but extracting it when 
coming in cold is hard and time-consuming.


Cheers,

Simon.



___
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] "no address range available for DHCP request via br0" when using for IPv6 RA

[Simon Kelley]

On 11/04/2023 14:04, Ben Hendin wrote:

" looks like we need
--no-dhcpv4-interface and --no-dhcpv6-interface. That would certainly
solve your problem."

Just to clarify - you are stating that these options don't currently 
exist and would need to be implemented in a future version?


Affirmative. I've just implemented them for the next release.

I have blocked the request via ebtables on my device for now and this 
seems to work until a more supported solution is available.


Also, in regards to the dhcp-options/tag syntax.  What is the preferred 
way to define multiple dhcp-options statements for different scopes?

It sounds list if I have:

eth1 with 192.168.1.1
eth2 with 10.10.10.1
and
dhcp-range=192.168.1.50-192.168.1.100
dhcp-range=10.0.0.100-10.0.0.150

That when the requests come in on those interfaces they will be 
"automagically" tagged with eth1/eth2.

You can add additional tags, but they are not strictly necessary.

Correct


dhcp-option=ABC
dhcp-option=XYZ

How does dnsmasq know which of those two defined options to provide to 
clients in their respective scopes if I have not configured a tag, or 
somehow correlated them to each individual range?




It doesn't. You need to specify which one gets used with tags. Just 
using the automatically provided interface name tags is enough in this case.


dhcp-option=tag:eth1,ABC
dhcp-option=tag:eth2,XYZ


tagged options are used when the tag(s) match, with fallback to untagged 
options. If there's more than one possible option, which one actually 
gets used is undefined.


Simon.



thanks!



On Mon, Apr 10, 2023 at 4:29 PM Simon Kelley <mailto:si...@thekelleys.org.uk>> wrote:




On 05/04/2023 19:04, Ben Hendin wrote:
 > Thanks Simon (apologies - my first reply went to your direct email
 > instead of back to the list which was not my intent!)
 >
 > There are dhcp4 ranges defined, but none with ranges for those
interface.
 > For example, the interface which should give out the RAs is br0,
and the
 > relevant lines are:
 >
 > ra-param=br0,10,600
 > enable-ra
 > quiet-ra
 > dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
 >
 > But the device has other interfaces, for example br1 and br2
which have
 > the following configuration:
 >
 > interface=br1
 > dhcp-range=br1,192.168.101.2,192.168.101.254,255.255.255.0,86400s
 > dhcp-option=br1,3,192.168.101.1
 > interface=br2
 > dhcp-range=br2,192.168.102.2,192.168.102.254,255.255.255.0,86400s
 > dhcp-option=br2,3,192.168.102.1
 >
 > My understanding is that the line "interface=X" (e.g.
interface=br1) is
 > needed to actually enable dnsmasq to listen *at all* on that
interface.
Almost. If there are no "interface=X" options at all, then dnsmasq will
listen on all interfaces.

 > But the use of br1 on the range/option lines is an arbitrary tag to
 > simply associate those two options together.
That usage seems to be common folklore, actually it does nothing in
this
case. dhcp-option=br1,. is the same as dhcp-option=set:br1, for
long-dead backwards compatibility reasons. So it sets the tag "br1" for
DHCP transactions which arrive via br1. But a tag with the same name as
the interface is always automagically set so a "br1" tag exists anyway,
and the presence of br1 in the dhcp-option has no effect.

 >
 > IOW, a particular dhcp-range is not associated with an interface
using
 > any explicit command, rather if a dhcp-range is defined and an
interface
 > that is defined with "interface=X" is bound to that subnet it
will serve
 > requests from the defined range?

That's correct.
 >
 > So I do have dhcp4 ranges defined, and I want those serving out
those
 > IPs on the interfaces that are on those ranges, but I don't
expect any
 > DHCPv4 traffic to be answered on br0.
 >
 > I'm sure I can write iptable rules to block that, but something
tells me
 > that isn't the elegant way and perhaps there is a dnsmasq
configuration
 > methodology that I am overlooking???


The whole interface= access control started when dnsmasq only did DNS,
and when DHCP was added it defaulted to doing both services on the same
set of interfaces, which is sensible default. To account for
configurations where DNS would be provided on interfaces where DHCP
wasn't wanted, the --no-dhcp-interface option was added. (Providing
DHCP
on an interface but not DNS is not supported.)  Logically, now that
DHCP
has bifurcated into DHCPv4 and DHCPv6 it looks like we need
--no-dhcpv4-interface and --no-dhcpv6-interface. That would certainly
solve your problem.

Re: [Dnsmasq-discuss] proxy-dnssec, how does it work (with unbound as upstream)

[Simon Kelley]

On 09/04/2023 18:50, Peter Russel wrote:

SOLVED

The developers added code to pihole-FTL, which is the latest dnsmasq +
features (to make pi-hole the better solution).

full story (pi-hole forum) here:
https://discourse.pi-hole.net/t/dnssec-discussion-support-for-proxy-dnssec/62217




That was quite the read. Am I right in thinking there's no need for any 
changes to dnsmasq arising?


Cheers,

Simon.


___
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] Understand logging - don't find details

[Simon Kelley]

On 11/04/2023 17:21, web...@manfbraun.de wrote:

Hello!
I want to find out the response time from clients request up to 
dnsmasq's response
(including the external answer!) to the client. But a look into the 
logfile - thought, easy

to make a wrapper, because I am missing dnstap support - wonders me.
For example, here a short excerpt, omitting the date, I cut out of a 
contueing block:
dnsmasq[315]: 86114 192.120.33.206/55020 query[PTR] 
155.33.120.192.in-addr.arpa from 192.120.33.206
dnsmasq[315]: 86114 192.120.33.206/55020 /etc/dnsmasq.d/hosts 
192.120.33.155 is proxy.lan.local


dnsmasq[315]: 86115 192.120.33.206/55020 query[A] stackoverflow.com from 
192.120.33206
dnsmasq[315]: 86115 192.120.33.206/55020 forwarded stackoverflow.com to 
208.67.222.222
dnsmasq[315]: 86115 192.120.33.206/55020 reply stackoverflow.com is 
151.101.193.69
dnsmasq[315]: 86115 192.120.33.206/55020 reply stackoverflow.com is 
151.101.65.69
dnsmasq[315]: 86115 192.120.33.206/55020 reply stackoverflow.com is 
151.101.129.69
dnsmasq[315]: 86115 192.120.33.206/55020 reply stackoverflow.com is 
151.101.1.69


dnsmasq[315]: 86116 192.120.33.206/55020 query[A] alive.github.com from 
192.120.33.206
dnsmasq[315]: 86116 192.120.33.206/55020 forwarded alive.github.com to 
77.88.8.8

dnsmasq[315]: 86116 192.120.33.206/55020 reply alive.github.com is 
dnsmasq[315]: 86116 192.120.33.206/55020 reply live.github.com is 
140.82.113.25

Am I right, that in the second column, is just a sequence number?
Then, the first block would be easy to understand and I could use the 
timedifference (the

time, were the loglines arrive in my warapper).
The second block looks like dnsmasq is sending four responses, because of
stackoverflow has four ip-addresses? Or does this mean, the query (of 
this second
block) started at it's first line and was complete(!) at the sixt line 
and the answer to
the client was one response packet? At least, the following "sequence" 
number then

is logically different.
The same pattern then is visible in the third block.
Some comments would help me!
Thanks so far,
Manfred



You seem to have pretty much decoded it.

The second column is a sequence number. It's more useful when dnsmasq is 
busy and more than one query is in progress at the same time, since it 
allows you to work out which answer goes with which query.


The four lines of responses are all in a single packet.

The third column is the address and port number of the client sending 
the request.


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] "no address range available for DHCP request via br0" when using for IPv6 RA

[Simon Kelley]

On 05/04/2023 19:04, Ben Hendin wrote:
Thanks Simon (apologies - my first reply went to your direct email 
instead of back to the list which was not my intent!)


There are dhcp4 ranges defined, but none with ranges for those interface.
For example, the interface which should give out the RAs is br0, and the 
relevant lines are:


ra-param=br0,10,600
enable-ra
quiet-ra
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600

But the device has other interfaces, for example br1 and br2 which have 
the following configuration:


interface=br1
dhcp-range=br1,192.168.101.2,192.168.101.254,255.255.255.0,86400s
dhcp-option=br1,3,192.168.101.1
interface=br2
dhcp-range=br2,192.168.102.2,192.168.102.254,255.255.255.0,86400s
dhcp-option=br2,3,192.168.102.1

My understanding is that the line "interface=X" (e.g. interface=br1) is 
needed to actually enable dnsmasq to listen *at all* on that interface.
Almost. If there are no "interface=X" options at all, then dnsmasq will 
listen on all interfaces.


But the use of br1 on the range/option lines is an arbitrary tag to 
simply associate those two options together.
That usage seems to be common folklore, actually it does nothing in this 
case. dhcp-option=br1,. is the same as dhcp-option=set:br1, for 
long-dead backwards compatibility reasons. So it sets the tag "br1" for 
DHCP transactions which arrive via br1. But a tag with the same name as 
the interface is always automagically set so a "br1" tag exists anyway, 
and the presence of br1 in the dhcp-option has no effect.




IOW, a particular dhcp-range is not associated with an interface using 
any explicit command, rather if a dhcp-range is defined and an interface 
that is defined with "interface=X" is bound to that subnet it will serve 
requests from the defined range?


That's correct.


So I do have dhcp4 ranges defined, and I want those serving out those 
IPs on the interfaces that are on those ranges, but I don't expect any 
DHCPv4 traffic to be answered on br0.


I'm sure I can write iptable rules to block that, but something tells me 
that isn't the elegant way and perhaps there is a dnsmasq configuration 
methodology that I am overlooking???



The whole interface= access control started when dnsmasq only did DNS, 
and when DHCP was added it defaulted to doing both services on the same 
set of interfaces, which is sensible default. To account for 
configurations where DNS would be provided on interfaces where DHCP 
wasn't wanted, the --no-dhcp-interface option was added. (Providing DHCP 
on an interface but not DNS is not supported.)  Logically, now that DHCP 
has bifurcated into DHCPv4 and DHCPv6 it looks like we need 
--no-dhcpv4-interface and --no-dhcpv6-interface. That would certainly 
solve your problem.



Cheers,

Simon.



On Wed, Apr 5, 2023 at 12:33 PM Simon Kelley <mailto:si...@thekelleys.org.uk>> wrote:




On 03/04/2023 16:54, Ben Hendin wrote:
 > I'm running Dnsmasq version 2.85-openssl-5-g989ee98 on an embedded
 > device (Entware installation)
 >
 > I am seeing log entries that state the following when clients
come onto
 > the network to request IP addresses via DHCP:
 >
 > "no address range available for DHCP request via br0"
 >
 > br0 is a bridged interface that includes the LAN and main WiFi of
the
 > embedded device.
 >
 > The issue is that I do not use dnsmasq on this device for DHCP on
this
 > interface.
 > (I do have it configured to deliver dhcp-range information to
some other
 > wireless interfaces.)
 > The main function on this interface is DNS and to deliver RAs for
IPv6.
 >
 > It appears, in order to deliver RAs to my clients the following
lines
 > must be configured:
 >
 > ---
 > interface=br0
 > ra-param=br0,10,600
 > enable-ra
 > dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
 > ---
 >
 > In other words, dhnsmasq must be configured to deliver the
"dhcp-range"
 > option in order to deliver RAs (enable-ra isn't enough)
 > Because of this you can't use the "no-dhcp-interface=br0" option
or else
 > the dhcp-range and therefore the RA will not get delivered to
clients.
 >
 > When a client joins the network, it requests an IPv4 address,
which will
 > not be served by dnsmasq, but by another authoritative server on the
 > network.
 > However, because dnsmasq is configured to provide DHCP services,
yet has
 > no IPv4 range defined it spits out the "no address range available"
 >
 > I have tried changing the "ra-stateless" option to "slaac" or
"ra-only"
 > as the description of 

Re: [Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA

[Simon Kelley]

On 03/04/2023 16:54, Ben Hendin wrote:
I'm running Dnsmasq version 2.85-openssl-5-g989ee98 on an embedded 
device (Entware installation)


I am seeing log entries that state the following when clients come onto 
the network to request IP addresses via DHCP:


"no address range available for DHCP request via br0"

br0 is a bridged interface that includes the LAN and main WiFi of the 
embedded device.


The issue is that I do not use dnsmasq on this device for DHCP on this 
interface.
(I do have it configured to deliver dhcp-range information to some other 
wireless interfaces.)

The main function on this interface is DNS and to deliver RAs for IPv6.

It appears, in order to deliver RAs to my clients the following lines 
must be configured:


---
interface=br0
ra-param=br0,10,600
enable-ra
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
---

In other words, dhnsmasq must be configured to deliver the "dhcp-range" 
option in order to deliver RAs (enable-ra isn't enough)
Because of this you can't use the "no-dhcp-interface=br0" option or else 
the dhcp-range and therefore the RA will not get delivered to clients.


When a client joins the network, it requests an IPv4 address, which will 
not be served by dnsmasq, but by another authoritative server on the 
network.
However, because dnsmasq is configured to provide DHCP services, yet has 
no IPv4 range defined it spits out the "no address range available"


I have tried changing the "ra-stateless" option to "slaac" or "ra-only" 
as the description of "ra-only" seems to indicate that dnsmasq will then 
be made aware it is only to deliver RAs and not DHCP (though perhaps 
this only registers for v6).  I have also tried to use "quiet-dhcp" to 
suppress these unsuccessfully.   Because the message is still logged, it 
would fall under "error or problem" according to "quiet-dhcp" 
specifications.


Is this behavior expected?  If so, is it considered preferable or should 
dnsmasq have some configuration where it should not assume that an IPv4 
range being unconfigured is an issue worth notifying about in scenarios 
like this?




That's not expected behaviour. The log does indeed imply that this is a 
DHCPv4 request (it would say no address range available for DHCPv6) but 
unless there's a valid IPv4 dhcp-range defined dnsmasq should not even 
be listening on the DHCPv4 port. The current code doesn't, and I don't 
remember any fixes to this the 2.85-2.89 timeframe.


What does dnsmasq log when it starts up? The most obvious explantion for 
this is that Entware's startup is defining a DHCPv4 range somewhere in 
the config that gets passed to dnsmasq.



Cheers,

Simon.



thank you

___
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] State of blocking type=65 requests?

[Simon Kelley]

On 05/04/2023 14:32, Ed W wrote:

On 17/03/2023 17:54, Simon Kelley wrote:

On 16/03/2023 16:04, Petr Menšík wrote:



I think it should be fixed on the side of clients instead. If they ask for all 
addresses, just
give them when they do exist. If the network is very expensive (can you be more 
concrete about
type of connection?) then find a way to tell clients what it does provide (and 
what it does not).
It does not provide IPv6? Well, then clients should not ask for it without a 
reason. They also
have to be special on such expensive network, haven't they? I expect they have 
to be tuned
somehow to avoid unnecessary network communication anyway.


Ed can answer this.



I have customers on Iridium satellite links. So basic system is 2.4kbit (300 
bytes/sec) and it costs
around $100/MB

Faster systems are limited by the 22kbit uplink (put a system with something 
from Microsoft near
this link and it can nearly fill the uplink with spammy DNS queries for all the 
junk the MS seem to
be pre-installing on Windows 11...). Data costs on this system are cheaper at 
only $10/MB (so
$10,000/GB, although there are actually discounts on this level of data which 
bring it down a bit)

A further issue with having to bridge typical commercial devices (iphones, 
laptops, etc) is that the
modem link goes down when not in use and takes many seconds to bring it up. 
Annoyingly the modem
hardware caches some of the packets in flight and so you easily get massive 
bandwidth amplification,
eg many clients retry a DNS query every 2 seconds, so if it takes 10 seconds to 
bring up the link
you have 5x as much traffic queued on the outbound, then you get 5x replies, 
then if you aren't
careful you get 4x ICMP replies about the port being closed. At $10/MB this is 
costly very quickly

We add value by using all kinds of tricks to filter the traffic to the very 
minimum needed. However,
this game requires compressing data carefully, counting bytes and packets and 
often peering inside
packets to decide what can get chopped and what can live.

Note I'm not looking for suggestions on alternatives or tips here. Just thought 
you might be
interested that these worlds still exist...



Faking empty responses is poor man's choice just to dodge assumptions on 
multiple sides. But if
it does not want to forward something , I think REFUSED would be correct 
response. It would also
solve problem to decide whether to send NOERROR or NXDOMAIN. And would cause no 
forwarded queries
of unwanted types.



The problem with REFUSED is that the behaviour of resolvers to a REFUSED answer 
is not well
defined. I bet lots of them will just retry, especially when they only have one 
recursive server
configured. That's not very useful.



My opening position on filtering  requests is to "REFUSED" them. However, 
it seems like musl
resolver handles this as a fail for everything, including the A record. Now I'm 
digging through the
code and pretty sure I can fix my own resolver, but we are looking to offer a 
docker solution for
the customers, plus we assume we will have various IOT devices on the LAN side 
using us as well, so
I can't necessarily have them all apply patches to their distros...

So I'm on the fence here over pragmatism and needing to get a solution that 
works for everyone.

Broadly we have 2 modes, either we have cellular connectivity and we want to 
let people do as they
wish, or we are in satellite mode and heavily filtering apps and traffic to the 
minimum. Ideally I
want to use external firewall rules to decide the fate, but this looks 
difficult. Also I want to
support wireguard and the like, so we will likely need  in some limited 
capacity...

I will likely end up butchering dnsmasq to get something reasonable for this 
use case I think.
Ideally I would want  for specific domains to complete and everything else 
to magically give the
correct response without an upstream check. Simon's suggestion of being able to 
search the cache for
the A and guess an answer would get me closer some of  the time. I think for 
the rest the best I can
do is blindly convert "REFUSED" into "NODATA" and accept this will break some 
small proportion of
things, but it's the best I can do within these constraints?




If it would work the same way as faking empty responses, I would vote for 
--reject-rrset=https
instead of --filter-rrset=https.  would be probably more difficult, because
getaddrinfo(AF_UNSPEC) implementations may not handle REFUSED just one one of 
two queries well.
But if browsers doing HTTPS would handle it better, please try that first. I 
admit I haven't
tried. But HTTPS should not have similar legacy problems, it may work better.



I think we have consensus that that filter-a and filter- should be 
generalised to filer=rrset.

I'd also like to generalise the cache to allow something like cache-rrtype=SRV 
or cache-rrtype=https.



Yes, I think this should be low priority because

Re: [Dnsmasq-discuss] [PATCH] Report filtered A or AAAA records via EDE code

[Simon Kelley]

On 31/03/2023 14:28, Petr Menšík wrote:

I agree with Dominik.

--cache-rr=!TXT,!DNSKEY,!DS or maybe just --no-cache-rr=TXT,DNSKEY,DS

would be more useful.

For my own preference it would be more useful to cache ANY record by 
default, maybe with exceptions of explicitly listed records. I think it 
would be nice to specify maximal record set size instead. On memory 
constrained devices it might choose to not cache rrset records longer 
than 32B for example. Addresses might have exception for that. I think 
usually it does not matter if that is OPENPGPKEY or TXT. I think only 
what matters is how long the record is and how often it is queried. 
--no-cache-rrset-over=120 might be an example.


Larger records should have slightly higher chance to be pushed out from 
the cache. I think that were not changed yet. Does existing code prefer 
to release bigger chunks from the cache?


That all sounds really complicated. I wonder if anyone would actually 
use it or find it useful?


I think also a cache summary should be requestable via dbus or signal. 
Something like X A records, 256B, Y  records, 600B, Z TXT records, 
1400B. Ideally also cache hits number or ratio for those types. 
Something which could briefly describe what current cache is holding. Do 
we have something like that already?


sending SIGUSR1 dumps all the records in the cache, but none of the 
stats are kept per-RR type.


If we want to refuse caching of some records, we should have a better 
evidence whose tend to occupy memory without being much useful. I think 
we are making just educated guesses. On some networks it might be 
significantly different. Gathering a good default needs some evidence, 
which I think we are missing now. Bare total cache misses and hits are 
not enough IMO.



To the original issue with EDE code, thanks for that. The answer from 
IETF dnsop were indeed filtered might be not a correct one. Code 21 no 
supported were suggested, unless we define a better one. There is a new 
type defined Synthetized, but that has also somehow different usage. I 
have created feature request on bind [1], they have very similar 
functionality to filter out address records. Do not indicate modified 
answers with any code at the moment.




Thanks for chasing this. I'll leave the behaviour as-is for now, and aim 
to change things when the standards people come to a conclusion.



Cheers,

Simon.


[1] https://gitlab.isc.org/isc-projects/bind9/-/issues/3979

On 3/31/23 09:25, Dominik Derigs via Dnsmasq-discuss wrote:

Hey Simon,

On Thu, 2023-03-30 at 18:28 +0100, Simon Kelley wrote:

I just merged the branch I've been working on for the last week which
includes this patch, but much modified because the surrounding code has
changed. The function is unaltered.

The other changes are adding the ability to cache any RR-type, and the
ability to filter any RR-type. There's quite a bit of code cleanup in
the affected code paths too.

The new man page says:

By default, dnsmasq caches A, , CNAME and SRV DNS

record types. This option adds other record types to the
cache. [...]

I wonder how useful this really is. Won't it cause config
files to explode with lines like (possibly line-per-line):
--cache-
rr=NS,MD,MF,SOA,MB,MG,MR,NULL,WKS,PTR,HINFO,MINFO,MX,TXT,RP,
AFSDB,X25,ISDN,RT,NSAP,NSAP_PTR,SIG,KEY,PX,GPOS,LOC,NXT,EID,
NIMLOC,ATMA,NAPTR,KX,CERT,A6,DNAME,SINK,OPT,APL,DS,SSHFP,IPS
ECKEY,RRSIG,NSEC,DNSKEY,DHCID,NSEC3,NSEC3PARAM,TLSA,SMIMEA,H
IP,NINFO,RKEY,TALINK,CDS,CDNSKEY,OPENPGPKEY,CSYNC,ZONEMD,SVC
B,HTTPS,SPF,UINFO,UID,GID,UNSPEC,NID,L32,L64,LP,EUI48,EUI64,
TKEY,TSIG,IXFR,AXFR,MAILB,MAILA,ANY,URI,CAA,AVC,DOA,AMTRELAY
,TA,DLV

if I want to cache all types known to dnsmasq by name (yes,
this does not include proprietary extensions by numbers). It
also seems inefficient to always loop over these 86 RR types
when we check if this RR is to be cached.


Since we have just binary indication for numberic type, I think we need 
just:


- default value
- array of uint8_t for bit indication for each specified type.
- array size would be max specified type / 8+1.
- over max value the default value would apply, no need to have full 
size bitmap.


This would be able to query type cacheability in linear way. No loops 
per each query should be necessary, should be quite fast. I think 
NSEC(3) uses similar kind of bit magic. Not sure that is decoded by 
dnsmasq anywhere in the code.


Unless we need dbus API to change cached types runtime, those would be 
initialized just once. Makes sense to spend time once during init and 
save it per-query.




Looking at this new option, it seems really counter-
intuitive to specify "I want to cache ANY but not TXT". Is
there a real-world scenario where someone would not like to
cache a specific type? I suppose these queries should
arguably have a TTL of 0 from upstream to prevent caching.

My feeling is that we should really have at least a shortcut
to specify "cache everything you can". 

Re: [Dnsmasq-discuss] [PATCH] Report filtered A or AAAA records via EDE code

[Simon Kelley]

On 31/03/2023 08:25, Dominik Derigs wrote:

Hey Simon,

On Thu, 2023-03-30 at 18:28 +0100, Simon Kelley wrote:

I just merged the branch I've been working on for the last week which
includes this patch, but much modified because the surrounding code has
changed. The function is unaltered.

The other changes are adding the ability to cache any RR-type, and the
ability to filter any RR-type. There's quite a bit of code cleanup in
the affected code paths too.


The new man page says:

By default, dnsmasq caches A, , CNAME and SRV DNS

record types. This option adds other record types to the
cache. [...]

I wonder how useful this really is. Won't it cause config
files to explode with lines like (possibly line-per-line):
--cache-
rr=NS,MD,MF,SOA,MB,MG,MR,NULL,WKS,PTR,HINFO,MINFO,MX,TXT,RP,
AFSDB,X25,ISDN,RT,NSAP,NSAP_PTR,SIG,KEY,PX,GPOS,LOC,NXT,EID,
NIMLOC,ATMA,NAPTR,KX,CERT,A6,DNAME,SINK,OPT,APL,DS,SSHFP,IPS
ECKEY,RRSIG,NSEC,DNSKEY,DHCID,NSEC3,NSEC3PARAM,TLSA,SMIMEA,H
IP,NINFO,RKEY,TALINK,CDS,CDNSKEY,OPENPGPKEY,CSYNC,ZONEMD,SVC
B,HTTPS,SPF,UINFO,UID,GID,UNSPEC,NID,L32,L64,LP,EUI48,EUI64,
TKEY,TSIG,IXFR,AXFR,MAILB,MAILA,ANY,URI,CAA,AVC,DOA,AMTRELAY
,TA,DLV

if I want to cache all types known to dnsmasq by name (yes,
this does not include proprietary extensions by numbers). It
also seems inefficient to always loop over these 86 RR types
when we check if this RR is to be cached.

Looking at this new option, it seems really counter-
intuitive to specify "I want to cache ANY but not TXT". Is
there a real-world scenario where someone would not like to
cache a specific type? I suppose these queries should
arguably have a TTL of 0 from upstream to prevent caching.

My feeling is that we should really have at least a shortcut
to specify "cache everything you can". May this be "--cache-
rr" without options, some special "--cache-rr=all" or maybe
a dedicated option like "--cache-all".



Good question. The motive for making caching opt-in rather than opt-out 
is only that just silently starting to cache everything has the 
potential to have a big enough affect on the memory footprint of dnsmasq 
to be noticeable on small routers.


I've made --cache-rr=ANY do the obvious thing.



Others than that - thanks for working on this! I already
started testing (using the long command above) and will
report any oddities I come across.



Thanks. Please pick up the latest code, which is more efficient at 
storing small RRs.



Cheers,

Simon.


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] dhcp-fqdn bug

[Simon Kelley]

On 30/03/2023 22:00, 0zl wrote:

Greetings,

I believe this might be a bug in dnsmasq. When using the shorthand 
`domain=mydomain.com,local` and `dhcp-fqdn`, dnsmasq fails with:


`there must be a default domain when --dhcp-fqdn is set`

I'm not sure if this is intended behavior or not, but from what I could 
gather this shouldn't happen.




You're possibly a victim of dnsmasq's over-complex configuration syntax.

The error is `there must be a default domain when --dhcp-fqdn is set` 
which is true. By default domain it means a domain which doesn't apply 
only to hosts with an address in a particular address range.


The problem is that -domain=mydomain.com,local is being parsed by the 
dnsmasq code as being a domain which only applies to hosts which have an 
address in the same range as a network interface called "local". That's 
not a default domain, hence the problem.


I doubt that's what you intended your domain option to mean, but it's 
not clear what you are trying to do here: the "local" keyword only makes 
sense in a domain declaration which includes an address range.


If you let us know what you are behaviour you want, we can tell you how 
to configure dnsmasq to get it.



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] Report filtered A or AAAA records via EDE code

[Simon Kelley]

I just merged the branch I've been working on for the last week which 
includes this patch, but much modified because the surrounding code has 
changed. The function is unaltered.


The other changes are adding the ability to cache any RR-type, and the 
ability to filter any RR-type. There's quite a bit of code cleanup in 
the affected code paths too.


Simon.


On 21/03/2023 12:05, Petr Menšík wrote:

On 3/17/23 19:08, Simon Kelley wrote:
I think that looks like a sensible change. I'm slightly worried about 
the definition of EDE_FILTERED


4.18. Extended DNS Error Code 17 - Filtered
    The server is unable to respond to the request because the domain is
    on a blocklist as requested by the client. Functionally, this
    amounts to "you requested that we filter domains like this one."

Which talks about domains and not RRtypes. You can imagine a client 
noting that a domain is filtered and not sending other queries for the 
domain, when in this case they are fine, it's the RRtype which is 
being filtered.



Simon.

Yes, I have noticed that too. But there does not seem to be any code 
better suited for filtered RRtypes. Do you know any software doing such 
decisions based on just EDE code? It would make sense to do so based on 
NXDOMAIN response, marked also with Filtered code. But by NOERROR 
response code we clearly indicate such domain is there and may return 
something for different types. I think response code has stronger 
authority than EDE code.


Alternatively we would have to request another code registered for 
filtered types only. I think asking on dnsop for opinions would not hurt.


Cheers,
Petr



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] log-queries and NXDOMAINS

[Simon Kelley]

On 26/03/2023 14:34, Ercolino de Spiacico wrote:
In the context of adblock/domain-filtering I was trying to find a way to 
log all the blocked queries only. We currently use a custom config 
formatted like:


local=baddomain.com/

which returns NXDOMAIN. The issue is that if we enable "log-queries" 
this is literally flooding the syslog. Beside this the messages appears 
to be logged as info.



I'm aware that we can redirect the dnsmasq logs to a different file but 
for the embedded devices we're discussing here (FreshTomato) you do want 
the main dnsmasq to hit the default syslog facility. Also performing a 
grep-in for NXDOMAIN onto a new file is surely a possibility but rather 
intensive for this type of devices, especially if this needs to be 
performed periodically.



So in a nutshell, would it be possible to:

A- use 'debug' (or allow custom level number) for the logs generated by 
log-queries


That would be simple. Something like

--log-queries=

would work. All the query logging goes through three calls to syslog.


B- allow to limit log-queries to certain results only e.g. log only if 
the result is: NXDOMAIN/0.0.0.0/else-the-user-might-want


Sound like a can of worms. Which ones, exactly? What happens when 
someone else wants a different subset to solve their logging problem?


C - Allow the --log-facility to be split by loglevel or message type e.g.:
  [0-6] > /var/log/messages
  7 > /var/log/dnssmasq.debug


That sounds like a job for rsyslogd.


Simon.





Thanks.

___
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] "reply query is duplicate" failure

[Simon Kelley]

On 22/03/2023 21:18, Manish Shakya wrote:

Hi there,

I am using v2.89 dnsmasq with openwrt. Evenever dnsmasq shows the 
following logs, the getaddrinfo() function fails and has to be retried.

   ^^

Missed this in my first answer. The log shows queries for the same 
domain A and  records coming from 127.0.0.1 and ::1 (the IPv6 
localhost address), so a total of four queries. All four queries get 
answered  with the apparently correct answers. If getaddrinfo() fails 
but only in the circumstance that you see the "duplicate" message then 
I'd like to see packet captures just to ensure that there's no dnsmasq 
problem.


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] "reply query is duplicate" failure

[Simon Kelley]

On 22/03/2023 21:18, Manish Shakya wrote:

Hi there,

I am using v2.89 dnsmasq with openwrt. Evenever dnsmasq shows the 
following logs, the getaddrinfo() function fails and has to be retried.


Wed Mar 22 20:54:41 2023 daemon.info  dnsmasq[1]: 45 
127.0.0.1/46942  query[A] 
alpha.wirelessneovi.com  from 127.0.0.1
Wed Mar 22 20:54:41 2023 daemon.info  dnsmasq[1]: 45 
127.0.0.1/46942  forwarded 
alpha.wirelessneovi.com  to 10.14.159.231
Wed Mar 22 20:54:41 2023 daemon.info  dnsmasq[1]: 46 
::1/46942 query[A] alpha.wirelessneovi.com 
 from ::1
Wed Mar 22 20:54:41 2023 daemon.info  dnsmasq[1]: 47 
127.0.0.1/46942  query[] 
alpha.wirelessneovi.com  from 127.0.0.1
Wed Mar 22 20:54:41 2023 daemon.info  dnsmasq[1]: 47 
127.0.0.1/46942  forwarded 
alpha.wirelessneovi.com  to 10.14.159.231
Wed Mar 22 20:54:41 2023 daemon.info  dnsmasq[1]: 47 
127.0.0.1/46942  reply alpha.wirelessneovi.com 
 is NODATA-IPv6
Wed Mar 22 20:54:41 2023 daemon.info  dnsmasq[1]: 48 
::1/46942 query[] alpha.wirelessneovi.com 
 from ::1
Wed Mar 22 20:54:41 2023 daemon.info  dnsmasq[1]: 48 
::1/46942 forwarded alpha.wirelessneovi.com 
 to 10.14.159.231
Wed Mar 22 20:54:41 2023 daemon.info  dnsmasq[1]: 48 
::1/46942 reply alpha.wirelessneovi.com  
is NODATA-IPv6
Wed Mar 22 20:54:41 2023 daemon.info  dnsmasq[1]: 45 
127.0.0.1/46942  reply alpha.wirelessneovi.com 
 is 45.27.190.129
Wed Mar 22 20:54:41 2023 daemon.info  dnsmasq[1]: 46 
::1/46942 reply query is duplicate


What am I doing wrong here? Am I missing any parameters? Any help is 
appreciated.




You're not doing anything wrong and the message doesn't indicate an error.

Reformatting the logs to avoid line wrap and remove non-interesting 
stuff we have.


45 127.0.0.1/46942  query[A]
45 127.0.0.1/46942 forwarded alpha.wirelessneovi.com to 10.14.159.231
46 ::1/46942 query[A] alpha.wirelessneovi.com from ::1
.
.
45 127.0.0.1/46942 reply alpha.wirelessneovi.com is 45.27.190.129
46 ::1/46942 reply query is duplicate

There are two transactions, here 45 and 46 which are both queries for 
the same domain alpha.wirelessneovi.com.


45 arrives first and gets sent to the upstream server.
46 then arrives and is not sent upstream because the same query is 
already in progress as 45.


Then the reply for 45 comes back and is returned to the original client 
at 127.0.0.1/46942
The same reply is then used to answer 46 and is sent to ::1/46942  as 
the original client.


The "duplicate" line just tells you that the query was recognized as a 
duplicate and it's now being answered with data from another, identical, 
query.


TL;DR your client is sending the same query over IPv4 and IPv6 and 
dnsmasq is combining both of those queries into one to send uptream and 
then answering them both from one upstream answer.


This behaviour is a small performance benefit, but it's mainly there for 
security reasons. It stops a malicious client from being able  to force 
dnsmasq to make many queries upstream for the same domain, which is part 
of a cache-poisoning attack.



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] State of blocking type=65 requests?

[Simon Kelley]

On 16/03/2023 16:04, Petr Menšík wrote:
I do not like attempts to filter out valid queries from clients on the 
side of dns cache. It should cache the HTTPS type, which it currently 
does not. That makes those kind of queries much more expensive.


Agree about HTTPS caching.


I think it should be fixed on the side of clients instead. If they ask 
for all addresses, just give them when they do exist. If the network is 
very expensive (can you be more concrete about type of connection?) then 
find a way to tell clients what it does provide (and what it does not). 
It does not provide IPv6? Well, then clients should not ask for it 
without a reason. They also have to be special on such expensive 
network, haven't they? I expect they have to be tuned somehow to avoid 
unnecessary network communication anyway.


Ed can answer this.


What is a good response for  record, which may exist, but we pretend 
it does not? NODATA or REFUSED? 


NODATA or NXDOMAIN are the only good answers. You can answer NXDOMAIN if 
a query for another RRtype for the same domain returned NXDOMAIN. You 
can also answer NODATA if that query returned an answer or NODATA. If 
you don't have the answer to another query, then you have to send it 
upstream. The current dnsmasq code handles cached NXDOMAIN. This is 
valid, not just if you're filtering the requested rrtype.  I'm tempted 
to add the NODATA check, that's only useful with filtering.


All similar quirks break DNSSEC 
deployment. 


Having DNS clients of dnsmasq which do DNSSEC validation is pretty 
hopeless anyway. It will work only if you don't use any the facilities 
in dnsmasq to alter the client's view of the DNS.  No overriding A/ 
records in /etc/hosts or --address. No generating A,  or other 
record types in dnsmasq. The only way it works is just using dnsmasq as 
a pure caching forwarder. That's a valid use case, but lots of people 
use dnsmasq to alter the client's view of the DNS and that's a valid use 
case too and there's no reason to avoid additional features that do it.


Would you want also EDNS0 extension stripped from forwarded 
queries? Or at least reset DO bit to 0 always? I would prefer if it 
could return REFUSED to queries it does not want to forward. Faking 
empty responses is poor man's choice just to dodge assumptions on 
multiple sides. But if it does not want to forward something , I think 
REFUSED would be correct response. It would also solve problem to decide 
whether to send NOERROR or NXDOMAIN. And would cause no forwarded 
queries of unwanted types.




The problem with REFUSED is that the behaviour of resolvers to a REFUSED 
answer is not well defined. I bet lots of them will just retry, 
especially when they only have one recursive server configured. That's 
not very useful.



If it would work the same way as faking empty responses, I would vote 
for --reject-rrset=https instead of --filter-rrset=https.  would be 
probably more difficult, because getaddrinfo(AF_UNSPEC) implementations 
may not handle REFUSED just one one of two queries well. But if browsers 
doing HTTPS would handle it better, please try that first. I admit I 
haven't tried. But HTTPS should not have similar legacy problems, it may 
work better.



I think we have consensus that that filter-a and filter- should be 
generalised to filer=rrset.


I'd also like to generalise the cache to allow something like 
cache-rrtype=SRV or cache-rrtype=https.




Simon.




Regards,
Petr

On 06. 03. 23 23:36, Ed W wrote:
Hi, can I get a leg up in understanding the options for blocking dns 
queries for a specific resource

type, specifically type 65 queries

I see there was a patch to implement a "filter-http" option here:

 https://github.com/rozahp/dnsmasq

It possibly seems like there is a filter- implemented in dnsmasq 
already, so I wonder if there

is appetite for the filter-http to also be accepted?


My motivation for needing this is that we operate a firewalling system 
for a very bandwidth
constrained system (even DNS is extremely expensive) and we operate a 
'blocked unless whitelisted'
firewalling system. The type 65 queries are currently inhibiting some 
of the whitelisting
capability. Whilst we can potentially improve things, the short term 
solution would be to block type 65


I see that there is an option in pi-hole, but I'm looking for an 
option within dnsmasq, ideally

without maintaining my own out of tree patch


Have I missed a solution that is possible within vanilla dnsmasq?

Has the idea to implement a filter-http option been rejected already? 
(I'm happy to send a patch if

not?)


Thanks

Ed W


___
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

Re: [Dnsmasq-discuss] Method to get Dnsmasq serve address of a host from interface address

[Simon Kelley]

This is really the function of the dnsmasq.conf.example file that's 
ditsributed with the source code for dnsmasq. Unfortunately that has 
become rather out-of-date. It could do with a major overhaul.



Simon.


On 14/03/2023 07:55, Olivier wrote:

Hello,

Could it be possible to add an  example in interface-name section of
dnsmasq.conf man page as
IMHO, current content is not very easy to understand.

Best regards

___
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] State of blocking type=65 requests?

[Simon Kelley]

On 11/03/2023 17:34, Ed W wrote:

On 07/03/2023 21:50, Simon Kelley wrote:


On 06/03/2023 22:36, Ed W wrote:

Hi, can I get a leg up in understanding the options for blocking dns queries 
for a specific resource
type, specifically type 65 queries



My motivation for needing this is that we operate a firewalling system for a 
very bandwidth
constrained system (even DNS is extremely expensive) and we operate a 'blocked 
unless whitelisted'
firewalling system. The type 65 queries are currently inhibiting some of the 
whitelisting
capability. Whilst we can potentially improve things, the short term solution 
would be to block
type 65

I see that there is an option in pi-hole, but I'm looking for an option within 
dnsmasq, ideally
without maintaining my own out of tree patch




Just to make clear, as I know you count every every byte of traffic, these 
filters are on
_answers_ not on queries. The query for A or  (or in future an arbitrary 
type) still gets sent
upstream and when the answer comes back, the RRs are stripped out of the 
answer. It has to be that
way because the upstream there may not be an positive answer from upstream, and 
in that case we
need to know is it's a NODATA answer (The RRtype we queried doesn't exist) or 
an NXDOMAIN answer
(the domain we queried doesn't exist.)



So I've kind of realised that it might be difficult to implement my preferred 
option to kill the
upstream query (and save the bytes).

I created a very simple iptables rule that (probably) blocks  queries by 
just matching on the
query type in the packet (motivation is that then I can block only on expensive 
connections and
leave cheap connections untouched)

However, I then hit an issue with the musl resolver. It seems that this got 
changed last year to
return both A and  results OR error. So if the  query fails, then it 
retries a few times and
then returns an error (rather than partial result with just the A). There is 
some reference in the
commit to this being "correct"?

I'm not sure I know which RFC might dictate this? I'm tempted to patch this to 
do what I want it to
do, but first any observations on why this might be a bad idea in the real 
world (to be clear,
change of behaviour that failed  request will be ignored and remaining A 
response will be
returned on it's own)? My proposal would be to match the A response, so if 
NX-Fail on A, then that's
what you get, but otherwise "NO-DATA" for the . What am I missing?



The problem with doing this in dnsmasq or with iptables is that the A 
and  queries are separate.



If you want to suppress the  query (rather than the answer) you need 
to know is the answer should be NODATA or NXDOMAIN.


If the A query happens first then A query happens first then you have 
that information: an NXDOMAIN answer means the  query can be 
NXDOMAIN too. A NODATA or actual data means that the answer to the  
query can be NODATA without every sending it upstream.



Of course there's the possibility that nothing is cached for the domain, 
in which case you have to send the query upstream.



The resolver is somewhat different: it just returns IPv4 and IPv6 
answers, if you could hack it to always return an empty set of IPv6 
addresses and never make  DNS queries, you're fixed, as long as 
everything uses the resolver library calls to do DNS. As long.



For dnsmasq, an  query will get an immediate NXDOMAIN if the A query 
already happened and cached the NXDOMAIN response. Otherwise the  
query gets sent upstream and if any RR are returned, that answer gets 
turned into a NODATA answer by filter-.


What doesn'y happen, but could, is a search of the cache for A or other 
records. If they exist, an  query with filter- could get turned 
into a NODATA answer without being sent upstream.


Simon.




Thanks

Ed W



___
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] [PATCH] Value stored to 'outmsgtype' is never read

[Simon Kelley]

Yes, that's a bug.

I prefer to goto theend of the function rather than duplicate the scary 
code that sets the message type. By reordering some code there, the 
logging works better too.


https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=00be8b39e240934e404533deda08cbae2aae25a8


Cheers,

Simon.

On 14/03/2023 11:51, Petr Menšík wrote:

Hi!

Our coverity scan detected new CLANG warning after I have cherry-picked 
commit 03345ecefeb0d82e3c3a4c28f27c3554f0611b39 [1] into our rhel8 
release. It reported it for 2.79 version, but even the last commit in 
master branch still has the same issue present. In attached patch I have 
suggested fix.


I am not sure how to trigger this code from the client, so this is not 
tested with real dhcp client. I track it under Fedora bug [2]. Coverity 
reported it as:


1. Defect type: CLANG_WARNING
1. dnsmasq-2.79/src/rfc3315.c:344:7: warning[deadcode.DeadStores]: Value stored 
to 'outmsgtype' is never read
#   342|
#   343|   {
#   344|->   outmsgtype = DHCP6REPLY;
#   345| o1 = new_opt6(OPTION6_STATUS_CODE);
#   346| put_opt6_short(DHCP6USEMULTI);

1. 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=03345ecefeb0d82e3c3a4c28f27c3554f0611b39

2. https://bugzilla.redhat.com/show_bug.cgi?id=2178069

--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.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


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Method to get Dnsmasq serve address of a host from interface address

[Simon Kelley]

On 13/03/2023 17:01, Simon Kelley wrote:

Thanks for the bug report, it's definitely not noise.

The history of line 363 is interesting.

When the dynamic-host option was added, it looked like

if (netmask.s_addr == 0x)


and stayed like that until October 2022 when it got changed to the 
current version


if (netmask.s_addr == 0x)

That's what was released as part of 2.88

So that explains why it used to work for you, and no longer does in 2.88 
and 2.89. If your PPoe interface had netmask 255.255.0.0 then it would 
not have worked previously, but would work now.


The change was prompted by this email to the list.

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q4/016607.html

and the explanation that it looks like the intention was to skip 
interfaces with /32 prefixes looks pretty sensible, so the patch went in 
without too much thought.


My dilemma is that I can't see the reason to do that and I have no 
recollection of why I might done it in early 2021 when dynamic-host was 
first implemented. Someone should invent a way to core-dump human brain 
state to git for future reference.


The best I can come up with is that what you are trying to do is not 
what I expected dynamic-host to be used for. I expected it to be used to 
name hosts on an internal network whose prefix was supplied by the ISP, 
typically in IPv6-land with prefix delegation. So the host is not the 
one running dnsmasq but another host connected to the same network as 
the interface but with a suffix. Clearly that can only exist when the 
prefix length is smaller than 32(IPv4) or 128(IPv6).


Actually, it's reasonable not to have considered your "weird hack", 
because dnsmasq has had an explicit mechanism to do what you want for a 
long time, interface-name. You could just use.


interface-name=myip.my.local.domain,dsl-provider

So.

There's an easier way to do what you want to do.
Your "weird hack" used to work because the code that was supposed to 
stop it used to be buggy and didn't.

The bug got fixed in 2.88 and now does stop your weird hack.
There's a very limited need for the once-buggy, now fixed code and I 
can't really remember what it was for.


Going forward we have three options for line 363

1) revert the October 2022 change. That would be stupid.
2) leave as is and educate people to use interface-name for this and not 
hack dynamic-host
3) remove it so that people skimming the man page who find dynamic-host 
before they find interface-name and rediscover your "weird hack" are not 
bewildered. This would also avoid people who found and used the "weird 
hack" in pre-2.88 releases from suffering a regression when they upgrade.



For that last reason alone, I propose option 3.


Comments?



Cheers,

Simon.




Replying to myself, there's further evidence of the intention behind 
line 363 in the analogous code for IPv6, around line 401.


/* No sense in doing /128. */
if (prefixlen == 128)
  continue;

If 363 goes, 401 should go too.

Simon.




On 13/03/2023 00:31, 0zl wrote:
Well, it seems like dnsmasq just ignores addresses with /32s. I see in 
src/network.c for some reason if an interface has 255.255.255.255 it 
just skips it (line 363)?


This might possibly the cause for the issue, I'm not sure if this is 
intentional or some sort of bug.


Thanks again and sorry for the noise!


On 3/13/23 02:08, 0zl wrote:

Hi everyone,

Previously on Debian Stable, I was using dynamic-host as a weird hack 
to get Dnsmasq to serve my PPPOE interface's IP address however this 
no longer seems to work with the Dnsmasq supplied in Debian Testing.


It was OK to just specify 0.0.0.0 as my ISP would allocate for me a 
/32 and so this thankfully matched my interface address and worked 
properly.


Now that this no longer works on 2.89, are there any alternatives I 
could use?


(What no longer works is 
`dynamic-host=myip.my.local.domain,0.0.0.0,dsl-provider` and Dnsmasq 
fails with `warning: no addresses found for interface dsl-provider`)


TIA





___
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] Method to get Dnsmasq serve address of a host from interface address

[Simon Kelley]

Thanks for the bug report, it's definitely not noise.

The history of line 363 is interesting.

When the dynamic-host option was added, it looked like

if (netmask.s_addr == 0x)


and stayed like that until October 2022 when it got changed to the 
current version


if (netmask.s_addr == 0x)

That's what was released as part of 2.88

So that explains why it used to work for you, and no longer does in 2.88 
and 2.89. If your PPoe interface had netmask 255.255.0.0 then it would 
not have worked previously, but would work now.


The change was prompted by this email to the list.

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q4/016607.html

and the explanation that it looks like the intention was to skip 
interfaces with /32 prefixes looks pretty sensible, so the patch went in 
without too much thought.


My dilemma is that I can't see the reason to do that and I have no 
recollection of why I might done it in early 2021 when dynamic-host was 
first implemented. Someone should invent a way to core-dump human brain 
state to git for future reference.


The best I can come up with is that what you are trying to do is not 
what I expected dynamic-host to be used for. I expected it to be used to 
name hosts on an internal network whose prefix was supplied by the ISP, 
typically in IPv6-land with prefix delegation. So the host is not the 
one running dnsmasq but another host connected to the same network as 
the interface but with a suffix. Clearly that can only exist when the 
prefix length is smaller than 32(IPv4) or 128(IPv6).


Actually, it's reasonable not to have considered your "weird hack", 
because dnsmasq has had an explicit mechanism to do what you want for a 
long time, interface-name. You could just use.


interface-name=myip.my.local.domain,dsl-provider

So.

There's an easier way to do what you want to do.
Your "weird hack" used to work because the code that was supposed to 
stop it used to be buggy and didn't.

The bug got fixed in 2.88 and now does stop your weird hack.
There's a very limited need for the once-buggy, now fixed code and I 
can't really remember what it was for.


Going forward we have three options for line 363

1) revert the October 2022 change. That would be stupid.
2) leave as is and educate people to use interface-name for this and not 
hack dynamic-host
3) remove it so that people skimming the man page who find dynamic-host 
before they find interface-name and rediscover your "weird hack" are not 
bewildered. This would also avoid people who found and used the "weird 
hack" in pre-2.88 releases from suffering a regression when they upgrade.



For that last reason alone, I propose option 3.


Comments?



Cheers,

Simon.

On 13/03/2023 00:31, 0zl wrote:
Well, it seems like dnsmasq just ignores addresses with /32s. I see in 
src/network.c for some reason if an interface has 255.255.255.255 it 
just skips it (line 363)?


This might possibly the cause for the issue, I'm not sure if this is 
intentional or some sort of bug.


Thanks again and sorry for the noise!


On 3/13/23 02:08, 0zl wrote:

Hi everyone,

Previously on Debian Stable, I was using dynamic-host as a weird hack 
to get Dnsmasq to serve my PPPOE interface's IP address however this 
no longer seems to work with the Dnsmasq supplied in Debian Testing.


It was OK to just specify 0.0.0.0 as my ISP would allocate for me a 
/32 and so this thankfully matched my interface address and worked 
properly.


Now that this no longer works on 2.89, are there any alternatives I 
could use?


(What no longer works is 
`dynamic-host=myip.my.local.domain,0.0.0.0,dsl-provider` and Dnsmasq 
fails with `warning: no addresses found for interface dsl-provider`)


TIA





___
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] [PATCH v2] dbus: allow setting filter-A and filter-AAAA options

[Simon Kelley]

Apologies for ignoring you. Patch looks fine. Applied to git repo.

Cheers,

Simon.


On 07/03/2023 23:20, Clayton Craft wrote:

On Thu, 23 Feb 2023 21:40:10 -0800 Clayton Craft  wrote:

On Fri, 10 Feb 2023 13:53:05 -0800 Clayton Craft  wrote:

Any chance this could get merged? Being able to set filters at runtime is very
useful for multi-homed phones and other devices in cases where we need to
restrict DNS response answers based on IP protocol.

Please let me know if I need to make changes so that it is acceptable.


Is this patch something that could be accepted?

-Clayton


___
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] State of blocking type=65 requests?

[Simon Kelley]

On 06/03/2023 22:36, Ed W wrote:

Hi, can I get a leg up in understanding the options for blocking dns queries 
for a specific resource
type, specifically type 65 queries

I see there was a patch to implement a "filter-http" option here:

     https://github.com/rozahp/dnsmasq

It possibly seems like there is a filter- implemented in dnsmasq already, 
so I wonder if there
is appetite for the filter-http to also be accepted?


It's well known that the only sensible numbers of entities in computer 
software are zero, one and many.


We've already got filter-a and filter- so that rule is broken, but I 
don't feel like breaking it further. At this point we should just go to 
filter-rrtype=, in your case filter-rrtype=65.





My motivation for needing this is that we operate a firewalling system for a 
very bandwidth
constrained system (even DNS is extremely expensive) and we operate a 'blocked 
unless whitelisted'
firewalling system. The type 65 queries are currently inhibiting some of the 
whitelisting
capability. Whilst we can potentially improve things, the short term solution 
would be to block type 65

I see that there is an option in pi-hole, but I'm looking for an option within 
dnsmasq, ideally
without maintaining my own out of tree patch




Just to make clear, as I know you count every every byte of traffic, 
these filters are on _answers_ not on queries. The query for A or  
(or in future an arbitrary type) still gets sent upstream and when the 
answer comes back, the RRs are stripped out of the answer. It has to be 
that way because the upstream there may not be an positive answer from 
upstream, and in that case we need to know is it's a NODATA answer (The 
RRtype we queried doesn't exist) or an NXDOMAIN answer (the domain we 
queried doesn't exist.)





Have I missed a solution that is possible within vanilla dnsmasq?



No possible, unless I've missed something.


Has the idea to implement a filter-http option been rejected already? (I'm 
happy to send a patch if
not?)



Send away for an implementation of filter-rrtype.



Cheers,

Simon.



Thanks

Ed W


___
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] Segfault when no uplink dns server is available

[Simon Kelley]

Right, that's a different bug then.

Fix here.

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=f5ef0f064c3f06b250a9eeda36dc239227658b00


Cheers,

Simon.



On 06/03/2023 16:58, Daniel Danzberger wrote:

It's from the current master branch:
commit 5dc14b6e05f39a5ab0dc02e376b1d7da2fda5bc1 (HEAD -> master, tag: v2.89)

On Mon, 2023-03-06 at 16:11 +0000, Simon Kelley wrote:


Thanks for the comprehensive analysis.

You don't mention what version of dnsmasq you were testing.


I think that this was fixed in release 2.88, the commit is:

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=2fc904111d9b6ec45fc1e4ec9f1f8b43c1e67b9b

If you were testing 2.88 or 2.89 then we'll need to look again.



Cheers,

Simon.

On 01/03/2023 15:58, Daniel Danzberger wrote:

Hi,

the segfault occurs when a custom 'server=/domain.test/#' entry is defined in 
the config,
but no upstream dns server is available yet.

The full valgrind crash log and config to reproduce the issue are below:

root@lappi:[dnsmasq]:# valgrind --track-origins=yes ./src/dnsmasq 
--conf-file=/tmp/dnsmasq.conf -k
==683879== Memcheck, a memory error detector
==683879== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==683879== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==683879== Command: ./src/dnsmasq --conf-file=/tmp/dnsmasq.conf -k
==683879==
==683879== Warning: invalid file descriptor 1024 in syscall close()
==683879== Warning: invalid file descriptor 1025 in syscall close()
==683879== Warning: invalid file descriptor 1026 in syscall close()
==683879== Warning: invalid file descriptor 1027 in syscall close()
==683879==    Use --log-fd= to select an alternative log fd.
==683879== Warning: invalid file descriptor 1028 in syscall close()
==683879== Warning: invalid file descriptor 1029 in syscall close()
==683879== Warning: invalid file descriptor 1030 in syscall close()
==683879== Invalid read of size 4
==683879==    at 0x129BED: forward_query (forward.c:353)
==683879==    by 0x12A756: receive_query (forward.c:1869)
==683879==    by 0x12ECEA: check_dns_listeners (dnsmasq.c:1843)
==683879==    by 0x110B38: main (dnsmasq.c:1264)
==683879==  Address 0x4a60560 is 16 bytes before a block of size 11 alloc'd
==683879==    at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==683879==    by 0x11AD60: safe_malloc (util.c:302)
==683879==    by 0x11C3CC: opt_malloc (option.c:633)
==683879==    by 0x11C3CC: opt_string_alloc (option.c:645)
==683879==    by 0x11F03B: one_opt (option.c:2346)
==683879==    by 0x125578: read_file (option.c:5381)
==683879==    by 0x125A0B: one_file (option.c:5487)
==683879==    by 0x126608: read_opts (option.c:5854)
==683879==    by 0x10FA0C: main (dnsmasq.c:104)
==683879==
==683879== Invalid write of size 4
==683879==    at 0x129BF7: forward_query (forward.c:353)
==683879==    by 0x12A756: receive_query (forward.c:1869)
==683879==    by 0x12ECEA: check_dns_listeners (dnsmasq.c:1843)
==683879==    by 0x110B38: main (dnsmasq.c:1264)
==683879==  Address 0x4a60560 is 16 bytes before a block of size 11 alloc'd
==683879==    at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==683879==    by 0x11AD60: safe_malloc (util.c:302)
==683879==    by 0x11C3CC: opt_malloc (option.c:633)
==683879==    by 0x11C3CC: opt_string_alloc (option.c:645)
==683879==    by 0x11F03B: one_opt (option.c:2346)
==683879==    by 0x125578: read_file (option.c:5381)
==683879==    by 0x125A0B: one_file (option.c:5487)
==683879==    by 0x126608: read_opts (option.c:5854)
==683879==    by 0x10FA0C: main (dnsmasq.c:104)
==683879==
==683879== Invalid read of size 8
==683879==    at 0x129C07: forward_query (forward.c:354)
==683879==    by 0x12A756: receive_query (forward.c:1869)
==683879==    by 0x12ECEA: check_dns_listeners (dnsmasq.c:1843)
==683879==    by 0x110B38: main (dnsmasq.c:1264)
==683879==  Address 0x4a60558 is 24 bytes before a block of size 11 alloc'd
==683879==    at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==683879==    by 0x11AD60: safe_malloc (util.c:302)
==683879==    by 0x11C3CC: opt_malloc (option.c:633)
==683879==    by 0x11C3CC: opt_string_alloc (option.c:645)
==683879==    by 0x11F03B: one_opt (option.c:2346)
==683879==    by 0x125578: read_file (option.c:5381)
==683879==    by 0x125A0B: one_file (option.c:5487)
==683879==    by 0x126608: read_opts (option.c:5854)
==683879==    by 0x10FA0C: main (dnsmasq.c:104)
==683879==
==683879== Invalid write of size 4
==683879==    at 0x129502: forward_query (forward.c:358)
==683879==    by 0x12A756: receive_query (forward.c:1869)
==683879==    by 0x12ECEA: check_dns_listeners (dnsmasq.c:1843)
==683879==    by 0x110B38: main (dnsmasq.c:1264)
==683879==  Address 0x4a60560 is 16 bytes before a block of size 11 alloc'd
==683879==    at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==683879==    by 0x11AD60: safe_malloc (util.c:302)
==683879==    by 0x11C3CC: opt_malloc (option.c:633)
==683879==    by 0x11C3CC: opt_string_alloc (option.c:645)
==683

Re: [Dnsmasq-discuss] [PATCH] Fix --rev-server option

[Simon Kelley]

Patch applied.

Cheers,

Simon.

On 03/03/2023 17:17, Dominik Derigs wrote:

Hey Simon, CC list,

the --rev-server option is currently broken in the released
version of dnsmasq for any non-dividable-by-eight CIDR
subnets.

It got broken in commit 1db9943 when resolving upstream
servers by name was extended to --rev-server without
accounting for the fact that rev-server is a special edge-
case. Re-using one and the same upstream server for each of
the x.y.z.in-addr.arpa is actually a wanted feature and
should not be suppressed.

A very simple patch for this is attached.

The offending commit on our mirror:
https://github.com/pi-hole/dnsmasq/commit/1db9943c6879c160a5fbef885d5ceadd3668b74d

The proposed fix:
https://github.com/pi-hole/dnsmasq/pull/13

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] Segfault when no uplink dns server is available

[Simon Kelley]

Thanks for the comprehensive analysis.

You don't mention what version of dnsmasq you were testing.


I think that this was fixed in release 2.88, the commit is:

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=2fc904111d9b6ec45fc1e4ec9f1f8b43c1e67b9b

If you were testing 2.88 or 2.89 then we'll need to look again.



Cheers,

Simon.

On 01/03/2023 15:58, Daniel Danzberger wrote:

Hi,

the segfault occurs when a custom 'server=/domain.test/#' entry is defined in 
the config,
but no upstream dns server is available yet.

The full valgrind crash log and config to reproduce the issue are below:

root@lappi:[dnsmasq]:# valgrind --track-origins=yes ./src/dnsmasq 
--conf-file=/tmp/dnsmasq.conf -k
==683879== Memcheck, a memory error detector
==683879== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==683879== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==683879== Command: ./src/dnsmasq --conf-file=/tmp/dnsmasq.conf -k
==683879==
==683879== Warning: invalid file descriptor 1024 in syscall close()
==683879== Warning: invalid file descriptor 1025 in syscall close()
==683879== Warning: invalid file descriptor 1026 in syscall close()
==683879== Warning: invalid file descriptor 1027 in syscall close()
==683879==Use --log-fd= to select an alternative log fd.
==683879== Warning: invalid file descriptor 1028 in syscall close()
==683879== Warning: invalid file descriptor 1029 in syscall close()
==683879== Warning: invalid file descriptor 1030 in syscall close()
==683879== Invalid read of size 4
==683879==at 0x129BED: forward_query (forward.c:353)
==683879==by 0x12A756: receive_query (forward.c:1869)
==683879==by 0x12ECEA: check_dns_listeners (dnsmasq.c:1843)
==683879==by 0x110B38: main (dnsmasq.c:1264)
==683879==  Address 0x4a60560 is 16 bytes before a block of size 11 alloc'd
==683879==at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==683879==by 0x11AD60: safe_malloc (util.c:302)
==683879==by 0x11C3CC: opt_malloc (option.c:633)
==683879==by 0x11C3CC: opt_string_alloc (option.c:645)
==683879==by 0x11F03B: one_opt (option.c:2346)
==683879==by 0x125578: read_file (option.c:5381)
==683879==by 0x125A0B: one_file (option.c:5487)
==683879==by 0x126608: read_opts (option.c:5854)
==683879==by 0x10FA0C: main (dnsmasq.c:104)
==683879==
==683879== Invalid write of size 4
==683879==at 0x129BF7: forward_query (forward.c:353)
==683879==by 0x12A756: receive_query (forward.c:1869)
==683879==by 0x12ECEA: check_dns_listeners (dnsmasq.c:1843)
==683879==by 0x110B38: main (dnsmasq.c:1264)
==683879==  Address 0x4a60560 is 16 bytes before a block of size 11 alloc'd
==683879==at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==683879==by 0x11AD60: safe_malloc (util.c:302)
==683879==by 0x11C3CC: opt_malloc (option.c:633)
==683879==by 0x11C3CC: opt_string_alloc (option.c:645)
==683879==by 0x11F03B: one_opt (option.c:2346)
==683879==by 0x125578: read_file (option.c:5381)
==683879==by 0x125A0B: one_file (option.c:5487)
==683879==by 0x126608: read_opts (option.c:5854)
==683879==by 0x10FA0C: main (dnsmasq.c:104)
==683879==
==683879== Invalid read of size 8
==683879==at 0x129C07: forward_query (forward.c:354)
==683879==by 0x12A756: receive_query (forward.c:1869)
==683879==by 0x12ECEA: check_dns_listeners (dnsmasq.c:1843)
==683879==by 0x110B38: main (dnsmasq.c:1264)
==683879==  Address 0x4a60558 is 24 bytes before a block of size 11 alloc'd
==683879==at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==683879==by 0x11AD60: safe_malloc (util.c:302)
==683879==by 0x11C3CC: opt_malloc (option.c:633)
==683879==by 0x11C3CC: opt_string_alloc (option.c:645)
==683879==by 0x11F03B: one_opt (option.c:2346)
==683879==by 0x125578: read_file (option.c:5381)
==683879==by 0x125A0B: one_file (option.c:5487)
==683879==by 0x126608: read_opts (option.c:5854)
==683879==by 0x10FA0C: main (dnsmasq.c:104)
==683879==
==683879== Invalid write of size 4
==683879==at 0x129502: forward_query (forward.c:358)
==683879==by 0x12A756: receive_query (forward.c:1869)
==683879==by 0x12ECEA: check_dns_listeners (dnsmasq.c:1843)
==683879==by 0x110B38: main (dnsmasq.c:1264)
==683879==  Address 0x4a60560 is 16 bytes before a block of size 11 alloc'd
==683879==at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==683879==by 0x11AD60: safe_malloc (util.c:302)
==683879==by 0x11C3CC: opt_malloc (option.c:633)
==683879==by 0x11C3CC: opt_string_alloc (option.c:645)
==683879==by 0x11F03B: one_opt (option.c:2346)
==683879==by 0x125578: read_file (option.c:5381)
==683879==by 0x125A0B: one_file (option.c:5487)
==683879==by 0x126608: read_opts (option.c:5854)
==683879==by 0x10FA0C: main (dnsmasq.c:104)
==683879==
==683879== Invalid write of size 8
==683879==at 0x12950C: forward_query (forward.c:357)
==683879==by 0x12A756: receive_query 

Re: [Dnsmasq-discuss] Feature Request: DNS over TLS or HTTPS

[Simon Kelley]

If you were to implement this in dnsmasq, by far the best way would be 
to put proxy in front of dnsmasq.


The existing dnsmasq concurrency model just doesn't support the 
implementation. If relies on most queries happening over UDP, and the 
context for such queries being very minimal. Anything that happens over 
TCP (like TLS or HTTPs) is the opposite extreme, with a new dnsmasq 
process being spawned for each request. That's not scalable when you're 
going to run everything upstream over TCP.


Given that the preferred architecture is a proxy in front of dnsmasq, 
the next question is, do we have to implement that, or does it already 
exist?  A quick Google reveals several potential candidates and the one 
that I've most heard people are using is dnscrypt-proxy.


I have no personal experience with dnscrypt-proxy  or any of the other 
options, but before thinking about writing  another one, I'd like to be 
sure that none of the existing options are suitable, and that I couldn't 
persuade someone else to do the work rather than making it part of the 
dnsmasq effort.



Simon.



On 27/02/2023 18:06, Curzon Dax via Dnsmasq-discuss wrote:

Greetings,

I checked through the last 1-2 years of the mailing list, and I hadn't 
seen anything regarding DoT/DoH. If this has come up before and I missed 
it, apologies in advance.


Thought I'd add a feature request for DNS over TLS or DNS over HTTPS 
when dnsmasq is used as a DNS forwarder.


BIND is about to implement this in the next version, and I believe 
Windows DNS is the last to the party among the other major DNS 
recursors/forwarders.


I realize that this could add considerable size, scope, and complexity 
to something which is inherently light weight and used on a lot of 
embedded devices with very minimal storage. Perhaps something optional 
at build time to avoid bundling large libraries/dependencies. embed-TLS 
could be something to look at to ensure this feature could be built on 
very-low-storage, embedded devices.


I know that many embedded devices (modems/routers) have some form of an 
SSL library already, as many offer admin control over https://.


If there is interest by the developers/maintainers, perhaps we could 
make a call for financial support from the major recursive providers 
(Google, Quad9, Cloudflare, etc). I know a few of the DNS folks at these 
organizations, and while I'm not making any promises or claims, it's 
something I'd be happy to reach out to them about.


Thanks in advance.
-Curzon

___
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] How to set no gateway

[Simon Kelley]

On 25/02/2023 00:05, Donald Muller wrote:


Thank you for responding Matus. It worked perfectly!

This behavior should really be documented.


My first reaction to this was "I'm sure it is!" but actually it isn't, 
except in the example config file.


I've added a paragraph to the man page to fix that.

Simon.



Don


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
42.7 percent of all statistics are made up on the spot.

___
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



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] consider adding a `dnsmasq --no-read-or-load-any-config` feature?

[Simon Kelley]

How does it differ from --conf-file=/dev/null

Simon.


On 04/03/2023 21:22, Johnny Utahh wrote:

Is this worth considering?

Proposal: add a `dnsmasq --no-read-or-load-any-config` feature.

Details:

1. 
https://www.reddit.com/r/linuxadmin/comments/11gp2he/dnsmasq_noreadconfig_does_this_or_some_similar/
2. 
https://github.com/rthalley/dnspython/discussions/877#discussioncomment-5203605
3. 
https://gist.githubusercontent.com/johnnyutahh/4d64d2d5927a6f0569c64a345a3f3e78/raw/


~J
--
//

___
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] ipv6 slaac or stateless - No address or no address range available

[Simon Kelley]

On 27/02/2023 20:10, Eric Fahlgren wrote:

Does 'option6:3' translate this from DHCPv4's 'router' to an RA, or does 
it consider it to be DHCPv6 'OPTION_IA_NA'?  Does the 'option6:6' 
(OPTION_ORO) use DHCPv4 dns-server semantics, or does it interpret it as 
DHCPv6 23, OPTION_DNS_SERVERs, or maybe even translate it to an RA RDNSS 
message???




values of DHCPv6 options 23 and 24 (DNS server and domain search list) 
are automatically used to populate RA options  25 and 31 which transmit 
the same information in RA-land.


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] ipv6 slaac or stateless - No address or no address range available

[Simon Kelley]

On 27/02/2023 20:10, Eric Fahlgren wrote:


On Mon, Feb 27, 2023 at 8:15 AM Simon Kelley <mailto:si...@thekelleys.org.uk>> wrote:



On 25/02/2023 16:19, Daniel via Dnsmasq-discuss wrote:
 > dhcp-option=tag:computer6,option6:3,fd99:1234:beef:cafe::2
 > dhcp-option=tag:computer6,option6:6,fd99:1234:beef:cafe::1
 > dhcp-option=tag:computer6,option6:ntp-server,fd99:1234:beef:cafe::2

...This all got a bit superseded
when the IETF started defining options on the RA packets for the common
configuration options.


Sort of on-topic, but sort of tangential, how will dnsmasq interpret the 
above three settings?


https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml 
<https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml>

Does 'option6:3' translate this from DHCPv4's 'router' to an RA, or does 
it consider it to be DHCPv6 'OPTION_IA_NA'?  Does the 'option6:6' 
(OPTION_ORO) use DHCPv4 dns-server semantics, or does it interpret it as 
DHCPv6 23, OPTION_DNS_SERVERs, or maybe even translate it to an RA RDNSS 
message???


I can see how with 'option6:ntp-server' using the logical name it would 
use DHCPv6 56,  OPTION_NTP_SERVER, but with the numerical 'option6:' 
values does it "do the right thing", or are those two option settings 
basically nonsense?


They are nonsense. If numeric option codes are used with option6 they 
need to be numbers from the DHCPv6 option namespace.



Simon.



Eric




___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] ipv6 slaac or stateless - No address or no address range available

[Simon Kelley]

On 25/02/2023 16:19, Daniel via Dnsmasq-discuss wrote:

Hi,

I'm banging my head with a KVM VM only ipv6 who can't get stateless 
dhcpv6 address. Always getting messages like shown below:


Configuration being

enable-ra
ra-param=lan,high,60,60
dhcp-range=set:computer6,::0,::,constructor:lan,ra-stateless,ra-names,1h
dhcp-option=tag:computer6,option6:3,fd99:1234:beef:cafe::2
dhcp-option=tag:computer6,option6:6,fd99:1234:beef:cafe::1
dhcp-option=tag:computer6,option6:ntp-server,fd99:1234:beef:cafe::2

Starting dnsmasq I get in logs

Feb 25 16:52:38 dnsmasq[211076]: demarré, version 2.85 (taille de cache 
2048)

[...]
Feb 25 16:52:38 dnsmasq-dhcp[211076]: DHCPv6 sans état (stateless) sur lan
Feb 25 16:52:38 dnsmasq-dhcp[211076]: noms IPv6 dérivés de DHCPv4 sur lan
Feb 25 16:52:38 dnsmasq-dhcp[211076]: annonces de routeurs sur lan

Feb 25 16:52:38 dnsmasq-dhcp[211076]: annonces de routeur IPv6 activées

[...]
Feb 25 16:53:09 dnsmasq-dhcp[211076]: pas de plage d'adresse disponible 
pour la requête DHCPv6 via lan


or configuration being

enable-ra
ra-param=lan,high,60,60
dhcp-range=set:computer6,fd99:1234:beef:cafe::0,fd99:1234:beef:cafe::,slaac,ra-names,1h
dhcp-option=tag:computer6,option6:3,fd99:1234:beef:cafe::2
dhcp-option=tag:computer6,option6:6,fd99:1234:beef:cafe::1
dhcp-option=tag:computer6,option6:ntp-server,fd99:1234:beef:cafe::2

Feb 25 17:10:32 dnsmasq[214786]: demarré, version 2.85 (taille de cache 
2048)

[...]
Feb 25 17:10:32 dnsmasq-dhcp[214786]: DHCPv6, plage d'adresses IP 
fd99:1234:beef:cafe:: -- fd99:1234:beef:cafe::, durée de bail 1h
Feb 25 17:10:32 dnsmasq-dhcp[214786]: noms IPv6 dérivés de DHCPv4 sur 
fd99:1234:beef:cafe::
Feb 25 17:10:32 dnsmasq-dhcp[214786]: annonces de routeurs sur 
fd99:1234:beef:cafe::

Feb 25 17:10:32 dnsmasq-dhcp[214786]: annonces de routeur IPv6 activées
[...]
Feb 25 17:11:37 dnsmasq-dhcp[214786]: DHCPSOLICIT(lan) 
00:01:00:01:27:b4:3b:4d:52:54:00:e5:33:8a
Feb 25 17:11:37 dnsmasq-dhcp[214786]: DHCPREPLY(lan) 
00:01:00:01:27:b4:3b:4d:52:54:00:e5:33:8a pas d'adresse disponible


Interface lan is a bridge of eth0 if it matter.

Any clue on whats going on here ? Thanks for your support.


"Stateless" dhcpv6 means using DHCP just to get configuration 
information, NOT allocating an address. The host is supposed to get its 
addresses via the router advertisements and use the DHCP request just to 
find DNS servers and other configuration. This all got a bit superseded 
when the IETF started defining options on the RA packets for the common 
configuration options.


TLDR; If you want your host to get an address via DHCPv6, don't 
configure stateless DHCP.


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] Is leasquery supported in Dnsmasq

[Simon Kelley]

src/rfc2131.c has all the relevant code: add code to handle 
DHCPLEASEQUERY to the switch in dhcp_repy();


HOWEVER. Whilst the RFC sort of makes this sound like a general query 
system, it's actually a hack to solve a specific problem that access 
concentrators don't have persistent storage, so this allows them to rely 
on the DHCP server to persistently store Relay Agent Information



   If the Relay Agent Information (option 82) is specified in the
   Parameter Request List, then the information contained in the most
   recent Relay Agent Information option received from the relay agent
   associated with this IP address MUST be included in the
   DHCPLEASEACTIVE message.


This is the biggest problem, since dnsmasq doesn't store that 
information in its lease database either. Adding that info is a large 
undertaking, with compatibility risks.


The quote above make it clear that, even if you application doesn't need 
option 82 information, an RFC-compliant implementation of LEASEQUERY 
does, and it's not a small job.


Simon.





On 24/02/2023 19:10, Rashi Krishna wrote:
Thanks for the update. If I want to add the code myself, do you have any 
pointers to where to get started from?


Thanks again,
Rashi

On Fri, 24 Feb, 2023, 16:23 Nicolas Cavallari, 
> wrote:


On 24/02/2023 10:13, Rashi Krishna wrote:
 > Hi all.
 >
 > I just wanted to know if leasequery is supported in Dnsmasq. I tried
 > sending a leasequery to the server, but I couldn't get any response.

There does not seem to be any leasequery (RFC 4388) support in dnsmasq.


___
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] Query on "strict-order"

[Simon Kelley]

On 23/02/2023 13:58, Gomathi Shankar P S wrote:

Hi Simon,
Thanks for the response.

We have updated resolv.dnsmasq file with couple of false nameservers 
(just to experiment) at the top. With pinging /google.com 
/, we could observe that the dnsmasq (with 
*strict-order*) is reaching out to first nameserver and then to next 
nameserver and it gives up as both nameservers failed to respond.
With the immediate ping again, dnsmasq reached to third nameserver this 
time which resolved /google.com /.
We have tested the same with *dnsmasq* *v2.86* and we could see the same 
behavior.


Could you please confirm that dnsmasq (with *strict-order*) reaches out 
only to the top two nameservers one by one and gives up if both fail to 
respond? We are expecting dnsmasq to reach all the nameservers one by 
one until it gets the response.


Unfortunately, exactly what happens depends on how the client behaves. 
The first attempt at the query by the client gets sent to the first 
server, the second attempt goes to the second server, and so on. Most 
clients give up after one retry, so only the first two servers get 
queries. If you configure your clients to make more retries you'll see 
more upstream servers get hit.


There's a fundamental limitation of the DNS UDP protocol: there's 
nothing that dnsmasq can send to the client which means "I'm still 
working, please wait". If the client doesn't see an answer during its 
timeout period, it will give up and it makes no difference if dnsmasq is 
still working down a long list of servers.


This is why strict-order is generally a bad idea: without strict order 
dnsmasq can send the query to all available servers in parallel, and it 
does much better at finding one which works.


Cheers,

Simon.



I agree that having unreliable upstream servers are not recommended but 
sometimes our nameservers fail to respond due to other issues.


Thanks
Gomathi Shankar P S


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Query on "strict-order"

[Simon Kelley]

OK, I can belive that behaves in the way you've seen, and there's not 
way to alter that.


You should try the latest release, and also configure fast-retry, that 
might give your better behaviour. It's still the case that 
"strict-order" is not really compatible with dealing with unreliable 
upstream servers. Dnsmasq does much better at that when it can try for 
an answer from any server.


Simon.


On 22/02/2023 03:38, Gomathi Shankar P S wrote:

Hi Simon,

We are using Dnsmasq v2.83

Thanks
Gomathi Shankar P S


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Query on "strict-order"

[Simon Kelley]

What release of dnsmasq are you using? The behaviour around SERVFAIL has 
changed several times over the years.


Simon.



On 21/02/2023 10:39, Gomathi Shankar P S wrote:

Hello,

Sorry for asking a basic question.

I was experimenting with "strict-order" and I could see that dnsmasq 
reaches out only top two nameservers in resolv.dnsmasq in the order. 
When both nameservers at top order fails with SERVFAIL , dnsmasq is 
giving up. Do we have any options to configure the number of nameservers 
it should try with "strict-order" enabled?


Appreciate your help.

Regards,
Gomathi Shankar P S

___
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] DHCPv6 - Relay-reply dhcpv6.option.type 79 Client Link-Layer Address with zero length

[Simon Kelley]

On 12/02/2023 16:19, Harald Jensas wrote:

On 2/11/23 23:39, Simon Kelley wrote:

Is dnsmasq acting as the relay or as the DHCP server in that pcap?

Simon.



dnsmasq is acting as the DHCP server in the attached pcap.


I'm confused.

The code in dnsmasq to handle a dhcpv6 packet which has been relayed is 
at line 233 in src/rfc3315.c


For each option in the relayed message:

If it's an encapsulated DHCPv6 request, is gets replaced with an 
encapsulated DHCPv6 reply.


Any other option gets copied from the request to the reply EXCEPT option 
79, which is not copied at all.


I can't see where the zero-length option 79 is coming from in that code, 
it shouldn't be copied at all.



Looking at git blame, this code was fixed in 2019, around version 2.81. 
Are you using really old code?


Cheers,

Simon.






--
Harald



On 10/02/2023 17:01, Harald Jensas wrote:

Hi,

The router is dropping relay replies from dnsmasq because it sees the 
Option 79 with lenght of 0 as invalie, i.e less that minimum length.


I have attached a pcap file showing that the reply from dnsmasq does 
include Option 79 with len == 0.


RFC6939 - 6.  DHCPv6 Server Behavior

"""
There is no requirement that a server return this option and its data
in a downstream DHCP message.
"""

I think we want to either copy all of the option data from the 
Relay-forward message, or simply drop the entire option in the reply?



--
Harald Jensås

___
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



___
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] DHCPv6 - Relay-reply dhcpv6.option.type 79 Client Link-Layer Address with zero length

[Simon Kelley]

Is dnsmasq acting as the relay or as the DHCP server in that pcap?

Simon.


On 10/02/2023 17:01, Harald Jensas wrote:

Hi,

The router is dropping relay replies from dnsmasq because it sees the 
Option 79 with lenght of 0 as invalie, i.e less that minimum length.


I have attached a pcap file showing that the reply from dnsmasq does 
include Option 79 with len == 0.


RFC6939 - 6.  DHCPv6 Server Behavior

"""
There is no requirement that a server return this option and its data
in a downstream DHCP message.
"""

I think we want to either copy all of the option data from the 
Relay-forward message, or simply drop the entire option in the reply?



--
Harald Jensås

___
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] logging DHCPDISCOVER

[Simon Kelley]

If you set the log-dhcp option in the dnsmasq config, it will log all 
the options being sent to the client, which should include a copy of the 
vendor-class received from the client.



Cheers,

Simon.

On 09/02/2023 20:54, Carl Karsten wrote:

I want to gather stats on how often I don't get a 2nd DHCPDISCOVER.
my plan is to log for a day, and then parse/analyze the log.

I could use some help creating the log.
I think I want to log
Vendor-Class (60), length 32: "PXEClient:Arch:0:UNDI:002001"
as that seems to be how I can tell if this is the first or 2nd dhcp.

details:

I have 10 raspi pi net booting
server is dnsmasq which is working fine.

the pi's closed source bootcode.bin does dhcp and requests/gets the kernel:

Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-dhcp[21125]:
DHCPDISCOVER(eth-local) b8:27:eb:86:39:63
Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-dhcp[21125]: DHCPOFFER(eth-local)
10.21.0.136 b8:27:eb:86:39:63
Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-tftp[21125]: file
/srv/tftp/bootsig.bin not found
Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-tftp[21125]: sent
/srv/tftp/bootcode.bin to 10.21.0.136
Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-dhcp[21125]:
DHCPDISCOVER(eth-local) b8:27:eb:86:39:63
Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-dhcp[21125]: DHCPOFFER(eth-local)
10.21.0.136 b8:27:eb:86:39:63
Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-tftp[21125]: error 0 Early
terminate received from 10.21.0.136
Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-tftp[21125]: failed sending
/srv/tftp/80863963/start.elf to 10.21.0.136
Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-tftp[21125]: file
/srv/tftp/80863963/autoboot.txt not found
Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-tftp[21125]: error 0 Early
terminate received from 10.21.0.136
Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-tftp[21125]: failed sending
/srv/tftp/80863963/start.elf to 10.21.0.136
Feb  9 14:47:59 rpi-cb-1f-f7 dnsmasq-tftp[21125]: sent
/srv/tftp/80863963/config.txt to 10.21.0.136

Feb  9 14:57:50 rpi-cb-1f-f7 dnsmasq-tftp[21125]: sent
/srv/tftp/80863963/kernel8.img to 10.21.0.136
Feb  9 14:58:08 rpi-cb-1f-f7 dnsmasq-dhcp[21125]:
DHCPDISCOVER(eth-local) b8:27:eb:86:39:63
Feb  9 14:58:08 rpi-cb-1f-f7 dnsmasq-dhcp[21125]: DHCPOFFER(eth-local)
10.21.0.136 b8:27:eb:86:39:63
Feb  9 14:58:08 rpi-cb-1f-f7 dnsmasq-dhcp[21125]:
DHCPREQUEST(eth-local) 10.21.0.136 b8:27:eb:86:39:63
Feb  9 14:58:08 rpi-cb-1f-f7 dnsmasq-dhcp[21125]: DHCPACK(eth-local)
10.21.0.136 b8:27:eb:86:39:63 pi36

Feb  9 14:58:10 rpi-cb-1f-f7 dnsmasq-dhcp[21125]:
DHCPDISCOVER(eth-local) b8:27:eb:86:39:63
Feb  9 14:58:10 rpi-cb-1f-f7 dnsmasq-dhcp[21125]: DHCPOFFER(eth-local)
10.21.0.136 b8:27:eb:86:39:63
Feb  9 14:58:10 rpi-cb-1f-f7 dnsmasq-dhcp[21125]:
DHCPREQUEST(eth-local) 10.21.0.136 b8:27:eb:86:39:63
Feb  9 14:58:10 rpi-cb-1f-f7 dnsmasq-dhcp[21125]: DHCPACK(eth-local)
10.21.0.136 b8:27:eb:86:39:63 pi36
Feb  9 14:58:10 rpi-cb-1f-f7 rpc.mountd[22860]: authenticated mount
request from 10.21.0.136:936 for /srv/nfs/rpi/bullseye/root
(/srv/nfs/rpi/bullseye/root)
Feb  9 14:58:24 rpi-cb-1f-f7 dnsmasq-dhcp[21125]:
DHCPDISCOVER(eth-local) b8:27:eb:86:39:63
Feb  9 14:58:24 rpi-cb-1f-f7 dnsmasq-dhcp[21125]: DHCPOFFER(eth-local)
10.21.0.136 b8:27:eb:86:39:63
Feb  9 14:58:24 rpi-cb-1f-f7 dnsmasq-dhcp[21125]:
DHCPREQUEST(eth-local) 10.21.0.136 b8:27:eb:86:39:63
Feb  9 14:58:24 rpi-cb-1f-f7 dnsmasq-dhcp[21125]: DHCPACK(eth-local)
10.21.0.136 b8:27:eb:86:39:63 pi36

Feb  9 14:58:27 rpi-cb-1f-f7 dnsmasq-dhcp[21125]:
DHCPDISCOVER(eth-local) b8:27:eb:86:39:63
Feb  9 14:58:27 rpi-cb-1f-f7 dnsmasq-dhcp[21125]: DHCPOFFER(eth-local)
10.21.0.136 b8:27:eb:86:39:63
Feb  9 14:58:27 rpi-cb-1f-f7 dnsmasq-dhcp[21125]:
DHCPREQUEST(eth-local) 10.21.0.136 b8:27:eb:86:39:63
Feb  9 14:58:27 rpi-cb-1f-f7 dnsmasq-dhcp[21125]: DHCPACK(eth-local)
10.21.0.136 b8:27:eb:86:39:63 pi36
Feb  9 14:58:30 rpi-cb-1f-f7 rpc.mountd[22860]: authenticated mount
request from 10.21.0.136:733 for /srv/nfs/rpi/bullseye/boot
(/srv/nfs/rpi/bullseye/boot)

serial console on the pi:

Raspberry Pi Bootcode
Read File: config.txt, 2428
Read File: start.elf, 2975104 (bytes)
Read File: fixup.dat, 7265 (bytes)
MESS:00:00:21.012905:0: brfs: File read: /mfs/sd/config.txt

MESS:00:00:48.308603:0: brfs: File read: /mfs/sd/kernel8.img
MESS:00:00:48.312568:0: Loaded 'kernel8.img' to 0x8 size 0x7d0a2c
MESS:00:00:50.482131:0: Kernel relocated to 0x20
MESS:00:00:50.485400:0: Device tree loaded to 0x2e718600 (size 0x89ba)
MESS:00:00:50.494040:0: uart: Set PL011 baud rate to 103448.30 Hz
MESS:00:00:50.500331:0: uart: Baud rate change done...
MESS:00:00:50.503764:0: uart: Baud rate change done...
[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[   15.177883] Run /init as init process
Begin: Running /scripts/nfs-premount ... done.
IP-Config: eth0 hardware address b8:27:eb:86:39:63 mtu 1500 DHCP
IP-Config: eth0 complete (dhcp from 10.21.0.1):
  address: 10.21.0.136  broadcast: 10.21.0.255  netmask:
255.255.255.0

except 'sometimes' a pi will load the kernel, but instead of

Re: [Dnsmasq-discuss] Can't get tags to apply with dhcp-circuitid

[Simon Kelley]

Luckily, we have the  complete data being added by the relay

option: 82 agent-id  01:04:00:64:00:02:02:06:5c:f4:ab:af:6f:9c

That's at circuit-ID (01) of length four (04) value 00:64:00:02
and a remote-id (02) length six (06) value 5c:f4:ab:af:6f:9c

So you can either match against the remote-id


dhcp-remoteid=set:iot,06:5c:f4:ab:af:6f:9c

or against the circuitid

dhcp-circuitid=set:iot,00:64:00:02


In the first case you nearly got it, but matched against circuitid not 
the remoteid, and in both cases you've accidentally copied the length 
byte into the pattern you're matching.


Please be gentle with the facepalm: we don't want to be responsible to 
injuries to dnsmasq users :)


Simon.


On 09/02/2023 19:50, Justin Ellison wrote:

I'm sure the solution to this is really going to make me facepalm, but I've 
been working on this for hours and can't figure out what I'm doing wrong.

I'm using dnsmasq on a pi-hole docker container.  I'm trying to set up dnsmasq 
so that it hands out DHCP requests for multiple vlans.  I've configured my 
switch to relay and to add option 82.  I have pcaps from the docker host that 
show option 82 is being added.  I can also see in the logs that dnsmasq sees 
the option 82 information.  For the life of me, I can't get the tag to apply 
using dhcp-circuitid.  Here's the relevant config where I try to match on the 
agentid:

dhcp-circuitid=set:iot,06:5c:f4:ab:af:6f:9c

I've also tried matching on the circuitid a few different ways:
dhcp-circuitid=set:iot,04:00:64:00:02
dhcp-circuitid=set:iot,0400640002

I then try to use that tag to set a custom range like so:

dhcp-range=tag:iot,set:shared,192.168.3.1,192.168.3.254,255.255.254.0,24h

With debug logging, I can see option 82 with the correct values being sent, but it just 
won't assign the "iot" tag:

Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 available DHCP range: 
192.168.3.1 -- 192.168.3.254
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 available DHCP range: 
172.31.10.99 -- 172.31.10.199
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 client provides name: 
KRY-MB-AE-021
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 DHCPDISCOVER(enp3s0) 
f4:d4:88:5f:05:2f
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 tags: enp3s0
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 DHCPOFFER(enp3s0) 172.31.10.103 
f4:d4:88:5f:05:2f
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 requested options: 1:netmask, 
121:classless-static-route, 3:router,
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 requested options: 6:dns-server, 
15:domain-name, 108:ipv6-only,
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 requested options: 114, 
119:domain-search, 252, 95, 44:netbios-ns,
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 requested options: 
46:netbios-nodetype
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 next server: 172.31.10.2
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 sent size:  1 option: 53 
message-type  2
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 sent size:  4 option: 54 
server-identifier  172.31.10.2
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 sent size:  4 option: 51 
lease-time  1d
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 sent size:  4 option: 58 T1  12h
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 sent size:  4 option: 59 T2  21h
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 sent size:  4 option:  1 netmask 
 255.255.255.0
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 sent size:  4 option: 28 
broadcast  172.31.10.255
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 sent size:  4 option:  6 
dns-server  172.31.10.2
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 sent size: 14 option: 15 
domain-name  techadvise.com
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 sent size:  4 option:  3 router  
172.31.10.1
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3615888487 sent size: 14 option: 82 
agent-id  01:04:00:64:00:02:02:06:5c:f4:ab:af:6f:9c
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 available DHCP range: 
192.168.3.1 -- 192.168.3.254
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 available DHCP range: 
172.31.10.99 -- 172.31.10.199
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 client provides name: 
KRY-MB-AE-021
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 DHCPDISCOVER(enp3s0) 
f4:d4:88:5f:05:2f
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 tags: enp3s0
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 DHCPOFFER(enp3s0) 172.31.10.103 
f4:d4:88:5f:05:2f
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 requested options: 1:netmask, 
121:classless-static-route, 3:router,
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 requested options: 6:dns-server, 
15:domain-name, 108:ipv6-only,
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 requested options: 114, 
119:domain-search, 252, 95, 44:netbios-ns,
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 requested options: 
46:netbios-nodetype
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 next server: 172.31.10.2
Feb  9 13:45:48 dnsmasq-dhcp[3033]: 3372121439 sent size:  1 option: 53 

Re: [Dnsmasq-discuss] dnsmasq (pihole) caching of HTTPS requested

[Simon Kelley]

On 31/01/2023 12:01, Petr Menšík wrote:

On 19. 01. 23 11:57, Simon Kelley wrote:

Addendum.

I just looked at the latest draft (11) rather than draft zero whixh 
was linked here. That makes it clear that the additional processing is 
optional, so simply caching SVCB recpords might be a usable option.



Opinions? I'm basing this on a 10 minute skim of the draft, does 
anyone have more information?


Simon.


Yes, I also think we can just cache the record as any good recursive 
server. Additional records may or may not be stored to cache too, but 
that is clearly optional. If they are, similar restrictions to CNAME 
processing should be done. I think we should rely on clients be able to 
ask them.


I think dnsmasq should be modified to cache any reasonably short 
response, no matter what record type it contains. It is not necessary to 
cache PGP keys, but HTTPS and SVCB might be queried before each 
connection. It makes sense to cache those. I think type of record should 
be made separate cache field instead of encoding it in flags field. Only 
loggers should be taught to provide descriptions for common types and 
just simplified for more unusual types. Current code has it quite 
entangled into the logic and is difficult to add just selected new 
records. I agree that HTTPS RR would be the best candidate now. Ideally 
dnsmasq should be able to collect record query types per some period and 
cache most queried types, whatever it is. But sure, that would require 
non-trivial logic updates.


There's actually already code to cache arbitrary-length RRs. It was 
built for DNSKEY and DS records in the DNSSEC campaign, but it's 
subsequently been used to cache SRV records. Expanding the SRV caching 
code to cache from an arbitrary list is a reasonable thing to do. The 
list of cached RRS could default to SRV and SVCB, but allowing 
configuration of an arbitrary list would be easy and useful.


I think we should cache HTTPS response and just that record response. 
Rely on clients to ask additional records until we implement logic to 
store those related records as well. And for cases where some clients 
cannot handle well what they should, allow runtime cache disabling for 
selected record types, including HTTPS. New option --skip-cache-rr=https 
maybe?


Or that, I prefer my suggestion because it's a smaller behaviour change 
without explicit configuration.


Or we could modify cache to store separate records for ANSWER and 
ADDITIONAL sections. If we can respond a query with multiple records of 
different types and into multiple sections, that would solve the 
problem, right? We do not do iterative queries, so we just need to 
answer with all records our upstream has included. That might help also 
with CNAME or DNAME following, right?


That's a fairly big change to the cache code.


Simon.



Just my 2 cents.

Cheers,
Petr




On 19/01/2023 00:20, Dan Schaper via Dnsmasq-discuss wrote:
HTTPS is a valid resource record type. It's currently in draft 
status but it's used in the wild rather frequently.


https://developer.mozilla.org/en-US/docs/Glossary/https_rr

https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/

Best,
Dan



___
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