[Dnsmasq-discuss] DNS forwarding steered based on source interface?

[Christopher Hill]

On 4/19/24 00:29, Geert Stappers wrote:
> On Fri, Apr 19, 2024 at 06:20:03AM +0200, Geert Stappers wrote:
>> On Thu, Apr 18, 2024 at 10:07:04PM -0400, Christopher Hill wrote:
>>> Hi,
>>>
>>> I have a question regarding if upstream DNS forwarding can be based on the
>>> source interface? Reading the manual I don't believe it is possible..?
>>>
>>> The scenario I have is two VLANs that can talk to each other and both use
>>> dnsmasqfor local name resolution - this works fine. Each VLAN is configured
>>> at the gateway to default route traffic to different VPNs, e.g. VLAN1 out to
>>> VPN1, and VLAN2 to VPN2 respectively, and I would like dnsmasq to forward
>>> requests originating on VLAN1 to the DNS on VPN1, and the same for VLAN2
>>> forwarding to VPN2.
>>>
>>> To illustrate:
>>>
>>>               tun1     VPN1   VPN2     tun2
>>>               10.0.1.1  |       | 10.0.2.1
>>>                         +---+---+
>>>                             |
>>>                            WAN
>>>                             |
>>>                     +-------+--------+
>>>                     |      eth0      |
>>>            VLAN 1 <-+-eth1      eth2-+-> VLAN 2
>>>    192.168.1.0/24   |    (gateway)   |   192.168.2.0/24
>>>                     +----------------+
>>>
>>>
>>> I would like to do something like the following in the dnsmasq configuration
>>> on the gateway:
>>>
>>>    server=eth1,10.0.1.1 at tun1
>>>    server=eth2,10.0.2.1 at tun2
>>>
>>> i.e. queries arriving on eth1 get sent to 10.0.1.1 via tun1, and queries
>>> arriving on eth2 get sent to 10.0.2.1 via tun 2.
>>>
>>> I have considered running two instances (one bound to eth1 and another
>>> to eth2) but that duplicates setup and makes local queries across VLANs more
>>> complicated.
>> Read the dnsmasq manual and reread the dnsmasq manual.
>   
>   --server=[/[<domain>]/[domain/]][<server>[#<port>]][@<interface>][@<source-ip>[#<port>]]
>

I have tried the below (with and without the interface part)

   --server=10.0.1.1 at eth1@192.168.1.1
   --server=10.0.2.1 at eth2@192.168.2.1

This results in queries originating from either VLAN being routed to 
*both* 10.0.1.1 and 10.0.2.1, it doesn't "pin" incoming queries to their 
respective upstream VPN.

Debug logs show:

   dnsmasq: started, version 2.89 cache disabled
   dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 
DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC 
loop-detect inotify dumpfile
   dnsmasq: using nameserver 10.0.1.1#53(via eth1)
   dnsmasq: using nameserver 10.0.2.1#53(via eth2)
   dnsmasq: read /etc/hosts - 8 names

Then servicing a query:

   dnsmasq: query[A] google.com from 192.168.1.15           <-- client 
is on vlan1
   dnsmasq: forwarded google.com to 10.0.2.1             <-- sent to vpn2
   dnsmasq: reply google.com is 172.217.1.110
   dnsmasq: query[AAAA] google.com from 192.168.1.15
   dnsmasq: forwarded google.com to 10.0.2.1
   dnsmasq: reply google.com is 2607:f8b0:4009:801::200e

Notice the query came in on VLAN 1 but went to VPN2. :-(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20240419/fbfa4f26/attachment.htm>