[Dnsmasq-discuss] Becoming authoritative DNS for additional netblock

Hi "A C",

Le Sun, 29 Nov 2015 14:08:50 -0800

Post by A C
Ok, this question is for a much older version of dnsmasq because I
haven't been able to update the router firmware to bring in a newer
version. I'm currently using version 2.35
My current internal IP space is 10.0.0.0/255.255.0.0 (A Class B subnet
of the 10.x.x.x Class A space). I have a VPN server on the network
that I use when I'm away from home. It uses the 10.100.0.0 network
space for the remote clients.
What I would like to do is configure dnsmasq on my router to answer
authoritatively for any requests about addresses in that 10.100.0.0
network even though the main network is outside that space. The VPN
clients are assigned these extra IPs statically so I would just be
adding them to the router's hosts file for dnsmasq to pick up.
According to online man pages (the router doesn't have them because of
space) there's a rev-server option which appears to be what I want
but I can't determine if rev-server is supported in 2.35 or if it's a
later addition.

As per the current manpage, the --rev-server option is just syntactic
sugar for --server. Therefore, if --rev-server does what you need, do
does --server, and IIUC, it does not work as a "reverse query router".

Amicalement,

--
Albert.

A C

2015-11-30 07:19:28 UTC

Post by Albert ARIBAUD
Hi "A C",
Le Sun, 29 Nov 2015 14:08:50 -0800

Hi Albert,

I did try server but it's not working. Attempting to resolve a hostname
in the alternate netblock tries to send upstream.

My current network has my router serving as DNS and DHCP server via
dnsmasq. The VPN server has dnsmasq running with the goal of being
authoritative for any of the VPN clients (the VPN software can write to
the hosts file on the server as clients come and go).

My router's configuration has local=/example.com/ (of course I'm using
my real domain but it's not important for this)
I added an additional line server=vpn.example.com/10.0.0.140 (my vpn
server having the address 10.0.0.140)

On the VPN server, I have local=/vpn.example.com/ and the hosts file is
populated by the server, for example:
10.100.0.10 client1.vpn.example.com

On the VPN server I can run a DNS query against localhost and dnsmasq
there returns the proper IP address. However, if I query using the
router as the DNS server, the query actually gets sent upstream to the
ISP and I eventually a failure.

I also tried server=/0.100.10.in-addr.arpa/10.0.0.140 with no luck and I
also added local=/vpn.example.com/ (so now there are two local
directives) but the end result is that the query is not forwarded over
to the VPN server, it's sent up to the ISP.

Albert ARIBAUD

2015-11-30 07:49:33 UTC

Hi again "A C",

Le Sun, 29 Nov 2015 23:19:28 -0800

Post by Albert ARIBAUD
Hi "A C",
Le Sun, 29 Nov 2015 14:08:50 -0800

Post by A C
Ok, this question is for a much older version of dnsmasq because I
haven't been able to update the router firmware to bring in a newer
version. I'm currently using version 2.35
My current internal IP space is 10.0.0.0/255.255.0.0 (A Class B
subnet of the 10.x.x.x Class A space). I have a VPN server on
the network that I use when I'm away from home. It uses the
10.100.0.0 network space for the remote clients.
What I would like to do is configure dnsmasq on my router to answer
authoritatively for any requests about addresses in that 10.100.0.0
network even though the main network is outside that space. The
VPN clients are assigned these extra IPs statically so I would
just be adding them to the router's hosts file for dnsmasq to pick
up.
According to online man pages (the router doesn't have them
because of space) there's a rev-server option which appears to be
what I want but I can't determine if rev-server is supported in
2.35 or if it's a later addition.

As per the current manpage, the --rev-server option is just
syntactic sugar for --server. Therefore, if --rev-server does what
you need, do does --server, and IIUC, it does not work as a
"reverse query router".

OK, so from the docs, any request for "*.vpn.example.com" will be
forwarded to 10.0.0.140. Is that what you want?

