Re: [Dnsmasq-discuss] Scripting with lua

2024-05-24 Thread White, Phil via Dnsmasq-discuss
On Wed, 15 May 2024 at 06:32, Geert Stappers  wrote:

> I've followed that URL and had to click deeper.
> Now sharing the output of
> $ curl --silent 
> https://raw.githubusercontent.com/whitepj/dnsmasq-lua/main/dhcp.lua

Thanks Geert.
Apologies -- it was my intention to keep the actual noise down to a
minimum. You can see from the script that the vast majority of it is
nothing more than comment.

The line that I am having the problem with is that which retrieves
that various variables.
I have tried:
a = (os.getenv("DNSMASQ_TIME_REMAINING") or "blank")
but this returns nothing at all. Since my knowledge of lua is far from
extensive, I'm hoping that someone may know what I'm doing wrong..

Many thanks.


> --[[
>
>LUA script for dnsmasq DHCP leases. Modified from original source at:
>http://lists.thekelleys.org/pipermail/dnsmasq-discuss/2012q1/005425.html
>This script is principally a boilerplate example, to show what is 
> possible...
>Tested using dnsmasq v2.90
>
>Run when:
>  - Startup (existing leases are invoked with 'old' event
>  - SIGHUP ?
>  - dhcp lease created, renewed, changed, or destroyed.
>  - tftp file transfer completes (not tested)
>
>ENVIRONMENT VARIABLES
>=
>  - DNSMASQ_DOMAIN
>  - DNSMASQ_SUPPLIED_HOSTNAME
>  - DNSMASQ_USER_CLASS0 ... _CLASSn
>  - DNSMASQ_LEASE_LENGTH / DNSMASQ_LEASE_EXPIRES
>  - DNSMASQ_TIME_REMAINING
>  - DNSMASQ_DATA_MISSING
>  - DNSMASQ_INTERFACE
>  - DNSMASQ_RELAY_ADDRESS
>  - DNSMASQ_TAGS
>  - DNSMASQ_REQUESTED_OPTIONS
>  - DNSMASQ_MUD_URL
>- IPv4 Only
>  - DNSMASQ_CLIENT_ID
>  - DNSMASQ_CIRCUIT_ID
>  - DNSMASQ_SUBSCRIBER_ID
>  - DNSMASQ_REMOTE_ID
>  - DNSMASQ_VENDOR_CLASS
>- IPv6 Only
>  - DNSMASQ_VENDOR_CLASS_ID
>  - DNSMASQ_VENDOR_CLASS0 ... _CLASSn
>  - DNSMASQ_SERVER_DUID
>  - DNSMASQ_IAID
>  - DNSMASQ_MAC
>--]]
>
> DBI = require "DBI" -- The ONLY external dependency. On gentoo, use 
> emerge dev-lua/luadbi (or use luarocks)
>
> -- Variable Declarations
> counter = 0
> file = nil  -- writing to a normal file
> dbh = nil   -- our database connection
> dbinsert = nil  -- preprepared call to write to a database
>
> local function myenv()  -- For testing. How do we retrieve the contents of 
> the environment variables?
> a = (os.getenv("DNSMASQ_TIME_REMAINING") or "blank")   -- 
> Help. Always blank.
> return a
> end
>
> local function myerrorhandler(err)
> print("ERROR: " .. err)
> end
>
> function init(a)
> a = (a or "--\n")
> -- MOST of this function will need to be deleted or commented out, 
> depending on what functionality is required.
> local ok, err, code = os.rename("/tmp/ilua.db","/tmp/ilua.db")
> if not ok then
> if code == 13 then
> print("DB File exists, but we can't open it! Please 
> fix (or delete).")
> os.exit()
> else
> print("No DB file found. Creating...")
> os.execute('sqlite3 --line /tmp/ilua.db "CREATE TABLE 
> table1(\"a\");"')
> end
> end
>
> print(a .. "Starting dnsmasq lua 
> script...\n==\n")
>
> file = assert(io.open("/tmp/test.log", "a+"))
> --  dbh = assert(DBI.Connect('PostgreSQL', 'db', 'user', 'password' ))
>   -- Alternative
> dbh = assert(DBI.Connect('SQLite3','/tmp/ilua.db'))
> dbh:autocommit(true)
> --  dbinsert = assert(dbh:prepare('INSERT INTO table1(a) values ($1)'))   
>   -- PostgreSQL
> end
>
> local function output(mystring)
> print(mystring) -- In production, I see little point 
> in this. Left for testing.
> file:write(mystring)-- We write our data to a standard 
> file...
> file:flush()
>
> DBI.Do(dbh, "INSERT INTO table1(a) VALUES ('" .. mystring .. "');")   
>   -- ... or a SQLite3 file ...
> -- dbinsert:execute(mystring)   -- ... or a database (if using 
> postgreSQL)
>
> -- See: http:jpmens.net/2013/10/21/tracking-dhcp-leases-with-dnsmasq/
> local cmd = 'mosquitto_pub -h 192.168.1.2 -t "' .. "topic" .. '" -m 
> "' .. "payload" .. '" -r'
> print(cmd .. "\n")

[Dnsmasq-discuss] [PATCH] Add support for --dhcp-allowed-srvids option.

2024-05-21 Thread Marek Skrobacki via Dnsmasq-discuss
If the DHCP server is running inside a container or behind a load
balancer, the DHCPREQUEST arriving at dnsmasq for processing may have a
Server ID (option 54) configured with an IP address that is not assigned
to the local interface. In this case, dnsmasq will check if the 'Server
Identifier Override' option was set in the incoming packet.

- If it was not set, the packet is dropped.
- If it was set, dnsmasq evaluates the Server ID against the value
  provided in 'Server ID Override' suboption 11, as outlined in RFC5107.

In both cases, there is no match against the 'backend' IP address
configured on the interface. This results in the DHCPNAK being returned
with the 'wrong server' message.

The --dhcp-allowed-srvids option allows turning off this security
mechanism for specific address(es). When enabled, the incoming
DHCPREQUEST is evaluated against the provided value(s) instead of the
addresses configured on the local interfaces.

Signed-off-by: Marek Skrobacki 
---
 man/dnsmasq.8 | 20 
 src/dnsmasq.h |  2 ++
 src/option.c  | 15 +++
 src/rfc2131.c | 46 ++
 4 files changed, 75 insertions(+), 8 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 32bdeff..d05ffc4 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -2026,6 +2026,26 @@ form is used, there must be a route to all of the 
addresses configured on the in
 The two-address form of shared-network is also usable with a DHCP relay: the 
first address
 is the address of the relay and the second, as before, specifies an extra 
subnet which
 addresses may be allocated from.
+.TP
+.B --dhcp-allowed-srvids[=]
+(IPv4 Only) If the DHCP server is running inside a container or behind a load 
balancer, the
+DHCPREQUEST arriving at dnsmasq for processing may have a Server ID (option 54)
+configured with an IP address that is not assigned to the local interface. In
+this case, dnsmasq will check if the 'Server Identifier Override' option was
+set in the incoming packet.
+.IP
+If it was not set, the packet is dropped.
+.IP
+If it was set, dnsmasq evaluates the Server ID against the value provided in 
\'Server ID Override\' suboption
+11, as outlined in RFC5107.
+.IP
+In both cases, there is no match against the \'backend\' IP address configured 
on the interface.
+This results in the DHCPNAK being returned with the \'wrong server\' message.
+.IP
+The \fB\-\-dhcp\-allowed\-srvids\fP option allows turning off this security
+mechanism for specific address(es). When enabled, the incoming DHCPREQUEST is
+evaluated against the provided value(s) instead of the addresses configured on
+the local interfaces.
 
 .TP
 .B \-s, --domain=[[,[,local]]|]
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index e455c3f..6f52e3e 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -1206,11 +1206,13 @@ extern struct daemon {
   struct pxe_service *pxe_services;
   struct tag_if *tag_if; 
   struct addr_list *override_relays;
+  struct addr_list *allowed_srvids;
   struct dhcp_relay *relay4, *relay6;
   struct delay_config *delay_conf;
   int override;
   int enable_pxe;
   int doing_ra, doing_dhcp6;
+  int allowing_custom_srvids;
   struct dhcp_netid_list *dhcp_ignore, *dhcp_ignore_names, *dhcp_gen_names; 
   struct dhcp_netid_list *force_broadcast, *bootp_dynamic;
   struct hostsfile *dhcp_hosts_file, *dhcp_opts_file;
diff --git a/src/option.c b/src/option.c
index f4ff7c0..eafcf54 100644
--- a/src/option.c
+++ b/src/option.c
@@ -192,6 +192,7 @@ struct myoption {
 #define LOPT_NO_DHCP4  383
 #define LOPT_MAX_PROCS 384
 #define LOPT_DNSSEC_LIMITS 385
+#define LOPT_DHCP_AL_SVID  386
 
 #ifdef HAVE_GETOPT_LONG
 static const struct option opts[] =  
@@ -388,6 +389,7 @@ static const struct myoption opts[] =
 { "use-stale-cache", 2, 0 , LOPT_STALE_CACHE },
 { "no-ident", 0, 0, LOPT_NO_IDENT },
 { "max-tcp-connections", 1, 0, LOPT_MAX_PROCS },
+{ "dhcp-allowed-srvids", 1, 0, LOPT_DHCP_AL_SVID },
 { NULL, 0, 0, 0 }
   };
 
@@ -591,6 +593,7 @@ static struct {
   { LOPT_NO_IDENT, OPT_NO_IDENT, NULL, gettext_noop("Do not add CHAOS TXT 
records."), NULL },
   { LOPT_CACHE_RR, ARG_DUP, "", gettext_noop("Cache this DNS resource 
record type."), NULL },
   { LOPT_MAX_PROCS, ARG_ONE, "", gettext_noop("Maximum number of 
concurrent tcp connections."), NULL },
+  { LOPT_DHCP_AL_SVID, ARG_DUP, "[=]...", gettext_noop("Allow these 
ServerIDs"), NULL },
   { 0, 0, NULL, NULL, NULL }
 }; 
 
@@ -4720,6 +4723,18 @@ static int one_opt(int option, char *arg, char *errstr, 
char *gen_err, int comma

break;
   }
+case LOPT_DHCP_AL_SVID:
+   daemon->allowing_custom_srvids = 1;
+   while (arg) {
+   struct addr_list *new = opt_malloc(sizeof(struct addr_list));
+   comma = split(arg);
+   if (!(inet_pton(AF_INET, arg, >addr) > 0))
+ ret_err_free

Re: [Dnsmasq-discuss] [PATCH] Update DNS records after pruning DHCP leases

2024-05-18 Thread Dominik Derigs via Dnsmasq-discuss

Dear list,

we have added this commit to the currently running Pi-hole v6.0 beta. It 
was confirmed by multiple users to fix aforementioned issues.


https://github.com/pi-hole/FTL/pull/1965

Have a great weekend!
Dominik

On 29.04.24 20:44, Erik Karlsson wrote:

From: Erik Karlsson 

Not doing so can result in a use after free since the name for DHCP
derived DNS records is represented as a pointer into the DHCP lease
table. Update will only happen when necessary since lease_update_dns
tests internally on dns_dirty and the force argument is zero.

Signed-off-by: Erik Karlsson 
---
  src/dnsmasq.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index a9f26ae..1be3b82 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -1518,6 +1518,7 @@ static void async_event(int pipe, time_t now)
  {
lease_prune(NULL, now);
lease_update_file(now);
+   lease_update_dns(0);
  }
  #ifdef HAVE_DHCP6
else if (daemon->doing_ra)


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


[Dnsmasq-discuss] [PATCH 0/1] Proposal for adding long option support (rfc3396)

2024-05-15 Thread Peter Kaestle via Dnsmasq-discuss
Hello,

I worked on a solution to add support for long options into dnsmasq and
want to share what I have come up with.  I tested it successfully with
busybox udhcpc.
Looking forward to get feedback on this proposal.

best regards,
--peter;

Peter Kaestle (1):
  dhcp protocol: adding long options support (rfc3396)

 src/dhcp-protocol.h |  5 -
 src/rfc2131.c   | 22 +-
 2 files changed, 21 insertions(+), 6 deletions(-)

-- 
2.45.0


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


[Dnsmasq-discuss] [PATCH 1/1] dhcp protocol: adding long options support (rfc3396)

2024-05-15 Thread Peter Kaestle via Dnsmasq-discuss
When the value length of an option exceeds 255 bytes, split it into a
second option with same option id, following rfc3396.

Signed-off-by: Peter Kaestle 
---
 src/dhcp-protocol.h |  5 -
 src/rfc2131.c   | 22 +-
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/src/dhcp-protocol.h b/src/dhcp-protocol.h
index 3dde354..faf1b2b 100644
--- a/src/dhcp-protocol.h
+++ b/src/dhcp-protocol.h
@@ -92,11 +92,14 @@
 
 #define DHCP_CHADDR_MAX 16
 
+#define MAX_OPTION_BUFF_SIZE 3000
+#define MAX_OPTION_SIZE 255
+
 struct dhcp_packet {
   u8 op, htype, hlen, hops;
   u32 xid;
   u16 secs, flags;
   struct in_addr ciaddr, yiaddr, siaddr, giaddr;
   u8 chaddr[DHCP_CHADDR_MAX], sname[64], file[128];
-  u8 options[312];
+  u8 options[MAX_OPTION_BUFF_SIZE];
 };
diff --git a/src/rfc2131.c b/src/rfc2131.c
index 68834ea..b428c40 100644
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -1979,13 +1979,25 @@ static void option_put_string(struct dhcp_packet *mess, 
unsigned char *end, int
  const char *string, int null_term)
 {
   unsigned char *p;
-  size_t len = strlen(string);
-
-  if (null_term && len != 255)
+ /* using signed int here to detect if length is shorter than MAX_OPTION_SIZE 
*/
+  int len = strlen(string);
+
+  /*
+   * if string is not terminated, add one byte for termination
+   *  - don't do that in case data fits exactly in 255 bytes of one option
+   */
+  if (null_term && len % MAX_OPTION_SIZE)
 len++;
 
-  if ((p = free_space(mess, end, opt, len)))
-memcpy(p, string, len);
+  /* if option data length is bigger than 255, split it like specified in 
rfc3396 */
+  for (; len > 0; len -= MAX_OPTION_SIZE, string += MAX_OPTION_SIZE) {
+size_t l = len >= MAX_OPTION_SIZE ? MAX_OPTION_SIZE : len;
+
+if ((p = free_space(mess, end, opt, l)))
+  memcpy(p, string, l);
+else
+  break;
+  }
 }
 
 /* return length, note this only does the data part */
-- 
2.45.0


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


[Dnsmasq-discuss] Scripting with lua

2024-05-14 Thread White, Phil via Dnsmasq-discuss
Hi All,

Feeling inquisitive about the options --dhcp-luascript, script-arp,
and script-on-renewal, I've been exploring what possibilities this
brings. Knowing absolutely nothing about lua, I have pulled together a
simple logging script that works -- but I've run up against a problem
in accessing the stored variables. Therefore, this is probably more of
a query about lua than it is about dnsmasq.

The man page states that the environment inherits a number of
variables (example: DNSMASQ_TAGS) which I am trying to retrieve -- but
my current approach is returning nil (eg. tags =
os.getenv("DNSMASQ_TAGS"))

Questions:
* How can I retrieve the contents of the DNSMASQ_ variables (if set)
* Does the dnsmasq log the return status if there is an error?
* and (tentatively / hypothetically), could the actions taken by
dnsmasq in granting/renewing a lease be modified following the results
of running the lua script? For example, if the lua script modified the
DNSMASQ_TAGS variable.

Note: This is NOT a feature request -- purely thinking about what
might be possible...

I've uploaded my current test script to:
https://github.com/whitepj/dnsmasq-lua if this makes anything clearer.

Many thanks,
Phil

_______
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-after-free with DHCP + use-stale-cache

2024-05-13 Thread Dominik Derigs via Dnsmasq-discuss

Hey Erik,

sorry for the late reply.. I wanted to err on the side of caution this 
time. We have been testing with your patch applied on top of latest 
master for almost four days now and - so far - no new use-after-free 
events occurred. Before, it happened at least once a day. Seems I have 
misinterpreted when SIGALRM is used so I thought your patch wouldn't be 
effective in our case. Sorry for this and thanks for challenging my 
earlier statement.


Best,
Dominik

On 06.05.24 11:39, Erik Karlsson wrote:

Hi Dominik,

Are you sure the patch I sent does not solve this? I think it should 
or are there more places where a lease_update_dns(0) is missing? 
Alternatively, can there be dangling pointers left even 
after lease_update_dns has been run?


Best regards,
Erik

Den mån 6 maj 2024 07:14Dominik Derigs via Dnsmasq-discuss 
 skrev:


Hey Simon,

we found a bug resulting in a use-after-free returning garbage
data and possibly crash when using DHCP + stale cache data.

The bug is triggered when using DHCP and a lease expires. It's
name is then free'd in kill_name() + do_script_run(). When the PTR
record is queried thereafter and use-stale-cache is enabled,
dnsmasq accesses this dangling pointer and returns random data -
often a string containing a few control characters, once dnsmasq
even SEGFAULTed.

Related dnsmasq.log:

|May 5 19:00:00 dnsmasq[4395]: query[PTR]
141.2.168.192.in-addr.arpa from 127.0.0.1 May 5 19:00:00
dnsmasq[4395]: DHCP 192.168.2.141 is  May 5
19:00:00 dnsmasq[4395]: forwarded 141.2.168.192.in-addr.arpa to
1.0.0.1|

The final immediate "forwarded" line comes from dnsmasq itself and
confirms that this was triggered by use-stale-cache.

Best,
Dominik

P.S.: The patch recently sent by Erik Karlsson doesn't fix this,
it touches other code.

___
    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] Use-after-free with DHCP + use-stale-cache

2024-05-05 Thread Dominik Derigs via Dnsmasq-discuss

Hey Simon,

we found a bug resulting in a use-after-free returning garbage data and 
possibly crash when using DHCP + stale cache data.


The bug is triggered when using DHCP and a lease expires. It's name is 
then free'd in kill_name() + do_script_run(). When the PTR record is 
queried thereafter and use-stale-cache is enabled, dnsmasq accesses this 
dangling pointer and returns random data - often a string containing a 
few control characters, once dnsmasq even SEGFAULTed.


Related dnsmasq.log:

|May 5 19:00:00 dnsmasq[4395]: query[PTR] 141.2.168.192.in-addr.arpa 
from 127.0.0.1 May 5 19:00:00 dnsmasq[4395]: DHCP 192.168.2.141 is 
 May 5 19:00:00 dnsmasq[4395]: forwarded 
141.2.168.192.in-addr.arpa to 1.0.0.1|


The final immediate "forwarded" line comes from dnsmasq itself and 
confirms that this was triggered by use-stale-cache.


Best,
Dominik

P.S.: The patch recently sent by Erik Karlsson doesn't fix this, it 
touches other code.
_______
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] confused about tag set (looking for !known control per vlan)

2024-04-24 Thread Brian Cook via Dnsmasq-discuss
assuming something wrong with my syntax.. as I'm getting unexpected results..

tl;dr:
(if a host on eth0.42 is unknown I would like to not offer them an IP)
(looking to have a !know option for some vlans but not all)

domain=dyn.dom.v42,10.120.48.0/24,local
dhcp-range=v42,10.120.48.100,10.120.48.200,255.255.255.0,4h
dhcp-option=v42,option:router,10.120.48.1
dhcp-option=v42,option:domain-name,dyn.dom.v42
dhcp-option=v42,option:dns-server,10.20.0.254

I have an eth0.42 vlan configured with an ip in the 10.120.48.0/24
range (assuming this is how it knows where to route the request..)

I have set:

bind-interfaces
interface=eth0.42
log-dhcp

with the above everything seems to work and I can see tags

a host on vlan42 asks for an ip and gets one in the range 48.100-48.200
(tags: v42, eth0.42)

replacing v42 with tag=v42 gives a 'no address available' error
message to all hosts on vlan42
(no tags)

even if I define them with dhcp-host

replacing v42 with set=v42 seems to make no difference, but it does
allow the host to get an ip
(tags: v42, eth0.42, known)

set=v42 also gets the known tag to show if the host is defined with dhcp-host

dhcp-ignore=set:v42,tag:!known

or

dhcp-ignore=tag:v42,tag:!known

does not seem to work like I would like to use it..

setting dhcp-ignore=tag:!known does work (globally across all vlans)
but the host has multiple vlans.. (v100, v200, v300, ex)

I would like v42, v100, v200 to respect !known but v300 to give ips to
unknown hosts..

I think I'm missing something simple..

Can someone offer some help?

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


[Dnsmasq-discuss] Unexpected caching behavior when using --address

2024-04-24 Thread Dom Sekotill via Dnsmasq-discuss
I'm seeing what looks like cached CNAME records overriding addresses set 
with --address.


Setup: using a version since 2.86 (I used 2.89) override A records for 
an upstream domain with --address but allow other queries for the domain 
to be forwarded upstream.


When querying A records for a name that the upstream returns CNAME for, 
the response is initially the expected overridden address. However, 
after requesting  records and getting a CNAME response, further 
queries for A records return the CNAME record.


As long as other record types are not wanted, this can be mitigated by 
restoring the previous behavior with --local, as per the manpage.


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


[Dnsmasq-discuss] dnsmasq

2024-04-15 Thread Turritopsis Dohrnii Teo En Ming via Dnsmasq-discuss
Subject: dnsmasq

Good day from Singapore,

I am wondering if dnsmasq can be installed and configured as a full-fledged 
authoritative DNS Server?

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore






___
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-range with ipv6 vlan not working?

2024-04-11 Thread Buck Horn via Dnsmasq-discuss

On 10.04.24 23:51, Robert Sharp wrote:

I have set up dnsmasq to provide dhcpv6 addresses for my network using
a /64 prefix delegated to the LAN interface (enp3s0) using dhcpcd.
Everything works fine, so I am now trying to extend ipv6 to a vlan I
have set up for my wifi clients. Again, dhcpcd has obtained and
delegated another prefix to the vlan only this time its a /68 for some
reason.



I can't comment on dnsmasq's implementation details, but in general, you
won't have much joy using a /68 prefix.

While it is true that IPv6 routing decisions are based on arbitrary
prefix lengths of 0 to 128, quite a few RFCs require the interface id to
be 64 bit wide - to name just a few: RFC3972 (CGAs), RFC4291 (Addressing
Architecture), RFC4193 (ULAs), RFC7136 (Significance of IPv6 Interface
Identifiers).

E.g. the latter states:
>    For all unicast addresses, except those that start with the binary
>    value 000, Interface IDs are required to be 64 bits long. If
>    derived from an IEEE MAC-layer address, they must be constructed
>    in Modified EUI-64 format.

Other RFCs often refer above and adhere to it, even if their proposed
algorithm could be adopted to deal with shorter interface ids (e.g.
RFC7217).

This pretty much makes 64bit interface ids a de-facto standard.
Using prefix lengths larger than 64 would thus be likely to result in
inability to calculate such 64bit interface identifiers.

Independent of your chosen DHCPv6 sever, you should probably consider to
use a different prefix length.

If you would want to be able to semantically use some portions of the
interface id to identify a logical subnet from your DHCPv6 assigned
addresses, you may be able to use a /64 and adjust dnsmasq's dhcp-range
accordingly. Depending on your router's configuration options, you may
still be able to use a /68 for routing decisions (like vlan isolation).

However, note that when advertising a /64 prefix, clients using
NDP/SLAAC to join your network (like Androids only ever do) would use
the full 64bit for self-assigning their interface id (but using a /68
may stop them from joining your network, when they only support SLAAC's
default /64 prefix).

Again, you may be better off avoiding issues by using a maximum prefix
length of 64.

Kind regards,
 Buck


___
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 & DDNS

2024-04-06 Thread Morgan Read via Dnsmasq-discuss

Thanks Petr & Geert for getting back to me.

I thought I'd followed up days ago - but, there's nothing in the archive...

Geert, I checked DDNS on Wikipedia and there are two meanings of DDNS, 
one automating the update of zone files on industrial scale DNS services 
(BIND I guess) and the other what I understood - updating transient IPs 
to a domain name.  But, neither of those seem relevant to dnsmasq, so I 
came to the conclusion the Fedora article was wrong.


Petr, thanks.  I now see that the article perhaps is not wrong because I 
guess the resolution services provided locally to the local network by 
DHCP might be thought of as DDNS.  But, as you say, that's not going to 
help dynamic resolution of the Internet FQDN to IP of the machine on 
which dnsmasq is running - which is what I meant by 'DDNS client'.


Many thanks
M

On 04/04/2024 11:22 am, Petr Menšík wrote:

Hi Morgan,

I am quite sure dnsmasq cannot be client to anything. Especially not 
dynamic dns client. I would recommend unbound for medium sized networks, 
dnsmasq is great for small networks. Depends.


dnsmasq can provide authoritative server parts as well as forwarder 
caching. You have not specified what means to you to be DDNS client, it 
might vary somehow. dnsmasq can provide changing machine names with 
changing IP addresses. If it does DHCP+DNS on your network, it works out 
of the box. If fact it is kind of difficult to supress it in unwanted. 
But that works great only with clients using DHCP to dnsmasq. Machine 
running dnsmasq itself has absolutely no support from dnsmasq, except 
local DNS cache. It should work if any external tool updates server 
address, dnsmasq should resolve it with help of upstream forwarder. 
Whether you use nsupdate or other tool to update your server address, it 
might work.


But you cannot use such address for cnames served by dnsmasq, because 
dnsmasq would need to fetch its target first. It does not know how to do 
that correctly.


I think DDNS was meant for DHCP clients only, not the server itself.

On 01. 04. 24 12:21, Morgan Read via Dnsmasq-discuss wrote:

Hi Folks,

I've been following this little how to:
https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/
Which says:
'Fedora Server Edition recommends the lightweight dnsmasq program to 
provide DHCP, DDNS and DNS caching service for a server and a small to 
medium-sized local network.'


Which has led me to believe I can configure dnsmasq as a DDNS 
client... However, I've found very little information about how to do 
that - nil. And, the dnsmasq manual mentions DDNS precisely once.  All 
of which, after well wasted morning, leads me to suspect that dnsmasq 
is not meant to be configured as a DDNS client...


My question: are my suspicions correct?

If I'm wrong and dnsmasq can be configured as a DDNS client and my 
google foo has been poo - can anyone give me a pointer to where I 
might find more information.


Thanks folks and have a good Easter Monday.

M

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




--
Morgan Read

Grande Bretagne


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Multicast Netlink Crash on gVisor Kernel

2024-04-05 Thread shamrock_sesame214--- via Dnsmasq-discuss
At this time the ip monitor command does not function in a gVisor container, 
although it is a WIP per gVisor. By nfset, I assume you mean the nftables 
equivalent of ipset. I don't believe this works either due to the architecture 
of namespaces that gVisor uses, with assumptions it should be used on the host 
OS.

My container will be run in a stub namespace without any L2 bridging, so it 
will not be receiving multicast anyway. I was thus hoping to see if it would be 
safe to compile out or perhaps open a bug report if the code may benefit from a 
restructure.

Thank you

On Tuesday, March 19th, 2024 at 5:09 AM, Nicolas Cavallari - nicolas.cavallari 
at green-communications.fr  wrote:

> 
> 
> On 16/03/2024 10:09, shamrock_sesame214--- via Dnsmasq-discuss wrote:
> 
> > Hello,
> > 
> > I am attempting to run dnsmasq DNS resolver in gVisor. gVisor is a hardened 
> > userspace kernel compatible with Kubernetes and Docker containers. At the 
> > moment, gVisor does not seem to support some routing features such as those 
> > found in linux/rtnetlink.h, including multicast related netlink 
> > subscriptions.
> > 
> > When I run dnsmasq in gVisor, I get this crash on startup:
> > 
> > cannot create netlink socket: Permission denied
> > 
> > Checking strace debugger, this was the attempted call made:
> > 
> > dnsmasq X bind(0x3 socket:[1], 0x7ee5d298ca58 {Family: AF_NETLINK, PortID: 
> > 0, Groups: 1360}, 0xc) = 0 (0x0) errno=13 (permission denied) (19.017µs)
> > 
> > The next call writes an error message to the terminal and begins exiting 
> > the program. I believe this to be caused by multicast route subscription 
> > near this line 73 in src/netlink.c: 
> > https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/netlink.c;h=ef4b5fec3197ec1a855fca3bcf8d86eaa29ca479;hb=HEAD#l73
> > 
> > I noticed the comment in the code:
> > 
> > /* May not be able to have permission to set multicast groups don't die in 
> > that case */
> > 
> > I am unsure if line 79 will trigger this error anyway, and if this is 
> > intended behavior, as the program seems to crash anyway.
> 
> 
> Line 79 basically retries the bind without subscribing to any
> route/ifaddr groups. There is no reason for it to fail. Actually, i
> think the second call is a no-op and it could just be omitted, the
> kernel will autobind on the first sendmsg(). I'm not the maintainer so i
> don't know why this call was added.
> 
> Anyway, as of 2024, both calls do not require any privileges (try "ip
> monitor" as a simple user, which requests even more rtnetlink groups).
> Not being able to use rtnetlink multicast groups is a severe limitation,
> this should really be fixed in gVisor.
> 
> Out of curiosity, does dnsmasq's nfset support works inside gVisor ?


___
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 confiure dnsmasq for IPv4 to IPv6 DNS proxy?

2024-04-05 Thread shamrock_sesame214--- via Dnsmasq-discuss
DNSMasq should automatically resolve names when it gets a DNS request for a 
device it registered over DHCP. Make sure to set the base name in your DHCP 
scopes. I believe it updates /etc/hosts too.


This can be combined with IPv6 DHCPv6, but not all devices use DHCPv6, such as 
Android. Android only does IPv6 SLAAC (never registers name). You can work 
around this with ra-names options, see below.

For devices disabling IPv4 and only use IPv6 SLAAC will never get a hostname 
registered. Devices that do this are rare but it is possible to configure.


ra-names:
ra-names enables a mode which gives DNS names to dual-stack hosts which do 
SLAAC for IPv6. Dnsmasq uses the host's IPv4 lease to derive the name, network 
segment and MAC address and assumes that the host will also have an IPv6 
address calculated using the SLAAC algorithm, on the same network segment. The 
address is pinged, and if a reply is received, an  record is added to the 
DNS for this IPv6 address. Note that this is only happens for 
directly-connected networks, (not one doing DHCP via a relay) and it will not 
work if a host is using privacy extensions. ra-names can be combined with 
ra-stateless and slaac.

See ra-names in manual
https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

On Friday, April 5th, 2024 at 3:22 AM, Hsin-Yao Huang - zeusshuang at gmail.com 
 wrote:

> A router with WAN site IPv6 only with IPv6 DNS server settings, and LAN site 
> supports both IPv4/IPv6.While the LAN site client only query DNS by IPv4 (A 
> record), how to configure dnsmasq to convert between A and  automatically?
> 
> Thanks,
> Eric


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


[Dnsmasq-discuss] dnsmasq & DDNS

2024-04-01 Thread Morgan Read via Dnsmasq-discuss

Hi Folks,

I've been following this little how to:
https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/
Which says:
'Fedora Server Edition recommends the lightweight dnsmasq program to 
provide DHCP, DDNS and DNS caching service for a server and a small to 
medium-sized local network.'


Which has led me to believe I can configure dnsmasq as a DDNS client... 
However, I've found very little information about how to do that - nil. 
And, the dnsmasq manual mentions DDNS precisely once.  All of which, 
after well wasted morning, leads me to suspect that dnsmasq is not meant 
to be configured as a DDNS client...


My question: are my suspicions correct?

If I'm wrong and dnsmasq can be configured as a DDNS client and my 
google foo has been poo - can anyone give me a pointer to where I might 
find more information.


Thanks folks and have a good Easter Monday.

M
--
Morgan Read

Grande Bretagne
Em: 


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Different behaviour with "interface=" on two almost identical systems

2024-03-28 Thread Buck Horn via Dnsmasq-discuss

On 28.03.24 14:28, Chris Green wrote:

... and another system, also running dnsmasq version 2.90:-

 chris@t470$ nmap 192.168.1.128 | grep 53
 53/tcpopen  domain
 chris@t470


So why are they acting differently and, possibly more to the point,
how do I make dnsmasq listen only on the loopback address?



Hi Chris,

you are just probing for port 53, without information about the process
handling that port, so it could be another resolver on the same machine
(e.g. systemd-resolved, or a dnsmasq instance controlled by
NetworkManager) that hogs port 53.


You may want to consider using something like sudo ss -tulpn sport = 53
to see what is actually listening.


For listening on 127.0.0.1 only, you probably should consider to
explicitly state that as listen-address:
(quoting https://dnsmasq.org/docs/dnsmasq-man.html)

-a, --listen-address=

Listen on the given IP address(es). Both --interface and
--listen-address options may be given, in which case the set of both
interfaces and addresses is used. Note that if no --interface option is
given, but --listen-address is, dnsmasq will not automatically listen on
the loopback interface. To achieve this, its IP address, 127.0.0.1, must
be explicitly given as a --listen-address option.


Kind regards,
   Buck


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


[Dnsmasq-discuss] Enquiry about default server

2024-03-26 Thread Elias LA via Dnsmasq-discuss
In my dnsmasq.conf file, I have a blanket block rule to block everything:

no-resolv
server=8.8.8.8

address=/#/0.0.0.0

Before this rule, I would like to allow exceptions, say for example gitlab.com. 
The problem I am having is that this rule:

server=/gitlab.com/#

Does not work, and I have to use instead:

server=/gitlab.com/8.8.8.8

So why is not the '#' translating into the default server 8.8.8.8?

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


Re: [Dnsmasq-discuss] dump dynamic dns assignments

2024-03-21 Thread Buck Horn via Dnsmasq-discuss

On 21.03.24 04:33, Tim Tassonis wrote:

What I wonder: Is there a way to find out what hostnames the dhcp
server has assigned to what ip addresses dynamically? I know that
dnsmasq registers them just fine, but is there a run-time access to
that information?



dnsmasq stores its currently active lease information in a file
(dnsmasq.leases), see

https://dnsmasq.org/docs/dnsmasq-man.html#lbAL


An explanation of the field format can be found from the mailing list, see

https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg00771.html


And of course, if you knew either an IP or a hostname of an active(!)
dynamic client, you could query dnsmasq for the other.

Kind regards,
 Buck


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


[Dnsmasq-discuss] RFC 2136 DNS Update?

2024-03-20 Thread Ronan Pigott via Dnsmasq-discuss
Hi dnsmasq,

So I searched around and found some very old discussions about supporting DNS
Update in dnsmasq. It seems like the feeling was that since dnsmasq already
gathered it's own information base from DHCP, it wasn't necessary to add DNS
Update support for clients because we already know their local address.

Today I am interested in DNS Update support for the benefit of IPv6 home lans,
especially IPv6 only lans, where we cannot derive the host address from DHCP
leases. With --enable-ra, in some cases we can guess the client address if it
chooses EUI-64 addresses, but RFC 7217 "stable privacy" addresses are
increasingly common, and once again it seems there is just no way to resolve
 records accurately on the lan. I think DNS Update could resolve this
problem.

Any thoughts on reconsidering support for this protocol in dnsmasq? Or other
solutions?

Cheers,

Ronan

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


Re: [Dnsmasq-discuss] shortcuts for REFUSED / RCODE

2024-03-20 Thread Dominik Derigs via Dnsmasq-discuss

Hey Ercolino,

In the context of adblocking I am told certain browsers/systems react 
much better when the DNS server returns FORBIDDEN (I guess they mean 
REFUSED which is return code 5 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) 
as this instructs the query generator (app) to stops hammering again 
for such domain.



Have you actually tried this?

A few years back, the Pi-hole team explored various possibilities for 
blocking requests. REFUSED was among them. However, in our testing, 
devices did not stop to request when they received REFUSED but continued 
hammering the server. This was especially true for embedded devices 
where any kind of DNS "error" may simply trigger endless repetitions. 
The best compromise we could come up with was in fact defining a "valid" 
response (A 0.0.0.0,  ::) for blocking.


Best,
Dominik




It seems like this behavior can be achieved in dnsmasq via the syntax

local=/example.com/127.0.0.1

Great. Since we run this on routers (Tomato) the dsnamsq configuration 
file size matters.


Bottom line: Could we have a shortcut char for REFUSED as well e.g.

local/example.com/%

As an alternative request... is it a good idea to re-thing the 
shortcut approach and simply allow the rfc's RCODE after the latest 
slash to return the correspondent RCODE name? e.g.


local/example.com/2 // ServFail
local/example.com/9 // notAuth
etc?

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] dnsmasq does not catches AAAA requests to domains in --address with only IPv4 records

2024-03-19 Thread Buck Horn via Dnsmasq-discuss

On 19.03.24 20:38, Grundik wrote:

But, if the record in --address is only specified as IPv4, then 
requests are still forwarded further, and I found no way to make
dnsmasq to return NXDOMAIN instead (as it should do in first place,
according to my understanding of documentation).



Quoting dnsmasq's manpage  at https://dnsmasq.org/docs/dnsmasq-man.html:

"Note that the behaviour for queries which don't match the specified
address literal changed in version 2.86. Previous versions, configured
with (eg) --address=/example.com/1.2.3.4 and then queried for a RR type
other than A would return a NoData answer. From 2.86, the query is sent
upstream. To restore the pre-2.86 behaviour, use the configuration
--address=/example.com/1.2.3.4 --local=/example.com/"


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


Re: [Dnsmasq-discuss] Question about behaviour of '#' symbol

2024-03-19 Thread Elias LA via Dnsmasq-discuss
Thanks again. I will rephrase my question one last time:

Considering that I have the rule `address=/*.firebaseio.com/`, how can I allow 
only the domain `firebaseio.com` without having to use the instruction 
`server=/firebaseio.com/8.8.8.8`? (How can I block all the subdomains except 
the main domain).

 Original Message 
On Mar 18, 2024, 4:06 PM, Matus UHLAR - fantomas wrote:

> On 18.03.24 14:21, Elias LA via Dnsmasq-discuss wrote: > Thanks. I see. So 
> the rule `server=/firebaseio.com/#` is sent to local > server 127.0.0.1 which 
> then blocks it because it has the rule > `address=/*.firebaseio.com/` I don't 
> think the request is sent anywhere, why would dnsmasq send it to itself? 
> Since you used no-resolv, I guess the request is handled locally according to 
> docs: Also permitted is a -S flag which gives a domain but no IP ad‐ dress; 
> this tells dnsmasq that a domain is local and it may an‐ swer queries from 
> /etc/hosts or DHCP but should never forward queries on that domain to any 
> upstream servers. --local is a synonym for --server to make configuration 
> files clearer in this case. perhaps guys can correct me. >A rephrase of my 
> question is: > > How can I route `firebaseio.com` to resolve using default 
> address (the > standard server defined by `server=8.8.8.8`) without having to 
> write > `server=/firebaseio.com/8.8.8.8` (with keeping the second following 
> rule > `address=/*.firebaseio.com/`). I have said it already: since you send 
> everything to 8.8.8.8 why do you need explicitly configure any domain to 
> query 8.8.8.8 ? Why did you specify that domain at all? Why did you set 
> server= and address= with firebaseio.com? >> > > On 18.03.24 09:41, Elias LA 
> via Dnsmasq-discuss wrote: >> > > >> > > > In mydnsmasq.conffile, I have 
> either one of two sets of rules: >> > > > >> > > > # Set 1: >> > > > >> > > > 
> no-resolv >> > > > server=8.8.8.8 >> > > > >> > > > server=/firebaseio.com/# 
> >> > > > address=/*.firebaseio.com/ >> > > > >> > > > # Set 2: >> > > > >> > 
> > > no-resolv >> > > > server=8.8.8.8 >> > > > >> > > > 
> server=/firebaseio.com/8.8.8.8 >> > > > address=/*.firebaseio.com/ >> > > > 
> >> > > > Running `dig firebaseio.com` using Set 1 gives local address, but 
> using >> > > > `Set 2` give a valid server IP address. Why does not the first 
> set give a >> > > > valid IP? Is not the rule 
> `server=/firebaseio.com/#`supposed to fetch the >> > > > IP address from the 
> "the standard servers" defined by `server=8.8.8.8`? -- 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. I intend to live forever - so far so 
> good. ___ 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] Multicast Netlink Crash on gVisor Kernel

2024-03-18 Thread shamrock_sesame214--- via Dnsmasq-discuss
Re-sending previous email with HTML formatting disabled, my apologies. 

Control and standard test cases for issue reproduction listed below:

A 'control' test case for the issue would be to launch dnsmasq in a typical 
Docker container. The program should launch normally and begin parsing the 
config, etc. The `docker run` statement should contain --privileged and 
--cap-add=NET_ADMIN for the sole purpose of testing. (Any non-dev reading this, 
please do not use --privileged in prod!).

A standard test case to reproduce this issue would be to launch the exact same 
Docker container, using the gVisor runtime. Then the crash is reproduced.

gVisor can be installed quickly using an apt repo & a modification of 
/etc/docker/daemon.json to permit use of the new runtime:
https://gvisor.dev/docs/user_guide/install/

gVisor can then be launched for any container using `docker run 
--runtime=runsc`, combined with any other necessary Docker args:

https://gvisor.dev/docs/user_guide/quick_start/docker/

Further information regarding this runtime:

Overview: https://gvisor.dev/docs/

Syscall compatibility docs: 
https://gvisor.dev/docs/user_guide/compatibility/linux/amd64/




On Saturday, March 16th, 2024 at 5:49 AM, Geert Stappers - stappers at 
stappers.nl  wrote:

> 
> 
> On Sat, Mar 16, 2024 at 09:09:16AM +, shamrock_sesame214--- via 
> Dnsmasq-discuss wrote:
> 
> > Hello,
> > 
> > I am attempting to run dnsmasq DNS resolver in gVisor. gVisor is
> > a hardened userspace kernel compatible with Kubernetes and Docker
> > containers. At the moment, gVisor does not seem to support some routing
> > features such as those found in linux/rtnetlink.h, including multicast
> > related netlink subscriptions.
> > 
> > When I run dnsmasq in gVisor, I get this crash on startup:
> > 
> > cannot create netlink socket: Permission denied
> > 
> > Checking strace debugger, this was the attempted call made:
> > 
> > dnsmasq X bind(0x3 socket:[1], 0x7ee5d298ca58 {Family: AF_NETLINK, PortID: 
> > 0, Groups: 1360}, 0xc) = 0 (0x0) errno=13 (permission denied) (19.017µs)
> > 
> > The next call writes an error message to the terminal and
> > begins exiting the program. I believe this to be caused by
> > multicast route subscription near this line 73 in src/netlink.c:
> > https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/netlink.c;h=ef4b5fec3197ec1a855fca3bcf8d86eaa29ca479;hb=HEAD#l73
> > 
> > I noticed the comment in the code:
> > 
> > /* May not be able to have permission to set multicast groups don't die in 
> > that case */
> > 
> > I am unsure if line 79 will trigger this error anyway, and if this is
> > intended behavior, as the program seems to crash anyway.
> > 
> > I also found in the source code that Netlink multicast subscription
> > is added to prevent routing race conditions when routes update, and
> > of course for DHCP/RA support. If Dnsmasq is running as a stub DNS
> > resolver inside a network namespace with one default gateway, is a
> > feature considerable to disable multicast Netlink subscriptions? In
> > this condition I do not anticipate routing updates to be frequent.
> > 
> > For additional debugging notes, the dnsmasq container functions outside
> > of gVisor. The Docker --user root, --privileged, and --cap-add=NET_ADMIN
> > did not resolve the issue, as it appears to be gVisor compatibility
> > limitation.
> 
> 
> Advice: Do a follow-up which aims for much more common interest. Like
> explaining how cool gVisor is and where to find more information about it.
> 
> 
> Groeten
> Geert Stappers
> --
> Silence is hard to parse
> 
> ___
> 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] Multicast Netlink Crash on gVisor Kernel

2024-03-18 Thread shamrock_sesame214--- via Dnsmasq-discuss
Control and standard test cases for issue reproduction listed below:

A 'control' test case for the issue would be to launch dnsmasq in a typical 
Docker container. The program should launch normally and begin parsing the 
config, etc. The `docker run` statement should contain --privileged and 
--cap-add=NET_ADMIN for the sole purpose of testing. (Any non-dev reading this, 
please do not use --privileged in prod!).

A standard test case to reproduce this issue would be to launch the exact same 
Docker container, using the gVisor runtime. Then the crash is reproduced.

gVisor can be installed quickly using an apt repo & a modification of 
/etc/docker/daemon.json to permit use of the new runtime:
[https://gvisor.dev/docs/](https://gvisor.dev/docs/user_guide/install/

gVisor can then be launched for any container using `docker run 
--runtime=runsc`, combined with any other necessary Docker args:

[https://gvisor.dev/docs/](https://gvisor.dev/docs/user_guide/quick_start/docker/

Further information regarding this runtime:

Overview: https://gvisor.dev/docs/

Syscall compatibility docs: 
https://gvisor.dev/docs/user_guide/compatibility/linux/amd64/

gVisor is owned by Google and used Google Cloud Platform's container related 
services, so looking into this issue may improve GCP compatibility, although I 
have not personally tested this against Google's online container services at 
this time.
 Original Message 
On Mar 16, 2024, 5:49 AM, Geert Stappers - stappers at stappers.nl wrote:

> On Sat, Mar 16, 2024 at 09:09:16AM +, shamrock_sesame214--- via 
> Dnsmasq-discuss wrote: > Hello, > > I am attempting to run dnsmasq DNS 
> resolver in gVisor. gVisor is > a hardened userspace kernel compatible with 
> Kubernetes and Docker > containers. At the moment, gVisor does not seem to 
> support some routing > features such as those found in linux/rtnetlink.h, 
> including multicast > related netlink subscriptions. > > When I run dnsmasq 
> in gVisor, I get this crash on startup: > > cannot create netlink socket: 
> Permission denied > > Checking strace debugger, this was the attempted call 
> made: > > dnsmasq X bind(0x3 socket:[1], 0x7ee5d298ca58 {Family: AF_NETLINK, 
> PortID: 0, Groups: 1360}, 0xc) = 0 (0x0) errno=13 (permission denied) 
> (19.017µs) > > The next call writes an error message to the terminal and > 
> begins exiting the program. I believe this to be caused by > multicast route 
> subscription near this line 73 in src/netlink.c: > 
> https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/netlink.c;h=ef4b5fec3197ec1a855fca3bcf8d86eaa29ca479;hb=HEAD#l73
>  > > I noticed the comment in the code: > > /* May not be able to have 
> permission to set multicast groups don't die in that case */ > > I am unsure 
> if line 79 will trigger this error anyway, and if this is > intended 
> behavior, as the program seems to crash anyway. > > I also found in the 
> source code that Netlink multicast subscription > is added to prevent routing 
> race conditions when routes update, and > of course for DHCP/RA support. If 
> Dnsmasq is running as a stub DNS > resolver inside a network namespace with 
> one default gateway, is a > feature considerable to disable multicast Netlink 
> subscriptions? In > this condition I do not anticipate routing updates to be 
> frequent. > > For additional debugging notes, the dnsmasq container functions 
> outside > of gVisor. The Docker --user root, --privileged, and 
> --cap-add=NET_ADMIN > did not resolve the issue, as it appears to be gVisor 
> compatibility > limitation. Advice: Do a follow-up which aims for much more 
> common interest. Like explaining how cool gVisor is and where to find more 
> information about it. Groeten Geert Stappers -- Silence is hard to parse 
> ___ 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 potential memory leak

2024-03-18 Thread Dan Schaper via Dnsmasq-discuss

-- Original Message --

From "Brian Haley" 
To "Geert Stappers" ; 
dnsmasq-discuss@lists.thekelleys.org.uk

Date 3/18/2024 6:59:21 AM
Subject Re: [Dnsmasq-discuss] [PATCH] Fix potential memory leak




As an attempt to express that proposed patches get human attention.

I'm not sure what that means...


It means Geert doesn't think Simon is running `dnsmasq` to his (Geert's) 
liking so Geert is doing yet another passive aggressive attack on the 
list. You'll notice how Geert likes to change the email address he sends 
from with what he thinks are witty and creative names, like his monthly 
rules to post reminders.


Would be nice to just blanket ban anything from @stappers.nl but until 
then it's easier to just set a rule to send anything from that address 
to spam.


Geert has no authority to do anything in the `dnsmasq` project and this 
latest game with him setting up a patch repository is just a game. Simon 
is the sole gateway to getting any code in, much to Geert's dismay.


Best,
Dan

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


Re: [Dnsmasq-discuss] Question about behaviour of '#' symbol

2024-03-18 Thread Elias LA via Dnsmasq-discuss
Thanks. I see. So the rule `server=/firebaseio.com/#` is sent to local server 
127.0.0.1 which then blocks it because it has the rule 
`address=/*.firebaseio.com/`

A rephrase of my question is:

How can I route `firebaseio.com` to resolve using default address (the standard 
server defined by `server=8.8.8.8`) without having to write 
`server=/firebaseio.com/8.8.8.8` (with keeping the second following rule 
`address=/*.firebaseio.com/`).

Apologies for the multiple enquiries and thanks very much.

Elias.




Sent with Proton Mail secure email.

On Monday, 18 March 2024 at 13:11, Matus UHLAR - fantomas  
wrote:

> On 18.03.24 12:29, Elias LA via Dnsmasq-discuss wrote:
>
> > Yes, I am aware about the documentation which you quoted (and which I 
> > quoted). But how do you explain that the domain `firebaseio.com` is being 
> > blocked by set 1 and NOT by set 2?
> >
> > As you mentioned, we should expect `server=/firebaseio.com/#` to lookup the 
> > domain from `8.8.8.8`.
>
>
> 1. since you already have "server=8.8.8.8", why do you explicitly set
> "server=/firebaseio.com/8.8.8.8" ?
>
> - What is the point of resolving specific domain through a server, when you
> already resolve everything through the same server?
>
> > But it is not happening, and the domain is being blocked!
>
>
> 2. You have not said anything about it being blocked, you said it's
> resolving to local address. That is different issue.
>
> And that is issue what server=/domain/# supposed to do -
>
> 3. you already set .firebaseio.com not to resolve:
> address=/.firebaseio.com/
>
>
> So why exactly you are complaining it's not resolving when you set it not to
> resolve?
>
> > On Monday, 18 March 2024 at 11:12, Matus UHLAR - fantomas uh...@fantomas.sk 
> > wrote:
> >
> > > On 18.03.24 09:41, Elias LA via Dnsmasq-discuss wrote:
> > >
> > > > In mydnsmasq.conffile, I have either one of two sets of rules:
> > > >
> > > > # Set 1:
> > > >
> > > > no-resolv
> > > > server=8.8.8.8
> > > >
> > > > server=/firebaseio.com/#
> > > > address=/*.firebaseio.com/
> > > >
> > > > # Set 2:
> > > >
> > > > no-resolv
> > > > server=8.8.8.8
> > > >
> > > > server=/firebaseio.com/8.8.8.8
> > > > address=/*.firebaseio.com/
> > > >
> > > > Running `dig firebaseio.com` using Set 1 gives local address, but using
> > > > `Set 2` give a valid server IP address. Why does not the first set give 
> > > > a
> > > > valid IP? Is not the rule `server=/firebaseio.com/#`supposed to fetch 
> > > > the
> > > > IP address from the "the standard servers" defined by `server=8.8.8.8`?
> > >
> > > the dnsmasq documentation says in the "-S --local --server=" docs:
> > >
> > > The special server address '#' means, "use the standard servers", so
> > > --server=/google.com/1.2.3.4 --server=/www.google.com/# will send queries
> > > for google.com and its subdomains to 1.2.3.4, except www.google.com (and
> > > its subdo‐ mains) which will be forwarded as usual.
> > >
> > > which usually means, use servers mentioned in /etc/resolv.conf for that
> > > domain.
> > >
> > > note that when you already have:
> > >
> > > server=8.8.8.8
> > >
> > > it's useless to specify any domains to the same server
> > >
> > > > server=/firebaseio.com/8.8.8.8
>
>
> --
> 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.
> "The box said 'Requires Windows 95 or better', so I bought a Macintosh".
>
> ___
> 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] Question about behaviour of '#' symbol

2024-03-18 Thread Elias LA via Dnsmasq-discuss
Thanks Matus.

Yes, I am aware about the documentation which you quoted (and which I quoted). 
But how do you explain that the domain `firebaseio.com` is being blocked by set 
1 and NOT by set 2?

As you mentioned, we should expect `server=/firebaseio.com/#` to lookup the 
domain from `8.8.8.8`. But it is not happening, and the domain is being blocked!


Sent with Proton Mail secure email.

On Monday, 18 March 2024 at 11:12, Matus UHLAR - fantomas  
wrote:

> On 18.03.24 09:41, Elias LA via Dnsmasq-discuss wrote:
> 
> > In mydnsmasq.conffile, I have either one of two sets of rules:
> > 
> > # Set 1:
> > 
> > no-resolv
> > server=8.8.8.8
> > 
> > server=/firebaseio.com/#
> > address=/*.firebaseio.com/
> > 
> > # Set 2:
> > 
> > no-resolv
> > server=8.8.8.8
> > 
> > server=/firebaseio.com/8.8.8.8
> > address=/*.firebaseio.com/
> > 
> > Running `dig firebaseio.com` using Set 1 gives local address, but using
> > `Set 2` give a valid server IP address. Why does not the first set give a
> > valid IP? Is not the rule `server=/firebaseio.com/#`supposed to fetch the
> > IP address from the "the standard servers" defined by `server=8.8.8.8`?
> 
> 
> the dnsmasq documentation says in the "-S --local --server=" docs:
> 
> The special server address '#' means, "use the standard servers", so
> --server=/google.com/1.2.3.4 --server=/www.google.com/# will send queries
> for google.com and its subdomains to 1.2.3.4, except www.google.com (and
> its subdo‐ mains) which will be forwarded as usual.
> 
> which usually means, use servers mentioned in /etc/resolv.conf for that
> domain.
> 
> note that when you already have:
> 
> server=8.8.8.8
> 
> it's useless to specify any domains to the same server
> 
> > server=/firebaseio.com/8.8.8.8
> 
> 
> you can skip this line.
> 
> --
> 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.
> On the other hand, you have different fingers.
> 
> _______
> 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] Question about behaviour of '#' symbol

2024-03-18 Thread Elias LA via Dnsmasq-discuss
Dear Dnsmasq team,

I have a question which I hope someone can kindly clarify:

In mydnsmasq.conffile, I have either one of two sets of rules:

# Set 1:

no-resolv
server=8.8.8.8

server=/firebaseio.com/#
address=/*.firebaseio.com/

# Set 2:

no-resolv
server=8.8.8.8

server=/firebaseio.com/8.8.8.8
address=/*.firebaseio.com/

Running `dig firebaseio.com`usingSet 1gives local address, but using `Set 
2`give a valid server IP address. Why does not the first set give a valid IP? 
Is not the rule `server=/firebaseio.com/#`supposed to fetch the IP address from 
the "the standard servers" defined by `server=8.8.8.8`?

Thank you very much.

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


[Dnsmasq-discuss] Multicast Netlink Crash on gVisor Kernel

2024-03-16 Thread shamrock_sesame214--- via Dnsmasq-discuss
Hello, 

I am attempting to run dnsmasq DNS resolver in gVisor. gVisor is a hardened 
userspace kernel compatible with Kubernetes and Docker containers. At the 
moment, gVisor does not seem to support some routing features such as those 
found in linux/rtnetlink.h, including multicast related netlink subscriptions.

 When I run dnsmasq in gVisor, I get this crash on startup:

     cannot create netlink socket: Permission denied 

Checking strace debugger, this was the attempted call made:

 dnsmasq X bind(0x3 socket:[1], 0x7ee5d298ca58 {Family: AF_NETLINK, PortID: 
0, Groups: 1360}, 0xc) = 0 (0x0) errno=13 (permission denied) (19.017µs)

The next call writes an error message to the terminal and begins exiting the 
program. I believe this to be caused by multicast route subscription near this 
line 73 in src/netlink.c: 
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/netlink.c;h=ef4b5fec3197ec1a855fca3bcf8d86eaa29ca479;hb=HEAD#l73

I noticed the comment in the code: 

 /* May not be able to have permission to set multicast groups don't die in 
that case */ 

I am unsure if line 79 will trigger this error anyway, and if this is intended 
behavior, as the program seems to crash anyway.

 I also found in the source code that Netlink multicast subscription is added 
to prevent routing race conditions when routes update, and of course for 
DHCP/RA support. If Dnsmasq is running as a stub DNS resolver inside a network 
namespace with one default gateway, is a feature considerable to disable 
multicast Netlink subscriptions? In this condition I do not anticipate routing 
updates to be frequent. 

For additional debugging notes, the dnsmasq container functions outside of 
gVisor. The Docker --user root, --privileged, and --cap-add=NET_ADMIN did not 
resolve the issue, as it appears to be gVisor compatibility limitation. 

Thank you for your time


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


Re: [Dnsmasq-discuss] config error is REFUSED (EDE: not ready) for dnsmasq version

2024-03-11 Thread Purushotham P via Dnsmasq-discuss
Can someone help me from this blocker?







Thanks & Regards,
Purushotham P

From: Purushotham P 
Date: Friday, 23 February 2024 at 11:37 AM
To: dnsmasq-discuss@lists.thekelleys.org.uk 

Cc: Saumya Singh 
Subject: config error is REFUSED (EDE: not ready) for dnsmasq version
Hi Team,

When we upgrade dnsmasq to 2.89 on our docker container has stopped responding 
and showing error message as config error is REFUSED (EDE: not ready). But if 
we try using dnsmasq version 2.85 our docker container is responding and 
working good. We are supposed to use 2.89-r3 version to avoid vulnerabilities.

Can someone please help us resolve this blocking issue?


2.85 Configuration is as below:
dnsmasq -k -q \
--log-facility=- \
--cache-size=0 \
--no-hosts \
--no-resolv \
   --log-debug \
--log-queries \
--server=/#/my_IPaddress1 \
--server=/#/ my_IPaddress2


2.89 configuration is as below:

dnsmasq -k -q \
--log-facility=- \
--cache-size=0 \
--no-hosts \
--no-resolv \
   --log-debug \
--log-queries \
--server= my_IPaddress1 \
--server= my_IPaddress2

 (or)

dnsmasq -k -q \
--log-facility=- \
--cache-size=0 \
--no-hosts \
--no-resolv \
   --log-debug \
--log-queries \
--server=/#/my_IPaddress1 \
--server=/#/ my_IPaddress2


For 2.89 we tried with and without /#/ both times we are getting config error 
is REFUSED (EDE: not ready) error.




Thanks & Regards,
Purushotham P
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Test

2024-03-03 Thread Knud via Dnsmasq-discuss

sorry test again

Have difficulties to get dnsmasq list mails throught spamfilter

On 29.02.2024 13.30, Knud via Dnsmasq-discuss wrote:

Only test mail

As I having problems to receive mails from the list

Knud

___
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 Not Working on Linux 6.6.13

2024-03-02 Thread Buck Horn via Dnsmasq-discuss

On 28.02.24 11:29, Robert Sharp wrote:

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.


It's quite possible you would not need DHCPv6 at all.

The DNS protocol is oblivious to the way it gets transported:
A DNS server will answer an IPv4 (A) or IPv6 () hostname record as
requested, regardless whether a client connects via IPv4 or IPv6.

And the majority of IPv6 clients won't request an IPv6 address via
DHCPv6, but rather use SLAAC to construct their IPv6s themselves, only
using the IPv6 prefix as learned from your router. The favoured method
of a client would depend on a client's OS. Linux and MacOS could do
DHCPv6 or SLAAC early on, Windows first favoured DHCPv6, but supported
SLAAC since Win 10 or 8.1, and Android does and only ever did SLAAC
exclusively.

Are you running your dnsmasq on a router or a dedicated server?

As it's the router's job to advertise IPv6 configuration information
(like prefix or DNS servers), you probably only have to deal with
dnsmasq's IPv6 configuration if its running on a router.

Kind regards,

    Buck


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


[Dnsmasq-discuss] Test

2024-02-29 Thread Knud via Dnsmasq-discuss

Only test mail

As I having problems to receive mails from the list

Knud

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


[Dnsmasq-discuss] config error is REFUSED (EDE: not ready) for dnsmasq version

2024-02-22 Thread Purushotham P via Dnsmasq-discuss
Hi Team,

When we upgrade dnsmasq to 2.89 on our docker container has stopped responding 
and showing error message as config error is REFUSED (EDE: not ready). But if 
we try using dnsmasq version 2.85 our docker container is responding and 
working good. We are supposed to use 2.89-r3 version to avoid vulnerabilities.

Can someone please help us resolve this blocking issue?


2.85 Configuration is as below:
dnsmasq -k -q \
--log-facility=- \
--cache-size=0 \
--no-hosts \
--no-resolv \
   --log-debug \
--log-queries \
--server=/#/my_IPaddress1 \
--server=/#/ my_IPaddress2


2.89 configuration is as below:

dnsmasq -k -q \
--log-facility=- \
--cache-size=0 \
--no-hosts \
--no-resolv \
   --log-debug \
--log-queries \
--server= my_IPaddress1 \
--server= my_IPaddress2

 (or)

dnsmasq -k -q \
--log-facility=- \
--cache-size=0 \
--no-hosts \
--no-resolv \
   --log-debug \
--log-queries \
--server=/#/my_IPaddress1 \
--server=/#/ my_IPaddress2


For 2.89 we tried with and without /#/ both times we are getting config error 
is REFUSED (EDE: not ready) error.




Thanks & Regards,
Purushotham P
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


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

2024-02-20 Thread Clayton Craft via Dnsmasq-discuss
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.




#!/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] Similar to bfefd6e38c6e, fix error introduced in 51471cafa5a4

2024-02-20 Thread renmingshuai via Dnsmasq-discuss
>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


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

2024-02-19 Thread Matthias Lay via Dnsmasq-discuss
Am Sat, 17 Feb 2024 22:36:04 +
schrieb 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?

filtering for "known" in dhcp-range does exactly what i was trying to
achieve. I was trying to hard to use the ignore option ;)

thx for your help


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


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

2024-02-16 Thread Matthias Lay via Dnsmasq-discuss


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?

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] Both IPv6 router + separate dnsmasq server do router advertisements - results in two IPv6 routes for clients

2024-02-11 Thread Klaus Wissmann via Dnsmasq-discuss
Hi all,

I’m pretty sure I’m overlooking something really simple but somehow I’m stuck.

Initially I had a fairly standard setup: my router at home does IPv6 router 
advertisements + DHCP + DNS etc., local hosts do slaac and stateless dhcpv6.

Due to several reasons I wanted to move DHCP + DNS away from the router to a 
separate server. So what I did was
• Switch off DHCPv6 on the router
• Keep Router Advertisements active on router (with O flag set)
• Set up dnsmasq on the new dedicated DNS/DHCP server (Debian 11, dnsmasq 
2.85). dnsmasq config is here: 
https://pastebin.aw.net/?f55651e94ecc6755#GhRFdiYGdzPpurJOks4etAmXx7u3dxGvuJQBdemNWOk=

What is now happening is that both the router as well as the dnsmasq server 
send router advertisements and my local hosts end up with two default routes. 
If I completely leave out the dhcp-range statement for IPv6, then dnsmasq will 
not send any router advertisements but unfortunately the really nice ra-names 
functionality is also switched off.

Interestingly enough, my local Linux and MacOS don’t seem to be bothered at all 
by the two default routes while the Windows clients get confused sometimes (if 
I understand correctly depending on when they received which router 
advertisement).

I tried to dig into the source code a bit and if I prevent dnsmasq from 
executing send_ra_aliases() that seems to do the trick. But I have to admit 
that I don’t understand the source code thoroughly enough and I assume this 
will break something else...

So my question is: is there a way to stop dnsmasq from sending router 
advertisements while at the same still providing the ra-names functionality? 

Thanks,
 Klaus

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


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

2024-02-06 Thread Dominik Derigs via Dnsmasq-discuss

Hey Simon,

this patch adds a method for deprecating ANY queries (following RFC 
8482: Providing Minimal-Sized Responses to DNS Queries That Have 
QTYPE=ANY). This conforms to how many of the large scale upstream DNS 
providers (Google, Cloudflare to name only a few) are dealing with the 
use_less_ness of ANY in general on one hand but the unfortunate 
use_full_ness in DNS amplification attacks on the other hand. Another 
solution could be only disallowing ANY queries over UDP and forcing 
clients to re-try over TCP but - given how useless ANY is - it doesn't 
seem worth implementing this more complex path.


The proposed option --no-ANY simply ensures dnsmasq will not add any RRs 
for such questions.


We are looking forward to enable it by default in Pi-hole v6.0+ given 
this patch is accepted.


Best,
Dominik
From ac3134c48ef3ee6ec9be2f3b0993f710ac36f8f8 Mon Sep 17 00:00:00 2001
From: DL6ER 
Date: Tue, 6 Feb 2024 17:51:22 +0100
Subject: [PATCH] Add option --no-ANY providing minimal-sized responses to ANY
 queries (RFC 8482)

Signed-off-by: DL6ER 
---
 CHANGELOG | 4 
 man/dnsmasq.8 | 9 +
 src/dnsmasq.h | 3 ++-
 src/option.c  | 3 +++
 src/rfc1035.c | 8 
 5 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG b/CHANGELOG
index 2ce53a8..75575b5 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -25,6 +25,10 @@ version 2.90
 	end up in the query also. This bug only seems to cause problems
 	when the usptream server is a DOH/DOT proxy. Thanks to Justin He
 	for the bug report.
+
+	Add --no-ANY option to stop processing ANY queries.
+	The ANY type has been deprecated by RFC 8482, and is a common vector
+	for DNS amplification attacks.
 	
 	
 version 2.89
diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index bb8da54..1a7a280 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -388,6 +388,15 @@ Remove  records from answers. No IPv6 addresses will be returned.
 .B --filter-rr=[,...]
 Remove records of the specified type(s) from answers.
 .TP
+.B --no-ANY
+Provide minimal-sized responses to ANY DNS queries instead of processing them.
+Queries with QTYPE=ANY are frequently observed as part of reflection attacks,
+since a relatively small query can be used to elicit a large response. This is a desirable
+characteristic if the goal is to maximize the amplification potential of a DNS server as
+part of a volumetric attack. With this option being enabled, minimal responses are returned making
+dnsmasq a much less useful amplifier.
+The follows RFC 8482 which effectively deprecates the DNS ANY query type.
+.TP
 .B --cache-rr=[,...]
 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
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 129e2c9..9ec4d39 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -282,7 +282,8 @@ struct event_desc {
 #define OPT_NO_IDENT   70
 #define OPT_CACHE_RR   71
 #define OPT_LOCALHOST_SERVICE  72
-#define OPT_LAST   73
+#define OPT_NO_ANY 73
+#define OPT_LAST   74
 
 #define OPTION_BITS (sizeof(unsigned int)*8)
 #define OPTION_SIZE ( (OPT_LAST/OPTION_BITS)+((OPT_LAST%OPTION_BITS)!=0) )
diff --git a/src/option.c b/src/option.c
index 0cb691e..a5297eb 100644
--- a/src/option.c
+++ b/src/option.c
@@ -191,6 +191,7 @@ struct myoption {
 #define LOPT_NO_DHCP6  382
 #define LOPT_NO_DHCP4  383
 #define LOPT_MAX_PROCS 384
+#define LOPT_NO_ANY385
 
 #ifdef HAVE_GETOPT_LONG
 static const struct option opts[] =  
@@ -231,6 +232,7 @@ static const struct myoption opts[] =
 { "filter-A", 0, 0, LOPT_FILTER_A },
 { "filter-", 0, 0, LOPT_FILTER_ },
 { "filter-rr", 1, 0, LOPT_FILTER_RR },
+{ "no-ANY", 0, 0, LOPT_NO_ANY },
 { "pid-file", 2, 0, 'x' },
 { "strict-order", 0, 0, 'o' },
 { "server", 1, 0, 'S' },
@@ -416,6 +418,7 @@ static struct {
   { LOPT_FILTER_A, ARG_DUP, NULL, gettext_noop("Don't include IPv4 addresses in DNS answers."), NULL },
   { LOPT_FILTER_, ARG_DUP, NULL, gettext_noop("Don't include IPv6 addresses in DNS answers."), NULL },
   { LOPT_FILTER_RR, ARG_DUP, "", gettext_noop("Don't include resource records of the given type in DNS answers."), NULL },
+  { LOPT_NO_ANY, OPT_NO_ANY, NULL, gettext_noop("Don't reply to ANY requests"), NULL },
   { 'F', ARG_DUP, ",...", gettext_noop("Enable DHCP in the range given with lease duration."), NULL },
   { 'g', ARG_ONE, "", gettext_noop("Change to this group after startup (defaults to %s)."), CHGRP },
   { 'G', ARG_DUP, "", gettext_noop("Set address or hostname for a specified machine."), NULL },
diff --git a/src/rfc1035.c b/src/rfc1035.c
index 04b1472..423a4b4 100644
--- a/src/rfc1035.c
+++ b/src/rfc1035.c
@@ -1550,6 +1550,14 @@ size_t answer_request(struct 

Re: [Dnsmasq-discuss] Restrict nameserver interfaces but not dhcp ones

2024-01-05 Thread Luigi Baldoni via Dnsmasq-discuss
On 5 January 2024, Geert Stappers wrote:
> On Fri, Jan 05, 2024 at 09:58:19AM +0100, Luigi Baldoni wrote:
> > On 4 January 2024, Geert Stappers wrote:
> > > On Thu, Jan 04, 2024 at 08:08:46PM +0100, Luigi Baldoni wrote:
> > > >
> > > > I'm trying to get rid of a second (kea) dhcp server and
> > > > hopefully be able to do everything I need with dnsmasq.
> > > >
> > > > The main hurdle, so far, is to run the nameserver only
> > > > on eth1, because bind is listening on eth0, but have
> > > > the dhcp server listen on both interfaces (and more).
> > >
> > > What has already been tried?
> >
> > Done several tests and if I launch dnsmasq first then neither it nor bind 
> > will  complain,
> > but ss lists both listening on port 53 on the same interface.
>
> Mmm, I hoped that 'What has already been  tried?' got an answer like
>   Configured for daemon A , for daemon B 
>   Configured for daemon A , for daemon B 
>   Configured for daemon A , for daemon B 
>   Configured for daemon A , for daemon B 
>   Repeated that with starting the other one first
>   All iterations checked with ...
>
> > > Advice: Tell in the reply more about the network, such as
> > > which IP-addresses are on the network interfaces.
> >
> > This is a map of my network:
>
> > lan15 192.168.7.0/24 bind on 192.168.7.100 and dnsmasq dhcp on the same 
> > address (can be changed)
> > lan30 192.168.8.0/24 dnsmasq dhcp on 192.168.8.150
> > lan45 192.168.11.0.24/ dnsmasq dhcp on 192.168.11.150
> > lan130 192.168.130.0/24 dnsmasq ns and dnsmasq dhcp on 192.168.130.200
> > lan166 192.168.166.0/24 dnsmasq dhcp on 192.168.166.200
>
> Acknowledge on "these 5 networks". What about telling the IP-adresses on
> the interfaces of the box where the tests^Wconfiguration attempts are done?

They are mentioned on the same line for each.

> (I'm lost, previously one computer with eth0 and eth1, now five networks
> and nothing about eth0 nor eth1.)

Forget about those. It was a basic example, the one above is my actual
configuration.

> For what it is worth: Over here is it "dnsmasq works" My reason for
> involvement in discussion like this is "can dnsmasq be better?" and/or
> "what can i learn more about dnsmasq?".  I aim for win-win. Making lots
> of effort to understand what is going on the other side, reduces "my win".

I hear you, but before beginning systematic testing, what I would like
to understand is whether it's theoretically possible, in dnsmasq, for
the listen interface for the nameserver to be configured separately from
the dhcp one. Otherwise this whole exercise is kind of pointless.

Right now if bind is started before dnsmasq, then dnsmasq won't start.
If dnsmasq is started before bind, dnsmasq starts but it takes over
port 53 on every interface and bind doesn't receive queries.
DHCP appears to be working, at least on a non-conflicting interface.
(tried this with only lan15, lan30 and lan130 enabled).

Regards


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


Re: [Dnsmasq-discuss] Restrict nameserver interfaces but not dhcp ones

2024-01-05 Thread Luigi Baldoni via Dnsmasq-discuss
On 4 January 2024, Geert Stappers wrote:

> > On Thu, Jan 04, 2024 at 08:08:46PM +0100, Luigi Baldoni wrote:
> >
> > I'm trying to get rid of a second (kea) dhcp server and
> > hopefully be able to do everything I need with dnsmasq.
> >
> > The main hurdle, so far, is to run the nameserver only
> > on eth1, because bind is listening on eth0, but have
> > the dhcp server listen on both interfaces (and more).
>
> What has already been tried?

Done several tests and if I launch dnsmasq first then neither it nor bind will  
complain,
but ss lists both listening on port 53 on the same interface.

> Advice: Tell in the reply more about the network, such as
> which IP-addresses are on the network interfaces.

This is a map of my network:

lan15 192.168.7.0/24 bind on 192.168.7.100 and dnsmasq dhcp on the same address 
(can be changed)
lan30 192.168.8.0/24 dnsmasq dhcp on 192.168.8.150
lan45 192.168.11.0.24/ dnsmasq dhcp on 192.168.11.150
lan130 192.168.130.0/24 dnsmasq ns and dnsmasq dhcp on 192.168.130.200
lan166 192.168.166.0/24 dnsmasq dhcp on 192.168.166.200

Regards


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


[Dnsmasq-discuss] Restrict nameserver interfaces but not dhcp ones

2024-01-04 Thread Luigi Baldoni via Dnsmasq-discuss
  Hello,
I'm trying to get rid of a second (kea) dhcp server and
hopefully be able to do everything I need with dnsmasq.

The main hurdle, so far, is to run the nameserver only
on eth1, because bind is listening on eth0, but have
the dhcp server listen on both interfaces (and more).

The secondary question concerns the syntax of dhcp-host:
is it possible to have it pass the IP address by hostname,
resolving it locally (from bind in this case) instead
of hardcoding it?

Thanks


___
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 packet received on enp6s0 which has no address

2024-01-04 Thread Buck Horn via Dnsmasq-discuss



On 04.01.24 09:46, Masin wrote:

Hi Buck,

thanks for your hints. Sadly, they don't work.

3. Januar 2024 18:48, "Buck Horn via Dnsmasq-discuss" 

schrieb:
> (...)
> Regarding your configuration: Did you try a configuration with just 
listen-address and bind-interfaces, without interface, no-dhcp-interface, and 
except-interface options?
I try to avoid that because I want dnsmasq to bin to whatevet IPv6 address the 
container receives.
I'm still new to IPv6 but I want to make it work in my local network. And as 
DHCPv6 seems to work
quite different I don't know what address to expect for the container.

But it's worth a try.


root@lan-basics:~# systemctl start dnsmasq.service
Job for dnsmasq.service failed because the control process exited with error 
code.
See "systemctl status dnsmasq.service" and "journalctl -xeu dnsmasq.service" 
for details.
root@lan-basics:~# cat /etc/dnsmasq.d/dns.conf
domain-needed
bogus-priv

listen-address=10.23.40.53,fd00::2e2:69ff:fe61:fe9f

log-queries=extra
cache-size=1000
dnssec

no-resolv
#domain=wiedner.berlin
expand-hosts
no-negcache

servers-file=/etc/dnsmasq.d/google.dns
#servers-file=/etc/dnsmasq.d/quad9.dns
conf-file=/usr/share/dnsmasq-base/trust-anchors.conf



That config is missing the suggested bind-interfaces option. ;)

As for DHCPv6:
It's probably a good idea to concern yourself with IPv6 only once IPv4
is working.
Most clients won't use DHCPv6 anyway.

IPv6 clients may join a network via SLAAC or Stateless or Stateful DHCPv6.

MacOS and Linux could do all three early on.
Windows preferred DHCPv6 for a long time, I believe supporting SLAAC
started with the introduction of Win8.1 or 10.
Android only does and only ever did SLAAC.

It's a client's OS (and its configuration, of course, as well as the
router configuration) that decides which mechanism is employed, but
there's a strong preference for SLAAC as a default.

You may even find out that you do not need DHCPv6 at all.


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


Re: [Dnsmasq-discuss] DHCP packet received on enp6s0 which has no address

2024-01-03 Thread Buck Horn via Dnsmasq-discuss

On 03.01.24 16:12, Masin wrote:

In the log I got

DHCP packet received on enp6s0 which has no address



That message isn't necessarily related to your attempt of having dnsmasq
and systemd-resolved coexist (however, your mentioning of IPv4 LLAs
could mean it is). It tells you that your enp6s0 network interface had
no address at the time the packet was received.

That could happen if dnsmasq was ready before the networking stack of
your OS, or if indeed there would be no address proper assigned to enp6s0.

Just to make sure: You did configure a static IP address on the host
running dnsmasq as DHCP server, didn't you?

Regarding your configuration: Did you try a configuration with just
listen-address and bind-interfaces, without interface,
no-dhcp-interface, and except-interface options?

Kind regards,

    Buck



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


[Dnsmasq-discuss] DNSMasq as secondary server

2023-12-13 Thread Michel DIEMER via Dnsmasq-discuss
‌

‌

‌

‌Dear dnsmasq user,

I have a domain let's claim that it is somedomain.com

I own that domain and it is officially registred and the name servers for that 
domain are on the Internet.

There is a physical server with two network interfaces, one connected to the 
Internet and one connected to the local network.

dnsmasq is running on that server.

My ISP does not support IPv6. IPv6 is not disabled but not properly configured. 
IPv4 is configured.


The web ports (80 and 443) are redirected to the web server of the local 
network. Only the server with dnsmasq and the web server are accessible from 
the Internet. Other computers are not and should not.

So when I type "https://somedomain.com; from any web browser, from the local 
network or from the Internet, the website is loaded from the internet server on 
the local network.


Now I have several computers on the local network and dnsmasq is configured for 
the domain "somedomain.com".


The domain of the localnetwork is "somedomain.com".

Now when I ping a computer on the Interneet from the local network it is 
working fine, using some publc DNS.


The problem is when I want to "ping somecomputer.somedimain.com".

If "somecomputer" is on the lan I want dnsmasq to give the private, local IP 
address.

If "somecomputer" is not on the lan, dnsmasq may use the public name server as 
anyone who is on the Internet.


"ping computer1.somedomain.com" -> local IP address, fine

"ping computer2.somedomain.com" -> tries to find computer2 on the WAN using the 
public IPv4 address. Not working. dnsmasq should find computer2.

"ping somedomain.com" -> should return either the public Internet IP address of 
the domain or the local IP address of the local dns server. Works fine from 
Internet but not from the internal network.

"ping google.fr" -> works find, using public DNS


If it is not supposed to work I will replace dnsmasq setting from 
domain=somedomain.com to domain=lan.somedomain.com or domain=somedomain.lan. 
Except the web server, other computers on the local network are not supposed to 
be visible from the Internet.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Caching of HTTPS and SVCB records

2023-12-08 Thread Evandro Menezes via Dnsmasq-discuss
Awesome!  This will make evaluating the caching of the HTTPS record much more 
easy.

Thank you, Dominik.

-- 
Evandro Menezes



> Em 7 de dez. de 2023, à(s) 21:35, Dominik Derigs  escreveu:
> 
> Hey Evandro,
> 
> chaching of arbitrary types has been added this year in March and is
> available in the latest master code (option --cache-rr). You can even
> add --cache-rr=ANY to cache all records.
> 
> See
> https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=638c7c4d20004c0f320820098e29df62a27dd2a1
> and
> https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=c244d92d8a3f96e3a16b53f733190faa17004ae3
> 
> and the corresponding man page entry:
> 
> --cache-rr=[,...]
> 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 is allowed. Use --cache-rr=ANY to enable caching for
> all RR-types.
> 
> This feature is included in the current Pi-hole v6.0 beta testing to get
> a wide testing audience (it is enabled to cache ANY in Pi-hole) but more
> testing is always welcome!
> 
> Best,
> Dominik
> 
> On Thu, 2023-12-07 at 14:05 -0600, Evandro Menezes via Dnsmasq-discuss
> wrote:
>> Current OSes are now using the HTTPS record to query the addresses and the 
>> canonical name, as well other information important to browsers, rather than 
>> using the A and  records as they used to.
>> 
>> In my anecdotal experience, HTTPS queries amount to over a third of the 
>> queries.  It might make sense to cache their replies, if not to decode them 
>> and also populate the cache with any information for A,  and CNAME the 
>> they may contain.
>> 
>> Another record that is rising in usage in SVCB, primarily by browsers and 
>> IoT devices, to discover the DNS resolvers for DNS over HTTPS, DNS over TLS 
>> and DNS over QUIC.  Along with HTTPS, it would be interesting to add a 
>> configuration option for these records.
>> 
>> If these suggestions are considered worthwhile, I’d be glad to contribute 
>> patches.
>> 
>> Cheers,
>> 
> 

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


Re: [Dnsmasq-discuss] Caching of HTTPS and SVCB records

2023-12-08 Thread Evandro Menezes via Dnsmasq-discuss
It is already in the master branch.

After building it, one can use `man -l man/dnsmasq.8` from the project 
directory to view the new manual.

HTH 

-- 
Evandro Menezes



> Em 8 de dez. de 2023, à(s) 10:18, Eric Fahlgren  
> escreveu:
> 
> 
> On Fri, Dec 8, 2023 at 6:42 AM Donald Muller  <mailto:donmulle...@outlook.com>> wrote:
>> I do not see this in the man page. 
>> 
>> https://thekellys.org.uk/dnsmasq/docs/dnsmasq-man.htm 
>> <https://thekellys.org.uk/dnsmasq/docs/dnsmasq-man.html>
> Yes.  It's not released yet so you have to look on the 'all-rr-type' branch:
> 
> https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=man/dnsmasq.8;h=acb78df891320e41c84e4f5aa4b92d295ef22b19;hb=refs/heads/all-rr-type#l382
> 
> 
> _______
> 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] Caching of HTTPS and SVCB records

2023-12-07 Thread Dominik Derigs via Dnsmasq-discuss
Hey Evandro,

chaching of arbitrary types has been added this year in March and is
available in the latest master code (option --cache-rr). You can even
add --cache-rr=ANY to cache all records.

See
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=638c7c4d20004c0f320820098e29df62a27dd2a1
and
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=c244d92d8a3f96e3a16b53f733190faa17004ae3

and the corresponding man page entry:

--cache-rr=[,...]
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 is allowed. Use --cache-rr=ANY to enable caching for
all RR-types.

This feature is included in the current Pi-hole v6.0 beta testing to get
a wide testing audience (it is enabled to cache ANY in Pi-hole) but more
testing is always welcome!

Best,
Dominik

On Thu, 2023-12-07 at 14:05 -0600, Evandro Menezes via Dnsmasq-discuss
wrote:
> Current OSes are now using the HTTPS record to query the addresses and the 
> canonical name, as well other information important to browsers, rather than 
> using the A and  records as they used to.
> 
> In my anecdotal experience, HTTPS queries amount to over a third of the 
> queries.  It might make sense to cache their replies, if not to decode them 
> and also populate the cache with any information for A,  and CNAME the 
> they may contain.
> 
> Another record that is rising in usage in SVCB, primarily by browsers and IoT 
> devices, to discover the DNS resolvers for DNS over HTTPS, DNS over TLS and 
> DNS over QUIC.  Along with HTTPS, it would be interesting to add a 
> configuration option for these records.
> 
> If these suggestions are considered worthwhile, I’d be glad to contribute 
> patches.
> 
> Cheers,
> 


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


Re: [Dnsmasq-discuss] Caching of NS and SOA records

2023-12-07 Thread Dominik Derigs via Dnsmasq-discuss
Hey Evandro,

see my reply to your other question as the questions are just two
aspects of the same thing:

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2023q4/017363.html

Best,
Dominik

P.S. Your address evandro+dnsm...@gcc.gnu.org throws an "user unknown"
error.



On Thu, 2023-12-07 at 15:44 -0600, Evandro Menezes via Dnsmasq-discuss
wrote:
> Before I went and hacked it, I figured that it’d be better to float the idea, 
> in case it’d been discussed before and deemed not worthy the while.
> 


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


Re: [Dnsmasq-discuss] Caching of NS and SOA records

2023-12-07 Thread Evandro Menezes via Dnsmasq-discuss
Before I went and hacked it, I figured that it’d be better to float the idea, 
in case it’d been discussed before and deemed not worthy the while.

-- 
Evandro Menezes



> Em 7 de dez. de 2023, à(s) 14:37, Geert Stappers  
> escreveu:
> 
> On Thu, Dec 07, 2023 at 01:03:16PM -0600, Evandro Menezes wrote:
>> 
>> I’d gladly contribute a patch if this is deemed worthwhile.
> 
> Build it, play with it and find out the "worthwhile".


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


[Dnsmasq-discuss] Caching of HTTPS and SVCB records

2023-12-07 Thread Evandro Menezes via Dnsmasq-discuss
Current OSes are now using the HTTPS record to query the addresses and the 
canonical name, as well other information important to browsers, rather than 
using the A and  records as they used to.

In my anecdotal experience, HTTPS queries amount to over a third of the 
queries.  It might make sense to cache their replies, if not to decode them and 
also populate the cache with any information for A,  and CNAME the they may 
contain.

Another record that is rising in usage in SVCB, primarily by browsers and IoT 
devices, to discover the DNS resolvers for DNS over HTTPS, DNS over TLS and DNS 
over QUIC.  Along with HTTPS, it would be interesting to add a configuration 
option for these records.

If these suggestions are considered worthwhile, I’d be glad to contribute 
patches.

Cheers,

-- 
Evandro Menezes




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


[Dnsmasq-discuss] Caching of NS and SOA records

2023-12-07 Thread Evandro Menezes via Dnsmasq-discuss
These records are not cached, right?  In my anecdotal experience, they 
represent just 2 to 5% of the queries.  Though these records are not very 
common, their TTL is fairly high, so it might make sense to cache them as well, 
since their replies necessarily gate subsequent queries, which would improve 
latency of the latter's.

I’d gladly contribute a patch if this is deemed worthwhile.

Cheers,

-- 
Evandro Menezes




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


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

2023-11-30 Thread Chris Friesen via Dnsmasq-discuss

On 11/30/2023 6:13 AM, Simon Kelley wrote:

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. 


I performed some practical tests in case anyone is interested. I created 
one dnsmasq instance with:


interface=enp0s8
interface=enp0s10
bind-interfaces
listen-address=192.168.204.1

and another with

interface=enp0s9
bind-interfaces
except-interface=lo

Both instances were able to start up without any issues, presumably 
because of SO_REUSEADDR /SO_REUSEPORT being used on the socket.


NOTE: If I don't specify "bind-interfaces" in the second case, then it 
errors out with "failed to bind DHCP server socket: Address already in use".


From another host I then ran "dhclient -d enp0s9" to emit a broadcast 
packet, or "dhclient  -d enp0s9 -s " to emit a unicast packet.


If the incoming DHCP packets on enp0s9 are broadcast packets, everything 
is fine because both instances of dnsmasq receive the packet (due to 
SO_REUSEADDR /SO_REUSEPORT).  The first instance just ignores it, the 
second instance replies to it.


If the incoming DHCP packets on enp0s9 are unicast packets (like a 
DHCPREQUEST to the IP address of enp0s9), it's non-deterministic which 
instance of dnsmasq receives the packet.  If it's the first, the packet 
is ignored and the client gets no response.  If it's the second, it 
works as expected.


Following the instructions above to ensure that each instance binds to a 
single interface with SO_BINDTODEVICE would avoid the issue with the 
unicast packets by ensuring that all the incoming packets are processed 
by the dnsmasq instance which actually cares about them.


Chris Friesen


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


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

2023-11-30 Thread Chris Friesen via Dnsmasq-discuss

On 11/30/2023 6:13 AM, Simon Kelley wrote:

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.


Perfect, thanks.

Chris


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


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

2023-11-30 Thread Buck Horn via Dnsmasq-discuss


On 30.11.23 00:09, Chris Friesen via Dnsmasq-discuss wrote:

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


Yes.

You may also want to further tune usage via '--no-dhcp-interface' (or
maybe '--no-dhcpv4-interface' and '--no-dhcpv6-interface' in a future
release, see
https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg16828.html
).

However, I wonder whether tagging requests for the interfaces and
setting up corresponding dhcp options for those tags wouldn't already
match your requirements with only one instance of dnsmasq running.

Kind regards,
    Buck


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


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

2023-11-29 Thread Chris Friesen via Dnsmasq-discuss

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

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


[Dnsmasq-discuss] [PATCH] Add number of forks for TCP to metrics and dump

2023-11-24 Thread Damian Sawicki via Dnsmasq-discuss
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 = 1;
   daem

Re: [Dnsmasq-discuss] dnsmasq page fault

2023-11-14 Thread Damian Sawicki via Dnsmasq-discuss
Hi Hartmut,

Thank you very much for the report and my sincere apologies for missing this!

Simon, many thanks for the quick reaction. I'm not an expert, but I've reviewed 
the commit with the fix just in case, and I agree that it should fix the 
problem reported by Hartmut.

Regards,
Damian

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


[Dnsmasq-discuss] having 2 dnsmasq in redundacy + zone transfer

2023-11-10 Thread Doff via Dnsmasq-discuss

Hi gurus,

I appologize in advance for my poor english, I'm not a native speaker.


I'm trying to setup a double dnsmasq configuration acting this way : 
having one dnsmasq as an authoritative server for a zone, and a second 
one being a slave server.


I'd like to configure these to have zone transfer between them.

The first part, the one with zone authority and zone transfer to my ISP 
works fine. Now, (for fun), I'd like to have another dnsmasq running, as 
a slave system, to see if I can replace my ISP dns.


So, I've been able to configure my primary dnsmasq system with 
auth-sec-servers and auth-peer, but the slave one, I couldn't find any 
documentation on how to set this correctly.


I've dug the internet (maybe not enough) but this "slave" config is 
still a mystery.


Would anyone have a hint to achieve this ?

Thanks in advance

Doff


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


[Dnsmasq-discuss] New query type RESINFO

2023-11-02 Thread Dominik Derigs via Dnsmasq-discuss
Hey Simon,

today the IANA started listing a new query type RESINFO that was
assigned to RR Type no. 261. The simple attached patch adds this RR Type
to dnsmasq.

Best,
Dominik
From a6331078d3b22c960df8ad78106da567cb76e82c Mon Sep 17 00:00:00 2001
From: DL6ER 
Date: Thu, 2 Nov 2023 17:57:54 +0100
Subject: [PATCH] New querytype 261 RESINFO

Signed-off-by: DL6ER 
---
 src/cache.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/cache.c b/src/cache.c
index 9f64a05..e28fad4 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -124,6 +124,7 @@ static const struct {
   { 258, "AVC" }, /* Application Visibility and Control [Wolfgang_Riedel] AVC/avc-completed-template 2016-02-26*/
   { 259, "DOA" }, /* Digital Object Architecture [draft-durand-doa-over-dns] DOA/doa-completed-template 2017-08-30*/
   { 260, "AMTRELAY" }, /* Automatic Multicast Tunneling Relay [RFC8777] AMTRELAY/amtrelay-completed-template 2019-02-06*/
+  { 261, "RESINFO" }, /* Resolver Information as Key/Value Pairs https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/06/ */
   { 32768,  "TA" }, /* DNSSEC Trust Authorities [Sam_Weiler][http://cameo.library.cmu.edu/][ Deploying DNSSEC Without a Signed Root. Technical Report 1999-19, Information Networking Institute, Carnegie Mellon University, April 2004.] 2005-12-13*/
   { 32769,  "DLV" }, /* DNSSEC Lookaside Validation (OBSOLETE) [RFC8749][RFC4431] */
 };
-- 
2.34.1

_______
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

2023-10-25 Thread Luigi Baldoni via Dnsmasq-discuss
Sent: Tuesday, October 24, 2023 at 10:15 PM
From: "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.

Thanks for the in-depth answer.
Will file a bug report upstream and see what the ISC people can tell me.

Regards


___
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

2023-10-19 Thread Luigi Baldoni via Dnsmasq-discuss
Sent: Thursday, October 19, 2023 at 4:06 PM
From: "Matus UHLAR - fantomas" 
>
> >On Wed Oct 18 09:00:24 UTC 2023, Matus UHLAR wrote:
> >> I don't see any explicit option to disable dhcp server, but using
> >> --no-dhcp-interface= option or --dhcp-alternate-port could hep you.
>
> On 19.10.23 14:02, Luigi Baldoni via Dnsmasq-discuss wrote:
> >I do not wish to disable the dhcp server, indeed I want to use it.
>
> why do you run kea dhcp server then?

It's different traffic that I wish to handle separately and it's easier for me 
this way.

> >Applying --no-dhcp-interface for lo and other interfaces did not help.
> >Would the dhcp server still work if listening on a different interface?
>
> yes, that's possible.
> option bind-interfaces should fix the problem.

That solved the problem with ISC dhcp server, but not with kea.

> >> how is it being started? could the startup procedures be protecting the 
> >> config by rewriting it to a known state during startup?
>
> >On Wed Oct 18 09:56:49 UTC 2023, wkitty42 wrote:
> >Tried init, systemctl (two different debian installations) and invoking the 
> >daemon straight from console: no change.
>
> I don't think this will help.

Which one?

> the problem is that both dnsmasq and kea dhcp server are trying to listen on
> port 69.

On different interfaces. And it's hard for me to understand why both, or dnsmasq
at any rate, attempt to listen on interfaces that are explicitly excluded in the
configuration.

Regards


___
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

2023-10-19 Thread Luigi Baldoni via Dnsmasq-discuss
On Wed Oct 18 09:00:24 UTC 2023, Matus UHLAR wrote:

> I don't see any explicit option to disable dhcp server, but using
> --no-dhcp-interface= option or --dhcp-alternate-port could hep you.

I do not wish to disable the dhcp server, indeed I want to use it.
Applying --no-dhcp-interface for lo and other interfaces did not help.
Would the dhcp server still work if listening on a different interface?

On Wed Oct 18 09:56:49 UTC 2023, wkitty42 wrote:

> how is it being started? could the startup procedures be protecting the 
> config by rewriting it to a known state during startup?

Tried init, systemctl (two different debian installations) and invoking the 
daemon straight from console: no change.

Regards



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


[Dnsmasq-discuss] [PATCH] Add a flag to customize MAX_PROCS

2023-10-18 Thread Damian Sawicki via Dnsmasq-discuss
Add the flag --max-tcp-connections overwriting the former MAX_PROCS
constant limiting the number of concurrent TCP requests handled.
---
 man/dnsmasq.8 |  4 
 src/config.h  |  2 +-
 src/dnsmasq.c | 23 ---
 src/dnsmasq.h |  5 +++--
 src/option.c  | 16 +++-
 5 files changed, 39 insertions(+), 11 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 30429df..6d37360 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -2254,6 +2254,10 @@ example command to query this, using the
 utility would be
 
 dig +short chaos txt cachesize.bind
+.TP
+.B --max-tcp-connections=
+The maximum number of concurrent TCP connections. The application forks to
+handle each TCP request. The default maximum is 20.
 
 .SH CONFIG FILE
 At startup, dnsmasq reads
diff --git a/src/config.h b/src/config.h
index 88cf72e..cc1c465 100644
--- a/src/config.h
+++ b/src/config.h
@@ -15,7 +15,7 @@
 */
 
 #define FTABSIZ 150 /* max number of outstanding requests (default) */
-#define MAX_PROCS 20 /* max no children for TCP requests */
+#define MAX_PROCS 20 /* default max no children for TCP requests */
 #define CHILD_LIFETIME 150 /* secs 'till terminated (RFC1035 suggests > 120s) 
*/
 #define TCP_MAX_QUERIES 100 /* Maximum number of queries per incoming TCP 
connection */
 #define TCP_BACKLOG 32  /* kernel backlog limit for TCP connections */
diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index bc6644c..112dbe5 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -36,6 +36,7 @@ static void async_event(int pipe, time_t now);
 static void fatal_event(struct event_desc *ev, char *msg);
 static int read_event(int fd, struct event_desc *evp, char **msg);
 static void poll_resolv(int force, int do_reload, time_t now);
+static void tcp_init(void);
 
 int main (int argc, char **argv)
 {
@@ -415,6 +416,8 @@ int main (int argc, char **argv)
daemon->numrrand = max_fd/3;
   /* safe_malloc returns zero'd memory */
   daemon->randomsocks = safe_malloc(daemon->numrrand * sizeof(struct 
randfd));
+
+  tcp_init();
 }
 
 #ifdef HAVE_INOTIFY
@@ -1043,7 +1046,7 @@ int main (int argc, char **argv)
   pid = getpid();
 
   daemon->pipe_to_parent = -1;
-  for (i = 0; i < MAX_PROCS; i++)
+  for (i = 0; i < daemon->max_procs; i++)
 daemon->tcp_pipes[i] = -1;
   
 #ifdef HAVE_INOTIFY
@@ -1520,7 +1523,7 @@ static void async_event(int pipe, time_t now)
break;
}  
  else 
-   for (i = 0 ; i < MAX_PROCS; i++)
+   for (i = 0 ; i < daemon->max_procs; i++)
  if (daemon->tcp_pids[i] == p)
daemon->tcp_pids[i] = 0;
break;
@@ -1584,7 +1587,7 @@ static void async_event(int pipe, time_t now)

   case EVENT_TERM:
/* Knock all our children on the head. */
-   for (i = 0; i < MAX_PROCS; i++)
+   for (i = 0; i < daemon->max_procs; i++)
  if (daemon->tcp_pids[i] != 0)
kill(daemon->tcp_pids[i], SIGALRM);

@@ -1761,7 +1764,7 @@ static void set_dns_listeners(void)
 poll_listen(rfl->rfd->fd, POLLIN);
   
   /* check to see if we have free tcp process slots. */
-  for (i = MAX_PROCS - 1; i >= 0; i--)
+  for (i = daemon->max_procs - 1; i >= 0; i--)
 if (daemon->tcp_pids[i] == 0 && daemon->tcp_pipes[i] == -1)
   break;
 
@@ -1785,7 +1788,7 @@ static void set_dns_listeners(void)
 }
   
   if (!option_bool(OPT_DEBUG))
-for (i = 0; i < MAX_PROCS; i++)
+for (i = 0; i < daemon->max_procs; i++)
   if (daemon->tcp_pipes[i] != -1)
poll_listen(daemon->tcp_pipes[i], POLLIN);
 }
@@ -1820,7 +1823,7 @@ static void check_dns_listeners(time_t now)
  to free the process slot. Once the child process has gone, poll()
  returns POLLHUP, not POLLIN, so have to check for both here. */
   if (!option_bool(OPT_DEBUG))
-for (i = 0; i < MAX_PROCS; i++)
+for (i = 0; i < daemon->max_procs; i++)
   if (daemon->tcp_pipes[i] != -1 &&
  poll_check(daemon->tcp_pipes[i], POLLIN | POLLHUP) &&
  !cache_recv_insert(now, daemon->tcp_pipes[i]))
@@ -1844,7 +1847,7 @@ static void check_dns_listeners(time_t now)
 at least one a poll() time, that we still do.
 There may be more waiting connections after
 poll() returns then free process slots. */
-  for (i = MAX_PROCS - 1; i >= 0; i--)
+  for (i = daemon->max_procs - 1; i >= 0; i--)
if (daemon->tcp_pids[i] == 0 && daemon->tcp_pipes[i] == -1)
  break;
 
@@ -2186,3 +2189,9 @@ int delay_dhcp(time_t start, int sec, int fd, uint32_t 
addr, unsigned short id)
   return 0;
 }
 #endif /* HAVE_DHCP */
+
+void tcp_init(void)
+{
+  daemon->tcp_pids = safe_malloc(daemon->max_procs*sizeof(pid_t));
+  daemon->tcp_pipes = safe_malloc(daemon->max_procs*sizeof(int));
+}
diff --git a/src/dnsmasq.h b/src/dnsmasq.

[Dnsmasq-discuss] Having dnsmasq coexist with other dhcp server

2023-10-18 Thread Luigi Baldoni via Dnsmasq-discuss
  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?


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


[Dnsmasq-discuss] [PATCH] Add a flag to customise MAX_PROCS

2023-10-11 Thread Damian Sawicki via Dnsmasq-discuss
Hello dnsmasq experts,

I'd like to propose a patch adding a flag to customise MAX_PROCS. I know
this was already suggested in
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014907.html
for other reasons and rejected back then. My motivation is that in some use
cases in Kubernetes, MAX_PROCS is actually a bottleneck, so it would be
great to have the possibility to customise this limit depending on the load.

Do you think that this patch is enough or would it be good to have insight
into the utilisation? I've prepared another patch that introduces logs with
the information on the number of child processes (behind a feature flag).
Could you please advise?

Please kindly let me know what you think.

Kind regards,

Damian Sawicki


0001-Add-a-flag-to-customize-MAX_PROCS.patch
Description: Binary data
___
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

2023-10-10 Thread Luci Stanescu via Dnsmasq-discuss
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.

>> 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.

Cheers,
Luci

-- 
Luci Stanescu
Information Security Consultant


smime.p7s
Description: S/MIME cryptographic signature
_______
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] [PATCH] Fix DHCPv6 "NotOnlink" response which previously failed to set the message type correctly

2023-10-10 Thread renmingshuai via Dnsmasq-discuss
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


Re: [Dnsmasq-discuss] DHCPv6 doesn't work on Linux interfaces enslaved to a VRF

2023-10-09 Thread Luci Stanescu via Dnsmasq-discuss
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

> 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?

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.

I've adapted my scripts slightly to allow easier testing of the behaviour. The 
receiver socket now binds to the VRF device instead (you can even not bind to 
any device and just set the net.ipv4.udp_l3mdev_accept sysctl to 1)

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

2023-10-08 Thread renmingshuai via Dnsmasq-discuss
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
}

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

2023-10-07 Thread Luci Stanescu via Dnsmasq-discuss
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 

[Dnsmasq-discuss] Memory leak for SRV records with TTL=0 in v2.88

2023-10-05 Thread Damian Sawicki via Dnsmasq-discuss
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

-

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

2023-09-28 Thread renmingshuai via Dnsmasq-discuss
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 ?S00: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 ?S00: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] VmRss of dnsmasq increases when I changed the host information in dhcp hostsfile

2023-09-25 Thread renmingshuai via Dnsmasq-discuss
Hi,
I run dnsmasq as the follow:
dnsmasq --no-hosts --dhcp-hostsfile=/home/hosts
Every time I changed the dhcp host information in /home/hosts, I found that the 
VmRss value of dnsmasq increases accordingly. Has anyone else had a similar 
problem?
___
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 use non-default routing table

2023-09-23 Thread Matthias May via Dnsmasq-discuss

Hi Luigi

Nothing wrong with using bind and dnsmasq at the same time.
Are you using the same upstream servers?
Or are they different IPs?
In the ip rule from my previous mail, you can also specify a 
destination, e.g.
# maym@Orpheus:~$ sudo ip rule add pref 100 iif lo proto 17 dport 53 to 
8.8.8.8 lookup 100

# maym@Orpheus:~$ ip rule
# 0:    from all lookup local
# 100:    from all to 8.8.8.8 iif lo dport 53 lookup 100 proto 17
# 32766:    from all lookup main
# 32767:    from all lookup default

Regarding the @interface option of --server:
This only forces as source an interface/source-ip.
That doesn't specify what router to use.
You still need somewhere to specify what router should be used.
--> This is what the additional default gateway on table 100 would do.
If your source is bound via the --server parameter, you can match in the 
routing rule on this:


In my setup my default gateway goes via wlan0.
# maym@Orpheus:~$ ip -br a
# lo   UNKNOWN    127.0.0.1/8 ::1/128
# eth0 DOWN
# wlan0    UP 10.0.8.147/24
# gpd0 UNKNOWN    10.0.17.5/24
# maym@Orpheus:~$ ip r
# default via 10.0.8.1 dev wlan0 proto dhcp src 10.0.8.147 metric 600
# 10.0.17.0/24 dev gpd0 proto kernel scope link src 10.0.17.5 metric 50

I now want to force requests from dnsmasq to go via the gateway 
10.0.17.1 reachable on gpd0
and all outgoing dns traffic originating from 10.0.17.5 should be sent 
via this gateway.


# maym@Orpheus:~$ sudo ip route add default via 10.0.17.1 table 100
# maym@Orpheus:~$ ip route show table 100
# default via 10.0.17.1 dev gpd0
# maym@Orpheus:~$ sudo ip rule add pref 100 iif lo proto 17 dport 53 
from 10.0.17.5 lookup 100

# maym@Orpheus:~$ ip rule
# 0:    from all lookup local
# 100:    from 10.0.17.5 iif lo dport 53 lookup 100 proto 17
# 32766:    from all lookup main
# 32767:    from all lookup default

With this setup: the @interface in the --server parameter forces the 
requests to have a source of 10.0.17.5
and the routing rule and routing table 100 ensure that the frames go via 
the gateway reachable on gpd0


BR
Matthias

On 23/09/2023 06:54, Luigi Baldoni wrote:

   Hi Matthias,
unfortunately that won't do because I also have bind running on the same machine
(please don't ask, long story).
So, I was thinking, why couldn't I simply use e.g. server=8.8.8.8@ppp1 as
dnsmasq option?
With that parameter set, I see the outgoing queries on ppp1 and the replies
from the upstream server, but dnsmasq still times out.

Am I misunderstanding the meaning of the @interface option?

Regards


Sent: Saturday, September 23, 2023 at 12:31 AM
From: "Matthias May via Dnsmasq-discuss" 


Hi Luigi

Strictly speaking this has nothing to do with dnsmasq, and is a question
of how to do policy-routing.
I assume you're using linux since you mention iptables.

A good starting point for policy routing with linux is
https://urldefense.com/v3/__https://tldp.org/HOWTO/Adv-Routing-HOWTO/__;!!I9LPvj3b!EwyAIUNi6FdVtkbRccYjgEyzfpK75jrOEKBROoLanLDjvsuLj6eKEyQrnraUNwOsDWwN9xblaimXym-rdQ$
respectively 
https://urldefense.com/v3/__https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html__;!!I9LPvj3b!EwyAIUNi6FdVtkbRccYjgEyzfpK75jrOEKBROoLanLDjvsuLj6eKEyQrnraUNwOsDWwN9xblailAtySdtA$

What i would do is to create a routing rule that redirects your frames
to a separate routing table.

By the default the routing rules look like this:
# maym@Orpheus:~$ ip rule
# 0:    from all lookup local
# 32766:    from all lookup main
# 32767:    from all lookup default

You can create a new routing table (e.g table 100) that contains a
different default gateway.
# maym@Orpheus:~$ sudo ip route add default via 10.0.8.99 table 100
# maym@Orpheus:~$ ip route show table 100
# default via 10.0.8.99 dev wlan0

Now create a routing rule that matches your traffic and calls the table 100:
# maym@Orpheus:~$ sudo ip rule add pref 100 iif lo proto 17 dport 53
lookup 100
# maym@Orpheus:~$ ip rule
# 0:    from all lookup local
# 100:    from all iif lo dport 53 lookup 100 proto 17
# 32766:    from all lookup main
# 32767:    from all lookup default

Now all traffic originating:
from the device itself (iif lo)
with proto 17 (udp)
to the destination port 53 (dns)
will be directed to the routing table 100 which contains the default
gateway to the router you want to use.

BR
Matthias

On 22/09/2023 15:10, Luigi Baldoni wrote:

Hello,
after a few days of fruitless efforts, I thought of asking you all directly.

I need dnsmasq to send its queries to the upstream server via a different
route than everything else. I've tried adding the @interface parameter to
the --server option but I don't think I quite understand how it's supposed
to work.
Then I've attempted to mark the packets originating from the dnsmasq process
via the iptables owner module, also with little success.

Before I proceed any further with these experiments, I would like to know
whether I'm missing something, or if some

Re: [Dnsmasq-discuss] Having dnsmasq use non-default routing table

2023-09-23 Thread Matthias May via Dnsmasq-discuss


On 23/09/2023 02:41, Wink Saville wrote:

On Fri, Sep 22, 2023 at 4:32 PM Matthias May via Dnsmasq-discuss
 wrote:


On 22/09/2023 18:27, Wink Saville wrote:

On Fri, Sep 22, 2023, 06:34 Luigi Baldoni  wrote:

Hello,
after a few days of fruitless efforts, I thought of asking you all directly.

I need dnsmasq to send its queries to the upstream server via a different
route than everything else. I've tried adding the @interface parameter to
the --server option but I don't think I quite understand how it's supposed
to work.
Then I've attempted to mark the packets originating from the dnsmasq process
via the iptables owner module, also with little success.

Before I proceed any further with these experiments, I would like to know
whether I'm missing something, or if someone has found a different way to
do this.

Thanks

I think your question is: How do I configure dnsmasq on Linux to send
its upstream DNS queries using a specific route?

Here is GPT-4 answer:
https://urldefense.com/v3/__https://chat.openai.com/share/47fe1f23-57b6-4bbb-b51d-c4bf3818ef__;!!I9LPvj3b!BOetutoPDMZVnmN8eLyHRg_93gZ4QBXVK9yRGbAdpa0cFIkcjOvTnrwVxE7UDVbqoi1GyC1C38Fqgutf$
  df

And Bard answer: 
https://urldefense.com/v3/__https://g.co/bard/share/866e99f101bf__;!!I9LPvj3b!BOetutoPDMZVnmN8eLyHRg_93gZ4QBXVK9yRGbAdpa0cFIkcjOvTnrwVxE7UDVbqoi1GyC1C319ebuBN$

If I've got the question wrong provide the proper question and I'll ask

-- Wink


Hi Wink

The link to openai returns a 404. What is the answer it provided? (pure
interest).

The bard answer looks to me like garbage. I don't think the parameters
it refers to actually exist...

BR
Matthias


Try the one below, I made a mistake as Bots do too :)

https://urldefense.com/v3/__https://chat.openai.com/share/47fe1f23-57b6-4bbb-b51d-c4bf3818efdf__;!!I9LPvj3b!BL7TTHnGyi-f6LFGBlpqC1YIqwzB9d4erTyuO1c25G0Lis9AGe-B2BIFaUjM9bitxr9YUyHGbB64J0OP$

-- Wink


Ok, this answer seems to be sane.
Probably doesn't solve Luigi's issue, but make sense :)

BR
Matthias


___
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 use non-default routing table

2023-09-22 Thread Matthias May via Dnsmasq-discuss



On 22/09/2023 18:27, Wink Saville wrote:

On Fri, Sep 22, 2023, 06:34 Luigi Baldoni  wrote:

   Hello,
after a few days of fruitless efforts, I thought of asking you all directly.

I need dnsmasq to send its queries to the upstream server via a different
route than everything else. I've tried adding the @interface parameter to
the --server option but I don't think I quite understand how it's supposed
to work.
Then I've attempted to mark the packets originating from the dnsmasq process
via the iptables owner module, also with little success.

Before I proceed any further with these experiments, I would like to know
whether I'm missing something, or if someone has found a different way to
do this.

Thanks


I think your question is: How do I configure dnsmasq on Linux to send
its upstream DNS queries using a specific route?

Here is GPT-4 answer:
https://urldefense.com/v3/__https://chat.openai.com/share/47fe1f23-57b6-4bbb-b51d-c4bf3818ef__;!!I9LPvj3b!BOetutoPDMZVnmN8eLyHRg_93gZ4QBXVK9yRGbAdpa0cFIkcjOvTnrwVxE7UDVbqoi1GyC1C38Fqgutf$
  df

And Bard answer: 
https://urldefense.com/v3/__https://g.co/bard/share/866e99f101bf__;!!I9LPvj3b!BOetutoPDMZVnmN8eLyHRg_93gZ4QBXVK9yRGbAdpa0cFIkcjOvTnrwVxE7UDVbqoi1GyC1C319ebuBN$

If I've got the question wrong provide the proper question and I'll ask

-- Wink


Hi Wink

The link to openai returns a 404. What is the answer it provided? (pure 
interest).


The bard answer looks to me like garbage. I don't think the parameters 
it refers to actually exist...


BR
Matthias


___
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 use non-default routing table

2023-09-22 Thread Matthias May via Dnsmasq-discuss

Hi Luigi

Strictly speaking this has nothing to do with dnsmasq, and is a question 
of how to do policy-routing.

I assume you're using linux since you mention iptables.

A good starting point for policy routing with linux is 
https://tldp.org/HOWTO/Adv-Routing-HOWTO/

respectively https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html

What i would do is to create a routing rule that redirects your frames 
to a separate routing table.


By the default the routing rules look like this:
# maym@Orpheus:~$ ip rule
# 0:    from all lookup local
# 32766:    from all lookup main
# 32767:    from all lookup default

You can create a new routing table (e.g table 100) that contains a 
different default gateway.

# maym@Orpheus:~$ sudo ip route add default via 10.0.8.99 table 100
# maym@Orpheus:~$ ip route show table 100
# default via 10.0.8.99 dev wlan0

Now create a routing rule that matches your traffic and calls the table 100:
# maym@Orpheus:~$ sudo ip rule add pref 100 iif lo proto 17 dport 53 
lookup 100

# maym@Orpheus:~$ ip rule
# 0:    from all lookup local
# 100:    from all iif lo dport 53 lookup 100 proto 17
# 32766:    from all lookup main
# 32767:    from all lookup default

Now all traffic originating:
from the device itself (iif lo)
with proto 17 (udp)
to the destination port 53 (dns)
will be directed to the routing table 100 which contains the default 
gateway to the router you want to use.


BR
Matthias

On 22/09/2023 15:10, Luigi Baldoni wrote:

   Hello,
after a few days of fruitless efforts, I thought of asking you all directly.

I need dnsmasq to send its queries to the upstream server via a different
route than everything else. I've tried adding the @interface parameter to
the --server option but I don't think I quite understand how it's supposed
to work.
Then I've attempted to mark the packets originating from the dnsmasq process
via the iptables owner module, also with little success.

Before I proceed any further with these experiments, I would like to know
whether I'm missing something, or if someone has found a different way to
do this.

Thanks


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://urldefense.com/v3/__https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss__;!!I9LPvj3b!B5ufkCPULSxnt3FjUe0ZvdgQYisVtbnoP_jvcsm9droDBts9Pe8Dsw2EuLsUBxoFy5MKDHvMZKv7X1_ueQ$


___
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 addresses are (almost) immediately deprecated

2023-09-22 Thread Graham Leggett via Dnsmasq-discuss
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?

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] IPv6 addresses are (almost) immediately deprecated

2023-09-22 Thread Graham Leggett via Dnsmasq-discuss
Hi all,

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”. 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?

The manual refers to a timeout which defaults to one day, and allows me to set 
it to a day, but I’m not sure it’s configured correctly.

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] Hello! Also, question about /etc/ethers and /etc/hosts

2023-09-13 Thread TRUNKLES via Dnsmasq-discuss
Hi, all!

So, this will be my first email to this mailing list, in other words, my only 
chance to make a first impression. I really hope it isn't a stupid one.

I'm running an Ubuntu 22.04.3 server on which I've been using isc-dhcp-server 
to service my local network, mostly because I'm old and it's the one I remember 
using back in the day. And it worked well enough, for what I wanted; setting 
aside a range of the subnet for dynamic IPs (mostly visitors) while also using 
static IPs outside of that range for more permanent devices. So I might not 
immediately remember what 192.168.111.47 is, but because it isn't between 
192.168.111.100 and 192.168.111.200, I know it's a device that's probably one 
I'm supposed to see on my local network, rather than something transient. Of 
course, some would say, having local DNS for this might make it easier. So, I 
thought ... yeah, it might, and dnsmasq seems perfect for that!

Obviously, I'm here, writing to you, because it isn't working like I wanted it 
to, which is a delicate way of saying, things really aren't working very well 
at all. I've reverted to isc-dhcp-server for now. I'm posting here for two 
reasons. Well, two that I can think of right now, maybe there are more and 
we'll think of them as we go along. ;-) But the two I have in mind are: 1) 
figure out how to make things work like I want them to, and 2) contribute back 
what I see as 'strange', so that those in the know might either say 'oh, that's 
expected when you do something as weird as you have been doing' or, more 
rewarding, if it were to happen, 'oh, that's not actually supposed to be 
possible, how'd you manage to get things quite so borked as that?'

I'd like to start by just asking a simple question I've not managed to find an 
answer to anywhere else: are /etc/ethers and /etc/hosts supposed to supersede 
dynamic IP allocaiton? Suppose I have all of my "known" devices (MAC addresses) 
in /etc/ethers, are those supposed to appear to dnsmasq as implicit 
--dhcp-host= declarations, to take precedence over dynamic host IP allocation 
as provided by --dhcp-range= statements in the conf file?

And as for the things that don't work at all part: As deployed, probably badly 
configured by me, dnsmasq is apparently recognising the /etc/ethers entry and 
matching it with /etc/hosts, because that shows up and looks good in 
/var/lib/misc/dnsmasq.leaes, but then, also allocating it a dynamic IP address, 
which results in entries like this:

1694633632 41:c4:b7:ff:16:a3 192.168.111.126 192.168.111.20 # media-server *

That not only looks wrong, but is wrong enough that if I stop dnsmasq and then 
restart it, it refuses to run until I've deleted that file. Clearly, I've done 
something terrible somewhere, but I still find it interesting that dnsmasq 
would produce a lease file that is so wrong that it segfaults upon trying to 
read it back upon restart.

Also, it's nice to meet you all!

Regards,
Sebastian Trunkles

Sent with [Proton Mail](https://proton.me/) secure email._______
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] multiple dhcp-options with the same tag

2023-09-09 Thread William Edwards via Dnsmasq-discuss

> Op 9 sep. 2023 om 07:19 heeft Wink Saville  het volgende 
> geschreven:
> 
> I'm learning dnsmasq and I'm taking advice from ChatGPT-4, probably a
> bad idea but so far it's given reasonable advice :)

How are you able to judge if advice is reasonable if you’re needing to ask for 
advice?

> 
> Anyway, in this instance I was asking a question[1] about how to
> configure dnsmasq on OpenWRT.
> 
> The first prompt was:
> 
> "Using Luci on openwrt is there a way to set a dhcp-option and use it
> on a dhcp-host record?"
> 
> It answered correctly that using luci you can't do it but you can do
> it in /etc/dnsmasq.conf and gave an example:
> 
> ```
> dhcp-host=00:11:22:33:44:55,set:myOptions,192.168.1.100
> dhcp-option=tag:myOptions,option:dns-server,192.168.1.2
> dhcp-option=tag:myOptions,option:router,192.168.1.1
> ```
> 
> My second prompt ends with the question:
> 
> "Anyway, your example shows that myOptions is composed of two separate
> dhcp-option's. Are you sure that is legal, can you provide me with a
> link or a quote from the dnsmasg.conf documentation?"
> 
> Its response was, as is typical. a long winded yes and it also gave me
> a quote from the documentation. Of course, I couldn't find that quote,
> which is also typical, it lies! Anyway, to cut to the chase I'm
> writing because the technique the bot showed does work, at least it
> seems to work for me on OpenWRT with dnsmasq v2.86. But, as I said I
> don't see in the documentation. Did I just miss it or should I not use
> it or maybe it should be documented?
> 
> -- Wink
> 
> [1]:https://chat.openai.com/share/cadee80b-4e3e-41e1-b95e-5fd62e799a9a
> 
> _______
> 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] Blockdata SIGSEGV on master

2023-09-01 Thread Dominik Derigs via Dnsmasq-discuss
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 /app/FTL/src/main.c:152


Best,
Dominik


chrome_fb.pcap
Description: application/vnd.tcpdump.pcap
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] DUID LL/LLT

2023-08-24 Thread Mateusz Pśnik via Dnsmasq-discuss
Hello,

is there any possibility to force either the LL or the LLT DUID type in the 
dnsmasq DHCPv6 server configuration?

The man page includes a "dhcp-duid" option but as far as I understand it allows 
only to set the DUID-EN type.
Is there any other option or some workaround that could help me in this case?

By the way, what is the type of the DUID generated automatically by dnsmasq?

Thanks,

Mateusz


Adtran Confidential
_______
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.service: Control process exited, code=exited, status=127/n/a

2023-07-10 Thread Andrew Miskell via Dnsmasq-discuss


> On Jul 10, 2023, at 3:34 PM, dnsmasqyq@neverbox.com wrote:
> 
> It's my own problem.
> 
> On Mon, Jul 10, 2023 at 3:57 PM Tong Sun wrote:
> 
>> Sure, but I'd like to rule out that it's because of my own *unusual* use
>> case, that my network device is not eth0 but br0 instead.
>> 
>> And it turns out to be exactly the root cause --
>> 
>> reverting from br0 to eth0 & reboot, then do the following
>> 
>> sudo apt install -y --reinstall dnsmasq-base dnsmasq
>> 
>> and it finished without any issue, while previously it was just impossible.
>> 
>> Ref, switching my network device from eth0 to br0 is done via following
>> https://linuxconfig.org/how-to-use-bridged-networking-with-libvirt-and-kvm
> 
> Hmm... redid my steps in a clean VM and it works just fine. So,
> 
>> I'm now more inclined to think it is dnsmasq's problem, not Debian
>> packaging's problem. Comments?
> 
> It's my own problem.
> 
> Sorry about the noise.
> 
> 
> _______
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Were you using a migrated configuration file or a fresh configuration file on 
the original VM? You might have had a configuration line which was telling 
dnsmasq to bind to a specific interface and that interface wasn’t available on 
the system.

I think by default, the configuration file in most packages don’t specify an 
interface to bind to, so dnsmasq will bind to all available interfaces.
_______
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] dhcp-vendorclass versus dhcp-option=vendor:

