Re: [Dnsmasq-discuss] How to create /etc/resolv.conf after removing systemd-resolved?

2024-06-06 Thread Petr Menšík
Depends on how you use dnsmasq. If you use NetworkManager managed 
instance, it can create /etc/resolv.conf for you. Define dns=dnsmasq in 
NetworkManager.conf and restart the service. That's it!


Or just rm -f /etc/resolv.conf && sudoedit /etc/resolv.conf, manually.

On 04. 06. 24 11:10, Chris Green wrote:

I run dnsmasq instead of systemd-resolved on all my systems.

I have just built a new xubuntu 24.04 system and, having disabled
systemd-resolved and installed dnsmasq it appears to be working OK but
the /etc/resolv.conf symbolic link is broken, so there's no
/etc/resolv.conf which upsets some programs.

Should I just manually edit /etc/resolv.conf or is there some better
way of handling this?  All the systems in question just use dnsmasq
for local DNS cacheing and use the router at 192.168.1.1 for upstream
DNS queries.  Thus, on other systems on the LAN, I just have an
/etc/resolv.conf file as follows:-

 search zbmc.eu
 nameserver 127.0.0.1

Should I just create an /etc/resolv.conf like this for the new system?


No, there is no way on dnsmasq to manage /etc/resolv.conf. Just create 
it manually as normal file. Depends on if you use resolvconf or similar 
tool. At least on Fedora systemd-resolved tends to take 
/etc/resolv.conf, if it already does not exist on boot. So you need to 
create it as normal file to prevent it.


I suggest adding option ends0 trust-ad into it. Dnsmasq's TCP retry is 
somehow poor, using edns0 wherever it works will improve its 
performance. It should work on every sane network. Consider lowering 
timeout and increasing attempts. options timeout:3 attempts:3 or 
timeout:2 attempts:4 might work better. Dnsmasq retries are driven by 
external clients, caching should reduce issues with it when network works.


--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Support DNS cookies

2024-06-06 Thread Petr Menšík
SWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0298755806e389e7010065f2f100a7431d9cc031584a (good)
;; QUESTION SECTION:
;thekelleys.org.uk.   IN   A

;; ANSWER SECTION:
thekelleys.org.uk.   900   IN   A85.119.82.65

;; Query time: 39 msec
;; SERVER: 192.168.10.2#53(192.168.10.2) (UDP)
;; WHEN: Thu Mar 14 13:43:44 CET 2024
;; MSG SIZE  rcvd: 90

# dig +cookie=0298755806e389e7010065f2f100a7431d9cc031584a thekelleys.org.uk

; <<>> DiG 9.18.15 <<>> +cookie thekelleys.org.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36828
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0298755806e389e7010065f2f100a7431d9cc031584a (good)
;; QUESTION SECTION:
;thekelleys.org.uk.   IN   A

;; ANSWER SECTION:
thekelleys.org.uk.   859   IN   A85.119.82.65

;; Query time: 0 msec
;; SERVER: 192.168.10.2#53(192.168.10.2) (UDP)
;; WHEN: Thu Mar 14 13:44:25 CET 2024
;; MSG SIZE  rcvd: 90

# dig +cookie=0298755806e389e7010065f2f100a7431d9cc031584a 
thekelleys.org.uk @127.0.0.2
;; BADCOOKIE, retrying.

; <<>> DiG 9.18.15 <<>> +cookie thekelleys.org.uk @127.0.0.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37824
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0298755806e389e7010065f2f13eee4760ca63aa7570 (good)
;; QUESTION SECTION:
;thekelleys.org.uk.   IN   A

;; ANSWER SECTION:
thekelleys.org.uk.   838   IN   A85.119.82.65

;; Query time: 0 msec
;; SERVER: 127.0.0.2#53(127.0.0.2) (UDP)
;; WHEN: Thu Mar 14 13:44:46 CET 2024
;; MSG SIZE  rcvd: 90

Regards,
Tijs Van Buggenhout

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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, 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] [PATCH] Static analysis minor issue fixes

2024-05-31 Thread Petr Menšík

Hi!

As part of our review of dnsmasq code, our code scanning tools revealed 
few warnings. Some of them are valid, although it does fix only more or 
less cosmetic fixes. Potentially emitting warnings in tools like 
Coverity scan. 3 small changes attached.


Cheers,
Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

From 4bce87819b8df79a1a25c9eb79a83c9ce81d2ad5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Thu, 28 Mar 2024 00:54:38 +0100
Subject: [PATCH 3/3] Error: Y2K38_SAFETY (CWE-197):

dnsmasq-2.85/src/dhcp6.c:624: store_truncates_time_t: A ""time_t"" value is stored in an integer with too few bits to accommodate it.  The expression ""*((time_t *)parm)"" is cast to ""u32"".
  622| PUTSHORT(1, p); /* DUID_LLT */
  623| PUTSHORT(type, p); /* address type */
  624|->   PUTLONG(*((time_t *)parm), p); /* time */
  625|   }
  626|

Resolves: https://issues.redhat.com/browse/RHEL-30809
---
 src/dhcp6.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/dhcp6.c b/src/dhcp6.c
index c9d54dc..6e96dae 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -633,7 +633,6 @@ static int make_duid1(int index, unsigned int type, char *mac, size_t maclen, vo
   
   unsigned char *p;
   (void)index;
-  (void)parm;
   time_t newnow = *((time_t *)parm);
   
   if (type >= 256)
@@ -652,7 +651,8 @@ static int make_duid1(int index, unsigned int type, char *mac, size_t maclen, vo
   daemon->duid_len = maclen + 8;
   PUTSHORT(1, p); /* DUID_LLT */
   PUTSHORT(type, p); /* address type */
-  PUTLONG(*((time_t *)parm), p); /* time */
+  /* avoid warnings with 64bit time_t */
+  PUTLONG((newnow & 0xu), p); /* time */
 }
   
   memcpy(p, mac, maclen);
-- 
2.45.0

From 60a7c4a88c8ffd2b9818ae26289544b62a798747 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Wed, 27 Mar 2024 01:46:59 +0100
Subject: [PATCH 2/3] Error: UNINIT (CWE-457):

dnsmasq-2.85/src/edns0.c:272: var_decl: Declaring variable "encode" without initializer.
dnsmasq-2.85/src/edns0.c:289: uninit_use_in_call: Using uninitialized value "*encode" when calling "strlen".
  287|   }
  288|
  289|->   return add_pseudoheader(header, plen, limit, PACKETSZ, EDNS0_OPTION_NOMDEVICEID, (unsigned char *)encode, strlen(encode), 0, replace);
  290|   }

Resolves: https://issues.redhat.com/browse/RHEL-30804
---
 src/edns0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/edns0.c b/src/edns0.c
index 598478f..93a5ce3 100644
--- a/src/edns0.c
+++ b/src/edns0.c
@@ -270,6 +270,7 @@ static size_t add_dns_client(struct dns_header *header, size_t plen, unsigned ch
   int replace = 0, maclen = 0;
   unsigned char mac[DHCP_CHADDR_MAX];
   char encode[18]; /* handle 6 byte MACs ONLY */
+  *encode = 0;
 
   if ((option_bool(OPT_MAC_B64) || option_bool(OPT_MAC_HEX)) && (maclen = find_mac(l3, mac, 1, now)) == 6)
 {
-- 
2.45.0

From 08728eefef7f70b5a7571e3c70050dee6e8265c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Thu, 28 Mar 2024 00:42:08 +0100
Subject: [PATCH 1/3] Error: UNINIT (CWE-457):

dnsmasq-2.85/src/forward.c:65: var_decl: Declaring variable ""p"" without initializer.
dnsmasq-2.85/src/forward.c:69: uninit_use_in_call: Using uninitialized value ""p"". Field ""p.ipi_addr"" is uninitialized when calling ""memcpy"". [Note: The source code implementation of the function has been overridden by a builtin model.]
   67| p.ipi_spec_dst = source->addr4;
   68| msg.msg_controllen = CMSG_SPACE(sizeof(struct in_pktinfo));
   69|->   memcpy(CMSG_DATA(cmptr), , sizeof(p));
   70| cmptr->cmsg_len = CMSG_LEN(sizeof(struct in_pktinfo));
   71| cmptr->cmsg_level = IPPROTO_IP;

Resolves: https://issues.redhat.com/browse/RHEL-30809
---
 src/forward.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/forward.c b/src/forward.c
index 10e7496..95e5ae8 100644
--- a/src/forward.c
+++ b/src/forward.c
@@ -68,9 +68,10 @@ int send_from(int fd, int nowild, char *packet, size_t len,
   if (to->sa.sa_family == AF_INET)
 	{
 #if defined(HAVE_LINUX_NETWORK)
-	  struct in_pktinfo p;
-	  p.ipi_ifindex = 0;
-	  p.ipi_spec_dst = source->addr4;
+	  struct in_pktinfo p = {
+	.ipi_ifindex = 0,
+	.ipi_spec_dst = source->addr4,
+	  };
 	  msg.msg_controllen = CMSG_SPACE(sizeof(struct in_pktinfo));
 	  memcpy(CMSG_DATA(cmptr), , sizeof(p));
 	  cmptr->cmsg_len = CMSG_LEN(sizeof(struct in_pktinfo));
-- 
2.45.0



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


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] dnsmasq

2024-05-07 Thread Petr Menšík

Hi!

Depends on what you mean by full-fledged. The --auth-zone support should 
be enough for simple things. Of course running BIND9 provides you much 
more features with better performance under heavy load, but also with 
much higher resources used. Depends on what are your use cases. For 
simple static zone it should work well enough.


Of course it is somehow limited. It can serve typical records, define 
SOA values, even define secondary servers allowed to AXFR. On demand 
dynamic updates are *not* supported. It can work together with DHCP, but 
depends a lot what you are trying to accomplish. Since that were not 
shared, it depends.


I doubt you can use --auth-zone without recursive cache part, if that is 
what you were asking.


Cheers,
Petr

On 4/15/24 15:44, Turritopsis Dohrnii Teo En Ming via Dnsmasq-discuss wrote:

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


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


Re: [Dnsmasq-discuss] NXDOMAIN entries in addn-host file

2024-05-07 Thread Petr Menšík
I think that can be already specified by --server-file. Each domain 
would be listed as --server=/blocked.example.net/, which implements just 
--local= option. Of course that requires some decoration around just 
list of domains. It is not possible to load just domain per line file 
into dnsmasq.



You can also use --conf-script to generate blocklist. I think 
server-file can reload updated information after SIGHUP received. I 
doubt conf-script can do the same, although the example in man page uses 
blocklist definition. But have not verified that myself.



Cheers,
Petr


On 5/7/24 13:14, Steffen Greber wrote:
I know in the addn-host you can specify additional hosts files. It 
would be great to extend the syntax, so we can block some domains 
(ipv4 and ipv6).
Currently I add some domains with 127.0.0.1 or 0.0.0.0 to blacklist 
them but it seams not to be really the same than be resolved to 
NXDOMAIN, since (some) tools try then to connect to the specified ips.
The background is, I have some services running on a local machine. An 
entry in the addnhost file is only done if the service is running. So, 
if now a service dies (or is deactivated) and another service tries to 
resolve it by its name, the ip can not be resolved locally and the 
request it forwarded to the upstream resolver (which in my case leads 
to a security issue).


A other solution would be to use the *bogus-nxdomain* so I can map my 
services to a specify ip and define it as a bogus-nxdomain. But this 
option seems not to be working with domains defined in the addn-hosts 
files.



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


--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] dnsmasq 2.90 reply truncated

2024-04-08 Thread Petr Menšík
Are you sure DNS over TCP were disabled by default? Were it not some 
local applied policy?


TCP is mandatory for a long time, I am not even sure it ever was just 
optional. Can you share where this is set and where it can be checked, 
whether TCP is enabled already?


Great test examples are:

- nslookup -type=txt google.com
- nslookup -type=txt cisco.com

On 3/19/24 08:36, Adam Pribyl wrote:

Seems the problem is solved by allowing a DNS over TCP for clients.

While inability to forward larger EDNS querries ove UDS in 2.90 is 
certainly a change, I understand that dnsmasq is now following the DNS 
flag day suggestion instead RFC.


I'd like to still point out, that the --edns-packet-max option does 
not workaround the problem for me as dnsmasq "shrinks" the value to 
the 1232 even this is set larger.


Regards

Adam Pribyl



On Mon, 18 Mar 2024, Adam Pribyl wrote:



I tried to increase the --edns-packet-max=1450, did not work, set it 
to 2048 now resolution seems to work. Interestingly only temporarily, 
because this appears in the dnsmasq log soon


 reducing DNS packet size for nameserver 10.101.255.253 to 1232

and the resolution is not working again.

So it seems this is related to that change in dnsmasq and Windows 
name resolution as with Linux clients there is no problem, but even 
using this option does not fix the problem as for some reason dnsmasq 
decides to override the override..


Still it is not obvious to me, what edns packet size was used in 
dnsmasq before 2.90 version.


Adam Pribyl



On Tue, 12 Mar 2024, Adam Pribyl wrote:

In this case the query is from Windows 10 machine->dnsmasq server on 
Fedora 38 forwards to -> bind on debian.


The result on Windows nslookup

Server: UnKnown
Address: 192.168.34.1

*** UnKnown can't find login.microsoftonline.com: Unspecified error

In dnsmasq there is this "reply is truncated" for this forwarded query.

I do not think the problem is the Windows client, because from the 
time I downgraded the dnsmasq on Fedora to 2.89, I did not get any 
"reply is truncated" dnsmasq log message anymore.


I can not judge if client should do anything else in this case thou..

Adam Pribyl


On Tue, 12 Mar 2024, Petr Menšík wrote:

The response seems correct and acceptable in size. It should not 
truncate, at least what I see. It should also retry with TCP when 
truncated reply arrives. I have verified even last release works 
with dig. Dnsmasq does not do tcp query by itself, it expects 
client to do TCP query. What client do you use?


$ dig login.microsoftonline.com a

; <<>> DiG 9.18.24 <<>> login.microsoftonline.com a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20188
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 3 (Stale Answer)
;; QUESTION SECTION:
;login.microsoftonline.com.    IN    A

;; ANSWER SECTION:
login.microsoftonline.com. 10360 IN    CNAME login.mso.msidentity.com.
login.mso.msidentity.com. 30    IN    CNAME 
ak.privatelink.msidentity.com.
ak.privatelink.msidentity.com. 30 IN    CNAME 
www.tm.ak.prd.aadg.trafficmanager.net.

www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 40.126.31.71
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 20.190.159.0
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 20.190.159.68
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 20.190.159.71
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 20.190.159.73
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 20.190.159.75
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 40.126.31.67
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A 40.126.31.69

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Mar 12 10:07:36 CET 2024
;; MSG SIZE  rcvd: 303

I have tried dig +ignore +noedns -t txt on google.com or cisco.com. 
If client does not retry, it gets no response. If it does, it does. 
It seems to work as intended.


If might help querying your bind server by dig @10.101.255.253 txt 
ch version.bind. But I suspect the problem is in client incorrectly 
omitting TCP query retry. Is it glibc program? Can you tell us more 
about client program making those queries?


Cheers,
Petr

On 3/11/24 09:27, Adam Pribyl wrote:
After upgrade of dnsmasq 2.89 to dnsmasq-2.90-1.fc38.x86_64 I 
started to notice, that some queries won't resolve when asked thru 
dnsmasq, but work asked directly to upstream nameserver.


I found that certain queries forwarded to anycast bind nameservers 
return only a "reply is truncated" message and no record.


Mar 11 07:30:05 server dnsmasq[4054056]: query[A] 
login.microsoftonline.com from 192.168.34.194
Mar 11 07:30:05 server dnsmasq[4054056]: forwarded 
login.microsoftonline.com to 10.101.255.253

Mar 11 07:30:05 server dnsmasq[4054056]: reply is truncated

Downgrading to dnsmasq-2.89-1.fc38.x86_64 seems to solve the problem.

The respo

Re: [Dnsmasq-discuss] RFC 2136 DNS Update?

2024-04-04 Thread Petr Menšík
I thought about it very similar way. Yes, SLAAC clients even on trusted 
network have absolutely no good way to make their own name registered 
and recognized similar way as DHCP clients have. Yes, it would first 
have to start on client side to even try to attempt to register the name.


I would like this configurable via Network Manager, which should provide 
way to send name registration on trusted network, but stay as anonymous 
as possible on public networks like mass transit, hotels, conferences or 
airports.


sssd already has some support for sending name updates. I think we need 
two things:


- indication from the network, likely an router advertisement extension, 
indicating router is willing to update names without strong authentication


- client reacting to it if allowed by machine owner/administrator. We do 
not want network on train to tell our laptops to reveal its name. sssd 
or nsupdate backed scripts might work.


- acceptance at dnsmasq with updates requested. It might be restricted 
to --auth-zone. There is no authentication involved in dnsmasq even in 
DHCP case. So this is not significantly less secure.


I am old enough to know Windows 2000 once did that on any network they 
connected. I think unconditionally. It were quite annoying to see logged 
attempts refused in common bind installation. But I think we want 
something like that for ipv6, but tuned up. Those addresses are even 
less friendly to type.


The only problem I see is DHCP requires multiple packets to confirm 
source address and insert the name. Single update DNS packet doing the 
same does not allow checking source address validity.


Should it be allowed only over TCP?

I general I would like that too. Not sure how fast I can prepare some 
proposal, by queue is getting long already.


On 20. 03. 24 21:48, Ronan Pigott via Dnsmasq-discuss wrote:

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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


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] How to get dnsmasq to see changes in files in /etc/dnsmasq.d?

2024-04-04 Thread Petr Menšík
Normal conf-file or conf-dir is not re-read upon receiving SIGHUP 
signal. You would have to use special servers-file for that. If you 
explicitly add your blacklist using 
servers-file=/etc/dnsmasq.d/blacklist.conf, it should be able to read 
that blacklist again. I am afraid there is no servers-dir variant, which 
might watch for file changes automatically.


On 25. 03. 24 20:26, Chris Green wrote:

Is there a way (other than restarting dnsmasq) to get it to notice
changes to files in /etc/dnsmasq.d?

I have a blacklist file which I put in /etc/dnsmasq.d and, obviously,
when the file is updated I want dnsmasq to notice any changes in the
file.


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] dnsmasq & DDNS

2024-04-04 Thread Petr Menšík

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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] dnsmasq 2.90 reply truncated

2024-03-12 Thread Petr Menšík
The response seems correct and acceptable in size. It should not 
truncate, at least what I see. It should also retry with TCP when 
truncated reply arrives. I have verified even last release works with 
dig. Dnsmasq does not do tcp query by itself, it expects client to do 
TCP query. What client do you use?


$ dig login.microsoftonline.com a

; <<>> DiG 9.18.24 <<>> login.microsoftonline.com a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20188
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 3 (Stale Answer)
;; QUESTION SECTION:
;login.microsoftonline.com.    IN    A

;; ANSWER SECTION:
login.microsoftonline.com. 10360 IN    CNAME login.mso.msidentity.com.
login.mso.msidentity.com. 30    IN    CNAME ak.privatelink.msidentity.com.
ak.privatelink.msidentity.com. 30 IN    CNAME 
www.tm.ak.prd.aadg.trafficmanager.net.

www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A    40.126.31.71
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A    20.190.159.0
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A    20.190.159.68
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A    20.190.159.71
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A    20.190.159.73
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A    20.190.159.75
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A    40.126.31.67
www.tm.ak.prd.aadg.trafficmanager.net. 30 IN A    40.126.31.69

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Mar 12 10:07:36 CET 2024
;; MSG SIZE  rcvd: 303

I have tried dig +ignore +noedns -t txt on google.com or cisco.com. If 
client does not retry, it gets no response. If it does, it does. It 
seems to work as intended.


If might help querying your bind server by dig @10.101.255.253 txt ch 
version.bind. But I suspect the problem is in client incorrectly 
omitting TCP query retry. Is it glibc program? Can you tell us more 
about client program making those queries?


Cheers,
Petr

On 3/11/24 09:27, Adam Pribyl wrote:
After upgrade of dnsmasq 2.89 to dnsmasq-2.90-1.fc38.x86_64 I started 
to notice, that some queries won't resolve when asked thru dnsmasq, 
but work asked directly to upstream nameserver.


I found that certain queries forwarded to anycast bind nameservers 
return only a "reply is truncated" message and no record.


Mar 11 07:30:05 server dnsmasq[4054056]: query[A] 
login.microsoftonline.com from 192.168.34.194
Mar 11 07:30:05 server dnsmasq[4054056]: forwarded 
login.microsoftonline.com to 10.101.255.253

Mar 11 07:30:05 server dnsmasq[4054056]: reply is truncated

Downgrading to dnsmasq-2.89-1.fc38.x86_64 seems to solve the problem.

The response for login.microsoftonline.com is a long one.

In the dnsmasq changelog I found, there were some changes with edns 
max size, but I can not find the commit to find out what was there 
before, to set the --edns-packet-max.


The general question would be - what is the correct DNS setup then? I 
probably need to change the bind config, as I do not want to fix every 
dnsmasq "client" in the network.


Thanks

Adam Pribyl



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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] Upgrade to [x]ubuntu 23.10 means dnsmasg can't read /run/NetworkManager

2024-02-09 Thread Petr Menšík
I would consider it a bug and it should be reported to distribution 
bugtracker (launchpad?).


We have something similar and I admit there are different SELinux 
contexts assigned for those files.


$ LANG=C.UTF-8 ls -lZ /run/NetworkManager/*resolv.conf
-rw-r--r--. 1 root root system_u:object_r:NetworkManager_var_run_t:s0 
281 Feb  9 13:29 /run/NetworkManager/no-stub-resolv.conf
-rw-r--r--. 1 root root system_u:object_r:net_conf_t:s0   
281 Feb  9 13:29 /run/NetworkManager/resolv.conf


I think Ubuntu is using AppArmor instead, but anyway. I do not think 
this file is meant to be private or has any good reason to be. That 
should be read-only for any service needing that information.


Similar files are produced by systemd-resolved:

# ls -lZ /run/systemd/resolve/*resolv.conf
-rw-r--r--. 1 systemd-resolve systemd-resolve 
unconfined_u:object_r:user_tmp_t:s0 788 Feb  9 13:48 
/run/systemd/resolve/resolv.conf
-rw-r--r--. 1 systemd-resolve systemd-resolve 
unconfined_u:object_r:user_tmp_t:s0 920 Feb  9 13:48 
/run/systemd/resolve/stub-resolv.conf


Which should be readable by other services as well.

Fill a bug for your distribution please.

On 12/14/23 23:46, Chris Green wrote:

Up until now I have the following in my /etc/dnsmasq.conf:-

 resolv-file=/run/NetworkManager/no-stub-resolv.conf

This means that dnsmasq uses the upstream DNS that Network Manager
configures.  When I'm on the local LAN this resolves to 'my' DNS
server at 192.168.1.2, when I'm connected somewhere else Network
Manager sorts things out accordingly and dnsmasq gets the right
upstream DNS server.

However the latest Ubuntu update has tightened the permissions on
/etc/NetworkManager and dnsmasq can't read the file
/run/NetworkManager/no-stub-resolv.conf.

I know this is a slightly non-standard configuration but it has worked
very nicely for me for some years.  Can anyone suggest a way to fix
this?   Obviously /run/NetworkManager/no-stub-resolv.conf is created
at every boot so the permissions will revert to 'too strict' every
time I start the system.


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


Re: [Dnsmasq-discuss] Don't set up inotify watch on resolv.conf if --port=0

2024-02-08 Thread Petr Menšík
This is merged by 
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=762a3f243099d26b1e87aad2b1b4b696cd8c33ac


Simon has added description for it.

On 06. 02. 24 0:15, Heikki Linnakangas wrote:

On 05/02/2024 22:52, Geert Stappers wrote:

On Mon, Feb 05, 2024 at 08:47:54PM +0200, Heikki Linnakangas wrote:

diff --git a/src/inotify.c b/src/inotify.c
index a944c62..0c775de 100644
--- a/src/inotify.c
+++ b/src/inotify.c
@@ -94,7 +94,7 @@ void inotify_dnsmasq_init()
    if (daemon->inotifyfd == -1)
  die(_("failed to create inotify: %s"), NULL, EC_MISC);
  -  if (option_bool(OPT_NO_RESOLV))
+  if (daemon->port == 0 || option_bool(OPT_NO_RESOLV))


Nice and clean


Thanks!


diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index ce897ae..5520511 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -429,8 +429,8 @@ int main (int argc, char **argv)
  }
    #ifdef HAVE_INOTIFY
-  if ((daemon->port != 0 || daemon->dhcp || daemon->doing_dhcp6)
-  && (!option_bool(OPT_NO_RESOLV) || daemon->dynamic_dirs))
+  if ((daemon->port != 0 && !option_bool(OPT_NO_RESOLV))
+  || ((daemon->dhcp || daemon->doing_dhcp6) && 
daemon->dynamic_dirs))


Mmm, not so clean.  So I didn't give it further attention.


The point is to avoid calling inotify_init1() and creating an inotify 
fd, if inotify is not used. My thinking was that inotify is used for 
two things:


1. To watch for resolv_files. Only if port != 0 and --no-resolv was 
not given.
2. To watch for dhcp-hostsdir, dhcp-optsdir and hostsdir. Only if DHCP 
is enabled.


Hmm, I think I got 2. wrong: the --hostsdir option also affects DNS 
replies. I'm not sure what exactly the conditions here should be. This 
is one alternative:


  if ((daemon->port != 0 && !option_bool(OPT_NO_RESOLV))
  || daemon->dynamic_dirs)

But that'd still create the inotify fd unnecessarily e.g if you 
specify --dhcp-optsdir but no --dhcp-range. (Admittedly that's a silly 
combination.)


- Heikki


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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


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

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


I would prefer sending just A or  queries, whatever from them comes 
first. Or maybe excluding other types and using just A and  records, 
if they are in cache. Reference 4.3 
<https://www.rfc-editor.org/rfc/rfc8482#section-4.3>. Alternatively do 
what unbound does, return NOTIMPL error.


Shown localhost example:

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

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

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

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


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

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

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


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


I disagree with current proposal.

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

RFC 8482


--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


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


[Dnsmasq-discuss] [PATCH] Easier custom lua version

2024-01-24 Thread Petr Menšík

Hello!

I have just noticed bump of lua in Makefile. A bit problem is our 
Fedora's lua-devel does not provide versioned pkg-config lua5.4. Instead 
it provides just lua. Attached change makes it simple to customize used 
lua pkg-config to overcome that limitation. Default stays the same, but 
customization can be done just by make COPTS='-DHAVE_LUASCRIPT' LUA=lua.


Cheers,
Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

From 2de2259472d64d36221bd7ab0efe03f4501f8620 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Wed, 24 Jan 2024 11:28:38 +0100
Subject: [PATCH] Make lua version more easy to customize

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

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

diff --git a/Makefile b/Makefile
index 4c5401e..7a6aac6 100644
--- a/Makefile
+++ b/Makefile
@@ -36,6 +36,7 @@ LIBS  =
 
 PKG_CONFIG = pkg-config
 INSTALL= install
+LUA= lua5.4
 MSGMERGE   = msgmerge
 MSGFMT = msgfmt
 XGETTEXT   = xgettext
@@ -60,8 +61,8 @@ idn2_cflags =   `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LIBIDN2 $(PKG_CONFI
 idn2_libs = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LIBIDN2 $(PKG_CONFIG) --libs libidn2`
 ct_cflags = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_CONNTRACK $(PKG_CONFIG) --cflags libnetfilter_conntrack`
 ct_libs =   `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_CONNTRACK $(PKG_CONFIG) --libs libnetfilter_conntrack`
-lua_cflags =`echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LUASCRIPT $(PKG_CONFIG) --cflags lua5.4` 
-lua_libs =  `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LUASCRIPT $(PKG_CONFIG) --libs lua5.4` 
+lua_cflags =`echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LUASCRIPT $(PKG_CONFIG) --cflags $(LUA)`
+lua_libs =  `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_LUASCRIPT $(PKG_CONFIG) --libs $(LUA)`
 nettle_cflags = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_DNSSEC $(PKG_CONFIG) --cflags 'nettle hogweed' \
 HAVE_CRYPTOHASH $(PKG_CONFIG) --cflags nettle \
 HAVE_NETTLEHASH $(PKG_CONFIG) --cflags nettle`
-- 
2.43.0



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


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

2024-01-09 Thread Petr Menšík

Kind reminder for this change.

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


Cheers,
Petr

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


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


Simon.


--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


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


[Dnsmasq-discuss] [PATCH] HTTPS and SVCB RFC update

2024-01-03 Thread Petr Menšík
Sending update of HTTPS and SVCB dns records. There is still no 
straightforward way to serve such records from dnsmasq (except 
--dns-rr), but at least update reference to final RFC it were assigned 
to it.


Happy new year everyone!

Cheers,
Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

From 0379ea46fc50617379185be9e45d42b189f14361 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Tue, 2 Jan 2024 23:36:53 +0100
Subject: [PATCH] Update references for HTTPS and SVBC records

RFC 9460 were assigned to draft-ietf-dnsop-svcb-https final version 12.
Change stored reference to final spec. Numbers have not changed, just
comment changes.
---
 src/cache.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/cache.c b/src/cache.c
index 07f81ad..b088b24 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -99,8 +99,8 @@ static const struct {
   { 61,  "OPENPGPKEY" }, /* OpenPGP Key [RFC7929] OPENPGPKEY/openpgpkey-completed-template 2014-08-12*/
   { 62,  "CSYNC" }, /* Child-To-Parent Synchronization [RFC7477] 2015-01-27*/
   { 63,  "ZONEMD" }, /* Message Digest Over Zone Data [RFC8976] ZONEMD/zonemd-completed-template 2018-12-12*/