Post by A C
On the VPN server, I have local=/vpn.example.com/ and the hosts file
10.100.0.10 client1.vpn.example.com
On the VPN server I can run a DNS query against localhost and dnsmasq
there returns the proper IP address. However, if I query using the
router as the DNS server, the query actually gets sent upstream to the
ISP and I eventually a failure.
I also tried server=/0.100.10.in-addr.arpa/10.0.0.140 with no luck
and I also added local=/vpn.example.com/ (so now there are two local
directives) but the end result is that the query is not forwarded over
to the VPN server, it's sent up to the ISP.

What is the physical and logical topology of your network, and what are
your router's and name server's networking configurations, both in
terms of hardware interfaces and of software settings such as IP
addresses and netmasks per interface, gateway(s), and routing table(s)?

Amicalement,

--
Albert.

A C

2015-11-30 08:31:28 UTC

Post by Albert ARIBAUD
Hi again "A C",
Le Sun, 29 Nov 2015 23:19:28 -0800

Post by Albert ARIBAUD
Hi "A C",
Le Sun, 29 Nov 2015 14:08:50 -0800

Post by A C
Ok, this question is for a much older version of dnsmasq because I
haven't been able to update the router firmware to bring in a newer
version. I'm currently using version 2.35
My current internal IP space is 10.0.0.0/255.255.0.0 (A Class B
subnet of the 10.x.x.x Class A space). I have a VPN server on
the network that I use when I'm away from home. It uses the
10.100.0.0 network space for the remote clients.
What I would like to do is configure dnsmasq on my router to answer
authoritatively for any requests about addresses in that 10.100.0.0
network even though the main network is outside that space. The
VPN clients are assigned these extra IPs statically so I would
just be adding them to the router's hosts file for dnsmasq to pick
up.
According to online man pages (the router doesn't have them
because of space) there's a rev-server option which appears to be
what I want but I can't determine if rev-server is supported in
2.35 or if it's a later addition.

As per the current manpage, the --rev-server option is just
syntactic sugar for --server. Therefore, if --rev-server does what
you need, do does --server, and IIUC, it does not work as a
"reverse query router".

OK, so from the docs, any request for "*.vpn.example.com" will be
forwarded to 10.0.0.140. Is that what you want?

Yes, that's exactly correct. I want to address the vpn clients as
<client>.vpn.example.com and I want the vpn server to be the DNS server
for that subdomain. The main dnsmasq in the router should simply defer
to the vpn server.

The entire private network is 10.0.0.0/16 and all machines are attached
to the single NAT router. Everything going on is internal only, none of
this traffic should exit the private network.

The main router is 10.0.0.1, the VPN server is 10.0.0.140, all normal
clients on the network are 10.0.0.0/16.
VPN clients coming in from the outside receive 10.100.0.0/24 so that it
falls outside of the internal network (otherwise routing breaks).

There's only one internal interface on the router, eth1, and it's the
only interface that dnsmasq is listening (conf file says interface=eth1)
with the same /16 netmask. The external interface is eth0.

The VPN server has only one interface on the network, it's eth0 also
with /16. The clients come in via tunnels so they show up on the VPN
server as tun[] devices and the VPN server takes care to route onto the
main network.

The router has four defined routes. Two of the routes are for the
outbound external interface and all public IPs. The other two routes
are for the internal network and the VPN client network. Those are
defined as:

net 10.100.0.0 gw 10.0.0.140 mask 255.255.255.0 if eth1 (remapping
gateway to the vpn server for the VPN block)
net 10.0.0.0 gw * mask 255.255.0.0 if eth1 (default route)

The VPN server also has four routes, two are for its eth0 to the rest of
the network and the other two are the tun[] interfaces which are only
visible to connected clients. The two eth0 routes are the default route
and the local network:

net 0.0.0.0 gw 10.0.0.1 mask 0.0.0.0 eth0
net 10.0.0.0 gw * mask 255.255.0.0 eth0