2023-07-07 Thread parasitid--- via Dnsmasq-discuss
hi,
we have a the following working setup to bootstrap servers using tfp which is 
based on vendor serial numbers to send devices specific files:(NOTE: we match 
on vendor class because we can't know the mac address at this stage)

lets say that device A has vendorclass AAA, and device B BBB and that 
corresponding tftp files are named AAA.tftp and BBB.tftp

dnsmasq.conf:
```... 
dhcp-vendorclass=AAA,AAAdhcp-option=AAA,67,AAA.tftpdhcp-vendorclass=BBB,BBBdhcp-option=BBB,67,BBB.tftp...```

this works perfectly fine, yet we would like to review our setup to be based on 
dhcp options only, so that we can benefit from the dhcp-optsdir inotify 
featureand add devices dynamically by writing the following files into the dhcp 
opts dir without having to restart the dnsmasq service:
AAA.conf:
```vendor:AAA,67,AAA.tftp
```and
 
BBB.conf:
```vendor:BBB,67,BBB.tftp
```
but it seems that the "vendor:*," doesn't match our vendorclass devices, 
whereas the same dhcp-vendorclass dnsmasq option does.
is this a bug or a bad comprehension of the "vendor:" dhcp option feature ?is 
there another way to achieve the same result (add devices conf without 
restarting dnsmasq) ?


thanks a lot.
best regards
yann

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


Re: [Dnsmasq-discuss] Why does the dnsmasq routing feature require a subnet prefix length of 64?

2023-06-20 Thread Rance Hall via Dnsmasq-discuss
Neal:

You aren’t the only one who thought the math was off with IPv6.

I had my issues, but for different reasons.  

Interesting read.

R

Sent from my iPhone

> On Jun 20, 2023, at 7:17 PM, imn...@gmail.com wrote:
> 
> I did some math a while back. IPv6 will 'never' run out of addresses? Hah! 
> It'll happen sooner than anyone thinks.
> 
>  - Assume 2^31 IPv6 LANs attached to the internet around the world.
>  - Compute 2^31 * 2^64 = 2^95 addresses assigned
>  - Assume 16 devices connected on each LAN: 2^31 * 2^4 = 2^35 addresses in use
> 
> Converting to decminal, about 40 * 10^27 addresses assigned, 34 * 10^9 
> addresses used. That leaves about 1.2 quintillion times the number of 
> addresses in use that will never be used.
> 
> Had they used /96 as the standard size (32-bit host address), that would've 
> resulted in about 2^63 addresses assigned for the same 2^35 addresses used. 
> The wastage would've dropped to about 270 million times the addresses used: 
> about 12 orders of magnitude less address wastage.
> 
> My opinion on this in more detail: http://murent.us/#ipv6wastage.
> 
> I read somewhere that some may be second-guessing that decision. They 
> might've done better to use /96 and hash the MAC address down to 24 bits to 
> make SLAAC work.
> 
> Neal
> 
> 
>> On Tue, 20 Jun 2023 15:05:07 -0700
>> Eric Fahlgren  wrote:
>> 
>> Yeah, some of the RFCs on v6 address formats hem and haw about how big the
>> network ID and interface ID parts are (probably written before actual
>> implementations were in place), but
>> https://www.rfc-editor.org/rfc/rfc4291#section-2.5.1 says quite
>> unequivocally:
>> 
>>   For all unicast addresses, except those that start with the binary
>>   value 000, Interface IDs are required to be 64 bits long...
>> 
>> Which drives a stake in the ground regarding how to partition those 128 bits.
>> 
>> 
>>> On Tue, Jun 20, 2023 at 11:59 AM Petr Menšík  wrote:
>>> 
>>> I think that is required by SLAAC RFC, which adds another 2 bytes to 6
>>> bytes of hardware ethernet address.
>>> 
>>> Which is in total 8 bytes, therefore 64 bits is required for it. Prefix
>>> cannot be higher, but can be lower in theory. There might be some
>>> implementation details now supporting lower prefix length in current
>>> implementation.
>>> 
>>> Cheers,
>>> Petr
>>>> On 15. 06. 23 12:07, renmingshuai via Dnsmasq-discuss wrote:
>>> 
>>> When ra-only, slaac, or ra-stateless is configured in dhcp-range and the
>>> prefix len is set to a value other than 64, like this:
>>> 
>>> “dhcp-range=2000:1000:1000:1000:1000:1000::, ra-stateless,120,infinite”
>>> 
>>> the following error message is displayed:
>>> 
>>> dnsmasq: prefix length must be exactly 64 for RA subnets at line 16 of
>>> /etc/dnsmasq.conf
>>> 
>>> Why must the prefix length be 64? This may come from an RFC regulation or
>>> recommendation, but I didn't find it. Would you mind tell me the reason?
>>> 
>>> --
>>> 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

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


[Dnsmasq-discuss] Static DHCP clients are not answered for in DNS requests

2023-06-16 Thread michalk via Dnsmasq-discuss
I am wanting to keep all of my configuration in the dnsmasq.conf file, 
therefor am not maintaining a separate hosts file.


For some machines that are not running a DHCP client, and therefore 
never request an IP lease, those machines will not be returned when 
dnsmasq is asked for name resolution.


In this example, "proxy" is a DHCP client machine, and "routerpi" is a 
static IP machine with no DHCP client installed.


root@routerpi:/etc# nslookup proxy
Server:        127.0.0.1
Address:    127.0.0.1#53

Non-authoritative answer:
*** Can't find proxy: No answer

root@routerpi:/etc# nslookup mediapi
Server:        127.0.0.1
Address:    127.0.0.1#53

Name:    mediapi
Address: 192.168.10.203

The entries in dnsmasq look like this:

dhcp-host=192.168.10.203,mediapi
dhcp-host=192.168.10.61,proxy

I have also tried the format that includes MAC addresses, but the result 
is the same:


# dhcp-host=dc:a6:32:4f:ce:4e,192.168.10.203,mediapi

And the log file contains:

dnsmasq: 147 127.0.0.1/53500 query[A] mediapi from 127.0.0.1
dnsmasq: 147 127.0.0.1/53500 DHCP mediapi is 192.168.10.203

dnsmasq: 171 127.0.0.1/56905 query[A] proxy from 127.0.0.1
dnsmasq: 171 127.0.0.1/56905 config proxy is NODATA-IPv4

How do I get the static IP hosts to be resolved?

This used to work, and I'm not sure what's changed.

--
Brian Michalk
Owner, Hasgrok.com, LLC.
512-699-4037
www.hasgrok.com


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


[Dnsmasq-discuss] Why does the dnsmasq routing feature require a subnet prefix length of 64?

2023-06-15 Thread renmingshuai via Dnsmasq-discuss
When ra-only, slaac, or ra-stateless is configured in dhcp-range and the prefix 
len is set to a value other than 64, like this:
"dhcp-range=2000:1000:1000:1000:1000:1000::, ra-stateless,120,infinite"
the following error message is displayed:
dnsmasq: prefix length must be exactly 64 for RA subnets at line 16 of 
/etc/dnsmasq.conf
Why must the prefix length be 64? This may come from an RFC regulation or 
recommendation, but I didn't find it. Would you mind tell me the reason?
_______
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] expose the stale and unanswered metrics through CHAOS records

