1

I have a network setup with a 2008 R2 AD domain called internal.domain.org. Our externally hosted website uses www.domain.org and domain.org. I'd like users to be able to access our RDS server--machinename.internal.domain.org--using the same domain name whether inside or outside the LAN. This would be remote.domain.org. From outside is easy enough, but on the inside I'm lost. Trying split DNS, it's easy to get remote.domain.org to the internal RDS machine, but it breaks access to the external website from inside the LAN.

The trouble seems to be that when I create a Forward Lookup Zone called domain.org, it comes up with a subfolder called internal, instead of the normal set of folders. I add records for * and www, but can't get to the outside. I'm out of my league here. Any thoughts?

Thanks,

Ron Lee
  • 43
  • 5
  • Split DNS is bad. This seems like a good idea, but it's really not. The price of this user convenience is an exponential amount of increased design complexity and man hours spent by your company. – Andrew B Mar 14 '15 at 03:33

1 Answers1

2

Use split DNS (split horizon), but not on a server running Microsoft software - it doesn't work.

On your local DNS recursor/cacher you can usually create a specific override for a FQDN to map to a different IP. This adds exactly one CI to your CMDB and isn't unusual or complex at all.

Depending on your setup, you usually do this on your network gateway system. For example on pfSense, it can be done using the GUI in Services->DNS Server at the bottom. Since you did not post what you are using, I cannot give you an example for your system.

Elaborating on my answer:

This is an exact case on why split-horizon DNS works and is needed. If you have multiple entry points to a service which require different IP's to access it, and you are using a FQDN to access it, DNS is exactly how this is solved.

Usually, there are 3 very common cases that depending on the places your staff works from come in to play:

  • Local RDS on the LAN where the RDS is actually accessible
  • RDS via WAN, which requires the WAN IP to be used (which then NATs to the LAN IP for RDS)
  • RDS via VPN, where VPN lives on its own subnet and may or may not have access to the LAN

Sometimes where are multiple VPN connections or tunnels, which can complicate things even further. In many cases this can be solved with routing and firewalling, but that creates so many more Configuration Items that your CMDB will simply be flooded with nonsense every time you need to configure a service to be reachable from multiple places.

In many setups, the zone for which the Windows server needs to be authoritative for can simply be configured on the main router, gateway or DNS server, so that you can have one high-performance single point of configuration for your entire DNS needs. The only drawback is that if zone transfers or remote DNS updates are needed to the default DNS server by clients, it will no longer work. This is, however, usually no longer the case in client-server setups.

The way split-DNS works in this case is simply this:

  • Public DNS holds the A record for WAN connections
  • Internal DNS holds an override A record for the specific FQDN (remote.example.com)

Because only two different DNS records are needed (public and LAN), this is easy and reliably configurable. There is no need for views like BIND has, or PowerDNS's views implementation, or Unbound with rewriting support. Views and Split-DNS is not implemented in Microsoft DNS, that's why that is not an option in this case. (See http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software for a comparison)

On a second note: if you have pfSense, you could simply create an L2TP over IPSec or OpenVPN tunnel so people can have remote access. While it does require installation of software on the client system, it removes the need of a WAN-accessible RDS.

John Keates
  • 681
  • 4
  • 9
  • Ah, thanks very much, John. I do use pfSense, and hadn't thought of that at all. Nice. I'll give it a shot later today. Any pfSense specifics I should be aware of? Thanks again. – Ron Lee Mar 14 '15 at 16:08
  • Yes, you should make sure the Windows server uses the pfSense box as it's DNS server too. That way, all AD and internal windows services will still use it's local DNS server for lookups, and if it can't find a matching record, it will forward the request to pfSense (either dnsmasq or unbound on 2.2) which then uses it's local cache and lookup tables. I'm editing my answer to elaborate on why and how it works. – John Keates Mar 14 '15 at 17:07
  • Great. Just to clarify, since I'd like to keep my internal Microsoft DNS intact, I can leave it as is, and create an entry on the pfSense box that will bounce remote.domain.org coming from the internal network back to rds.internal.domain.org, yes? You mention dnsmasq and unbound. I'll read up on both--any preference on your part? Thanks again. – Ron Lee Mar 14 '15 at 19:47
  • Also, the Windows server uses the pfSense box as its only DNS forwarder. Is this what you meant by "uses the pfSense box as it's DNS server too"? I'm assuming that since remote.domain.org is an external domain name, that would go to the forwarder, which is the pfSense box, correct? – Ron Lee Mar 14 '15 at 20:08
  • Ok, tried unbound, works like a champ! Thanks so much for all the info. I'll be using Microsoft Web Application Proxy + RD Gateway for outside access. Things seem to be coming together nicely. Thanks again John. – Ron Lee Mar 14 '15 at 20:34
  • Sorry I couldn't respond earlier, but you were spot-on anyway ;-) MS DNS can indeed be left intact. ClientPC->MS-DNS->Unbound is indeed an OK setup. Consider unbound's caching support for faster DNS :) Unbound vs. DNSMasq: Unbound has more features and does DNSSEC in a nice way. Setting up split-DNS works on both, but Unbound also allows you to add rewriting support in case you need to create NAT'ed responses for a separate isolated subnet that is 1:1 NAT'ed to a local subnet. For now, your split-DNS is set up just fine I take it, so your problem is solved in the least-invasive way :-) – John Keates Mar 14 '15 at 20:37
  • You could also simply have a lan vs external DNS server. Things like the View clause and rewrite DNS are relics of a day when servers were expensive. Ita interesting that the "least invasive" way was to increase your management pain for the entry, rather than reuse the existing methods and management of DNS in the environment. Expensive solutions like this should usually be avoided. – Jim B Mar 16 '15 at 21:09
  • How is this expensive, and not an internal LAN server and a WAN DNS server? He had a DNS server running, and now he still has a DNS server running, but with an additional record that is only served to LAN. Views and rewrites may be a relic, but not if you have many NAT'ed subnets with their own DNS servers (for example when managing services for other business via VPN tunnels; you need to network-NAT those because you can't have two identical subnets on one network). Rewriting responses for a NAT'ed LAN requires exactly 1 CI: simply one configuration line. It's not that unusual or complex. – John Keates Mar 16 '15 at 21:14
  • Oh, and in this case, no views or rewrites are used. Only one simple DNS record addition to his existing configuration. No additional server or complex configuration, nothing that wasn't already there. Just one additional line in an existing table. – John Keates Mar 16 '15 at 21:16