Re: [Touch-packages] [Bug 1974230] [NEW] Negative cache results from dnsmasq do not include SOA as required in RFC2308

[Simon Kelley]

Acknowledge that RFC non-compliance. Fixing this is actually a fairly 
big ask, since the problem is not that dnsmasq omits the SOA when 
answering from cache, but that dnsmasq doesn't cache SOA records. The 
design philosophy was (and is) to cache only a few RR types to make the 
code and data structures simple and small (remember that dnsmasq's niche 
is "lightweight", for low capability hardware). There's been a implied 
assumption that clients using dnsmasq would typically be stub-resolvers, 
and not full-service DNS servers.


That said, the set of cached RR types has increased over the years, 
notably with the introduction of DNSSEC and the RR types needed to 
suuport that. Adding caching of SOA records is possible, but I'm not 
sure it's worth the effort.

A reasonable workaround might be to disable negative caching in dnsmasq 
and rely on systemd-resolved to do that for itself.


Simon.


On 19/05/2022 20:51, Eric Blevins wrote:
> Public bug reported:
> 
> RFC2308 states:
> 6 - Negative answers from the cache
> 
> When a server, in answering a query, encounters a cached negative
> response it MUST add the cached SOA record to the authority section
> of the response with the TTL decremented by the amount of time it was
> stored in the cache.  This allows the NXDOMAIN / NODATA response to
> time out correctly.
> 
> The effect is that the negative cache results returned by dnsmasq cannot
> be cached by other resolvers such as systemd-resolved.
> 
> A good example of why this is a problem:
> Two clients with systemd-resolved send DNS queries to dnsmasq for the same 
> record
> The first one makes a query and gets NXDOMAIN with SOA.
> This results in systemd-resolved caching the negative result.
> 
> The second client makes a query and gets NODATA without the SOA.
> This results in systemd-resolved not caching the negative result.
> 
> Consider a domain name that only has an A record published.
> When connecting to that domain a lookup happens for the  and A record.
> One can end up in a situation where systemd-resolved has the A record cached 
> locally, but it still goes out to the network to perform the  lookup only 
> to get the same negative cache result that is missing the SOA
> 
> I see this behavior in 18.04 and 22.04
> 
> 
> First query to dnsmasq can be cached:
> dig @10.0.1.21 a.google.com
> 
> ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.1.21 a.google.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3107
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;a.google.com.  IN  A
> 
> ;; AUTHORITY SECTION:
> google.com. 60  IN  SOA ns1.google.com. 
> dns-admin.google.com. 449437361 900 900 1800 60
> 
> ;; Query time: 15 msec
> ;; SERVER: 10.0.1.21#53(10.0.1.21)
> ;; WHEN: Thu May 19 15:00:12 EDT 2022
> ;; MSG SIZE  rcvd: 91
> 
> 
> Cached response from dnsmasq cannot be cached:
> dig @10.0.1.21 a.google.com
> 
> ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.1.21 a.google.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61408
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;a.google.com.  IN  A
> 
> ;; Query time: 0 msec
> ;; SERVER: 10.0.1.21#53(10.0.1.21)
> ;; WHEN: Thu May 19 15:00:13 EDT 2022
> ;; MSG SIZE  rcvd: 41
> 
> ** Affects: dnsmasq (Ubuntu)
>   Importance: Undecided
>   Status: New
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1974230

Title:
  Negative cache results from dnsmasq do not include SOA as required in
  RFC2308

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  RFC2308 states:
  6 - Negative answers from the cache

 When a server, in answering a query, encounters a cached negative
 response it MUST add the cached SOA record to the authority section
 of the response with the TTL decremented by the amount of time it was
 stored in the cache.  This allows the NXDOMAIN / NODATA response to
 time out correctly.

  The effect is that the negative cache results returned by dnsmasq
  cannot be cached by other resolvers such as systemd-resolved.

  A good example of why this is a problem:
  Two clients with systemd-resolved send DNS queries to dnsmasq for the same 
record
  The first one makes a query and gets NXDOMAIN with SOA. 
  This results in systemd-resolved caching the negative result.

  The second client makes a query and gets NODATA without the SOA. 
  This results in systemd-resolved not caching the negative result.

  Consider a domain name that only has an A r

Re: [Touch-packages] [Bug 1782362] [NEW] dnsmasq segfaults on cnames referring to themselves

[Simon Kelley]

This was fixed upstream, in release 2.77.

Simon.


On 18/07/18 14:59, Frank Klaassen wrote:
> Public bug reported:
> 
> If one would add a CNAME-record that would point to itself like so:
> CNAME=test.example.com,test.example.com
> 
> This will result in a segfault and crash of the dnsmasq process.
> 
> Segfault on 14.04 / dnsmasq 2.68:
> dnsmasq[22762]: segfault at 7ffe1727dff8 ip 7f7c60cde755 sp 
> 7ffe1727dff0 error 6 in libc-2.19.so[7f7c60c5e000+1be000]
> 
> Segfault on 16.04 / dnsmasq 2.75:
> dnsmasq[21097]: segfault at 7ffc4bf90ff8 ip 7f268bf7ebbc sp 
> 7ffc4bf90ff0 error 6 in libc-2.23.so[7f268befd000+1c]
> 
> 
> Ubuntu versions affected: Ubuntu 14.04.5 LTS & Ubuntu 16.04.4 LTS
> 
> dnsmasq version (14.04) 2.68-1ubuntu0.2
> dnsmasq version (16.04): 2.75-1ubuntu0.16.04.5
> 
> ** Affects: dnsmasq (Ubuntu)
>  Importance: Undecided
>  Status: New
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1782362

Title:
  dnsmasq segfaults on cnames referring to themselves

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  If one would add a CNAME-record that would point to itself like so:
  CNAME=test.example.com,test.example.com

  This will result in a segfault and crash of the dnsmasq process.

  Segfault on 14.04 / dnsmasq 2.68:
  dnsmasq[22762]: segfault at 7ffe1727dff8 ip 7f7c60cde755 sp 
7ffe1727dff0 error 6 in libc-2.19.so[7f7c60c5e000+1be000]

  Segfault on 16.04 / dnsmasq 2.75:
  dnsmasq[21097]: segfault at 7ffc4bf90ff8 ip 7f268bf7ebbc sp 
7ffc4bf90ff0 error 6 in libc-2.23.so[7f268befd000+1c]

  
  Ubuntu versions affected: Ubuntu 14.04.5 LTS & Ubuntu 16.04.4 LTS

  dnsmasq version (14.04) 2.68-1ubuntu0.2
  dnsmasq version (16.04): 2.75-1ubuntu0.16.04.5

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1782362/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1800347] [NEW] Defining 2 dhcp ranges for static dhcp definition causes dnsmasq to not start - subnet other than /24 not accepted?

[Simon Kelley]

dhcp-range for static ranges is

dhcp-range=,static,..

ie, there's only one address before  the static keyword.

Simon.


On 28/10/2018 12:55, Lutz Heitmüller wrote:
> Public bug reported:
> 
> Description:Ubuntu 18.04.1 LTS
> Release:18.04
> __
> dnsmasq:
>   Installiert:   2.79-1
>   Installationskandidat: 2.79-1
>   Versionstabelle:
>  *** 2.79-1 500
> 500 http://de.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
> 500 http://de.archive.ubuntu.com/ubuntu bionic/universe i386 Packages
> 100 /var/lib/dpkg/status
> __
> 
> #Configuration excerpt:
> listen-address=127.0.0.1
> listen-address=192.168.115.18
> dhcp-range=192.168.114.100,192.168.114.250,255.255.254.0,6h
> 
> #dhcp-range=192.168.115.21,192.168.115.250,static
> #dhcp-range=192.168.114.31,192.168.114.99,static,255.255.254.0,infinite
> 
> As soon as I activate one of the last lines, dnsmasq refuses to start with 
> the error msg that the range was incorrect, although there is no overlap in 
> range, nor is the range incorrect. 
> I am starting to think that this might be a bug, maybe dnsmasq cannot cope 
> with subnets other than /24?
> 
> Thanks for your support!
> 
> ** Affects: dnsmasq (Ubuntu)
>  Importance: Undecided
>  Status: New
> 
> ** Summary changed:
> 
> - Defining 2 dhcp ranges for static dhcp definition causes dnsmasq to not 
> start
> + Defining 2 dhcp ranges for static dhcp definition causes dnsmasq to not 
> start - subnet other than /24 not accepted?
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1800347

Title:
  Defining 2 dhcp ranges for static dhcp definition causes dnsmasq to
  not start - subnet other than /24 not accepted?

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  Description:Ubuntu 18.04.1 LTS
  Release:18.04
  __
  dnsmasq:
