Using Pinpoint DNS to route AD FS authentication traffic

In this post, we’ll look at pinpoint zones in DNS and how they can be used to route AD FS traffic more favorably for authentication.

In larger AD FS setups with thousands of users, enterprises may be using a global farm spanning multiple regions. In the absence of global site load balancing, pinning users to a particular region for authentication is not trivial, and begs the question: How do I respond with different IP addresses from a single hostname?

Let’s look at a hypothetical AD FS scenario using Azure VMs. Our farm is located in Azure region US East and two AD FS farm nodes are configured behind an Azure internal load balanced virtual IP of 172.20.15.5. On the Internet facing side, we have a pair of Web Application Proxies (WAP) connected to an Azure Internet load balancer (these are not germane to this discussion).

An ExpressRoute connects the corporate New York headquarters of the organization to the Azure network in the US, and a similar connection links up Europe via their London office. An (A) record in DNS adfs.mydomain.com points to the IP address of the Azure load balancer.

Users in Europe, however, are reporting that AD FS logon times are poor when connected to the company network. To improve response time and overall performance, an additional farm in the Azure region UK South is deemed necessary.

From an AD FS perspective, the challenge at this point is how to route internal logon traffic to the new farm. Remember that the federation service URL in internal DNS currently points to the US East VIP of the Azure load balancer.

The trick is using a pinpoint DNS zone. We create a primary zone in DNS representing the URL of the federation service. By making it a primary zone we are allowing control over which domain controllers the zone is created on and whether it is replicated (Active Directory Integrated). By localizing it to domain controllers of our choice, say Europe, we can then create an A record in DNS that points to the Europe Azure internal load balancer VIP (172.20.75.5).

Let’s see how that works. On a European domain controller, we create a new primary forward lookup zone (adfs.mydomain.com)

Once that’s done, we create an (A) record in DNS in the adfs.mydomain.com zone. Leave the name blank.

Those clients using this domain controller as their DNS server will now resolve the name to the European load balancer.

On each domain controller where we wish connecting clients to use the European AD FS farm, we repeat this process. Other domain controllers that are using the Active Directory Integrated (ADI) replicated version of this record will continue to resolve to the US East Azure internal load balancer.