Microsoft Windows 2008 Server Domain Name System Security Technical Implementation Guide

V1R5 2019-01-04       U_MS_Windows_2008_Server_DNS_STIG_V1R5_Manual-xccdf.xml
V1R4 2018-07-09       U_MS_Windows_2008_Server_DNS_STIG_V1R4_Manual-xccdf.xml
This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: [email protected]
Comparison
All 43
No Change 42
Updated 1
Added 0
Removed 0
V-58237 No Change
Findings ID: WDNS-AC-000001 Rule ID: SV-83199r1_rule Severity: medium CCI: CCI-000054

Discussion

Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) on any system.

A DNS server's function requires it to be able to handle multiple sessions at a time so limiting concurrent sessions could potentially cause an impact to availability. Primary name servers need to be configured to limit the actual hosts from which they will accept dynamic updates and from which they will accept zone transfer requests, and all name servers should be configured to limit the hosts from/to which they receive/send zone transfers. Restricting sessions to known hosts will mitigate the DoS vulnerability.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Once selected, right-click the name of the zone.

From the displayed context menu, click the “Properties” option.

On the opened domain's properties box, click the “General” tab.

Verify the Type: is Active Directory-Integrated.

Verify the Dynamic updates has "Secure only" selected.

If the zone is Active Directory-Integrated and the Dynamic updates are not configured for "Secure only", this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Once selected, right-click the name of the zone.

From the displayed context menu, click the “Properties” option.

On the opened domain's properties box, click the “General” tab.

If the Type: is not Active Directory-Integrated, configure the zone for AD-integration.

Select "Secure only" from the Dynamic updates: drop-down list.
V-58543 No Change
Findings ID: WDNS-AU-000001 Rule ID: SV-83231r1_rule Severity: medium CCI: CCI-000366

Discussion

Without a means for identifying the individual that produced the information, the information cannot be relied upon. Identifying the validity of information may be delayed or deterred.

This requirement ensures organizational personnel have a means to identify who produced or changed specific information in transfers, zone information, or DNS configuration changes.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

Right-click the DNS server, select “Properties”.

Click on the “Event Logging” tab. By default, all events are logged.

Verify "Errors and warnings" or "All events" is selected.

If any option other than "Errors and warnings" or "All events" is selected, this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

If not automatically started, initialize the “Server Manager” window by clicking its icon from the bottom left corner of the screen.

On the opened “Server Manager” window, from the left pane, click to select “DNS”.

From the right pane, under the “SERVERS” section, right-click the DNS server.

From the displayed context menu, click the “DNS Manager” option.

Click on the “Event Logging” tab.

Select the "Errors and warnings" or "All events" option.

Click on “Apply”.

Click on “OK”.
V-58547 No Change
Findings ID: WDNS-AU-000003 Rule ID: SV-83233r2_rule Severity: medium CCI: CCI-000366

Discussion

Failing to act on the validation errors may result in the use of invalid, corrupted, or compromised information. The validation of bindings can be achieved, for example, by the use of cryptographic checksums. Validations must be performed automatically.

At a minimum, the application must log the validation error. However, more stringent actions can be taken based on the security posture and value of the information. The organization should consider the system's environment and impact of the errors when defining the actions. Additional examples of actions include automated notification to administrators, halting system process, or halting the specific operation.

The auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server.

Checks

Windows 2012 DNS servers, hosting Active Directory integrated zones, transfer zone information via AD replication. Windows 2012 DNS servers hosting non-AD-integrated zones as a secondary name server and/or are not hosting AD-integrated zones use zone transfer to sync zone data.

If the Windows 2012 DNS server only hosts AD-integrated zones and all other name servers for the zones hosted are Active Directory Domain Controllers, this requirement is not applicable.

If the Windows 2012 DNS server is not an Active Directory Domain Controller, or is a secondary name server for a zone with a non-AD-integrated name server as the master, this requirement is applicable.

Administrator notification is only possible if a third-party event monitoring system is configured or, at a minimum, there are documented procedures requiring the administrator to review the DNS logs on a routine, daily basis.

If a third-party event monitoring system is not configured, or a document procedure is not in place requiring the administrator to review the DNS logs on a routine, daily basis, this is a finding.

Fix

To detect and notify the administrator, configure a third-party event monitoring system or, at a minimum, document and implement a procedure to require the administrator to check the DNS logs on a routine, daily basis.
V-58549 No Change
Findings ID: WDNS-AU-000005 Rule ID: SV-83201r1_rule Severity: medium CCI: CCI-000169

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

Right-click the DNS server, select “Properties”.

Click on the “Event Logging” tab. By default, all events are logged.

Verify "Errors and warnings" or "All events" is selected.

If any option other than "Errors and warnings" or "All events" is selected, this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

Right-click the DNS server, select “Properties”.

Click on the “Event Logging” tab. By default, all events are logged.

Select the "Errors and warnings" or "All events" option.

Click on “Apply”.

Click “OK”.
V-58553 No Change
Findings ID: WDNS-AU-000007 Rule ID: SV-83203r2_rule Severity: medium CCI: CCI-000171

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server.

Since the configuration of the audit logs on the DNS server dictates which events are logged for the purposes of correlating events, the permissions for configuring the audit logs must be restricted to only those with the role of ISSM or those appointed by the ISSM.

Checks

Verify the effective setting in Local Group Policy Editor.

Run "gpedit.msc".

Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

If any accounts or groups other than the following are granted the "Manage auditing and security log" user right, this is a finding:

Administrators Auditors (if the site has an Auditors group that further limits this privilege.)

If an application requires this user right, this would not be a finding.
Vendor documentation must support the requirement for having the user right.
The requirement must be documented with the ISSO.
The application account must meet requirements for application account passwords.

Verify the permissions on the DNS logs.

Standard user accounts or groups must not have greater than READ access.

The default locations are:

DNS Server %SystemRoot%\System32\Winevt\Logs\DNS Server.evtx

Using the file explorer tool navigate to the DNS Server log file.

Right click on the log file, select the “Security” tab.

The default permissions listed below satisfy this requirement:

Eventlog - Full Control
SYSTEM - Full Control
Administrators - Full Control

If the permissions for these files are not as restrictive as the ACLs listed, this is a finding.

Fix

Configure the permissions on the DNS logs.

Standard user accounts or groups must not have greater than READ access.

The default permissions listed below satisfy this requirement:

Eventlog - Full Control
SYSTEM - Full Control
Administrators - Full Control

The default locations are:

DNS Server %SystemRoot%\System32\Winevt\Logs\DNS Server.evtx
V-58573 No Change
Findings ID: WDNS-AU-000016 Rule ID: SV-83205r1_rule Severity: medium CCI: CCI-001348