Installiert:   2.79-1
Installationskandidat: 2.79-1
Versionstabelle:
   *** 2.79-1 500
  500 http://de.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
  500 http://de.archive.ubuntu.com/ubuntu bionic/universe i386 Packages
  100 /var/lib/dpkg/status
  __

  #Configuration excerpt:
  listen-address=127.0.0.1
  listen-address=192.168.115.18
  dhcp-range=192.168.114.100,192.168.114.250,255.255.254.0,6h

  #dhcp-range=192.168.115.21,192.168.115.250,static
  #dhcp-range=192.168.114.31,192.168.114.99,static,255.255.254.0,infinite

  As soon as I activate one of the last lines, dnsmasq refuses to start with 
the error msg that the range was incorrect, although there is no overlap in 
range, nor is the range incorrect. 
  I am starting to think that this might be a bug, maybe dnsmasq cannot cope 
with subnets other than /24?

  Thanks for your support!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1800347/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1502226] [NEW] error message "dnsmasq: failed to create listening socket for 0.0.0.0: Address already in use" doesn't explain which port number it refers to

[Simon Kelley]

What configuration was in use to get that exact error message. If
dnsmasq is binding the wildcard address (0.0.0.0), I'd expect to see a
message  like

dnsmasq: failed to create listening socket for port 53

Whilst if dnsmasq is configured to bind the hosts addresses, I'd expect
to see something like

dnsmasq: failed to create listening socket for 192.168.151.1

So I'm confused how you're getting the message with an IP address, but
for the 0.0.0.0 wildcard address.

Cheers,

Simon


On 02/10/15 17:24, Karl-Philipp Richter wrote:
> Public bug reported:
> 
> The error message "dnsmasq: failed to create listening socket for
> 0.0.0.0: Address already in use" doesn't explain which port number it
> refers to. In case it's an OS message it needs to be catched and
> enhanced with necessary information (in order to get any use of the
> message).
> 
> ProblemType: Bug
> DistroRelease: Ubuntu 15.04
> Package: dnsmasq 2.72-3ubuntu0.1
> ProcVersionSignature: Ubuntu 3.19.0-30.33-generic 3.19.8-ckt6
> Uname: Linux 3.19.0-30-generic x86_64
> NonfreeKernelModules: zfs zunicode zcommon znvpair zavl fglrx
> ApportVersion: 2.17.2-0ubuntu1.5
> Architecture: amd64
> Date: Fri Oct  2 18:22:22 2015
> InstallationDate: Installed on 2015-04-20 (165 days ago)
> InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release amd64 
> (20141022.2)a 
> PackageArchitecture: all
> ProcEnviron:
>  TERM=screen
>  PATH=(custom, no user)dig @172.17.42.1
> d8607ce495db.node.aws-us-east-1.consul
>  XDG_RUNTIME_DIR=
>  LANG=de_DE.UTF-8
>  SHELL=/bin/bash
> SourcePackage: dnsmasq
> UpgradeStatus: Upgraded to vivid on 2015-04-24 (160 days ago)
> mtime.conffile..etc.dnsmasq.conf: 2015-06-13T18:46:46.597888
> 
> ** Affects: dnsmasq (Ubuntu)dig @172.17.42.1
> d8607ce495db.node.aws-us-east-1.consul
>  Importance: Undecided
>  Status: New
> 
> 
> ** Tags: amd64 apport-bug vivid
> 
> ** Description changed:
> 
> - error message "dnsmasq: failed to create listening socket for 0.0.0.0:
> - Address already in use" doesn't explain which port number it refers to
> + The error message "dnsmasq: failed to create listening socket for
> + 0.0.0.0: Address already in use" doesn't explain which port number it
> + refers to. In case it's an OS message it needs to be catched and
> + enhanced with necessary information (in order to get any use of the
> + message).
>   
>   ProblemType: Bug
>   DistroRelease: Ubuntu 15.04
>   Package: dnsmasq 2.72-3ubuntu0.1
>   ProcVersionSignature: Ubuntu 3.19.0-30.33-generic 3.19.8-ckt6
>   Uname: Linux 3.19.0-30-generic x86_64
>   NonfreeKernelModules: zfs zunicode zcommon znvpair zavl fglrx
>   ApportVersion: 2.17.2-0ubuntu1.5
>   Architecture: amd64
>   Date: Fri Oct  2 18:22:22 2015
>   InstallationDate: Installed on 2015-04-20 (165 days ago)
>   InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release amd64 
> (20141022.2)
>   PackageArchitecture: all
>   ProcEnviron:
> -  TERM=screendig @172.17.42.1
> d8607ce495db.node.aws-us-east-1.consul
> -  PATH=(custom, no user)
> -  XDG_RUNTIME_DIR=
> -  LANG=de_DE.UTF-8
> -  SHELL=/bin/bash
> +  TERM=screen
> +  PATH=(custom, no user)
> +  XDG_RUNTIME_DIR=
> +  LANG=de_DE.UTF-8
> +  SHELL=/bin/bash
>   SourcePackage: dnsmasq
>   UpgradeStatus: Upgraded to vivid on 2015-04-24 (160 days ago)
>   mtime.conffile..etc.dnsmasq.conf: 2015-06-13T18:46:46.597888
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1502226

Title:
  error message "dnsmasq: failed to create listening socket for 0.0.0.0:
  Address already in use" doesn't explain which port number it refers to

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  The error message "dnsmasq: failed to create listening socket for
  0.0.0.0: Address already in use" doesn't explain which port number it
  refers to. In case it's an OS message it needs to be catched and
  enhanced with necessary information (in order to get any use of the
  message).

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: dnsmasq 2.72-3ubuntu0.1
  ProcVersionSignature: Ubuntu 3.19.0-30.33-generic 3.19.8-ckt6
  Uname: Linux 3.19.0-30-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl fglrx
  ApportVersion: 2.17.2-0ubuntu1.5
  Architecture: amd64
  Date: Fri Oct  2 18:22:22 2015
  InstallationDate: Installed on 2015-04-20 (165 days ago)
  InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release amd64 
(20141022.2)
  PackageArchitecture: all
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: Upgraded to vivid on 2015-04-24 (160 days ago)
  mtime.conffile..etc.dnsmasq.conf: 2015-06-13T18:46:46.597888

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1502226/+subscriptions

-- 
Mailing list: https://launchpad.net/~t

Re: [Touch-packages] [Bug 1501189] [NEW] Don't put 127.0.0.1 in resolvconf when port=0

[Simon Kelley]

