Re: [Dnsmasq-discuss] Dnsmasq IPv6 NXDOMAIN issue when using synth-domain for IPv4

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


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

should fix things.


Cheers,

Simon.



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

Hi,

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


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



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


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


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

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

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


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

Re: [Dnsmasq-discuss] [PATCH] Introduce local-service=host specialization

2023-12-03 Thread Simon Kelley 
Looks sensible to me. Very much in the spirit of the original 
--local-service option flag.


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


Simon.


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

Hello!

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


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


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


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


What do you think?

Looking for any feedback!

Regards,
Petr

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

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


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


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

Re: [Dnsmasq-discuss] Domain not applied correctly when reading DHCP lease file

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


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

reorders things and should fix this.


Cheers,

Simon.


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

I have the following config:

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

eth1 is 10.0.1.1/24.

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

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

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

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

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



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