2023-06-07 Thread Karavelov, Luben via Dnsmasq-discuss
On Wed, 2023-06-07 at 23:15 +0200, Geert Stappers wrote:
> 
> It misses
> 
> --- a/man/dnsmasq.8
> +++ b/man/dnsmasq.8
> @@ -2248,6 +2248,7 @@ Do not respond to class CHAOS and type TXT in domain 
> bind queries.
>  Without this option being set, the cache statistics are also available in the
>  DNS as answers to queries of class CHAOS and type TXT in domain bind. The 
> domain
>  names are cachesize.bind, insertions.bind, evictions.bind, misses.bind,
> +stale.bind, unanswered.bind,
>  hits.bind, auth.bind and servers.bind unless disabled at compile-time. An
>  example command to query this, using the
>  .B dig
> 
> 
> Regards
> Geert Stappers
> Mostly saying   "the patch has been seen"
> --
> Silence is hard to parse

Thanks for noticing the miss - I forgot about the man page.
Below is the fixed patch.

One related question. I noticed that in the DBUS servers stats
now we report also the average response latencies. If we want
to also expose them through CHAOS, should we extend the
existing "servers.bind" with another field, or should we
create a new name with the extended metrics?

Best regards,
luben

Adding two new chaos names:
- stale.bind
- unanswered.bind
that expose the dns_stale_answered and dns_unanswered metrics.
---
 man/dnsmasq.8 | 4 ++--
 src/cache.c   | 8 
 src/dnsmasq.h | 2 ++
 src/option.c  | 2 ++
 4 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 30429df..1036635 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -2247,8 +2247,8 @@ Do not respond to class CHAOS and type TXT in domain bind 