Discussion

Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on a defined frequency helps to assure, in the event of a catastrophic system failure, the audit records will be retained.

This helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records.

This requirement only applies to applications that have a native backup capability for audit records. Operating system backup requirements cover applications that do not provide native backup functions.

Checks

Consult with the System Administrator to determine the backup policy in place for Windows 2008 DNS Server.

Review the backup methods used and determine if the backup's methods have been successful at backing up the audit records at least every seven days.

If the organization does not have a backup policy in place for backing up the Windows 2008 DNS Server's audit records and/or the backup methods have not been successful at backing up the audit records at least every seven days, this is a finding.

Fix

Document and implement a backup policy to back up the DNS Server's audit records at least every seven days.
V-58577 No Change
Findings ID: WDNS-CM-000002 Rule ID: SV-83213r2_rule Severity: medium CCI: CCI-000366

Discussion

In addition to network-based separation, authoritative name servers should be dispersed geographically as well. In other words, in addition to being located on different network segments, the authoritative name servers should not all be located within the same building. One approach that some organizations follow is to locate some authoritative name servers in their own premises and others in their ISPs' data centers or in partnering organizations.

A network administrator may choose to use a "hidden" master authoritative server and only have secondary servers visible on the network. A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the master authoritative name server is "hidden", a secondary authoritative name server may reside in the same building as the hidden master.

Checks

Windows 2008 DNS Servers that are Active Directory integrated must be located where required to meet the Active Directory services.

If all of the Windows 2008 DNS Servers are AD integrated, this check is Not Applicable.

If any or all of the Windows 2008 DNS Servers are standalone and non-AD-integrated, verify with the System Administrator their geographic location.

If any or all of the authoritative name servers are located in the same building as the master authoritative name server, and the master authoritative name server is not "hidden", this is a finding.

Fix

For non-AD-integrated Windows 2008 DNS servers, distribute secondary authoritative servers to be located in different buildings from the primary authoritative server.
V-58579 No Change
Findings ID: WDNS-CM-000003 Rule ID: SV-83235r1_rule Severity: medium CCI: CCI-000366

Discussion

A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to non-existent hosts (which constitutes a denial of service), or, worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords.

To guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine: one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation.

Checks

Note: If the Windows DNS server is in the classified network, this check is Not Applicable.

Note: In Windows 2008 DNS Server, if forwarders are configured, the recursion setting must also be enabled since disabling recursion will disable forwarders.

If forwarders are not used, recursion must be disabled.

In both cases, the use of root hints must be disabled. The root hints configuration requirement is addressed in WDNS-CM-000004.

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select “Properties”.

Click on the “Forwarders” tab.

If forwarders are enabled and configured, this check is not applicable.

If forwarders are not enabled, click on the “Advanced” tab and ensure the "Disable recursion (also disables forwarders)" check box is selected.

If forwarders are not enabled and configured, and the "Disable recursion (also disables forwarders)" check box in the “Advanced” tab is not selected, this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select “Properties”.

Click on the “Forwarders” tab.

If forwarders are not being used, click the “Advanced” tab.

Select the "Disable recursion (also disables forwarders)" check box.
V-58581 No Change
Findings ID: WDNS-CM-000004 Rule ID: SV-83237r1_rule Severity: medium CCI: CCI-000366

Discussion

A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to non-existent hosts (which constitutes a denial of service), or, worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords.

To guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine: one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation.

Checks

Note: If the Windows DNS server is in the classified network, this check is Not Applicable.

Note: In Windows 2008 DNS Server, if forwarders are configured, the recursion setting must also be enabled since disabling recursion will disable forwarders.

If forwarders are not used, recursion must be disabled. In both cases, the use of root hints must be disabled.

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select “Properties”.

Click on the “Forwarders” tab.

If forwarders are not being used, this is not applicable.

Review the IP address(es) for the forwarder(s) use.

If the DNS Server does not forward to another DoD-managed DNS server or to the DoD Enterprise Recursive Services (ERS), this is a finding.

If the "Use root hints if no forwarders are available" is selected, this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select “Properties”.

Click on the “Forwarders” tab.

Replace the forwarders being used with another DoD-managed DNS server or the DoD Enterprise Recursive Services (ERS).

Deselect the "Use root hints if no forwarders are available".
V-58583 No Change
Findings ID: WDNS-CM-000005 Rule ID: SV-83239r1_rule Severity: medium CCI: CCI-000366

Discussion

A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to non-existent hosts (which constitutes a denial of service), or, worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords.

To guard against poisoning, name servers specifically fulfilling the role of providing recursive query responses for external zones need to be segregated from name servers authoritative for internal zones.

Checks

Verify the Windows 2008 DNS Server will only accept TCP and UDP port 53 traffic from specific IP addresses/ranges.

This can be configured via a local or network firewall.

If the caching name server is not restricted to answering queries from only specific networks, this is a finding.

Fix

Configure a local or network firewall to only allow specific IP addresses/ranges to send inbound TCP and UDP port 53 traffic to a DNS caching server.
V-58593 No Change
Findings ID: WDNS-CM-000010 Rule ID: SV-83255r2_rule Severity: high CCI: CCI-000366

Discussion

Poorly constructed NS records pose a security risk because they create conditions under which an adversary might be able to provide the missing authoritative name services that are improperly specified in the zone file. The adversary could issue bogus responses to queries that clients would accept because they learned of the adversary's name server from a valid authoritative name server, one that need not be compromised for this attack to be successful. The list of slave servers must remain current within 72 hours of any changes to the zone architecture that would affect the list of slaves. If a slave server has been retired or is not operational but remains on the list, then an adversary might have a greater opportunity to impersonate that slave without detection, rather than if the slave was actually online. For example, the adversary may be able to spoof the retired slave's IP address without an IP address conflict, which would not be likely to occur if the true slave were active.

Checks

NOTE: This check is Not Applicable if Windows DNS server is only serving as a caching server and does not host any zones authoritatively.
Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press “Windows Key + R”, execute “dnsmgmt.msc”.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Review the NS records for the zone.

Verify each of the name servers, represented by the NS records, is active.

At a command prompt on any system, type:

nslookup <enter>;

At the nslookup prompt, type:

