We discussed the special DNS records used for IPv6, and that brings up the question of which DNS server to use. Most organizations that deploy URA would typically all be using Microsoft DNS servers, and the good news is that Microsoft's DNS started supporting IPv6 way back in 2003. This means that even if your domain is a bit older, you're still good to go and don't need to upgrade the DNS. If your environment is using UNIX or Linux, you're going to have to make sure your DNS servers are running BIND version 9 at least, though we're sure you've gone there a long time ago, following the numerous security vulnerabilities discovered in the older versions of BIND.

Another aspect of DNS with regards to URA is the matter of internal vs. external name resolution. Your URA clients will have to be able to correctly resolve the public hostname of your URA server or your server array. While connected to the corporate network, the clients will have to be able to resolve the names of internal servers they need to contact.

If your organization is using the same DNS domain structure on the internal network and on the public internet, referred to as split-brains DNS, it can be tricky because you need to decide if you want URA users to access the published resources externally or internally. In such a case, you need to make sure that as clients move from using the internal DNS server on the corporate network to using the public DNS server that their ISP is hosting, they are still able to resolve all the appropriate URLs, and do so correctly. A problem could happen, for example, if there is a resource that is supposed to be accessible from both the internal network and the public one. Perhaps your SharePoint server is set up this way, or the company's public website may be. In such a situation, you have two options. One is to make a choice and have that resource available either internally or externally (only to the URA users!). The other option is to configure the resource with an alternative internal name.

A very important part of the DNS resolution mechanism for URA clients is the Name Resolution Policy Table (NRPT). This is a piece of the name resolution mechanism on a URA client that is in charge of controlling how the client resolves internal and external hostnames. This table comes into play when the client is outside of the corporate network, and is used to manage the way name resolution is done on the client. When URA is on, the client needs to be able to resolve internal corporate network names, but still resolve public hostnames on the internet. The public DNS server that the client is configured with is still around, doing its job, and the URA server will be in charge of helping resolve internal hostnames. The NRPT simply tells the client for which network resources it should contact the URA server, and for which it should not. For example, the NRPT might say "For any hostname that ends with Createhive.com, perform name resolution through the URA server, and for anything else, use the public DNS server you have configured". You will be configuring this later as part of the URA role setup, so we'll examine this with more detail later on, but keep this concept in mind as it's very important.