[Dnsmasq-discuss] Problem with auth and sub-domain servers after chain extension

[Roger Lucas]

Hi Geert,

Thanks for coming back to me on this.

> From: Dnsmasq-discuss <dnsmasq-discuss-bounces at lists.thekelleys.org.uk> on behalf of Geert Stappers <stappers at stappers.nl>
> Sent: 14 October 2024 16:26
> To: dnsmasq-discuss at lists.thekelleys.org.uk <dnsmasq-discuss at 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 at 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