-  { 64,  "SVCB" }, /* Service Binding [draft-ietf-dnsop-svcb-https-00] SVCB/svcb-completed-template 2020-06-30*/
-  { 65,  "HTTPS" }, /* HTTPS Binding [draft-ietf-dnsop-svcb-https-00] HTTPS/https-completed-template 2020-06-30*/
+  { 64,  "SVCB" }, /* Service Binding [RFC9460] SVCB/svcb-completed-template 2023-11-06*/
+  { 65,  "HTTPS" }, /* HTTPS Binding [RFC9460] HTTPS/https-completed-template 2023-11-06 */
   { 99,  "SPF" }, /* [RFC7208] */
   { 100, "UINFO" }, /* [IANA-Reserved] */
   { 101, "UID" }, /* [IANA-Reserved] */
-- 
2.43.0



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


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


[Dnsmasq-discuss] [PATCH] Allow dns-rr type specified by name

2023-12-25 Thread Petr Menšík

Hello,

I were pointed to [1] article on fosstodon discussion and I have noticed 
it does accept only numeric type value. But on other places we accept 
also nicer symbolic names. I have made a simple change to allow also 
type name to be specified. Not sure about wording in man page, if you 
could find clearer notation, I would be glad.


Happy new year!

1. 
https://forum.openwrt.org/t/resolving-query-type-65-to-local-address-for-ios-clients-in-dnsmasq/179504


Cheers,
Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 490ae2290b243fe0f7c6bf963d96039a2d1c17ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Mon, 25 Dec 2023 22:40:33 +0100
Subject: [PATCH] Allow specification of dns-rr record type by name

Use existing database of record types and support them instead of just
integer numbers for --dns-rr. Allows specification like
dns-rr=example.net,SVCB. Unknown record types are refused, but original
style dns-rr=example.net,64 still works.

Update man page to match document it.
---
 man/dnsmasq.8 | 10 +-
 src/option.c  | 14 --
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 1b5ebda..b055795 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -731,11 +731,11 @@ If the time-to-live is given, it overrides the default, which is zero
 or the value of \fB--local-ttl\fP. The value is a positive integer and gives
 the time-to-live in seconds.
 .TP
-.B --dns-rr=,,[]
-Return an arbitrary DNS Resource Record. The number is the type of the
-record (which is always in the C_IN class). The value of the record is
-given by the hex data, which may be of the form 01:23:45 or 01 23 45 or
-012345 or any mixture of these.
+.B --dns-rr=,,[]
+Return an arbitrary DNS Resource Record. The RR-type is the type of the
+record in an integer or a name form (which is always in the C_IN class).
+The value of the record is given by the hex data, which may be of
+the form 01:23:45 or 01 23 45 or 012345 or any mixture of these.
 .TP
 .B --interface-name=,[/4|/6]
 Return DNS records associating the name with the address(es) of
diff --git a/src/option.c b/src/option.c
index 3eeda18..520b212 100644
--- a/src/option.c
+++ b/src/option.c
@@ -766,6 +766,16 @@ static int atoi_check16(char *a, int *res)
   return 1;
 }
 
+static int atoi_or_rrtype(char *a, int *res)
+{
+  if (!atoi_check16(a, res))
+{
+  *res = rrtype(a);
+  return (*res != 0);
+}
+  return 1;
+}
+
 #ifdef HAVE_DNSSEC
 static int atoi_check8(char *a, int *res)
 {
@@ -3508,7 +3518,7 @@ static int one_opt(int option, char *arg, char *errstr, char *gen_err, int comma
 	else
 	  {
 	comma = split(arg);
-	if (!atoi_check(arg, ) && (type = rrtype(arg)) == 0)
+	if (!atoi_or_rrtype(arg, ))
 	  ret_err(_("bad RR type"));
 	  }
 	
@@ -4992,7 +5002,7 @@ err:
 	new = opt_malloc(sizeof(struct txt_record));
 	new->name = NULL;
 	
-	if (!atoi_check(comma, ) || 
+	if (!comma || !atoi_or_rrtype(comma, ) ||
 	!(new->name = canonicalise_opt(arg)) ||
 	(data && (len = parse_hex(data, (unsigned char *)data, -1, NULL, NULL)) == -1U))
   {
-- 
2.43.0

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


[Dnsmasq-discuss] FOSDEM 2024

2023-12-13 Thread Petr Menšík

Hello!

I have offered presentation on upcoming FOSDEM 2024 DNS room and was 
accepted. Unless something changes unexpectedly, I would be again on the 
conference 3rd and 4th of February in Brussels. I would like to meet 
anyone involved in dnsmasq (or any other open-source product) if the 
time will allow.


Is anyone involved planning to be there as well?

https://fosdem.org/2024/schedule/track/dns/

Cheers,
Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


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] DNSMasq as secondary server

2023-12-13 Thread Petr Menšík
I would suggest using some prefix for internal names anyway. I tend to 
use something like in.example.net for internal (private) networks, where 
example.net contains only public records. Such config can work with 
DNSSEC for example and makes it easier to debug what is defined on which 
network.


I think dnsmasq acting as local server should override all names defined 
locally, so it should work like you have described. Even for dynamically 
connected hosts using DHCP. If it defines names in dnsmasq, it answers 
instead of forwarding. Just ensure you define local=/somedomain.com/ to 
prevent forwarding queries to your zone, which is not defined inside 
your zone. auth-zone=somedomain.com should also work. That forwards all 
names undefined names, except it generates NXDOMAIN responses for names 
in the domain it does not define.


Hope that helps. Your description is kind of hard to understand, more 
detailed examples might help. Of course what you have tried already and 
what works and what does not would help much more.


Cheers,
Petr

On 12/13/23 17:28, Michel DIEMER via Dnsmasq-discuss wrote:

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


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

2023-11-30 Thread Petr Menšík

Hello!

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


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


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


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


What do you think?

Looking for any feedback!

Regards,
Petr

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

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

--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

From fa6c187cb12d275b6cffc0d7659ed6dd9ae06b1b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Tue, 5 Oct 2021 13:46:51 +0200
Subject: [PATCH] Introduce new --local-service=host parameter
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Similar to local-service, but more strict. Listen only on localhost
unless other interface is specified. Has no effect when interface is
provided explicitly. I had multiple bugs fillen on Fedora, because I have
changed default configuration to:

interface=lo
bind-interfaces

People just adding configuration parts to /etc/dnsmasq.d or appending to
existing configuration often fail to see some defaults are already there.
Give them auto-ignored configuration as smart default.

Signed-off-by: Petr Menšík 

Do not add a new parameter on command line. Instead add just parameter
for behaviour modification of existing local-service option. Now it
accepts two optional values:
- net: exactly the same as before
- host: bind only to lo interface, do not listen on any other addresses
  than loopback.
---
 man/dnsmasq.8 |  8 +---
 src/dnsmasq.c |  2 ++
 src/dnsmasq.h |  3 ++-
 src/option.c  | 44 +---
 4 files changed, 42 insertions(+), 15 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 6d37360..0f0f0c8 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -270,14 +270,16 @@ the address dnsmasq is listening on. When an interface is specified,
 it may be qualified with "/4" or "/6" to specify only the IPv4 or IPv6
 addresses associated with the interface. Since any defined authoritative zones are also available as part of the normal recusive DNS service supplied by dnsmasq, it can make sense to have an --auth-server declaration with no interfaces or address, but simply specifying the primary external nameserver.
 .TP
-.B --local-service
+.B --local-service[=net|host]
+Without parameter or with net parameter, restricts service to connected network.
 Accept DNS queries only from hosts whose address is on a local subnet,
-ie a subnet for which an interface exists on the server. This option
+ie a subnet for which an interface exists on the server. With host parameter, listens
+only on lo interface and accepts queries from localhost only. This option
 only has effect if there are no \fB--interface\fP, \fB--except-interface\fP,
 \fB--listen-address\fP or \fB--auth-server\fP options. It is intended to be set as
 a default on installation, to allow unconfigured installations to be
 useful but also safe from being used for DNS amplification attacks.
-.TP 
+.TP
 .B \-2, --no-dhcp-interface=
 Do not provide DHCP, TFTP or router advertisement on the specified interface, but do provide DNS service.
 .TP
diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 65ba334..83174cf 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -861,6 +861,8 @@ int main (int argc, char **argv)
 
   if (option_bool(OPT_LOCAL_SERVICE))
 	my_syslog(LOG_INFO, _("DNS service limited to local subnets"));
+  else if (option_bool(OPT_LOCALHOST_SERVICE))
+	my_syslog(LOG_INFO, _("DNS service limited to localhost"));
 }
   
   my_syslog(LOG_INFO, _("compile time options: %s"), compile_opts);
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 67c083b..d6985b6 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -281,7 +281,8 @@ struct event_desc {
 #define OPT_NORR   69
 #define OPT_NO_IDENT   70
 #define OPT_CAC

Re: [Dnsmasq-discuss] dnsmasq: /#/ and error "config error is REFUSED (EDE: not ready)“

2023-11-28 Thread Petr Menšík
hich
> > > states that the /#/ bug has been fixed... but I don't see it
with version
> > > 2.89 (the last version installed on Debian). The /#/ in the
config file
> > > seems still to be an issue.
> > >
> > > listen-address=127.0.0.1
> > > bind-interfaces
> > > server=/#/8.8.8.8 <http://8.8.8.8>
> > > server=/svc.cluster.local/10.96.0.10 <http://10.96.0.10>
> > > cache-size=500
> > >
> >
> > And with
> >
> >  listen-address=127.0.0.1
> >  bind-interfaces
> >  server=9.9.9.9
> >  server=/svc.cluster.local/10.96.0.10 <http://10.96.0.10>
> >  cache-size=500
> >
> > ?   (Yes, that are two changes!)
> >
> Hi,
>
> From the client :
> root@bookworm:~# dig @127.0.0.1 <http://127.0.0.1> perdu.com
<http://perdu.com> A +short
> 172.67.133.176
> 104.21.5.178
>
> Log from the daemon :
> root@bookworm:~# dnsmasq --no-daemon --log-queries --log-debug
> dnsmasq: started, version 2.89 cachesize 500
> dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus i18n
IDN2 DHCP
> DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC
> loop-detect inotify dumpfile
> dnsmasq: using nameserver 9.9.9.9#53
> dnsmasq: using nameserver 10.96.0.10#53 for domain svc.cluster.local
> dnsmasq: reading /etc/resolv.conf
> dnsmasq: using nameserver 9.9.9.9#53
> dnsmasq: using nameserver 10.96.0.10#53 for domain svc.cluster.local
> dnsmasq: ignoring nameserver 127.0.0.1 - local interface
> dnsmasq: read /etc/hosts - 7 names
> dnsmasq: query[A] perdu.com <http://perdu.com> from 127.0.0.1
> dnsmasq: forwarded perdu.com <http://perdu.com> to 9.9.9.9
> dnsmasq: reply perdu.com <http://perdu.com> is 172.67.133.176
> dnsmasq: reply perdu.com <http://perdu.com> is 104.21.5.178

Okay, that looks fine.  Now test the two changes separately.
I refer to the above "Yes, that are two changes!"


Groeten
Geert Stappers
-- 
Silence is hard to parse



--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


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] [PATCH] Refuse to start with EADDRINUSE in --bind-dynamic mode

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


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


More below...

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


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


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


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


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


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




TLDR;

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



Cheers,

Simon.


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


Cheers,
Petr




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


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


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

Re: [Dnsmasq-discuss] Confused about simple subdomain authoritative server (re: home network)

2023-11-23 Thread Petr Menšík
It depends what interface you use for auth-server in second parameter. 
You have not shared if you have internal and external interfaces, so I 
would guess enp2s0f0 is internal interface. If you want authoritative 
answers served to internal clients, use just 
|auth-server=server.home.mydomain.com <http://server.home.mydomain.com>

|

||auth-server with interface specified is intended to be used on router 
WAN interface facing to potentially hostile network. Therefore it does 
not do recursive service, but just authoritative on it. That is by 
design, but may not be what you wanted.


For trusted internal network, specify just allowed interface(s).

interface=lo
interface=enp20f0
|auth-server=server.home.mydomain.com
<http://server.home.mydomain.com>||auth-zone=home.mydomain.com 
<http://home.mydomain.com>,192.168.1.0/24

||host-record=server.home.mydomain.com,192.168.1.50|

||

Cheers,
Petr|
|

On 06. 11. 23 14:22, John Klimek wrote:
Here is the dnsmasq.conf I'm using.  It seems to return authoritative 
responses for home.mydomain.com <http://home.mydomain.com> but if I 
query anything else it returns REFUSED:


|log-queries no-resolv server=8.8.4.4 server=8.8.8.8 
auth-server=server.home.mydomain.com 
<http://server.home.mydomain.com>,enp2s0f0 auth-zone=home.mydomain.com 
<http://home.mydomain.com>,192.168.1.0/24 
host-record=server.home.mydomain.com,192.168.1.50 
<http://192.168.1.0/24 host-record=server.home.mydomain.com,192.168.1.50>|



--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


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

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


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


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


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

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

dnsmasq: process is missing required capability NET_BIND_SERVICE

# Compare this with:

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

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

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


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

Isn't this sufficient to fix the problem?

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


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


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

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

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

Cheers,

Simon.

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

Hello everyone,

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


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


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


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


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


--
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] [PATCH] Refuse to start with EADDRINUSE in --bind-dynamic mode

2023-11-22 Thread Petr Menšík

Hello everyone,

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


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


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


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


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

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 207e9f4241c79b703320ae3568208e3a47cd25ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Wed, 22 Nov 2023 20:04:14 +0100
Subject: [PATCH 2/2] Prevent starting another instance with --bind-dynamic

Previously startup bind() errors were silently dropped when starting with
--bind-dynamic. Make even in that mode EADDRINUSE error fatal to prevent
running another instance with half-initialized listeners.

On the other hand still hide address not available error, which is very
likely the reason for using bind-dynamic. Expect the address specified
will just appear later.
---
 src/network.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/src/network.c b/src/network.c
index ca9fada..f18be24 100644
--- a/src/network.c
+++ b/src/network.c
@@ -921,13 +921,9 @@ static int make_sock(union mysockaddr *addr, int type, int dienow)
   errno = errsave;
 
   if (dienow)
-	{
-	  /* failure to bind addresses given by --listen-address at this point
-	 is OK if we're doing bind-dynamic */
-	  if (!option_bool(OPT_CLEVERBIND))
-	die(s, daemon->addrbuff, EC_BADNET);
-	}
-  else
+	die(s, daemon->addrbuff, EC_BADNET);
+  else if (!option_bool(OPT_CLEVERBIND)
+	   || (option_bool(OPT_CLEVERBIND) && errno != EADDRNOTAVAIL))
 	my_syslog(LOG_WARNING, s, daemon->addrbuff, strerror(errno));
   
   return -1;
@@ -940,7 +936,14 @@ static int make_sock(union mysockaddr *addr, int type, int dienow)
 goto err;
   
   if ((rc = bind(fd, (struct sockaddr *)addr, sa_len(addr))) == -1)
-goto err;
+{
+  if (dienow && option_bool(OPT_CLEVERBIND) && errno != EADDRINUSE)
+	  /* failure to bind addresses given by --listen-address at this point
+	 is OK if we're doing bind-dynamic, except EADDRINUSE */
+	dienow = 0;
+
+  goto err;
+}
   
   if (type == SOCK_STREAM)
 {
-- 
2.42.0

From c1982e364c01a00c8b6454b677ae0dbe1ea4a382 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Wed, 22 Nov 2023 20:00:01 +0100
Subject: [PATCH 1/2] Make stderr logging enabled until normal logging starts

Some kinds of errors like socket bind errors are done before dnsmasq
starts regular logging facility. Do not have those messages disappear,
but log them to stderr. As soon as log_start is called, that is resetted
according to configuration settings.
---
 src/log.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/log.c b/src/log.c
index 77032fb..6edcc09 100644
--- a/src/log.c
+++ b/src/log.c
@@ -35,7 +35,7 @@
 /* defaults in case we die() before we log_start() */
 static int log_fac = LOG_DAEMON;
 static int log_stderr = 0;
-static int echo_stderr = 0;
+static int echo_stderr = 1;
 static int log_fd = -1;
 static int log_to_file = 0;
 static int entries_alloced = 0;
-- 
2.42.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] Captive Portals check

2023-11-13 Thread Petr Menšík
Yes, you can do --server=/connectivitycheck.gstatic.com 
<http://connectivitycheck.gstatic.com>/8.8.8.8, but you would have to 
know what special domains to send to local resolvers provided by 
network. Unfortunately such list is usually not provided. Often 
ipv4.dns-search list is misused for that purpose and NM will configure 
that for you. Check journalctl -xeu NetworkManager with dns=dnsmasq 
configured in NM. Provisioning Domains should help, but NM does not 
support RFC 7556 also.


2.c) If our proxy could know the address of the network-provided DNS 
server, it could use that specific DNS address when reaching to 
http://connectivitycheck.gstatic.com/generate_204 
<http://connectivitycheck.gstatic.com/generate_204>


The problem is that only dnsmasq holds the information about the 
current network-provided DNS server. And I could not find any way to 
get this information from dnsmasq via dbus. dnsmasq supports messages 
like “SetServers” but nothing like “GetServers”.



Is getting the network-provided DNS server (or, alternatively, the 
full list of DNS servers) something that is or could be supported by 
dnsmasq?


There is NM plugin to push network servers to dnsmasq via dbus. I 
suggest you use DBus to get servers from NM. That knows dns servers too, 
but I think does not offer simple way as well. Unfortunately memory 
structures used in dnsmasq does not offer simple way to do GetServers 
implementation. Even printing used servers into the log is somehow 
incomplete. I think it would require refactoring to implement GetServers 
properly. With current structures it would be inefficient, but still 
possible.


We are working on dnsconfd [1] prototype, which sometime in the future 
might be able to handle similar situations, but we are not there yet. 
Captive portal processing is one of reasons for its existence, 
especially if they should be followed by encrypted DNS channel. But 
current code won't help you, it barely does basic configuration now. We 
want unbound to be primary handling software now, but our idea is every 
capable DNS cache/proxy should work with it too, with just thin 
specialized module. Including dnsmasq in the future. But we are still 
far from that.




Thanks,

Evgeny



Cheers,
Petr

1. https://github.com/InfrastructureServices/dnsconfd


--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


OpenPGP_signature
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] [PATCH] Add a flag to customise MAX_PROCS

2023-11-01 Thread Petr Menšík
In general I like the change. Fixed number does not scale. I would move 
max_procs in dnsmasq right after tcp_pipes. It belongs to it and is 
directly related. I would add into comment  /* tcp_pipes size */, 
because the name does not make it obvious. Maybe even call it 
tcp_pipes_sz instead of max_procs. I would use unsigned int as a type, 
negative value does not make sense for it anyway.


I think whole TCP handling concept is unfortunate and slow. It allocates 
64kB for each TCP socket I think, which is no issue on any today's 
hardware. But some old routers may have too little of memory. I may have 
mistaken this with avahi, it does it similar way. This is a minimal 
change to archieve non-crashing results. I would expect just 4kB buffer 
would be enough for almost anything, it should just reallocate the 
buffer if that is not enough. But that would require careful changes to 
not break anything else.


Even better it should handle TCP inside main process with non-blocking 
socket API, without extra forks spawned. But that has to wait.


I recommend using option edns0 inside /etc/resolv.conf on any clients 
where it can work, to avoid TCP queries if possible. TCP queries have 
worse failover implementation and are much slower than UDP queries.


Anyway, nice change in my opinion.

Cheers,
Petr

On 12. 10. 23 0:36, Damian Sawicki via Dnsmasq-discuss wrote:

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

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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


OpenPGP_signature
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


[Dnsmasq-discuss] [PATCH] Re: Issues with dnsmasq under NM and domain redirection: REFUSED

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


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


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


It runs with these parameters:

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


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


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

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

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

Hello everyone.

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


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


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

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

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


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

(gdb) p *$d->servers->next->next->next->next->next->next->next
$9 = {flags = 800, domain_len = 10, domain = 0x5557a43ff9f0 
"redhat.com", next = 0x5557a43f5fb0, serial = 7, arrayposn = 25, 
last_server = -1,
  addr = {sa = {sa_family = 2, sa_data = 

[Dnsmasq-discuss] Issues with dnsmasq under NM and domain redirection: REFUSED

2023-10-16 Thread Petr Menšík
ip a show dev enp9s0u1
7: enp9s0u1:  mtu 1500 qdisc fq_codel 
state UP group default qlen 1000

    link/ether 00:50:b6:b4:17:b2 brd ff:ff:ff:ff:ff:ff
    inet 10.43.2.229/24 brd 10.43.2.255 scope global dynamic 
noprefixroute enp9s0u1

   valid_lft 56729sec preferred_lft 56729sec
    inet6 2620:52:0:2b02:b3ba:7320:65f8:1fff/64 scope global dynamic 
noprefixroute

   valid_lft 2591999sec preferred_lft 604799sec
    inet6 fe80::b2f:65c5:d743:524b/64 scope link noprefixroute
   valid_lft forever preferred_lft forever

The problem seems to be wrong ifindex for redhat.com domain, while for 
brq.redhat.com it has refreshed correctly. I am not sure how exactly did 
that happen, but I think I have saw that few times already. I am not 
sure about exact steps required to reproduce this issue, but I think it 
would be related to undocking from thunderbolt and reconnecting again. 
Has anyone else saw similar behaviour?


It seems to me call to enumerate_interfaces(0) should have fixed this. I 
wonder whether it would make sense to call it explicitly after 
local_bind failure. Because full journal I do not have details about 
interface changes anymore:


journalctl -xeu NetworkManager | grep 'failed to bind server socket to 
enp9s0u1' | wc -l

711

Has similar error been seen in the wild? Is there fix for it, which I 
have failed to find?


Cheers,
Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] Syntax for multiple listen addresses

2023-07-17 Thread Petr Menšík
I tend to use lsof -np $(pidof dnsmasq) to know where is my instance 
listening.


Manual page does not mention delimiter by comma. I think the second 
variant is expected to work and documented way.


Cheers,
Petr

On 17. 07. 23 16:56, Chris Green wrote:

I'm sure this must be in the man page somewhere but I can't find it.
If dnsmasq is to listen on more than one address how do you put this
in the configuration file?

I.e. is it:-
 listen-address=192.168.1.2,127.0.0.1

or is it:-
 listen-address=192.168.1.2
 listen-address=127.0.0.1

Or will either work?


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] Problem with 127.0.1.1 versus 127.0.0.1

2023-07-17 Thread Petr Menšík
What is specified in dnsmasq does not matter. host by default does not 
talk to dnsmasq directly. It reads /etc/resolv.conf and uses nameserver 
specified there. If that is IP of dnsmasq, okay. If it is not, well, the 
problem might be elsewhere. Because I don't know what is there, I cannot 
help.


If you do "dig @localhost jacquibennett.com", then you are asking 
dnsmasq explicitly. Just "dig jacquibennett.com" uses server in 
/etc/resolv.conf, which may not even contain localhost address at all. 
That is why I have asked what is there.


On 17. 07. 23 9:00, Chris Green wrote:

On Sun, Jul 16, 2023 at 11:58:38PM +0200, Petr Menšík wrote:

I think you have failed to show us what is in /etc/resolv.conf on the
machine, which is running host command.


It's specified in /etc/dnsmasq.conf:-

 resolv-file=/run/NetworkManager/no-stub-resolv.conf

... and the contents are:-

 # Generated by NetworkManager
 search zbmc.eu
 nameserver 192.168.1.2


unless listen-address or interface is specified, it should listen on all
interfaces.


Yes, that's what I thought.



Try using host -v jacquibennett.com, it might provide more details what
exactly has timed out.

If unsure what is host contacting, try separate queries to server
specified explicitly:

- host -v jacquibennett.com 127.0.0.1
- host -v jacquibennett.com 127.0.1.1

That might provide hints what is failing and what is working.


Ah, thank you, I hadn't thought to check options for the host command,
I had been using dig to look deeper.

Typically when I tried just now both the above host commands worked
instantly with no errors!  I'll have to keep trying to work out what's
wrong.
dig is better tool anyway, stay using that. host returns more compact 
result, but is worse tool when hunting strange errors. Mostly because 
without -t parameters it does 3 queries and possibleerror does not have 
clear indication, to which it belongs.



Cheers,
Petr

On 7/16/23 22:10, Chris Green wrote:

I use dnsmasq on a number of, mostly Ubuntu, home systems. One system
at 192.168.1.2 acts as the DNS server for my LAN, then there are
several 'client' systems that just use dnsmasq as a caching DNS server
for their own lookups.

I *suspect* I have a problem with looking up names via the local
dnsmasq because it is listening only on 127.0.1.1 and the request is
on 127.0.0.1#53.

for example a 'host'command on my laptop returns:-

  chris$ host jacquibennett.com
  ;; communications error to 127.0.0.1#53: timed out
  jacquibennett.com has address 153.92.6.161
  jacquibennett.com has IPv6 address 2a02:4780:a:1080:0:174b:7855:7
  jacquibennett.com mail is handled by 5 mx1.hostinger.com.
  jacquibennett.com mail is handled by 10 mx2.hostinger.com.

But dnsmasq is running on the laptop:-

dnsmasq 7443 1 0 09:27 ? 00:00:01 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid

-u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service
--trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d



The dnsmasq configuration file on the laptop (and other client
systems) is almost non-existent, it's just:-

  resolv-file=/run/NetworkManager/no-stub-resolv.conf

... /run/NetworkManager/no-stub-resolv.conf is:-

  # Generated by NetworkManager
  search zbmc.eu
  nameserver 192.168.1.2


... and in /etc/dnsmasq.d I just have a blacklist file with lots of
address= entries, but that's all.  The /etc/default/dnsmasq
file just has:-

  ENABLED=1
  CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new


So why do I get that timeout error from the 'host' coommand? It's as
if dnsmasq on the local machine isn't listening on 127.0.0.1.  Does it
only listen on 127.0.1.1 by default?


--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] Problem with 127.0.1.1 versus 127.0.0.1

