Resolving the Internal/External DNS zone Dilemma with Pinpoint DNS

Here’s an interesting trick that might help you resolve some of your DNS management woes, particularly if you have a different Public and Private DNS zone in your environment. For instance, you have a domain name of whatever.com externally, but use whatever.local internally. When your DNS is set up like that, all attempts to access systems using the whatever.com domain name will default to using the external, Public IP addresses assigned in that DNS zone. If you want to have internal, Private IP addresses assigned to those systems instead (which is common), you normally have to create an entire zone for whatever.com on your Internal DNS servers and populate it with A records for all the systems that exist in the public DNS zone. This technique, known as Split Horizon DNS or just Split DNS, results in additional administrative burden, since changes to the external DNS zone have to be replicated internally as well, and you have to spend time recreating all the DNS records that are already there. Luckily, there’s a little DNS trick you can use to get past this limitation: Pinpoint DNS.

Pinpoint DNS – What is it?

Put simply, Pinpoint DNS is a technique that utilizes some of the features of DNS to allow you to create a record for a single host name that exists in a different DNS zone than you usually use. For instance, instead of creating an entire Primary zone in your internal DNS for whatever.com, you can create a Pinpoint DNS record for really.whatever.com.

Make it So!

To implement Pinpoint DNS, all you have to do is create a new Primary DNS zone in DNS. Instead of naming the zone whatever.com, name the zone really.whatever.com. Once the zone is created, you can then assign an IP address to the root of that new zone (in Windows, this shows up as the IP being “Same as Parent”). Attempts to connect to really.whatever.com will resolve the root zone IP address, and you will be connected to whatever you set that IP to. So, instead of having an entire internal DNS zone full of DNS A records that you have to fill out, even if you only want an Internal IP on one of them, you can have a DNS zone for the single Internal IP record.

Downsides?

There really aren’t a lot of downsides to this, other than it could confuse people who aren’t familiar with the technique. It does look a little odd to see a lot of Forward Lookup Zones in DNS with only a single record in them, but that’s just aesthetic.

Functionally, as long as the DNS zones you create for Pinpoint records are AD integrated, there aren’t any technical downsides to this technique, but if you have a large, distributed DNS infrastructure that *isn’t* AD integrated, this technique will greatly increase administrative burden, since you have to create replication configurations for each Pinpoint record. If you run a DNS environment that isn’t part of Active Directory, Pinpoint DNS isn’t a good solution, because it increases the burden more than managing split horizon DNS.

DNS is a very light-weight protocol (having been designed in the late 70s), so replication traffic increases caused by having multiple Forward Lookup Zones is generally not an issue here.

Windows How To

To implement this, do the following:

  1. Open DNS Management (preferably a Domain Controller)
  2. Expand the DNS server that’s listed
  3. Right Click the Forward Lookup Zones entry and select New Zone to open the new zone wizard. Hit Next when the wizard opens.
  4. Make sure Primary DNS Zone is selected, and that the AD Integration option is checked. Click Next.
  5. Select the option to replication to all DCs in the Forest (particularly if you are in a multi-domain Forest. It’s not necessary for single domain forests, but it’s a good idea to set this anyway, in case that ever changes). Click Next.
  6. Enter the name of the zone. This will be the host name you’re assigning an IP to, so really.whatever.com for the previous example. Click Next.
  7. Select the option to only allow secure updates (It’s the default, anyway). Click Next, then Finish to finalize the wizard and create the zone.
  8. Expand your Forward Lookup Zones and you’ll see the zone there, like below:PinpointDNSZone
  9. Right Click the new Zone, select New Host (A or AAAA).
  10. In the wizard that appears, *leave the host name blank*. This is important, since it is the key part of Pinpoint DNS. An empty host name assigns the A record to the root domain.
  11. Enter the IP address you want to point to in the IP address field, then click Add Host. Your record should look like the one below:PinpointDNSRecord
  12. Verify the new record appears in the really.whatever.com zone, and shows as (Same as Parent).

Once that’s done, the next time you ping really.whatever.com (after running “ipconfig /flushdns” to clear your DNS cache, of course), you’ll receive the Internal IP address you assigned to the Pinpoint zone, and the rest of your external DNS records will remain managed by external DNS servers.

Advertisements

Internal DNS and Exchange Autodiscover

The Issue

By now, anyone who has managed, deployed, or worked with an Exchange 2007 or later environment should be familiar with Autodiscover. If you aren’t yet, I’ll give a short Explanation of what it is and how it works.

Autodiscover is a feature that allows any Mail Client that supports Autodiscover to configure the appropriate server settings for communication so you don’t have to input everything manually. It’s very handy. Unfortunately, you can end up with a lot of headaches related to Autodiscover when you start having to deal with Certificates. The issues you may run into are specifically limited to Exchange Organizations that have a Domain Name that uses a non-public TLD like domain.local, or a public domain name that they don’t actually own and can’t use externally as well. On an unrelated note, this is one of the reasons that Microsoft has started recommending the use of Public domain names for Active Directory domains.

