1

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
  • 2
    Do you have any specific doubts? This question is bordering off-topic. See BIND and DNS views, or see defining multiple domains with several DNS servers, one for the Internet, and other for the internal network. – Rui F Ribeiro Jan 4 '18 at 18:54
  • @RuiFRibeiro I am looking for help in the implementation. I will add a specific doubt to the question content. Do you have any suggests to make this question not border "off-topic". – Jonathan Komar Jan 4 '18 at 18:55
  • 1
    I am afraid writing and detailing good questions is OPs work, I am afraid. I am not moderating it as off-topic though, I understand we have people with different levels of experience here. You have got to configure via DHCP one DNS server for all your PCs, I think it is one of your problems. – Rui F Ribeiro Jan 4 '18 at 19:35
  • DNS is just a directory service; it turns names into IP addresses (in this use case — it does a bunch of other lookup types too). It basically has nothing to do with IP routing. It seems like you could solve this by just adding webserver.subdomain.site.com IN A 10.0.1.4 to public DNS. Or by running your own DNS server internally, if the IPs must stay secret. Not really seeing the connection to Unix/Linux, though... – derobert Jan 4 '18 at 20:21
  • @derobert Thanks for your input. Just for info: connection to Unix/Linux is OpenWRT, LEDE, and dnsmasq. As you can see, there are even subject tags for them. Try asking a question about home networks on ServerFault and you'll almost get murdered. Still, maybe you're right and this question would fit into a different community better. – Jonathan Komar Jan 4 '18 at 20:52
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
1

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";
};

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.