2023-07-16 Thread Petr Menšík
I think you have failed to show us what is in /etc/resolv.conf on the 
machine, which is running host command.


unless listen-address or interface is specified, it should listen on all 
interfaces.


Try using host -v jacquibennett.com, it might provide more details what 
exactly has timed out.


If unsure what is host contacting, try separate queries to server 
specified explicitly:


- host -v jacquibennett.com 127.0.0.1
- host -v jacquibennett.com 127.0.1.1

That might provide hints what is failing and what is working.

Cheers,
Petr

On 7/16/23 22:10, Chris Green wrote:

I use dnsmasq on a number of, mostly Ubuntu, home systems. One system
at 192.168.1.2 acts as the DNS server for my LAN, then there are
several 'client' systems that just use dnsmasq as a caching DNS server
for their own lookups.

I *suspect* I have a problem with looking up names via the local
dnsmasq because it is listening only on 127.0.1.1 and the request is
on 127.0.0.1#53.

for example a 'host'command on my laptop returns:-

 chris$ host jacquibennett.com
 ;; communications error to 127.0.0.1#53: timed out
 jacquibennett.com has address 153.92.6.161
 jacquibennett.com has IPv6 address 2a02:4780:a:1080:0:174b:7855:7
 jacquibennett.com mail is handled by 5 mx1.hostinger.com.
 jacquibennett.com mail is handled by 10 mx2.hostinger.com.

But dnsmasq is running on the laptop:-

dnsmasq 7443   1  0 09:27 ?00:00:01 /usr/sbin/dnsmasq -x 
/run/dnsmasq/dnsmasq.pid -u dnsmasq -7 
/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service 
--trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d


The dnsmasq configuration file on the laptop (and other client
systems) is almost non-existent, it's just:-

 resolv-file=/run/NetworkManager/no-stub-resolv.conf

... /run/NetworkManager/no-stub-resolv.conf is:-

 # Generated by NetworkManager
 search zbmc.eu
 nameserver 192.168.1.2


... and in /etc/dnsmasq.d I just have a blacklist file with lots of
address= entries, but that's all.  The /etc/default/dnsmasq
file just has:-

 ENABLED=1
 CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new


So why do I get that timeout error from the 'host' coommand? It's as
if dnsmasq on the local machine isn't listening on 127.0.0.1.  Does it
only listen on 127.0.1.1 by default?


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


Re: [Dnsmasq-discuss] Implications of raising dns-forward-max

2023-07-03 Thread Petr Menšík
I think these kinds of problem arises usually when connectivity to 
upstream is broken or interrupted.


150 is number of concurrent queries waiting for resolution. It should 
not be required to increase this limit if the remote server is answering 
fast. Unless I am mistaken, as soon as the response arrives back, that 
frees on of those sessions. Dnsmasq cannot drive retries itself, it 
relies on client to do them. But that should not matter.


Unless we know more details when and how increasing this value should 
help, I would be opposed in doing so. We may need to improve switching 
to alternative resolvers, if that alternatives respond faster. If that 
is interruption in upstream connectivity, no increase here would help.


On 29. 06. 23 15:39, Eric Fahlgren wrote:

On Thu, Jun 29, 2023 at 12:52 AM Buck Horn  wrote:

Blindly increasing dns-forward-max without having analysed the actual
issue does not seem to recommend itself as the best option
available to
me, even if it would turn out that actual resource impacts are minor.

Stopping or unconfiguring the DNS loop or switching to more reliable
upstreams would seem more adequate measures to address the warning.

If you have actively been involved in investigating such an issue, it
may be worth verifying those causes, if only to preclude them. ;)


Hi Buck,

Thanks a bunch for the possible causes.  As you could probably tell 
from my "assuming", I have not done any root cause investigation, all 
the reports are just anecdotal "I saw this, then did that, and the 
issue went away..." In some of the posts, it has been suggested that 
the installation default be raised to 500 based on these reports, 
because "why not?" and "it looks like it fixes something?"


So, at this point I'm still in tentative data collection phase and 
armed with your suggested avenues of investigation, I'll see if I can 
get someone to reproduce the problem and find the real root issue.


Thanks again,
Eric

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


--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


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

2023-07-02 Thread Petr Menšík
I have just found RFC draft EDNS(0) option to negotiate Leases on DNS 
Updates [1]. It seems it would be good not only for SRV records of 
DNS-SD, but also for hostnames registered from SLAAC clients.


Of course there would have to be some indication to clients to try 
sending update. Maybe new RA option for that? I think we may allocate 
similar record that we create for DHCP clients. Just allow DNS client to 
do UPDATE query on domain offered to them, unless they conflict. If they 
do not send another update, delete it after leased time. Could work, right?


I guess accepted should be only A,  and PTR. Maybe also SRV with a 
correct service prefix.


Found a reference for that on dnsextd [2]. It acompanies RFC 8764, which 
is more useful for Avahi than dnsmasq. But limited updates might be 
useful even for us.


Cheers,
Petr

1. https://www.ietf.org/archive/id/draft-ietf-dnssd-update-lease-07.html
2. 
https://github.com/apple-oss-distributions/mDNSResponder/blob/d31f3447dfb1997e6457abf83502390b1f42f2ce/mDNSShared/dnsextd.8

3. https://datatracker.ietf.org/doc/rfc8764/

On 6/12/23 19:53, Simon Kelley wrote:
Dnsmasq has a feature, enabled by "ra-names" which attempts to solve 
this problem for dual-stack hosts.


It works like this.

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


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


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


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

Simon.


--

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


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

2023-06-20 Thread Petr Menšík
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


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

2023-06-20 Thread Petr Menšík
This situation should be supported and working. But if those hosts do 
not use DHCP to "activate" those names, you have to use different option 
for them. Use --host-record instead, like:


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

I think dhcp-host does not care for the order of name or IP. You can 
swap them to have single way defining them:


dhcp-host=mediapi,192.168.10.203

Not sure host-record does not care for the order of addresses and name.

dhcp-host is not resolvable until that address is assigned. That is by 
design. If you need name to have static address, then host-record or 
/etc/hosts is the way to go.


Cheers,
Petr

On 16. 06. 23 20:32, michalk via Dnsmasq-discuss wrote:
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.


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


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

2023-06-09 Thread Petr Menšík

Hi Eric,

For example older windows were trying to send DNS updates on their 
configured DNS servers. I am not sure if they are still trying that, I 
assume they don't. That would work on ipv6-only network. Only that 
machine knows its name.


As you have described, the name of the host is revealed anyway in DHCPv4 
request. I think the OS could try to send updates to the local network 
DNS server, if it resides on local network. That would be equivalent to 
using mdns, which I think is used by Apple devices often. But unicast is 
more reliable. The question is after which time such name should be 
removed. Because not paired with DHCP lease time, it should not remain 
there forever.


On 6/9/23 17:38, Eric Fahlgren wrote:


Hi Petr,

I have been looking into this off and on for the last year or two and 
haven't found a good solution (where "good" is defined as "apt install 
give-me-ipv6-dns-auto-names").


My two use cases are both on-LAN, so privacy is a non-issue:
  1) making tcpdump show host names when I do traces;
  2) allow wife and other home users to just say "https://videos.lan/; 
instead of me explaining and dealing with IP addresses.
For devices offering any services to network, I think DHCPv6 client 
would make sense. That would register the name automagically. Static 
records would be good for devices always there, like raspberry pi service.


My solution is a cron script on my (Linux/OpenWrt) gateway device that 
looks at the DHCPv4 table to collect MAC:host-name pairs, then looks 
at 'ip -6 neigh show' to get MAC:IPv6 pairs, matches up the names and 
SLAAC IPv6s to the names and writes them to a dnsmasq config file.  
(The config file still needs manual cleaning, as I don't have anything 
logging expiration times.)
Sounds like working, but not too elegant hack. I think dhcp-range with 
ra-names should help you in this case, if the dnsmasq is doing this job. 
Should do something like your script in a bit more elegant way. But 
needs IPv4 DHCP to obtain the name. If we ever stop using it, that will 
stop providing names.


It would be lovely if there were a nice demon that just sat and 
watched for NDP NA/NS messages and used that information (including 
TTLs) to do a DNS UPDATE instead of my hack.  I'm not sure where to 
get host names on an IPv6-only network, as I haven't looked into that 
part deeply...


Eric


At least using MDNS responder on network gateway might push names 
obtained via mdns into unicast dns too. I would expect some RA option to 
say: try to register on the DNS server (if you wish). But IANA has 
nothing such registered [1]. Because I would like to have some names for 
all connected devices in my network, without a need to register them 
manually.


1. 
https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5


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


Re: [Dnsmasq-discuss] [PATCH] TCP client timeout setting

2023-06-08 Thread Petr Menšík

This relies on default settings of tcp tuning values set in system.

I like the change in 50adf82199c362da6c542f1d22be2eeab7481211 adding 
timeout variable check.


But using SO_SNDTIMEO would allow setting it in time units, regardless 
default tcp values. And should be supported also on BSD and in general 
more portable variant. Do you have a reason to use only linux-specific 
variant? 2 tries seems too little if 6 is the default. I wish we had 
some value to tell system just retry (a bit) faster than usual. Haven't 
found that. I would use 3-4 to overcome short connection break at least. 
20-30 seconds should be better default value.


I think the final fix would be making connections non-blocking and in 
parallel, accepting first reply which arrives. This is just small tuning 
to be not so terrible. It has to be sooner than alarm kills the TCP 
client, at least 3 servers should be tried before that happens. I think 
previous default allowed just one, so my changed server report over pipe 
did not happen.


I am also not sure we should log every truncated packet without some 
limit. I think it might lead to denial of service attack. Just stats 
counter should be incremented, which can be watched by polling. Number 
of accepted TCP connections is not counted if I see well. As is not 
number of truncated messages. Would be useful for the service monitoring.


On 26. 05. 23 18:53, Simon Kelley wrote:


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


Simon.


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] Test suite for RFC validation

2023-06-07 Thread Petr Menšík
I know only ISC forge project. Never tried to use it on dnsmasq, but in 
theory it could be possible.


https://github.com/isc-projects/forge

On 21. 05. 23 17:05, Geert Stappers wrote:

Hello Shashi,

You might get two copies of this email.
In case you answer, please answer the mailinglist.
( Reply-To: is set to accomodate that )

On Fri, May 19, 2023 at 12:42:24PM +0200, Petr Menšík wrote:

On 5/3/23 06:23, shashikumar Shashi wrote:

On Tue, May 2, 2023 at 4:05 AM Simon Kelley wrote:



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

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

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

Hi Simon,

While validating the RFC 3315 standards through the test suite caught
this issue.


Just for pure interest, can you share what test suite are you using? Is that
open source?

I would also like what the name of the test suite is
and under which licence it is available.


Groeten
Geert Stappers


--
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] Do we have good way to register SLAAC clients?

2023-06-07 Thread Petr Menšík

Hello everyone.

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


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


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


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


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


Cheers,
Petr

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

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

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] v6 to v4 switch on fail over on Strict Order

2023-06-02 Thread Petr Menšík
If the V6 route is missing, UDP packets sent to v6 hosts would fail 
immediately. dnsmasq tries to use usually some resolver, which is 
responding. If v6 timeouts, they should not become such. It tries to 
send query every 20 seconds or 50 queries to all servers. But in 
general, it should work fine on UDP. TCP is more difficult, there are 
unfixed issues.


On 2/16/23 08:42, Gomathi Shankar P S wrote:

Hi Team,
We are facing an issue when we have the following pre-conditions

  * dnsmasq version - 2.83, and is running in strict-order
  * both v6 and v4 nameservers are in the resolv file
  * when v6 route is fails

there is no fail-over fallback to v4 from v6 nameserver for resolution.

I understand that dnsmasq only reaches V6 nameservers (note - we have 
both v6 and v4 nameservers in resolv.dnsmasq) when we have V6 IP.


I haven't seen any code preferring just IPv6 nameservers when there is 
also IPv4. It should treat them equally and choose last_server to be 
used by any response arrived. If that is only IPv4 servers, it should 
choose them.


If that does not happen, can you provide log with --log-queries or pcap 
with recorded responses? I think it should work.




When V6 route fails (but still we have V6 IP), we would like dnsmasq 
to reach V4 nameservers when V6 route is failed. Currently, it 
forwards the domains only to V6 nameservers as we have V6 IPs.


In the case of "no-strict-order", dnsmasq is reaching out to all 
nameservers.
Is it possible to let dnsmasq to reach out V4 nameservers if the route 
fails (no response from V6 nameservers)?


Regards
Gomathi Shankar P S

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


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


Re: [Dnsmasq-discuss] [PATCH] TCP client timeout setting

2023-05-31 Thread Petr Menšík
Attached my bigger attempt to solve this problem. 7 separate patches 
included.


Because in rare circumstances servers might have changed since TCP 
connection process started, I serialize domain, server address and its 
last position in server array. Hacked a redirection with special -2 
value from cache inserting, where it always reads just one server. It 
then tries server at reported position first, iterating on all servers 
for this domain.


In rare cases there might be a problem, because it does not send source 
address or interface, which might identify correct server. But I doubt 
those would make it different in any real world examples. We have no 
simple identification for changed servers. It works in basic testing well.


Added also separation of TCP and UDP last servers. It should be able to 
forward UDP to server responding just over UDP and TCP to server 
responding just TCP. That should be quite rare case, more teoretical 
than real-world. Maybe change of UDP server should change also TCP, 
because UDP test can be done in parallel.


I have found also unwanted difference from UDP queries. If the response 
is REFUSED, even that were accepted as valid last_server response. Now 
it sets TCP last_server just after non-refused response, not just 
successful connection.


I have tried to look into glibc, that does not seem to set any timeout 
for TCP (vc) queries. Default timeout in dig tool is 10 seconds, it does 
not seem to tweak number of SYN packets sent. I think it just measures 
time before reply arrives. I think ideally we should be able to spawn 
another TCP connection to the other server if it didn't respond in few 
seconds. And wait for fastest response from any of those. But that would 
require quite significant rework of current code.


Did just a basic testing, but those changes improve tested situation.

What do you think about it?

Cheers,
Petr

On 26. 05. 23 18:19, Simon Kelley wrote:



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


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


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

Now start dnsmasq and send tcp query to it

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

$ dig +tcp @localhost -p 2053 test

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

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

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


Now lets be persistent and keep trying:

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

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


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

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

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

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


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

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


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


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


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

Cheers,
Petr




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

2023-05-30 Thread Petr Menšík
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


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

2023-05-26 Thread Petr Menšík

Added captive-portal DHCP option to database.

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


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


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


BR
Florian


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


--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From e0674d8ae1737f00e89bf9fbb87a1369174f5751 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Fri, 26 May 2023 11:31:12 +0200
Subject: [PATCH] Add captive-portal DHCP options entry

Defined by RFC 8910 it adds string defining URL with the information
about captive portal.

RA option is not defined.
---
 src/dhcp-common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/dhcp-common.c b/src/dhcp-common.c
index b004e40..c3b978b 100644
--- a/src/dhcp-common.c
+++ b/src/dhcp-common.c
@@ -685,7 +685,8 @@ static const struct opttab_t {
   { "client-machine-id", 97, 0 },
   { "posix-timezone", 100, OT_NAME }, /* RFC 4833, Sec. 2 */
   { "tzdb-timezone", 101, OT_NAME }, /* RFC 4833, Sec. 2 */
-  { "ipv6-only", 108, 4 | OT_DEC },  /* RFC 8925 */ 
+  { "ipv6-only", 108, 4 | OT_DEC },  /* RFC 8925 */
+  { "captive-portal", 114, OT_NAME }, /* RFC 8910 */
   { "subnet-select", 118, OT_INTERNAL },
   { "domain-search", 119, OT_RFC1035_NAME },
   { "sip-server", 120, 0 },
@@ -727,6 +728,7 @@ static const struct opttab_t opttab6[] = {
   { "ntp-server", 56, 0 /* OT_ADDR_LIST | OT_RFC1035_NAME */ },
   { "bootfile-url", 59, OT_NAME },
   { "bootfile-param", 60, OT_CSTRING },
+  { "captive-portal", 103, OT_NAME }, /* RFC 8910 */
   { NULL, 0, 0 }
 };
 #endif
-- 
2.40.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] dhcp-lease-max is only for DHCPv4?

2023-05-25 Thread Petr Menšík
Yes, dhclient generates DUID into its lease file. Either add -lf 
/var/lib/dhclient/dhclient-$I.leases or just remove lease file after 
each dhclient run. Parameter -D LLT might help too.


It should be visible what IPv6 address it is offering to the client in 
logs. Does it change?


Petr

On 5/23/23 10:11, Simon Kelley wrote:
In DHCPv6, the unique identifier for a client is NOT the MAC address, 
it's a client ID which sometimes contains the MAC address.


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


Simon.


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

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

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


steps of the script:

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

    2. run dhclient with macvlan interface

    3. get an IP from DHCPv6 server

    4. kill the dhclient and remove the macvlan interface

    5. back to step 1. and go on.


Results:

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



Thanks,
Lin



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


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

 > > >        attacks from hosts which create thousands of leases
    and use
 > > >        lots of memory in the dnsmasq process.
 > >
 > > Hello,
 > >
 > > I'm using dnsmasq2.89 and testing the maximum lease count of
    the DHCPv6
 > > server with the *dhcp-lease-max* option.
 > >
 > > For the testing, I'm using below configuration:
 > >
 > >     *dhcp-lease-max* = 512
 > >  *dhcp-range*=tag:pool0,2022::1,2022::1f:::fffe,64,120m
 > >     tag-if=set:pool0,tag:intfv0
 > >
 > >
 > > However, when the number of clients reaches the maximum 
number, the

 > > server still provides IPs to clients. Is this the expected
    behavior of
 > > DHCPv6?
 > >
 > There's a possible difference between the number of clients and
    the number
 > of DHCP leases, since leases can expire to be deleted by the 
client.

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

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


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


    Regards
    Geert Stappers
    --     Silence is hard to parse

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




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


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


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


Re: [Dnsmasq-discuss] [PATCH] TCP client timeout setting

2023-05-25 Thread Petr Menšík
This problem is best tested by an example, taken from [2] but a bit 
modified.


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


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

Now start dnsmasq and send tcp query to it

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

$ dig +tcp @localhost -p 2053 test

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

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

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


Now lets be persistent and keep trying:

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

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


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

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

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

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


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

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


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


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


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

Cheers,
Petr

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

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


...

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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


OpenPGP_signature
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


[Dnsmasq-discuss] [PATCH] TCP client timeout setting

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


The problem is if the client chooses to use TCP for whatever reason, 
dnsmasq will never switch to actually working server until some UDP 
request arrives to trigger re-evaluation of last_server responsiveness. 
It might do so, but just inside single TCP process. It just stubbornly 
forwards even 5th retry to the same server now, when another one might 
be able to answer right away.


I think the proper solution would be implementation of event driven 
reading of TCP sockets in the main process. I don't think using threads 
is possible, because quite a lot of globals used. It should not fork 
another processes without --no-daemon parameter, but just use poll() to 
watch socket readiness, then read whatever is prepared already. Since 
TCP DNS message says its length at the start, it can just allocate 
buffer big enough for that connection and iteratively read without 
blocking. Once it is read, it can parse it, process it. A bit of socket 
magic would be required, but similar approach could solve also sending 
with multiple calls without blocking. That would be big change however.


I think some feedback should be delivered to main dnsmasq process from 
tcp processing children, just like cache is updated from 
cache_end_insert(). I think it should be able to switch last_server used 
due to feedback from tcp client process. I even think there should be 
different last_server for UDP and different for TCP, but not untill TCP 
can report issues too. But not sure what approach to choose. At first I 
though about special F_flag, but all bits for cache record (struct crec) 
are already used.


Alternative quick-fix might be in case the TCP request sending fails to 
some server to generate UDP request with EDNS header added from tcp 
child process to main process UDP socket. It would ensure UDP check is 
done at the main process, which might change current used resolver for 
following TCP connections too.


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

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From c02cfcb0a358e04636ffd2bcc595860b25b3a440 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Wed, 17 May 2023 21:40:19 +0200
Subject: [PATCH] Add --dns-tcp-timeout option

Changes send timeout of outgoing TCP connections. Allows waiting just
short time for successful connection before trying another server.
Makes possible faster switch to working server if previous is not
responding. Default socket timeout seems too high for DNS connections.
---
 man/dnsmasq.8 |  4 
 src/config.h  |  1 +
 src/dnsmasq.h |  1 +
 src/forward.c | 10 --
 src/option.c  | 10 +-
 5 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 30429df..94fd5b1 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -860,6 +860,10 @@ where this needs to be increased is when using web-server log file
 resolvers, which can generate large numbers of concurrent queries. This
 parameter actually controls the number of concurrent queries per server group, where a server group is the set of server(s) associated with a single domain. So if a domain has it's own server via --server=/example.com/1.2.3.4 and 1.2.3.4 is not responding, but queries for *.example.com cannot go elsewhere, then other queries will not be affected. On configurations with many such server groups and tight resources, this value may need to be reduced.
 .TP
+.B --dns-tcp-timeout=
+Sets send timeout for forwarded TCP connections. Can be used to reduce time of waiting
+for successful TCP connection. Default value 0 skips the change of it.
+.TP
 .B --dnssec
 Validate DNS replies and cache DNSSEC data. When forwarding DNS queries, dnsmasq requests the 
 DNSSEC records needed to validate the replies. The replies are validated and the result returned as 
diff --git a/src/config.h b/src/config.h
index 88cf72e..5fd5cdf 100644
--- a/src/config.h
+++ b/src/config.h
@@ -61,6 +61,7 @@
 #define LOOP_TEST_TYPE T_TXT
 #define DEFAULT_FAST_RETRY 1000 /* ms, default delay before fast retry */
 #define STALE_CACHE_EXPIRY 86400 /* 1 day in secs, default maximum expiry time for stale cache data */
+#define TCP_TIMEOUT 0 /* timeout of tcp outgoing connections */
  
 /* compile-time options: uncomment below to enable or do eg.
make COPTS=-DHAVE_BROKEN_RTC
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 2f95c12..4113ccb 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -1256,6 +1256,7 @@ extern struct

Re: [Dnsmasq-discuss] dnsmasq sending advertise packets for the packet containing server id

2023-05-19 Thread Petr Menšík
Just for pure interest, can you share what test suite are you using? Is 
that open source?


On 5/3/23 06:23, shashikumar Shashi wrote:

Hi Simon,

While validating the RFC 3315 standards through the test suite caught 
this issue.


Thanks,
Shashi

On Tue, May 2, 2023 at 4:05 AM Simon Kelley  
wrote:


On 24/04/2023 05:41, shashikumar Shashi wrote:
> Hi,
>
> I am using dnsmasq-2.80, IN this I am observing dnsmasq sending the
> advertising packets for the packet containing the Server id.
> This is a violation of the RFC -
> https://www.rfc-editor.org/rfc/rfc3315#section-15.2
> <https://www.rfc-editor.org/rfc/rfc3315#section-15.2>
>
> Below is my packet:
> 0x:  0001 0002 0050 5696 5000 86dd 6000
> 0x0010:  003a 11ff fe80    0250
> 0x0020: 56ff fe96 5000 ff02    
> 0x0030:  0001 0002 0222 0223 003a ac9b 01ac
> 0x0040: 1a04 0002 0012 554e 5553 4544 2d53 4552
> 0x0050: 5645 522d 4455 4944 0001 0004 3e74 dd1b
> 0x0060: 0003 000c 6848 70e4    
>
>
> Is there any known issue??
>


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


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

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


Cheers,

Simon.

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


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


--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] [PATCH] TCP client timeout setting

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


The problem is if the client chooses to use TCP for whatever reason, 
dnsmasq will never switch to actually working server until some UDP 
request arrives to trigger re-evaluation of last_server responsiveness. 
It might do so, but just inside single TCP process. It just stubbornly 
forwards even 5th retry to the same server now, when another one might 
be able to answer right away.


I think the proper solution would be implementation of event driven 
reading of TCP sockets in the main process. I don't think using threads 
is possible, because quite a lot of globals used. It should not fork 
another processes without --no-daemon parameter, but just use poll() to 
watch socket readiness, then read whatever is prepared already. Since 
TCP DNS message says its length at the start, it can just allocate 
buffer big enough for that connection and iteratively read without 
blocking. Once it is read, it can parse it, process it. A bit of socket 
magic would be required, but similar approach could solve also sending 
with multiple calls without blocking. That would be big change however.


I think some feedback should be delivered to main dnsmasq process from 
tcp processing children, just like cache is updated from 
cache_end_insert(). I think it should be able to switch last_server used 
due to feedback from tcp client process. I even think there should be 
different last_server for UDP and different for TCP, but not untill TCP 
can report issues too. But not sure what approach to choose. At first I 
though about special F_flag, but all bits for cache record (struct crec) 
are already used.


Alternative quick-fix might be in case the TCP request sending fails to 
some server to generate UDP request with EDNS header added from tcp 
child process to main process UDP socket. It would ensure UDP check is 
done at the main process, which might change current used resolver for 
following TCP connections too.


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

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From c02cfcb0a358e04636ffd2bcc595860b25b3a440 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Wed, 17 May 2023 21:40:19 +0200
Subject: [PATCH] Add --dns-tcp-timeout option

Changes send timeout of outgoing TCP connections. Allows waiting just
short time for successful connection before trying another server.
Makes possible faster switch to working server if previous is not
responding. Default socket timeout seems too high for DNS connections.
---
 man/dnsmasq.8 |  4 
 src/config.h  |  1 +
 src/dnsmasq.h |  1 +
 src/forward.c | 10 --
 src/option.c  | 10 +-
 5 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 30429df..94fd5b1 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -860,6 +860,10 @@ where this needs to be increased is when using web-server log file
 resolvers, which can generate large numbers of concurrent queries. This
 parameter actually controls the number of concurrent queries per server group, where a server group is the set of server(s) associated with a single domain. So if a domain has it's own server via --server=/example.com/1.2.3.4 and 1.2.3.4 is not responding, but queries for *.example.com cannot go elsewhere, then other queries will not be affected. On configurations with many such server groups and tight resources, this value may need to be reduced.
 .TP
+.B --dns-tcp-timeout=
+Sets send timeout for forwarded TCP connections. Can be used to reduce time of waiting
+for successful TCP connection. Default value 0 skips the change of it.
+.TP
 .B --dnssec
 Validate DNS replies and cache DNSSEC data. When forwarding DNS queries, dnsmasq requests the 
 DNSSEC records needed to validate the replies. The replies are validated and the result returned as 
diff --git a/src/config.h b/src/config.h
index 88cf72e..5fd5cdf 100644
--- a/src/config.h
+++ b/src/config.h
@@ -61,6 +61,7 @@
 #define LOOP_TEST_TYPE T_TXT
 #define DEFAULT_FAST_RETRY 1000 /* ms, default delay before fast retry */
 #define STALE_CACHE_EXPIRY 86400 /* 1 day in secs, default maximum expiry time for stale cache data */