Every client on the internal network has DNS defined to be the router.
None of them are aware of any external DNS (every resolv.conf or
equivalent is set to 10.0.0.1). The VPN clients have the same
configuration pushed to them on connect. The only device on the network
aware of additional DNS servers is the router. Its resolv.conf points
to the ISP DNS servers. The IP address is static so the entire
configuration is static including the DNS servers (no live rewriting of
resolv.conf).

All traffic and DNS lookups work for the main network hosts
(*.example.com) even from the VPN clients. I can be on a VPN client and
ask for the IP of device.example.com and get an answer that is in the
10.0.0.0/16 block as expected. Reverse communication (i.e. ping) is
possible to the VPN client IP addresses so now it's just a matter of
getting DNS working. I can manually query the VPN's dnsmasq using dig
or nslookup for a *.vpn.example.com address from any other network
machine and get a proper answer. But if query the router's dnsmasq, I
get NXDOMAIN.

I am also watching the VPN server's input for DNS packets. When I query
the router's dnsmasq, the VPN server is never sent a DNS query packet so
the router's dnsmasq is not forwarding the request over to the VPN
server. I can see the packet when I query direct just not when I try to
go through the router's dnsmasq.

Albert ARIBAUD

2015-11-30 13:02:59 UTC

Hello again "A C",

Le Mon, 30 Nov 2015 00:31:28 -0800

Post by Albert ARIBAUD
Hi again "A C",
Le Sun, 29 Nov 2015 23:19:28 -0800

Post by Albert ARIBAUD
Hi "A C",
Le Sun, 29 Nov 2015 14:08:50 -0800

Post by A C
Ok, this question is for a much older version of dnsmasq because
I haven't been able to update the router firmware to bring in a
newer version. I'm currently using version 2.35
My current internal IP space is 10.0.0.0/255.255.0.0 (A Class B
subnet of the 10.x.x.x Class A space). I have a VPN server on
the network that I use when I'm away from home. It uses the
10.100.0.0 network space for the remote clients.
What I would like to do is configure dnsmasq on my router to
answer authoritatively for any requests about addresses in that
10.100.0.0 network even though the main network is outside that
space. The VPN clients are assigned these extra IPs statically
so I would just be adding them to the router's hosts file for
dnsmasq to pick up.
According to online man pages (the router doesn't have them
because of space) there's a rev-server option which appears to be
what I want but I can't determine if rev-server is supported in
2.35 or if it's a later addition.

As per the current manpage, the --rev-server option is just
syntactic sugar for --server. Therefore, if --rev-server does what
you need, do does --server, and IIUC, it does not work as a
"reverse query router".

OK, so from the docs, any request for "*.vpn.example.com" will be
forwarded to 10.0.0.140. Is that what you want?

Yes, that's exactly correct. I want to address the vpn clients as
<client>.vpn.example.com and I want the vpn server to be the DNS
server for that subdomain. The main dnsmasq in the router should
simply defer to the vpn server.

Post by A C
On the VPN server, I have local=/vpn.example.com/ and the hosts
10.100.0.10 client1.vpn.example.com
On the VPN server I can run a DNS query against localhost and
dnsmasq there returns the proper IP address. However, if I query
using the router as the DNS server, the query actually gets sent
upstream to the ISP and I eventually a failure.
I also tried server=/0.100.10.in-addr.arpa/10.0.0.140 with no luck
and I also added local=/vpn.example.com/ (so now there are two
local directives) but the end result is that the query is not
forwarded over to the VPN server, it's sent up to the ISP.

What is the physical and logical topology of your network, and what
are your router's and name server's networking configurations, both
in terms of hardware interfaces and of software settings such as IP
addresses and netmasks per interface, gateway(s), and routing table(s)?

