Nat – External Requests to Internal DNS Server

domain-name-systemnat;reverse-proxy

What would be the best way to configure my internal NAT network to handle external DNS requests? i.e.:

  • Domain 'example.com' is pointed to my public IP address on the WAN port of the router.
  • Internal network has DNS server at 'ns1.example.com'.
  • Client from external network wants to connect to 'web-server.example.com'.
  • Client from external network wants to connect to 'confluence.example.com'.
  • 'ns1.example.com' resolves both clients and users can connect to them.

I don't want to simply just port forward a bunch of things and configure a bunch of port redirects for all my SSH, RDP, and web servers. I'd like to have sub-domains available through NAT. Would this be configured on the router for all queries to be redirected to ns1.example.com? Would a reverse-proxy be the way to go? The simpler the better.

Best Answer

Given that all the services you want to run are HTTP/HTTPS you will need a DNS service and a reverse proxy.

Authoritative DNS Service

You will need at least two DNS servers that hosts your zone. One of them can run behind your NAT, the other one can't. The best setup in this case is probably the master zone behind your NAT, accessible through port-forwarding from the outside and a slave zone somewhere in the internet.

Once you've got that setup you can then make the registry point to your nameservers for your domain and add records for your services pointing at your NAT ip.

Alternative: Just configure the dns-zone in your provider's web-interface or whatever.

Reverse Proxy

Install a reverse-proxy (Apache, nginx, varnish, whatever) that will handle the HTTP/HTTPS traffic for all your services. Set up a NAT port-forwarding for 80/tcp and 443/tcp that points to that proxy.

Theory of operation

When a clients wants to connect to yourservice.example.com it will resolve DNS for that name and get your NAT ip address. The client will then connect to the NAT address on 80/tcp or 443/tcp and will be port-forwarded to your proxy.

The client now either sends a HTTP request with a Host-Header or initiates a SSL-handshake with SNI. In both cases the reverse-proxy will be able to see that the request was for yourservice.example.com and can then forward the request to the correct application server.