+#define TCP_TIMEOUT 0 /* timeout of tcp outgoing connections */
  
 /* compile-time options: uncomment below to enable or do eg.
make COPTS=-DHAVE_BROKEN_RTC
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index 2f95c12..4113ccb 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -1256,6 +1256,7 @@ extern struct

Re: [Dnsmasq-discuss] Filtering non-latin1 or non-ASCIII dns requests?

2023-05-11 Thread Petr Menšík
Okay, I understand. I think one possible defense would be enabling 
dnssec validation. I doubt CitiBαnk.com. can be registered at any 
serious domain. I am quite sure .com domain has rules to disallow 
registering that. The reason is obvious and you are not the only one 
thinking about that. There are even more similar letters in other 
alphabets. I still think the proper place for defenses are at domain 
registrars. I doubt that name is possible to register in any common TLD, 
there would be a lot of people registering that already, just to misuse 
them. So basic protection against that is already in place. Can you name 
any real registered domain, which impersonates similar domain this way?


It seems to me more proper protection would be using some recursive 
server applying additional block lists, which would block problematic 
domains. Creating and maintaining such list is more difficult than 
rejecting all IDN domains, but should provide significantly more 
security. Sadly nothing we can implement at simple cache as is dnsmasq. 
I understand US citizens do not consider non-ASCII names important or 
even suspicious, but I doubt very much they posses significant danger to 
any your network users. I am quite sure common TLD do not allow names 
differing in just few letters, others would be suspicious right away 
even to your children.


Seriously, if you want better protection, use real kind of protection 
instead. Something like servers 1.1.1.2 or 1.0.0.2 offering serious 
protection. Visit [1], other providers often have similar alternatives. 
I think hacks like you are proposing will offer just false sense of 
"more secure" network. Attackers often upload malicious code to genuine 
domains because of unfixed security issues. Bots are searching for such 
holes all over the internet. Expectation that such attacks will come 
just from strange looking domains only is very naive.


But if you would insist, I am thinking whether some scriptable rules 
written for example in lua could be supported in dnsmasq. Something 
which could test queried name dynamically, without listing all idn 
domains as blocked explicitly. I am not sure whether regular expressions 
filter would be enough. Rejecting any name matching "\.xn--.*" or 
"xn--.*" might be able to reject name containing IDN anywhere in the 
name. I think there are more important features missing.


Just my 2 cents,
Petr

|[1] https://developers.cloudflare.com/1.1.1.1/setup/|||

On 5/11/23 19:18, bur...@burtonstrauss.us wrote:


The use case I'm defending against have been recent reports of 
standard *looking* domains with Greek or Cyrillic characters that 
appear like very similar to their Western alphabet counterparts: 
CitiBank.com vs. CitiB(Greek alpha)nk.com, (I don’t think this comes 
through the mailing list) CitiBank.com vs. CitiBαnk.com.


I click on the link and maybe behind the page, the browser translates 
it to something else, but all I see is what looks like my Bank’s URL 
until it’s too late.


https://www.whois.com/whois/citibank.com

https://www.whois.com/whois/citib%CE%B1nk.com

BTW, that last domain is available!

If once a year that means I can’t download the driver for my LILYGO 
T-SIM7000G without special effort… s’be’it. That would be a purposeful 
measured action. I know it’s narrow minded and everything, for my 
personal/household daily surfing, I’m just not interested in IDN 
(https://newgtlds.icann.org/en/about/idns).


Given that the risks are real, I’m back in the white-bread ‘murica 
only Internet where a URI/URL was


   “A URI is composed from a limited set of characters consisting of

   digits, letters, and a few graphic symbols.  A reserved subset of

   those characters may be used to delimit syntax components within a

   URI while the remaining characters, including both the unreserved set

   and those reserved characters not acting as delimiters, define each

   component's identifying data.” (RFC3986, RFC3305 or even earlier)

Specific answers to your ?s: “Burton, the feature you are asking for 
would be blocking IDNA domains?” YES


As for your scale question, my firewall is a disgustingly beefy 65W 
i5-8400 (Coffee Lake) with 6 cores and 24Gb of RAM. Load average is 
0.00. Free memory is 22.9GiB. I upgraded packages this morning and 
dnsmasq has used 7 seconds of CPU in 5 hours.


(What can I say? It was the cheap box that week at MicroCenter when I 
went shopping – in my hands NOW instead of waiting two weeks for box 
half as capable to save $100??) (Could I run it as a VM on my ESXi 
box? Sure – I used to do that before I decided to use a real NIC for 
the firewall instead of a USB “gigabit” ethernet adapter) (But where 
is the fun in THAT?)


-Burton

-Original Message-
From: Dominik Derigs 
Sent: Thursday, May 11, 2023 11:40 AM
To: Petr Menšík ; 
dnsmasq-discuss@lists.thekelleys.org.uk; B@us 
Subject: Re: [Dnsmasq-discuss] Filtering non-latin1 or non-ASCIII dns 
r

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

2023-05-11 Thread Petr Menšík
Use host-record=example.com,IP instead. Use host-record=example.com,:: 
if that name does not have IPv6 address. Do you need to override any 
records queries for that name, not just addresses?


On 5/8/23 08:23, public1020 via Dnsmasq-discuss wrote:

I want dnsmasq to do exact match, e.g "address=/example.com/IP" should only 
match example.com, not *.example.com.

Does dnsmasq support that?

--- Original Message ---
On Monday, May 8th, 2023 at 1:49 PM, Monthly Posting 
 wrote:



On Mon, May 08, 2023 at 03:45:29AM +, public1020 wrote:


I'm trying to use dnsmasq to hijack example.com, but not
api.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?


Play with two changes in the configuration:

api.example.com=valid_address
example.com=hijack_address


See manual page for actual syntax.
Karma bonus points for sharing what works.


Regards
Monthly Posting
--
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2023q2/017067.html


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


Re: [Dnsmasq-discuss] Filtering non-latin1 or non-ASCIII dns requests?

2023-05-11 Thread Petr Menšík
I think there might be a way to reject all IDN names, which start with 
xn-- prefix. Which is present in all ascii forms of incoming names, 
which contain non-ascii characters, encoded in IDN 2008. That might 
help. I am not sure there is existing option to block any name 
containing such label.


On 5/11/23 04:12, B@us wrote:


I realize this breaks many standards. But the reality for most small 
installations is we have no real business visiting sites with 
non-ASCII domain names. I’m thinking of protecting against the Greek 
“α” which looks a lot like the letter “a”.


Is there an easy way to translate domains that don’t match 
\.[A-Za-z0-9]\. to 127.0.0.1?


Thanks!



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


Re: [Dnsmasq-discuss] Filtering non-latin1 or non-ASCIII dns requests?

2023-05-11 Thread Petr Menšík
Is there any specific reason why would you want to block all IDN domains 
in your dnsmasq? What attack would you like to prevent? Can you share 
examples where this would help?


I think this is a primary job for domain registrators, which should 
prevent registrations of mixed alphabets to prevents spoofing of 
selected letters. If they don't, I think it is possible to block whole 
TLD where this is allowed. There is no good solution for dnsmasq to do 
such thing. I think it should not be done on client side and especially 
not this way. I would recommend using RPZ driven blocklist in bigger 
resolver, which would block only known bad sites.


On 5/11/23 04:12, B@us wrote:


I realize this breaks many standards. But the reality for most small 
installations is we have no real business visiting sites with 
non-ASCII domain names. I’m thinking of protecting against the Greek 
“α” which looks a lot like the letter “a”.


Is there an easy way to translate domains that don’t match 
\.[A-Za-z0-9]\. to 127.0.0.1?


Thanks!


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


Re: [Dnsmasq-discuss] Implement --no-dns-interface?

2023-05-02 Thread Petr Menšík
I think you can use --bind-interfaces and --listen-address 127.0.0.2 to 
listen only on alternate address.


On 21. 04. 23 3:18, Tony Zhou wrote:

Hi,

I am running dnsmasq 2.86 on openwrt, and have multiple vlans in my 
network. dnsmasq works great for dhcp purposes (for both dynamic and 
static leases) that I need for all interfaces/vlans. However, some of 
the vlans I do not need/want to have dnsmasq providing dns, but 
another dns server for content filtering purposes.


I'd prefer to keep both dns servers on the same host/router, but the 
way dnsmasq works, either binding to interfaces, or wildcard, binds to 
all port 53, so that the 2nd dns server can't bind.


It appears that when dnsmasq is set to bind to interfaces, it has to 
either offer both dns and dhcp, or skip dhcp by "--no-dhcp-interface" 
argument, but there is no counterpart "--no-dns-interface".


Setting port=0 disables dns service on all interfaces, which is not 
what I wanted as well.


I did found there were two discussions regarding this:

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2011q4/005335.html 



https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q3/015429.html 



Running two instances of dnsmasq doesn't resolve this issue, since I 
still rely on dnsmasq's dhcp.



Thanks.



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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


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

2023-04-19 Thread Petr Menšík

On 17. 04. 23 15:57, Simon Kelley wrote:


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



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


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


I thought dnsmasq does not do anything special with cnames. Just caches 
it for the name, which reply contained it. I thought it does not insert 
separate CNAME entries into the cache. But haven't looked how the cache 
looks like. Anyway, if any part of the name chain is not signed, I think 
it is okay to mark also signed parts without AD bit. For majority of 
uses it won't make a difference.



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



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


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


Something like

server=/example.com/1.2.3.4

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


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


No, what I had on mind were connections of Network Manager. Those listed 
by "nmcli c" command. While majority of network resolvers works just 
fine with DNSSEC validation, it may cause issues on some. Network 
Manager reconfigures dnsmasq via DBus call setting servers. It would be 
nice if it could also disable validation on servers from known 
connection, where resolvers do not forward EDNS with DO=1 bit back to 
client.


Because dnssec validation can be enabled only always or never, it cannot 
adjust automatically if I move with my laptop to another wi-fi network. 
Or there would have to be something to stop dnsmasq, (re)create 
configuration snippet and restart it. It would be better if global 
dnssec validation status could be toggled runtime. Even better if just 
servers provided by NM from affected connection, lets say wifi SSID of 
train network, could be marked non-validating. Ie. not per domain, but 
per server. Not sure it it is possible to use server=/./1.2.3.4 to 
disable DNSSEC on that server. I expect because trust anchor would be 
defined for root, it would do validation for it.


For example unbound-control has optional +i flag for forwarding zone, 
which means for these servers ignore validation. It is sort of 
per-domain usually, but can be done also for root zone forwarder.





Cheers,

Simon.



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

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

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


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


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


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


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


A real wor

Re: [Dnsmasq-discuss] Confusion about "no address range available for DHCPv6 request via ..."

2023-04-19 Thread Petr Menšík
Are you aware that 80 on the end of dhcp-range is lease time, not any 
prefix size? Consider using of constructor:tapvm4qyj3a instead of manual 
end address. If I see correctly the end address is the same as the start 
address. Not sure how this should behave, but I would not be surprised 
if it did not work.


Try this:

dhcp-range=2a01:4f9:2b:35a:7df2::2,constructor:tapvm4qyj3a,80

On 18. 04. 23 10:40, Daniel Farina wrote:

Hello everyone,

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


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


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

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


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

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

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


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

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

...

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


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


Thank you for considering my question.

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


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

2023-04-17 Thread Petr Menšík

Hi!

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


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


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


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


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

Cheers,
Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 7abc1f58988b1f299ce1dd008c48890314f3581b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Thu, 13 Apr 2023 14:31:22 +0200
Subject: [PATCH 2/2] Small optimization around dbus socket events

Reduce calls to fd_search function and use get or set all flags by a
single call. Then do some bit operations and set the flags.

This is done in hope compiler will be optimize separate flag checks and
using just single integer. DBUS_WATCH_READABLE should equal to POLLIN on
normal system anyway.
---
 src/dbus.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/src/dbus.c b/src/dbus.c
index c2142b4..f58fb46 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -961,14 +961,14 @@ void set_dbus_listeners(void)
   {
 	unsigned int flags = dbus_watch_get_flags(w->watch);
 	int fd = dbus_watch_get_unix_fd(w->watch);
+	int poll_flags = POLLERR;
 	
 	if (flags & DBUS_WATCH_READABLE)
-	  poll_listen(fd, POLLIN);
-	
+	  poll_flags |= POLLIN;
 	if (flags & DBUS_WATCH_WRITABLE)
-	  poll_listen(fd, POLLOUT);
+	  poll_flags |= POLLOUT;
 	
-	poll_listen(fd, POLLERR);
+	poll_listen(fd, poll_flags);
   }
 }
 
@@ -982,14 +982,13 @@ static int check_dbus_watches()
   {
 	unsigned int flags = 0;
 	int fd = dbus_watch_get_unix_fd(w->watch);
-	
-	if (poll_check(fd, POLLIN))
+	int poll_flags = poll_check(fd, POLLIN|POLLOUT|POLLERR);
+
+	if ((poll_flags & POLLIN) != 0)
 	  flags |= DBUS_WATCH_READABLE;
-	
-	if (poll_check(fd, POLLOUT))
+	if ((poll_flags & POLLOUT) != 0)
 	  flags |= DBUS_WATCH_WRITABLE;
-	
-	if (poll_check(fd, POLLERR))
+	if ((poll_flags & POLLERR) != 0)
 	  flags |= DBUS_WATCH_ERROR;
 
 	if (flags != 0)
-- 
2.39.2

From 9ac7a5433527f88b3603c00769c4545011abaa17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Thu, 13 Apr 2023 12:59:17 +0200
Subject: [PATCH 1/2] Watch modification of dbus watches list

If watches are modified during dbus_watch_handle() call, existing
watch pointers might be invalidated. Always restart the loop if
modification is detected. Should prevent crashes when dbus service is
restarted.
---
 src/dbus.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/src/dbus.c b/src/dbus.c
index 360985a..c2142b4 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -106,6 +106,7 @@ const char* introspection_xml_template =
 "\n";
 
 static char *introspection_xml = NULL;
+static int watches_modified = 0;
 
 struct watch {
   DBusWatch *watch;  
@@ -127,6 +128,7 @@ static dbus_bool_t add_watch(DBusWatch *watch, void *data)
   w->watch = watch;
   w->next = daemon->watches;
   daemon->watches = w;
+  watches_modified++;
 
   (void)data; /* no warning */
   return TRUE;
@@ -134,7 +136,7 @@ static dbus_bool_t add_watch(DBusWatch *watch, void *data)
 
 static void remove_watch(DBusWatch *watch, void *data)
 {
-  struct watch **up, *w, *tmp;  
+  struct watch **up, *w, *tmp;
   
   for (up = &(daemon->watches), w = daemon->watches; w; w = tmp)
 {
@@ -143,6 +145,7 @@ static void remove_watch(DBusWatch *watch, void *data)
 	{
 	  *up = tmp;
 	  free(w);
+	  watches_modified++;
 	}
   else
 	up = &(w->next);
@@ -969,11 +972,11 @@ void set_dbus_listeners(void)
   }
 }
 