That depends on how you set it up, actually, and probably on the size
of the network, but for my (admittedly small) network, VPN connections
are handled by a bridging OpenVPN instance on a TAP device bridged with
a physical interface. Local and VPN clients thus have use the same DHCP
server and therefore coexist in the same subnet, and have access to the
same servers, including the DNS server.

Now, a separated subnet for VPN client works too, as long as the VPN
server does the natting for them -- again, OpenVPN does that normally,
so that no packet on 10.0.*.* should have a source or destination IP of
10.100.*.*.

Post by A C
There's only one internal interface on the router, eth1, and it's the
only interface that dnsmasq is listening (conf file says
interface=eth1) with the same /16 netmask. The external interface is
eth0.

Does that mean there is also an eth0 interface on the router?

Post by A C
The VPN server has only one interface on the network, it's eth0 also
with /16. The clients come in via tunnels so they show up on the VPN
server as tun[] devices and the VPN server takes care to route onto
the main network.
The router has four defined routes. Two of the routes are for the
outbound external interface and all public IPs. The other two routes
are for the internal network and the VPN client network. Those are
net 10.100.0.0 gw 10.0.0.140 mask 255.255.255.0 if eth1 (remapping
gateway to the vpn server for the VPN block)
net 10.0.0.0 gw * mask 255.255.0.0 if eth1 (default route)
The VPN server also has four routes, two are for its eth0 to the rest
of the network and the other two are the tun[] interfaces which are
only visible to connected clients. The two eth0 routes are the
net 0.0.0.0 gw 10.0.0.1 mask 0.0.0.0 eth0
net 10.0.0.0 gw * mask 255.255.0.0 eth0
Every client on the internal network has DNS defined to be the
router. None of them are aware of any external DNS (every resolv.conf
or equivalent is set to 10.0.0.1). The VPN clients have the same
configuration pushed to them on connect. The only device on the
network aware of additional DNS servers is the router. Its
resolv.conf points to the ISP DNS servers. The IP address is static
so the entire configuration is static including the DNS servers (no
live rewriting of resolv.conf).
All traffic and DNS lookups work for the main network hosts
(*.example.com) even from the VPN clients. I can be on a VPN client
and ask for the IP of device.example.com and get an answer that is in
the 10.0.0.0/16 block as expected. Reverse communication (i.e. ping)
is possible to the VPN client IP addresses so now it's just a matter
of getting DNS working. I can manually query the VPN's dnsmasq using
dig or nslookup for a *.vpn.example.com address from any other network
machine and get a proper answer. But if query the router's dnsmasq, I
get NXDOMAIN.
I am also watching the VPN server's input for DNS packets. When I
query the router's dnsmasq, the VPN server is never sent a DNS query
packet so the router's dnsmasq is not forwarding the request over to
the VPN server. I can see the packet when I query direct just not
when I try to go through the router's dnsmasq.

Can you watch the router's DNS traffic rather than the VPN server's?
Possibly give a tcpdump of a successful and a failed DNS request? I
assume you cannot change how dnsmasq runs on the router but if you can,
then try having it log the successful and failed DNS requests too.
This log might show whether a request is forwarded or cached, for
instance.

Amicalement,

--
Albert.

A C

2015-11-30 14:43:32 UTC

Post by Albert ARIBAUD
Hello again "A C",
Le Mon, 30 Nov 2015 00:31:28 -0800

Post by Albert ARIBAUD
Hi again "A C",
Le Sun, 29 Nov 2015 23:19:28 -0800

Post by Albert ARIBAUD
Hi "A C",
Le Sun, 29 Nov 2015 14:08:50 -0800

