0

I'm currently having some problems delegating a subdomain, e.g. lan.example.com, to a nameserver in a private network.

My private network is split in to subnets

192.168.0.1/24 <--- 192.168.0.1
Physical LAN        172.20.20.1 ---> 172.20.20.1/24
                   OpenWRT Router    VPN

I have some services running in the physical LAN and the clients should access them with a static DNS name, no matter if the client is connected to the physical LAN or VPN. The OpenWRT Router also acts as the DNS resolver for all clients in the physical LAN and can resolve local hostnames, e.g. server.lan.example.com.

The public reachable nameserver of example.com has NS records

lan.example.com         IN NS lan-router.example.com
lan-router.example.com  IN A  192.168.0.1

In theory all DNS requests to *.lan.example.com should be delegated to my OpenWRT box, but client's connected to the VPN use a nameserver of their home network. These servers try to answer DNS requests recursively but naturally can't reach 192.168.0.1.

The request dig +trace A server.lan.example.com @8.8.8.8 works fine but the same request without +trace isn't.

Do you have any idea how to fix this without setting 192.168.0.1 as nameserver for all VPN clients? This would add a lot of latency for normal internet access on these clients.

  • Depending on the vpn type and setup, if clients get server-assigned ip addresses, you can also pass them the dns address – Dan Feb 3 '15 at 6:14
2

The problem is that you want the DNS to respond differently depending on who is asking. This is called a split-view or split-horizon configuration. Unfortunately, DNSMasq doesn't really have great support for this. I would highly recommend you uninstall dnsmasq and install bind. In bind, you can configure views and set ACLs to who can see them. Effectively, you can give 172 responses to the 172 network... and 192 responses to the 192 network.

More info can be found here for configuring split-views in bind.

  • That wouldn't solve my problem. Clients connected to the VPN can't resolve *.lan.example.com because nameservers in their home network try to answer all request recursively but can't reach 192.168.0.1. The client's should instead query the authoritative nameserver for lan.example.com directly. – xblax Feb 3 '15 at 0:30
  • Ultimately, you need some way to identify the source of the query. There is no way around this. If the router has 3 IPs (two LANs, and one WAN) and is also the DNS server on all 3 IPs... you would simply respond to all queries. The source-IP would be their private IP (or public from outside the LAN).. because the router only NATs on postrouting on the WAN interface. It wouldn't make a difference if the Query was directed to the WAN IP or a LAN IP. – TheCompWiz Feb 3 '15 at 0:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.