-void check_dbus_listeners()
+static int check_dbus_watches()
 {
-  DBusConnection *connection = (DBusConnection *)daemon->dbus;
   struct watch *w;
 
+  watches_modified = 0;
   for (w = daemon->watches; w; w = w->next)
 if (dbus_watch_get_enabled(w->watch))
   {
@@ -990,9 +993,22 @@ void check_dbus_listeners()
 	  f

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

2023-04-16 Thread Petr Menšík
wer it needs to 
validate, those records are necessarily cached in knot or unbound 
because they've already done validation.


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


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


Cheers,

Simon.


It seems to be just confusion caused by how dnssec status is presented 
in pi-hole interface. I think most resolvers answers with AD bit even if 
EDNS0 were not present in the initial query. Recent unbound certainly 
does so.


$ dig @localhost +noedns | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

I know only systemd-resolved uses some EDNS0 options to inform upstream 
of its supported DNSSEC algorithms. I know no other implementation 
sending such list. Otherwise status of DNSSEC validation is unrelated to 
EDE. Except in validation failures, but they would usually cause 
SERVFAIL, which means no caching anyway.





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

Hi

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

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

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

- knot resolver has DNSSEC capabilities.

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

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

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

Since, in my opinion, it isn't very efficient to have unbound OR
knot-resolver validate DNSSEC, then forward the reply to dnsmasq, and
let dnsmasq do the DNSSEC validation all over again, I want to use
proxy-dnssec, thus evaluating the DNSSEC info, using the data already
available in EDE, supplied by unbound or knot-resolver.

Dominik, your questions and comments.

Thanks for explaining "add-cpe-id=01234", meaning that it informs
upstream that it is capable of processing EDNS data, nothing more.
This implies dnsmasq cannot be the cause of "not receiving EDE" data?
As I understood from you comments on discourse, the same could be
achieved with "add-mac=base64"?

Since you "somewhat" agree this might be caused by unbound, NOT
caching EDE data, it was my intention to wait for the unbound PRs to
be merged into master, than restart testing (unless instructed
otherwise by one of you).

I started posting only, because another pi-hole user is also testing
the feature (proxy-dnssec), and noticed the same inconsistencies, be
it under different circumstances (docker, using dnsmasq
cache-size=1, no redis, ...)

I don't really understand why dig queries (both on the pi-hole
terminal and from a remote windows machine always provide the correct
status (SECURE), while site visits, using a browser provide
inconsistent statuses (SECURE / INSECURE) I assume dig replies are
also cached...

Again, thank you both for your interest in this, your valuable time 
and effort.


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


Re: [Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA

2023-04-11 Thread Petr Menšík
 <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


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


Re: [Dnsmasq-discuss] dnsmasq reverse auth zone transfers

2023-04-03 Thread Petr Menšík
ey might be missing.
Explain them the cool thing that you want, aim for
common interrest.


> Thanks a lot in advance

No, not accepted.
Express "thanks" when you get something usefull.


> Regards
> Juanca



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





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


--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] [PATCH] Report filtered A or AAAA records via EDE code

2023-03-31 Thread Petr Menšík

I agree with Dominik.

--cache-rr=!TXT,!DNSKEY,!DS or maybe just --no-cache-rr=TXT,DNSKEY,DS

would be more useful.

For my own preference it would be more useful to cache ANY record by 
default, maybe with exceptions of explicitly listed records. I think it 
would be nice to specify maximal record set size instead. On memory 
constrained devices it might choose to not cache rrset records longer 
than 32B for example. Addresses might have exception for that. I think 
usually it does not matter if that is OPENPGPKEY or TXT. I think only 
what matters is how long the record is and how often it is queried. 
--no-cache-rrset-over=120 might be an example.


Larger records should have slightly higher chance to be pushed out from 
the cache. I think that were not changed yet. Does existing code prefer 
to release bigger chunks from the cache?


I think also a cache summary should be requestable via dbus or signal. 
Something like X A records, 256B, Y  records, 600B, Z TXT records, 
1400B. Ideally also cache hits number or ratio for those types. 
Something which could briefly describe what current cache is holding. Do 
we have something like that already?


If we want to refuse caching of some records, we should have a better 
evidence whose tend to occupy memory without being much useful. I think 
we are making just educated guesses. On some networks it might be 
significantly different. Gathering a good default needs some evidence, 
which I think we are missing now. Bare total cache misses and hits are 
not enough IMO.



To the original issue with EDE code, thanks for that. The answer from 
IETF dnsop were indeed filtered might be not a correct one. Code 21 no 
supported were suggested, unless we define a better one. There is a new 
type defined Synthetized, but that has also somehow different usage. I 
have created feature request on bind [1], they have very similar 
functionality to filter out address records. Do not indicate modified 
answers with any code at the moment.


[1] https://gitlab.isc.org/isc-projects/bind9/-/issues/3979

On 3/31/23 09:25, Dominik Derigs via Dnsmasq-discuss wrote:

Hey Simon,

On Thu, 2023-03-30 at 18:28 +0100, Simon Kelley wrote:

I just merged the branch I've been working on for the last week which
includes this patch, but much modified because the surrounding code has
changed. The function is unaltered.

The other changes are adding the ability to cache any RR-type, and the
ability to filter any RR-type. There's quite a bit of code cleanup in
the affected code paths too.

The new man page says:

By default, dnsmasq caches A, , CNAME and SRV DNS

record types. This option adds other record types to the
cache. [...]

I wonder how useful this really is. Won't it cause config
files to explode with lines like (possibly line-per-line):
--cache-
rr=NS,MD,MF,SOA,MB,MG,MR,NULL,WKS,PTR,HINFO,MINFO,MX,TXT,RP,
AFSDB,X25,ISDN,RT,NSAP,NSAP_PTR,SIG,KEY,PX,GPOS,LOC,NXT,EID,
NIMLOC,ATMA,NAPTR,KX,CERT,A6,DNAME,SINK,OPT,APL,DS,SSHFP,IPS
ECKEY,RRSIG,NSEC,DNSKEY,DHCID,NSEC3,NSEC3PARAM,TLSA,SMIMEA,H
IP,NINFO,RKEY,TALINK,CDS,CDNSKEY,OPENPGPKEY,CSYNC,ZONEMD,SVC
B,HTTPS,SPF,UINFO,UID,GID,UNSPEC,NID,L32,L64,LP,EUI48,EUI64,
TKEY,TSIG,IXFR,AXFR,MAILB,MAILA,ANY,URI,CAA,AVC,DOA,AMTRELAY
,TA,DLV

if I want to cache all types known to dnsmasq by name (yes,
this does not include proprietary extensions by numbers). It
also seems inefficient to always loop over these 86 RR types
when we check if this RR is to be cached.


Since we have just binary indication for numberic type, I think we need 
just:


- default value
- array of uint8_t for bit indication for each specified type.
- array size would be max specified type / 8+1.
- over max value the default value would apply, no need to have full 
size bitmap.


This would be able to query type cacheability in linear way. No loops 
per each query should be necessary, should be quite fast. I think 
NSEC(3) uses similar kind of bit magic. Not sure that is decoded by 
dnsmasq anywhere in the code.


Unless we need dbus API to change cached types runtime, those would be 
initialized just once. Makes sense to spend time once during init and 
save it per-query.




Looking at this new option, it seems really counter-
intuitive to specify "I want to cache ANY but not TXT". Is
there a real-world scenario where someone would not like to
cache a specific type? I suppose these queries should
arguably have a TTL of 0 from upstream to prevent caching.

My feeling is that we should really have at least a shortcut
to specify "cache everything you can". May this be "--cache-
rr" without options, some special "--cache-rr=all" or maybe
a dedicated option like "--cache-all".

Others than that - thanks for working on this! I already
started testing (using the long command above) and will
report any oddities I come across.

Best,
Dominik


--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.

Re: [Dnsmasq-discuss] Allow IP address in nftset

2023-03-30 Thread Petr Menšík
I think IP addresses never make it to dnsmasq, they stay at clients. So 
dnsmasq cannot add them anywhere into tables. Domain name queries go 
trough dnsmasq so it can manage them. Is there something I am missing?


I think IP-only tables should be managed by something else than dnsmasq. 
I expect different tools can add into common table, but never tried myself.


On 3/26/23 23:10, Kurt Fitzner via Dnsmasq-discuss wrote:
Yes, it's OpenWrt.  I'm on master, recently compiled.  In general 
nftset works fine, it just only seems to work for hostnames and not 
for IP addresses:


nftset=/cooper.logs.roku.com/4#inet#fw4#adb4
nftset=/99.83.154.118/4#inet#fw4#adb4

The former works.  The latter never appears in the ruleset.

It would be handy if IP addresses could work too.  This would make it, 
for example, so that DoH blocklists (IP only) could work alongside 
adblock block lists (hostnames).


    Kurt

On 2023-03-26 17:33, Eric Fahlgren wrote:


Hi Kurt,

Could it be that your dnsmasq is too old?   Can I assume OpenWrt?  
Dnsmasq is currently at 2.86 on the release branch 22.03, and is 
missing the nftset stuff, but SNAPSHOT is at 2.89, so it should work 
there...


Eric

On Sun, Mar 26, 2023 at 1:15 PM Kurt Fitzner via Dnsmasq-discuss 
 wrote:


Is there a way to have dnsmasq support the use of IP addresses in 
nftset

directives?  I cannot get it to work, though I can't see any reason why
it shouldn't.

Thanks.

Kurt Fitzner


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


Re: [Dnsmasq-discuss] DNSMASQ on Ubuntu VirtualBox.

2023-03-22 Thread Petr Menšík
Have you checked the contents of /etc/hosts file? Sometimes the local 
hostname is added there to save resolution of local hostname again and 
again. Could its record override address= you wanted to assign? I doubt 
there is defined and documented order if they conflict.


Does you /etc/hosts contain:

127.0.0.1 localhost xxx  ?

it might help if you remove expand-hosts from dnsmasq configuration and 
use aliases in the file itself. But avoid conflicting definition with 
dnsmasq. Consider also using host-record, which will match only 
xxx.mydomain.com, not example.xxx.mydomain.com.


Cheers,
Petr

On 3/20/23 18:15, Paul Constantine wrote:

So here is my DNSMASQ problem.
I'm running to VirtualBox Ubuntu 16.04 servers on two seperate 2011 
mac mini servers (macos High Sierra).
Each of the two VirtualBox Ubuntu servers runs a LAMP website (Drupal 
based) and a DNSMASQ dns server.
The network is controlled by a Fritz!Box 7590. In the configuration 
the two different DNSMASQ servers are listed instead of the standard 
provider DNS.

VirtualBox One:
    static IP     192.168.2.50
    website IP     192.168.2.50    xxx.mydomain.com
    DNSMASQ IP     192.168.2.50
VirtualBox Two:
    static IP     192.168.2.55
    website IP     192.168.2.55    yyy.mydomain.com
    DNSMASQ IP     192.168.2.55
Fritz!Box (router)
    Gateway        192.168.2.1
    DHCP        192.168.2.100-200
So far so good. This setup seemed to have worked for hals a year. Then 
recently I had to restore one of the VirtualBox servers. And now it 
only works somewhat. In short:
Each of the two DNSMASQ servers will only resolve the website on the 
other VirtualBox, the website on the same VirtualBox will resolve to 
localhost.
So if I want to be able to reach the domain in VirtualBox One I have 
to use the DNSMASQ server in VirtualBox Two and the other way around.
Here is the dnsmasq.conf file from VirtalBox Two (for Box One just 
substitute the 192.168.2.50 for 192.168.2.55).

cat /etc/dnsmasq.conf

# DNS configuration
port=53
#/etc/dnsmasq.conf
domain-needed
bogus-priv
expand-hosts

# The address 192.168.2.55 is the static IP of this server
# You can find this ip by running ifconfig and look for the
# IP of the interface which is connected to the router.
listen-address=127.0.0.1
listen-address=192.168.2.55
bind-interfaces

# Use open source DNS servers
server=8.8.8.8
server=8.8.4.4

# Create custom 'domains'.
# Custom 'domains' can also be added in /etc/hosts
address=/xxx.mydomain.com/192.168.2.50
address=/yyy.mydomain.com/192.168.2.55
# address=/www.anotherdomain.com/192.168.2.50
# address=/anotherdomain.com/192.168.2.50
# address=/www.stillanotherdomain.ch/192.168.2.50
# address=/stillanotherdomain.ch/192.168.2.50

I am not very experienced with DNS servers, so can you possible point 
me in the right direction if you see an error.

Thanks
Paul


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


Re: [Dnsmasq-discuss] [PATCH] Report filtered A or AAAA records via EDE code

2023-03-21 Thread Petr Menšík

On 3/17/23 19:08, Simon Kelley wrote:
I think that looks like a sensible change. I'm slightly worried about 
the definition of EDE_FILTERED


4.18. Extended DNS Error Code 17 - Filtered
    The server is unable to respond to the request because the domain is
    on a blocklist as requested by the client. Functionally, this
    amounts to "you requested that we filter domains like this one."

Which talks about domains and not RRtypes. You can imagine a client 
noting that a domain is filtered and not sending other queries for the 
domain, when in this case they are fine, it's the RRtype which is 
being filtered.



Simon.

Yes, I have noticed that too. But there does not seem to be any code 
better suited for filtered RRtypes. Do you know any software doing such 
decisions based on just EDE code? It would make sense to do so based on 
NXDOMAIN response, marked also with Filtered code. But by NOERROR 
response code we clearly indicate such domain is there and may return 
something for different types. I think response code has stronger 
authority than EDE code.


Alternatively we would have to request another code registered for 
filtered types only. I think asking on dnsop for opinions would not hurt.


Cheers,
Petr

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


Re: [Dnsmasq-discuss] [RFC PATCH v3] Add support for blocking A or AAAA queries per domain

2023-03-21 Thread Petr Menšík
1,7 +21,7 @@ static int order_qsort(const void *a, const void *b);
  static int order_servers(struct server *s, struct server *s2);

  /* If the server is USE_RESOLV or LITERAL_ADDRES, it lives on the 
local_domains chain. */
-#define SERV_IS_LOCAL (SERV_USE_RESOLV | SERV_LITERAL_ADDRESS)
+#define SERV_IS_LOCAL (SERV_USE_RESOLV | SERV_LITERAL_ADDRESS | SERV_NODATA)

  void build_server_array(void)
  {
@@ -370,9 +370,11 @@ int is_local_answer(time_t now, int first, char *name)
int flags = 0;
int rc = 0;

-  if ((flags = daemon->serverarray[first]->flags) & SERV_LITERAL_ADDRESS)
+  if ((flags = daemon->serverarray[first]->flags) & (SERV_LITERAL_ADDRESS | 
SERV_NODATA))
  {
-  if (flags & SERV_4ADDR)
+  if (flags & SERV_NODATA)
+rc = F_NOERR;
+  else if (flags & SERV_4ADDR)
rc = F_IPV4;
else if (flags & SERV_6ADDR)
rc = F_IPV6;
diff --git a/src/option.c b/src/option.c
index 8e61a6b..6fe53a4 100644
--- a/src/option.c
+++ b/src/option.c
@@ -1095,7 +1095,7 @@ static char *domain_rev4(int from_file, char *server, 
struct in_addr *addr4, int
int i, j;
char *string;
int msize;
-  u16 flags = 0;
+  int flags = 0;
char domain[29]; /* strlen("xxx.yyy.zzz.ttt.in-addr.arpa")+1 */
union mysockaddr serv_addr, source_addr;
char interface[IF_NAMESIZE+1];
@@ -1178,7 +1178,7 @@ static char *domain_rev6(int from_file, char *server, 
struct in6_addr *addr6, in
int i, j;
char *string;
int msize;
-  u16 flags = 0;
+  int flags = 0;
char domain[73]; /* strlen("32*ip6.arpa")+1 */
union mysockaddr serv_addr, source_addr;
char interface[IF_NAMESIZE+1];
@@ -2966,7 +2966,7 @@ static int one_opt(int option, char *arg, char *errstr, 
char *gen_err, int comma
  case 'A':/*  --address */
{
char *lastdomain = NULL, *domain = "", *cur_domain;
-   u16 flags = 0;
+   int flags = 0;
char *err;
union all_addr addr;
union mysockaddr serv_addr, source_addr;
@@ -3002,6 +3002,12 @@ static int one_opt(int option, char *arg, char *errstr, 
char *gen_err, int comma
/* # as literal address means return zero address for 4 and 6 */
if (strcmp(arg, "#") == 0)
  flags = SERV_ALL_ZEROS | SERV_LITERAL_ADDRESS;
+   /* `!A` means return NODATA for A queries */
+   else if (strcmp(arg, "!A") == 0)
+ flags = SERV_4ADDR | SERV_NODATA;
+   /* `!` means return NODATA for  queries */
+   else if (strcmp(arg, "!") == 0)
+ flags = SERV_6ADDR | SERV_NODATA;
else if (inet_pton(AF_INET, arg, ) > 0)
  flags = SERV_4ADDR | SERV_LITERAL_ADDRESS;
else if (inet_pton(AF_INET6, arg, ) > 0)
@@ -3019,7 +3025,20 @@ static int one_opt(int option, char *arg, char *errstr, 
char *gen_err, int comma
  flags |= SERV_FROM_FILE;

cur_domain = domain;
-   while ((flags & SERV_LITERAL_ADDRESS) || parse_server_next())
+   if (flags & SERV_NODATA)
+ {
+   while (1)
+ {
+   if (!add_update_server(flags, sdetails.addr, sdetails.source_addr, 
sdetails.interface, cur_domain, ))
+ ret_err(gen_err);
+
+   if (!lastdomain || cur_domain == lastdomain)
+ break;
+
+   cur_domain += strlen(cur_domain) + 1;
+ }
+ }
+   else while ((flags & SERV_LITERAL_ADDRESS) || 
parse_server_next())
  {
cur_domain = domain;


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


Re: [Dnsmasq-discuss] Picking up the patches

2023-03-17 Thread Petr Menšík
Could we perhaps make some service, which would gather list of patches 
sent to mailing list. And if Simon would not respond to it in any way, 
it would make a list of sender, subject and name of patches in a summary.


If no response were say in a week, it might send a summary mail with a 
list of such pending patches. Maybe supporting some keywords to mark a 
reason, why it is not merged (yet).


It might be doable

Examples:

[merged] - merged as it is. In some cases this could be detected without 
any message by watching git repo.


[modified] - merged by a different change. Solved the problem in a 
different way.


[modify] - request to make a changes in patch, is waiting on the 
contributor to do so


[refused] - stating such change won't be merged even with small 
modifications, stop tracking that patch.


Altough it would be much easier if Simon would accept also pull requests 
on any kind of git hosting service, which already provides a way to 
create pull request, which can be commented on, merged or closed. 
Services like github.com, gitlab or pagure already implements similar 
workflows.


But above proposal would allow Simon just add those keywords into his 
reply and otherwise do not change his way of processing incoming 
patches. It would require to do some coding by us and hosting such 
service somewhere.


Maybe even very simple reminder threads containing patches do not 
contain any message for some time from Simon would help. Looking at 
pipermail threads page, some hacking at HTML level in python might solve 
that. Ideally with once a day generated page of links to messages 
waiting for any comment, which could be checked any time.


On 3/16/23 22:51, Geert Stappers wrote:

Hi,

How can I help that patches get the attention that they deserve?


Groeten
Geert Stappers


On Wed, Mar 08, 2023 at 03:38:02PM +, Simon Kelley wrote:

On 07/03/2023 23:20, Clayton Craft wrote:

On Thu, 23 Feb 2023 21:40:10 -0800 Clayton Craft wrote:

On Fri, 10 Feb 2023 13:53:05 -0800 Clayton Craft wrote:

Any chance this could get merged? Being able to set filters at runtime is very
useful for multi-homed phones and other devices in cases where we need to
restrict DNS response answers based on IP protocol.

Please let me know if I need to make changes so that it is acceptable.

Is this patch something that could be accepted?


Apologies for ignoring you. Patch looks fine. Applied to git repo.


Cheers,
Simon.


--
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] [PATCH] Report filtered A or AAAA records via EDE code

2023-03-16 Thread Petr Menšík

Hi!

I have raised filtering topic on DNS-OARC chat. One of proposals were to 
mark at least filtered records by EDE status, which current dnsmasq 
supports already. I like it. We create fake answer on when --filter-A or 
--filter- options is used. It should be marked somehow.


There is also proposal for more verbose error and contact information 
[1], but at least marking the response somehow synthetized is a good 
start. I attached a change to rrfilter to report number of modified 
records. Then it marks any filtered response with Filtered EDE code. I 
expect the same should be possible for any other record type filtered, 
except EDNS0 and DNSSEC records.


Credits for the idea goes to Vladimír Čunát. It might allow potential 
DNSSEC validator to not emit SERVFAIL on bogus answer we made. If that 
would trust our response for any reason.


What do you think?

By the way, maybe we should strip also RRSIG for those records if 
present. It looks like a bug to me. But would not make validating 
resolvers more happy anyway.


; <<>> DiG 9.18.12 <<>> -4 @localhost -p 2053 example.org a +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21029
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1220
; COOKIE: b2ad85a9275d948e02176a79641381dce6990a257f089ec5 (good)
; EDE: 17 (Filtered)
;; QUESTION SECTION:
;example.org.            IN    A

;; ANSWER SECTION:
example.org.        32748    IN    RRSIG    A 8 2 86400 20230323193411 
20230302075235 43798 example.org. 
QwrK73kR5vStRzG6IPOpYU2exzSIOatl1p8DffKi4PP2Ig8yAL43AhVu 
2bsA0I0EFINH3xvF2IiM7eyR/fMm8rfeAsG1pokOFOOhlYQQHhglgfu6 
mgNJnFrHUs3M+JNBNyAay42aSSDt5gXcvk77nx32uWv40pfknU7wH2Xc rP4=


[1] https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

From acb66a570a5e338a79160a8dd2b9e072ab8c5a81 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Thu, 16 Mar 2023 21:15:40 +0100
Subject: [PATCH] Report number of modified records from rrfilter()

Set EDE_FILTERED when filter-A or filter- caused some change. Pass
length value by pointer instead returning its new value. It assigned
into the same variable in all uses anyway.
---
 src/dnsmasq.h  |  2 +-
 src/edns0.c|  2 +-
 src/forward.c  | 12 
 src/rrfilter.c | 46 --
 4 files changed, 34 insertions(+), 28 deletions(-)

diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index fe9aa07..92cc291 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -1811,7 +1811,7 @@ void poll_listen(int fd, short event);
 int do_poll(int timeout);
 
 /* rrfilter.c */
-size_t rrfilter(struct dns_header *header, size_t plen, int mode);
+size_t rrfilter(struct dns_header *header, size_t *plen, int mode);
 u16 *rrfilter_desc(int type);
 int expand_workspace(unsigned char ***wkspc, int *szp, int new);
 /* modes. */
diff --git a/src/edns0.c b/src/edns0.c
index c498eb1..567101b 100644
--- a/src/edns0.c
+++ b/src/edns0.c
@@ -178,7 +178,7 @@ size_t add_pseudoheader(struct dns_header *header, size_t plen, unsigned char *l
 	memcpy(buff, datap, rdlen);	  
 	  
 	  /* now, delete OPT RR */
-	  plen = rrfilter(header, plen, RRFILTER_EDNS0);
+	  rrfilter(header, , RRFILTER_EDNS0);
 	  
 	  /* Now, force addition of a new one */
 	  p = NULL;	  
diff --git a/src/forward.c b/src/forward.c
index 0f03818..b95aa80 100644
--- a/src/forward.c
+++ b/src/forward.c
@@ -721,7 +721,7 @@ static size_t process_reply(struct dns_header *header, time_t now, struct server
 	  if (added_pheader)
 	{
 	  /* client didn't send EDNS0, we added one, strip it off before returning answer. */
-	  n = rrfilter(header, n, RRFILTER_EDNS0);
+	  rrfilter(header, , RRFILTER_EDNS0);
 	  pheader = NULL;
 	}
 	  else
@@ -814,11 +814,15 @@ static size_t process_reply(struct dns_header *header, time_t now, struct server
   /* Before extract_addresses() */
   if (rcode == NOERROR)
 	{
+	  size_t modified = 0;
 	  if (option_bool(OPT_FILTER_A))
-	n = rrfilter(header, n, RRFILTER_A);
+	modified = rrfilter(header, , RRFILTER_A);
 
 	  if (option_bool(OPT_FILTER_))
-	n = rrfilter(header, n, RRFILTER_);
+	modified += rrfilter(header, , RRFILTER_);
+
+	  if (modified > 0)
+	ede = EDE_FILTERED;
 	}
 
   switch (extract_addresses(header, n, daemon->namebuff, now, ipsets, nftsets, is_sign, check_rebind, no_cache, cache_secure, ))
@@ -860,7 +864,7 @@ static size_t process_reply(struct dns_header *header, time_t now, struct server
   
   /* If the requestor didn't set the DO bit, don't return DNSSEC info. */
   if (!do_bit)
-	n = rrfilter(header, n, RRFILTER_DNSSEC);
+	rrfilter(header, , RRFILTER_DNSSEC);
 }
 

Re: [Dnsmasq-discuss] State of blocking type=65 requests?

2023-03-16 Thread Petr Menšík
I do not like attempts to filter out valid queries from clients on the 
side of dns cache. It should cache the HTTPS type, which it currently 
does not. That makes those kind of queries much more expensive.


I think it should be fixed on the side of clients instead. If they ask 
for all addresses, just give them when they do exist. If the network is 
very expensive (can you be more concrete about type of connection?) then 
find a way to tell clients what it does provide (and what it does not). 
It does not provide IPv6? Well, then clients should not ask for it 
without a reason. They also have to be special on such expensive 
network, haven't they? I expect they have to be tuned somehow to avoid 
unnecessary network communication anyway.


What is a good response for  record, which may exist, but we pretend 
it does not? NODATA or REFUSED? All similar quirks break DNSSEC 
deployment. Would you want also EDNS0 extension stripped from forwarded 
queries? Or at least reset DO bit to 0 always? I would prefer if it 
could return REFUSED to queries it does not want to forward. Faking 
empty responses is poor man's choice just to dodge assumptions on 
multiple sides. But if it does not want to forward something , I think 
REFUSED would be correct response. It would also solve problem to decide 
whether to send NOERROR or NXDOMAIN. And would cause no forwarded 
queries of unwanted types.


If it would work the same way as faking empty responses, I would vote 
for --reject-rrset=https instead of --filter-rrset=https.  would be 
probably more difficult, because getaddrinfo(AF_UNSPEC) implementations 
may not handle REFUSED just one one of two queries well. But if browsers 
doing HTTPS would handle it better, please try that first. I admit I 
haven't tried. But HTTPS should not have similar legacy problems, it may 
work better.


Regards,
Petr

On 06. 03. 23 23:36, Ed W wrote:

Hi, can I get a leg up in understanding the options for blocking dns queries 
for a specific resource
type, specifically type 65 queries

I see there was a patch to implement a "filter-http" option here:

     https://github.com/rozahp/dnsmasq

It possibly seems like there is a filter- implemented in dnsmasq already, 
so I wonder if there
is appetite for the filter-http to also be accepted?


My motivation for needing this is that we operate a firewalling system for a 
very bandwidth
constrained system (even DNS is extremely expensive) and we operate a 'blocked 
unless whitelisted'
firewalling system. The type 65 queries are currently inhibiting some of the 
whitelisting
capability. Whilst we can potentially improve things, the short term solution 
would be to block type 65

I see that there is an option in pi-hole, but I'm looking for an option within 
dnsmasq, ideally
without maintaining my own out of tree patch


Have I missed a solution that is possible within vanilla dnsmasq?

Has the idea to implement a filter-http option been rejected already? (I'm 
happy to send a patch if
not?)


Thanks

Ed W


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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] Is leasquery supported in Dnsmasq

2023-03-14 Thread Petr Menšík
I looked into RFC 3046(DHCP Relay Agent Information Option) and it seems 
it suggests the DHCP server should assign address to triplets [1]:


(client IP address,  client MAC address,  client remote ID)

I am pretty sure dnsmasq does not use any client remote id at the moment 
to make mac addresses from different clients independent. Not sure how 
much common such configurations are and whether is it desirable to 
implement them. That RFC is from 2001.


But it seems leasequery purpose is not obtaining just status of 
leased/non-leased address, but also those ids. Because they are not 
defined as a simple integers but variable length binary ids, processing 
them would not be simple task. Dnsmasq lease database code does not have 
easily extendable database for any new key=value pair on leases, so this 
would be somehow difficult.


Also I think networks where multiple circuit ids appear should not rely 
on dnsmasq to do DHCP for them. I think such network deserves more 
heavy-weight DHCP server implementation, which should have support for 
storing (and querying) additional parameters. It might make sense to add 
configurable ids into forwarded requests when acting as relay agent though.


Cheers,
Petr

[1] https://www.rfc-editor.org/rfc/rfc3046#section-4.0

On 27. 02. 23 13:46, Simon Kelley wrote:
src/rfc2131.c has all the relevant code: add code to handle 
DHCPLEASEQUERY to the switch in dhcp_repy();


HOWEVER. Whilst the RFC sort of makes this sound like a general query 
system, it's actually a hack to solve a specific problem that access 
concentrators don't have persistent storage, so this allows them to 
rely on the DHCP server to persistently store Relay Agent Information



   If the Relay Agent Information (option 82) is specified in the
   Parameter Request List, then the information contained in the most
   recent Relay Agent Information option received from the relay agent
   associated with this IP address MUST be included in the
   DHCPLEASEACTIVE message.


This is the biggest problem, since dnsmasq doesn't store that 
information in its lease database either. Adding that info is a large 
undertaking, with compatibility risks.


The quote above make it clear that, even if you application doesn't 
need option 82 information, an RFC-compliant implementation of 
LEASEQUERY does, and it's not a small job.


Simon.





On 24/02/2023 19:10, Rashi Krishna wrote:
Thanks for the update. If I want to add the code myself, do you have 
any pointers to where to get started from?


Thanks again,
Rashi

On Fri, 24 Feb, 2023, 16:23 Nicolas Cavallari, 
<mailto:nicolas.cavall...@green-communications.fr>> wrote:


    On 24/02/2023 10:13, Rashi Krishna wrote:
 > Hi all.
 >
 > I just wanted to know if leasequery is supported in Dnsmasq. I 
tried
 > sending a leasequery to the server, but I couldn't get any 
response.


    There does not seem to be any leasequery (RFC 4388) support in 
dnsmasq.



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


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


--
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] [PATCH] Value stored to 'outmsgtype' is never read

2023-03-14 Thread Petr Menšík

Hi!

Our coverity scan detected new CLANG warning after I have cherry-picked 
commit 03345ecefeb0d82e3c3a4c28f27c3554f0611b39 [1] into our rhel8 
release. It reported it for 2.79 version, but even the last commit in 
master branch still has the same issue present. In attached patch I have 
suggested fix.


I am not sure how to trigger this code from the client, so this is not 
tested with real dhcp client. I track it under Fedora bug [2]. Coverity 
reported it as:


1. Defect type: CLANG_WARNING
1. dnsmasq-2.79/src/rfc3315.c:344:7: warning[deadcode.DeadStores]: Value stored 
to 'outmsgtype' is never read
#   342|
#   343|   {
#   344|->   outmsgtype = DHCP6REPLY;
#   345| o1 = new_opt6(OPTION6_STATUS_CODE);
#   346| put_opt6_short(DHCP6USEMULTI);

1. 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=03345ecefeb0d82e3c3a4c28f27c3554f0611b39

2. https://bugzilla.redhat.com/show_bug.cgi?id=2178069

--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 198f1971d80692582eb3206632873295ea725556 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Tue, 14 Mar 2023 12:39:56 +0100
Subject: [PATCH] Fix: Value stored to 'outmsgtype' is never read

Coverity detected bug since commit 03345ecefeb0d82e3c3a4c28f27c3554f0611b39,
there is assignment not used anymore. Assign the value to the actual
packet. Still present even in 2.89 version.

1. Defect type: CLANG_WARNING
1. dnsmasq-2.79/src/rfc3315.c:344:7: warning[deadcode.DeadStores]: Value stored to 'outmsgtype' is never read
   342|
   343|   {
   344|->   outmsgtype = DHCP6REPLY;
   345| o1 = new_opt6(OPTION6_STATUS_CODE);
   346| put_opt6_short(DHCP6USEMULTI);
---
 src/rfc3315.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/rfc3315.c b/src/rfc3315.c
index 8754481..1338c87 100644
--- a/src/rfc3315.c
+++ b/src/rfc3315.c
@@ -348,7 +348,7 @@ static int dhcp6_no_relay(struct state *state, int msg_type, unsigned char *inbu
   (msg_type == DHCP6REQUEST || msg_type == DHCP6RENEW || msg_type == DHCP6RELEASE || msg_type == DHCP6DECLINE))
 
 {  
-  outmsgtype = DHCP6REPLY;
+  ((unsigned char *)(daemon->outpacket.iov_base))[start_msg] = DHCP6REPLY;
   o1 = new_opt6(OPTION6_STATUS_CODE);
   put_opt6_short(DHCP6USEMULTI);
   put_opt6_string("Use multicast");
-- 
2.39.2

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


Re: [Dnsmasq-discuss] consider adding a `dnsmasq --no-read-or-load-any-config` feature?

2023-03-13 Thread Petr Menšík
It was proposed to change --conf-file= to have such effect. There were 
even patch posted to implement that. I think that would be more useful 
than current handling of empty value.


On 3/4/23 22:22, Johnny Utahh wrote:

Is this worth considering?

Proposal: add a `dnsmasq --no-read-or-load-any-config` feature.

Details:

1. 
https://www.reddit.com/r/linuxadmin/comments/11gp2he/dnsmasq_noreadconfig_does_this_or_some_similar/
2. 
https://github.com/rthalley/dnspython/discussions/877#discussioncomment-5203605
3. 
https://gist.githubusercontent.com/johnnyutahh/4d64d2d5927a6f0569c64a345a3f3e78/raw/


~J
--
//

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


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


Re: [Dnsmasq-discuss] dnsmasq (pihole) caching of HTTPS requested

2023-01-31 Thread Petr Menšík

On 19. 01. 23 11:57, Simon Kelley wrote:

Addendum.

I just looked at the latest draft (11) rather than draft zero whixh 
was linked here. That makes it clear that the additional processing is 
optional, so simply caching SVCB recpords might be a usable option.



Opinions? I'm basing this on a 10 minute skim of the draft, does 
anyone have more information?


Simon.


Yes, I also think we can just cache the record as any good recursive 
server. Additional records may or may not be stored to cache too, but 
that is clearly optional. If they are, similar restrictions to CNAME 
processing should be done. I think we should rely on clients be able to 
ask them.


I think dnsmasq should be modified to cache any reasonably short 
response, no matter what record type it contains. It is not necessary to 
cache PGP keys, but HTTPS and SVCB might be queried before each 
connection. It makes sense to cache those. I think type of record should 
be made separate cache field instead of encoding it in flags field. Only 
loggers should be taught to provide descriptions for common types and 
just simplified for more unusual types. Current code has it quite 
entangled into the logic and is difficult to add just selected new 
records. I agree that HTTPS RR would be the best candidate now. Ideally 
dnsmasq should be able to collect record query types per some period and 
cache most queried types, whatever it is. But sure, that would require 
non-trivial logic updates.


I think we should cache HTTPS response and just that record response. 
Rely on clients to ask additional records until we implement logic to 
store those related records as well. And for cases where some clients 
cannot handle well what they should, allow runtime cache disabling for 
selected record types, including HTTPS. New option --skip-cache-rr=https 
maybe?


Or we could modify cache to store separate records for ANSWER and 
ADDITIONAL sections. If we can respond a query with multiple records of 
different types and into multiple sections, that would solve the 
problem, right? We do not do iterative queries, so we just need to 
answer with all records our upstream has included. That might help also 
with CNAME or DNAME following, right?


Just my 2 cents.

Cheers,
Petr




On 19/01/2023 00:20, Dan Schaper via Dnsmasq-discuss wrote:
HTTPS is a valid resource record type. It's currently in draft 
status but it's used in the wild rather frequently.


https://developer.mozilla.org/en-US/docs/Glossary/https_rr

https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ 



Best,
Dan



--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


OpenPGP_signature
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


[Dnsmasq-discuss] FOSDEM meeting

2023-01-30 Thread Petr Menšík

Dear developers and users,

Already this weekend will be FOSDEM conference. I will be there, because 
also DNS dev room [2] would be present, I would like to meed anyone 
involved in dnsmasq. I would be there and have it already planned.


Will anyone else visit the conference too?

Looking forward to meet anyone.

Cheers,
Petr

[1] https://fosdem.org/2023/
[2] https://fosdem.org/2023/schedule/track/dns/

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


Re: [Dnsmasq-discuss] [PATCH] Add run-time option to disable CHAOS TXT records

2023-01-03 Thread Petr Menšík

Hi Dominik,

Good idea. But there is copy error on line 572, no help 
description is changed for new option. What does --no-ident stand for by 
the way? Wouldn't be --no-chaos more descriptive? Should we support 
optional argument to disable only some parts of provided records? For 
example cache statistics might be restricted to localhost only or 
provided only by DBus, while version might be still useful to report.


Cheers,
Petr

On 23. 12. 22 12:54, Dominik Derigs via Dnsmasq-discuss wrote:

Dear mailing list members,

In 2016, dnsmasq got the option to prevent serving the
server version, some statistics and even the used upstream
DNS servers to its clients. Compiling with -DNO_ID removes
the entire *.bind info structure. However, setting -DNO_ID
requires a (re-)compilation from source.

This patch adds a new run-time option --no-ident to achieve
the same without the need for recompiling.

I wish you some nice and hopefully relaxing Christmas days!

Best regards,
Dominik

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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


OpenPGP_signature
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] Dynamic address config?

2022-11-28 Thread Petr Menšík

On 11/26/22 14:14, Feng Shao wrote:

Thanks for the reply Petr.
Let me explain more about the motivation: I am a developer and our 
testers test the code on various environments, including VMs on cloud 
and k8s worker nodes from cloud providers. These machines and IPs are 
not provisioned/allocated by dnsmasq. For cost reason, these 
environments only lives for a short period of time, like one week or 
so, and testers provision these IPs directly without awareness of 
network administrators, that’s also why we don’t configure hostname 
for these machines in DNS system. Also I can not know in advance the 
list of possible IPs.
I think the best place to find a solution would be on provisioning those 
VM. Understood, they are just temporary machines. But especially for 
those hostname assigned by DHCP server would make more sense to me. I 
work on DNS and dislike having to type full IPs. Dnsmasq is used in some 
cloud technologies also. Depends on the interface available for testers 
to start a new VM. I would expect readiness to auto-register a name 
instance to DNS on most common cloud interfaces.


Whenever tester find some issue or need help, they give me the IP of 
the environments and I need to ssh to that environment. Because I will 
probably login to that same machine several times since the testers 
are testing my code on that machine recently, I want to setup 
passwordless login. So I  normally ssh-copy-id -i <~/.ssh/id_rsa.work 
<http://id_rsa.work>> first, then ssh to that machine. In order to 
instruct ssh to use my ssh key when connecting to that IP, I have 
below lines in my .ssh/config:


Host *.mylab
User root
IdentityFile ~/.ssh/id_rsa.wor <http://id_rsa.work/>k


Did you know you can use also multiple patterns in ssh_config? Like:

Host *.mylab 123.123.123.*
  User root
  IdentityFile ~/.ssh/id_rsa.wor <http://id_rsa.work/>k

My point is, I would understand if you had entries like:

address=/lab-123.mylab/123.123.123.123
address=/lab-124.mylab/123.123.123.124

dynamic-host should help with such setup as DHCP server, but won't work 
in your case.


But if you have full IP in the hostname, then what is the reason for a 
hostname anyway? It is not easier to remember or type. It is longer than 
just IP. And if you wanted to use IPv6, then similar solution would 
become too inefficient.


Take a look into --synth-domain option. It does format IPs a different 
way, but may provide very similar feature you are looking for. Should 
work for both IPv4 and IPv6.




And lines like below in /etc/hosts:
address=/123.123.123.123 
<http://123.123.123.123>.mylab/123.123.123.123 <http://123.123.123.123/>
address=/123.123.123.12 <http://123.123.123.123>4.mylab/123.123.123.12 
<http://123.123.123.123/>4


So that I can now “ssh 123.123.123.123.mylab”

As you can see, the problem here is, whenever a new IP comes, I need 
to add a new entry in /etc/hosts. So what I want is any .mylab is 
resolved to .


A key pair can be specified when creating VM on cloud, but I can not 
ask every tester add my ssh key pair when creating VM.



Petr Menšík 于2022年11月25日 周五19:52写道:

Did you know that dnsmasq registers all hosts by their name, if
they send their own hostname when requesting DHCP from dnsmasq?
Just use domain=mylab and have that host send hostname. It would
make using names possible without any additional configuration.

I do not get what is the advantage of having IP suffixed by some
domain. It looks like IP address, but it is even longer. Names of
machines should be easy to remember or use, I doubt that would be
the case here.

I think we have new feature conf-script, which can generate
dnsmasq configuration on the output. But I doubt we have a
possible code for what you describe. Could you please describe
more about intended usage? Why isn't using just hostname for each
host enough? Using dhcp-host seems enough for similar uses.

I think DLZ plugins for BIND9 are able to do similar things to
your request, but that would be very heavy-weight solution. I
think more motivation for your current design should be shared,
because I do not understand advantage of your solution.

Cheers,
Petr

On 11/23/22 06:47, Feng Shao wrote:

There are a bunch of machines in our lab, and we normally don't
have DNS records configured for them, only accessing by IP. In
order to ssh to them with key auth, I have a config in my
.ssh/config like

Host *.mylab
User root
IdentityFile ~/.ssh/id_rsa.work <http://id_rsa.work/>

and I have some "address=/123.123.123.123
<http://123.123.123.123>.mylab/123.123.123.123
<http://123.123.123.123/>" line in dnsmasq.conf. The problem here
is I need to add an entry whenever a new IP comes.

Can this configuration be dynamically? For example,
"address=/*.mylab/somecmd %1", where "s

Re: [Dnsmasq-discuss] v2.88rc2 segmentation fault with config "local=//" [PATCH]

2022-11-25 Thread Petr Menšík

Hi!

After reading those changes a bit, it seems there are too many variables 
used in a complex mess. It is very easy to get lost in them, especially 
when sdetails just points somewhere to local function other variables.


I made attempt to reduce the complexity and amount of local variables. 
Instead I moved contents of variables directly into server_details 
structure and added function to just add server from its pointer. Tried 
reducing repetitions by moving similar parts to shared functions.


But I admit I haven't tested the result stays unchanged. It should not 
change any behaviour, just cleanups the code. I think I should finally 
fix more serious runnable tests, which would ensure the functionality 
stayed the same.


What do you think?

Cheers,
Petr

On 11/17/22 20:59, Simon Kelley wrote:

Thanks for testing these builds. That's a genuine problem.

Fixed in 2.88rc3, in git now.

Cheers,

Simon.


On 17/11/2022 18:26, Johnny S. Lee via Dnsmasq-discuss wrote:

"local=//" means "Do not forward unqualified names to any upstream
servers", right?
It has not generated any kind of error until I updated to v2.88rc2.
The last build I've been using was built against
d3c21c596ef96027429b11216fcdbf65c9434afa

___
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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 1a6eba5f3972efe31f1a03d33ed64e239ed47079 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Fri, 25 Nov 2022 15:02:37 +0100
Subject: [PATCH 3/3] Reuse similar dbus message parsing

Move almost same codes into single function, use map_address parameter
to make difference between them.
---
 src/dbus.c | 91 +-
 1 file changed, 42 insertions(+), 49 deletions(-)

diff --git a/src/dbus.c b/src/dbus.c
index 6370b41..3e9b9a8 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -260,11 +260,46 @@ static DBusMessage *dbus_reply_server_loop(DBusMessage *message)
 }
 #endif
 
+/* Parse one entry from dbus. */
+static DBusMessage *dbus_parse_servers(DBusMessage *message,
+   struct server_details *sdetails,
+   char *str_addr, const char *str,
+   int map_address)
+{
+  const char *addr_err;
+  DBusMessage *error = NULL;
+
+  if ((addr_err = parse_server(str_addr, sdetails)))
+return dbus_message_new_error_printf(message, DBUS_ERROR_INVALID_ARGS,
+	 "Invalid IP address '%s': %s",
+	 str, addr_err);
+
+  while (parse_server_next(sdetails))
+{
+  if ((addr_err = parse_server_addr(sdetails)))
+	return dbus_message_new_error_printf(message, DBUS_ERROR_INVALID_ARGS,
+	 "Invalid IP address '%s': %s",
+	 str, addr_err);
+
+  if (map_address)
+	{
+	  /* 0.0.0.0 for server address == NULL, for Dbus */
+	  if (sdetails->addr.in.sin_family == AF_INET &&
+	  sdetails->addr.in.sin_addr.s_addr == 0)
+	sdetails->flags |= SERV_LITERAL_ADDRESS;
+	  else
+	sdetails->flags &= ~SERV_LITERAL_ADDRESS;
+	}
+
+	add_update_server_details(sdetails, str, NULL);
+}
+  return error;
+}
+
 static DBusMessage* dbus_read_servers_ex(DBusMessage *message, int strings)
 {
   DBusMessageIter iter, array_iter, string_iter;
   DBusMessage *error = NULL;
-  const char *addr_err;
   char *dup = NULL;
   
   if (!dbus_message_iter_init(message, ))
@@ -392,26 +427,9 @@ static DBusMessage* dbus_read_servers_ex(DBusMessage *message, int strings)
 	   }
 	 else
 	   {
-		 if ((addr_err = parse_server(str_addr, )))
-		   {
-		 error = dbus_message_new_error_printf(message, DBUS_ERROR_INVALID_ARGS,
-			   "Invalid IP address '%s': %s",
-			   str, addr_err);
-		 break;
-		   }
-		 
-		 while (parse_server_next())
-		   {
-		 if ((addr_err = parse_server_addr()))
-		   {
-			 error = dbus_message_new_error_printf(message, DBUS_ERROR_INVALID_ARGS,
-			   "Invalid IP address '%s': %s",
-			   str, addr_err);
-			 break;
-		   }
-		 
-	 add_update_server_details(, str_domain, NULL);
-		   }
+		 error = dbus_parse_servers(message, , str_addr, str, 0);
+		 if (error)
+		   break;
 	   }
 	  } while ((str_domain = p));
 	}
@@ -427,34 +445,9 @@ static DBusMessage* dbus_read_servers_ex(DBusMessage *message, int strings)
 	  dbus_message_iter_get_basic(_iter, );
 	dbus_message_iter_next (_iter);
 
-	if ((addr_err = parse_server(str_addr, )))
-	  {
-		error = dbus_message_new_error_printf(message, DBUS_ERROR_INVALID_ARGS,
-		  "Invalid 

Re: [Dnsmasq-discuss] [PATCH] Optimize speed on massive server=/.../... records

2022-11-25 Thread Petr Menšík
When looking what this change did, I have noticed mark_servers() cleanup 
of local_domains is using serv->next after it has freed serv. Use 
additional variable just like in cleanup_servers().


Patch attached.

On 11/21/22 23:22, Simon Kelley wrote:
Thanks for this. It was in my mind that vary large number of domains 
would be --local=/domain/ or --address=/domain/, not forwarding to 
servers.


I've applied something that looks very like your patch, but with 
cosmetic code changes.


Cheers,

Simon.


On 20/11/2022 05:50, Ye Zhou wrote:

Hi all,

I'm attaching a patch to optimize a speed issue introduced in version 
2.86.


I have two ISP upstreams and need to forward different sites to 
different ISP's DNS providers. For example:


server=/meituan.com/114.114.114.114 <http://meituan.com/114.114.114.114>
... (lots of records)
server=/taobao.com/223.5.5.5 <http://taobao.com/223.5.5.5>
... (lots of records)

It works well before v2.86. Since v2.86 the configuration load time 
becomes extremely long (more than 1 minutes to load all server 
records). The time consuming part is inside the rewritten 
domain-match.c. When adding a new server record, the code will 
traverse all existing records so the configuration load becomes 
quadratic time complexity. The issue still persists on v2.88rc3.
This patch will optimize the config load time by bypassing the time 
consuming code block. During the config load mark_servers() will 
never be called so does not need to waste time on the record 
traversal and re-order part.


Before:
dnsmasq --test  77.50s user 0.30s system 99% cpu 1:17.84 total
After:
dnsmasq --test  0.16s user 0.02s system 99% cpu 0.188 total

https://gist.github.com/zhouye/adfd509f51645d314f53992331449c45 
<https://gist.github.com/zhouye/adfd509f51645d314f53992331449c45>



___
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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 11fe9dd86740865ebd6911a3a2ccdaa6b943d043 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Fri, 25 Nov 2022 14:06:17 +0100
Subject: [PATCH] Avoid use-after-free when cleaning up local_domains

mark_servers() must use additional variable to hold next pointer. Just
like very similar loop in cleanup_servers() does.
---
 src/domain-match.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/domain-match.c b/src/domain-match.c
index bef460a..52a0342 100644
--- a/src/domain-match.c
+++ b/src/domain-match.c
@@ -559,7 +559,7 @@ static int maybe_free_servers = 0;
 /* Must be called before  add_update_server() to set daemon->servers_tail */
 void mark_servers(int flag)
 {
-  struct server *serv, **up;
+  struct server *serv, *next = NULL, **up;
 
   maybe_free_servers = !!flag;
   
@@ -580,8 +580,9 @@ void mark_servers(int flag)
  1) numerous and 2) not reloaded often. We just delete 
  and recreate. */
   if (flag)
-for (serv = daemon->local_domains, up = >local_domains; serv; serv = serv->next)
+for (serv = daemon->local_domains, up = >local_domains; serv; serv = next)
   {
+	next = serv->next;
 	if (serv->flags & flag)
 	  {
 	*up = serv->next;
-- 
2.38.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] Dynamic address config?

2022-11-25 Thread Petr Menšík
Did you know that dnsmasq registers all hosts by their name, if they 
send their own hostname when requesting DHCP from dnsmasq? Just use 
domain=mylab and have that host send hostname. It would make using names 
possible without any additional configuration.


I do not get what is the advantage of having IP suffixed by some domain. 
It looks like IP address, but it is even longer. Names of machines 
should be easy to remember or use, I doubt that would be the case here.


I think we have new feature conf-script, which can generate dnsmasq 
configuration on the output. But I doubt we have a possible code for 
what you describe. Could you please describe more about intended usage? 
Why isn't using just hostname for each host enough? Using dhcp-host 
seems enough for similar uses.


I think DLZ plugins for BIND9 are able to do similar things to your 
request, but that would be very heavy-weight solution. I think more 
motivation for your current design should be shared, because I do not 
understand advantage of your solution.


Cheers,
Petr

On 11/23/22 06:47, Feng Shao wrote:
There are a bunch of machines in our lab, and we normally don't have 
DNS records configured for them, only accessing by IP. In order to ssh 
to them with key auth, I have a config in my .ssh/config like


Host *.mylab
  User root
  IdentityFile ~/.ssh/id_rsa.work <http://id_rsa.work/>

and I have some "address=/123.123.123.123 
<http://123.123.123.123>.mylab/123.123.123.123 
<http://123.123.123.123/>" line in dnsmasq.conf. The problem here is I 
need to add an entry whenever a new IP comes.


Can this configuration be dynamically? For example, 
"address=/*.mylab/somecmd %1", where "somecmd" is a external command 
and %1 will be replaced by the name in A/ request. So that for any 
DNS request to *.mylab, dnsmasq invoke this external command and pass 
the name as argument, the output of external command, which will be 
interpreted as IPv4/IPv6 addr then responsed to client?


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


--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] dnsmasq mishandles some cases when bad dns response packet is received

2022-11-24 Thread Petr Menšík
. But 
for the first bug, there is really no check, I think this should be 
fixed.


|The following CLASS mnemonics and values are defined:
|
|IN  1 the Internet
|
|CS  2 the CSNET class (Obsolete - used only for examples in
|    some obsolete RFCs)
|
|CH  3 the CHAOS class
|
|HS  4 Hesiod [Dyer 87]

Thank you very much for your reply.



This is a perfect example of why dnsmasq should not reject packets it 
can't understand. If the IETF should define a new class tomorrow, 
every release of dnsmasq since 2000 would be quite happy to forward 
queries in that class and return results. The same goes for classes 
between 65280 and 65534 which are reserved for private use in RFC 6895.


https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-2 



This is all set out explicitly in section 3 of RFC 5625

https://datatracker.ietf.org/doc/html/rfc5625#page-3

Quote:

   The role of the proxy should therefore be no more and no less than to
   receive DNS requests from clients on the LAN side, forward those
   verbatim to one of the known upstream recursive resolvers on the WAN
   side, and ensure that the whole response is returned verbatim to the
   original client.


Cheers,

Simon.




Thanks,
P1n9



Cheers,

Simon.

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


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



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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] dnsmasq mishandles some cases when bad dns response packet is received

2022-11-22 Thread Petr Menšík
Created ldns-testns files for all queries. Also contains their body 
responses parsed by dig tool on that.


Interesting cases, but I am not sure how much should dnsmasq validate 
those responses.  Most of these responses is valid DNS responses. Sure, 
not what client expected or needed, but I doubt we can make reasonable 
filter on dnsmasq side.


On 19. 11. 22 0:12, Geert Stappers via Dnsmasq-discuss wrote:

On Wed, Nov 16, 2022 at 11:15:08AM +0800, zhangjiangyu via Dnsmasq-discuss 
wrote:

Hi,

On Mon, Nov 15, 2022 at 8:15:00PM +0800, Petr Menšík wrote:

Interesting tests.

But dnsmasq is somehow naive in parsing replied queries. It tries to
deliver the response exactly as it were delivered to it. I think the
main reason for it is it expects trusted resolvers to be used as a
forwarding servers, not something bogus. Sure, I admit that might not be
correct expectation. dnsmasq is minimalistic and tries to minimize the
size of code and used resources. Therefore it does not do full parsing
of the message and verification of every aspect in the response.

I would recommend using Unbound for less trusted forwarders. I think all
other implementations do not rely on recursive server doing the hard
work, so they may encounter also less trusted responses. But dnsmasq
should send queries to trusted forwarders only. It can therefore trust
them to do more strict checking.

Unfortunately the unbound also has the same problem, I also submitted
an issue. Although the forwarders configured by dnsmasq are trusted,
there are also some situations that need to be considered, such as,
the dnsmasq configuration file has been maliciously changed, your
trusted forwarder has the same error handling problem or the host
computer where the forwarder is located is attacked, so dnsmasq needs
to do some obvious wrong checks, and it is also necessary.it can't
rely entirely on other parsers.


But I admit we should add at least the most obvious checks. Would you
please make the responses in ldns-testns [1] server format, so it would
be easier to test it? It allows also encoding the body in hex format, so
invalid responses are broken as well. It would be easier to test the bad
behaviour and prepare fixes for them. Are those links leading to DNS in
wire format? It would be simpler to read if pcap with them were used,
wireshark would visualise those responses well.

Yes, The message I provided is a wire format,
but it is a bit different from the wire format,
because the first four bytes are a length field.

Ah, a length field, a sixtyfour bit length field.



I removed the length field,
it should be all dns request and reply messages, it is wire format.

 ;-)



Below is the download link:
origin request: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request0
origin response: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response0
request1: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request1
response1: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response1
request2: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request2
response2: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response2
request3: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request3
response3: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response3

Of course, in previous comminicate, Geert Stappers
has already made a reproduced git repository,
here: https://git.sr.ht/~stappers/cert_check_by_dnsmasq, you can use
this to reproduce it.

For ldns-testns, I don't know how to construct the corresponding data format,

A working example,  also attached  (and in the above named git repository)
-8<8<--8<
; ldns-testns data file
;
; Intented use
;   ldns-testns -p 53531  this_file_name
; or
;   ldns-testns -v -p 53531  this_file_name
; In other session, query with
;   dig @localhost -p 53531 -t   A cert00.example
;   dig @localhost -p 53531 -t CERT cert00.example
; or tell dnsmasq to use this test name server by
;   server=127.0.0.1#53531
;
;

$TTL 3600

ENTRY_BEGIN
MATCH qname
MATCH qtype
REPLY QUERY
REPLY NOERROR
ADJUST copy_id
SECTION QUESTION
cert00.example IN CERT
HEX_ANSWER_BEGIN
   e1 0c 81 80 00 01 00 01 00 02 00 01
   06 63 65 72 74 30 30 07 65 78 61 6d 70 6c 65
   00 00
   25 00 01
   c0 0c 00 25 00 01 00 00 00 00 00 55 ff fe ff ff
   fe 33 11 5c 6f 2f 64 ff 2b de 74 c7 d0 80 ac e1
   1f 97 ab d0 cb bf bc 82 f3 e3 92 24 b2 47 1e 14
   68 22 58 29 ff 1b 11 e1 6a 2e 95 02 e1 c0 a0 d5
   33 e1 8a 14 d6 d5 5f 48 24 aa 41 89 fa ff fd 75
   53 a3 65 77 cd 23 11 e0 bc 69 3a ce f8 a2 a6 09
   a6 c0 13 00 02 00 01 00 00 00 00 00 06 03 6e 73
   34 c0 13 c0 13 00 02 00 01 00 00 00 00 00 06 03
   6e 73 32 c0 13 00 00 29 10 00 00 00 00 00 00 00
HEX_ANSWER_END
ENTRY_END


ENTRY_BEGIN
MATCH qname
MATCH qtype
REPLY NOERROR
ADJUST copy_id
SECTION QUESTION
cert00.example IN A
HEX_ANSWER_BEGIN
   a5 d5 85 80 00 01 00 01 00 00 00 01
   06 63 65 72 74 30 30 ; cert00
   07 65 78 61 6d

Re: [Dnsmasq-discuss] [PATCH] Make ECC-GOST optional only

2022-11-21 Thread Petr Menšík
Great! I tried comparing the implementation of GOST to bind or unbound, 
which I have seen before. But found they both lack any implementation of 
GOST. Anyway, It seems working fine. Tried it on my Fedora 36 and in 
CentOS 8 container. Centos as expected resolves GOST related algorithms 
without AD flag, but this time without SERVFAILs at all. So the issue 
seems fixed both on nettle 3.4 and 3.8.


But I have noticed strange if in one related changes. I believe 
unsupported DNSKEY algorithms checks should have been there. Attached 
fixup patch.


Thanks for fixing also ED448 algorithm. Of course in this case my 
previous patch is not needed for anything, because yours fixes it in a 
better way. Just take a look at this patch.


Thanks!

Petr

On 11/16/22 18:23, Simon Kelley wrote:



On 10/11/2022 17:02, Petr Menšík wrote:

Hi!

I were testing my builds on rootcanary.org test, where dnsmasq is the 
only one failing with DNSSEC validation enabled. I am not sure why, I 
think gost crypto algorithm might be broken intentionally on Fedora 
or RHEL for legal reason. But I have tested it on Debian unstable and 
the result were same. It passes other algorithms, but fails on this one.


I have therefore made it possible to skip GOST support. In addition 
it makes that default as well. Is there any distribution, which has 
GOST support working? Is it possible that rootcanary.org has wrong 
signatures?


All other implementations return already insecure status - not 
implemented algorithm. This change makes the same for dnsmasq.


Opinions on that?




This sent me down something of a rabbit hole.

I've found and fixed multiple issues.

1) The code relies on algo_digest_name() returning NULL for any 
signature algorithm that's not supported, but the combination of a bug 
in the #defines in that code and a bug in libnettle made that not 
always true, so the DNSSEC code tried to validate things it shouldn't 
and failed,resulting in a SERVFAIL.


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



fixes that.


2) The code to handle the GOST algorithms was broken; it used the 
wrong digest parameters and got the byte-order of the keys wrong and 
the order of the fields in the signature wrong. libnettle needs to be 
version 3.6 or later to support the correct digest and signature algo.


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




fixes.

3) The handling of unsupported hash algorithms in DS records was 
wrong. A correctly signed DS RRset which contains only unsupported 
hashes should be treated the same as a signed empty DS RRset and allow 
answers for the domain it covers to be returned unvalidated, and not 
to generate SERVFAIL responses.


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



Fixes that.

With those three patches, rootcanary.org gives sensible results, both 
with dnsmasq compiled against Nettle-3.5 (which doesn't support ED488 
and GOST) and complied against Nettle-3.8, which does support both 
those. In the nettle-3.8 case records signed with RSA-MD5, DSA and 
DSA-NSEC-SHA1 are returned without being verified as specified in the 
DNSSEC Validation column of RFC 8624 para 3.1 The GOST signature and 
DS hash algorithms are still marked as MAY in that column, so I think 
it's fine to leave them in.



Given the above, I don't think there's a need to be able to disable 
the GOST algorithms, but I'm happy to hear arguments to the contrary.



Cheers,

Simon.


Cheers,
Petr



--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 47bafee561f492c5fad7429c9043d97f95e31d50 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Mon, 21 Nov 2022 22:25:52 +0100
Subject: [PATCH] fixup! Handle DS records for unsupported crypto algorithms
 correctly.

---
 src/dnssec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/dnssec.c b/src/dnssec.c
index ce01b2e..219ba9a 100644
--- a/src/dnssec.c
+++ b/src/dnssec.c
@@ -1068,7 +1068,7 @@ int dnssec_validate_ds(time_t now, struct dns_header *header, size_t plen, char
 	  algo = *p++;
 	  digest = *p++;
 	  
-	  if (!ds_digest_name(digest) || !ds_digest_name(digest))
+	  if (!ds_digest_name(digest) || !algo_digest_name(algo))
 		{
 		  a.log.keytag = keytag;
 		  a.log.algo = algo;
-- 
2.38.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 mishandles some cases when bad dns response packet is received

2022-11-15 Thread Petr Menšík

Interesting tests.

But dnsmasq is somehow naive in parsing replied queries. It tries to 
deliver the response exactly as it were delivered to it. I think the 
main reason for it is it expects trusted resolvers to be used as a 
forwarding servers, not something bogus. Sure, I admit that might not be 
correct expectation. dnsmasq is minimalistic and tries to minimize the 
size of code and used resources. Therefore it does not do full parsing 
of the message and verification of every aspect in the response.


I would recommend using Unbound for less trusted forwarders. I think all 
other implementations do not rely on recursive server doing the hard 
work, so they may encounter also less trusted responses. But dnsmasq 
should send queries to trusted forwarders only. It can therefore trust 
them to do more strict checking.


But I admit we should add at least the most obvious checks. Would you 
please make the responses in ldns-testns [1] server format, so it would 
be easier to test it? It allows also encoding the body in hex format, so 
invalid responses are broken as well. It would be easier to test the bad 
behaviour and prepare fixes for them. Are those links leading to DNS in 
wire format? It would be simpler to read if pcap with them were used, 
wireshark would visualise those responses well.


But as I said already, unlike other mentioned implementations, dnsmasq 
will accept responses ONLY from configured addresses. It will never use 
any other for iterative queries from root. Because it does not know how 
to do that. So if the forwarder ensures those packets have valid format, 
dnsmasq just relies on it. It is not possible to send query for 
attacker's name and get around the forwarder's checking. I think at 
least the 1st bug should be fixed, others can rely on forwarder's checks.


Regards,
Petr

[1] https://linux.die.net/man/1/ldns-testns

On 11/12/22 03:30, ZhangJiangyu 张江瑜 via Dnsmasq-discuss wrote:
The rcode of the dnsmasq returned 


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


Re: [Dnsmasq-discuss] [PATCH] Make ECC-GOST optional only

2022-11-15 Thread Petr Menšík
Oh, I think that were just typo when editing that file. Of course 
shouln't be there.


Attached fixed patch.

On 11/13/22 14:44, Geert Stappers via Dnsmasq-discuss wrote:

On Thu, Nov 10, 2022 at 06:02:44PM +0100, Petr Menšík wrote:

Hi!

I were testing my builds on rootcanary.org test, where dnsmasq is the only
one failing with DNSSEC validation enabled. I am not sure why, I think gost
crypto algorithm might be broken intentionally on Fedora or RHEL for legal
reason. But I have tested it on Debian unstable and the result were same. It
passes other algorithms, but fails on this one.

I have therefore made it possible to skip GOST support. In addition it makes
that default as well. Is there any distribution, which has GOST support
working? Is it possible that rootcanary.org has wrong signatures?

All other implementations return already insecure status - not implemented
algorithm. This change makes the same for dnsmasq.


 

--- a/src/config.h
+++ b/src/config.h
@@ -198,6 +201,8 @@ RESOLVFILE
  /* #define HAVE_CONNTRACK */
  /* #define HAVE_CRYPTOHASH */
  /* #define HAVE_DNSSEC */
+/* #define HAVE_GOST */
+/* #define HAVE_GOST */
  /* #define HAVE_NFTSET */
  
  /* Default locations for important system files. */


Why twice the '/* #define HAVE_GOST */' line?



Groeten
Geert Stappers


--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 45c68f29f0fa3d202072cc51c7d7d2cf38b95e42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Thu, 10 Nov 2022 17:50:11 +0100
Subject: [PATCH] Make ECC-GOST algorithm 12 optional only

According to my testing on rootcanary.org, dnsmasq always fails to
validate the record with algorithm 12. Make it disabled by default,
because it fails both on Debian and Fedora. Enable it by
-DCOPTS=HAVE_GOST define.
---
 src/config.h | 8 
 src/crypto.c | 8 +---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/config.h b/src/config.h
index df1d985..a9df5ee 100644
--- a/src/config.h
+++ b/src/config.h
@@ -131,6 +131,9 @@ HAVE_CRYPTOHASH
 HAVE_DNSSEC
include DNSSEC validator.
 
+HAVE_GOST
+   include DNSSEC algorithm 12 (ECCGOST) support
+
 HAVE_DUMPFILE
include code to dump packets to a libpcap-format file for debugging.
 
@@ -198,6 +201,7 @@ RESOLVFILE
 /* #define HAVE_CONNTRACK */
 /* #define HAVE_CRYPTOHASH */
 /* #define HAVE_DNSSEC */
+/* #define HAVE_GOST */
 /* #define HAVE_NFTSET */
 
 /* Default locations for important system files. */
@@ -442,6 +446,10 @@ static char *compile_opts =
 "no-"
 #endif
 "DNSSEC "
+#ifndef HAVE_GOST
+"no-"
+#endif
+"gost "
 #ifdef NO_ID
 "no-ID "
 #endif
diff --git a/src/crypto.c b/src/crypto.c
index 060e27f..8f36839 100644
--- a/src/crypto.c
+++ b/src/crypto.c
@@ -39,7 +39,7 @@
 #if MIN_VERSION(3, 1)
 #include 
 #endif
-#if MIN_VERSION(3, 6)
+#if defined(HAVE_GOST) && MIN_VERSION(3, 6)
 #  include 
 #endif
 
@@ -281,7 +281,7 @@ static int dnsmasq_ecdsa_verify(struct blockdata *key_data, unsigned int key_len
   return nettle_ecdsa_verify(key, digest_len, digest, sig_struct);
 }
 
-#if MIN_VERSION(3, 6)
+#if defined(HAVE_GOST) && MIN_VERSION(3, 6)
 static int dnsmasq_gostdsa_verify(struct blockdata *key_data, unsigned int key_len, 
   unsigned char *sig, size_t sig_len,
   unsigned char *digest, size_t digest_len, int algo)
@@ -381,7 +381,7 @@ static int (*verify_func(int algo))(struct blockdata *key_data, unsigned int key
 case 5: case 7: case 8: case 10:
   return dnsmasq_rsa_verify;
 
-#if MIN_VERSION(3, 6)
+#if defined(HAVE_GOST) && MIN_VERSION(3, 6)
 case 12:
   return dnsmasq_gostdsa_verify;
 #endif
@@ -444,7 +444,9 @@ char *algo_digest_name(int algo)
 case 7: return "sha1";/* RSASHA1-NSEC3-SHA1 */
 case 8: return "sha256";  /* RSA/SHA-256 */
 case 10: return "sha512"; /* RSA/SHA-512 */
+#ifdef HAVE_GOST
 case 12: return "gosthash94"; /* ECC-GOST */
+#endif
 case 13: return "sha256"; /* ECDSAP256SHA256 */
 case 14: return "sha384"; /* ECDSAP384SHA384 */ 	
 case 15: return "null_hash";  /* ED25519 */
-- 
2.38.1

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


[Dnsmasq-discuss] [PATCH] Make ECC-GOST optional only

2022-11-10 Thread Petr Menšík

Hi!

I were testing my builds on rootcanary.org test, where dnsmasq is the 
only one failing with DNSSEC validation enabled. I am not sure why, I 
think gost crypto algorithm might be broken intentionally on Fedora or 
RHEL for legal reason. But I have tested it on Debian unstable and the 
result were same. It passes other algorithms, but fails on this one.


I have therefore made it possible to skip GOST support. In addition it 
makes that default as well. Is there any distribution, which has GOST 
support working? Is it possible that rootcanary.org has wrong signatures?


All other implementations return already insecure status - not 
implemented algorithm. This change makes the same for dnsmasq.


Opinions on that?

Cheers,
Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 4709f4f07129ac61f52eda4ee186aadbf20f3d74 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Thu, 10 Nov 2022 17:50:11 +0100
Subject: [PATCH] Make ECC-GOST algorithm 12 optional only

According to my testing on rootcanary.org, dnsmasq always fails to
validate the record with algorithm 12. Make it disabled by default,
because it fails both on Debian and Fedora. Enable it by
-DCOPTS=HAVE_GOST define.
---
 src/config.h | 9 +
 src/crypto.c | 8 +---
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/src/config.h b/src/config.h
index df1d985..130ae0f 100644
--- a/src/config.h
+++ b/src/config.h
@@ -131,6 +131,9 @@ HAVE_CRYPTOHASH
 HAVE_DNSSEC
include DNSSEC validator.
 
+HAVE_GOST
+   include DNSSEC algorithm 12 (ECCGOST) support
+
 HAVE_DUMPFILE
include code to dump packets to a libpcap-format file for debugging.
 
@@ -198,6 +201,8 @@ RESOLVFILE
 /* #define HAVE_CONNTRACK */
 /* #define HAVE_CRYPTOHASH */
 /* #define HAVE_DNSSEC */
+/* #define HAVE_GOST */
+/* #define HAVE_GOST */
 /* #define HAVE_NFTSET */
 
 /* Default locations for important system files. */
@@ -442,6 +447,10 @@ static char *compile_opts =
 "no-"
 #endif
 "DNSSEC "
+#ifndef HAVE_GOST
+"no-"
+#endif
+"gost "
 #ifdef NO_ID
 "no-ID "
 #endif
diff --git a/src/crypto.c b/src/crypto.c
index 060e27f..8f36839 100644
--- a/src/crypto.c
+++ b/src/crypto.c
@@ -39,7 +39,7 @@
 #if MIN_VERSION(3, 1)
 #include 
 #endif
-#if MIN_VERSION(3, 6)
+#if defined(HAVE_GOST) && MIN_VERSION(3, 6)
 #  include 
 #endif
 
@@ -281,7 +281,7 @@ static int dnsmasq_ecdsa_verify(struct blockdata *key_data, unsigned int key_len
   return nettle_ecdsa_verify(key, digest_len, digest, sig_struct);
 }
 
-#if MIN_VERSION(3, 6)
+#if defined(HAVE_GOST) && MIN_VERSION(3, 6)
 static int dnsmasq_gostdsa_verify(struct blockdata *key_data, unsigned int key_len, 
   unsigned char *sig, size_t sig_len,
   unsigned char *digest, size_t digest_len, int algo)
@@ -381,7 +381,7 @@ static int (*verify_func(int algo))(struct blockdata *key_data, unsigned int key
 case 5: case 7: case 8: case 10:
   return dnsmasq_rsa_verify;
 
-#if MIN_VERSION(3, 6)
+#if defined(HAVE_GOST) && MIN_VERSION(3, 6)
 case 12:
   return dnsmasq_gostdsa_verify;
 #endif
@@ -444,7 +444,9 @@ char *algo_digest_name(int algo)
 case 7: return "sha1";/* RSASHA1-NSEC3-SHA1 */
 case 8: return "sha256";  /* RSA/SHA-256 */
 case 10: return "sha512"; /* RSA/SHA-512 */
+#ifdef HAVE_GOST
 case 12: return "gosthash94"; /* ECC-GOST */
+#endif
 case 13: return "sha256"; /* ECDSAP256SHA256 */
 case 14: return "sha384"; /* ECDSAP384SHA384 */ 	
 case 15: return "null_hash";  /* ED25519 */
-- 
2.38.1

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


[Dnsmasq-discuss] [PATCH] Offer alternative DHCPv6 address if requested is taken

2022-10-21 Thread Petr Menšík

Hi,

I am attaching a change, which has been part of RHEL/CentOS Stream 9 for 
some while [1]. It fixes the problem with DHCPv6 only requests, which on 
some situations fail to provide an address. This change is older than 
related change, which attempted to solve similar issue on IPv4 too. It 
works by offering a different (free) IPv6 address to client, than he 
originally asked for. It is a simple change, but tested clients worked 
with it. Accompanied by related change to add client-arch tag support 
also for DHCPv6 [2]. It were created to solve rh bug #2002871 [3], of 
which most of communication is unfortunately RH internal only. Parent 
bug [4] has a bit more background visible to public. But no regressions 
were reported after this change and it has improved a situation in 
openstack. I haven't found my attempt to offer it here, but maybe I just 
failed my search. If it were refused already, kindly point me to correct 
thread. It improves iPXE booting of multiple machines on the same host 
concurrently.


Cheers,
Petr

1. 
https://gitlab.com/redhat/centos-stream/rpms/dnsmasq/-/blob/c9s/dnsmasq-2.86-alternative-lease.patch
2. 
https://gitlab.com/redhat/centos-stream/rpms/dnsmasq/-/blob/c9s/dnsmasq-2.86-dhcpv6-client-arch.patch

3. https://bugzilla.redhat.com/show_bug.cgi?id=2002871
4. https://bugzilla.redhat.com/show_bug.cgi?id=1998448

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 21b92ff46aa887da6f2eb85e5cf39253deb61d80 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Wed, 22 Sep 2021 14:54:01 +0200
Subject: [PATCH 2/2] Add support for option6 names of RFC 5970

Client Network Interface Identifier and Client System Architecture Type
options were not understood by dnsmasq. Add it to supported option
types.
---
 src/dhcp-common.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/dhcp-common.c b/src/dhcp-common.c
index bc6d95e..ca0f967 100644
--- a/src/dhcp-common.c
+++ b/src/dhcp-common.c
@@ -725,6 +725,8 @@ static const struct opttab_t opttab6[] = {
   { "ntp-server", 56, 0 /* OT_ADDR_LIST | OT_RFC1035_NAME */ },
   { "bootfile-url", 59, OT_NAME },
   { "bootfile-param", 60, OT_CSTRING },
+  { "client-arch", 61, 2 | OT_DEC }, /* RFC 5970 */
+  { "client-interface-id", 62, 1 | OT_DEC }, /* RFC 5970 */
   { NULL, 0, 0 }
 };
 #endif
-- 
2.37.3

From 6fea19991eba45bf72c10fa30516d6d58f22cf47 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Fri, 17 Sep 2021 20:12:21 +0200
Subject: [PATCH 1/2] Offer alternative DHCPv6 address if requested is taken

In some cases multiple requests might arrive from single DUID. It may
happen just one address is offered to different IAID requests. When
the first request confirms lease, another would be offered alternative
address instead of address in use error.

Includes check on such Rapid commit equivalents and returns NotOnLink
error, required by RFC 8145, if requested address were not on any
supported prefix.
---
 src/rfc3315.c | 39 ---
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/src/rfc3315.c b/src/rfc3315.c
index 8754481..bd7c40f 100644
--- a/src/rfc3315.c
+++ b/src/rfc3315.c
@@ -615,7 +615,7 @@ static int dhcp6_no_relay(struct state *state, int msg_type, unsigned char *inbu
   
 case DHCP6SOLICIT:
   {
-  	int address_assigned = 0;
+	int address_assigned = 0, ia_invalid = 0;
 	/* tags without all prefix-class tags */
 	struct dhcp_netid *solicit_tags;
 	struct dhcp_context *c;
@@ -698,6 +698,8 @@ static int dhcp6_no_relay(struct state *state, int msg_type, unsigned char *inbu
 		get_context_tag(state, c);
 		address_assigned = 1;
 		  }
+		else
+		  ia_invalid++;
 	  }
 	
 	/* Suggest configured address(es) */
@@ -783,11 +785,26 @@ static int dhcp6_no_relay(struct state *state, int msg_type, unsigned char *inbu
 	tagif = add_options(state, 0);
 	  }
 	else
-	  { 
+	  {
+	char *errmsg;
 	/* no address, return error */
 	o1 = new_opt6(OPTION6_STATUS_CODE);
-	put_opt6_short(DHCP6NOADDRS);
-	put_opt6_string(_("no addresses available"));
+	if (state->lease_allocate && ia_invalid)
+	  {
+		/* RFC 8415, Section 18.3.2:
+		   If any of the prefixes of the included addresses are not
+		   appropriate for the link to which the client is connected,
+		   the server MUST return the IA to the client with a Status
+		   Code option with the value NotOnLink. */
+		put_opt6_short(DHCP6NOTONLINK);
+		errmsg = _("not on link");
+	  }
+	else
+	  {
+		put_opt6_short(DHCP6NOADDRS);
+		errmsg = _("no addresses available");
+	  }
+	put_opt6_string(errmsg);
 	end_opt6(o1);
 
 	/* Some clients will ask repeatedly when we're not giving
@@ -796,7 +813,7 @@ static int dhcp6_no_relay(struct state *state, int msg_type, u

Re: [Dnsmasq-discuss] [PATCH] Offer alternative DHCPv6 address if requested is taken

2022-10-21 Thread Petr Menšík

Ah, found reference to the original thread:

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q3/015640.html

It has subject: [PATCH] DHCPv6 - network booting 'address in use'

It was neither refused or merged, so I like it to be reviewed.

On 10/21/22 12:25, Petr Menšík wrote:

Hi,

I am attaching a change, which has been part of RHEL/CentOS Stream 9 
for some while [1]. It fixes the problem with DHCPv6 only requests, 
which on some situations fail to provide an address. This change is 
older than related change, which attempted to solve similar issue on 
IPv4 too. It works by offering a different (free) IPv6 address to 
client, than he originally asked for. It is a simple change, but 
tested clients worked with it. Accompanied by related change to add 
client-arch tag support also for DHCPv6 [2]. It were created to solve 
rh bug #2002871 [3], of which most of communication is unfortunately 
RH internal only. Parent bug [4] has a bit more background visible to 
public. But no regressions were reported after this change and it has 
improved a situation in openstack. I haven't found my attempt to offer 
it here, but maybe I just failed my search. If it were refused 
already, kindly point me to correct thread. It improves iPXE booting 
of multiple machines on the same host concurrently.


Cheers,
Petr

1. 
https://gitlab.com/redhat/centos-stream/rpms/dnsmasq/-/blob/c9s/dnsmasq-2.86-alternative-lease.patch
2. 
https://gitlab.com/redhat/centos-stream/rpms/dnsmasq/-/blob/c9s/dnsmasq-2.86-dhcpv6-client-arch.patch

3. https://bugzilla.redhat.com/show_bug.cgi?id=2002871
4. https://bugzilla.redhat.com/show_bug.cgi?id=1998448


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] DNSSEC Enable with Centos 7

2022-09-27 Thread Petr Menšík
I would suggest upgrading to CentOS 8 if possible. That version has 
already DNSSEC support built-in.


If not possible, consider rebuilding CentOS 8 or CentOS 9 dnsmasq 
package from source. Another way might be just adding 
COPTS+=-DHAVE_DNSSEC to rhel7 srpm and rebuild. Using rpm-build -bb 
*.spec, after installing rpm -I dnsmasq*.src.rpm first.


I don't maintain any alternative repositories for dnsmasq, not sure if 
any of those are maintained by someone. I will not maintain any version 
for RHEL7 though, it is too old IMO.


Regards,
Petr

On 9/5/22 14:16, Michelangelo Lauria via Dnsmasq-discuss wrote:

Hello, I need to use dnsmasq with “dnssec" enabled in a Centos 7 environment.
The yum repository lists dnsmasq v.2.76 available to install which I understand 
is outdated and seems to me it is without dnssec.
I have tried to compile from source but I am getting several errors of 
dependencies and don’t know how to create the service.
Instead I can install and run as service dnsmasq from yum no problem, but it 
does not support dnssec.
Can you suggest a repository to install the latest version (with dnssec) and/or 
provide guidance on compiling thsi software and enabling it to run as service ?

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


[Dnsmasq-discuss] [PATCH] Introduce whine_realloc

2022-07-18 Thread Petr Menšík

Hi,

After reading the code creating servers.bind reply, I made a change to 
use realloc call instead. It should allow saving some memory copying 
when it is possible to just extend allocated memory size. I have 
replaced  few other uses as well. It is not yet tested much, but should 
be safe enough.


It might also slightly improve performance handling sockets, because it 
reduces copying done on socket listener adding.


Just improvement without adding any other feature.

Cheers,

Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 49070b7d5ba1406cbcd1a854abf33f54d7c45e1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Mon, 18 Jul 2022 13:30:07 +0200
Subject: [PATCH] Introduce whine_realloc

Move few patters with whine_malloc, if (successful) copy+free, to a new
whine_realloc. It should do the same thing, but with a help from OS it
can avoid unnecessary copy and free if allocation of more data after
current data is possible.

Added few setting remanining space to 0, because realloc does not use
calloc like whine_malloc does. There is no advantage of zeroing what we
will immediately overwrite. Zero only remaining space.
---
 src/cache.c|  4 +---
 src/dnsmasq.h  |  1 +
 src/lease.c|  8 +---
 src/poll.c |  9 +
 src/rrfilter.c | 16 ++--
 src/util.c | 10 ++
 6 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/src/cache.c b/src/cache.c
index a99d70d..8ed4740 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -1676,10 +1676,8 @@ int cache_make_stat(struct txt_record *t)
 	  {
 		/* expand buffer if necessary */
 		newlen = bytes_needed + 1 + bufflen - bytes_avail;
-		if (!(new = whine_malloc(newlen)))
+		if (!(new = whine_realloc(buff, newlen)))
 		  return 0;
-		memcpy(new, buff, bufflen);
-		free(buff);
 		p = new + (p - buff);
 		lenp = p - 1;
 		buff = new;
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index bfc0fd4..db8a26b 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -1394,6 +1394,7 @@ void *safe_malloc(size_t size);
 void safe_strncpy(char *dest, const char *src, size_t size);
 void safe_pipe(int *fd, int read_noblock);
 void *whine_malloc(size_t size);
+void *whine_realloc(void *ptr, size_t size);
 int sa_len(union mysockaddr *addr);
 int sockaddr_isequal(const union mysockaddr *s1, const union mysockaddr *s2);
 int hostname_order(const char *a, const char *b);
diff --git a/src/lease.c b/src/lease.c
index 81477d5..8a7b975 100644
--- a/src/lease.c
+++ b/src/lease.c
@@ -1180,17 +1180,11 @@ void lease_add_extradata(struct dhcp_lease *lease, unsigned char *data, unsigned
   if ((lease->extradata_size - lease->extradata_len) < (len + 1))
 {
   size_t newsz = lease->extradata_len + len + 100;
-  unsigned char *new = whine_malloc(newsz);
+  unsigned char *new = whine_realloc(lease->extradata, newsz);
   
   if (!new)
 	return;
   
-  if (lease->extradata)
-	{
-	  memcpy(new, lease->extradata, lease->extradata_len);
-	  free(lease->extradata);
-	}
-
   lease->extradata = new;
   lease->extradata_size = newsz;
 }
diff --git a/src/poll.c b/src/poll.c
index 29b33a0..0e5964d 100644
--- a/src/poll.c
+++ b/src/poll.c
@@ -105,14 +105,15 @@ void poll_listen(int fd, short event)
 
 	   arrsize = (arrsize == 0) ? 64 : arrsize * 2;
 
-	   if (!(new = whine_malloc(arrsize * sizeof(struct pollfd
+	   if (!(new = whine_realloc(pollfds, arrsize * sizeof(struct pollfd
 	 return;
 
 	   if (pollfds)
 	 {
-	   memcpy(new, pollfds, i * sizeof(struct pollfd));
-	   memcpy([i+1], [i], (nfds - i) * sizeof(struct pollfd));
-	   free(pollfds);
+	   memmove([i+1], [i], (nfds - i) * sizeof(struct pollfd));
+	   /* clear remaining space with zeroes. */
+	   if (nfds+1 < arrsize)
+	 memset(new+nfds+1, 0, arrsize-nfds-1);
 	 }
 	   
 	   pollfds = new;
diff --git a/src/rrfilter.c b/src/rrfilter.c
index f02f5a5..42d9c21 100644
--- a/src/rrfilter.c
+++ b/src/rrfilter.c
@@ -159,7 +159,7 @@ static int check_rrs(unsigned char *p, struct dns_header *header, size_t plen, i
 /* mode may be remove EDNS0 or DNSSEC RRs or remove A or  from answer section. */
 size_t rrfilter(struct dns_header *header, size_t plen, int mode)
 {
-  static unsigned char **rrs;
+  static unsigned char **rrs = NULL;
   static int rr_sz = 0;
 
   unsigned char *p = (unsigned char *)(header+1);
@@ -339,15 +339,11 @@ int expand_workspace(unsigned char ***wkspc, int *szp, int new)
 return 0;
 
   new += 5;
-  
-  if (!(p = whine_malloc(new * sizeof(unsigned char *
-return 0;  
-  
-  if (old != 0 && *wkspc)
-{
-  memcpy(p, *wkspc, old * sizeof(unsigned char *));
-  free(*wkspc);
-}
+
+  if (!(p = whine_realloc(*wkspc, new * sizeof(unsigned char *
+return 0;
+
+  memset(p+old, 0, new-old);
   
   *wkspc = p;
   *szp = new;
diff --git a/sr

Re: [Dnsmasq-discuss] patchwork

2022-07-18 Thread Petr Menšík

On 17. 07. 22 14:35, Geert Stappers via Dnsmasq-discuss wrote:

Previous-Subject: Re: [Dnsmasq-discuss] [PATCH] Create temporary leases for 
DHCPOFFER actions
In-Reply-To: 
On Fri, Jul 15, 2022 at 10:54:28PM +0200, Petr Menšík wrote:

On 7/13/22 19:20, Geert Stappers via Dnsmasq-discuss wrote:

On Fri, Jul 08, 2022 at 10:26:35PM +0200, Petr Menšík wrote:

   ... First two patches were already sent. I think I have sent
also following patches already, but were not able to find them.

To prevent that patches get lost,
advices the Monthly Posting to poke after eight days again.


An additional attempt to prevent that patches (and contributors) get
lost, am I now experimenting with "dnsmasq mailing list patch collection"

It is a git repository that is cloned from git://thekelleys.org.uk/dnsmasq.git
The master branch follows that repo, the other branches have patches
that I collected from this mailinglist. Currently that is the only
extra branch "y22w27", short for "year 2022, week 27". An upcoming
branch is "gcc12".  I'm in need for a (short) branch name for
Create temporary leases for DHCPOFFER actions
as Previous-Subject says / suggests.

Ideas for the branch name are still welcome.


I would prefer to have a feature branches. One mailing list thread, one 
branch for it. If it is named after author and number, it would be okay. 
Something simple to rebase over current master and track independent 
things independent.


Allows separate changes review and merging them in any order without 
extra work.



Webpage https://git.sr.ht/~stappers/dnsmasqmlpc has `git clone URL`
and links for further "browsing".
Example given: https://git.sr.ht/~stappers/dnsmasqmlpc/log/y22w27


Interesting. Do you generate those by hand
or are those generated by some tool?

By hand

  

I have thought about a tool, which would collect patches sent from
registered people and create a pull requests on gitlab or github, which
would show their status. And if possible mark them merged automagically. But
haven't found enough free time to play with that. Sort of external pull
requests, which can be linked to bugs and tracked progress, if any.

There is 'patchwork' http://jk.ozlabs.org/projects/patchwork/
documentation is at https://patchwork.readthedocs.io/en/latest/

My estimation is that we, dnsmasq project, can live without such tool.
On the other hand it would be nice to have such tool.
Of course, Simon is the only maintainer of the repository. Whatever he 
prefers is important. But I guess a tool could make changes tracking 
easier without forcing Simon to change his workflow.

Groeten
Geert Stappers


P.S.
If I have missed patches, just say so.
Seems great! Thanks for the reference. I knew there has to be multiple 
of projects with similar requirements. I will try to read a more about 
it and if it could be enabled as addition to current patches review 
workflow.


Thanks!
Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] [PATCH] Create temporary leases for DHCPOFFER actions

2022-07-15 Thread Petr Menšík
Interesting. Do you generate those by hand or are those generated by 
some tool? Is that tool in some repository also?


I have thought about a tool, which would collect patches sent from 
registered people and create a pull requests on gitlab or github, which 
would show their status. And if possible mark them merged automagically. 
But haven't found enough free time to play with that. Sort of external 
pull requests, which can be linked to bugs and tracked progress, if any.


On 7/13/22 19:20, Geert Stappers via Dnsmasq-discuss wrote:

On Fri, Jul 08, 2022 at 10:26:35PM +0200, Petr Menšík wrote:

Hi!

I have already described similar problem back in year 2021 [1]. There exists
race condition when higher count of clients starts at similar time and
requests DHCP(v4). First two patches were already sent. I think I have sent
also following patches already, but were not able to find them.

To prevent that patches get lost,
advices the Monthly Posting to poke after eight days again.


An additional attempt to prevent that patches (and contributors) get
lost, am I now experimenting with "dnsmasq mailing list patch collection"

It is a git repository that is cloned from git://thekelleys.org.uk/dnsmasq.git
The master branch follows that repo, the other branches have patches
that I collected from this mailinglist. Currently that is the only
extra branch "y22w27", short for "year 2022, week 27". An upcoming
branch is "gcc12".  I'm in need for a (short) branch name for
   Create temporary leases for DHCPOFFER actions
as Subject says / suggests.


Webpage https://git.sr.ht/~stappers/dnsmasqmlpc has `git clone URL`
and links for further "browsing".
Example given: https://git.sr.ht/~stappers/dnsmasqmlpc/log/y22w27


Groeten
Geert Stappers



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


Re: [Dnsmasq-discuss] [PATCH] RFC8520 (MUD) support in DHCP

2022-07-12 Thread Petr Menšík

Seems simple, nice and reasonable. I vote for merging it.

On 11. 07. 22 15:18, Jasper Wiegratz wrote:

Hi Simon,

my university project for network security has been working with a 
fork of dnsmasq for some time now.


I'm submitting the attached 2 patches for dnsmasq master branch to add 
MUD DHCP option and URL extraction. This was requested on the mailing 
list [1] [2].


I'm looking forward to hearing back from you. Thanks for your time and 
efforts.


Best Regards

Jasper Wiegratz


[1] 
https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg12326.html 



[2] 
https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg12116.html 




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


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] [PATCH] free() after use

2022-07-11 Thread Petr Menšík
Correct, I have seen such warning on Fedora 36 too. While technically it 
does not try to use any content of freed pointer, just a pointer value. 
But worth fixing it, consider it a vote from me as well.


But it seems to me we want here just whine_realloc() introduced. It 
would make it slightly more efficient.


On 22. 06. 22 11:05, Geert Stappers via Dnsmasq-discuss wrote:

Because  GCC 12.1 did report:
   cache.c: In function ‘cache_make_stat’:
   cache.c:1683:30: warning: pointer used after ‘free’ [-Wuse-after-free]
1683 | p = new + (p - buff);
 |   ~~~^~~
   cache.c:1682:17: note: call to ‘free’ here
1682 | free(buff);
 | ^~
---
  src/cache.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/cache.c b/src/cache.c
index a99d70d..e221afd 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -1679,8 +1679,8 @@ int cache_make_stat(struct txt_record *t)
if (!(new = whine_malloc(newlen)))
  return 0;
memcpy(new, buff, bufflen);
-   free(buff);
p = new + (p - buff);
+   free(buff);
lenp = p - 1;
buff = new;
bufflen = newlen;


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] malformed DNS packets with edns0 enabled

2022-07-11 Thread Petr Menšík
Can you share any of such recorded packets? The existing pcap file would 
be useful. isc.org is example of signed name with TTL=300. If you have 
names you don't want to share publicly only, please send them to me. I 
am RHEL maintainer, but haven't noticed a behaviour you are describing. 
It sounds like worth investigation. I doubt any state of TTL should make 
requests different.


Do I understand it correctly you have enabled a dnssec validation? If 
you see those on RHEL derivative, consider please filling a bug on 
bugzilla.redhat.com. Even if not using rhel directly, it should be fixed 
there.


Have you tried a CentOS 9 version also?

On 08. 07. 22 19:17, James Brown via Dnsmasq-discuss wrote:

Hello:

We use dnsmasq as a local caching resolver (binding to ::1) and are 
currently upgrading some systems to EL8 (Rocky Linux 8 specifically, 
which is a rebuild of Red Hat 8). We've noticed that a fairly 
significant fraction of name resolutions fail when `|option edns0|` is 
enabled in /etc/resolv.conf and dnsmasq is being used; that is to say, 
when resolv.conf looks like


|option edns0
nameserver ::1|

These failures manifest for queries issued very close to a TTL expiry 
(that is to say, if you request a name X with a TTL of 300 seconds, 
then wait 299.99 seconds, then request X again, it will fail about ½ 
of the time).


I've tried backporting dnsmasq 2.86, but it shows the same behavior.

I used tcpdump to capture the actual request issued and the Wireshark 
protocol analyzer says that dnsmasq is emitting malformed DNS queries.


The query from libc to dnsmasq looks correct and the "additional 
records" portion of the packet contains the following bytes:


00 00 29 04 b0  00 00 00 00 00 00

Based on my reading of EDNS0, this looks right (domain name is 0 bytes 
long and is the root domain; packet type is 0x29 == 41).


However, on failed requests, the packet sent from dnsmasq to the 
upstream DNS server ends with the following "additional records" section:


c0 0c 00 05 00 01 00 00 0c e4 00

This looks like a compressed label, since it starts with 0xc...? Which 
doesn't make any sense to put in the OPT section?


The rest of the query looks fine.

Neither add-mac nor add-subnet is set, and edns-packet-max is set to 4096.

If I turn off dnsmasq and send queries directly to the upstream 
nameserver, I don't ever see any of these "c00c" packets emitted, so 
I am pretty confident that these bad bytes are coming from dnsmasq itself.


Has anyone ever seen anything like this? I'm glad to privately share 
pcaps if that would help.


James Brown
Infrastructure Architect

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


--
Petr Menšík
Software Engineer, RHEL
Red Hat,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] [PATCH] Create temporary leases for DHCPOFFER actions

2022-07-08 Thread Petr Menšík

Hi!

I have already described similar problem back in year 2021 [1]. There 
exists race condition when higher count of clients starts at similar 
time and requests DHCP(v4). First two patches were already sent. I think 
I have sent also following patches already, but were not able to find them.


Anyway, some DHCP clients tend to handle badly situation, where dnsmasq 
first offers them some address. Then later in the process it realizes 
such address were offered also to someone else and denies acking it. We 
already have a workaround merged for IPv6 case, where it will ack 
instead different address. I think it would be nice also for IPv6 the 
same way, but I think it is not as urgent as for IPv4.


I have created a kind of half-lease. When it offers someone address, it 
makes it reserved for that address. That should prevent unnecessary race 
during startup, where some clients tend to receive NACK. When client 
continues with DHCPREQUEST, it converts a temporary lease to a permanent 
lease, which is then stored into lease file.


It solves a race in case more clients requests address than addresses on 
such network are available. When there are the same amount of temporary 
leases and remaining addresses, it reuses random temporary lease. Of 
course in such situation a failures are unavoidable. But I think it 
should attempt do the best available.


I am attaching also setup.sh, which I used to emulate starting multiple 
clients at similar time. I configured dnsmasq listening on virbr1 device 
and offering addresses. Then run that script as root and record 
communication in wireshark. Unlike current situation, there should not 
be any NACKs present. Even though ISC dhclient handles NACK well and is 
able to retry, unlike some netbooting firmware, which fails the boot in 
such situation.


Comments or testing would be welcome.

This is tracked on redhat bug #2028704 [2]. I have pushed those commits 
also to dhcp-temp-leases branch in github [3].


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

2. https://bugzilla.redhat.com/show_bug.cgi?id=2028704
3. https://github.com/InfrastructureServices/dnsmasq/tree/dhcp-temp-leases
From 3930e69abd272ea49e026ced78f8660564d34858 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Wed, 8 Dec 2021 00:39:30 +0100
Subject: [PATCH 1/6] Add icmp ping hash also when pinging requested address

Previously requested address were pinged always with hash 0, but pinged
from address_allocate with different hash. Try using the same hash for
the same client, regardless what source place it were used.
---
 src/dhcp.c| 26 +-
 src/dnsmasq.h |  1 +
 src/rfc2131.c |  3 ++-
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/src/dhcp.c b/src/dhcp.c
index 8e9c606..1cf0b5b 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -715,6 +715,21 @@ struct dhcp_config *config_find_by_address(struct dhcp_config *configs, struct i
   return NULL;
 }
 
+unsigned int ping_hash(unsigned char *hwaddr, int hw_len)
+{
+  int i;
+  unsigned int j = 0;
+  /* hash hwaddr: use the SDBM hashing algorithm.  Seems to give good
+ dispersal even with similarly-valued "strings". */
+  for (i = 0; i < hw_len; i++)
+j = hwaddr[i] + (j << 6) + (j << 16) - j;
+
+  /* j == 0 is marker */
+  if (j == 0)
+j = 1;
+  return j;
+}
+
 /* Check if and address is in use by sending ICMP ping.
This wrapper handles a cache and load-limiting.
Return is NULL is address in use, or a pointer to a cache entry
@@ -785,18 +800,11 @@ int address_allocate(struct dhcp_context *context,
 
   struct in_addr start, addr;
   struct dhcp_context *c, *d;
-  int i, pass;
+  int pass;
   unsigned int j; 
 
-  /* hash hwaddr: use the SDBM hashing algorithm.  Seems to give good
- dispersal even with similarly-valued "strings". */ 
-  for (j = 0, i = 0; i < hw_len; i++)
-j = hwaddr[i] + (j << 6) + (j << 16) - j;
+  j = ping_hash(hwaddr, hw_len);
 
-  /* j == 0 is marker */
-  if (j == 0)
-j = 1;
-  
   for (pass = 0; pass <= 1; pass++)
 for (c = context; c; c = c->current)
   if (c->flags & (CONTEXT_STATIC | CONTEXT_PROXY))
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index a8937ce..88ff980 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -1499,6 +1499,7 @@ struct dhcp_context *address_available(struct dhcp_context *context,
 struct dhcp_context *narrow_context(struct dhcp_context *context, 
 struct in_addr taddr,
 struct dhcp_netid *netids);
+unsigned int ping_hash(unsigned char *hwaddr, int hw_len);
 struct ping_result *do_icmp_ping(time_t now, struct in_addr addr,
  unsigned int hash, int loopback);
 int address_allocate(struct dhcp_context *context,
diff --git a/src/rfc2131.c b/src/rfc2131.c
index ecda2d3..a7ce872 100644
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -1133,7 +1133,8 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index,
 		   

Re: [Dnsmasq-discuss] Possible to reuse Cache over restats?

2022-07-01 Thread Petr Menšík

Nice, very helpful.

Why do you use all-servers and strict-order with servers 1.1.1.1 and 
1.0.0.1? I don't think they provide different results. Just keep the 
default, dnsmasq would try to find whichever is faster. It would try the 
other one if the first failed in any case.


Have you tried disabling periodic restarts? How does broken resolution 
look like when it stops working, with this setting? Can you show us some 
logs? At least example of failing query?


I like to check dnsmasq is listening correctly by lsof -np $(pidof dnsmasq).

sudo ss -lnp | grep dnsmasq should print also buffer usage.

Would those commands reveal something suspicious? Can you compare their 
output when it works and when it stopped working?


On 7/1/22 17:50, Tobias Hochgürtel wrote:

On 30.06.22, 15:42, "Geert Stappers"  wrote:
 Acknowledge on "I'm still stuck", but what about:

 * Reread the manual page and in particular --log-queries option

 ???

Three questionmarks, okay I did something wrong?
I reread the man page and figure out some misunderstands about --no-daemon 
mode, and I think Geert Stappers, wanted to have my configuration file?

dnsmasq.conf: 
https://gist.github.com/tobiashochguertel/c65386ce594c09ffcba11acc6a6cca47


-q, --log-queries
   Log the results of DNS queries handled by dnsmasq. Enable a full cache 
dump on receipt of SIGUSR1. If the argument "extra" is supplied, ie 
--log-queries=extra then the log has extra information at the start of each line.  This 
consists of a serial number which ties together the log lines associated with an 
individual query, and the IP address of the requestor.

I didn't know this little detail about the parameter "extra" for log-queries. I 
will add this, and update the above gist to Rev 3.

On 30.06.22, 15:42, "Geert Stappers"  wrote:

 On Thu, Jun 30, 2022 at 12:32:20PM +, Tobias Hochgürtel wrote:
 > From: Donald Muller, Date: Thursday, 30. June 2022 at 02:48
 > > Geert Stappers, Sent: Wednesday, June 29, 2022 6:14:30 PM
 > > > On Wed, Jun 29, 2022 at 08:25:18PM +, Dominik Derigs wrote:
 > > > > On Wed, 2022-06-29 at 18:37 +, Tobias Hochgürtel wrote:
 > > > > }  "state" is piled up
 > > > > }  I do a hourly restart to loose state.
 > > > > }  But I don't want to loose all the state!
 > > > > > I also don't know how I can analyse that behavior.
 > > > >
 > > > > You could use some widely known and used tools like Wireshark 
where various
 > > > > tutorial are available to see whether the issue is dnsmasq not 
responding
 > > > > or the queries not making their way to dnsmasq or if something 
happens to
 > > > > the queries sent upstream to the forward destionation, or whatever 
else may
 > > > > be happening. We can surely give some assistance here, if you want.
 > > >
 > > > Here already some assistance:
 > > >
 > > >
 > > > * Tell us which version of dnsmasq is being used
 > > > * Reread the manual page and in particular --log-queries option
 > >
 > > Also, what you are running it on?
 >
 > [root@router-fedora ~]# hostnamectl
 > Static hostname: router-fedora
 >Icon name: computer-desktop
 >  Chassis: desktop 
 >   Machine ID: c9c0e33265b848bfbce224fd8615fb30
 >  Boot ID: 0824361c352745c0a35a75167a2f81a0
 > Operating System: Fedora Linux 36 (Server Edition)
 >  CPE OS Name: cpe:/o:fedoraproject:fedora:36
 >   Kernel: Linux 5.18.6-200.fc36.x86_64
 > Architecture: x86-64
 >  Hardware Vendor: BIOSTAR Group
 >   Hardware Model: N3150NH
 >
 > [root@router-fedora ~]# dnsmasq --version
 > Dnsmasq version 2.86  Copyright (c) 2000-2021 Simon Kelley
 > Compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP
 >   DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect
 >   inotify dumpfile
  
 Acknowledge on "I'm still stuck", but what about:
 
 * Reread the manual page and in particular --log-queries option
 
 ???
 
 
 
 Regards

 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] Possible to reuse Cache over restats?

2022-06-30 Thread Petr Menšík
I am maintainer of Fedora dnsmasq package.  I don't know about any issue 
with latest dnsmasq on f36. It should work reliably.


I agree with Geert, log-queries option should reveal the most details 
for troubleshooting. Default logging to journal should be enough. Use 
"journalctl -xeu dnsmasq" command to see the most recent output of dnsmasq.


You should see whether incoming query were received by the dnsmasq. And 
where did it forwarded it. It should log also what forwarder replied. If 
reply after forward is not logged but wireshark can record such packets, 
it would mean some error in socket handling code. But I think all known 
errors in Fedora 36 were fixed.


It is possible to send SIGHUP to dnsmasq to clear just cache. Just use 
kill -SIGHUP $(pidof dnsmasq). But that should not be necessary, 
especially not periodic way. Because systemd-resolved is enabled by 
default on Fedora, are you sure you have disabled it correctly? Are you 
connected by multiple interfaces at the same time? Would it work with 
just one interface connected?


Lets find somehow a reason for your broken resolution instead of dumping 
the cache periodically. While it should work even with that, it 
definitely should not be required.


Cheers,
Petr

On 30. 06. 22 14:32, Tobias Hochgürtel wrote:


On Wed, Jun 29, 2022 at 08:25:18PM +, Dominik Derigs wrote:

  * Tell us which version of dnsmasq is being used

  * Reread the manual page and in particular --log-queries option

[root@router-fedora ~]# *hostnamectl*

Static hostname: router-fedora

   Icon name: computer-desktop

 Chassis: desktop 

  Machine ID: c9c0e33265b848bfbce224fd8615fb30

 Boot ID: 0824361c352745c0a35a75167a2f81a0

Operating System: *Fedora Linux 36 (Server Edition)*

 CPE OS Name: cpe:/o:fedoraproject:fedora:36

  Kernel: *Linux 5.18.6-200.fc36.x86_64*

    Architecture: x86-64

Hardware Vendor: BIOSTAR Group

  Hardware Model: N3150NH

[root@router-fedora ~]# *dnsmasq --version*

*Dnsmasq version 2.86*Copyright (c) 2000-2021 Simon Kelley

Compile time options: *IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP 
DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect 
inotify dumpfile*


This software comes with ABSOLUTELY NO WARRANTY.

Dnsmasq is free software, and you are welcome to redistribute it

under the terms of the GNU General Public License, version 2 or 3.

From: Dnsmasq-discuss 
 on behalf of Donald 
Muller 


Date: Thursday, 30. June 2022 at 02:48

To: Geert Stappers , 
"dnsmasq-discuss@lists.thekelleys.org.uk" 



Subject: Re: [Dnsmasq-discuss] Possible to reuse Cache over restats?

Also, what you are running it on?

From: Dnsmasq-discuss 
 on behalf of Geert 
Stappers via Dnsmasq-discuss 


Sent: Wednesday, June 29, 2022 6:14:30 PM

To: dnsmasq-discuss@lists.thekelleys.org.uk 



Subject: Re: [Dnsmasq-discuss] Possible to reuse Cache over restats?

On Wed, Jun 29, 2022 at 08:25:18PM +, Dominik Derigs wrote:

> On Wed, 2022-06-29 at 18:37 +, Tobias Hochgürtel wrote:

> > There isn't a feature to reuse the dns-cache?

> > or a plan to add this feature?

> > 

> 


> There is no such feature and there is also nothing planned at the moment

Oh, it was not a joke.

> However, restarting dnsmasq once per hour surely is the least optimal

> solution to circumvent what you are observing.

So true.

> On Wed, 2022-06-29 at 18:37 +, Tobias Hochgürtel wrote:

> > I also don't know how I can analyse that behavior.

> 


> You could use some widely known and used tools like Wireshark where various

> tutorial are available to see whether the issue is dnsmasq not responding

> or the queries not making their way to dnsmasq or if something happens to

> the queries sent upstream to the forward destionation, or whatever else may

> be happening. We can surely give some assistance here, if you want.

Here already some assistance:

* Tell us which version of dnsmasq is being used

* Reread the manual page and in particular --log-queries option

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


--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] DNSMASQ Cache

2022-06-20 Thread Petr Menšík
Even if that value were never used, it should be initialized to a 
defined value. Be it 0 or ~0, it does not matter. But it should not have 
random value from stack, even in case it cannot be obtained by outer 
requests.


On 19. 06. 22 23:48, Simon Kelley wrote:

On 13/06/2022 08:16, John Gilmour via Dnsmasq-discuss wrote:

Hello,


First time user so please bear with me.


I have some quite specific in-house code that relies on the 
"cache->ttd" value.  I have noticed that the function "cache_reload" 
in "src/cache.c" defines the following variable:

struct crec lrec


Further down in this function it makes non-terminal records for all 
locally-defined RRs.  It may be more of a question but why are the 
"ttd", "uid" and "ns_id" fields not initialized before the various 
calls to "make_non_terminals()".   When I check the value of the 
"cache->ttd" in this function it's clearly just going to be random.




cache entries which don't expire are marked by setting the F_IMMORTAL 
flag in the ->flags field. If that flag is set then the value of ->ttd 
is meaningless and unused. It's done this way rather than assigning a 
special value to ttd because the time scale varies in different 
installations and there isn't a suitable "special" time value that 
will always work.





Is this just an oversight or is deliberately not set?


See above.


Cheers,

Simon.




Best regards,


John.



--
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] [PATCH] Forgotten servers from file config on dbus servers update

2022-06-17 Thread Petr Menšík
It got reported to me on bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=2061944


This issue were introduced by commit 
553c4c99cca173e9964d0edbd0676ed96c30f62b, which I backported to Fedora. 
I believe it is still unfixed even in master branch.


It is usually simple to reproduce it, when dns=dnsmasq is set in NM. 
Then when I connect both on ethernet and wifi, it happens always. I am 
not sure why it happens only on two interfaces configured, that might be 
just coincidence. Or it requires existing dbus configuration to break. 
It does not matter, the problem is elsewhere.


When dbus calls add_update_server function, it has first server in 
daemon->servers with flags == 0, domain set from dnsmasq configuration 
file. When add_update_server is called from dbus update, it marks all 
dbus servers. Then when at least two dbus servers were configured, it 
will forget servers at the beginning without mark and replace 
daemon->servers with serv->next pointer. Which is some server set by 
dbus in this case. The first servers get leaked and their redirection 
does not work anymore.


That happens because up pointer were not updated in else branch. up 
needs to be updated when not marked, just like it is done in 
cleanup_servers function. I have moved out the loop closer to it into 
separate replace_server function. It makes it easier to compare again 
similar loops above it.


Cheers,

Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 7e2e0a573835aa312f0a099c80faaa7a1afb60c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Fri, 17 Jun 2022 11:40:56 +0200
Subject: [PATCH] Correct add_update_server losing first unmarked entries

Beginning of servers list were updated when first server(s) record is
not marked. That was a mistake, which forgot updating also up pointer to
correct value. Move that loop to separate reuse_server function, which
is close to similar loop in cleanup_servers. Makes it easier to compare
and do correct. Removed tmp variable, because this code does not
invalidate previous serv pointer.
---
 src/domain-match.c | 50 ++
 1 file changed, 28 insertions(+), 22 deletions(-)

diff --git a/src/domain-match.c b/src/domain-match.c
index 32a269e..1882ffd 100644
--- a/src/domain-match.c
+++ b/src/domain-match.c
@@ -606,6 +606,33 @@ void cleanup_servers(void)
   build_server_array();
 }
 
+/* Upstream servers. See if there is a suitable candidate, if so unmark
+   and move to the end of the list, for order. The entry found may already
+   be at the end. */
+static struct server *reuse_server(char *alloc_domain)
+{
+  struct server **up, *serv;
+
+  for (serv = daemon->servers, up = >servers; serv; serv = serv->next)
+{
+  if ((serv->flags & SERV_MARK) &&
+	  hostname_isequal(alloc_domain, serv->domain))
+	{
+	  /* Need to move down? */
+	  if (serv->next)
+	{
+	  *up = serv->next;
+	  daemon->servers_tail->next = serv;
+	  daemon->servers_tail = serv;
+	  serv->next = NULL;
+	}
+	  return serv;
+	}
+  up = >next;
+}
+  return NULL;
+}
+
 int add_update_server(int flags,
 		  union mysockaddr *addr,
 		  union mysockaddr *source_addr,
@@ -665,28 +692,7 @@ int add_update_server(int flags,
 }
   else
 { 
-  /* Upstream servers. See if there is a suitable candidate, if so unmark
-	 and move to the end of the list, for order. The entry found may already
-	 be at the end. */
-  struct server **up, *tmp;
-  
-  for (serv = daemon->servers, up = >servers; serv; serv = tmp)
-	{
-	  tmp = serv->next;
-	  if ((serv->flags & SERV_MARK) &&
-	  hostname_isequal(alloc_domain, serv->domain))
-	{
-	  /* Need to move down? */
-	  if (serv->next)
-		{
-		  *up = serv->next;
-		  daemon->servers_tail->next = serv;
-		  daemon->servers_tail = serv;
-		  serv->next = NULL;
-		}
-	  break;
-	}	
-	}
+  serv = reuse_server(alloc_domain);
 
   if (serv)
 	{
-- 
2.35.3

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


Re: [Dnsmasq-discuss] Disable dhcp-option for a single host

2022-06-17 Thread Petr Menšík


On 05. 06. 22 13:41, Brian Rossa wrote:

Hello,

I'm doing some firmware-related work and am using a --dhcp-hostsdir 
setup to test several devices on my LAN. This is working fine, but I 
appear to have hit the limits of my dnsmasq-fu when attempting to 
*toggle* the DHCP options for a particular end host.


Namely, (1) the global config sets enable-tftp and (2) the hostsdir 
config for the target device starts as "{mac},{ip},set:green". During 
my test I (3) update it asynchronously to "{mac},{ip},set:red" and (4) 
hit dnsmasq with SIGHUP. According to my understanding, this will 
cause dnsmasq to clear its host cache and reload the hostsdir configs.


The only remaining question, then, is how to specify individual 
dhcp-option disablement for the target. Specifically, for "red" tags, 
I tried the following configuration to override the global tftp-enable 
setting:


dhcp-option=tag:red,option:tftp-server,""
dhcp-option=tag:red,option:tftp-server-address,""
dhcp-option=tag:red,option:boot-file-size,""
dhcp-option=tag:red,option:bootfile-name,""


What about doing just negated option? Send that option for every client 
but few you don't want to. That is what you want, right? Send correct 
values only to those, who are not in red tag.


dhcp-option=tag:!red,option:tftp-server,127.0.0.127
dhcp-option=tag:!red,option:tftp-server-address,127.0.0.127
dhcp-option=tag:!red,option:boot-file-size,123
dhcp-option=tag:!red,option:bootfile-name,"example.bin"



Unfortunately, this approach seems to be flawed as the service 
complains that empty string is an invalid option and never comes up.


Is there a common "disable" flag for scenarios like this? If so, I 
could not find it in the docs. If not, what approach is recommended 
for these kinds of per-host override situations?


Thanks!
~br


Unless you have complicated conditions already, above solution should work.

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] DNSSEC validation

2022-06-11 Thread Petr Menšík

I would suggest using delv +vtrace @8.8.8.8


Then compare it with delv +vtrace @127.0.0.1


It is not about the AD flag, dnsmasq would set it itself. But there have 
to be RRSIG records when you do dig +dnssec. All 1.1.1.1, 8.8.8.8 or 
9.9.9.9 should support DNSSEC just fine. Is it possible your request are 
intercepted on the way by different server?



You would have to use DNS over TLS or DNS over HTTPS, which dnsmasq does 
not support. Or maybe just different internet provider.



On 08. 06. 22 13:04, Stuart Bailey wrote:

Hello,
I have dnsmasq running on a Debian server / router, configured so that 
clients on the 'LAN' side can send DNS queries to the server rather 
than directly to the Internet. I'd like to configure dnsmasq to 
validate DNSSEC responses, but when I add the lines:


conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
dnssec

to my config file, all DNS request to forwarders no fail.

If I run
dig +dnssec @8.8.8.8 
directly on the server, I get the expected response with the 'ad' flag 
as appropriate.


My dnsmasq.conf file looks like:

# Configuration file for dnsmasq.
#
domain-needed
bogus-priv
localise-queries
domain=integra-edge.io
no-hosts
local=/integra-edge.io/
port=53
log-queries
log-debug
max-ttl=1
listen-address=127.0.0.1
cache-size=1000
no-resolv
no-poll

strict-order
server=1.1.1.1
server=8.8.8.8
server=9.9.9.9

conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
dnssec
#dnssec-check-unsigned

dhcp-leasefile=/var/lib/dhcp/dnsmasq.leases

conf-dir=/etc/dnsmasq.d/dhcp,*.conf

Using tcpdump, I can see that dnsmasq seems to get stuck on the DNSKEY 
request:
10:59:15.431106 IP 192.168.20.55.43867 > dns9.quad9.net.domain: 33763+ 
[1au] A? bbc.co.uk. (50)
10:59:15.471293 IP dns9.quad9.net.domain > 192.168.20.55.43867: 33763 
4/0/1 A 151.101.192.81, A 151.101.64.81, A 151.101.0.81, A 
151.101.128.81 (102)
10:59:15.471497 IP 192.168.20.55.45970 > dns9.quad9.net.domain: 27235+ 
[1au] DS? uk. (31)
10:59:15.508817 IP dns9.quad9.net.domain > 192.168.20.55.45970: 27235$ 
2/0/1 DS, RRSIG (366)
10:59:15.509375 IP 192.168.20.55.60968 > dns9.quad9.net.domain: 38502+ 
[1au] DNSKEY? . (28)
10:59:20.434731 IP 192.168.20.55.60968 > dns9.quad9.net.domain: 38502+ 
[1au] DNSKEY? . (28)
10:59:25.438660 IP 192.168.20.55.60968 > dns9.quad9.net.domain: 38502+ 
[1au] DNSKEY? . (28)



But using dig directly as above, I only get:
11:00:42.118765 IP 192.168.20.55.34235 > dns9.quad9.net.domain: 47855+ 
[1au] A? bbc.co.uk. (50)
11:00:42.149587 IP dns9.quad9.net.domain > 192.168.20.55.34235: 47855 
4/0/1 A 151.101.64.81, A 151.101.128.81, A 151.101.192.81, A 
151.101.0.81 (102)


I am running Debian 11 (bullseye) with dnsmasq version 2.85
my trust-anchors.conf file is the standard file shipped with Bullseye.

Many thanks,

Stuart

/This email and any attachments are confidential and intended solely 
for the individual to whom it is addressed. Any view or opinion 
expressed belongs solely to the author and does not necessarily 
represent those of Applied Satellite Technology Ltd, its subsidiaries 
or any affiliated group company (AST). If you are not the intended 
recipient please do not disclose, copy or distribute information in 
this email nor take any action in reliance of its content; to do so is 
strictly prohibited and may be unlawful. Please inform us if you have 
received this message in error before deleting it. All liability is 
excluded to the extent permitted by law for any claims arising as a 
result of the use of this medium to transmit information by or to AST. 
Thank you for your co-operation.


Applied Satellite Technology Ltd | Company Number: 2153172 England | 
Registered Office: Satellite House, Bessemer Way, Harfreys Industrial 
Estate, Great Yarmouth, Norfolk NR31 0LX (UK)


/

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


--
Petr Menšík
Software Engineer, RHEL
Red Hat,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


  1   2   3   >