I'm sympathetic to aim, but this solution is rather fragile, there are
plenty of ways to get dnsmasq to read configuration from places other
than /etc/dnsmasq.conf and /etc/dnsmasq.d/*, for instance adding

conf-file=/path/to/more/configuration

to the existing config files.

It's also possible to override things in /etc/default/dnsmasq.


A better solution might be to extend the IGNORE_RESOLVCONF setting in
/etc/default/dnsmasq so that it inhibits adding 127.0.0.1 to resolvconf,
as well as stopping dnsmasq from using the resolvconf output as upstream.

Simon.



On 30/09/15 07:38, Alkis Georgopoulos wrote:
> Public bug reported:
> 
> The following function is defined in /etc/init.d/dnsmasq:
> 
> start_resolvconf()
> {
> # If interface "lo" is explicitly disabled in /etc/default/dnsmasq
> # Then dnsmasq won't be providing local DNS, so don't add it to
> # the resolvconf server set.
> for interface in $DNSMASQ_EXCEPT
> do
> [ $interface = lo ] && return
> done
> 
> if [ -x /sbin/resolvconf ] ; then
> echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
> fi
> return 0
> }
> 
> When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it 
> only as a (proxy)DHCP/TFTP server,
> 127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens 
> there.
> 
> One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
> But that doesn't make much sense, we don't want to exclude some interface, 
> we're not running a DNS server at all.
> 
> So it would be nice if dnsmasq checked if port=0 is defined in its
> configuration, and didn't add 127.0.0.1 to resolvconf then.
> 
> Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf 
> ]`:
> grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return
> 
> ** Affects: dnsmasq (Ubuntu)
>  Importance: Undecided
>  Status: New
> 
> 
> ** Tags: patch
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1501189

Title:
  Don't put 127.0.0.1 in resolvconf when port=0

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  The following function is defined in /etc/init.d/dnsmasq:

  start_resolvconf()
  {
  # If interface "lo" is explicitly disabled in /etc/default/dnsmasq
  # Then dnsmasq won't be providing local DNS, so don't add it to
  # the resolvconf server set.
  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  if [ -x /sbin/resolvconf ] ; then
  echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
  fi
  return 0
  }

  When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it 
only as a (proxy)DHCP/TFTP server,
  127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens 
there.

  One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
  But that doesn't make much sense, we don't want to exclude some interface, 
we're not running a DNS server at all.

  So it would be nice if dnsmasq checked if port=0 is defined in its
  configuration, and didn't add 127.0.0.1 to resolvconf then.

  Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf 
]`:
  grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1501189/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1501189] Re: DNS breaks when port=0 is used in dnsmasq.conf

[Simon Kelley]

*** This bug is a duplicate of bug 1042275 ***
https://bugs.launchpad.net/bugs/1042275

On 06/10/15 11:08, Alkis Georgopoulos wrote:
> Hi Robie,
> 
> while this also happens in Debian, the use case is more common in Ubuntu, 
> because NetworkManager is patched to use a spawned dnsmasq instance as a 
> local resolver, and mixing the two DNS servers is problematic (neither 
> bind-dynamic nor bind-interfaces work very well).
> In Debian they more frequently use the normal dnsmasq/DNS service as it was 
> designed, because NM doesn't spawn a local resolver there.
> 
> For upstream report, Simon (the upstream dnsmasq developer and Debian
> maintainer) already answered here, Simon would you like me to file a
> debian bug as well? It's easy to work around this issue, so we can even
> close it with won't fix if you prefer.
> 
> Thank you.
> 

No need to file a Debian bug, whatever fix goes in will go into upstream
and Debian anyway.

Cheers,

Simon.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1501189

Title:
  DNS breaks when port=0 is used in dnsmasq.conf

Status in dnsmasq package in Ubuntu:
  Triaged

Bug description:
  The following function is defined in /etc/init.d/dnsmasq:

  start_resolvconf()
  {
  # If interface "lo" is explicitly disabled in /etc/default/dnsmasq
  # Then dnsmasq won't be providing local DNS, so don't add it to
  # the resolvconf server set.
  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  if [ -x /sbin/resolvconf ] ; then
  echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
  fi
  return 0
  }

  When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it 
only as a (proxy)DHCP/TFTP server,
  127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens 
there.

  One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
  But that doesn't make much sense, we don't want to exclude some interface, 
we're not running a DNS server at all.

  So it would be nice if dnsmasq checked if port=0 is defined in its
  configuration, and didn't add 127.0.0.1 to resolvconf then.

  Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf 
]`:
  grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1501189/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1468611] Re: dnsmasq fails to start in lxc-net

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The underlying problem is that 2.73 accidentally change the meaning of

dnsmasq --conf-file

from "don't read any conf-file" to "read the default conf-file".

This is a bug, not a feature, and I've just committed a fix to git.


Cheers,

Simon.


On 26/06/15 20:41, Christopher Townsend wrote:
> Hey Serge,
> 
> Yes, I can confirm that setting "LXC_DHCP_CONFILE=/dev/null" does
> indeed make it work.
> 
> Thanks!
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVmZu1AAoJEBXN2mrhkTWiX0YP/jN8smIOJxSj5A+aXsNhNvAL
P+awNJoTV+qh+CEAaYQkNv+A+2pDbPlggJeJl24jHIsBOURcPM32ziqP9NyOFoQ+
+ryeK9pRLLE2TrrFc7JguM8DYSKlHRzBldTtCzU5Lfiom2PJm3iB96uAdNNsLU5J
dLjicEBhQjs/PnM5x+tonWinGbpyJYJ0Kh9gRg9VG7aG571oyFn56Tj9PxEhZV7c
2rpVomrm2FL+C+9ozRJHcwj+Wv76IeUXSEk1nyjEbr0U+F5AvzdU/wXfydHxQlv/
igB8RivZozaWp2Xz62lnHaRRBA7QSeuCu08vngsKqBmP5HURgejzhOGfmBhnt7ZK
HI35CNXAqAL/RFDiSbSXzzdQOEHN30Ferr0hZr57UxHbOgtFZV+c57wBciEU/gRv
k6tkC/eJ7OuzrPrfK4cxSli2aeQEIDKmesQTrFP63pD11QwSXgBhRousArLqljgE
13RRwDkPXLYF9iKXem5z9qXAAxocmjYqmrQhjq51VUqOM6Svk0vSuZEk2K7TuS2L
tsYNRZDUwIRYpJfzKKnQK1+flh7Y5WorcxWbNfMDBDhtLhUNoCvg4yH5+tI7x7eF
oZAVBXo0mpdJkrmKGjhQkMunssIujsY4Nbc22guv9LWh/OpXteYFAmQRVmZcPHYO
c5soqxgCzoOJNm3KBf2s
=Dj/i
-END PGP SIGNATURE-

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1468611

Title:
  dnsmasq fails to start in lxc-net

Status in dnsmasq package in Ubuntu:
  Confirmed
Status in lxc package in Ubuntu:
  Fix Committed

Bug description:
  The lxc-net systemd service calls /usr/lib/x86_64-linux-gnu/lxc/lxc-
  net start.  This causes

  dnsmasq -s lxc -S /lxc/ -u lxc-dnsmasq --strict-order --bind-
  interfaces --pid-file=/run/lxc/dnsmasq.pid --conf-file= --listen-
  address 10.0.3.1 --dhcp-range 10.0.3.2,10.0.3.254 --dhcp-lease-max=253
  --dhcp-no-override --except-interface=lo --interface=lxcbr0 --dhcp-
  leasefile=/var/lib/misc/dnsmasq.lxcbr0.leases --dhcp-authoritative

  to be run.  With dnsmasq-base   2.72-3.1 this works fine.  With 2.73-1
  it fails with:

  dnsmasq: cannot read /etc/dnsmasq.conf: No such file or directory

  unless one creates /etc/dnsmasq.conf, after which it succeeds.  Is
  this a change in the handling of --conf-file=- ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1468611/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1672099] Re: DNS loop, >5, 000 queries per second for minutes at a time

[Simon Kelley]

Whenever the set of servers to which dnsmasq is forwarding queries
changes, the whole set is logged to syslog. It would be useful to have
that information.

On 13/03/17 00:01, Paul wrote:
> Restarting dnsmasq immediately stops an ongoing DNS storm.
> 
The actual upstream server used can change unpredictably, so that's no
surprise.

Cheers,

Simon.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1672099

Title:
  DNS loop, >5,000 queries per second for minutes at a time

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  Since upgrading a desktop to 17.04, several times a day a DNS storm
  occurs. The same A or  record is requested over and over again.
  The storm lasts 10 to 15 minutes and can clog name resolution
  entirely, making the computer unusable for that time.

  Mar 12 08:55:12 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:13 hostname systemd-resolved[1188]: message repeated 5401 times: 
[ Processing query...]
  Mar 12 08:55:13 hostname dnsmasq[1227]: Maximum number of concurrent DNS 
queries reached (max: 150)
  Mar 12 08:55:13 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:14 hostname kernel: [185434.365153] proc_thermal :00:04.0: 
Unsupported event [0x84]
  Mar 12 08:55:19 hostname systemd-resolved[1188]: message repeated 40288 
times: [ Processing query...]
  Mar 12 08:55:19 hostname dnsmasq[1227]: Maximum number of concurrent DNS 
queries reached (max: 150)
  Mar 12 08:55:19 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:25 hostname systemd-resolved[1188]: message repeated 44022 
times: [ Processing query...]
  Mar 12 08:55:25 hostname dnsmasq[1227]: Maximum number of concurrent DNS 
queries reached (max: 150)
  Mar 12 08:55:25 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:31 hostname systemd-resolved[1188]: message repeated 43874 
times: [ Processing query...]

  Both Firefox and Transmission originated hostnames have appeared in
  the storms, so it does not seem like an individual application is
  causing the problem.

  There are so many requests that running tcpdump on a random port (port
  29381 is used below) soon catches part of the storm. Example output
  below. Note that throughout the duration of these captures, identical
  DNS requests were being sent from pretty much every other port as
  well.

  

  = Transmission looking up mgtracker.org, got stuck on this single hostname 
for =
  = about 15 minutes (this is just the tail end of yesterday morning's storm).  
 = 
  


  08:40:24.667302 IP localhost.29381 > 127.0.0.53.domain: 60802+% [1au] ? 
mgtracker.org. (42)
  E..F..@.@..5r..5.2.y  mgtracker.org...)
  08:40:24.685708 IP 127.0.0.53.domain > localhost.29381: 60802 0/0/1 (42)
  E..Fdd@.@..5.5r..2.y  mgtracker.org...)
  08:40:33.580735 IP localhost.29381 > 127.0.0.53.domain: 53746+% [1au] A? 
mgtracker.org. (42)
  E..F.+@.@.9F...5r..5.2.y  mgtracker.org...)
  08:40:33.594830 IP 127.0.0.53.domain > localhost.29381: 53746 6/0/1 A 
92.241.171.245, A 37.19.5.139, A 77.91.229.218, A 5.79.83.194, A 5.79.83.193, A 
37.19.5.155 (138)
  E.@.@.t8...5.5r.  
mgtracker.org..X..\X..%X..M[...X...OS..X...OS..X..%.)
  08:41:30.717640 IP localhost.29381 > 127.0.0.53.domain: 63667+% [1au] ? 
mgtracker.org. (42)
  E..F\.@.@..5r..5.2.y  mgtracker.org...)
  08:41:30.733855 IP 127.0.0.53.domain > localhost.29381: 63667 0/0/1 (42)
  E..F .@.@..5.5r..2.y  mgtracker.org...)
  08:42:35.768840 IP localhost.29381 > 127.0.0.53.domain: 18342+% [1au] ? 
mgtracker.org. (42)
  E..FeH@.@..(...5r..5.2.yG...  mgtracker.org...)
  08:42:35.786098 IP 127.0.0.53.domain > localhost.29381: 18342 0/0/1 (42)
  E..F)N@.@..#...5.5r..2.yG...  mgtracker.org...)
  08:42:38.568885 IP localhost.29381 > 127.0.0.53.domain: 43765+% [1au] ? 
mgtracker.org. (42)
  E..F..@.@.s5r..5.2.y  mgtracker.org...)
  08:42:38.587299 IP 127.0.0.53.domain > localhost.29381: 43765 0/0/1 (42)
  E..F..@.@..5.5r..2.y  mgtracker.org...)
  08:42:41.348249 IP localhost.29381 > 127.0.0.53.domain: 39157+% [1au] A? 
mgtracker.org. (42)
  E..F)Z@.@..5r..5.2.y  mgtracker.org...)
  08:42:41.362068 IP 127.0.0.53.domain > localhost.29381: 39157 6/0/1 A 
92.241.171.245, A 37.19.5.139, A 77.91.229.218, A 5.79.83.194, A 5.79.83.193, A 

Re: [Touch-packages] [Bug 1672099] Re: DNS loop, >5, 000 queries per second for minutes at a time

[Simon Kelley]

Are we clear that this is a dnsmasq problem, and not a systemd-resolved
one? Can you add --log-queries to the dnsmasq configuration and see what
dnsmasq is doing? That should demonstrate if the loop is dnsmasq
forwarding to itself, of if the problem is something else.


Cheers,

Simon.



On 13/03/17 08:46, Paul wrote:
> There aren't any such entries in syslog, presumably because I had
> hardcoded two upstream servers (208.67.222.222 and 208.67.220.220) using
> the GUI Wi-Fi settings dialog in 16.10 and they're not changing. Oddly,
> I can't see that setting in the 17.04 dialog, even though "systemd-
> resolve --status" correctly reports them:
> 
> Global
>  DNS Servers: 127.0.0.1
>   DNSSEC NTA: 10.in-addr.arpa
>   16.172.in-addr.arpa
>   168.192.in-addr.arpa
>   17.172.in-addr.arpa
>   18.172.in-addr.arpa
>   19.172.in-addr.arpa
>   20.172.in-addr.arpa
>   21.172.in-addr.arpa
>   22.172.in-addr.arpa
>   23.172.in-addr.arpa
>   24.172.in-addr.arpa
>   25.172.in-addr.arpa
>   26.172.in-addr.arpa
>   27.172.in-addr.arpa
>   28.172.in-addr.arpa
>   29.172.in-addr.arpa
>   30.172.in-addr.arpa
>   31.172.in-addr.arpa
>   corp
>   d.f.ip6.arpa
>   home
>   internal
>   intranet
>   lan
>   local
>   private
>   test
> 
> Link 2 (wlp2s0)
>   Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
>LLMNR setting: yes
> MulticastDNS setting: no
>   DNSSEC setting: allow-downgrade
> DNSSEC supported: no
>  DNS Servers: 208.67.222.222
>   208.67.220.220
>   DNS Domain: local
> 
> The requests against the upstream server are disturbingly fast, I'm
> surprised I haven't been blacklisted yet.
> 
> 19:40:12.000415 IP hostname.50776 > resolver1.opendns.com.domain: 42051+% 
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C...X.5.=nB.C...4.1.168.192.in-addr.arpa...)
> 19:40:12.000920 IP hostname.59219 > resolver1.opendns.com.domain: 14223+% 
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C...S.5.=..74.1.168.192.in-addr.arpa...)
> 19:40:12.001411 IP hostname.51647 > resolver1.opendns.com.domain: 2501+% 
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C.5.=.Z  
> 4.1.168.192.in-addr.arpa...)
> 19:40:12.001885 IP hostname.33104 > resolver1.opendns.com.domain: 30929+% 
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C...P.5.=..x4.1.168.192.in-addr.arpa...)
> 19:40:12.002412 IP hostname.47231 > resolver1.opendns.com.domain: 46563+% 
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C.5.=j{.4.1.168.192.in-addr.arpa...)
> 19:40:12.004238 IP hostname.57292 > resolver1.opendns.com.domain: 61082+% 
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C.5.=
> w.4.1.168.192.in-addr.arpa...)
> 19:40:12.008187 IP hostname.49786 > resolver1.opendns.com.domain: 14681+% 
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C...z.5.=.
> 9Y...4.1.168.192.in-addr.arpa...)
> 19:40:12.008926 IP hostname.53171 > resolver1.opendns.com.domain: 24423+% 
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C.5.=.._g...4.1.168.192.in-addr.arpa...)
> 19:40:12.009629 IP hostname.37811 > resolver1.opendns.com.domain: 55231+% 
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C.5.=mk.4.1.168.192.in-addr.arpa...)
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1672099

Title:
  DNS loop, >5,000 queries per second for minutes at a time

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  Since upgrading a desktop to 17.04, several times a day a DNS storm
  occurs. The same A or  record is requested over and over again.
  The storm lasts 10 to 15 minutes and can clog name resolution
  entirely, making the computer unusable for that time.

  Mar 12 08:55:12 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:13 hostname systemd-resolved[1188]: message repeated 5401 times: 
[ Processing query...]
  Mar 12 08:55:13 hostname dnsmasq[1227]: Maximum number of concurrent DNS 
queries reached (max: 150)
  Mar 12 08:55:13 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:14 hostname kernel: [1

Re: [Touch-packages] [Bug 1672099] Re: DNS loop, >5, 000 queries per second for minutes at a time

[Simon Kelley]

Ok, so the amplification is arising from dnsmasq looping queries around
127.0.0.1 -> 127.0.0.53 -> 127.0.0.1 -> .

It would be really useful to get dnsmasq's idea of what it's upstreams
are. We know that 127.0.0.1 is in the list from your previous  post, and
I guess that dnsmasq has successfully worked out not to use that as it
loops back to itself. It's very likely that it didn't work out that
127.0.0.53 also loops back to itself too, but it's not clear how that's
getting into the list of upstreams.

This is starting to look like an Ubuntu/systemd plumbing problem, rather
than a dnsmasq bug.


Simon.


On 14/03/17 11:15, Paul wrote:
> I have cpulimit(1) watching dnsmasq now, so it only goes berserk for a
> second before being killed, but the attached syslog extract captures the
> moments before and during the DNS storm. These particular lookups are
> mostly originated by Transmission, but previously the storms have
> happened when there were no Transmission processes running, with queries
> from Firefox or perhaps some unidentified Gnome weather applet.
> 
> ** Attachment added: "syslog_dns_storm.txt"
>
> https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1672099/+attachment/4837521/+files/syslog_dns_storm.txt
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1672099

Title:
  DNS loop, >5,000 queries per second for minutes at a time

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  Since upgrading a desktop to 17.04, several times a day a DNS storm
  occurs. The same A or  record is requested over and over again.
  The storm lasts 10 to 15 minutes and can clog name resolution
  entirely, making the computer unusable for that time.

  Mar 12 08:55:12 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:13 hostname systemd-resolved[1188]: message repeated 5401 times: 
[ Processing query...]
  Mar 12 08:55:13 hostname dnsmasq[1227]: Maximum number of concurrent DNS 
queries reached (max: 150)
  Mar 12 08:55:13 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:14 hostname kernel: [185434.365153] proc_thermal :00:04.0: 
Unsupported event [0x84]
  Mar 12 08:55:19 hostname systemd-resolved[1188]: message repeated 40288 
times: [ Processing query...]
  Mar 12 08:55:19 hostname dnsmasq[1227]: Maximum number of concurrent DNS 
queries reached (max: 150)
  Mar 12 08:55:19 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:25 hostname systemd-resolved[1188]: message repeated 44022 
times: [ Processing query...]
  Mar 12 08:55:25 hostname dnsmasq[1227]: Maximum number of concurrent DNS 
queries reached (max: 150)
  Mar 12 08:55:25 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:31 hostname systemd-resolved[1188]: message repeated 43874 
times: [ Processing query...]

  Both Firefox and Transmission originated hostnames have appeared in
  the storms, so it does not seem like an individual application is
  causing the problem.

  There are so many requests that running tcpdump on a random port (port
  29381 is used below) soon catches part of the storm. Example output
  below. Note that throughout the duration of these captures, identical
  DNS requests were being sent from pretty much every other port as
  well.

  

  = Transmission looking up mgtracker.org, got stuck on this single hostname 
for =
  = about 15 minutes (this is just the tail end of yesterday morning's storm).  
 = 
  


  08:40:24.667302 IP localhost.29381 > 127.0.0.53.domain: 60802+% [1au] ? 
mgtracker.org. (42)
  E..F..@.@..5r..5.2.y  mgtracker.org...)
  08:40:24.685708 IP 127.0.0.53.domain > localhost.29381: 60802 0/0/1 (42)
  E..Fdd@.@..5.5r..2.y  mgtracker.org...)
  08:40:33.580735 IP localhost.29381 > 127.0.0.53.domain: 53746+% [1au] A? 
mgtracker.org. (42)
  E..F.+@.@.9F...5r..5.2.y  mgtracker.org...)
  08:40:33.594830 IP 127.0.0.53.domain > localhost.29381: 53746 6/0/1 A 
92.241.171.245, A 37.19.5.139, A 77.91.229.218, A 5.79.83.194, A 5.79.83.193, A 
37.19.5.155 (138)
  E.@.@.t8...5.5r.  
mgtracker.org..X..\X..%X..M[...X...OS..X...OS..X..%.)
  08:41:30.717640 IP localhost.29381 > 127.0.0.53.domain: 63667+% [1au] ? 
mgtracker.org. (42)
  E..F\.@.@..5r..5.2.y  mgtracker.org...)
  08:41:30.733855 IP 127.0.0.53.domain > localhost.29381: 63667 0/0/1 (42)
  E..F .@.@..5.5r..2.y  mgtracker.org...)
  08:42:35.768840 IP localhost.29381 > 127.0.0.53.domain: 18342+% [1au] ? 
mgtracker.

Re: [Touch-packages] [Bug 1672099] Re: DNS loop, >5, 000 queries per second for minutes at a time

[Simon Kelley]

Looking again. the loop probably involves systemd-resolverd too, dnsmasq
forwards to 127.0.0.53 which is systemd-resolverd, and systemd-resolverd
then returns it to dnsmasq at 127.0.0.1


Why, oh why is Ubuntu running both?


Cheers,

Simon.


On 14/03/17 11:15, Paul wrote:
> I have cpulimit(1) watching dnsmasq now, so it only goes berserk for a
> second before being killed, but the attached syslog extract captures the
> moments before and during the DNS storm. These particular lookups are
> mostly originated by Transmission, but previously the storms have
> happened when there were no Transmission processes running, with queries
> from Firefox or perhaps some unidentified Gnome weather applet.
> 
> ** Attachment added: "syslog_dns_storm.txt"
>
> https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1672099/+attachment/4837521/+files/syslog_dns_storm.txt
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1672099

Title:
  DNS loop, >5,000 queries per second for minutes at a time

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  Since upgrading a desktop to 17.04, several times a day a DNS storm
  occurs. The same A or  record is requested over and over again.
  The storm lasts 10 to 15 minutes and can clog name resolution
  entirely, making the computer unusable for that time.

  Mar 12 08:55:12 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:13 hostname systemd-resolved[1188]: message repeated 5401 times: 
[ Processing query...]
  Mar 12 08:55:13 hostname dnsmasq[1227]: Maximum number of concurrent DNS 
queries reached (max: 150)
  Mar 12 08:55:13 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:14 hostname kernel: [185434.365153] proc_thermal :00:04.0: 
Unsupported event [0x84]
  Mar 12 08:55:19 hostname systemd-resolved[1188]: message repeated 40288 
times: [ Processing query...]
  Mar 12 08:55:19 hostname dnsmasq[1227]: Maximum number of concurrent DNS 
queries reached (max: 150)
  Mar 12 08:55:19 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:25 hostname systemd-resolved[1188]: message repeated 44022 
times: [ Processing query...]
  Mar 12 08:55:25 hostname dnsmasq[1227]: Maximum number of concurrent DNS 
queries reached (max: 150)
  Mar 12 08:55:25 hostname systemd-resolved[1188]: Processing query...
  Mar 12 08:55:31 hostname systemd-resolved[1188]: message repeated 43874 
times: [ Processing query...]

  Both Firefox and Transmission originated hostnames have appeared in
  the storms, so it does not seem like an individual application is
  causing the problem.

  There are so many requests that running tcpdump on a random port (port
  29381 is used below) soon catches part of the storm. Example output
  below. Note that throughout the duration of these captures, identical
  DNS requests were being sent from pretty much every other port as
  well.

  

  = Transmission looking up mgtracker.org, got stuck on this single hostname 
for =
  = about 15 minutes (this is just the tail end of yesterday morning's storm).  
 = 
  


  08:40:24.667302 IP localhost.29381 > 127.0.0.53.domain: 60802+% [1au] ? 
mgtracker.org. (42)
  E..F..@.@..5r..5.2.y  mgtracker.org...)
  08:40:24.685708 IP 127.0.0.53.domain > localhost.29381: 60802 0/0/1 (42)
  E..Fdd@.@..5.5r..2.y  mgtracker.org...)
  08:40:33.580735 IP localhost.29381 > 127.0.0.53.domain: 53746+% [1au] A? 
mgtracker.org. (42)
  E..F.+@.@.9F...5r..5.2.y  mgtracker.org...)
  08:40:33.594830 IP 127.0.0.53.domain > localhost.29381: 53746 6/0/1 A 
92.241.171.245, A 37.19.5.139, A 77.91.229.218, A 5.79.83.194, A 5.79.83.193, A 
37.19.5.155 (138)
  E.@.@.t8...5.5r.  
mgtracker.org..X..\X..%X..M[...X...OS..X...OS..X..%.)
  08:41:30.717640 IP localhost.29381 > 127.0.0.53.domain: 63667+% [1au] ? 
mgtracker.org. (42)
  E..F\.@.@..5r..5.2.y  mgtracker.org...)
  08:41:30.733855 IP 127.0.0.53.domain > localhost.29381: 63667 0/0/1 (42)
  E..F .@.@..5.5r..2.y  mgtracker.org...)
  08:42:35.768840 IP localhost.29381 > 127.0.0.53.domain: 18342+% [1au] ? 
mgtracker.org. (42)
  E..FeH@.@..(...5r..5.2.yG...  mgtracker.org...)
  08:42:35.786098 IP 127.0.0.53.domain > localhost.29381: 18342 0/0/1 (42)
  E..F)N@.@..#...5.5r..2.yG...  mgtracker.org...)
  08:42:38.568885 IP localhost.29381 > 127.0.0.53.domain: 43765+% [1au] ? 
mgtracker.org. (42)
  E..F..@.@.s5r..5.2.y.

Re: [Touch-packages] [Bug 1702726] [NEW] dnsmasq fails when the ARP cache is full

[Simon Kelley]

Testing this, the results are not quite as clear-cut as the example. I
don't always see the same errors.

Also, I don't understand why the send() calls in dig, which are sending
UDP packets over the loopback interface, should return the invalid
argument. ARP is not needed over loopback, surely?


Looking at an strace of dnsmasq, what I see is that either the query
never arrives at dnsmasq, or it gets answered correctly but the answers
never makes it back to dig: the UDP packets are being dropped in the
kernel. (In the later case, the send() of the reply gets the same
invalid argument error that dig is seeing)

The lesson here is that if the arp-cache overflows, UDP, (even over lo)
drops packets. There's really not much dnsmasq can do about that. I
guess the only answer is "don't let your arp-cache overflow".

(or possibly, work on getting the kernel to behave better under these
circumstances)

TL;DR not a dnsmasq bug.

Cheers,

Simon.


On 06/07/17 18:17, Christopher Berner wrote:
> Public bug reported:
> 
> Test setup:
> OS: Ubuntu 16.04
> Hardware: D15_v2 VM on Azure
> 
> Steps to reproduce:
> 1) sudo apt-get install dnsmasq
> 2) sudo sysctl -w net.ipv4.neigh.default.gc_thresh1=1
> 3) sudo sysctl -w net.ipv4.neigh.default.gc_thresh2=1
> 4) sudo sysctl -w net.ipv4.neigh.default.gc_thresh3=1
> 5) dig @127.0.0.1 google.com
> 
> Result: 
> ~$ dig @127.0.0.1 google.com
> ../../../../lib/isc/unix/socket.c:2104: internal_send: 127.0.0.1#53: Invalid 
> argument
> ../../../../lib/isc/unix/socket.c:2104: internal_send: 127.0.0.1#53: Invalid 
> argument
> ../../../../lib/isc/unix/socket.c:2104: internal_send: 127.0.0.1#53: Invalid 
> argument
> 
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.1 google.com
> ; (1 server found)
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached 
> 
> However, an external DNS server still works fine (dig @8.8.8.8
> google.com, for example).
> 
> We discovered this as the default max ARP cache size is 1024, and we're
> running a large cluster with a lot of intra-cluster network traffic.
> Increasing the size of the ARP cache solves this problem, but it seems
> like dnsmasq should still work and just be slow, like other applications
> (curl for example just takes longer to connect)
> 
> ** Affects: dnsmasq (Ubuntu)
>  Importance: Undecided
>  Status: New
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1702726

Title:
  dnsmasq fails when the ARP cache is full

Status in dnsmasq package in Ubuntu:
  Confirmed

Bug description:
  Test setup:
  OS: Ubuntu 16.04
  Hardware: D15_v2 VM on Azure

  Steps to reproduce:
  1) sudo apt-get install dnsmasq
  2) sudo sysctl -w net.ipv4.neigh.default.gc_thresh1=1
  3) sudo sysctl -w net.ipv4.neigh.default.gc_thresh2=1
  4) sudo sysctl -w net.ipv4.neigh.default.gc_thresh3=1
  5) dig @127.0.0.1 google.com

  Result: 
  ~$ dig @127.0.0.1 google.com
  ../../../../lib/isc/unix/socket.c:2104: internal_send: 127.0.0.1#53: Invalid 
argument
  ../../../../lib/isc/unix/socket.c:2104: internal_send: 127.0.0.1#53: Invalid 
argument
  ../../../../lib/isc/unix/socket.c:2104: internal_send: 127.0.0.1#53: Invalid 
argument

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.1 google.com
  ; (1 server found)
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached 

  However, an external DNS server still works fine (dig @8.8.8.8
  google.com, for example).

  We discovered this as the default max ARP cache size is 1024, and
  we're running a large cluster with a lot of intra-cluster network
  traffic. Increasing the size of the ARP cache solves this problem, but
  it seems like dnsmasq should still work and just be slow, like other
  applications (curl for example just takes longer to connect)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1702726/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1862157] [NEW] dnsmasq does in all cases prepend "tftp_root" to tftp-bootfiles

[Simon Kelley]

tftp-root is a security feature. The tftp protocol is entirely
unauthenticated, and if a request was allowed to go outside the
specified root directory, than that effectively makes all readable files
on the host available for internet-wide access, which is not generally
desirable. If you want TFTP to be able to access any file on the
machine, don't set a tftp-root.


Simon.


On 06/02/2020 11:02, Thomas Schweikle wrote:
> Public bug reported:
> 
> dnsmasq does in all cases prepend "tftp_root" to tftp-files.
> 
> tftp-root=/data/tftp
> dhcp-boot=grub/i386-pc/core.0
> 
> now have some config files for different subnets:
> dhcp-boot=net:172-18-1,grub/i386-pc/core.0,172.18.1.1
> dhcp-boot=net:172-18-8,pxelinux.0,172.18.8.1
> dhcp-boot=net:172-18-7,/var/lib/tftpboot/pxelinux.0,spacewalk-ber.bfs.de
> 
> Now booting clients within subnet 172.18.1.0/24 will boot grub with:
> /data/tftp/grub/i386-pc/core.0
> 
> Booting clients within subnet 172.18.2.0/24 will boot pxelinux.0 with:
> /data/tftp/pxelinux.0
> 
> And in subnet 172.18.7.0/24 clients will boot with:
> /data/tftp/var/lib/tftpboot/pxelinux.0
> 
> and return a "File not found" error.
> 
> I'd expected:
> 172.18.1: grub/i386-pc/core.0   (file found within /data/tftp -- 
> without exposing path)
> 172.18.2: pxelinux.0(file found within /data/tftp -- 
> without exposing path)
> 172.18.3: /pxelinux.0   (file found within /)
> 172.18.7: /var/lib/tftpboot/pxelinux.0  (file found within 
> /var/lib/tftpboot/pxelinux.0)
> 
> or even better: some way to set tftp-root for every subnet-config and
> having only relative paths to access files regardless of giving absolute
> or relative paths.
> 
> ProblemType: Bug
> DistroRelease: Ubuntu 18.04
> Package: dnsmasq 2.79-1
> ProcVersionSignature: Ubuntu 4.15.0-87.87-generic 4.15.18
> Uname: Linux 4.15.0-87-generic x86_64
> ApportVersion: 2.20.9-0ubuntu7.10
> Architecture: amd64
> Date: Thu Feb  6 11:43:07 2020
> InstallationDate: Installed on 2014-01-31 (2197 days ago)
> InstallationMedia: Ubuntu-Server 13.10 "Saucy Salamander" - Release amd64 
> (20131016)
> PackageArchitecture: all
> ProcEnviron:
>  TERM=xterm
>  PATH=(custom, no user)
>  XDG_RUNTIME_DIR=
>  LANG=de_DE.UTF-8
>  SHELL=/bin/bash
> SourcePackage: dnsmasq
> UpgradeStatus: Upgraded to bionic on 2018-11-23 (439 days ago)
> mtime.conffile..etc.default.dnsmasq: 2014-02-19T17:19:28.429595
> mtime.conffile..etc.dnsmasq.conf: 2016-08-17T12:18:41.225353
> 
> ** Affects: dnsmasq (Ubuntu)
>  Importance: Undecided
>  Status: New
> 
> 
> ** Tags: amd64 apport-bug bionic
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1862157

Title:
  dnsmasq does in all cases prepend "tftp_root" to tftp-bootfiles

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  dnsmasq does in all cases prepend "tftp_root" to tftp-files.

  tftp-root=/data/tftp
  dhcp-boot=grub/i386-pc/core.0

  now have some config files for different subnets:
  dhcp-boot=net:172-18-1,grub/i386-pc/core.0,172.18.1.1
  dhcp-boot=net:172-18-8,pxelinux.0,172.18.8.1
  dhcp-boot=net:172-18-7,/var/lib/tftpboot/pxelinux.0,spacewalk-ber.bfs.de

  Now booting clients within subnet 172.18.1.0/24 will boot grub with:
  /data/tftp/grub/i386-pc/core.0

  Booting clients within subnet 172.18.2.0/24 will boot pxelinux.0 with:
  /data/tftp/pxelinux.0

  And in subnet 172.18.7.0/24 clients will boot with:
  /data/tftp/var/lib/tftpboot/pxelinux.0

  and return a "File not found" error.

  I'd expected:
  172.18.1: grub/i386-pc/core.0   (file found within /data/tftp -- 
without exposing path)
  172.18.2: pxelinux.0(file found within /data/tftp -- 
without exposing path)
  172.18.3: /pxelinux.0   (file found within /)
  172.18.7: /var/lib/tftpboot/pxelinux.0  (file found within 
/var/lib/tftpboot/pxelinux.0)

  or even better: some way to set tftp-root for every subnet-config and
  having only relative paths to access files regardless of giving
  absolute or relative paths.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-87.87-generic 4.15.18
  Uname: Linux 4.15.0-87-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.10
  Architecture: amd64
  Date: Thu Feb  6 11:43:07 2020
  InstallationDate: Installed on 2014-01-31 (2197 days ago)
  InstallationMedia: Ubuntu-Server 13.10 "Saucy Salamander" - Release amd64 
(20131016)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: Upgraded to bionic on 2018-11-23 (439 days ago)
  mtime.conffile..etc.default.dnsmasq: 2014-02-19T17:19:28.429595
  mtime.conffile..etc.dnsmasq.conf: 2016-08-17T12:18:41.225353

To manage notifications about this bug go to:
https://bugs.launchpad.

Re: [Touch-packages] [Bug 1416895] Re: /etc/dnsmasq.conf does not contain an ending newline character

[Simon Kelley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thomas, this is fixed upstream. I'll add (LP: #1416895) to the
changelog.


Cheers,

Simon.


On 01/02/15 21:04, Thomas Hood wrote:
> Confirmed that the bug affects 2.72-2.
> 
> $ cat /etc/dnsmasq.conf | tail -n 2 # Include all files in a
> directory which end in .conf #conf-dir=/etc/dnsmasq.d/*.conf$ od -t
> c /etc/dnsmasq.conf | tail -n 2 0062620   /   *   .   c   o   n
> f 0062627 $
> 
> 
> ** Changed in: dnsmasq (Ubuntu) Status: New => Confirmed
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUz+wdAAoJEBXN2mrhkTWi/gwP/1QL4kncy+NHv4u9XUu7C3Nf
ilfwOPmZquxXL6Xe2SyoLcM6O5cMPamfMRNvp6upVozZqvn3buBSflXn5I5lgl6j
J3/fmHwOl2uUg+GT7kM+6lca8SrFVaWuyOVLsCzlH1PVIuucrVoQmCGjMxo/3dy2
PB6fvMve21vGYYXs39rsmhoPFIOB+Xz10cbDeeyF4GIwFB15s3dPaL/9yy4y8x9O
TUNivrrUVBAKqTFjx9rWx8Xi/h98sy2WJ0dZWnWCJuA0Vy01lnzwMK6WRDaZ4FKy
XQ7anFgnLCD6I18PrFEb7g2kYzzwVGxqtvK53h8PNYh7swGxyr2eHxBHlkc6OC3E
eZa20aqhgVENVC/5PSmR/jpoR1CJta52aNhu3lJy+Ym1aIy/fdQVog4TZ44osyHG
VAOV4FEP0Ucw+tKAXzYlRDnCpMCsR/O8iycwgaJa2dhXPn156zY29MNxXdELMWo0
IUpBXG+KNm9NJty1HOZVoagUFI2pglXxnvYoh66sudBX3g27lXTIWTFjVoX5MyjY
duxBo6leRzY7OrK8A2j/73OrgudBU94kLQF7iig3vEYx3EYwl8yIzB6yEP5TNzYf
pX38rgBrSi3klsxg9ZVWXIIGz0demLCDO43rHnom6Uglq+zTFl6qePJ8XWwwPxMb
bETeMWMAG08HQJoMDoYW
=+g4T
-END PGP SIGNATURE-

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1416895

Title:
  /etc/dnsmasq.conf does not contain an ending newline character

Status in dnsmasq package in Ubuntu:
  Confirmed

Bug description:
  I'm using Ubuntu 15.04 dev with dnsmasq 2.72-2 and there is no ending
  newline character in /etc/dnsmasq.conf.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1416895/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 2098119] Re: dnsmasq does not open DHCP server ports

[Simon Kelley]

On 12/02/2025 17:16, jean-christophe manciot wrote:
> Now, if I add dhcp-range option, for instance:
> dhcp-range=192.168.0.50,192.168.0.150,12h
> 
> DHCP ports are open on **all** interfaces instead of just lo as specified 
> earlier:
> /usr/bin/netstat -tunpevaW | grep dnsmasq
> udp0  0 0.0.0.0:67  0.0.0.0:* 
>   0  74111502807884/dnsmasq
> udp0  0 127.0.0.1:690.0.0.0:* 
>   0  74111532807884/dnsmasq
> udp6   0  0 ::1:69  :::*  
>   0  74111542807884/dnsmasq
> 

That's as designed. To do DHCP successfully dnsmasq needs to get all 
packets. It will ignore packets arriving from interfaces it's not 
configured for.

(You're unlikely to be able to do DHCP on the loopback interface, and 
certainly not with that dhcp-range. The only time when a DHCP server can 
do something sensible with packets arriving on lo is when there's a DHCP 
relay in use on the same machine, and that's pretty esoteric.

Simon.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/2098119

Title:
  dnsmasq opens DHCP server ports on all interfaces instead of just on
  the interface(s) defined in interface= setting

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  ubuntu oracular
  linux 6.12.0-15-generic
  dnsmasq 2.90-4

  With the following specific configuration in /etc/dnsmasq.conf (due to 
interference with another DNS server):
  port=0

  The systemd service starts:
  # echo 'q' | sudo systemctl --no-pager --full status dnsmasq
  ● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled; 
preset: enabled)
   Active: active (running) since Wed 2025-02-12 17:31:55 CET; 1min 24s ago
   Invocation: 3aa94eb3e49c40e8b7cc53f316cc90eb
 Main PID: 1550822 (dnsmasq)
Tasks: 1 (limit: 36889)
   Memory: 844K (peak: 2.4M)
  CPU: 28ms
   CGroup: /system.slice/dnsmasq.service
   └─1550822 /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

  Feb 12 17:31:55 samsung9-ubuntux systemd[1]: Starting dnsmasq.service - 
dnsmasq - A lightweight DHCP and caching DNS server...
  Feb 12 17:31:55 samsung9-ubuntux dnsmasq[1550822]: started, version 2.90 DNS 
disabled
  Feb 12 17:31:55 samsung9-ubuntux dnsmasq[1550822]: compile time options: IPv6 
GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset 
nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
  Feb 12 17:31:55 samsung9-ubuntux systemd[1]: Started dnsmasq.service - 
dnsmasq - A lightweight DHCP and caching DNS server.

  but there is no DHCP server port open:
  # /usr/bin/netstat -tunpevaW | grep dnsmasq
  # /usr/bin/netstat -tunpevaW | grep :67
  #

  It does not change anything if I specify 'interface=eth0' or 
'listen-address=127.0.0.1' for instance.
  It does not change anything either if I specify a specific DNS port other 
than 53 with 'port=663' for instance: still no DHCP server port open by dnsmasq.

  Everything works fine with TFTP though with:
  listen-address=127.0.0.1
  bind-interfaces
  enable-tftp

  # /usr/bin/netstat -tunpevaW | grep dnsmasq
  udp0  0 127.0.0.1:690.0.0.0:* 
  0  57810842183724/dnsmasq

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2098119/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 2098119] [NEW] dnsmasq does not open DHCP server ports

[Simon Kelley]

It's not clear from this if there's at least one dhcp-range in 
/etc/dnsmasq.conf, but from the posted logs, it looks like there isn't. 
If so that's the problem. No dhcp-range -> no DHCP server -> no port 67 
socket.

Simon.

On 12/02/2025 16:57, jean-christophe manciot wrote:
> Public bug reported:
> 
> ubuntu oracular
> linux 6.12.0-15-generic
> dnsmasq 2.90-4
> 
> With the following specific configuration in /etc/dnsmasq.conf (due to 
> interference with another DNS server):
> port=0
> 
> The systemd service starts:
> # echo 'q' | sudo systemctl --no-pager --full status dnsmasq
> ● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
>   Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled; 
> preset: enabled)
>   Active: active (running) since Wed 2025-02-12 17:31:55 CET; 1min 24s ago
>   Invocation: 3aa94eb3e49c40e8b7cc53f316cc90eb
> Main PID: 1550822 (dnsmasq)
>Tasks: 1 (limit: 36889)
>   Memory: 844K (peak: 2.4M)
>  CPU: 28ms
>   CGroup: /system.slice/dnsmasq.service
>   └─1550822 /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
> 
> Feb 12 17:31:55 samsung9-ubuntux systemd[1]: Starting dnsmasq.service - 
> dnsmasq - A lightweight DHCP and caching DNS server...
> Feb 12 17:31:55 samsung9-ubuntux dnsmasq[1550822]: started, version 2.90 DNS 
> disabled
> Feb 12 17:31:55 samsung9-ubuntux dnsmasq[1550822]: compile time options: IPv6 
> GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset 
> nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
> Feb 12 17:31:55 samsung9-ubuntux systemd[1]: Started dnsmasq.service - 
> dnsmasq - A lightweight DHCP and caching DNS server.
> 
> but there is no DHCP server port open:
> # /usr/bin/netstat -tunpevaW | grep dnsmasq
> # /usr/bin/netstat -tunpevaW | grep :67
> #
> 
> It does not change anything if I specify 'interface=eth0' or 
> 'listen-address=127.0.0.1' for instance.
> It does not change anything either if I specify a specific DNS port other 
> than 53 with 'port=663' for instance: still no DHCP server port open by 
> dnsmasq.
> 
> Everything works fine with TFTP though with:
> listen-address=127.0.0.1
> bind-interfaces
> enable-tftp
> 
> # /usr/bin/netstat -tunpevaW | grep dnsmasq
> udp0  0 127.0.0.1:690.0.0.0:* 
>   0  57810842183724/dnsmasq
> 
> ** Affects: dnsmasq (Ubuntu)
>   Importance: Undecided
>   Status: New
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/2098119

Title:
  dnsmasq opens DHCP server ports on all interfaces instead of just on
  the interface(s) defined in interface= setting

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  ubuntu oracular
  linux 6.12.0-15-generic
  dnsmasq 2.90-4

  With the following specific configuration in /etc/dnsmasq.conf (due to 
interference with another DNS server):
  port=0

  The systemd service starts:
  # echo 'q' | sudo systemctl --no-pager --full status dnsmasq
  ● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled; 
preset: enabled)
   Active: active (running) since Wed 2025-02-12 17:31:55 CET; 1min 24s ago
   Invocation: 3aa94eb3e49c40e8b7cc53f316cc90eb
 Main PID: 1550822 (dnsmasq)
Tasks: 1 (limit: 36889)
   Memory: 844K (peak: 2.4M)
  CPU: 28ms
   CGroup: /system.slice/dnsmasq.service
   └─1550822 /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

  Feb 12 17:31:55 samsung9-ubuntux systemd[1]: Starting dnsmasq.service - 
dnsmasq - A lightweight DHCP and caching DNS server...
  Feb 12 17:31:55 samsung9-ubuntux dnsmasq[1550822]: started, version 2.90 DNS 
disabled
  Feb 12 17:31:55 samsung9-ubuntux dnsmasq[1550822]: compile time options: IPv6 
GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset 
nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
  Feb 12 17:31:55 samsung9-ubuntux systemd[1]: Started dnsmasq.service - 
dnsmasq - A lightweight DHCP and caching DNS server.

  but there is no DHCP server port open:
  # /usr/bin/netstat -tunpevaW | grep dnsmasq
  # /usr/bin/netstat -tunpevaW | grep :67
  #

  It does not change anything if I specify 'interface=eth0' or 
'listen-address=127.0.0.1' for instance.
  It does not change anything either if I specify a specific DNS port other 
than 53 with 'port=663' for instance: still no DHCP server port open by dnsmasq.

  Everything works fine with TFTP thou

Re: [Touch-packages] [Bug 2098119] Re: dnsmasq opens DHCP server ports on all interfaces instead of just on the interface(s) defined in interface= setting

[Simon Kelley]

On 17/02/2025 13:47, jean-christophe manciot wrote:
>> In order to allow multiple dnsmasq instances (for instance in the
>> libvirt case) dnsmasq sets REUSEPORT on DHCP sockets, and, if exactly
>> one interface is specified in the configuration, it sets SO_BINDTODEVICE.
> No, it does not work: if dnsmasq systemd service starts first, libvirtd 
> cannot start its own dnsmasq instance(s) and **no** VM can be assigned any IP 
> address.
> 
>> 1) The behaviour you are asking for doesn't work.
>> 2) This is not a regression: it has always been done this way.
> It used to work in all previous ubuntu releases and yes, it is a regression: 
> it is the first time I cannot use dnsmasq **and** libvirtd.
> 


Whatever change caused the regresssion, it's not binding the DHCP socket 
to INADDR_ANY, since dnsmasq has always done that.

So stop telling us that dnsmasq does that, and start giving useful 
information. What configuration is in use on the systemd-started 
dnsmasq? What configuration is available on the libvirt dnsmasq 
instance? What error messages are seen?

Don't assume that the problem is a dnsmasq change. What configuartion 
differences are there between a working system and a broken one?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/2098119

Title:
  dnsmasq opens DHCP server ports on all interfaces instead of just on
  the interface(s) defined in interface= setting

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  ubuntu oracular
  linux 6.12.0-15-generic
  dnsmasq 2.90-4

  With the following specific configuration in /etc/dnsmasq.conf (due to 
interference with another DNS server):
  port=0

  The systemd service starts:
  # echo 'q' | sudo systemctl --no-pager --full status dnsmasq
  ● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled; 
preset: enabled)
   Active: active (running) since Wed 2025-02-12 17:31:55 CET; 1min 24s ago
   Invocation: 3aa94eb3e49c40e8b7cc53f316cc90eb
 Main PID: 1550822 (dnsmasq)
Tasks: 1 (limit: 36889)
   Memory: 844K (peak: 2.4M)
  CPU: 28ms
   CGroup: /system.slice/dnsmasq.service
   └─1550822 /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

  Feb 12 17:31:55 samsung9-ubuntux systemd[1]: Starting dnsmasq.service - 
dnsmasq - A lightweight DHCP and caching DNS server...
  Feb 12 17:31:55 samsung9-ubuntux dnsmasq[1550822]: started, version 2.90 DNS 
disabled
  Feb 12 17:31:55 samsung9-ubuntux dnsmasq[1550822]: compile time options: IPv6 
GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset 
nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
  Feb 12 17:31:55 samsung9-ubuntux systemd[1]: Started dnsmasq.service - 
dnsmasq - A lightweight DHCP and caching DNS server.

  but there is no DHCP server port open:
  # /usr/bin/netstat -tunpevaW | grep dnsmasq
  # /usr/bin/netstat -tunpevaW | grep :67
  #

  It does not change anything if I specify 'interface=eth0' or 
'listen-address=127.0.0.1' for instance.
  It does not change anything either if I specify a specific DNS port other 
than 53 with 'port=663' for instance: still no DHCP server port open by dnsmasq.

  Everything works fine with TFTP though with:
  listen-address=127.0.0.1
  bind-interfaces
  enable-tftp

  # /usr/bin/netstat -tunpevaW | grep dnsmasq
  udp0  0 127.0.0.1:690.0.0.0:* 
  0  57810842183724/dnsmasq

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2098119/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 2098119] Re: dnsmasq opens DHCP server ports on all interfaces instead of just on the interface(s) defined in interface= setting

[Simon Kelley]

On 14/02/2025 13:38, jean-christophe manciot wrote:
> With the following setup:
> 
> port=0
> interface=eth0
> bind-interfaces
> dhcp-range=192.168.1.2,192.168.1.254
> 
> I get:
> # /usr/bin/netstat -tunpevaW | grep dnsmasq
> udp0  0 0.0.0.0:67  0.0.0.0:* 
>   0  19371604   3877093/dnsmasq
> 
> which contradicts your own documentation (please read until the end):
> # If you want dnsmasq to listen for DHCP and DNS requests only on
> # specified interfaces (and the loopback) give the name of the
> # interface (eg eth0) here.
> # Repeat the line for more than one interface.
> # interface=
> 
> # On systems which support it, dnsmasq binds the wildcard address,
> # even when it is listening on only some interfaces. It then discards
> # requests that it shouldn't reply to. This has the advantage of
> # working even when interfaces come and go and change address. If you
> # want dnsmasq to really bind only the interfaces it is listening on,
> # uncomment this option. About the only time you may need this is when
> # running another nameserver on the same machine.
> # bind-interfaces
> 
> So, bind-interfaces is not applied. Why is it a problem? In cases where
> there are multiple DHCP servers, this dnsmasq issue prevents the
> coexistence with these other servers as it binds to **all** ionterfaces
> and prevent other servers from listening on the interfaces they were
> setup for.
> 
> A perfect example is libvirtd: this issue prevents libvirtd from
> starting its one instance of dnsmasq over virbr0 (for instance). Cf.
> https://wiki.libvirt.org/Libvirtd_and_dnsmasq.html.
> 
> FYI, this failed behavior did not exist in Ubuntu noble.
> 

No release of dnsmasq ever made has bound the DHCP socket to anything 
other than the wildcard address. Whatever problem you are having, it's 
not what you think it is.

The DHCP socket has to be able to receive packets which are sent to 
255.255.255.255 and whose source address is 0.0.0.0 This is simply not 
reliable with a socket bound to the local address of the interface.

In order to allow multiple dnsmasq instances (for instance in the 
libvirt case) dnsmasq sets REUSEPORT on DHCP sockets, and, if exactly 
one interface is specified in the configuration, it sets SO_BINDTODEVICE.

Neither of these things is visible in netstat.

TLDR;

1) The behaviour you are asking for doesn't work.
2) This is not a regression: it has always been done this way.


Simon.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/2098119

Title:
  dnsmasq opens DHCP server ports on all interfaces instead of just on
  the interface(s) defined in interface= setting

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  ubuntu oracular
  linux 6.12.0-15-generic
  dnsmasq 2.90-4

  With the following specific configuration in /etc/dnsmasq.conf (due to 
interference with another DNS server):
  port=0

  The systemd service starts:
  # echo 'q' | sudo systemctl --no-pager --full status dnsmasq
  ● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled; 
preset: enabled)
   Active: active (running) since Wed 2025-02-12 17:31:55 CET; 1min 24s ago
   Invocation: 3aa94eb3e49c40e8b7cc53f316cc90eb
 Main PID: 1550822 (dnsmasq)
Tasks: 1 (limit: 36889)
   Memory: 844K (peak: 2.4M)
  CPU: 28ms
   CGroup: /system.slice/dnsmasq.service
   └─1550822 /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

  Feb 12 17:31:55 samsung9-ubuntux systemd[1]: Starting dnsmasq.service - 
dnsmasq - A lightweight DHCP and caching DNS server...
  Feb 12 17:31:55 samsung9-ubuntux dnsmasq[1550822]: started, version 2.90 DNS 
disabled
  Feb 12 17:31:55 samsung9-ubuntux dnsmasq[1550822]: compile time options: IPv6 
GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset 
nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
  Feb 12 17:31:55 samsung9-ubuntux systemd[1]: Started dnsmasq.service - 
dnsmasq - A lightweight DHCP and caching DNS server.

  but there is no DHCP server port open:
  # /usr/bin/netstat -tunpevaW | grep dnsmasq
  # /usr/bin/netstat -tunpevaW | grep :67
  #

  It does not change anything if I specify 'interface=eth0' or 
'listen-address=127.0.0.1' for instance.
  It does not change anything either if I specify a specific DNS port other 
than 53 with 'port=663' for instance: still no DHCP server port open by dnsmasq.

  Everything works fine with TFTP though with:
  listen-address=127.0.0.1
  bind-interfaces
  enable-tftp

  # /usr/bin/netstat -tunpevaW | grep dnsmasq
  udp0  0 127.0.0.1:690.0.0.0:*