Post by A C
Ok, this question is for a much older version of dnsmasq because
I haven't been able to update the router firmware to bring in a
newer version. I'm currently using version 2.35
My current internal IP space is 10.0.0.0/255.255.0.0 (A Class B
subnet of the 10.x.x.x Class A space). I have a VPN server on
the network that I use when I'm away from home. It uses the
10.100.0.0 network space for the remote clients.
What I would like to do is configure dnsmasq on my router to
answer authoritatively for any requests about addresses in that
10.100.0.0 network even though the main network is outside that
space. The VPN clients are assigned these extra IPs statically
so I would just be adding them to the router's hosts file for
dnsmasq to pick up.
According to online man pages (the router doesn't have them
because of space) there's a rev-server option which appears to be
what I want but I can't determine if rev-server is supported in
2.35 or if it's a later addition.

As per the current manpage, the --rev-server option is just
syntactic sugar for --server. Therefore, if --rev-server does what
you need, do does --server, and IIUC, it does not work as a
"reverse query router".

OK, so from the docs, any request for "*.vpn.example.com" will be
forwarded to 10.0.0.140. Is that what you want?

Yes, that's exactly correct. I want to address the vpn clients as
<client>.vpn.example.com and I want the vpn server to be the DNS
server for that subdomain. The main dnsmasq in the router should
simply defer to the vpn server.

What is the physical and logical topology of your network, and what
are your router's and name server's networking configurations, both
in terms of hardware interfaces and of software settings such as IP
addresses and netmasks per interface, gateway(s), and routing table(s)?

That depends on how you set it up, actually, and probably on the size
of the network, but for my (admittedly small) network, VPN connections
are handled by a bridging OpenVPN instance on a TAP device bridged with
a physical interface. Local and VPN clients thus have use the same DHCP
server and therefore coexist in the same subnet, and have access to the
same servers, including the DNS server.
Now, a separated subnet for VPN client works too, as long as the VPN
server does the natting for them -- again, OpenVPN does that normally,
so that no packet on 10.0.*.* should have a source or destination IP of
10.100.*.*.

Does that mean there is also an eth0 interface on the router?

I can't do a dump of traffic on the router but I think I should be able
to get logging working. However, watching the traffic on the VPN I'm
confident the request is not being forwarded to the VPN server. I
presume the log-queries directive will be sufficient for this. I will
try it this evening.

A C

2015-12-01 05:34:58 UTC

Post by Albert ARIBAUD
Can you watch the router's DNS traffic rather than the VPN server's?
Possibly give a tcpdump of a successful and a failed DNS request? I
assume you cannot change how dnsmasq runs on the router but if you can,
then try having it log the successful and failed DNS requests too.
This log might show whether a request is forwarded or cached, for
instance.

Ok. I ran with query logging turned on and queried for a device already
on the main 10.0.0.0/16 network from another machine and one of the VPN
clients that the VPN server should know and answer from the same machine
(the machine being 10.0.0.2).

The working query:
dnsmasq: query[A] device.example.com from 10.0.0.2
dnsmasq: /etc/hosts device.example.com is 10.0.0.180

The query that should be forwarded to the VPN server's instance of
dnsmasq responds like this:
dnsmasq: query[A] client1.vpn.example.com from 10.0.0.2
dnsmasq: config client1.vpn.example.com is <NXDOMAIN>-IPv4

Albert ARIBAUD

2015-12-01 15:46:50 UTC

Hi "A C",

Le Mon, 30 Nov 2015 21:34:58 -0800

Post by Albert ARIBAUD
Can you watch the router's DNS traffic rather than the VPN server's?
Possibly give a tcpdump of a successful and a failed DNS request? I
assume you cannot change how dnsmasq runs on the router but if you
can, then try having it log the successful and failed DNS requests
too. This log might show whether a request is forwarded or cached,
for instance.

Ok. I ran with query logging turned on and queried for a device
already on the main 10.0.0.0/16 network from another machine and one
of the VPN clients that the VPN server should know and answer from
the same machine (the machine being 10.0.0.2).
dnsmasq: query[A] device.example.com from 10.0.0.2
dnsmasq: /etc/hosts device.example.com is 10.0.0.180
The query that should be forwarded to the VPN server's instance of
dnsmasq: query[A] client1.vpn.example.com from 10.0.0.2
dnsmasq: config client1.vpn.example.com is <NXDOMAIN>-IPv4

