How can I get DNS IP Resolution for an Internet Domain Name pointing to a locally-hosted Web Server from within a LAN (across multiple subnets)?

Question

Cut to the chase:

A specific question of mine is this: a client on 10.0.3.X/24 network cannot reach subdomain.site.com. How can I make clients on 10.0.2.X/24 and 10.0.3.X/24 able to resolve 10.0.1.4 when calling subdomain.site.com?

---

I'd like to get my DNS resolution working for my web server LAN using the WAN-side domain name e.g. subdomain.site.com such that n clients on any of the LAN sub networks can just type subdomain.site.com or site.com and be routed appropriately (scalable, so /etc/hosts is out of the question).

My LAN has multiple subnets created with LEDE (network .1) and OpenWRT (network .2 and network .3):

10.0.1.X/24 Main puppy with WAN interface facing internet and NAT, web server fixed at 10.0.1.4 with ports forwarded
10.0.2.X/24 Auxiliary router with WAN interface facing 10.0.1.X/24 (routed)
10.0.3.X/24 Auxiliary router with WAN interface facing 10.0.1.X/24 (routed)

I do not want any hairpin NAT/loopback NAT solutions. I'd prefer a solution using DNS and here is why:

1. An outgoing call from a client calls authoritative DNS to find the IP (for routing!), then sends a packet to that destination,
2. which upon arriving, gets DNATed to the server.
3. The source IP is the client's local address, so the server calls the client directly (using the packet's source IP).
4. Client rejects this package because it expects it to come from the gateway, indirectly from the gateway's ext. addr. provided by DNS above.
5. A NAT loopback solves the issue by translating the outbound source IP to the gateway's LAN-side addr. such that the
6. Server then responds to the gateway, rather than directly to the client. Cool beans.

The problem with this data flow is that it is not efficient to leave the LAN and contact a global DNS server for an IP addr. when the server is a local peer (on the same side of NAT and in my case not necessarily within the same local subnet). Why even leave LAN when the client and server are local peers? A nice explanation of a loopback NAT flow can be found here, https://unix.stackexchange.com/a/282094/33386.

I know it is possible to achieve what I want using DNS split-horizons or whatever hip term some people are calling it these days. Also a local naming server that takes precedence over the global naming servers in certain instances would solve this. How can I implement this in OpenWRT or LEDE when using multiple subnets (multiple DHCP+DNS servers)? Somebody has to have done this already.

Currently, clients on 10.0.1.X/24 can reach subdomain.site.com with a corresponding dnsmasq setting /etc/config/dhcp but I have no clue why, because I thought this does not cover subdomains:

config domain
        option name 'site.com'
        option ip '10.0.1.4' # LAN address of web server

Answer 1

1st Missing Element

I had to add two things to my dnsmasq configuration on the aux routers in the file /etc/config/dhcp:

    list server '10.0.1.1'# Clients will still get 10.0.3.1 as dns server
    list rebind_domain 'subdomain.site.com' # Allow rebind to web server

The list server makes dnsmasq forward dns queries to the server at 10.0.1.1 (the main router dnsmasq server). The list rebind_domain allows rebinding for specific sites such that dns rebinding protection can be left on. Thank you "jow" here. Another option is to completely disabled dns rebinding protection. Alternatively, it might be possible to use option rebind_localhost 1, but I did not test this. Without this step, I could not ping subdomain.site.com.

2nd Missing Element

Add the following entry to /etc/dnsmasq.conf on the main router.

address=/.site.com/10.0.1.4

Note the placeholder . for any subdomains. This change might also be possible in /etc/config/dhcp, but I am not sure how.

Original 2nd Missing Element (limited)

This was my original solution, which I have since abandoned. I added an entry (10.0.1.4 subdomain.site.com) into the /etc/hosts file of the main router, which has the limitation that there are no placeholders for subdomains or extended URLs like when using webdav.

127.0.0.1 localhost

::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.0.1.4 subdomain.site.com

Test this by adding logqueries 1 to /etc/config/dhcp to log all DNS queries. Something like the following will be shown, which indicates that /etc/hosts was the source:

Fri Jan  5 14:11:20 2018 daemon.info dnsmasq[7368]: 73 10.0.3.149/64299 /etc/hosts subdomain.site.com is 10.0.1.4

What did not work

It surprised me that the following /etc/config/dhcp configuration on the main router only worked within the 10.0.1.X/24 subnet:

config domain
        option name 'site.com'
        option ip '10.0.1.4'

config domain
        option name 'subdomain.site.com'
        option ip '10.0.1.4'

If anybody can shed light on this, I'd love to know why! Perhaps a problem?

It would seem that adding option dns 10.0.1.1 to /etc/config/network on aux routers did not really help my situation either.

config interface 'lan'
        option ifname  'eth0.1'
        option force_link '1'
        option type    'bridge'
        option proto   'static'
        option ipaddr  '10.0.2.1'
        option netmask '255.255.255.0'
        option dns     '10.0.1.1'

config interface 'wan'
        option ifname 'eth0.2' # Comment this out if connecting as sta using wlan
        option proto   'dhcp'
        option netmask '255.255.255.0'
        option gateway '10.0.1.1'
        option dns     '10.0.1.1'

Adding this option makes an entry show up in cat /tmp/resolv.conf.auto. However, list server 10.0.1.1, as explained above, adds nameserver 10.0.1.1 for the WAN interface.

Adding dhcp_options to /etc/config/dhcp on aux routers did not help.

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '72h'
        option ra 'server'
        #list 'dhcp_option' '3,10.0.1.1' # SET DEFAULT GATEWAY, CAUTION CAN BREAK STUFF
        #list 'dhcp_option' '6,10.0.1.1' # SEND DNS SERVER ADDR TO CLIENTS, CAUTION CAN BREAK STUFF

Answer 2

You need either split horizon or a local nameserver.

Point the clients behind 10.0/16 at a local nameserver that is authoritative for the subdomain.example.com zone, and recurses otherwise. This is possible with a standalone nameserver or with split horizon.

Both examples below contain the minimum to perform their tasks. Security concerns and other configuration details are outside the scope of this question.

I strongly recommend reading the DNS HOWTO and DNS and BIND, in that order.

---

Split Horizon

view "internal" {
  match-clients { // Add any other "on-net" blocks here.
    localnets;
    127.0.0.1;
  };
  recursion yes;

  zone "example.com" in {
    type master;
    file "internal/example.com"; // Contains RFC1918 addresses for on-net hosts
  };

  zone "." in {
    type hint;
    file "root.cache";
  };
};

view "external" {
  recursion no;
  zone "example.com" in {
    type master;
    file "external/example.com"; // Contains public IPs for hosts
  };
};

---

Standalone Nameserver

This is a normal BIND instance, but configured to be authoritative for the internal zone.

options {
  recursion yes;
  // and any other options you want
};

zone "example.com" in {
  type master;
  file "example.com"; // Contains the RFC1918 addresses.
};

zone "." in {
  type hint;
  file "root.cache";
};