Hi Geert, Thanks for coming back to me on this.
> From: Dnsmasq-discuss <dnsmasq-discuss-boun...@lists.thekelleys.org.uk> on > behalf of Geert Stappers <stapp...@stappers.nl> > Sent: 14 October 2024 16:26 > To: dnsmasq-discuss@lists.thekelleys.org.uk > <dnsmasq-discuss@lists.thekelleys.org.uk> > Subject: Re: [Dnsmasq-discuss] Problem with auth and sub-domain servers after > chain extension > > CAUTION: This email originated from outside of Veea. Do not click links or > open attachments unless you recognize the sender and know the content is safe. > > > On Thu, Oct 10, 2024 at 10:13:05AM +0000, Roger Lucas via Dnsmasq-discuss > wrote: > > > > We have corporate Windows domain servers which delegate > > "labs.internal.company.com" to a DNSMASQ instance running on the > > lab gateway. > > > > This DNSMASQ instance has to run in authoritative mode otherwise we have > > problems with Windows DNS refusing to use it. > > > > The setup has worked well for years, until the lab network grew so > > big that we broke it up into sub-networks. > > Acknowledge > > > > Each sub-network has its own gateway running DNSMASQ. > > These sub-networks for the labs are lab1.labs.internal.company.com, > > lab2.labs.internal.company.com, lab3.labs.internal.company.com, etc. > > > > On the main lab gateway, I have a DNSMASQ config as below: > > > > resolv-file=/etc/resolv.conf.dnsmasq > > server=/lab1.labs.internal.company.com/10.64.241.1 > > server=/lab2.labs.internal.company.com/10.64.242.1 > > server=/lab3.labs.internal.company.com/10.64.243.1 > > no-dhcp-interface=eno1,lo > > dhcp-range=10.64.0.50,10.64.0.199,12h > > log-queries > > log-facility=/var/log/dnsmasq.log > > log-dhcp > > auth-server=labs.internal.company.com > > auth-zone=labs.internal.company.com > > auth-soa=2,admin.labs.internal.company.com > > auth-ttl=600 > > > > The main lab gateway is running DNSMASQ v2.90. > > > > The problem is that I don't get any delegated queries to the lab[123] > > DNSMASQ instances. > > When I send a DNS query to the lab gateway for a server in any of the > > lab[123] sub-domains, I get an immediate NXDOMAIN back. > > If I query the appropriate sub-domain server for the same FQDN, I get > > the expected reply. > > If I run tcpdump on the sub-domain server, I don't see any query > > coming in when I try to look up the FQDN on the main lab gateway, > > so the query isn't being passed on to the sub-domain server. > > > > I'm sure this is related to the auth-server aspect and I've read the > > DNSMASQ man page and Googled, but I can't see how to get it to work. > > As I see it, is the extension of the chain incomplete. [1] > > With "chain" I mean chain of DNServers. With "extension" I mean > the insertion of a DNS in the chain. I'm sorry, but I can't see where the chain is broken. Let's consider "lab1". I have the main lab gateway running on 10.64.0.1 with an instance of dnsmasq that is authoritative for "labs.internal.company.com". I have the gateway for LAB #1 on 10.64.241.1 and with an instance of dnsmasq managing "lab1.labs.internal.company.com". This is a sub-domain of "labs.internal.company.com". If I perform an "nslookup pc1.lab1.labs.internal.company.com 10.64.241.1" then this goes directly to the LAB #1 server and I get the expected A-record back. If I perform an "nslookup pc1.lab1.labs.internal.company.com 10.64.0.1" then this goes to the main lab gateway, and I get an NXDOMAIN back. I would have expected the config line "server=/lab1.labs.internal.company.com/10.64.241.1" in the main lab gateway to have caused the query to be forwarded from 10.64.0.1 to 10.64.241.1. I understand that authoritative mode is special, so there may be specific logic in dnsmasq to *not* behave as I was expecting above. I've not read through the code yet to see if this is the case. If dnsmasq is deliberately not doing the above, that's OK. I had avoided using BIND on the main lab gateway because dnsmasq is so much simpler to set up, but if dnsmasq is deliberately written to handle authoritative domains differently, then I can set up BIND on the main gateway. I don't want to try to make changes to dnsmasq if it is deliberately behaving differently. > > > > Thanks in advance for any suggestions! > > Back to the drawing board, draw the chain on it. > Make a cut in the chain, insert the extra DNS. > Complete the chain, put in all the needed connections. > > Please report back. > > > Groeten > Geert Stappers > > [1] And I think that parts of the extension are wrong, > but it could be that I misread the provided information. > -- > 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 Thanks for taking the time to look into this, it is very appreciated. Many thanks/Dank u wel, Roger _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
