The NRPT

Artikel
02/02/2017

Applies To: Windows Server 2012 R2, Windows Server 2012

The Name Resolution Policy Table (NRPT) in Windows Server 2012 and Windows Server 2012 R2 enables you to enforce name resolution policies on security-aware DNS clients. For information about configuring the NRPT, see Procedure: Configure the NRPT.

In this section

Introduction to the NRPT

The NRPT is a table that contains rules that you can configure to specify DNS settings or special behavior for names or namespaces. The NRPT can be configured using the Group Policy Management Editor under Computer Configuration\Policies\Windows Settings\Name Resolution Policy, or with Windows PowerShell. See the following example.

The Name Resolution Policy Table in Windows Server 2012 R2 is displayed below.

When the DNS Client service performs DNS name resolution, it checks the NRPT before it sends a DNS query. If a DNS query matches an entry in the NRPT, it is handled according to settings in the policy. Queries that do not match an NRPT entry are processed normally. You can use the NRPT to require that DNSSEC validation is performed on DNS responses for queries in the namespaces that you specify.

The following table shows the options that you can use to configure the namespace to which a policy applies.

Option	Usage
Suffix	The policy applies to any name that ends in .contoso.com. This includes child domains.
Prefix	The policy applies only to a host name. This policy is triggered only if the host name portion of a DNS query matches the flat name that is configured here. For example, an entry of server1 applies to both server1.contoso.com and server1.nwtraders.com.
FQDN	The policy applies only to the specified host. This fully qualified domain name (FQDN) is not the FQDN of a domain, but an FQDN of a host computer.
Subnet (IPv4)	This option configures a policy, which applies to reverse IPv4 lookup queries.
Subnet (IPv6)	This option configures a policy, which applies to reverse IPv6 lookup queries.
Any	This option configures the default policy.

Note

The NRPT can be used to create different types of rules by choosing one of four available tabs. This topic only discusses rules configured using the DNSSEC tab, that apply to a DNSSEC deployment.

Client computers that are not security-aware, for example, computers running Windows XP, will ignore NRPT settings. For more information, see DNS Clients.

NRPT rule processing

NRPT rules can be configured in a local, site, domain, or organizational unit (OU)-linked Group Policy Object (GPO). Normal Group Policy processing rules apply. For more information, see Group Policy processing and precedence (https://technet.microsoft.com/library/cc785665.aspx). NRPT rules are processed in the following order:

Local GPO
Site-linked GPOs
Domain-linked GPOs
Organizational unit-linked GPOs

If NRPT rules are present in multiple GPOs that apply to the same user or computer, the rules are merged, with more discrete rules taking precedence over more general rules. For example, a rule that applies to a child namespace takes precedence over a rule for the parent namespace, as shown in the following table.

GPO name	Namespace	DNSSEC-enabled	Validation required
Default domain policy	contoso.com	√	X
NRPT_settings	secure.contoso.com	√	√

In this example, DNSSEC validation is required for DNS queries that have a suffix of secure.contoso.com, for example, www.secure.contoso.com. This includes queries in a child domain, for example, www.corp.secure.contoso.com. However, validation is not required for *.contoso.com or *.corp.contoso.com. Therefore, if parent and child domains require a different name resolution policy, you must explicitly create policies for the child namespace.

Warning

NRPT rules do not overwrite each other. If two rules are created in two different GPOs that apply to the same namespace for the same user or computer, a conflict occurs, and neither rule is applied. If the rules apply to the same user or computer for different namespaces, they are merged. This rule does not apply to local Group Policy, however. If any NRPT settings are configured in domain Group Policy, then all local Group Policy NRPT settings are ignored.

The NRPT can be configured to require or not require validation for specific segments of your namespace. For example, you might use a conditional forwarder to disable DNSSEC validation as described in the "Managing validation" section of DNS Clients. Using this design, you can implement a conditional forwarder that directs client computers to an external, unsigned domain for a specific namespace, such as an FQDN. If the forwarded name is within a signed namespace in your organization, validation might be required unless you specifically disable it for that FQDN.

For example, assume that you have signed an internal domain, contoso.com and you also have an external website www.contoso.com that is not signed. In this scenario, the internal and external domains use different authoritative servers. A conditional forwarder is used to resolve the name www.contoso.com. The NRPT can be configured as follows to ensure client computers are able to reach the external website without requiring DNSSEC validation:

Name	Conditional forwarder	DNSSEC-enabled	Validation required
contoso.com	none	√	√
`www.contoso.com`	208.84.0.53	X	X

In this example, other names within the contoso.com namespace, such as finance.contoso.com, will still require validation because they do not match the NRPT FQDN rule for www.contoso.com.

Filter NRPT policy

By default, new domain-linked Group Policy Objects (GPOs) apply to the Authenticated Users group. You can apply NRPT policy to selected groups, users, and computers by removing the Authenticated Users group from Security Filtering and then adding a custom user, group, or computer. See the following example.

In this example, a new GPO is created named NRPT_settings. This GPO only applies to the computer CLI1 using security filtering.

View NRPT policy

You can use the Get-DnsClientNrptPolicy cmdlet to view NRPT policies. See the following example.

PS C:\> Get-DnsClientNrptPolicy -Effective

Namespace                        : .contoso.com
QueryPolicy                      : QueryIPv6Only
SecureNameQueryFallback          : FallbackPrivate
DirectAccessIPsecCARestriction   :
DirectAccessProxyName            :
DirectAccessDnsServers           :
DirectAccessEnabled              : False
DirectAccessProxyType            :
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   :
NameServers                      :
DnsSecIPsecCARestriction         :
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         : False
DnsSecValidationRequired         : False
NameEncoding                     :

Namespace                        : .secure.contoso.com
QueryPolicy                      : QueryIPv6Only
SecureNameQueryFallback          : FallbackPrivate
DirectAccessIPsecCARestriction   :
DirectAccessProxyName            :
DirectAccessDnsServers           :
DirectAccessEnabled              : False
DirectAccessProxyType            :
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   :
NameServers                      :
DnsSecIPsecCARestriction         :
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         : False
DnsSecValidationRequired         : True
NameEncoding                     :

The Get-DnsClientNrptPolicy cmdlet gets policy that applies to the local computer. In this example, the output indicates that DNSSEC validation is required for *.secure.contoso.com, and is not required for *.contoso.com.

Dela via