Can you copy-paste, with as little modifications as possible, the
complete dnsmasq configuration of the router?

Amicalement,

--
Albert.

A C

2015-12-01 17:59:07 UTC

Post by Albert ARIBAUD
Hi "A C",
Le Mon, 30 Nov 2015 21:34:58 -0800

Post by Albert ARIBAUD
Can you watch the router's DNS traffic rather than the VPN server's?
Possibly give a tcpdump of a successful and a failed DNS request? I
assume you cannot change how dnsmasq runs on the router but if you
can, then try having it log the successful and failed DNS requests
too. This log might show whether a request is forwarded or cached,
for instance.

Ok. I ran with query logging turned on and queried for a device
already on the main 10.0.0.0/16 network from another machine and one
of the VPN clients that the VPN server should know and answer from
the same machine (the machine being 10.0.0.2).
dnsmasq: query[A] device.example.com from 10.0.0.2
dnsmasq: /etc/hosts device.example.com is 10.0.0.180
The query that should be forwarded to the VPN server's instance of
dnsmasq: query[A] client1.vpn.example.com from 10.0.0.2
dnsmasq: config client1.vpn.example.com is <NXDOMAIN>-IPv4

Can you copy-paste, with as little modifications as possible, the
complete dnsmasq configuration of the router?

This is it in the most recent version including some of my edits related
to this testing. Until this new DNS work I had only one local statement
and no server statements.

interface=eth0
domain-needed
bogus-priv
filterwin2k
localise-queries
local=/example.com/
local=/vpn.example.com/
domain=example.com
expand-hosts
server=/vpn.example.com/10.0.0.140
server=/0.100.10.in-addr.arpa/10.0.0.140
dhcp-authoritative
dhcp-range=10.0.10.100,10.0.10.105,255.255.0.0,24h
dhcp-leasefile=/tmp/dhcp.leases

read-ethers
dhcp-option=3,10.0.0.1
dhcp-option=6,10.0.0.1
dhcp-option=42,10.0.0.141

Albert ARIBAUD

2015-12-01 21:22:07 UTC

Hi "A C",

Le Tue, 1 Dec 2015 09:59:07 -0800
A C <***@hotmail.com> a écrit:

(note : local= is synonymous to server=)

Post by A C
local=/example.com/

This one means *example.com should be resolved by reading /etc/hosts
or the DHCP lease info.

Post by A C
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.

Post by A C
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.*.

Amicalement,

--
Albert.

A C

2015-12-01 23:40:01 UTC

Post by Albert ARIBAUD
Hi "A C",
Le Tue, 1 Dec 2015 09:59:07 -0800
(note : local= is synonymous to server=)

Post by A C
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.

Post by A C
local=/vpn.example.com/
server=/vpn.example.com/10.0.0.140

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.

Post by A C
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.

A C

2015-12-02 03:53:37 UTC

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.

Post by Albert ARIBAUD
Hi "A C",
Le Tue, 1 Dec 2015 09:59:07 -0800
(note : local= is synonymous to server=)

Post by A C
local=/example.com/

This one means *example.com should be resolved by reading /etc/hosts
or the DHCP lease info.

Post by A C
local=/vpn.example.com/
server=/vpn.example.com/10.0.0.140

Post by A C
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
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Albert ARIBAUD

2015-12-02 06:22:04 UTC

Hi "A C",

Cc:ing Simon in case the problem is indeed a weird dependency of
"server=" on "local=" -- or to ascertain it doesn't.

Le Tue, 1 Dec 2015 19:53:37 -0800

Post by A C
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
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.

I am not sure that two lines are needed for one subdomain -- the
documentation imples that "server=" does not need a "companion" line
with "local=", and logically, no local= line should be needed for a
server= line to work.

