I just got it working. Your statement "but if the first line wins" gave me an idea. I cleaned up the config file and put these two lines in with this specific order:
server=/vpn.example.com/10.0.0.140 local=/vpn.example.com/ This is exactly reversed of the order I was using (I had local first, then server). It works now, any machine on the main network can send a DNS query to the router for any of the VPN machines and the query is forwarded over to the VPN server (I am able to see the packet arrive on the VPN server). So perhaps the documents should add that the server/local lines are order specific when handling subdomains of the base local domain otherwise it attempts to be authoritative for all of the domain even if there are other server lines. The server line works fine for external domains because they don't conflict with the local domain (in fact I've used them before for that purpose, to fix broken outside DNS servers by routing specific domains to alternate DNS servers). I just had never tried a subdomain of my own domain and I simply duplicated an old server line all of which came after the local directive at the top of the file. Thanks for the help, that was a bit of a mystery. On 2015-12-01 15:40, A C wrote: > On 2015-12-01 13:22, Albert ARIBAUD wrote: >> Hi "A C", >> >> Le Tue, 1 Dec 2015 09:59:07 -0800 >> A C <ag...@hotmail.com> a écrit: >> >> (note : local= is synonymous to server=) >> >>> local=/example.com/ >> >> This one means *example.com should be resolved by reading /etc/hosts >> or the DHCP lease info. > > Right, that's what I expect. The docs say, though, that a more specific > version will take precedence over a more general version. So > /vpn.example.com/ should take precedence over /example.com/ when > performing the redirect. If that's not the case then the docs should > reflect that. > >> >>> local=/vpn.example.com/ >>> server=/vpn.example.com/10.0.0.140 >> > >> Those two are contradictory since they specify the same domain. What > >> happens then, I don't know, but f the first line wins, then > >> *vpn.example.com will be resolved using /etc/hosts or DHCP leases, and > >> therefore will fail. > >> > > I took out the second local statement but it still didn't help. I > didn't have that at first, I only had the server statement. When that > didn't work I added local on a whim to see what happened. The same > result with only that server line, NXDOMAIN. > > >>> server=/0.100.10.in-addr.arpa/10.0.0.140 >> >> This one should forward reverse resolutions for 10.100.0.* to the VPN >> server. I believe you have not shown results of a reverse resolution, >> be it to 10.0.0.* or 10.100.0.*. > > > Same as the others, NXDOMAIN. The router's copy of dnsmasq just doesn't > forward the queries to the VPN server. > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