queries.
 
 Without this option being set, the cache statistics are also available in the
 DNS as answers to queries of class CHAOS and type TXT in domain bind. The 
domain
-names are cachesize.bind, insertions.bind, evictions.bind, misses.bind,
-hits.bind, auth.bind and servers.bind unless disabled at compile-time. An
+names are cachesize.bind, insertions.bind, evictions.bind, misses.bind, 
stale.bind,
+unanswered.bind, hits.bind, auth.bind and servers.bind unless disabled at 
compile-time. An
 example command to query this, using the
 .B dig
 utility would be
diff --git a/src/cache.c b/src/cache.c
index 1c0e250..daacbaa 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -1725,6 +1725,14 @@ int cache_make_stat(struct txt_record *t)
   break;
 #endif
 
+case TXT_STAT_STALE:
+  sprintf(buff+1, "%u", daemon->metrics[METRIC_DNS_STALE_ANSWERED]);
+  break;
+
+case TXT_STAT_UNANSWERED:
+  sprintf(buff+1, "%u", daemon->metrics[METRIC_DNS_UNANSWERED_QUERY]);
+  break;
+
 case TXT_STAT_SERVERS:
   /* sum counts from different records for same server */
   for (serv = daemon->servers; serv; serv = serv->next)
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 2f95c12..08e6888 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -380,6 +380,8 @@ struct naptr {
 #define TXT_STAT_HITS  5
 #define TXT_STAT_AUTH  6
 #define TXT_STAT_SERVERS   7
+#define TXT_STAT_STALE 8
+#define TXT_STAT_UNANSWERED9
 #endif
 
 struct txt_record {
diff --git a/src/option.c b/src/option.c
index 8322725..2b2705e 100644
--- a/src/option.c
+++ b/src/option.c
@@ -5947,6 +5947,8 @@ void read_opts(int argc, char **argv, char *compile_opts)
   add_txt("auth.bind", NULL, TXT_STAT_AUTH);
 #endif
   add_txt("servers.bind", NULL, TXT_STAT_SERVERS);
+  add_txt("stale.bind", NULL, TXT_STAT_STALE);
+  add_txt("unanswered.bind", NULL, TXT_STAT_UNANSWERED);
 }
 #endif
 
-- 
2.25.1

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


[Dnsmasq-discuss] [PATCH] expose the stale and unanswered metrics through CHAOS records

2023-06-07 Thread Karavelov, Luben via Dnsmasq-discuss
Adding two new CHAOS names:
- stale.bind
- unanswered.bind
that expose the dns_stale_answered and dns_unanswered metrics.
---
 src/cache.c   | 8 
 src/dnsmasq.h | 2 ++
 src/option.c  | 2 ++
 3 files changed, 12 insertions(+)

diff --git a/src/cache.c b/src/cache.c
index 1c0e250..daacbaa 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -1725,6 +1725,14 @@ int cache_make_stat(struct txt_record *t)
   break;
 #endif
 
+case TXT_STAT_STALE:
+  sprintf(buff+1, "%u", daemon->metrics[METRIC_DNS_STALE_ANSWERED]);
+  break;
+
+case TXT_STAT_UNANSWERED:
+  sprintf(buff+1, "%u", daemon->metrics[METRIC_DNS_UNANSWERED_QUERY]);
+  break;
+
 case TXT_STAT_SERVERS:
   /* sum counts from different records for same server */
   for (serv = daemon->servers; serv; serv = serv->next)
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 2f95c12..08e6888 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -380,6 +380,8 @@ struct naptr {
 #define TXT_STAT_HITS  5
 #define TXT_STAT_AUTH  6
 #define TXT_STAT_SERVERS   7
+#define TXT_STAT_STALE 8
+#define TXT_STAT_UNANSWERED9
 #endif
 
 struct txt_record {
diff --git a/src/option.c b/src/option.c
index 8322725..2b2705e 100644
--- a/src/option.c
+++ b/src/option.c
@@ -5947,6 +5947,8 @@ void read_opts(int argc, char **argv, char *compile_opts)
   add_txt("auth.bind", NULL, TXT_STAT_AUTH);
 #endif
   add_txt("servers.bind", NULL, TXT_STAT_SERVERS);
+  add_txt("stale.bind", NULL, TXT_STAT_STALE);
+  add_txt("unanswered.bind", NULL, TXT_STAT_UNANSWERED);
 }
 #endif
 
-- 
2.25.1

_______
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 DHCP Options for CAPPORT or RFC8908 [PATCH]

2023-05-30 Thread Florian Baaske via Dnsmasq-discuss
Hi Petr,

this might be true, but for the setup, I'm looking for the captive portal
service will be an appliance which is not able to talk to the DHCP service,
running on a different service. Thats why they need the information using
the provided URL.

BR
Florian

On Tue, May 30, 2023 at 3:26 PM Petr Menšík  wrote:

> I would expect the captive-portal service should be able to fetch
> low-level data from DHCP server doing the address assignment for it. It
> would guess the service is always operated by the same entity of they
> are cooperating. Very often they would be running on the same device. So
> mapping of IP to hwaddr or even DHCP options used should be possible. I
> think captive portal web server should be able to make dynamic responses
> based on who is asking. I expect using dhcp-script like libvirt does
> should allow the captive-portal service make customized responses with
> single URL. But the complexity would be at the web service, I think they
> are usually better prepared for that than DHCP services.
>
> On 5/26/23 17:27, Simon Kelley wrote:
> > 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.
> I think we should add a way to add RA options similar way to DHCP. I
> were looking at RFC 8781 PREF64, it does not define any related DHCPv6
> option. So instead of relying on re-using option6: for RA, could we add
> possibility to directly add --ra-option? Specification via dhcp-option
> is often okay, but not always. Ideally with ability to encode even
> unsupported option like dhcp can, making it ready for future options too.
> >
> > 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  >> <mailto:pemen...@redhat.com>> 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
> >>>
> >>>
> --
> 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] Two bugs with "server" ans "address" in case of CNAME cache and query[type=65]

2023-05-28 Thread Ivan Vanyushkin via Dnsmasq-discuss

Hello.

Config for "server" and "address" is not respected in case of CNAME 
cache or parallel request query[type=65].


dnsmasq v2.86, config:

server=/sydney.bing.com/1.0.0.1
address=/sydney.bing.com/::
ipset=/sydney.bing.com/my-list

Default nameserver: 8.8.8.8


1. Test some queries:

# dig A sydney.bing.com
sydney.bing.com.    2841    IN  CNAME 
sydney-bing-com.dual-a-0034.a-msedge.net.
sydney-bing-com.dual-a-0034.a-msedge.net. 30 IN CNAME 
dual-a-0034.a-msedge.net.

dual-a-0034.a-msedge.net. 30    IN  A   204.79.197.237
dual-a-0034.a-msedge.net. 30    IN  A   13.107.21.237

# dig  sydney.bing.com
sydney.bing.com.    0   IN      ::

Log:

Sun May 28 20:26:36 2023 daemon.info dnsmasq[1]: query[A] 
sydney.bing.com from 127.0.0.1
Sun May 28 20:26:36 2023 daemon.info dnsmasq[1]: forwarded 
sydney.bing.com to 1.0.0.1
Sun May 28 20:26:36 2023 daemon.info dnsmasq[1]: reply sydney.bing.com 
is 
Sun May 28 20:26:36 2023 daemon.info dnsmasq[1]: reply 
sydney-bing-com.dual-a-0034.a-msedge.net is 
Sun May 28 20:26:36 2023 daemon.info dnsmasq[1]: ipset add my-list 
204.79.197.237 dual-a-0034.a-msedge.net
Sun May 28 20:26:36 2023 daemon.info dnsmasq[1]: reply 
dual-a-0034.a-msedge.net is 204.79.197.237
Sun May 28 20:26:36 2023 daemon.info dnsmasq[1]: ipset add my-list 
13.107.21.237 dual-a-0034.a-msedge.net
Sun May 28 20:26:36 2023 daemon.info dnsmasq[1]: reply 
dual-a-0034.a-msedge.net is 13.107.21.237


Sun May 28 20:27:09 2023 daemon.info dnsmasq[1]: query[] 
sydney.bing.com from 192.168.1.143
Sun May 28 20:27:09 2023 daemon.info dnsmasq[1]: *_config 
sydney.bing.com is ::_*


— correct, as expected.


2. Resolve CNAME directly:

# dig  sydney-bing-com.dual-a-0034.a-msedge.net
sydney-bing-com.dual-a-0034.a-msedge.net. 150 IN CNAME 
dual-a-0034.a-msedge.net.

dual-a-0034.a-msedge.net. 150   IN   2620:1ec:c11::237

Log:

Sun May 28 20:27:25 2023 daemon.info dnsmasq[1]: query[] 
sydney-bing-com.dual-a-0034.a-msedge.net from 127.0.0.1
Sun May 28 20:27:25 2023 daemon.info dnsmasq[1]: forwarded 
sydney-bing-com.dual-a-0034.a-msedge.net to 8.8.8.8
Sun May 28 20:27:25 2023 daemon.info dnsmasq[1]: reply 
sydney-bing-com.dual-a-0034.a-msedge.net is 
Sun May 28 20:27:25 2023 daemon.info dnsmasq[1]: reply 
dual-a-0034.a-msedge.net is 2620:1ec:c11::237



3. Now repeat the test:

# dig A sydney.bing.com
sydney.bing.com.    3137    IN  CNAME 
sydney-bing-com.dual-a-0034.a-msedge.net.
sydney-bing-com.dual-a-0034.a-msedge.net. 48 IN CNAME 
dual-a-0034.a-msedge.net.

dual-a-0034.a-msedge.net. 48    IN  A   13.107.21.237
dual-a-0034.a-msedge.net. 48    IN  A   204.79.197.237

# dig  sydney.bing.com
sydney.bing.com.    3135    IN  CNAME 
sydney-bing-com.dual-a-0034.a-msedge.net.
sydney-bing-com.dual-a-0034.a-msedge.net. 46 IN CNAME 
dual-a-0034.a-msedge.net.

dual-a-0034.a-msedge.net. 143   IN   2620:1ec:c11::237

Log:

Sun May 28 21:20:52 2023 daemon.info dnsmasq[1]: query[A] 
sydney.bing.com from 127.0.0.1
Sun May 28 21:20:52 2023 daemon.info dnsmasq[1]: forwarded 
sydney.bing.com to 1.0.0.1
Sun May 28 21:20:52 2023 daemon.info dnsmasq[1]: reply sydney.bing.com 
is 
Sun May 28 21:20:52 2023 daemon.info dnsmasq[1]: reply 
sydney-bing-com.dual-a-0034.a-msedge.net is 
Sun May 28 21:20:52 2023 daemon.info dnsmasq[1]: ipset add my-list 
204.79.197.237 dual-a-0034.a-msedge.net
Sun May 28 21:20:52 2023 daemon.info dnsmasq[1]: reply 
dual-a-0034.a-msedge.net is 204.79.197.237
Sun May 28 21:20:52 2023 daemon.info dnsmasq[1]: ipset add my-list 
13.107.21.237 dual-a-0034.a-msedge.net
Sun May 28 21:20:52 2023 daemon.info dnsmasq[1]: reply 
dual-a-0034.a-msedge.net is 13.107.21.237


Sun May 28 21:20:54 2023 daemon.info dnsmasq[1]: query[] 
sydney.bing.com from 127.0.0.1
Sun May 28 21:20:54 2023 daemon.info dnsmasq[1]: _*cached 
sydney.bing.com is *_
Sun May 28 21:20:54 2023 daemon.info dnsmasq[1]: cached 
sydney-bing-com.dual-a-0034.a-msedge.net is 
Sun May 28 21:20:54 2023 daemon.info dnsmasq[1]: cached 
dual-a-0034.a-msedge.net is 2620:1ec:c11::237


— *incorrect!* Config defines static IPv6 address "::" that should be 
returned for  query. Maybe cached CNAME triggers the bug?



4. Sometimes I also see this in log:

Sun May 28 20:18:45 2023 daemon.info dnsmasq[405]: query[] 
sydney.bing.com from 192.168.1.143
Sun May 28 20:18:45 2023 daemon.info dnsmasq[405]: cached 
sydney.bing.com is 
Sun May 28 20:18:45 2023 daemon.info dnsmasq[405]: cached 
dual-a-0034.a-msedge.net is 2620:1ec:c11::237
Sun May 28 20:18:45 2023 daemon.info dnsmasq[406]: query[A] 
sydney.bing.com from 192.168.1.143
Sun May 28 20:18:45 2023 daemon.info dnsmasq[407]: query[type=65] 
sydney.bing.com from 192.168.1.143
Sun May 28 20:18:45 2023 daemon.info dnsmasq[407]: cached 
sydney.bing.com is 
Sun May 28 20:18:45 2023 daemon.info dnsmasq[406]: cached 
sydney.bing.com is 
Sun May 28 20:18:45 2023 daemon.info dnsmasq[407]

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

2023-05-26 Thread Florian Baaske via Dnsmasq-discuss
Hi Simon,

thanks for your reply.

The mac address is required by the CAPPORT implementation I would like to
use. I will not say that the mac address is always required when using
CAPPORT but for the selected implementation (Aruba ClearPass) it is
required.

Many thanks,
Florian



On Fri, May 26, 2023 at 6:21 PM Simon Kelley 
wrote:

> 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  > <mailto:pemen...@redhat.com>> 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   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>
> >
> > --
> > Petr Menšík
> > Software Engineer, RHEL
> > Red Hat,https://www.redhat.com/  <https://www.redhat.com/>
> > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> >
> > _______
> > 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
>
___
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 DHCP Options for CAPPORT or RFC8908 [PATCH]

2023-05-26 Thread Florian Baaske via Dnsmasq-discuss
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 
> listdnsmasq-disc...@lists.thekelleys.org.ukhttps://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] DNSMASQ DHCP Options for CAPPORT or RFC8908

2023-05-26 Thread Florian Baaske via Dnsmasq-discuss
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


Re: [Dnsmasq-discuss] Need help on configuring dnsmasq

2023-05-15 Thread public1020 via Dnsmasq-discuss
I came back. These two solutions worked for me:

- addn-hosts=/etc/dnsmasq-hosts

- host-record=example.com,1.2.3.4

Hopefully it would help someone.
--- Original Message ---
On Tuesday, May 9th, 2023 at 3:14 AM, Elisamuel Resto  wrote:

> What I do, which seems to work (for me):
>
> host-record=example.com/1.2.3.4
>
> Regards,
> -Sam
>
>> On May 7, 2023, at 23:01, public1020 via Dnsmasq-discuss 
>>  wrote:
>
>> 
>> I'm trying to use dnsmasq to hijackexample.com, but notapi.example.com, so I 
>> used the following configuration:
>>
>> address=/example.com/192.168.1.10
>>
>> However, dnsmasq also hijacks *.example.com to this IP address. Now how can 
>> I hijack only the specific address with 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] Filtering non-latin1 or non-ASCIII dns requests?

2023-05-11 Thread Dominik Derigs via Dnsmasq-discuss
Hey Burton and Petr,

On Wed, 2023-05-10 at 21:12 -0500, B@us wrote:
> domains that don’t match \.[A-Za-z0-9]\.

You'd probably want to allow for - and _ too but Petr has the better
idea how to achieve this:

On Thu, 2023-05-11 at 17:56 +0200, Petr Menšík wrote:
> reject all IDN names, which start with xn-- prefix

Even when truly non-ASCII domains would be possible (dig äöü), none of
the larger registrars allow registering such domains directly and will
always Punycode translation of the Unicode representation of the
language-specific alphabet.


Burton, the feature you are asking for would be blocking IDNA domains?

Petr, I concur that this should be handled at a larger scale, however, I
do also think it'd be okay to have such a feature when the administrator
of a local dnsmasq says that international domains aren't something that
will happen at their place and wants some extra protection against such
letter confusion "attacks".

Best
Dominik

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


  1   2   3   4   5   6   7   8   >