Did you try just removing the "local=/vpn..." line from the (now)
working config?

If it still works with just the "server=" line, then your problem was
elsewhere and some other change of yours has fixed it.

If it needs the "local=" line along with the "server=" line to work,
then there is a weird problem indeed, which IMO justifies my cc:ing
Simon.

Post by A C
Thanks for the help, that was a bit of a mystery.

Happy that it works now; I'll be happier when we know why it did not.

Amicalement,

--
Albert.

A C

2015-12-02 06:46:40 UTC

Post by Albert ARIBAUD
Hi "A C",
Cc:ing Simon in case the problem is indeed a weird dependency of
"server=" on "local=" -- or to ascertain it doesn't.
Le Tue, 1 Dec 2015 19:53:37 -0800

I am not sure that two lines are needed for one subdomain -- the
documentation imples that "server=" does not need a "companion" line
with "local=", and logically, no local= line should be needed for a
server= line to work.
Did you try just removing the "local=/vpn..." line from the (now)
working config?
If it still works with just the "server=" line, then your problem was
elsewhere and some other change of yours has fixed it.
If it needs the "local=" line along with the "server=" line to work,
then there is a weird problem indeed, which IMO justifies my cc:ing
Simon.

The local=/vpn.../ line is already gone, only my base domain is local.

Without the server=/vpn.../ line, it does not work (local with no server
was my very original configuration). With the server line after local
it does not work either. But with server first and local last it works
fine.

My whole (working) configuration:

interface=br0
domain-needed
bogus-priv
filterwin2k
localise-queries
domain=example.com
expand-hosts
server=/vpn.example.com/10.0.0.140
server=/0.100.10.in-addr.arpa/10.0.0.140
local=/example.com/
dhcp-authoritative
dhcp-range=10.0.10.100,10.0.10.105,255.255.0.0,24h
dhcp-leasefile=/tmp/dhcp.leases
read-ethers
dhcp-option=3,10.0.0.1
dhcp-option=6,10.0.0.1
dhcp-option=42,10.0.0.141

