Conditional Forwarding and Split Horizon DNS

[deHakkelaar]

I dont have a quick solution but ... CF consists of two parts.
One part for forward lookups (name to IP) and one part for reverse lookups (IP to name).

@originalme8

true,10.1.0.0/16,10.1.10.20#53,domain.local

Above bit instructs forward lookups for the domain: domain.local to be forwarded to DNS server 10.1.10.20.
And reverse lookups for the 10.1.0.0/16 addresses to be forwarded to also 10.1.10.20.
Forward lookup example with 10.0.0.2 being my Pi-hole:

$ dig +short @10.0.0.2 hak01
10.0.0.145

Reverse lookup example:

$ dig +short @10.0.0.2 -x 10.0.0.145
hak01.home.dehakkelaar.nl.

@originalme8

true,10.2.0.0/16,1.1.1.1#53,domain.local
true,10.1.0.0/16,10.1.10.20#53,domain.local

From above, not sure if you can split up the domain: domain.local into two subnets with embedded dnsmasq like above.
I suspect dnsmasq will pick the first or last one only from above two directives.
Try changing the order to play around and follow the logs live to see what happens when testing:

sudo pihole tail

@originalme8

true,10.2.0.0/16,1.1.1.1#53
true,10.1.0.0/16,10.1.10.20#53

Above only deals with reverse lookups and not the forward lookups for domain.local!

@originalme8

domain.local

Ps. about the .local search/suffix domain above:

@deHakkelaar

Ps. I dont recommend using above .local as a search/suffix domain.
Thats a special domain intended for mDNS and not for regular old school DNS.
From the mDNS RFC:

Appendix G. Private DNS Namespaces

The special treatment of names ending in ".local." has been
implemented in Macintosh computers since the days of Mac OS 9, and
continues today in Mac OS X and iOS. There are also implementations
for Microsoft Windows [B4W], Linux, and other platforms.

Some network operators setting up private internal networks
("intranets") have used unregistered top-level domains, and some may
have used the ".local" top-level domain. Using ".local" as a private
top-level domain conflicts with Multicast DNS and may cause problems
for users. Clients can be configured to send both Multicast and
Unicast DNS queries in parallel for these names, and this does allow
names to be looked up both ways, but this results in additional
network traffic and additional delays in name resolution, as well as
potentially creating user confusion when it is not clear whether any
given result was received via link-local multicast from a peer on the
same link, or from the configured unicast name server. Because of
this, we recommend against using ".local" as a private Unicast DNS
top-level domain. We do not recommend use of unregistered top-level
domains at all, but should network operators decide to do this, the
following top-level domains have been used on private internal
networks without the problems caused by trying to reuse ".local." for
this purpose:

  .intranet.

.internal.
.private.
.corp.
.home.
.lan.

RFC 6762: Multicast DNS