If you have a domain that isn’t publicly useable on your Exchange AD environment, you will run into certificate errors when mail clients use Autodiscover. This becomes particularly problematic when you use Exchange 2013 and try to use HTTPS for Outlook Anywhere. This is because Microsoft is now enforcing certificate validity with Exchange 2013’s Autodiscover features (Note, though, that Outlook Anywhere will be configured to use HTTP only when your Exchange Server certificate is determined to be invalid in Exchange 2013). With Exchange 2007 and 2010, you will get a Certificate error every time you open Outlook. Generally, this error will state that the name on the certificate is not valid.

The Cause

To solve the issue with certificates, you need to configure your environment so it enforces the appropriate action with Autodiscover. By default, Autodiscover will attempt to communicate with a number of URLs based on the Client’s email address (for external users) or domain name (for internal users). It will take the following pattern when checking for Autodiscover services:

1. Autodiscover will attempt to find the Autodiscover configuration XML file at the domain name of the SMTP address used in configuration (because internal domain computers configure themselves automatically by default, this matches the Internal Domain. For example, the first place autodiscover looks is https://domain.com/Autodiscover/autodiscover.xml for external addresses. Change domain.com with domain.local for what Exchange looks for on Internal clients.

2. If the autodiscover record is not found at domain.com/domain.local, the server will attempt to connect to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml (replace domain.com with domain.local for internal). This is why the typical recommendation for having an A Record for Autodiscover in your DNS that points to the mail server exists. In addition, you would need to have autodiscover.domain.com as a SAN on the SSL certificate installed on the Exchange server for it to be valid when attempting to connect to autodiscover using this step.

3. If autodiscover information cannot be found in either of the first two steps, Exchange will attempt to use a Service Locator record in DNS to determine the appropriate location of the configuration files. This record points the Autodiscover service to a specific location for getting the configuration it needs.

Because of the way this works, there is some configuration necessary to get Autodiscover working correctly. This usually involves adding Subject Alternate Names to the SSL certificate you use for your Exchange Server to allow the many host names used to be authenticated with the certificate.

The problem lately, though, is that many Third Party Certificate Authorities that provide SSL certificates are beginning to deny requests for Subject Alternate Names that aren’t publicly available (There are valid security reasons for this that I won’t go in to in this post, but maybe later). As a result, you won’t be able to get a valid SSL certificate that allows domain.local as a SAN. This means that the automated steps Exchange uses for Autodiscover configuration will always fail on an Internal domain with a name that is not publicly accessible or not owned.

The Solution

IMPORTANT NOTE: This particular solution only applies to computers on your network that are *not* added to the domain. Domain-joined computers have a different solution to work with. Please read my article on resetting the Active Directory SCP for resolving Autodiscover issues like this on domain-joined computers.

There are actually two ways to solve the certificate issues, here. The first would be to prevent Outlook from automatically entering a user’s information when they create their profile. This will result in more work for you and your users, so I don’t recommend it. The other solution is to leverage that last step of the Autodiscover configuration search to force it to look at a host name that is listed on the certificate. This is actually fairly simple to do. Follow these steps to configure the Service Locator record in your internal domain.

  1. Open the DNS manager on one of your Domain Controllers.
  2. Expand out the management tree until you can see your Internal Domain’s Forward Lookup Zone. Click on it, and make sure there are no A records for autodiscover.domain.local in the zone.
  3. Once no autodiscover A records exist, right click the Zone name and select Other New Records.
  4. Select Service Location (SRV) from the list.
  5. Enter the settings as shown below:Image
  6. Hit OK to finish adding the record.

Once the SRV record is added to the internal DNS zone, Outlook and other autodiscover clients that attempt to configure themselves with a domain.local SMTP address will work properly without the Certificate errors on all versions of Exchange.

Other Nifty Stuff

There are some additional benefits to utilizing the Service Locator record for Autodiscover rather than an Autodiscover A record, even in your public domain. When you use a SRV record, you can also point public clients to communicate with mail.domain.com or outlook.domain.com, or whatever you have configured your external server name to be. This means you can get away with having a single host name on your SSL certificate, since you wouldn’t need autodiscover.domain.com to get autodiscover working. Since most Third Party CAs charge a bit more for SANs than they do for Single Name SSL certs, you can save a bit of money (for this to work, though, you may need to change your Internal and External Web Services URLs in Exchange to match the name you have configured).

Another Problem the SRV record Fixes

There are also some other issues you may run into that are easily fixed by adding a SRV record. One of the most common is the use of multiple Email Domains in a single Exchange Environment. If you have users that are not assigned a Primary or secondary SMTP address that matches the domain name listed on your SSL certificate, you’ll discover that those users and the rest of your users will not be able to share calendar data between their mailboxes. You can fix this by adding an Autodiscover SRV record to the DNS zone that manages the additional mail domains. For example, you have domain1.com and domain2.com on the same Exchange Server. user@domain1.com can’t see user@domain2.com’s calendar. The fix for this is to add the SRV record to the domain2.com DNS zone and point it to the public host name for domain1.com’s mail server. Once that’s done the services that operate the calendar sharing functions will be properly configured and both users will be able to share calendars.