Wouldn't it be nice to have a method you could use to control what DNS server is used by a DNS client based on the FQDN or some other criteria you set within Group Policy? This kind of feature would expand your client-side name resolution options by allowing the client to use the DNS servers configured on the systems' NIC(s) or use different DNS servers based on FQDN, DNS suffix, DNS prefix, IPv4 Network ID, IPv6 Network ID or anything else! Well, you can do that in a limited set of scenarios by taking advantage of the Name Resolution Policy Table included with Windows Server 2008 R2.
The NRPT defines the DNS client behavior based on queries made by the DNS client. If the client makes a query for one FQDN, that query would be sent to the DNS server configured on the client's NIC. If the client makes a query for another FQDN, that query would be sent to another DNS server, not configured on the client's NIC, but based on an entry in the NRPT. In fact, Windows 7 and Windows Server 2008 R2 take advantage of this ability to control what DNS servers are used and what the DNS client behavior should be based on the query subject in their implementations of DNSSEC and DirectAccess.
Before the DNS client issues a DNS query, it will check with the NRPT to see if it should set any flags on the request. After receiving a response from the DNS server, the DNS client will check again to see if there is any other processing requirements before moving forward. If there is no NRPT configured on the client, then the client will use the DNS server setting figured on its NIC to send DNS queries to, and there will be no special processing of DNS queries either before or after the query is sent.
To get a better idea of what you can do in the NRPT, let's take a look at the NRPT settings in Active Directory Group Policy. You can find them by opening the Group Policy Editor and navigating to Computer Configuration\Policies\Windows Settings\Name Resolution Policy, as seen in the figure below.
Figure 1
In the right pane of the console you will see the NRPT configuration interface, as seen in the figure below.
Figure 2
Let us now examine the options and see how they are used to configure an NRPT entry.
In the To which part of the namespace does this rule apply? Well, you decide whether you want the rule to apply to a Suffix, a Prefix, a FQDN, a Subnet (IPv4), a Subnet (IPv6) or Any. If you select "Any" then all queries will be controlled by the policy you set for this NRPT entry. In this example, we have chosen the Suffix option and entered a DNS suffix of ipadsux.org.
The next option is the Certification Authority(Optional) setting. This is used when you use the NRPT for a DNSSEC deployment. DNSSEC is a method you can use to insure that DNS queries and responses are done in a secure fashion, and that DNS clients can authenticate DNS servers for queries made for hosts in specific domains. You can click the Browse button to find a CA certificate that you want the DNS client to trust when authenticating the DNS server in a DNSSEC deployment.
There are two tabs that you can use to create this rule for the NRPT: the DNSSEC tab and the DNS Settings for DirectAccess. When creating the rule, use only one of these tabs at a time. In general, it's better to break the rules out, separating the DNSSEC rules from the DirectAccess rules; this makes them easier to keep track of and clear independently if you ever have a need to do so.
On the DNSSEC tab, as seen in the figure below, you have the following options:
- Enable DNSSEC in this rule: When this is enabled, any queries for the FQDN specified above will require the use of DNSSEC.
- Require DNS clients to check that name and address data has been validated by the DNS Server: Setting this value controls how the DNS client processes DNS queries; it does not control DNS server behavior or configuration of a "trust anchor" (used by DNSSEC to secure zones) on the DNS server. What it does do is tell the DNS clients to check for the "Authenticated Data" bit in the DNS response returned by the DNS server for the DNS query issued by the client. If the "Authenticated Data" bit is not set (thus confirming that the response data is not validated) the DNS client will drop the response and consider the query as failed.
- Use IPsec in communication between the DNS client and DNS server: This option tells the client whether it should establish an IPsec connection between itself and the DNS server before issuing the DNS query and receiving the DNS query response. If you do choose to enable IPsec to secure the communication between the DNS client and server, then you have several options in terms of how to secure the connection: No encryption (integrity only), Low: 3DES, AES (128, 192, 256), Medium: AES (128, 192,256), or High: AES (192,256). The "no encryption" option provides for machine authentication only and the DNS query traffic will move in the clear. If you choose an encryption option, the IPsec link will be both authenticated and encrypted, using the level of encryption you select here and that supported by the client and server.
Figure 3
After making your DNSSEC configuration selection, you can click the Update button and then see the NRPT entry in the Name Resolution Policy Table as seen in the figure below. Notice that there are two buttons under the table: Delete Rule and Edit Rule. These buttons appear when you click the line on the table for the rule of interest. If you want to edit the rule, click the Edit Rule button. If you want to delete the rule, click the Delete Rule button. It's pretty easy.
Figure 4
Now let us examine the options for the DNS Settings for DirectAccess. Notice that there is a minor spelling error on this Group Policy Object configuration page. DirectAccess should be one word but is listed as a two-word term several times in this configuration interface. I told Tom about this and now it's his problem :)
Note that if you want to create a new rule, you should click the Clear button and start the configuration over from the To which part of the namespace does this rule apply section and the Certification Authority section. Then you can click the Create button to create the new rule and use the Edit Rule button to make changes later if you like.
The options you have here include:
- Enable DNS settings for Direct Access [sic] in this rule: This option turns on the DNS settings configured here for the DirectAccess clients.
- Web proxy (optional): This is an interesting option, which might have several meanings. However, this appears to not be documented, so I recommend you avoid this option until such documentation becomes available.
- IPsec: Use IPsec in communication between the DNS client and DNS server: This option enables the same options as the IPsec choices seen earlier. You have the same options, which include No encryption, Low, Medium and High.
Figure 5
There is one more dialog box that is of interest if you are deploying a Windows DirectAccess solution. Click the Advanced Global Policy Settings button to expose this dialog box, as seen in the figure below.
Figure 6
This dialog box exposes three sections:
- Network Location Dependency
- Query Failure
- Query Resolution
The Network Location Dependency option allows you to configure roaming options. The default is Let Network ID (NID) determine when Direct Access [sic] settings are to be used. This is an undocumented option, but I believe it is related to whether or not the client is able to connect to a certain resource on the corpnet to determine which DNS settings to use when the client is acting as a DirectAccess client. If the client detects that it is on-network, it will use the DNS settings configured on its NIC. If the DirectAccess client isn't able to connect to a resource that is located on the corpnet, then the DirectAccess client assumes that it is off-network and will use DirectAccess settings for name resolution. However, this is an educated guess, since these settings are undocumented at this time.
The Query Failure option defines how name resolution should be handled if there is a DNS name query failure. If you select the Configure query failure options checkbox, the default setting is Always fall back to Link-Local Multicast Name Resolution (LLMNR) and NetBIOS if the name does not exist in DNS or if the DNS servers are unreachable when on a private network (moderately secure). This option allows the use of local name resolution on a private network when the corpnet DNS servers are unavailable to the DirectAccess client.
The Query Resolution section is also interesting. Again, this entire dialog box is not documented, but I think we can figure it out. When you select the Configure query resolution options checkbox, you have two options: Resolve only IPv6 address for names (recommended) and Resolve both IPv4 and IPv6 addresses for names. This is interesting because when the DirectAccess client connects to resources on the corpnet over a DirectAccess connection, is uses only IPv6 addresses, as all communications from the DirectAccess client to the corpnet are IPv6 communications – IPv4 is never used when the DirectAccess client connects to the corpnet. Perhaps that's why it's recommended.
The Resolve both IPv4 and IPv6 addresses for names does not seem to make sense in the DirectAccess client context given the facts as stated above. However, perhaps this means that you can use IPv4 for local name resolution or names that are not processed by the NRPT? I think we will have to wait for Microsoft to create some documentation of this configuration page before we make any hard and fast decisions on the utility of these settings.
All of this might be a moot issue anyhow, as Tom tells me that when using UAG for your DirectAccess solution, UAG handles the configuration of the NRPT and delivers the correct settings to DirectAccess clients using a GPO that's applied only to DirectAccess client computers that are members of a security group to which the GPO is applied. So, when working with UAG DirectAccess, you won't have to deal with this dialog box. Still, it would be nice to get some documentation on the missing settings.
No comments:
Post a Comment