Coordinating URLs with AAM and DNS

  • Article

Mark Arend, Senior Consultant, raised several good questions about coordinating URLs with alternate access mappings and DNS:

  • How do you configure alternate access mappings for single-name URLs, such as https://fabrikam?
  • How do you coordinate load-balanced access to Web applications that are extended with multiple zones, such as https://partnerweb and https://remotepartnerweb.fabrikam.com?

Configuring alternate access mappings can be tricky. After some research and consulting with our astute testers, Troy Starr, as well as working with Mark, I put together the following chart that lists the necessary information for creating or modifying alternate access mappings based on the classic authentication version of the logical architecture design sample.

As you can see, single-name URLs (for example, https://teams) can be configured for Intranet access.  These URLs are resolved by the client by appending the client’s DNS suffix, such as fabrikam.com, and then issuing a DNS lookup for the name with the suffix.  For example, when a client computer in the fabrikam.com domain requests https://teams, the computer sends a request to DNS for https://teams.fabrikam.com. 

In addition to configuring alternate access mappings, some DNS work is necessary as well. DNS must be configured with an A record for each Fully Qualified Domain Name (FQDN). The A record points to the load balanced IP address for the Web servers hosting a site. In a typical production deployment, servers are configure with statically assigned IP addresses, as well as statically assigned A records in DNS. 

After receiving the virtual IP address of the load balancer, the client browser establishes communication with a front-end Web server in the farm, then sends an HTTP request with the original single-name URL, https://teams.  IIS and SharePoint recognize this as a request for the Intranet zone, based on the settings configured in alternate access mappings.  If the user had instead requested https://teams.fabrikam.com, the process would be the same except IIS and SharePoint would receive this FQDN instead, and therefore recognize this request for the Default zone.

In environments with multiple domains, enter CNAME records for DNS in the domains that the sites do not reside in. For example, if the Fabrikam network environment includes a second domain called europe.fabrikam.com, CNAME records are entered for these sites in the Europe domain. For the Team Sites intranet site (https://teams), a CNAME record called teams is added to the europe.fabrikam.com domain that points to teams.fabrikam.com. Then, when a client’s DNS suffix is appended to DNS lookup requests, a request for https://teams from the Europe domain will issue a DNS lookup of teams.europe.fabrikam.com, and be directed by the CNAME record to teams.fabrikam.com.

After learning about how URLs are resolved by the browser, I realized that https://fabrikam is not a great choice for an illustrative URL (https://fabrikam.fabrikam.com?). Consequently, I updated the classic authentication version of the logical architecture design sample with the URL of https://intranet instead. You can download the updated version at  SharePoint Server 2010 design samples: Corporate portal with classic authentication or with claims-based authentication (https://go.microsoft.com/fwlink/?LinkId=196872).

Finally, there is a known issue with some Kerberos clients and resolving CNAME records. If your environment includes Kerberos authentication,  see Kerberos configuration known issues (SharePoint Server 2010).