server=###.###.###.### <enter>;
(where the ###.###.###.### is replaced by the IP of each NS record)

Enter a FQDN for a known host record in the zone.

If the NS server does not respond at all or responds with a non-authoritative answer, this is a finding.

Fix

If DNS servers are AD-integrated, troubleshoot and remedy the replication problem where the non-responsive name server is not getting updated.

If DNS servers are not AD-integrated, log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Review the NS records for the zone.

Select the NS record for the non-responsive name server and remove the record.
V-58595 No Change
Findings ID: WDNS-CM-000012 Rule ID: SV-83271r1_rule Severity: medium CCI: CCI-000366

Discussion

Most enterprises have an authoritative primary server and a host of authoritative secondary name servers. It is essential that these authoritative name servers for an enterprise be located on different network segments. This dispersion ensures the availability of an authoritative name server not only in situations in which a particular router or switch fails but also during events involving an attack on an entire network segment.

A network administrator may choose to use a "hidden" master authoritative server and only have secondary servers visible on the network. A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the master authoritative name server is "hidden", a secondary authoritative name server may reside on the same network as the hidden master.

Checks

Windows 2008 DNS Servers that are Active Directory-integrated must be located where required to meet the Active Directory services.

If all of the Windows 2008 DNS Servers are AD-integrated, this check is not applicable.

If any or all of the Windows 2008 DNS Servers are stand-alone and non-AD-integrated, verify with the System Administrator their geographic dispersal.

If all of the authoritative name servers are located on the same network segment, and the master authoritative name server is not "hidden", this is a finding.

Fix

For non-AD-integrated Windows 2008 DNS Servers, distribute secondary authoritative servers on separate network segments from the primary authoritative server.
V-58597 No Change
Findings ID: WDNS-CM-000013 Rule ID: SV-83273r1_rule Severity: medium CCI: CCI-000366

Discussion

The only protection approach for content control of a DNS zone file is the use of a zone file integrity checker. The effectiveness of integrity checking using a zone file integrity checker depends upon the database of constraints built into the checker. The deployment process consists of developing these constraints with the right logic, and the only determinant of the truth value of these logical predicates is the parameter values for certain key fields in the format of various RRTypes.

The serial number in the SOA RDATA is used to indicate to secondary name servers that a change to the zone has occurred and a zone transfer should be performed. It should always be increased whenever a change is made to the zone data. DNS NOTIFY must be enabled on the master authoritative name server.

Checks

Note: Due to the manner in which Active Directory replication increments SOA records for zones when transferring zone information via AD replication, this check is not applicable for AD-integrated zones.

Log on to the DNS server hosting a non-AD-integrated zone using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Review the SOA information for the zone and obtain the Serial Number.

Access each secondary name server for the same zone and review the SOA information.

Verify the Serial Number is the same on all authoritative name servers.

If the Serial Number is not the same on one or more authoritative name servers, this is a finding.

Fix

If all DNS servers are AD-integrated, troubleshoot why and mitigate the replication is not taking place to the out-of-sync secondary name servers.

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Initiate a zone transfer to all secondary name servers for the zone.
V-58603 No Change
Findings ID: WDNS-CM-000016 Rule ID: SV-83275r1_rule Severity: medium CCI: CCI-000366

Discussion

Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients.

External clients need to receive RRs that pertain only to public services (public Web server, mail server, etc.)

Internal clients need to receive RRs pertaining to public services as well as internal hosts.

The zone information that serves the RRs on both the inside and the outside of a firewall should be split into different physical files for these two types of clients (one file for external clients and one file for internal clients).

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

For each zone, review the records.

If any RRs (Resource Records) on an internal DNS server resolve to IP addresses located outside the internal DNS server's network, this is a finding.

If any RRs (Resource Records) on an external DNS server resolve to IP addresses located inside the network, this is a finding.

Fix

Remove any RRs from the internal zones for which the resolution is for an external IP address.

Remove any RRs from the external zones for which the resolution is for an internal IP address.
V-58605 No Change
Findings ID: WDNS-CM-000017 Rule ID: SV-83277r1_rule Severity: medium CCI: CCI-000366

Discussion

Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers.

One set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (Web servers that serve external Web pages or provide B2C services, mail servers, etc.)

The other set, called internal name servers, is to be located within the firewall and should be configured so they are not reachable from outside and hence provide naming services exclusively to internal clients.

Checks

Consult with the System Administrator to review the external Windows 2008 DNS Server's HBSS firewall policy.

The inbound TCP and UDP ports 53 rule should be configured to only restrict IP addresses from the internal network.

If the HBSS firewall policy is not configured with the restriction, consult with the network firewall administrator to confirm the restriction on the network firewall.

If neither the DNS server's HBSS firewall policy nor the network firewall is configured to block internal hosts from querying the external DNS server, this is a finding.

Fix

Configure the external DNS server's firewall policy, or the network firewall, to block queries from internal hosts.
V-58607 No Change
Findings ID: WDNS-CM-000018 Rule ID: SV-83279r1_rule Severity: medium CCI: CCI-000366

Discussion

Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers.

One set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (Web servers that serve external Web pages or provide B2C services, mail servers, etc.)

The other set, called internal name servers, is to be located within the firewall and should be configured so they are not reachable from outside and hence provide naming services exclusively to internal clients.

Checks

Consult with the System Administrator to review the internal Windows 2008 DNS Server's HBSS firewall policy.

The inbound TCP and UDP ports 53 rule should be configured to only allow hosts from the internal network to query the internal DNS server.

If the HBSS firewall policy is not configured with the restriction, consult with the network firewall administrator to confirm the restriction on the network firewall.

If neither the DNS server's HBSS firewall policy nor the network firewall is configured to block external hosts from querying the internal DNS server, this is a finding.

Fix

Configure the internal DNS server's firewall policy, or the network firewall, to block queries from external hosts.
V-58609 No Change
Findings ID: WDNS-CM-000019 Rule ID: SV-83281r1_rule Severity: medium CCI: CCI-000366

Discussion

Authoritative name servers (especially primary name servers) should be configured with an allow-transfer access control sub statement designating the list of hosts from which zone transfer requests can be accepted. These restrictions address the denial-of-service threat and potential exploits from unrestricted dissemination of information about internal resources. Based on the need-to-know, the only name servers that need to refresh their zone files periodically are the secondary name servers. Zone transfer from primary name servers should be restricted to secondary name servers. The zone transfer should be completely disabled in the secondary name servers. The address match list argument for the allow-transfer sub statement should consist of IP addresses of secondary name servers and stealth secondary name servers.

Checks

Verify whether the authoritative primary name server is AD-integrated.

Verify whether all secondary name servers for every zone for which the primary name server is authoritative are all AD-integrated in the same Active Directory.

If the authoritative primary name server is AD-integrated and all secondary name servers also part of the same AD, this check is not a finding since AD handles the replication of DNS data.

If one or more of the secondary name servers are non-AD integrated, verify the primary name server is configured to only send zone transfers to a specific list of secondary name servers.

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Right-click the zone and select “Properties”.

Select the “Zone Transfers” tab.

If the "Allow zone transfers:" check box is not selected, this is not a finding.

If the "Allow zone transfers:" check box is selected, verify either "Only to servers listed on the Name Server tab" or "Only to the following servers" is selected.

If the "To any server" option is selected, this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Right-click the zone and select “Properties”.

Select the "Zone Transfers" tab.

Select the "Only to servers listed on the Name Server tab" or "Only to the following servers" check box or deselect the "Allow zone transfers" check box.

Click “OK”.
V-58611 No Change
Findings ID: WDNS-CM-000020 Rule ID: SV-83283r1_rule Severity: medium CCI: CCI-000366

Discussion

Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.

The primary objective of DNS authentication and access control is the integrity of DNS records; only authorized personnel must be able to create and modify resource records, and name servers should only accept updates from authoritative master servers for the relevant zones. Integrity is best assured through authentication and access control features within the name server software and the file system the name server resides on. In order to protect the zone files and configuration data, which should only be accessed by the name service or an administrator, access controls need to be implemented on files, and rights should not be easily propagated to other users. Lack of a stringent access control policy places the DNS infrastructure at risk to malicious persons and attackers, in addition to potential denial of service to network resources.

DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. DAC models have the potential for the access controls to propagate without limit, resulting in unauthorized access to said objects.

When applications provide a DAC mechanism, the DNS implementation must be able to limit the propagation of those access rights.

Checks

In an Active Directory-integrated DNS implementation, this is not a finding by virtue of being compliant with the Windows 2008 AD STIG since DNS data within an AD-integrated zone is kept within the Active Directory.

For a file-back Windows DNS implementation, log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select each zone.

Right-click each zone and select “Properties”.

Select the “Security” tab.

Review the permissions applied to the zone. No group or user should have greater than READ privileges other than the DNS Admins and the System service account under which the DNS Server Service is running.

If any other account/group has greater than READ privileges, this is a finding.

Fix

For a file-back Windows DNS implementation, log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select each zone.

Right-click each zone and select “Properties”.

Select the “Security” tab.

Downgrade to READ privileges assigned to any group or user which has greater than READ privileges.
V-58613 No Change
Findings ID: WDNS-CM-000021 Rule ID: SV-83285r1_rule Severity: medium CCI: CCI-000366

Discussion

DNS servers with an internal role only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks, including the Internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization using address ranges, explicit access control lists, etc. In order to protect internal DNS resource information, it is important to isolate the requests to internal DNS servers. Separating internal and external roles in DNS prevents address space that is private (e.g., 10.0.0.0/24) or is otherwise concealed by some form of Network Address Translation from leaking into the public DNS system.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, review each zone.

Consult with the DNS Admin to determine if any of the zones also have hostnames needing to be resolved from the external network.

If the zone is split between internal and external networks, verify separate DNS servers have been implemented for each network.

If internal and external DNS servers have not been implemented for zones which require resolution from both the internal and external networks, this is a finding.

Fix

Configure separate DNS servers for each of the external and internal networks.
V-58615 No Change
Findings ID: WDNS-CM-000022 Rule ID: SV-83287r1_rule Severity: medium CCI: CCI-000366

Discussion

All caching name servers must be authoritative for the root zone because, without this starting point, they would have no knowledge of the DNS infrastructure and thus would be unable to respond to any queries. The security risk is that an adversary could change the root hints and direct the caching name server to a bogus root server. At that point, every query response from that name server is suspect, which would give the adversary substantial control over the network communication of the name servers' clients. When authoritative servers are sent queries for zones that they are not authoritative for, and they are configured as a non-caching server (as recommended), they can either be configured to return a referral to the root servers or they can be configured to refuse to answer the query. The recommendation is to configure authoritative servers to refuse to answer queries for any zones for which they are not authoritative. This is more efficient for the server and allows it to spend more of its resources doing what its intended purpose is, answering authoritatively for its zone.

Checks

Note: If the Windows DNS server is in the classified network, this check is Not Applicable.

Log on to the authoritative DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

Right-click the DNS server, select “Properties”.

Select the "Root Hints" tab.

Verify the "Root Hints" is either empty or only has entries for internal zones under "Name servers:". All Internet root server entries must be removed.

If "Root Hints" is not empty and the entries on the "Root Hints" tab under "Name servers:" are external to the local network, this is a finding.

Fix

Log on to the authoritative DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

Right-click the DNS server, select “Properties”.

Select the "Root Hints" tab.

Remove all entries under "Name servers:" which are for name servers outside of the internal network.
V-58617 No Change
Findings ID: WDNS-CM-000023 Rule ID: SV-83289r1_rule Severity: medium CCI: CCI-000366

Discussion

Each newer version of the name server software, especially the BIND software, generally is devoid of vulnerabilities found in earlier versions because it has design changes incorporated to take care of those vulnerabilities. These vulnerabilities have been exploited (i.e., some form of attack was launched), and sufficient information has been generated with respect to the nature of those exploits. It makes good business sense to run the latest version of name server software because theoretically it is the safest version. Even if the software is the latest version, it is not safe to run it in default mode. The security administrator should always configure the software to run in the recommended secure mode of operation after becoming familiar with the new security settings for the latest version.

Checks

Consult with the network IAVM scanner to confirm all Microsoft Operating System IAVMs applicable to Windows 2008/2008 R2 have been applied to the DNS server.

If the Windows Operating System has not been patched to handle all IAVMs, this is a finding.

Fix

Apply all related Microsoft Operating System IAVM patches to the DNS server.
V-58621 No Change
Findings ID: WDNS-CM-000025 Rule ID: SV-83291r1_rule Severity: medium CCI: CCI-000366

Discussion

The use of CNAME records for exercises, tests, or zone-spanning aliases should be temporary (e.g., to facilitate a migration). When a host name is an alias for a record in another zone, an adversary has two points of attack: the zone in which the alias is defined and the zone authoritative for the alias's canonical name. This configuration also reduces the speed of client resolution because it requires a second lookup after obtaining the canonical name. Furthermore, in the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers and thus compounds the vulnerability.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Review the RRs to confirm that there are no CNAME records older than 6 months.

The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated (AO approval of use of a commercial cloud offering would satisfy this requirement). Additional exceptions are CNAME records in a multi-domain Active Directory environment pointing to hosts in other internal domains in the same multi-domain environment.

If there are zone-spanning CNAME records older than 6 months and the CNAME records resolve to anything other than fully qualified domain names for glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms with an AO-approved and documented mission need, this is a finding.

Fix

Remove any zone-spanning CNAME records that have been active for more than six months, which are not supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms.

In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated (AO approval of use of a commercial cloud offering would satisfy this requirement).
V-58623 No Change
Findings ID: WDNS-CM-000026 Rule ID: SV-83293r1_rule Severity: medium CCI: CCI-000366

Discussion

IPv6 link-local scope addresses are not globally routable and must not be configured in any DNS zone. Similar to RFC1918 addresses, if a link-local scope address is inserted into a zone provided to clients, most routers will not forward this traffic beyond the local subnet.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Expand the Forward Lookup Zones folder.

Expand each zone folder and examine the host record entries. The third column titled “Data” will display the IP.

Verify this column does not contain any IP addresses that begin with the prefixes "FE8", "FE9", "FEA", or "FEB".

If any non-routable IPv6 link-local scope addresses are in any zone, this is a finding.

Fix

The SA should remove any link-local addresses and replace with appropriate Site-Local or Global scope addresses.
V-58625 No Change
Findings ID: WDNS-CM-000027 Rule ID: SV-83295r1_rule Severity: medium CCI: CCI-000366

Discussion

DNS is only responsible for resolving a domain name to an IP address. Applications and operating systems are responsible for processing the IPv6 or IPv4 record that may be returned. With this in mind, a denial of service could easily be implemented for an application that is not IPv6-aware. When the application receives an IP address in hexadecimal, it is up to the application/operating system to decide how to handle the response. Combining both IPv6 and IPv4 records into the same domain can lead to application problems that are beyond the scope of the DNS administrator.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, select each zone and examine the host record entries. The third column titled “Data” will display the IP.

Verify if any contain both IPv4 and IPv6 addresses.

If any hostnames contain both IPv4 and IPv6 addresses, confirm with the SA that the actual hosts are IPv6-aware.

If any zone contains hosts with both IPv4 and IPv6 addresses but are determined to be non-IPv6-aware, this is a finding.

Fix

Remove any IPv6 records for hosts which are not IPv6-aware.
V-58627 Updated
Findings ID: WDNS-CM-000028 Rule ID: SV-83297r12_rule Severity: medium CCI: CCI-000366

Discussion

To prevent the possibility of a denial of service in relation to an IPv4 DNS server trying to respond to IPv6 requests, the server should be configured not to listen on any of its IPv6 interfaces unless it does contain IPv6 AAAA resource records in one of the zones.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Locate the “Network Internet Access” icon, right-click on it and select "Open Network & Sharing Center".

Click on "Change adapter settings".

Right-click on the Ethernet and click “Properties”.

If the display shows Microsoft TCP/IP version 6 with a check, but the DNS server is not hosting any AAAA records, this is a finding.

Fix

Uninstall IPv6 from any LAN interface that is not hosting IPv6 AAAA records within its zones.Log onto the DNS server.

Access Group Policy Management.

Edit Default Domain Policy, go to Computer Configuration >> Policies >> Administrative Templates >> Network >> IPv6 Configuration, Open IPv6 Configuration Policy and set on “sisable all IP 6 coonenest.
V-58633 No Change
Findings ID: WDNS-IA-000002 Rule ID: SV-83211r2_rule Severity: medium CCI: CCI-000778

Discussion

Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. This applies to server-to-server (zone transfer) transactions only and is provided by TSIG/SIG(0), which enforces mutual server authentication using a key that is unique to each server pair (TSIG) or using PKI-based authentication (SIG(0)), thus uniquely identifying the other server.

TSIG and SIG(0) are not configurable in Windows 2008 DNS Server.

To meet the requirement for authentication between Windows DNS servers, IPsec will be implemented between the Windows DNS servers which host any non-AD-integrated zones.
TSIG and SIG(0) are not configurable in Windows 2012 DNS Server.

To meet the requirement for authentication between Windows DNS servers, IPsec will be implemented between the Windows DNS servers which host any non-AD-integrated zones.

Checks

Note: This requirement applies to any Windows 2008 DNS Server which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too.

If the Windows 2008 DNS Servers only host AD-integrated zones, this requirement is not applicable.

Log on to the DNS server which hosts non-AD-integrated zones using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute gpme.msc to open the Group Policy Management feature.

In the “Browse for Group Policy Object” dialog box, double-click “Domain Controllers.domain.com”.

Click “Default Domain Controllers Policy” and click “OK”.

In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security - LDAP.

Click “Connection Security Rules”.

Confirm at least one rule is configured for TCP 53.

Double-click on each Rule to verify the following:

On the “Authentication” tab, "Authentication mode:" is set to "Request authentication for inbound and outbound connections".

Confirm the "Signing Algorithm" is set to "RSA (default)".

On the “Remote Computers” tab, Endpoint1 and Endpoint2 are configured with the IP addresses of all DNS servers.

On the “Protocols and Ports” tab, "Protocol type:" is set to either TCP (depending upon which rule is being reviewed) and the "Endpoint 1 port:" is set to "Specific ports" and "53".

If there are not rules(s) configured with the specified requirements, this is a finding.

Fix

Complete the following procedures twice for each pair of name servers.

First create a rule for TCP connections.

Refer to the U_Windows_Domain_Name_Service_2008_Overview.pdf for Microsoft links for this procedure.

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute gpme.msc to open the Group Policy Management feature.

In the Browse for “Group Policy Object” dialog box, double-click “Domain Controllers.domain.com”.

Click “Default Domain Controllers Policy” and click “OK”.

In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security - LDAP.

Right-Click “Connection Security Rules” and select “New”.

For Rule Type, select the "Server-to-server" radio button, click “Next”.

For Endpoint 1 and Endpoint 2, select "These IP addresses:" and add the IP addresses of all DNS servers, click “Next”.

For Requirements, select "Request authentication for inbound and outbound connections", click “Next”.

For Authentication Method, select Computer certificate and from the "Signing Algorithm:" drop-down, select "RSA (default)".

From the "Certificate store type:" drop-down, select "Root CA (default)”.

From the "CA name:", click “Browse” and select the certificate for the CA, click “Next”.

On Profile, accept default selections, click “Next”.

On Name, enter a name applicable to the rule's function, click “Finish”.
V-58637 No Change
Findings ID: WDNS-IA-000004 Rule ID: SV-83197r1_rule Severity: medium CCI: CCI-001958

Discussion

Primary name servers also make outbound connection to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to only be made to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the master zone server and result in DoS to legitimate users.

AD-integrated DNS servers replicate zone information via AD replication. Non-AD-integrated DNS servers replicate zone information via zone transfers.

Checks

If the DNS server only hosts AD-integrated zones and there are not any non-AD-integrated DNS servers acting as secondary DNS servers for the zones, this check is not applicable.

For a non-AD-integrated DNS server:

Log on to the DNS server using an Administrator account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select, and then right-click the zone name.

From the displayed context menu, click the “Properties” option.

On the opened zone's properties box, go to the “Zone Transfers” tab.

On the displayed interface, verify if the "Allow zone transfers" check box is selected.

If the "Allow zone transfers" check box is not selected, this is not a finding.

If the "Allow zone transfers" check box is selected, verify that either the "Only to servers listed on the Name Servers tab" radio button is selected or the "Only to the following servers" radio button is selected.

If the "To any server" radio button is selected, this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

From the displayed context menu, click the “Properties” option.

On the opened zone's properties box, go to the “Zone Transfers” tab.

On the displayed interface, select the "Allow zone transfers" check box.

Select the "Only to servers listed on the Name Servers tab" radio button OR select the "Only to the following servers" radio button.

Click on “Apply”.

Click on “OK”.
V-58641 No Change
Findings ID: WDNS-IA-000006 Rule ID: SV-83207r1_rule Severity: medium CCI: CCI-000186

Discussion

The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.

SIG(0) is used for server-to-server authentication for DNS transactions, and it uses PKI-based authentication. So, in cases where SIG(0) is being used instead of TSIG (which uses a shared key, not PKI-based authentication), this requirement is applicable.

Checks

Access Windows Explorer.

Navigate to the following location:

%ALLUSERSPROFILE%\Microsoft\Crypto

Verify the permissions on the keys folder, sub-folders, and files are limited to SYSTEM and Administrators FULL CONTROL.

If any other user or group has greater than READ privileges to the %ALLUSERSPROFILE%\Microsoft\Crypto folder, sub-folders and files, this is a finding.

Fix

Access Windows Explorer.

Navigate to the following location:

%ALLUSERSPROFILE%\Microsoft\Crypto

Modify permissions on the keys folder, sub-folders, and files to be limited to SYSTEM and Administrators FULL CONTROL and to all other Users/Groups to READ.
V-58643 No Change
Findings ID: WDNS-IA-000007 Rule ID: SV-83209r2_rule Severity: medium CCI: CCI-000186

Discussion

To enable dnssec (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key can also be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by the dnscmd key generation utility used with DNSSEC is Base64-encoded.

Checks

Access Services on the Windows DNS Server and locate the DNS Server Service.

Determine the account under which the DNS Server Service is running.

Access Windows Explorer.

Navigate to the following location:

%ALLUSERSPROFILE%\Microsoft\Crypto

Right-click on each sub-folder, choose “Properties”, click on the “Security” tab, and click on the “Advanced” button.

Verify the Owner on the folder, sub-folders, and files are the account under which the DNS Server Service is running.

If any other user or group is listed as OWNER of the %ALLUSERSPROFILE%\Microsoft\Crypto folder, sub-folders, and files, this is a finding.

Fix

Access Windows Explorer.

Navigate to the following location:

%ALLUSERSPROFILE%\Microsoft\Crypto

Right-click on each sub-folder, choose “Properties”, click on the “Security” tab, and click on the “Advanced” button.

Click on "Change" next to the listed Owner and change to be the account under which the DNS Server Service is running.
V-58649 No Change
Findings ID: WDNS-IA-000011 Rule ID: SV-83241r1_rule Severity: medium CCI: CCI-001991

Discussion

Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates).

SIG(0) is used for server-to-server authentication for DNS transactions, and it uses PKI-based authentication. So, in cases where SIG(0) is being used instead of TSIG (which uses a shared key, not PKI-based authentication), this requirement is applicable.

Checks

Consult with the SA to determine if there is a third-party CRL server being used for certificate revocation lookup.

If there is, verify if a documented procedure is in place to store a copy of the CRL locally (local to the site, as an alternative to querying the actual Certificate Authorities). An example would be an OCSP responder installed at the local site.

If there is no local cache of revocation data, this is a finding.

Fix

Configure local revocation data to be used in the event access to Certificate Authorities is hindered.
V-58655 No Change
Findings ID: WDNS-SC-000003 Rule ID: SV-83243r2_rule Severity: medium CCI: CCI-000366

Discussion

The major threat associated with DNS forged responses or failures are the integrity of the DNS data returned in the response. By requiring remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service, data origin is validated.

Ensuring all name servers have static IP addresses makes it possible to configure restricted DNS communication between the name servers.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Locate the “Network Internet Access” icon, right-click on it and select "Open Network & Sharing Center".

Click on "Change adapter settings".

Right-click on the Ethernet and click “Properties”.

Select Internet Protocol Version 4 (TCP/IPv4) and click “Properties”.

Verify the “Use the following IP address” is selected, with an IP address, subnet mask, and default gateway assigned.

If the “Use the following IP address” is not selected with a configured IP address, subnet mask, and default gateway, this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Locate the “Network Internet Access” icon, right-click on it and select "Open Network & Sharing Center".

Click on "Change adapter settings".

Right-click on the Ethernet and click “Properties”.

Select Internet Protocol Version 4 (TCP/IPv4) and click “Properties”.

Select the “Use the following IP address” and populate with an IP address, subnet mask, and default gateway.
V-58661 No Change
Findings ID: WDNS-SC-000006 Rule ID: SV-83245r2_rule Severity: medium CCI: CCI-002462

Discussion

The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. If/when WINS lookups are enabled, the validity of the data becomes questionable since the WINS data is provided to the requestor, unsigned and invalidated. A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, right-click each zone, and then click “Properties”.

In the “Properties” dialog box for the zone, click the “WINS” tab.

Verify the "Use WINS forward lookup" check box is not selected.

If the "Use WINS forward lookup" check box is selected, this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, right-click each zone, and then click “Properties”.

In the “Properties” dialog box for the zone, click the “WINS” tab.

Uncheck the "Use WINS forward" lookup check box.

Click “OK”.
V-58693 No Change
Findings ID: WDNS-SC-000024 Rule ID: SV-83215r1_rule Severity: medium CCI: CCI-001199

Discussion

Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and non-volatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use.

The DNS server must protect the confidentiality and integrity of shared keys (for TSIG) and private keys (for SIG(0)) and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.

Checks

To ensure the cryptographic keys are protected after being backed up to another medium (tape, disk, SAN, etc.), consult with the System Administrator to determine the backup policy in place for the DNS Server.

Determine how and where backed up data is being stored.

Verify the protection of the backup medium is secured to the same level, or higher, as the server itself.

If a backup policy does not exist or the backup policy does not specify the protection required for backup medium to be at or above the same level as the server, this is a finding.

Fix

To ensure the cryptographic keys are protected after being backed up to tape or other medium, develop a backup policy to include the protection of backup date to be at or above the same level as the DNS server itself.
V-58695 No Change
Findings ID: WDNS-SC-000025 Rule ID: SV-83247r1_rule Severity: medium CCI: CCI-002475

Discussion

If zone information has not been validated in over a year, then there is no assurance that it is still valid. If invalid records are in a zone, then an adversary could potentially use their existence for improper purposes. An SOP detailing this process can resolve this requirement.

Checks

This requirement is not applicable for a Windows 2008 DNS Server which is only hosting AD-integrated zones.

For a Windows 2008 DNS Server which hosts a mix of AD-integrated zones and manually maintained zones, ask the DNS database administrator if they maintain a separate database with record documentation for the non-AD-integrated zone information. The reviewer should check that the record's last verified date is less than one year prior to the date of the review.

If a separate database with record documentation is not maintained for the non-AD-integrated zone information, this is a finding.

If a separate database with record documentation is maintained for the non-AD-integrated zone information, log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Review the zone records of the non-AD-integrated zones and compare to the separate documentation maintained.

Determine if any records have not been validated in over a year.

If zone records exist which have not been validated in over a year, this is a finding.

Fix

Create a separate database to maintain record documentation for non-AD-integrated zones.

Develop a procedure to validate annually all zone information on the DNS server against the separately maintained database.

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Select the zone records which have not been validated in over a year and revalidate.
V-58697 No Change
Findings ID: WDNS-SC-000026 Rule ID: SV-83217r1_rule Severity: medium CCI: CCI-001094

Discussion

Applications and application developers must take the steps needed to ensure users cannot use an authorized application to launch DoS attacks against other systems and networks. For example, applications may include mechanisms that throttle network traffic so users are not able to generate unlimited network traffic via the application. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks.

Checks

Review the DNS server to confirm the server restricts direct and remote console access to users other than Administrators.

Verify the effective setting in Local Group Policy Editor.

Run "gpedit.msc".

Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

If any accounts or groups other than the following are granted the "Allow log on through Remote Desktop Services" user right, this is a finding:

Administrators

Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

If the following accounts or groups are not defined for the "Deny access to this computer from the network" user right, this is a finding:

Guests Group

Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.

If the following accounts or groups are not defined for the "Deny log on locally" user right, this is a finding:

Guests Group

Fix

Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Allow log on through Remote Desktop Services" to only include the following accounts or groups:

Administrators

Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Deny access to this computer from the network" to include the following:

Guests Group

Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> "Deny log on locally" to include the following:

Guests Group
V-58699 No Change
Findings ID: WDNS-SC-000027 Rule ID: SV-83219r1_rule Severity: medium CCI: CCI-001095

Discussion

In the case of application DoS attacks, care must be taken when designing the application to ensure the application makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

In the list of hosts, review the Name Server (NS) records. Determine if any of the hosts listed as NS records are non-AD-integrated servers.

If the DNS server only hosts AD-integrated zones and there are not any non-AD-integrated DNS servers acting as secondary DNS servers for the zones, this check is not applicable.

For a non-AD-integrated DNS server, right click on the Forward Lookup zone and select “Properties”.
On the opened zone's properties box, go to the “Zone Transfers” tab.

On the displayed interface, verify if the "Allow zone transfers" check box is selected.

If the "Allow zone transfers" check box is selected, click on the “Notify” button and verify “Automatically notify with Servers” is listed on the “Name Servers” tab is selected.

If the “Notify” button is not enabled for non-AD-integrated DNS servers, this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

In the list of hosts, review the Name Server (NS) records. Determine if any of the hosts listed as NS records are non-AD-integrated servers.

If the DNS server only hosts AD-integrated zones and there are not any non-AD-integrated DNS servers acting as secondary DNS servers for the zones, this check is Not Applicable.

For a non-AD-integrated DNS server, log on to the DNS server using the Domain Admin or Enterprise Admin account.

On the opened DNS Manager snap-in from the left pane, expand the server name and then expand Forward Lookup Zones.

From the expanded list, click to select and then right-click the zone name.

From the displayed context menu, click the “Properties” option.

On the opened zone's properties box, go to the “Zone Transfers” tab.

On the displayed interface, verify if the "Allow zone transfers" check box is selected.

If the "Allow zone transfers" check box is selected, click on the “Notify” button and enable Notify to the non-AD-integrated DNS servers.
V-58707 No Change
Findings ID: WDNS-SI-000001 Rule ID: SV-83221r1_rule Severity: medium CCI: CCI-001310

Discussion

DNS zone data for which a Windows 2008 DNS server is authoritative should represent the network for which it is responsible. If a Windows 2008 DNS server hosts zone records for other networks or environments, there is the possibility for the records to become invalid or stale or be redundant/conflicting with a DNS server truly authoritative for the other network environment.

Checks

Consult with the System Administrator to determine the IP ranges for the environment.

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

If not automatically started, initialize the “Server Manager” window by clicking its icon from the bottom left corner of the screen.

Once the “Server Manager” window is initialized, from the left pane, click to select the DNS category.

From the right pane, under the “SERVERS” section, right-click the DNS server.

From the context menu that appears, click DNS Manager.

On the opened DNS Manager snap-in from the left pane, expand the server name and then expand Forward Lookup Zones.

From the expanded list, click to select and then right-click the zone name.

Review the zone information and compare to the IP ranges for the environment.

If any zone information is for a different IP range or domain, this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

If not automatically started, initialize the “Server Manager” window by clicking its icon from the bottom left corner of the screen.

Once the “Server Manager” window is initialized, from the left pane, click to select the DNS category.

From the right pane, under the “SERVERS” section, right-click the DNS server.

From the context menu that appears, click DNS Manager.

On the opened DNS Manager snap-in from the left pane, expand the server name and then expand Forward Lookup Zones.

Remove any zone information which is not part of the environment.
V-58709 No Change
Findings ID: WDNS-SI-000002 Rule ID: SV-83249r2_rule Severity: medium CCI: CCI-002754

Discussion

Failing to an unsecure condition negatively impacts application security and can lead to system compromise. Failure conditions include, for example, loss of communications among critical system components or between system components and operational facilities. Fail-safe procedures include, for example, alerting operator personnel and providing specific instructions on subsequent steps to take (e.g., do nothing, reestablish system settings, shutdown processes, restart the system, or contact designated organizational personnel).

Transactions such as zone transfers would not be able to work correctly anyway in this state.

Checks

Active Directory integrated DNS servers will handle the promotion of a secondary DNS server whenever a primary DNS server loses functionality.

If all of the DNS servers are AD-integrated, this is not a finding.

Consult with the System Administrator to determine if there are documented procedures for re-roling a non-AD-integrated secondary name server to a master name server role in the event a master name server loses functionality.

If there is not any documented procedures for re-roling a non-AD-integrated secondary name server to primary in the event a master name server loses functionality, this is a finding.

Fix

Active Directory-integrated DNS servers will handle the promotion of a secondary DNS server whenever a primary DNS server loses functionality.

Develop, test, and implement documented procedures for re-roling a non-AD-integrated secondary name server to a master name server role in the event a master name server loses functionality.
V-58711 No Change
Findings ID: WDNS-SI-000005 Rule ID: SV-83223r2_rule Severity: medium CCI: CCI-000366

Discussion

Predictable failure prevention requires organizational planning to address system failure issues. If components key to maintaining systems security fail to function, the system could continue operating in an insecure state. The organization must be prepared, and the application must support requirements that specify if the application must alarm for such conditions and/or automatically shut down the application or the system.

This can include conducting a graceful application shutdown to avoid losing information. Automatic or manual transfer of components from standby to active mode can occur, for example, upon detection of component failures.

Checks

Notification to system administrator is not configurable in Windows 2008. In order for system administrators to be notified when a component fails, the system administrator would need to implement a third-party monitoring system. At a minimum, the system administrator should have a documented procedure in place to review the diagnostic logs on a routine basis every day.

If a third-party monitoring system is not in place to detect and notify the system administrator upon component failures and the system administrator does not have a documented procedure in place to review the diagnostic logs on a routine basis every day, this is a finding.

Fix

Implement a third-party monitoring system to detect and notify the system administrator upon component failure or, at a minimum, document and implement a procedure to review the diagnostic logs on a routine basis every day.
V-58713 No Change
Findings ID: WDNS-SI-000006 Rule ID: SV-83251r1_rule Severity: medium CCI: CCI-000366

Discussion

Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Without verification, security functions may not operate correctly and this failure may go unnoticed.

Notifications provided by information systems include, for example, electronic alerts to system administrators, messages to local computer consoles, and/or hardware indications, such as lights.

The DNS server should perform self-tests, such as at server start-up, to confirm that its security functions are working properly.

Checks

This functionality should be performed by the Host Based Security System (HBSS), mandatory on all DoD systems.

Check to ensure McAfee HBSS is installed and fully operational on the Windows 2008 DNS Server.

If all required HBSS products are not installed and/or the installed products are not enabled, this is a finding.

Fix

Follow the HBSS guidance to install all HBSS products to the Windows 2008 DNS server.
V-58717 No Change
Findings ID: WDNS-SI-000008 Rule ID: SV-83225r1_rule Severity: medium CCI: CCI-001294

Discussion

Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. If personnel are not notified of failed security verification tests, they will not be able to take corrective action and the unsecure condition(s) will remain. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights.

The DNS server should be configured to generate audit records whenever a self-test fails. The OS/NDM is responsible for generating notification messages related to this audit record.

Checks

Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network.

Notification to system administrator is not configurable in Windows 2008. In order for ISSO/ISSM/DNS administrator to be notified if functionality of Secure Updates has been removed or broken, the ISSO/ISSM/DNS administrator would need to implement a third party monitoring system. At a minimum, the ISSO/ISSM/DNS administrator should have a documented procedure in place to review the diagnostic logs on a routine basis every day.

If a third party monitoring system is not in place to detect and notify the ISSO/ISSM/DNS administrator if functionality of Secure Updates has been removed or broken and the ISSO/ISSM/DNS administrator does not have a documented procedure in place to review the diagnostic logs on a routine basis every day, this is a finding.

Fix

Implement a third-party monitoring system to detect and notify the ISSO/ISSM/DNS administrator if functionality of Secure Updates has been removed or broken or, at a minimum, document and implement a procedure to review the diagnostic logs on a routine basis every day.
V-58737 No Change
Findings ID: WDNS-SI-000003 Rule ID: SV-83227r1_rule Severity: medium CCI: CCI-001312

Discussion

Each newer version of the name server software, especially the BIND software, generally is devoid of vulnerabilities found in earlier versions because it has design changes incorporated to take care of those vulnerabilities. Of course, these vulnerabilities have been exploited (i.e., some form of attack was launched), and sufficient information has been generated with respect to the nature of those exploits. Thus, it makes good business sense to run the latest version of name server software because theoretically it is the safest version.

In some installations, it may not be possible to switch over to the latest version of name server software immediately. If the version of the name server software is revealed in queries, this information may be used by attackers who are looking for a specific version of the software which has a discovered weakness. To prevent information about which version of name server software is running on a system, name servers should be configured to refuse queries for its version information.

Checks

The "EnableVersionQuery" property controls what version information the DNS server will respond with when a DNS query with class set to “CHAOS” and type set to “TXT” is received.

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Open a command window and execute the command:

nslookup <enter>
Note: Confirm the Default Server is the DNS Server on which the command is being run.

At the nslookup prompt, type:

set type=TXT <enter>
set class=CHAOS <enter>
version.bind <enter>

If the response returns something similar to text = "Microsoft DNS 6.1.7601 (1DB14556)", this is a finding.

Fix

To disable the version being returned in queries, execute the following command:

dnscmd /config /EnableVersionQuery 0 <enter>
V-58739 No Change
Findings ID: WDNS-SI-000004 Rule ID: SV-83229r1_rule Severity: medium CCI: CCI-001312

Discussion

There are several types of RRs in the DNS that are meant to convey information to humans and applications about the network, hosts, or services. These RRs include the Responsible Person (RP) record, the Host Information (HINFO) record, the Location (LOC) record, and the catch-all text string resource record (TXT) [RFC1035]. Although these record types are meant to provide information to users in good faith, they also allow attackers to gain knowledge about network hosts before attempting to exploit them. For example, an attacker may query for HINFO records, looking for hosts that list an OS or platform known to have exploits.

Therefore, great care should be taken before including these record types in a zone. In fact, they are best left out altogether.

More careful consideration should be taken with the TXT resource record type. A DNS administrator will have to decide if the data contained in a TXT RR constitutes an information leak or is a necessary piece of information. For example, several authenticated email technologies use TXT RR's to store email sender policy information such as valid email senders for a domain. These judgments will have to be made on a case-by-case basis.

A DNS administrator should take care when including HINFO, RP, TXT, LOC, or other RR types that could divulge information that would be useful to an attacker or the external view of a zone if using split DNS.

RRs such as HINFO and TXT provide information about software name and versions (e.g., for resources such as Web servers and mail servers) that will enable the well-equipped attacker to exploit the known vulnerabilities in those software versions and launch attacks against those resources.

Checks

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Review the zone's Resource Records (RR) and verify HINFO, RP, and LOC RRs are not used. If TXT RRs are used, they must not reveal any information about the organization which could be used for malicious purposes.

If there are any HINFO, RP, LOC, or revealing TXT RRs in any zone hosted by the DNS Server, this is a finding.

Fix

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones.

From the expanded list, click to select the zone.

Remove all HINFO, RP, TXT, and LOC RRs from all zones hosted by the DNS Server.