0

On the topic of AD naming best practices, I very carefully read this Q/A on serverfault.com, this Samba FAQ and various Microsoft's documents. I 100% agree with the general recommendation: use a suitable subdomain of your main domain (ie: ad.example.com) as your AD name.

However, when using such a setup, I wonder how to correctly manage mobile hosts (for example, laptop and smartphones) which can be both on the internal network and on a remote connection.

For a practical example, let's think about a simple mail client setup with an internal mail server. With a dedicated third-level domain (ad.example.com), I have two options:

  • setup the internal mail clients with mail.ad.example.com: while working very well inside the network, it fails apart when the client is on a remote connection. Asking the user to change its mail configuration is absolutely impractical, so let's discard this option entirely;
  • setup the internal mail clients with the external domain name, so mail.example.com: this should work fine for both internal and extenal client but internal traffic flow is sub-optimal, as clients resolve the internal mailserver address with a public IP address and so traffic bounce back and forth on the edge firewall. This cause an increased load on the appliance and it is even worse for UTM firewalls, which deeply inspect (a to-really-be-internal-only) traffic.

How do you cope with the above situation? Do you simply accept and increased load on the edge firewall?

I know this issues can be completely avoided with a split-DNS naming scheme (ie: example.com on both external and internal DNS); however, this naming scheme has its own drawback and it is (rightfully) not generally recommended.

shodanshok
  • 44,038
  • 6
  • 98
  • 162
  • 1
    If you're running Exchange Server and Outlook then this is taken care of for you. The Autodiscover mechanism will connect the Outlook clients correctly whether internally (via the SCP) or externally. The best practice of using an unused sub-domain of your public domain for AD stands. – joeqwerty Nov 14 '17 at 03:06
  • True, but I was talking about a situation where no autodiscovery is available (ie: a standalone IMAP or web server) – shodanshok Nov 14 '17 at 06:32

1 Answers1

0

Use mail.example.com for both internal and external mail clients. The records on your internal DNS servers should point clients to the internal mail server addresses. Clients outside your network would get routed to the external mail server addresses.

twconnell
  • 764
  • 4
  • 12
  • MX records designate which mail server(s) receive(s) email for a given domain. MX records don't designate which mail server hosts a given user's mailbox. Internal MX records are largely unnecessary except in very specific use cases, none of which relate to email client mailboxes. – joeqwerty Nov 14 '17 at 03:08
  • Of course the configuration of the mail server infrastructure is more involved, but I didn't think that was the question being asked. I wanted to provide an example of how to overcome the network challenges using DNS. Apologies if I misunderstood the question. Out of curiosity, if you host Exchange on the same network as your clients, why are internal MX records unnecessary? – twconnell Nov 14 '17 at 04:03
  • @twconnell because mail clients typically don't use the receiving domain's MX records when sending mail; they almost always use their mailserver as a smarthost. It's been this way for a very long time, regardless of Exchange or otherwise. – mfinni Nov 14 '17 at 15:27
  • Thanks for clearing that up. But to answer this specific question, couldn't you use the internal DNS to direct clients to the internal resources while external DNS servers would direct them through the externally facing service? That was the point I was trying to get across, but obviously failed :) – twconnell Nov 14 '17 at 16:48