My original configuration was exactly the same above except the server
lines were not present (commented copies from older configurations were
present). When I added them they were all located below
local=/example.com/ (that's where the commented copies were located).
Once I moved local=/example.com/ below server=//, it worked. I tested
again by swapping the lines in the above configuration, with local first
the whole thing fails but with local last it works.

Albert ARIBAUD

2015-12-02 07:43:05 UTC

Hi "A C",

Le Tue, 1 Dec 2015 22:46:40 -0800

Post by Albert ARIBAUD
Hi "A C",
Cc:ing Simon in case the problem is indeed a weird dependency of
"server=" on "local=" -- or to ascertain it doesn't.
Le Tue, 1 Dec 2015 19:53:37 -0800

Post by A C
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

------------------------------------------------------

Post by A C
server=/vpn.example.com/10.0.0.140
local=/vpn.example.com/

------------------------------------------------------

Post by A C
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.

I am not sure that two lines are needed for one subdomain -- the
documentation imples that "server=" does not need a "companion" line
with "local=", and logically, no local= line should be needed for a
server= line to work.
Did you try just removing the "local=/vpn..." line from the (now)
working config?
If it still works with just the "server=" line, then your problem
was elsewhere and some other change of yours has fixed it.
If it needs the "local=" line along with the "server=" line to work,
then there is a weird problem indeed, which IMO justifies my cc:ing
Simon.

The local=/vpn.../ line is already gone, only my base domain is local.

This does not match the extract you gave above (which I marked with
lines in this reply) where you have two lines where the domain part of
the local= directive starts with "vpn."

I infer that what you have in your working config is not

server=/vpn.example.com/10.0.0.140
local=/vpn.example.com/

as indicated above, but actually

server=/vpn.example.com/10.0.0.140
local=/example.com/

and what you witness is that it works in this order, but will not work
in that order:

local=/example.com/
server=/vpn.example.com/10.0.0.140

Am I correct?

Amicalement,

--
Albert.

A C

2015-12-02 08:00:06 UTC

Post by Albert ARIBAUD
Hi "A C",
Le Tue, 1 Dec 2015 22:46:40 -0800

Post by Albert ARIBAUD
Hi "A C",
Cc:ing Simon in case the problem is indeed a weird dependency of
"server=" on "local=" -- or to ascertain it doesn't.
Le Tue, 1 Dec 2015 19:53:37 -0800

Post by A C
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

------------------------------------------------------

Post by A C
server=/vpn.example.com/10.0.0.140
local=/vpn.example.com/

------------------------------------------------------

I am not sure that two lines are needed for one subdomain -- the
documentation imples that "server=" does not need a "companion" line
with "local=", and logically, no local= line should be needed for a
server= line to work.
Did you try just removing the "local=/vpn..." line from the (now)
working config?
If it still works with just the "server=" line, then your problem
was elsewhere and some other change of yours has fixed it.
If it needs the "local=" line along with the "server=" line to work,
then there is a weird problem indeed, which IMO justifies my cc:ing
Simon.

The local=/vpn.../ line is already gone, only my base domain is local.

This does not match the extract you gave above (which I marked with
lines in this reply) where you have two lines where the domain part of
the local= directive starts with "vpn."
I infer that what you have in your working config is not
server=/vpn.example.com/10.0.0.140
local=/vpn.example.com/
as indicated above, but actually
server=/vpn.example.com/10.0.0.140
local=/example.com/
and what you witness is that it works in this order, but will not work
local=/example.com/
server=/vpn.example.com/10.0.0.140
Am I correct?

Yes, that was a typo on my part. The actual config file has
local=/example.com/ I just typed the vpn into the email by accident.
The config file has no other local directives.

Also, your final observation is correct. If local appears before
server, the queries to the subdomain fail. If local appears after
server it works. Just for fun I tried out a couple extra server lines
that point to entirely different domains outside of mine (e.g.
server=/example.org/1.2.3.4 where local=/example.com/). In that case
the position of server and local doesn't matter the query is forwarded
as I remembered from previous usage. So there appears to be an
interaction between local and server when both contain the same domain
and the order must be from most specific to least specific.

Albert ARIBAUD

2015-12-02 08:50:17 UTC

Hi "A C",

Le Wed, 2 Dec 2015 00:00:06 -0800

Post by Albert ARIBAUD
I infer that what you have in your working config is not
server=/vpn.example.com/10.0.0.140
local=/vpn.example.com/
as indicated above, but actually
server=/vpn.example.com/10.0.0.140
local=/example.com/
and what you witness is that it works in this order, but will not
local=/example.com/
server=/vpn.example.com/10.0.0.140
Am I correct?

Yes, that was a typo on my part. The actual config file has
local=/example.com/ I just typed the vpn into the email by accident.
The config file has no other local directives.
Also, your final observation is correct. If local appears before
server, the queries to the subdomain fail. If local appears after
server it works. Just for fun I tried out a couple extra server lines
that point to entirely different domains outside of mine (e.g.
server=/example.org/1.2.3.4 where local=/example.com/). In that case
the position of server and local doesn't matter the query is forwarded
as I remembered from previous usage. So there appears to be an
interaction between local and server when both contain the same domain
and the order must be from most specific to least specific.

Hmm. Option --local is supposed to be syntactic sugar for "--server
without a server IP" (or maybe even just a synonym if the manpage is
literal about it), and --server is supposed to be order-insensitive,
so it /looks/ like the dnsmasq documentation and actual behaviour differ
here.

I guess at this point, Simon (now To:) is the one to confirm the issue
and analysis.

Amicalement,

--
Albert.

A C

2015-12-02 14:11:38 UTC

Post by Albert ARIBAUD
Hi "A C",
Le Wed, 2 Dec 2015 00:00:06 -0800