On Mon, Oct 14, 2024 at 05:24:54PM +0000, Roger Lucas via Dnsmasq-discuss wrote:
> From: Dnsmasq-discuss on behalf of Geert Stappers:
> Sent: 14 October 2024 16:26
> > 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.
Acknowledge
> 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!
> >
Retransmitting the suggestion ( with correction ;-)
> > Back to the drawing board, draw the chain on it.
Back to the drawing board, draw the original chain on it.
> > Make a cut in the chain, insert the extra DNS.
> > Complete the chain, put in all the needed connections.
Complete in the drawing the chain,
put in all the needed connections.
> >
Better word for drawing would be schematic.
Use the schematic now for trouble shooting,
keep it later for documentation purpose.
[2]
>
>
> Thanks for taking the time to look into this, it is very appreciated.
>
> Many thanks/Dank u wel,
No and no. No to "Thanks for looking into this", no to "Many thanks".
Be main stakeholder of the challenge.
> Roger
Groeten
Geert Stappers
[1] And I think that parts of the extension are wrong,
but it could be that I misread the provided information.
[2] I'm bold/blunt/rude/straight enough to say
"The lack of drawings / schematics is a strong indicator of a lack of
design"
--
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
