When I originally set up my Active Directory, I used an internal DNS namespace, with a .local TLD (as was the advice at the time – no longer recommended). Essentially, my external domains are managed by my hosting providers and I manage the internal namespace. Simple.

Then I set up a few Internet-facing resources at home. I decided to create a secondary forest using a subdomain of my main external DNS namespace so that:

• domain.local was the AD-integrated DNS for internal (private) resources.
• domain.tld was managed by my hosting provider for external resources.
• subdomain.domain.tld was the AD-integrated DNS for Internet-facing resources under my control.

I also added a forwarding rule on the DNS server to send requests for subdomain.domain.tld to the authoritative DNS server for the domain (under my control) but to send requests for domain.tld and all other domains to the ISP’s DNS servers.

That worked well but, because my mail server is known by two different names internally and externally (mailserver.domain.tld for external access and mailserver.subdomain.domain.tld for internal access) and these actually resolve to the same physical server, I get certificate errors when using the internal name. Furthermore, I’m unable to access the server from inside my firewall using the external name, because the mailserver.domain.tld name actually resolves to the IP address of my router, from where which IP filtering and NAT forwarding rules allow the packets to be forwarded to the mail server.

I needed mail clients to work with the same server name (mailserver.domain.tld) whether they were accessing the server on the internal or external networks, so I made some changes:

1. My hosting provider sent me a copy of the DNS zone file for mailserver.domain.tld and I imported this to my internal DNS server.
2. Next, I deleted the forwarding rule for mailserver.domain.tld (leaving the one for subdomain.domain.tld in place).
3. Then, I edited the entries for the servers that needed to be accessed with the same name internally and externally so that instead of resolving to the external IP address of my router, they resolved to the actual IP address of the server (which uses an RFC 1918 internal IP address range).
4. Finally, nslookup helped me to confirm that the addresses were resolving correctly on the internal and external networks – effectively getting one set of results in the Internet from my hosting provider and another set on the internal network from my DNS server.

The new setup looks like this (note that the IP addresses have been changed to protect the innocent):

Now I can seamlessly access my mail server using the same DNS name (mailserver.domain.tld) from wherever I roam to.