diff --git a/CHANGELOG.md b/CHANGELOG.md index 1474128d1..eeeef4c88 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,7 @@ ## [Unreleased] +* Update PowerSTIG to successfully parse/apply Microsoft Windows 2012 Server DNS STIG - Ver 2, Rel 1: [#760](https://github.com/microsoft/PowerStig/issues/760) * Update PowerSTIG to successfully parse/apply Microsoft SQL Server 2016 Instance Version 2; Release 1: [#761](https://github.com/microsoft/PowerStig/issues/761) * Update PowerSTIG to successfully parse/apply Microsoft Outlook 2016 Version 2; Release 1: [#767](https://github.com/microsoft/PowerStig/issues/767) * Update spacing in DoD logon script: [#757](https://github.com/microsoft/PowerStig/issues/757) diff --git a/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V1R14_Manual-xccdf.log b/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V1R14_Manual-xccdf.log deleted file mode 100644 index 669877c99..000000000 --- a/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V1R14_Manual-xccdf.log +++ /dev/null @@ -1,4 +0,0 @@ -V-58553::Auditors (if the site has an Auditors group that further limits this privilege.)::Administrators Auditors (if the site has an Auditors group that further limits this privilege.) -V-58627::*::HardCodedRule(RegistryRule)@{DscResource = 'Registry'; Ensure = 'Present'; Key = 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters'; ValueData = $null; ValueName = 'DisabledComponents'; ValueType = 'DWord'; OrganizationValueTestString = 'ValueData is set to 255 which disables IPv6 '} -V-58641::Verify the Owner on the folder, sub-folders, and files are the account under which the DNS Server Service is running.::Verify the permissions on the folder, sub-folders, and files are the account under which the DNS Server Service is running. -V-58643::Verify the Owner on the folder, sub-folders, and files are the account under which the DNS Server Service is running.::Verify the permissions on the folder, sub-folders, and files are the account under which the DNS Server Service is running. diff --git a/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V1R14_Manual-xccdf.xml b/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V1R14_Manual-xccdf.xml deleted file mode 100644 index 01a3e75c0..000000000 --- a/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V1R14_Manual-xccdf.xml +++ /dev/null @@ -1,2980 +0,0 @@ -acceptedMicrosoft Windows 2012 Server Domain Name System Security Technical Implementation GuideThe Microsoft Windows 2012 Server Domain Name System 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: disa.stig_spt@mail.mil.DISASTIG.DOD.MILRelease: 14 Benchmark Date: 24 Apr 20201I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>SRG-APP-000001-DNS-000115<GroupDescription></GroupDescription>WDNS-AC-000001The Windows 2012 DNS Server must restrict incoming dynamic update requests to known clients.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000054Log 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.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.SRG-APP-000348-DNS-000042<GroupDescription></GroupDescription>WDNS-AU-000001The Windows 2012 DNS Server must be configured to record, and make available to authorized personnel, who added/modified/deleted DNS zone information.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366CCI-001902Log 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”.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.SRG-APP-000350-DNS-000044<GroupDescription></GroupDescription>WDNS-AU-000003The Windows 2012 DNS Server must, in the event of an error validating another DNS servers identity, send notification to the DNS administrator.<VulnDiscussion>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 DNS server should audit all failed attempts at server authentication through DNSSEC and TSIG/SIG(0). The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366CCI-001906To 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.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. -SRG-APP-000089-DNS-000004<GroupDescription></GroupDescription>WDNS-AU-000005The Windows 2012 DNS Server log must be enabled.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000169Log 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”.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.SRG-APP-000089-DNS-000005<GroupDescription></GroupDescription>WDNS-AU-000006The Windows 2012 DNS Server logging must be enabled to record events from all DNS server functions.<VulnDiscussion>DNS server performance can be affected when additional logging is enabled, however the enhanced DNS logging and diagnostics feature in Windows Server 2012 R2 is designed to have a very low impact on performance. Enhanced DNS logging and diagnostics in Windows Server 2012 R2 and later includes DNS Audit events and DNS Analytic events. DNS audit logs are enabled by default, and do not significantly affect DNS server performance. DNS analytical logs are not enabled by default and typically will only affect DNS server performance at very high DNS query rates. - -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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000169Log on to the DNS server using the Domain Admin or Enterprise Admin account. - -Open an elevated Windows PowerShell prompt on the DNS server to which event logging needs to be enabled. - -Use the “Set-DnsServerDiagnostics” cmdlet to enable the required diagnostic events. - -Set-DnsServerDiagnostics -<diagnostic event> $true <enter> for the required diagnostic events. -For example, to set EnableLoggingForLocalLookupEvent to true, enter the following at the command line: -Set-DnsServerDiagnostics -EnableLoggingForLocalLookupEvent $true <enter> -Log on to the DNS server using the Domain Admin or Enterprise Admin account. - -Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account. - -Use the “Get-DnsServerDiagnostics” cmdlet to view the status of individual diagnostic events. - -Verify following diagnostic events are set to "True": -Queries, Answers, Notifications, Update, QuestionTransactions, UnmatcheResponse, SendPackets, ReceivePackets, TcpPackets, UdpPackets, FullPackets, UseSystemEventLog -Also set to “True” should be: -EnableLoggingForLocalLookupEvent -EnableLoggingForPluginDLLEvent -EnableLoggingForRecursiveLookupEvent -EnableLoggingForRemoteServerEvent -EnableLoggingForRemoteServerEvent -EnableLoggingForServerStartStopEvent -EnableLoggingForTombstoneEvent -EnableLoggingForZoneDataWriteEvent -EnableLoggingForZoneLoadingEvent - -If all required diagnostic events are not set to "True", this is a finding. -SRG-APP-000090-DNS-000005<GroupDescription></GroupDescription>WDNS-AU-000007The Windows 2012 DNS Server logging criteria must only be configured by the ISSM or individuals appointed by the ISSM.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000171Configure 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.evtxVerify 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. -SRG-APP-000504-DNS-000082<GroupDescription></GroupDescription>WDNS-AU-000008The Windows 2012 DNS Server must generate audit records for the success and failure of all name server events.<VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000172Log 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”. - -For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on “Properties”. - -Select the "Enable logging" check box. - -Click on “OK”. -Log on to the DNS server using the Domain Admin or Enterprise Admin account. -Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account. - -Use the “Get-DnsServerDiagnostics” cmdlet to view the status of individual diagnostic events. - -Verify following diagnostic events are set to "True": -UseSystemEventLog - -Press “Windows Key + R”, execute “dnsmgmt.msc”. - -Right-click on the DNS server, select “Properties”. - -Click 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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run “eventvwr.msc” at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click on the DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click on Analytical and then click “Properties”. - -Confirm the "Enable logging" check box is selected. - -If the checkbox to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding. -SRG-APP-000514-DNS-000075<GroupDescription></GroupDescription>WDNS-SC-000031The Windows 2012 DNS Server must implement NIST FIPS-validated cryptography for provisioning digital signatures, generating cryptographic hashes, and protecting unclassified information requiring confidentiality.<VulnDiscussion>Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. - -The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) [FIPS186] provides three algorithm choices: -* Digital Signature Algorithm (DSA) -* RSA -* Elliptic Curve DSA (ECDSA). - -Of these three algorithms, RSA and DSA are more widely available and considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. RSA is the recommended algorithm as far as this guideline is concerned. - -RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e. RSA/SHA-256, ECDSA) are also specified. - -It can be expected that name servers and clients will be able to use the RSA algorithm at the minimum. It is suggested that at least one ZSK for a zone use the RSA algorithm. - -NIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in the NIST's DSS[FIPS186]. It is expected that there will be support for Elliptic Curve Cryptography in the DNSSEC. The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before September 30th, 2015.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002450Sign or re-sign, the hosted zone(s) on the DNS server being validated. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click “Sign the Zone”, either using approved saved parameters or approved custom parameters.Note: This requirement applies to any Windows DNS Server which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server only hosts AD-integrated zones and does not host any file-based zones, this is not applicable. -Validate this check from the Windows 2012 DNS server being configured/reviewed. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. - -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -Note: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000095-DNS-000006<GroupDescription></GroupDescription>WDNS-AU-000010The Windows 2012 DNS Server log must include event types within the log records.<VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000130Log on to the DNS server using the Domain Admin or Enterprise Admin account. - -Press Windows Key + R, execute dnsmgmt.msc. - -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. - -For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. -Select the "Enable logging" check box. - -Click on OK.Log on to the DNS server using the Domain Admin or Enterprise Admin account. - -Press Windows Key + R, execute dnsmgmt.msc. - -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. 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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding.SRG-APP-000096-DNS-000007<GroupDescription></GroupDescription>WDNS-AU-000011The Windows 2012 DNS Server log must include time stamps within the log records.<VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000131Log 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 on OK. - -For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Select the "Enable logging" check box. - -Click on OK.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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding.SRG-APP-000097-DNS-000008<GroupDescription></GroupDescription>WDNS-AU-000012The Windows 2012 DNS Server log must include origin of events within the log records.<VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000132Log 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 on OK. - -For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Select the "Enable logging" check box. - -Click on OK.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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding.SRG-APP-000098-DNS-000009<GroupDescription></GroupDescription>WDNS-AU-000013The Windows 2012 DNS Server log must include the source of events within the log records.<VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000133Log 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 on OK. - -For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Select the "Enable logging" check box. - -Click on OK.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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding.SRG-APP-000099-DNS-000010<GroupDescription></GroupDescription>WDNS-AU-000014The Windows 2012 DNS Server log must include results of events within the log records.<VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000134Log 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 on OK. - -For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Select the "Enable logging" check box. - -Click on OK.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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding.SRG-APP-000100-DNS-000011<GroupDescription></GroupDescription>WDNS-AU-000015The Windows 2012 DNS Server log must include identity of individual or process associated with events within the log records.<VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001487Log 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 on OK. - -For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Select the "Enable logging" check box. - -Click on OK.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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding.SRG-APP-000125-DNS-000012<GroupDescription></GroupDescription>WDNS-AU-000016The Windows 2012 DNS Servers audit records must be backed up at least every seven days onto a different system or system component than the system or component being audited.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001348Document and implement a backup policy to back up the DNS Server's audit records at least every seven days.Consult with the System Administrator to determine the backup policy in place for Windows 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 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. -SRG-APP-000214-DNS-000079<GroupDescription></GroupDescription>WDNS-CM-000001The validity period for the RRSIGs covering the DS RR for a zones delegated children must be no less than two days and no more than one week.<VulnDiscussion>The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing. - -To prevent the impact of a compromised KSK, a delegating parent should set the signature validity period for RRSIGs covering DS RRs in the range of a few days to 1 week. This re-signing does not require frequent rollover of the parent's ZSK, but scheduled ZSK rollover should still be performed at regular intervals.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log 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 on the zone, choose DNSSEC->Properties. - -On the ZSK tab, for DS signature validity period (hours), choose more than 48 and less than 168.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. - -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. - -View the validity period for the DS Resource Record. - -If the validity period for the DS Resource Record for the child domain is less than two days (48 hours) or more than one week (168 hours), this is a finding.SRG-APP-000218-DNS-000027<GroupDescription></GroupDescription>WDNS-CM-000002The Windows DNS name servers for a zone must be geographically dispersed.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366For non-AD-integrated Windows DNS Servers, distribute secondary authoritative servers to be located in different buildings from the primary authoritative server. Windows DNS Servers that are Active Directory integrated must be located where required to meet the Active Directory services. - -If all of the Windows DNS Servers are AD integrated, this check is Not Applicable. - -If any or all of the Windows 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. -SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000003The Windows 2012 DNS Server must prohibit recursion on authoritative name servers for which forwarders have not been configured for external queries.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log 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.Note: If the Windows DNS server is in the classified network, this check is Not Applicable. - -Note: In Windows 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. -SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000004Forwarders on an authoritative Windows 2012 DNS Server, if enabled for external resolution, must only forward to either an internal, non-AD-integrated DNS server or to the DoD Enterprise Recursive Services (ERS).<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log 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".Note: If the Windows DNS server is in the classified network, this check is Not Applicable. - -Note: In Windows 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. -SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000005The Windows 2012 DNS Server with a caching name server role must restrict recursive query responses to only the IP addresses and IP address ranges of known supported clients.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Configure 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.Note: If Windows DNS server is not serving in a caching role, this check is Not Applicable. -Verify the Windows 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. -SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000006The Windows 2012 DNS Server with a caching name server role must be secured against pollution by ensuring the authenticity and integrity of queried records.<VulnDiscussion>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. - -Windows 2012 DNS Servers with a caching name server role must be secured against pollution by ensuring that the authenticity and integrity of queried records are verified before any data is cached.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Implement DNSSEC on all non-AD-integrated, standalone, caching Windows 2012 DNS Servers.Note: Blackhole name servers host records which are manually added and for which the name server is not authoritative. It is configured and intended to block resolvers from getting to a destination by directing the query to a blackhole. If the blackhole name server is not authoritative for any zones and otherwise only serves as a caching/forwarding name server, this check is Not Applicable. - -The non-AD-integrated, standalone, caching Windows 2012 DNS Server must be configured to be DNSSEC-aware. When performing caching and lookups, the caching name server must be able to obtain a zone signing key DNSKEY record and corresponding RRSIG record for the queried record. It will use this information to compute the hash for the hostname being resolved. The caching name server decrypts the RRSIG record for the hostname being resolved with the zone's ZSK to get the RRSIG record hash. The caching name server compares the hashes and ensures they match. - -If the non-AD-integrated, standalone, caching Windows 2012 DNS Server is not configured to be DNSSEC-aware, this is a finding. -SRG-APP-000440-DNS-000065<GroupDescription></GroupDescription>WDNS-CM-000007The Windows 2012 DNS Server must implement cryptographic mechanisms to detect changes to information during transmission unless otherwise protected by alternative physical safeguards, such as, at a minimum, a Protected Distribution System (PDS).<VulnDiscussion>Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. - -Confidentiality is not an objective of DNS, but integrity is. DNSSEC and TSIG/SIG(0) both digitally sign DNS information to authenticate its source and ensure its integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the DNS server using the account designated as Administrator or DNS Administrator. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -Note: This requirement applies to any Windows DNS Server which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server only hosts AD-integrated zones and does not host any file-based zones, this is not applicable. -Validate this check from the Windows 2012 DNS server being configured/reviewed. - -Note: This requirement does not apply for classified environments. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. - -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -Note: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000516-DNS-000078<GroupDescription></GroupDescription>WDNS-CM-000008The validity period for the RRSIGs covering a zones DNSKEY RRSet must be no less than two days and no more than one week.<VulnDiscussion>The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing. - -To minimize the impact of a compromised ZSK, a zone administrator should set a signature validity period of 1 week for RRSIGs covering the DNSKEY RRSet in the zone (the RRSet that contains the ZSK and KSK for the zone). The DNSKEY RRSet can be re-signed without performing a ZSK rollover, but scheduled ZSK rollovers should still be performed at regular intervals.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log on to the DNS server using the account designated as Administrator or DNS Administrator. - -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 DNSSEC, Properties. - -Select the KSK Tab. For the "DNSKEY RRSET signature validity period (hours):" setting, configure to a value between 48-168 hours. - -Select the ZSK Tab. For the "DNSKEY signature validity period (hours):" setting, configure to a value between 48-168 hours. -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. - -Log on to the DNS server using the account designated as Administrator or DNS Administrator. - -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 DNSSEC, Properties. - -Select the KSK Tab. - -Verify the "DNSKEY signature validity period (hours):” is set to at least 48 hours and no more than 168 hours. - -Select the ZSK Tab. -Verify the "DNSKEY signature validity period (hours):" is set to at least 48 hours and no more than 168 hours. - -If either the KSK or ZSK Tab "DNSKEY signature validity period (hours):" values are set to less than 48 hours or more than 168 hours, this is a finding. -SRG-APP-000516-DNS-000084<GroupDescription></GroupDescription>WDNS-CM-000009NSEC3 must be used for all internal DNS zones.<VulnDiscussion>NSEC records list the resource record types for the name, as well as the name of the next resource record. With this information it is revealed that the resource record type for the name queried, or the resource record name requested, does not exist. NSEC uses the actual resource record names, whereas NSEC3 uses a one-way hash of the name. In this way, walking zone data from one record to the next is prevented, at the expense of some CPU cycles both on the authoritative server as well as the resolver. To prevent giving access to an entire zone file, NSEC3 should be configured and in order to use NSEC3, RSA/SHA-1 should be used as the algorithm, as some resolvers that understand RSA/SHA-1 might not understand NSEC3. Using RSA/SHA-256 is a safe alternative.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log 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 the zone. - -Right-click the zone, select DNSSEC, Sign the Zone. - -Re-sign the zone, using an NSEC3 algorithm (RSA/SHA-1 (NSEC3), RSA/SHA-256, RSA/SHA-512).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. - -Log on to the DNS server using the Domain Admin or Enterprise Admin account. - -Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account. - -Type the following command: - -PS C:\> Get-DnsServerResourceRecord -ZoneName example.com <enter> - -Where example.com is replaced with the zone hosted on the DNS Server. - -All of the zone's resource records will be returned, among which should be the NSEC3 RRs, as depicted below. - -If NSEC3 RRs are not returned for the zone, this is a finding. - -2vf77rkf63hrgismnuvnb8... NSEC3 0 01:00:00 [RsaSha1][False][50][F2738D980008F73C] -7ceje475rse25gppr3vphs... NSEC3 0 01:00:00 [RsaSha1][False][50][F2738D980008F73C]SRG-APP-000516-DNS-000085<GroupDescription></GroupDescription>WDNS-CM-000010The Windows 2012 DNS Servers zone files must have NS records that point to active name servers authoritative for the domain specified in that record.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366If 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.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. -SRG-APP-000516-DNS-000087<GroupDescription></GroupDescription>WDNS-CM-000012All authoritative name servers for a zone must be located on different network segments.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366For non-AD-integrated Windows DNS Servers, distribute secondary authoritative servers on separate network segments from the primary authoritative server. Windows DNS Servers that are Active Directory-integrated must be located where required to meet the Active Directory services. - -If all of the Windows DNS Servers are AD-integrated, this check is not applicable. - -If any or all of the Windows 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. - -SRG-APP-000516-DNS-000088<GroupDescription></GroupDescription>WDNS-CM-000013All authoritative name servers for a zone must have the same version of zone information.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366If 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.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.SRG-APP-000516-DNS-000089<GroupDescription></GroupDescription>WDNS-CM-000014The Windows 2012 DNS Server must be configured to enable DNSSEC Resource Records.<VulnDiscussion>The specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF's DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. DNSSEC mechanisms involve two main processes: sign and serve, and verify signature. - -Before a DNSSEC-signed zone can be deployed, a name server must be configured to enable DNSSEC processing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters.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. - -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. - -Review the RRs for each zone and verify all of the DNSEC record types are included for the zone. - -NOTE: The DS (Delegation Signer)record should also exist but the requirement for it is validated under WDNS-SC-000011. - -RRSIG (Resource Read Signature) -DNSKEY (Public Key) -NSEC3 (Next Secure 3) - -If the zone does not show all of the DNSSEC record types, this is a finding.SRG-APP-000516-DNS-000090<GroupDescription></GroupDescription>WDNS-CM-000015Digital signature algorithm used for DNSSEC-enabled zones must be FIPS-compatible.<VulnDiscussion>The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) [FIPS186] provides three algorithm choices: -* Digital Signature Algorithm (DSA) -* RSA -* Elliptic Curve DSA (ECDSA). -Of these three algorithms, RSA and DSA are more widely available and hence are considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. - -RSA is the recommended algorithm as far as this guideline is concerned. RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e. RSA/SHA-256, ECDSA) are also specified. It can be expected that name servers and clients will be able to use the RSA algorithm at the minimum. It is suggested that at least one ZSK for a zone use the RSA algorithm. - -NIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in NIST's DSS[FIPS186]. It is expected that there will be support for Elliptic Curve Cryptography in the DNSSEC. The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before September 30th, 2015.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters.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. - -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 RRs in the right window pane. - -Review the DNSKEY encryption in the Data column. example: [DNSKEY][RsaSha1][31021] - -Confirm the encryption algorithm specified in the DNSKEY's Data is at RsaSha1, at a minimum. - -If the specified encryption algorithm is not RsaSha1 or stronger, this is a finding.SRG-APP-000516-DNS-000091<GroupDescription></GroupDescription>WDNS-CM-000016For zones split between the external and internal sides of a network, the RRs for the external hosts must be separate from the RRs for the internal hosts.<VulnDiscussion>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).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Remove 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.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.SRG-APP-000516-DNS-000092<GroupDescription></GroupDescription>WDNS-CM-000017In a split DNS configuration, where separate name servers are used between the external and internal networks, the external name server must be configured to not be reachable from inside resolvers.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Configure the external DNS server's firewall policy, or the network firewall, to block queries from internal hosts.Consult with the System Administrator to review the external Windows 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. - -SRG-APP-000516-DNS-000093<GroupDescription></GroupDescription>WDNS-CM-000018In a split DNS configuration, where separate name servers are used between the external and internal networks, the internal name server must be configured to not be reachable from outside resolvers.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Configure the internal DNS server's firewall policy, or the network firewall, to block queries from external hosts.Consult with the System Administrator to review the internal Windows 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. -SRG-APP-000516-DNS-000095<GroupDescription></GroupDescription>WDNS-CM-000019Primary authoritative name servers must be configured to only receive zone transfer requests from specified secondary name servers.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log 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”.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.SRG-APP-000516-DNS-000099<GroupDescription></GroupDescription>WDNS-CM-000020The Windows 2012 DNS Servers zone database files must not be accessible for edit/write by users and/or processes other than the Windows 2012 DNS Server service account and/or the DNS database administrator.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366For 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.For an Active Directory-integrated DNS implementation, this is Not Applicable by virtue of being compliant with the Windows 2008/2012 AD STIG, since DNS data within an AD-integrated zone is kept within the Active Directory. - -For a file-based 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. -SRG-APP-000516-DNS-000101<GroupDescription></GroupDescription>WDNS-CM-000021The Windows 2012 DNS Server must implement internal/external role separation.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Configure separate DNS servers for each of the external and internal networks.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.SRG-APP-000516-DNS-000102<GroupDescription></GroupDescription>WDNS-CM-000022The Windows 2012 DNS Server authoritative for local zones must only point root hints to the DNS servers that host the internal root domain.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log 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 the root hints from the DNS Manager, the CACHE.DNS file and from Active Directory for name servers outside of the internal network. -Replace the existing root hints with new root hints of internal servers. -If the DNS server is forwarding, click to select the : "Do not use recursion for this domain" check box on the "Forwarders" tab in DNS Manager to make sure that the root hints will not be used. -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 or entries on the "Root Hints" tab under "Name servers:" are external to the local network, this is a finding. -SRG-APP-000516-DNS-000103<GroupDescription></GroupDescription>WDNS-CM-000023The DNS name server software must be at the latest version.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Apply all related Microsoft Operating System IAVM patches to the DNS server.Consult with the network IAVM scanner to confirm all Microsoft Operating System IAVMs have been applied to the Windows DNS server. - -If all Microsoft Operating System IAVMs have not been applied to the DNS server, this is a finding. -SRG-APP-000516-DNS-000113<GroupDescription></GroupDescription>WDNS-CM-000024The Windows 2012 DNS Servers zone files must not include resource records that resolve to a fully qualified domain name residing in another zone.<VulnDiscussion>If a name server were able to claim authority for a resource record in a domain for which it was not authoritative, this would pose a security risk. In this environment, an adversary could use illicit control of a name server to impact IP address resolution beyond the scope of that name server (i.e., by claiming authority for records outside of that server's zones). Fortunately, all but the oldest versions of BIND and most other DNS implementations do not allow for this behavior. Nevertheless, the best way to eliminate this risk is to eliminate from the zone files any records for hosts in another zone. - -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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Remove any resource records in a zone file if the resource record resolves to a fully qualified domain name residing in another zone.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. - -Confirm with the DNS administrator that the hosts defined in the zone files do not resolve to hosts in another zone with its fully qualified domain name. - -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. 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 resource records are maintained that resolve to a fully qualified domain name in another zone, and the usage is not for resource records resolving to hosts that 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 with a documented and approved mission need, this is a finding.SRG-APP-000516-DNS-000114<GroupDescription></GroupDescription>WDNS-CM-000025The Windows 2012 DNS Servers zone files must not include CNAME records pointing to a zone with lesser security for more than six months.<VulnDiscussion>The use of CNAME records for exercises, tests, or zone-spanning (pointing to zones with lesser security) aliases should be temporary (e.g., to facilitate a migration) and not be in place for more than six months. 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Remove 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).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 (i.e., zones of lesser security)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. -SRG-APP-000516-DNS-000500<GroupDescription></GroupDescription>WDNS-CM-000026Non-routable IPv6 link-local scope addresses must not be configured in any zone.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366The SA should remove any link-local addresses and replace with appropriate Site-Local or Global scope addresses.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.SRG-APP-000516-DNS-000500<GroupDescription></GroupDescription>WDNS-CM-000027AAAA addresses must not be configured in a zone for hosts that are not IPv6-aware.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Remove any IPv6 records for hosts which are not IPv6-aware.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.SRG-APP-000516-DNS-000500<GroupDescription></GroupDescription>WDNS-CM-000028IPv6 protocol must be disabled unless the Windows 2012 DNS server is configured to answer for and hosting IPv6 AAAA records.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log 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 “Disable all IPv6 components”. - -As an alternative to using the GPO setting, the registry setting may also be altered directly to reflect: -HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters \ -Set the value for “DisabledComponents” to “255 (0xff)”. - -Note: If the Windows 2012 DNS server is hosting IPv6 records, this requirement is not applicable. - -Log on to the DNS server using the Domain Admin or Enterprise Admin account. - -From a command prompt, run regedit. -In the User Account Control dialog box, click Continue. -In Registry Editor, locate and then click the following registry subkey: -HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters \ -Verify the value for “DisabledComponents” is “255 (0xff)”. - -If the “DisabledComponents” entry is nonexistent, this is a finding. - -If the “DisabledComponents” exists but is not set to “255 (0xff)”, and the DNS server is not hosting any AAAA records, this is a finding. -SRG-APP-000142-DNS-000014<GroupDescription></GroupDescription>WDNS-CM-000029The Windows 2012 DNS Server must be configured to prohibit or restrict unapproved ports and protocols.<VulnDiscussion>In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. - -Applications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services); however, doing so increases risk over limiting the services provided by any one component. - -To support the requirements and principles of least functionality, the application must support the organizational requirements by providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues. - -On Windows 2012 DNS Server, during DNS resolution, DNS messages are sent from DNS clients to DNS servers or between DNS servers. Messages are sent over UDP and DNS servers bind to UDP port 53. When the message length exceeds the default message size for a User Datagram Protocol (UDP) datagram (512 octets), the first response to the message is sent with as much data as the UDP datagram will allow, and then the DNS server sets a flag indicating a truncated response. The message sender can then choose to reissue the request to the DNS server using TCP (over TCP port 53). The benefit of this approach is that it takes advantage of the performance of UDP but also has a backup failover solution for longer queries. - -In general, all DNS queries are sent from a high-numbered source port (49152 or above) to destination port 53, and responses are sent from source port 53 to a high-numbered destination port.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000382Re-install DNS.By default, the Windows 2012 DNS Server listens on TCP 53 and opens UDP ports 53. Also by default, Windows 2012 DNS Server sends from random, high-numbered source ports 49152 and above. - -To confirm the listening ports, log onto Windows 2012 DNS Server as an Administrator. -Open a command window with the “Run-as Administrator” option. - -In the command window, type the following command: -netstat -a -b |more <enter> - -The result is a list of all services running on the server, with the respective “LISTENING TCP” and “OPEN UDP” ports being used. - -Find Windows 2012 DNS Server service and verify the State is "LISTENING" on TCP port 53 and that UDP 53 is listed (indicating it is OPEN). - -If the server shows UDP 53 in results list and shows TCP port 53 as “LISTENING”, this is not a finding. -SRG-APP-000390-DNS-000048<GroupDescription></GroupDescription>WDNS-IA-000001The Windows 2012 DNS Server must require devices to re-authenticate for each dynamic update request connection attempt.<VulnDiscussion>Without re-authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. - -In addition to the re-authentication requirements associated with session locks, organizations may require re-authentication of devices, including, but not limited to, the following other situations: -(i) When authenticators change; -(ii) When roles change; -(iii) When security categories of information systems change; -(iv) After a fixed period of time; or -(v) Periodically. - -DNS does perform server authentication when DNSSEC or TSIG/SIG(0) are used, but this authentication is transactional in nature (each transaction has its own authentication performed). So this requirement is applicable for every server-to-server transaction request.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002039Log 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, and from the displayed context menu, go to Properties. - -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.Authentication of dynamic updates is accomplished in Windows Server 2012 DNS by configuring the zones to only accept secure dynamic updates. - -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, and from the displayed context menu, go to Properties. - -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.SRG-APP-000158-DNS-000015<GroupDescription></GroupDescription>WDNS-IA-000002The Windows 2012 DNS Server must uniquely identify the other DNS server before responding to a server-to-server transaction.<VulnDiscussion>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 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000778Complete 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”.Note: This requirement applies to any Windows DNS Server which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. - -If the Windows 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. -SRG-APP-000394-DNS-000049<GroupDescription></GroupDescription>WDNS-IA-000003The secondary Windows DNS name servers must cryptographically authenticate zone transfers from primary name servers.<VulnDiscussion>Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices can access the system. - -This requirement 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)).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001958Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the DNS server using the account designated as Administrator or DNS Administrator. -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. - -In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. - -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -Authenticity of zone transfers within Windows AD integrated zones is accomplished by AD replication. - -For zones which are completely AD-integrated, this check is not a finding. - -For authenticity of zone transfers between non-AD-integrated zones, DNSSEC must be implemented. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, indicating the zone has been signed with DNSSEC, this is a finding. -SRG-APP-000001-DNS-000001<GroupDescription></GroupDescription>WDNS-IA-000004The Windows DNS primary server must only send zone transfers to a specific list of secondary name servers.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001958Log 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”.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.SRG-APP-000347-DNS-000041<GroupDescription></GroupDescription>WDNS-IA-000005The Windows 2012 DNS Server must provide its identity with returned DNS information by enabling DNSSEC and TSIG/SIG(0).<VulnDiscussion>Weakly bound credentials can be modified without invalidating the credential; therefore, non-repudiation can be violated. - -This requirement supports audit requirements that provide organizational personnel with the means to identify who produced specific information in the event of an information transfer. Organizations and/or data owners determine and approve the strength of the binding between the information producer and the information based on the security category of the information and relevant risk factors. - -DNSSEC and TSIG/SIG(0) both use digital signatures to establish the identity of the producer of particular pieces of information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001958Sign, or re-sign, the hosted zone(s) on the DNS server being validated. -Log on to the DNS server using the account designated as Administrator or DNS Administrator. - -In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. - -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. - -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. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000176-DNS-000017<GroupDescription></GroupDescription>WDNS-IA-000006The Windows 2012 DNS Server must be configured to enforce authorized access to the corresponding private key.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000186Access 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.Access Windows Explorer. - -Navigate to the following location: - -%ALLUSERSPROFILE%\Microsoft\Crypto -Note: If the %ALLUSERSPROFILE%\Microsoft\Crypto folder doesn't exist, this is not applicable. - -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. - -SRG-APP-000176-DNS-000018<GroupDescription></GroupDescription>WDNS-IA-000007The Windows 2012 DNS Server key file must be owned by the account under which the Windows 2012 DNS Server service is run.<VulnDiscussion>To enable zone transfer (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 most key generation utilities used with DNSSEC is Base64-encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000186Access 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. -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 -Note: If the %ALLUSERSPROFILE%\Microsoft\Crypto folder doesn't exist, this is not applicable. - -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. -SRG-APP-000176-DNS-000019<GroupDescription></GroupDescription>WDNS-IA-000008The Windows 2012 DNS Server permissions must be set so that the key file can only be read or modified by the account that runs the name server software.<VulnDiscussion>To enable zone transfer (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 most key generation utilities used with DNSSEC is Base64-encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000186Access Windows Explorer. - -Navigate to the following location: -%ALLUSERSPROFILE%\Microsoft\Crypto - -Modify permissions on the folder, sub-folders and files to “FULL CONTROL” for “SYSTEM” and Administrators and to “READ” for all other Users/Groups. -Access Windows Explorer. - -Navigate to the following location: -%ALLUSERSPROFILE%\Microsoft\Crypto -Note: If the %ALLUSERSPROFILE%\Microsoft\Crypto folder doesn't exist, this is not applicable. - -Verify the permissions on the folder, sub-folders and files are limited to “SYSTEM” and Administrators for “FULL CONTROL”. - -If any other user or group has greater than READ permissions to the %ALLUSERSPROFILE%\Microsoft\Crypto folder, sub-folders and files, this is a finding. -SRG-APP-000176-DNS-000094<GroupDescription></GroupDescription>WDNS-IA-000009The private key corresponding to the ZSK must only be stored on the name server that does support dynamic updates.<VulnDiscussion>The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. - -This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept off-line.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000186Ensure the private key corresponding to the ZSK is only stored on the name server accepting dynamic updates.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. - -For Active Directory-integrated zones, private zone signing keys replicate automatically to all primary DNS servers through Active Directory replication. Each authoritative server signs its own copy of the zone when it receives the key. For optimal performance, and to prevent increasing the size of the Active Directory database file, the signed copy of the zone remains in memory for Active Directory-integrated zones. A DNSSEC-signed zone is only committed to disk for file-backed zones. Secondary DNS servers pull a full copy of the zone, including signatures, from the primary DNS server. - -If all DNS servers are AD integrated, this check is not applicable. - -If a DNS server is not AD integrated and has file-backed zones, does not accept dynamic updates and has a copy of the private key corresponding to the ZSK, this is a finding.SRG-APP-000401-DNS-000051<GroupDescription></GroupDescription>WDNS-IA-000011The Windows 2012 DNS Server must implement a local cache of revocation data for PKIauthentication in the event revocation information via the network is not accessible.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001991Configure local revocation data to be used in the event access to Certificate Authorities is hindered.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.SRG-APP-000516-DNS-000077<GroupDescription></GroupDescription>WDNS-SC-000001The salt value for zones signed using NSEC3 RRs must be changed every time the zone is completely re-signed.<VulnDiscussion>NSEC records list the resource record types for the name, as well as the name of the next resource record. With this information it is revealed that the resource record type for the name queried, or the resource record name requested, does not exist. NSEC uses the actual resource record names, whereas NSEC3 uses a one-way hash of the name. In this way, walking zone data from one record to the next is prevented, at the expense of some CPU cycles both on the authoritative server as well as on the resolver. To prevent giving access to an entire zone file, NSEC3 should be configured, and, in order to use NSEC3, RSA/SHA-1 should be used as the algorithm, as some resolvers that understand RSA/SHA-1 might not understand NSEC3. Using RSA/SHA-256 is a safe alternative.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002450Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. - -Re-validate the NSEC3PARAM Inception date and time against the DNSKEY date and time.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. - -In Windows 2012, the NSEC3 salt values are automatically changed when the zone is resigned. - -To validate: -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 RRs in the right window pane. - -Determine the RRSIG NSEC3PARAM's Inception (in the Data column). Compare the Inception to the RRSIG DNSKEY Inception. The date and time should be the same. - -If the NSEC3PARAM's Inception date and time is different than the DNSKEY Inception Date and Time, this is a finding.SRG-APP-000213-DNS-000024<GroupDescription></GroupDescription>WDNS-SC-000002The Windows 2012 DNS Server must include data origin with authoritative data the system returns in response to external name/address resolution queries.<VulnDiscussion>The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. The security objective is to verify the integrity of each response received. An integral part of integrity verification is to ensure that valid data has originated from the right source. Establishing trust in the source is called data origin authentication. - -The security objectives--and consequently the security services--that are required for securing the DNS query/response transaction are data origin authentication and data integrity verification. - -The specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF's DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001178Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the DNS server using the account designated as Administrator or DNS Administrator. - -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. - -In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. - -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -Authenticity of query responses is provided with DNSSEC signing of zones. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by Windows 2012 DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000420-DNS-000053<GroupDescription></GroupDescription>WDNS-SC-000003The Windows 2012 DNS Servers IP address must be statically defined and configured locally on the server.<VulnDiscussion>The major threat associated with DNS forged responses or failures are the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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, such as with DNSSEC, between the name servers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366CCI-002463Log 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.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.SRG-APP-000420-DNS-000053<GroupDescription></GroupDescription>WDNS-SC-000004The Windows 2012 DNS Server must return data information in responses to internal name/address resolution queries.<VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366CCI-002463Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -By default, when DNS servers are configured with DNSSEC signed zones, they will automatically respond to query requests, providing validating data in the response, whenever the query requests that validation. Since this takes place inherently when the zone is signed with DNSSEC, the requirement is satisfied by ensuring zones are signed. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000421-DNS-000054<GroupDescription></GroupDescription>WDNS-SC-000005The Windows 2012 DNS Server must use DNSSEC data within queries to confirm data origin to DNS resolvers.<VulnDiscussion>The major threat associated with DNS forged responses or failures are the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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. - -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. - -In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366CCI-002464Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000422-DNS-000055<GroupDescription></GroupDescription>WDNS-SC-000006WINS lookups must be disabled on the Windows 2012 DNS Server.<VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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. - -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. - -In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries. - -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. In order to be assured only the DNSSEC-signed data is being returned, WINS lookups must be disabled.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002462Log 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”.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.SRG-APP-000422-DNS-000055<GroupDescription></GroupDescription>WDNS-SC-000007The Windows 2012 DNS Server must use DNSSEC data within queries to confirm data integrity to DNS resolvers.<VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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. - -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. - -In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002462Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000214-DNS-000025<GroupDescription></GroupDescription>WDNS-SC-000008The Windows 2012 DNS Server must be configured with the DS RR carrying the signature for the RR that contains the public key of the child zone.<VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. - -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. - -In DNS, trust in the public key of the source is established by starting from a trusted name server and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. - -A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and Domain Name System Security Extensions (DNSSEC). - -When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor. A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate. In DNS, a trust anchor is a DNSKEY that is placed into a validating resolver so the validator can cryptographically validate the results for a given request back to a known public key (the trust anchor). - -An example means to indicate the security status of child subspaces is through the use of delegation signer (DS) resource records in the DNS. - -Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Without path validation and a chain of trust, there can be no trust that the data integrity authenticity has been maintained during a transaction.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001179Sign, or re-sign, the hosted zone(s) on the DNS server being validated. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000215-DNS-000003<GroupDescription></GroupDescription>WDNS-SC-000009The Windows 2012 DNS Server must enforce approved authorizations between DNS servers through the use of digital signatures in the RRSet.<VulnDiscussion>A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all application information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data. - -Application-specific examples of enforcement occur in systems that employ rule sets or establish configuration settings that restrict information system services or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics). - -Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy. - -Within the context of DNS, this is applicable in terms of controlling the flow of DNS information between systems, such as DNS zone transfers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001663Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -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 (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters.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. - -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 records for the zone and ensure the complete RRSet of records are present: RRSIG, NSEC3, DNSKEY, indicating DNSSEC compliance. - -If the RRSet of records are not in the zone, this is a finding.SRG-APP-000215-DNS-000003<GroupDescription></GroupDescription>WDNS-SC-000010The Name Resolution Policy Table (NRPT) must be configured in Group Policy to enforce clients to request DNSSEC validation for a domain.<VulnDiscussion>The Name Resolution Policy Table (NRPT) is used to require DNSSEC validation. The NRPT can be configured in local Group Policy for a single computer or domain Group Policy for some or all computers in the domain.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001663On Domain Controller, on the Server Manager menu bar, click Tools, and then click Group Policy Management. - -In the Group Policy Management console tree, under Domains >; domainname >; Group Policy Objects, right-click Default Domain Policy, and then click Edit. - -In the Group Policy Management Editor console tree, navigate to Computer Configuration >; Policies >; Windows Settings >; Name Resolution Policy. - -In the details pane, under Create Rules and to which part of the namespace does this rule apply, choose Suffix from the drop-down list and type domain.mil next to Suffix. - -On the DNSSEC tab, select the Enable DNSSEC in this rule check box and then under Validation select the Require DNS clients to check that name and address data has been validated by the DNS server check box. - -In the bottom right corner, click Create and then verify that a rule for domain.mil was added under Name Resolution Policy Table. - -Click Apply, and then close the Group Policy Management Editor. - -Open a Windows PowerShell prompt and enter the following commands: -gpupdate /force <enter> -get-dnsclientnrptpolicy <enter> -In the results, select the True for "DnsSecValidationRequired" setting for the domain.mil namespace.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. - -The Name Resolution Policy Table (NRPT) is configured in, and deployed to clients from, Group Policy and will be pushed to all clients in the domain. The Active Directory zones will be signed and the clients, with NRPT, will require a validation of signed data when querying. - -Log on to the DNS server using the Domain Admin or Enterprise Admin account. - -At the Windows PowerShell prompt, type the following command: - -get-dnsclientnrptpolicy <enter> - -In the results, verify the "DnsSecValidationRequired" is True. - -If there are no results to the get-dnsclientnrptpolicy cmdlet or the "DnsSecValidationRequired" is not True, this is a finding.SRG-APP-000215-DNS-000026<GroupDescription></GroupDescription>WDNS-SC-000011The Windows 2012 DNS Server must be configured to validate an authentication chain of parent and child domains via response data.<VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. -Like the DNSKEY resource record, the delegation signer (DS) resource record can be used to create a trust anchor for a signed zone. The DS record is smaller in size than a DNSKEY record because it contains only a hash of the public key. -The DS record is not added to a zone during the signing process like some DNSSEC-related resource records, even if a delegation already exists in the zone. To add a DS record, you must manually add or import it. Fortunately, the DS resource record set (DSSET) is automatically added as a file to the Key Master when a zone is signed. The DSSET file can be used with the Import-DnsServerResourceRecordDS cmdlet to import DS records to the parent zone. - -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. - -DNSSEC provides the means to verify integrity assurances for the host/service name to network address resolution information obtained through the service. By using the delegation signer (DS) resource records in the DNS, the security status of a child domain can be validated. The DS resource record is used to identify the DNSSEC signing key of a delegated zone. - -Starting from a trusted name server (such as the root name server) and down to the current source of response through successive verifications of signature of the public key of a child by its parent, the chain of trust is established. The public key of the trusted name servers is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. This requires that responses consist of not only the requested RRs but also an authenticator associated with them. In DNSSEC, this authenticator is the digital signature of a Resource Record (RR) Set. The digital signature of an RRSet is encapsulated through a special RRType called RRSIG. The DNS client using the trusted public key of the source (whose trust has just been established) then verifies the digital signature to detect if the response is valid or bogus. - -This control enables the DNS to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Without indication of the security status of a child domain and enabling verification of a chain of trust, integrity and availability of the DNS infrastructure cannot be assured. -</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001663A DS records must be added manually or imported. - -The DS resource record set (DSSET) is automatically added as a file to the Key Master when a zone is signed. - -This file can be used with the Import-DnsServerResourceRecordDS cmdlet to import DS records to the parent zone. - -Example: -PS C:\> Import-DnsServerResourceRecordDS -ZoneName adatum.com -DSSetFile "c:\windows\system32\dns\dsset-corp.adatum.com" - -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. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: - -PS C:\> Get-DnsServerResourceRecord -ZoneName adatum.com -RRType DS - -Replace adatum.com with the parent zone on the DNS server being evaluated. - -HostName RecordType Timestamp TimeToLive RecordData --------- ---------- --------- ---------- ---------- -corp DS 0 01:00:00 [58555][Sha1][RsaSha1NSec3] -corp DS 0 01:00:00 [58555][Sha256][RsaSha1NSec3] -corp DS 0 01:00:00 [63513][Sha1][RsaSha1NSec3] -corp DS 0 01:00:00 [63513][Sha256][RsaSha1NSec3] - -If the results do not show the DS records for child domain(s), this is a finding. - -In the previous example, DS records for the child zone, corp.adatum.com, were imported into the parent zone, adatum.com, by using the DSSET file that is located in the c:\windows\system32\dns directory. The DSSET file was located in this directory because the local DNS server is the Key Master for the child zone. - -If the Key Master DNS server for a child zone is not the same computer as the primary authoritative DNS server for the parent zone where the DS record is being added, the DSSET file must be obtained for the child zone and made available to the primary authoritative server for the parent zone. Alternatively, the DS records can be added manually. -SRG-APP-000215-DNS-000026<GroupDescription></GroupDescription>WDNS-SC-000012Trust anchors must be exported from authoritative Windows 2012 DNS Servers and distributed to validating Windows 2012 DNS Servers.<VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. - -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. - -DNSSEC provides the means to verify integrity assurances for the host/service name to network address resolution information obtained through the service. By using the delegation signer (DS) resource records in the DNS, the security status of a child domain can be validated. The DS resource record is used to identify the DNSSEC signing key of a delegated zone. - -Starting from a trusted name server (such as the root name server) and down to the current source of response through successive verifications of signature of the public key of a child by its parent, the chain of trust is established. The public key of the trusted name servers is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. This requires that responses consist of not only the requested RRs but also an authenticator associated with them. In DNSSEC, this authenticator is the digital signature of a Resource Record (RR) Set. The digital signature of an RRSet is encapsulated through a special RRType called RRSIG. The DNS client using the trusted public key of the source (whose trust has just been established) then verifies the digital signature to detect if the response is valid or bogus. - -This control enables the DNS to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Without indication of the security status of a child domain and enabling verification of a chain of trust, integrity and availability of the DNS infrastructure cannot be assured. - -A trust anchor is a preconfigured public key associated with a specific zone. A validating DNS server must be configured with one or more trust anchors in order to perform validation. If the DNS server is running on a domain controller, trust anchors are stored in the forest directory partition in Active Directory Domain Services (AD DS) and can be replicated to all domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named TrustAnchors.dns. A DNS server running Windows Server 2012 or Windows Server 2012 R2 also displays configured trust anchors in the DNS Manager console tree in the Trust Points container. Trust anchors can also be viewed by executing Windows PowerShell commands or Dnscmd.exe at a Windows command prompt.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001663Log onto the primary DNS server and click Windows Explorer on the taskbar. - -Navigate to C:\Windows\System32, right-click the dns folder, point to Share with, and then click Advanced sharing. - -In the dns Properties dialog box, click Advanced Sharing, select the Share this folder check box, verify the Share name is dns, and then click OK. - -Click Close and then close Windows Explorer. - -Log onto each of the validating Windows 2012 DNS Servers. - -In the DNS Manager console tree, navigate to the Trust Points folder. - -Right-click Trust Points, point to Import, and then click DNSKEY. - -In the Import DNSKEY dialog box, type \\primaryhost\dns\keyset-domain.mil (where primaryhost represent the FQDN of the Primary DNS Server and domain.mil represents the zone(s)). - -Click OK. -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. - -Log onto each of the validating Windows 2012 DNS Servers. - -In the DNS Manager console tree, navigate to each hosted zone under the Trust Points folder. - -Two DNSKEY trust points should be displayed, one for the active key and one for the standby key. - -If each validating Windows 2012 DNS Servers does not reflect the DNSKEY trust points for each of the hosted zone(s), this is a finding. -SRG-APP-000215-DNS-000026<GroupDescription></GroupDescription>WDNS-SC-000013Automatic Update of Trust Anchors must be enabled on key rollover.<VulnDiscussion>A trust anchor is a preconfigured public key associated with a specific zone. A validating DNS server must be configured with one or more trust anchors in order to perform validation. If the DNS server is running on a domain controller, trust anchors are stored in the forest directory partition in Active Directory Domain Services (AD DS) and can be replicated to all domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named TrustAnchors.dns. A DNS server running Windows Server 2012 or Windows Server 2012 R2 also displays configured trust anchors in the DNS Manager console tree in the Trust Points container. Trust anchors can also be viewed by executing Windows PowerShell commands or Dnscmd.exe at a Windows command prompt.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001663Log 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. - -From the displayed context menu, click DNSSEC>>Properties. - -Click the KSK tab. - -For each KSK that is listed under Key signing keys (KSKs), click the KSK, click Edit, and in the Key Rollover section, select the "Enable automatic rollover" check box.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. - -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. - -From the displayed context menu, click DNSSEC>>Properties. - -Click the KSK tab. - -For each KSK that is listed under Key signing keys (KSKs), click the KSK, click Edit, and in the Key Rollover section verify the "Enable automatic rollover" check box is selected. - -If the "Enable automatic rollover" check box is not selected for every KSK listed, this is a finding.SRG-APP-000423-DNS-000056<GroupDescription></GroupDescription>WDNS-SC-000014The Windows DNS secondary servers must request data origin authentication verification from the primary server when requesting name/address resolution.<VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data origin authentication must be performed to thwart these types of attacks. - -Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002465Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters.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. - -Validate this check from either a Windows 8 client or a Windows 2008 or higher server, authenticated as a Domain Administrator. - -Determine a valid host in the zone. - -Open the Windows PowerShell prompt on the Windows 8/Windows 2008 or higher client. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding.SRG-APP-000424-DNS-000057<GroupDescription></GroupDescription>WDNS-SC-000015The Windows DNS secondary server must request data integrity verification from the primary server when requesting name/address resolution.<VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks. - -Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002466Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000425-DNS-000058<GroupDescription></GroupDescription>WDNS-SC-000017The Windows DNS secondary server must validate data integrity verification on the name/address resolution responses received from primary name servers.<VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks. - -Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002467Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000426-DNS-000059<GroupDescription></GroupDescription>WDNS-SC-000018The Windows DNS secondary server must validate data origin verification authentication on the name/address resolution responses received from primary name servers.<VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data origin authentication verification must be performed to thwart these types of attacks. - -Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002468Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000219-DNS-000028<GroupDescription></GroupDescription>WDNS-SC-000019The Windows 2012 DNS Server must protect the authenticity of zone transfers via transaction signing.<VulnDiscussion>Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. This applies to server-to-server (zone transfer) transactions 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 2012 DNS Server. - -To meet the requirement for authentication between Windows DNS servers, IPsec will be implemented between the Windows DNS servers which hosts any non-AD-integrated zones.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001184Complete the following procedures twice for each pair of name servers. - -First create a rule for UDP connections, and then create a rule for TCP connections. - -Refer to the U_Windows_Domain_Name_Service_2012_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 generated by the internally-managed server performing the Active Directory Certificate Services (AD CS) role, click Next. - -On Profile, accept default selections, click Next. - -On Name, enter a name applicable to the rule's function (i.e., DNSSEC UDP), click Finish.NOTE: This requirement applies to any Windows 2012 DNS Servers which host non-AD-integrated zones (file based) even if the DNS servers host AD-integrated zones, too. - -If the Windows 2012 DNS Servers only host AD-integrated zones, this requirement is not applicable. - -To protect authenticity of zone transfers between Windows 2012 DNS Servers with file based zones, IPsec must be configured on each pair of name servers in a zone transfer transaction for those zones. - -Log on to the DNS server which hosts non-AD-integrated, file based zones, using the Administrator, 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. - -Consult with the SA to determine which Rules meet the intent of the server-to-server authentication. - -If Rules exist, double-click on each Rule to verify the following: - -For the "Authentication:" tab, click on the "Customize..." button. - -On the Authentication tab, verify "Authentication mode:" is set to "Request authentication for inbound and outbound connections". - -Confirm the "Signing Algorithm" is set to "RSA (default)". - -Under "Method", ensure the "Advanced:" radio button is selected. - -Click on the "Customize" button. - -For "First authentication methods:", double-click on the entry. - -Verify the "Select the credential to use for first authentication:" has "Computer certificate from this certification authority (CA):" radio button selected. - -Review the certificate specified and verify the certificate used was generated by the internally-managed server performing the Active Directory Certificate Services (AD CS) role. - -If rules do not exist for server-to-server authentication, this is a finding. - -If rules exist for this server to authenticate to other name servers hosting the same file based zones when transacting zone transfers, but the rules are not configured with the above settings, this is a finding.SRG-APP-000219-DNS-000029<GroupDescription></GroupDescription>WDNS-SC-000020The Windows 2012 DNS Server must protect the authenticity of dynamic updates via transaction signing.<VulnDiscussion>DNS is a fundamental network service that is prone to various attacks, such as cache poisoning and man-in-the middle attacks. If communication sessions are not provided appropriate validity protections, such as the employment of DNSSEC, the authenticity of the data cannot be guaranteed. - -The combination of signing DNS zones by DNSSEC and requiring clients to send their dynamic updates securely assures the authenticity of those DNS records when providing query responses for them.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001184Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. - -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. - -In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. - -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -Once resource records are received by a DNS server via a secure dynamic update, the resource records will automatically become signed by DNSSEC as long as the zone was originally signed by DNSSEC. Authenticity of query responses for resource records dynamically updated can be validated by querying for whether the zone/record is signed by DNSSEC. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace 131.77.60.235 with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an Expirations, date signed, signer and signature, similar to the following: - -Name : www.zonename.mil -QueryType : RRSIG -TTL : 189 -Section : Answer -TypeCovered : CNAME -Algorithm : 8 -LabelCount : 3 -OriginalTtl : 300 -Expiration : 11/21/2014 10:22:28 PM -Signed : 10/22/2014 10:22:28 PM -Signer : zonename.mil -Signature : {87, 232, 34, 134...} - -Name : origin-www.zonename.mil -QueryType : A -TTL : 201 -Section : Answer -IP4Address : 156.112.108.76 - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000219-DNS-000030<GroupDescription></GroupDescription>WDNS-SC-000021The Windows 2012 DNS Server must protect the authenticity of query responses via DNSSEC.<VulnDiscussion>The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. An integral part of integrity verification is to ensure that valid data has originated from the right source. DNSSEC is required for securing the DNS query/response transaction by providing data origin authentication and data integrity verification through signature verification and the chain of trust.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001184Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. - -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. -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. - -Authenticity of query responses is provided with DNSSEC signing of zones. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. - -Fix Text: Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. - -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. -SRG-APP-000427-DNS-000060<GroupDescription></GroupDescription>WDNS-SC-000022The Windows 2012 DNS Server must only allow the use of an approved DoD PKI-established certificate authorities for verification of the establishment of protected transactions.<VulnDiscussion>Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established. - -The DoD will only accept PKI certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates. - -TSIG and SIG(0) are not configurable in Windows 2012 DNS Server. To meet the requirement for authentication between Windows DNS servers, IPsec must be implemented between the Windows DNS servers. - -NOTE: If multiple certificates from the same CA are present on the DNS server, IPsec authentication might fail due to an incorrect certificate being chosen. For this purpose, an Active Directory Certificate Services (AD CS) role must be installed and configured as an Enterprise certification authority (CA). - -Refer to the U_Windows_Domain_Name_Service_2012_Overview.pdf for references on deploying certificates for this procedure.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002470Complete the following procedures twice for each pair of name servers. - -First create a rule for UDP connections, and then create a rule for TCP connections. - -Refer to the U_Windows_Domain_Name_Service_2012_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 generated by the internally-managed server performing the Active Directory Certificate Services (AD CS) role, click Next. - -On Profile, accept default selections, click Next. - -On Name, enter a name applicable to the rule's function (i.e., DNSSEC UDP), click Finish.NOTE: This requirement applies to any Windows 2012 DNS Servers which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. - -If the Windows 2012 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. - -Consult with the SA to determine which Rules meet the intent of DNSSEC server-to-server authentication. - -Double-click on each Rule to verify the following: -For the "Authentication:" tab, click on the "Customize..." button. - -On the Authentication tab, verify "Authentication mode:" is set to "Request authentication for inbound and outbound connections". - -Confirm the "Signing Algorithm" is set to "RSA (default)". - -Under "Method", ensure the "Advanced:" radio button is selected. Click on the "Customize" button. - -For "First authentication methods:", double-click on the entry. - -Verify the "Select the credential to use for first authentication:" has "Computer certificate from this certification authority (CA):" radio button selected. - -Review the certificate specified and verify the certificate used was generated by the internally-managed server performing the Active Directory Certificate Services (AD CS) role. - -If the certificate used does not meet the requirements, this is a finding.SRG-APP-000231-DNS-000033<GroupDescription></GroupDescription>WDNS-SC-000024The Windows 2012 DNS Server must protect secret/private cryptographic keys while at rest.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001199To 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. 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. -SRG-APP-000428-DNS-000061<GroupDescription></GroupDescription>WDNS-SC-000025The Windows 2012 DNS Server must not contain zone records that have not been validated in over a year.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002475Create 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.This requirement is not applicable for a Windows DNS Server which is only hosting AD-integrated zones. - -For a Windows 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. -SRG-APP-000246-DNS-000035<GroupDescription></GroupDescription>WDNS-SC-000026The Windows 2012 DNS Server must restrict individuals from using it for launching Denial of Service (DoS) attacks against other information systems.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001094Configure 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 GroupReview 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 GroupSRG-APP-000247-DNS-000036<GroupDescription></GroupDescription>WDNS-SC-000027The Windows 2012 DNS Server must use DNS Notify to prevent denial of service through increase in workload.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001095Log 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.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.SRG-APP-000439-DNS-000063<GroupDescription></GroupDescription>WDNS-SC-000028The Windows 2012 DNS Server must protect the integrity of transmitted information.<VulnDiscussion>Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. - -Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. - -Confidentiality is not an objective of DNS, but integrity is. DNSSEC and TSIG/SIG(0) both digitally sign DNS information to authenticate its source and ensure its integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002418Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000441-DNS-000066<GroupDescription></GroupDescription>WDNS-SC-000029The Windows 2012 DNS Server must maintain the integrity of information during preparation for transmission.<VulnDiscussion>Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002421Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. - -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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000442-DNS-000067<GroupDescription></GroupDescription>WDNS-SC-000030The Windows 2012 DNS Server must maintain the integrity of information during reception.<VulnDiscussion>Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002420Sign, or re-sign, the hosted zone(s) on the DNS server being validated. - -Log on to the Windows 2012 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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. -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. - -Validate this check from the Windows 2012 DNS server being configured/reviewed. -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000251-DNS-000037<GroupDescription></GroupDescription>WDNS-SI-000001The Windows 2012 DNS Server must be configured to only allow zone information that reflects the environment for which it is authoritative, to include IP ranges and IP versions.<VulnDiscussion>DNS zone data for which a Windows 2012 DNS server is authoritative should represent the network for which it is responsible. If a Windows 2012 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001310Log 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.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.SRG-APP-000451-DNS-000069<GroupDescription></GroupDescription>WDNS-SI-000002The Windows 2012 DNS Server must follow procedures to re-role a secondary name server as the master name server should the master name server permanently lose functionality.<VulnDiscussion>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). - -If a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly anyway in this state.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002754Active 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.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.SRG-APP-000268-DNS-000039<GroupDescription></GroupDescription>WDNS-SI-000005The Windows 2012 DNS Server must, when a component failure is detected, activate a notification to the system administrator.<VulnDiscussion>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. - -If a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly anyway in this state.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366CCI-001328Implement 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.Notification to system administrator is not configurable in Windows DNS Server. 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. -SRG-APP-000473-DNS-000072<GroupDescription></GroupDescription>WDNS-SI-000006The Windows 2012 DNS Server must perform verification of the correct operation of security functions: upon system start-up and/or restart; upon command by a user with privileged access; and/or every 30 days.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366CCI-002775Follow the HBSS guidance to install all HBSS products to the Windows DNS Server. 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 DNS Server. - -If all required HBSS products are not installed and/or the installed products are not enabled, this is a finding. -SRG-APP-000474-DNS-000073<GroupDescription></GroupDescription>WDNS-SI-000007The Windows 2012 DNS Server must log the event and notify the system administrator when anomalies in the operation of the signed zone transfers are discovered.<VulnDiscussion>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. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. - -If anomalies are not acted upon, security functions may fail to secure the system. - -The DNS server does not have the capability of shutting down or restarting the information system. The DNS server can be configured to generate audit records when anomalies are discovered, and the OS/NDM can then trigger notification messages to the system administrator based on the presence of those audit records.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002699Implement a third-party monitoring system to detect and notify the ISSO/ISSM/DNS administrator if functionality of DNSSEC/TSIG 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.Note: If only zones hosted are AD-integrated zones, this check is not applicable. - -Notification to system administrator is not configurable in Windows 2012. In order for administrator to be notified if functionality of DNSSEC/TSIG 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 DNSSEC/TSIG 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.SRG-APP-000275-DNS-000040<GroupDescription></GroupDescription>WDNS-SI-000008The Windows 2012 DNS Server must be configured to notify the ISSO/ISSM/DNS administrator when functionality of DNSSEC/TSIG has been removed or broken.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001294Implement 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.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 DNS Server. 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. -SRG-APP-000504-DNS-000074<GroupDescription></GroupDescription>WDNS-SI-000009The Windows 2012 DNS Server must generate audit records for the success and failure of start and stop of the DNS Server service.<VulnDiscussion>Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered, in order to compile an accurate risk assessment. Logging the actions of specific events provides a means to investigate an attack, to recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002702Log 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 on OK. - -For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Select the "Enable logging" check box. - -Click on OK.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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding.SRG-APP-000333-DNS-000104<GroupDescription></GroupDescription>WDNS-SI-000003The DNS Name Server software must be configured to refuse queries for its version information.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001312To disable the version being returned in queries, execute the following command: - -dnscmd /config /EnableVersionQuery 0 <enter>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.SRG-APP-000333-DNS-000107<GroupDescription></GroupDescription>WDNS-SI-000004The HINFO, RP, TXT and LOC RR types must not be used in the zone SOA.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001312Log 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.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. diff --git a/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V2R1_Manual-xccdf.log b/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V2R1_Manual-xccdf.log new file mode 100644 index 000000000..0c8e69710 --- /dev/null +++ b/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V2R1_Manual-xccdf.log @@ -0,0 +1,3 @@ +V-215597::Auditors (if the site has an Auditors group that further limits this privilege.)::Administrators Auditors (if the site has an Auditors group that further limits this privilege.) +V-215597::*::HardCodedRule(RegistryRule)@{DscResource = 'Registry'; Ensure = 'Present'; Key = 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters'; ValueData = $null; ValueName = 'DisabledComponents'; ValueType = 'DWord'; OrganizationValueTestString = 'ValueData is set to 255 which disables IPv6 '} +V-215605::Verify the Owner on the folder, sub-folders, and files are the account under which the DNS Server Service is running.::Verify the permissions on the folder, sub-folders, and files are the account under which the DNS Server Service is running. diff --git a/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V2R1_Manual-xccdf.xml b/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V2R1_Manual-xccdf.xml new file mode 100644 index 000000000..f528ada1d --- /dev/null +++ b/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V2R1_Manual-xccdf.xml @@ -0,0 +1,2558 @@ +acceptedMicrosoft Windows 2012 Server Domain Name System Security Technical Implementation GuideThis 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 email to the following address: disa.stig_spt@mail.mil.DISASTIG.DOD.MILRelease: 1 Benchmark Date: 23 Oct 20203.1.1.362251.10.02I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000003The Windows 2012 DNS Server must prohibit recursion on authoritative name servers for which forwarders have not been configured for external queries.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73009V-58579CCI-000366Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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.Note: If the Windows DNS server is in the classified network, this check is Not Applicable. + +Note: In Windows 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 or Local Administrator 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. +SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000004Forwarders on an authoritative Windows 2012 DNS Server, if enabled for external resolution, must only forward to either an internal, non-AD-integrated DNS server or to the DoD Enterprise Recursive Services (ERS).<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73011V-58581CCI-000366Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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".Note: If the Windows DNS server is in the classified network, this check is Not Applicable. + +Note: In Windows 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 or Local Administrator 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. +SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000005The Windows 2012 DNS Server with a caching name server role must restrict recursive query responses to only the IP addresses and IP address ranges of known supported clients.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73013V-58583CCI-000366Configure 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.Note: If Windows DNS server is not serving in a caching role, this check is Not Applicable. +Verify the Windows 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. +SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000006The Windows 2012 DNS Server with a caching name server role must be secured against pollution by ensuring the authenticity and integrity of queried records.<VulnDiscussion>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. + +Windows 2012 DNS Servers with a caching name server role must be secured against pollution by ensuring that the authenticity and integrity of queried records are verified before any data is cached.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58585SV-73015CCI-000366Implement DNSSEC on all non-AD-integrated, standalone, caching Windows 2012 DNS Servers to ensure caching server validates signed zones when resolving and caching.Note: Blackhole name servers host records which are manually added and for which the name server is not authoritative. It is configured and intended to block resolvers from getting to a destination by directing the query to a blackhole. If the blackhole name server is not authoritative for any zones and otherwise only serves as a caching/forwarding name server, this check is Not Applicable. + +The non-AD-integrated, standalone, caching Windows 2012 DNS Server must be configured to be DNSSEC-aware. When performing caching and lookups, the caching name server must be able to obtain a zone signing key DNSKEY record and corresponding RRSIG record for the queried record. It will use this information to compute the hash for the hostname being resolved. The caching name server decrypts the RRSIG record for the hostname being resolved with the zone's ZSK to get the RRSIG record hash. The caching name server compares the hashes and ensures they match. + +If the non-AD-integrated, standalone, caching Windows 2012 DNS Server is not configured to be DNSSEC-aware, this is a finding. +SRG-APP-000440-DNS-000065<GroupDescription></GroupDescription>WDNS-CM-000007The Windows 2012 DNS Server must implement cryptographic mechanisms to detect changes to information during transmission unless otherwise protected by alternative physical safeguards, such as, at a minimum, a Protected Distribution System (PDS).<VulnDiscussion>Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. + +Confidentiality is not an objective of DNS, but integrity is. DNSSEC and TSIG/SIG(0) both digitally sign DNS information to authenticate its source and ensure its integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58587SV-73017CCI-000366Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the DNS server using the account designated as Administrator or DNS Administrator. + +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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +Note: This requirement applies to any Windows DNS Server which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server only hosts AD-integrated zones and does not host any file-based zones, this is not applicable. +Validate this check from the Windows 2012 DNS server being configured/reviewed. + +Note: This requirement does not apply for classified environments. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. + +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +Note: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000516-DNS-000078<GroupDescription></GroupDescription>WDNS-CM-000008The validity period for the RRSIGs covering a zones DNSKEY RRSet must be no less than two days and no more than one week.<VulnDiscussion>The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing. + +To minimize the impact of a compromised ZSK, a zone administrator should set a signature validity period of 1 week for RRSIGs covering the DNSKEY RRSet in the zone (the RRSet that contains the ZSK and KSK for the zone). The DNSKEY RRSet can be re-signed without performing a ZSK rollover, but scheduled ZSK rollovers should still be performed at regular intervals.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73019V-58589CCI-000366Log on to the DNS server using the account designated as Administrator or DNS Administrator. + +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 DNSSEC, Properties. + +Select the KSK Tab. For the "DNSKEY RRSET signature validity period (hours):" setting, configure to a value between 48-168 hours. + +Select the ZSK Tab. For the "DNSKEY signature validity period (hours):" setting, configure to a value between 48-168 hours. +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. + +Log on to the DNS server using the account designated as Administrator or DNS Administrator. + +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 DNSSEC, Properties. + +Select the KSK Tab. + +Verify the "DNSKEY signature validity period (hours):” is set to at least 48 hours and no more than 168 hours. + +Select the ZSK Tab. +Verify the "DNSKEY signature validity period (hours):" is set to at least 48 hours and no more than 168 hours. + +If either the KSK or ZSK Tab "DNSKEY signature validity period (hours):" values are set to less than 48 hours or more than 168 hours, this is a finding. +SRG-APP-000516-DNS-000084<GroupDescription></GroupDescription>WDNS-CM-000009NSEC3 must be used for all internal DNS zones.<VulnDiscussion>NSEC records list the resource record types for the name, as well as the name of the next resource record. With this information it is revealed that the resource record type for the name queried, or the resource record name requested, does not exist. NSEC uses the actual resource record names, whereas NSEC3 uses a one-way hash of the name. In this way, walking zone data from one record to the next is prevented, at the expense of some CPU cycles both on the authoritative server as well as the resolver. To prevent giving access to an entire zone file, NSEC3 should be configured and in order to use NSEC3, RSA/SHA-1 should be used as the algorithm, as some resolvers that understand RSA/SHA-1 might not understand NSEC3. Using RSA/SHA-256 is a safe alternative.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73021V-58591CCI-000366Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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 the zone. + +Right-click the zone, select DNSSEC, Sign the Zone. + +Re-sign the zone, using an NSEC3 algorithm (RSA/SHA-1 (NSEC3), RSA/SHA-256, RSA/SHA-512).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. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. + +Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account. + +Type the following command: + +PS C:\> Get-DnsServerResourceRecord -ZoneName example.com <enter> + +Where example.com is replaced with the zone hosted on the DNS Server. + +All of the zone's resource records will be returned, among which should be the NSEC3 RRs, as depicted below. + +If NSEC3 RRs are not returned for the zone, this is a finding. + +2vf77rkf63hrgismnuvnb8... NSEC3 0 01:00:00 [RsaSha1][False][50][F2738D980008F73C] +7ceje475rse25gppr3vphs... NSEC3 0 01:00:00 [RsaSha1][False][50][F2738D980008F73C]SRG-APP-000516-DNS-000085<GroupDescription></GroupDescription>WDNS-CM-000010The Windows 2012 DNS Servers zone files must have NS records that point to active name servers authoritative for the domain specified in that record.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73023V-58593CCI-000366If 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 or Local 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 the zone. + +Review the NS records for the zone. + +Select the NS record for the non-responsive name server and remove the record.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 or Local 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 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. +SRG-APP-000516-DNS-000087<GroupDescription></GroupDescription>WDNS-CM-000012All authoritative name servers for a zone must be located on different network segments.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58595SV-73025CCI-000366For non-AD-integrated Windows DNS Servers, distribute secondary authoritative servers on separate network segments from the primary authoritative server. Windows DNS Servers that are Active Directory-integrated must be located where required to meet the Active Directory services. + +If all of the Windows DNS Servers are AD-integrated, this check is not applicable. + +If any or all of the Windows 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. + +SRG-APP-000516-DNS-000088<GroupDescription></GroupDescription>WDNS-CM-000013All authoritative name servers for a zone must have the same version of zone information.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58597SV-73027CCI-000366If 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 or Local 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 the zone. + +Initiate a zone transfer to all secondary name servers for the zone.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.SRG-APP-000516-DNS-000089<GroupDescription></GroupDescription>WDNS-CM-000014The Windows 2012 DNS Server must be configured to enable DNSSEC Resource Records.<VulnDiscussion>The specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF's DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. DNSSEC mechanisms involve two main processes: sign and serve, and verify signature. + +Before a DNSSEC-signed zone can be deployed, a name server must be configured to enable DNSSEC processing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58599SV-73029CCI-000366Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters.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. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 each zone. + +Review the RRs for each zone and verify all of the DNSEC record types are included for the zone. + +NOTE: The DS (Delegation Signer)record should also exist but the requirement for it is validated under WDNS-SC-000011. + +RRSIG (Resource Read Signature) +DNSKEY (Public Key) +NSEC3 (Next Secure 3) + +If the zone does not show all of the DNSSEC record types, this is a finding.SRG-APP-000516-DNS-000090<GroupDescription></GroupDescription>WDNS-CM-000015Digital signature algorithm used for DNSSEC-enabled zones must be FIPS-compatible.<VulnDiscussion>The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) [FIPS186] provides three algorithm choices: +* Digital Signature Algorithm (DSA) +* RSA +* Elliptic Curve DSA (ECDSA). +Of these three algorithms, RSA and DSA are more widely available and hence are considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. + +RSA is the recommended algorithm as far as this guideline is concerned. RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e. RSA/SHA-256, ECDSA) are also specified. It can be expected that name servers and clients will be able to use the RSA algorithm at the minimum. It is suggested that at least one ZSK for a zone use the RSA algorithm. + +NIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in NIST's DSS[FIPS186]. It is expected that there will be support for Elliptic Curve Cryptography in the DNSSEC. The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before September 30th, 2015.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58601SV-73031CCI-000366Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters.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. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. + +Review the zone's RRs in the right window pane. + +Review the DNSKEY encryption in the Data column. example: [DNSKEY][RsaSha1][31021] + +Confirm the encryption algorithm specified in the DNSKEY's Data is at RsaSha1, at a minimum. + +If the specified encryption algorithm is not RsaSha1 or stronger, this is a finding.SRG-APP-000516-DNS-000091<GroupDescription></GroupDescription>WDNS-CM-000016For zones split between the external and internal sides of a network, the RRs for the external hosts must be separate from the RRs for the internal hosts.<VulnDiscussion>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).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58603SV-73033CCI-000366Remove 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.Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 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.SRG-APP-000516-DNS-000092<GroupDescription></GroupDescription>WDNS-CM-000017In a split DNS configuration, where separate name servers are used between the external and internal networks, the external name server must be configured to not be reachable from inside resolvers.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58605SV-73035CCI-000366Configure the external DNS server's firewall policy, or the network firewall, to block queries from internal hosts.Consult with the System Administrator to review the external Windows 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. + +SRG-APP-000516-DNS-000093<GroupDescription></GroupDescription>WDNS-CM-000018In a split DNS configuration, where separate name servers are used between the external and internal networks, the internal name server must be configured to not be reachable from outside resolvers.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73037V-58607CCI-000366Configure the internal DNS server's firewall policy, or the network firewall, to block queries from external hosts.Consult with the System Administrator to review the internal Windows 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. +SRG-APP-000516-DNS-000095<GroupDescription></GroupDescription>WDNS-CM-000019Primary authoritative name servers must be configured to only receive zone transfer requests from specified secondary name servers.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73039V-58609CCI-000366Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 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”.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 or Local 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 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.SRG-APP-000516-DNS-000099<GroupDescription></GroupDescription>WDNS-CM-000020The Windows 2012 DNS Servers zone database files must not be accessible for edit/write by users and/or processes other than the Windows 2012 DNS Server service account and/or the DNS database administrator.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58611SV-73041CCI-000366For a file-back Windows DNS implementation, Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 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.For an Active Directory-integrated DNS implementation, this is Not Applicable by virtue of being compliant with the Windows 2008/2012 AD STIG, since DNS data within an AD-integrated zone is kept within the Active Directory. + +For a file-based Windows DNS implementation, Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 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. +SRG-APP-000516-DNS-000101<GroupDescription></GroupDescription>WDNS-CM-000021The Windows 2012 DNS Server must implement internal/external role separation.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58613SV-73043CCI-000366Configure separate DNS servers for each of the external and internal networks.Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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, 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.SRG-APP-000516-DNS-000102<GroupDescription></GroupDescription>WDNS-CM-000022The Windows 2012 DNS Server authoritative for local zones must only point root hints to the DNS servers that host the internal root domain.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73045V-58615CCI-000366Log 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 the root hints from the DNS Manager, the CACHE.DNS file and from Active Directory for name servers outside of the internal network. +Replace the existing root hints with new root hints of internal servers. +If the DNS server is forwarding, click to select the : "Do not use recursion for this domain" check box on the "Forwarders" tab in DNS Manager to make sure that the root hints will not be used. +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 or entries on the "Root Hints" tab under "Name servers:" are external to the local network, this is a finding. +SRG-APP-000516-DNS-000103<GroupDescription></GroupDescription>WDNS-CM-000023The DNS name server software must be at the latest version.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58617SV-73047CCI-000366Apply all related Microsoft Operating System IAVM patches to the DNS server.Consult with the network IAVM scanner to confirm all Microsoft Operating System IAVMs have been applied to the Windows DNS server. + +If all Microsoft Operating System IAVMs have not been applied to the DNS server, this is a finding. +SRG-APP-000516-DNS-000113<GroupDescription></GroupDescription>WDNS-CM-000024The Windows 2012 DNS Servers zone files must not include resource records that resolve to a fully qualified domain name residing in another zone.<VulnDiscussion>If a name server were able to claim authority for a resource record in a domain for which it was not authoritative, this would pose a security risk. In this environment, an adversary could use illicit control of a name server to impact IP address resolution beyond the scope of that name server (i.e., by claiming authority for records outside of that server's zones). Fortunately, all but the oldest versions of BIND and most other DNS implementations do not allow for this behavior. Nevertheless, the best way to eliminate this risk is to eliminate from the zone files any records for hosts in another zone. + +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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58619SV-73049CCI-000366Remove any resource records in a zone file if the resource record resolves to a fully qualified domain name residing in another zone.Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. + +Confirm with the DNS administrator that the hosts defined in the zone files do not resolve to hosts in another zone with its fully qualified domain name. + +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. 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 resource records are maintained that resolve to a fully qualified domain name in another zone, and the usage is not for resource records resolving to hosts that 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 with a documented and approved mission need, this is a finding.SRG-APP-000516-DNS-000114<GroupDescription></GroupDescription>WDNS-CM-000025The Windows 2012 DNS Servers zone files must not include CNAME records pointing to a zone with lesser security for more than six months.<VulnDiscussion>The use of CNAME records for exercises, tests, or zone-spanning (pointing to zones with lesser security) aliases should be temporary (e.g., to facilitate a migration) and not be in place for more than six months. 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73051V-58621CCI-000366Remove 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).Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 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 (i.e., zones of lesser security)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.SRG-APP-000516-DNS-000500<GroupDescription></GroupDescription>WDNS-CM-000026Non-routable IPv6 link-local scope addresses must not be configured in any zone.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73053V-58623CCI-000366The SA should remove any link-local addresses and replace with appropriate Site-Local or Global scope addresses.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.SRG-APP-000516-DNS-000500<GroupDescription></GroupDescription>WDNS-CM-000027AAAA addresses must not be configured in a zone for hosts that are not IPv6-aware.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58625SV-73055CCI-000366Remove any IPv6 records for hosts which are not IPv6-aware.Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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, 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.SRG-APP-000516-DNS-000500<GroupDescription></GroupDescription>WDNS-CM-000028IPv6 protocol must be disabled unless the Windows 2012 DNS server is configured to answer for and hosting IPv6 AAAA records.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58627SV-73057CCI-000366Log 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 “Disable all IPv6 components”. + +As an alternative to using the GPO setting, the registry setting may also be altered directly to reflect: +HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters \ +Set the value for “DisabledComponents” to “255 (0xff)”. + +Note: If the Windows 2012 DNS server is hosting IPv6 records, this requirement is not applicable. If the Windows 2012 DNS server is only hosting IPv4 records, this requirement must be met. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. + +From a command prompt, run regedit. +In the User Account Control dialog box, click Continue. +In Registry Editor, locate and then click the following registry subkey: +HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters \ +Verify the value for “DisabledComponents” is “255 (0xff)”. + +If the “DisabledComponents” entry is nonexistent, this is a finding. + +If the “DisabledComponents” exists but is not set to “255 (0xff)”, and the DNS server is not hosting any AAAA records, this is a finding. +SRG-APP-000142-DNS-000014<GroupDescription></GroupDescription>WDNS-CM-000029The Windows 2012 DNS Server must be configured to prohibit or restrict unapproved ports and protocols.<VulnDiscussion>In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. + +Applications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services); however, doing so increases risk over limiting the services provided by any one component. + +To support the requirements and principles of least functionality, the application must support the organizational requirements by providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues. + +On Windows 2012 DNS Server, during DNS resolution, DNS messages are sent from DNS clients to DNS servers or between DNS servers. Messages are sent over UDP and DNS servers bind to UDP port 53. When the message length exceeds the default message size for a User Datagram Protocol (UDP) datagram (512 octets), the first response to the message is sent with as much data as the UDP datagram will allow, and then the DNS server sets a flag indicating a truncated response. The message sender can then choose to reissue the request to the DNS server using TCP (over TCP port 53). The benefit of this approach is that it takes advantage of the performance of UDP but also has a backup failover solution for longer queries. + +In general, all DNS queries are sent from a high-numbered source port (49152 or above) to destination port 53, and responses are sent from source port 53 to a high-numbered destination port.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73059V-58629CCI-000382Re-install DNS.By default, the Windows 2012 DNS Server listens on TCP 53 and opens UDP ports 53. Also by default, Windows 2012 DNS Server sends from random, high-numbered source ports 49152 and above. + +To confirm the listening ports, log onto Windows 2012 DNS Server as an Administrator. +Open a command window with the “Run-as Administrator” option. + +In the command window, type the following command: +netstat -a -b |more <enter> + +The result is a list of all services running on the server, with the respective “LISTENING TCP” and “OPEN UDP” ports being used. + +Find Windows 2012 DNS Server service and verify the State is "LISTENING" on TCP port 53 and that UDP 53 is listed (indicating it is OPEN). + +If the server shows UDP 53 in results list and shows TCP port 53 as “LISTENING”, this is not a finding. +SRG-APP-000390-DNS-000048<GroupDescription></GroupDescription>WDNS-IA-000001The Windows 2012 DNS Server must require devices to re-authenticate for each dynamic update request connection attempt.<VulnDiscussion>Without re-authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. + +In addition to the re-authentication requirements associated with session locks, organizations may require re-authentication of devices, including, but not limited to, the following other situations: +(i) When authenticators change; +(ii) When roles change; +(iii) When security categories of information systems change; +(iv) After a fixed period of time; or +(v) Periodically. + +DNS does perform server authentication when DNSSEC or TSIG/SIG(0) are used, but this authentication is transactional in nature (each transaction has its own authentication performed). So this requirement is applicable for every server-to-server transaction request.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58631SV-73061CCI-002039Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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, and from the displayed context menu, go to Properties. + +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.Authentication of dynamic updates is accomplished in Windows Server 2012 DNS by configuring the zones to only accept secure dynamic updates. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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, and from the displayed context menu, go to Properties. + +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.SRG-APP-000158-DNS-000015<GroupDescription></GroupDescription>WDNS-IA-000002The Windows 2012 DNS Server must uniquely identify the other DNS server before responding to a server-to-server transaction.<VulnDiscussion>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 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58633SV-73063CCI-000778Complete 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 or Local Administrator 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”.Note: This requirement applies to any Windows DNS Server which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. + +If the Windows 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. +SRG-APP-000394-DNS-000049<GroupDescription></GroupDescription>WDNS-IA-000003The secondary Windows DNS name servers must cryptographically authenticate zone transfers from primary name servers.<VulnDiscussion>Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices can access the system. + +This requirement 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)).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58635SV-73065CCI-001958Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the DNS server using the account designated as Administrator or DNS Administrator. +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. + +In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. + +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +Authenticity of zone transfers within Windows AD integrated zones is accomplished by AD replication. + +For zones which are completely AD-integrated, this check is not a finding. + +For authenticity of zone transfers between non-AD-integrated zones, DNSSEC must be implemented. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, indicating the zone has been signed with DNSSEC, this is a finding. +SRG-APP-000001-DNS-000001<GroupDescription></GroupDescription>WDNS-IA-000004The Windows DNS primary server must only send zone transfers to a specific list of secondary name servers.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73067V-58637CCI-001958Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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”.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.SRG-APP-000347-DNS-000041<GroupDescription></GroupDescription>WDNS-IA-000005The Windows 2012 DNS Server must provide its identity with returned DNS information by enabling DNSSEC and TSIG/SIG(0).<VulnDiscussion>Weakly bound credentials can be modified without invalidating the credential; therefore, non-repudiation can be violated. + +This requirement supports audit requirements that provide organizational personnel with the means to identify who produced specific information in the event of an information transfer. Organizations and/or data owners determine and approve the strength of the binding between the information producer and the information based on the security category of the information and relevant risk factors. + +DNSSEC and TSIG/SIG(0) both use digital signatures to establish the identity of the producer of particular pieces of information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58639SV-73069CCI-001958Sign, or re-sign, the hosted zone(s) on the DNS server being validated. +Log on to the DNS server using the account designated as Administrator or DNS Administrator. + +In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. + +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. + +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. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000176-DNS-000017<GroupDescription></GroupDescription>WDNS-IA-000006The Windows 2012 DNS Server must be configured to enforce authorized access to the corresponding private key.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58641SV-73071CCI-000186Access 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.Access Windows Explorer. + +Navigate to the following location: + +%ALLUSERSPROFILE%\Microsoft\Crypto +Note: If the %ALLUSERSPROFILE%\Microsoft\Crypto folder doesn't exist, this is not applicable. + +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. + +SRG-APP-000176-DNS-000018<GroupDescription></GroupDescription>WDNS-IA-000007The Windows 2012 DNS Server key file must be owned by the account under which the Windows 2012 DNS Server service is run.<VulnDiscussion>To enable zone transfer (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 most key generation utilities used with DNSSEC is Base64-encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73073V-58643CCI-000186Access 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. +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 +Note: If the %ALLUSERSPROFILE%\Microsoft\Crypto folder doesn't exist, this is not applicable. + +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. +SRG-APP-000176-DNS-000019<GroupDescription></GroupDescription>WDNS-IA-000008The Windows 2012 DNS Server permissions must be set so that the key file can only be read or modified by the account that runs the name server software.<VulnDiscussion>To enable zone transfer (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 most key generation utilities used with DNSSEC is Base64-encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58645SV-73075CCI-000186Access Windows Explorer. + +Navigate to the following location: +%ALLUSERSPROFILE%\Microsoft\Crypto + +Modify permissions on the folder, sub-folders and files to “FULL CONTROL” for “SYSTEM” and Administrators and to “READ” for all other Users/Groups. +Access Windows Explorer. + +Navigate to the following location: +%ALLUSERSPROFILE%\Microsoft\Crypto +Note: If the %ALLUSERSPROFILE%\Microsoft\Crypto folder doesn't exist, this is not applicable. + +Verify the permissions on the folder, sub-folders and files are limited to “SYSTEM” and Administrators for “FULL CONTROL”. + +If any other user or group has greater than READ permissions to the %ALLUSERSPROFILE%\Microsoft\Crypto folder, sub-folders and files, this is a finding. +SRG-APP-000176-DNS-000094<GroupDescription></GroupDescription>WDNS-IA-000009The private key corresponding to the ZSK must only be stored on the name server that does support dynamic updates.<VulnDiscussion>The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. + +This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept off-line.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73077V-58647CCI-000186Ensure the private key corresponding to the ZSK is only stored on the name server accepting dynamic updates.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. + +Note: This requirement is not applicable to servers with only a caching role. + +For Active Directory-integrated zones, private zone signing keys replicate automatically to all primary DNS servers through Active Directory replication. Each authoritative server signs its own copy of the zone when it receives the key. For optimal performance, and to prevent increasing the size of the Active Directory database file, the signed copy of the zone remains in memory for Active Directory-integrated zones. A DNSSEC-signed zone is only committed to disk for file-backed zones. Secondary DNS servers pull a full copy of the zone, including signatures, from the primary DNS server. + +If all DNS servers are AD integrated, this check is not applicable. + +If a DNS server is not AD integrated and has file-backed zones, does not accept dynamic updates and has a copy of the private key corresponding to the ZSK, this is a finding.SRG-APP-000401-DNS-000051<GroupDescription></GroupDescription>WDNS-IA-000011The Windows 2012 DNS Server must implement a local cache of revocation data for PKIauthentication in the event revocation information via the network is not accessible.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73079V-58649CCI-001991Configure local revocation data to be used in the event access to Certificate Authorities is hindered.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.SRG-APP-000516-DNS-000077<GroupDescription></GroupDescription>WDNS-SC-000001The salt value for zones signed using NSEC3 RRs must be changed every time the zone is completely re-signed.<VulnDiscussion>NSEC records list the resource record types for the name, as well as the name of the next resource record. With this information it is revealed that the resource record type for the name queried, or the resource record name requested, does not exist. NSEC uses the actual resource record names, whereas NSEC3 uses a one-way hash of the name. In this way, walking zone data from one record to the next is prevented, at the expense of some CPU cycles both on the authoritative server as well as on the resolver. To prevent giving access to an entire zone file, NSEC3 should be configured, and, in order to use NSEC3, RSA/SHA-1 should be used as the algorithm, as some resolvers that understand RSA/SHA-1 might not understand NSEC3. Using RSA/SHA-256 is a safe alternative.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73081V-58651CCI-002450Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. + +Re-validate the NSEC3PARAM Inception date and time against the DNSKEY date and time.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. + +In Windows 2012, the NSEC3 salt values are automatically changed when the zone is resigned. + +To validate: +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. + +Review the zone's RRs in the right window pane. + +Determine the RRSIG NSEC3PARAM's Inception (in the Data column). Compare the Inception to the RRSIG DNSKEY Inception. The date and time should be the same. + +If the NSEC3PARAM's Inception date and time is different than the DNSKEY Inception Date and Time, this is a finding.SRG-APP-000213-DNS-000024<GroupDescription></GroupDescription>WDNS-SC-000002The Windows 2012 DNS Server must include data origin with authoritative data the system returns in response to external name/address resolution queries.<VulnDiscussion>The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. The security objective is to verify the integrity of each response received. An integral part of integrity verification is to ensure that valid data has originated from the right source. Establishing trust in the source is called data origin authentication. + +The security objectives--and consequently the security services--that are required for securing the DNS query/response transaction are data origin authentication and data integrity verification. + +The specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF's DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73083V-58653CCI-001178Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the DNS server using the account designated as Administrator or DNS Administrator. + +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. + +In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. + +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +Authenticity of query responses is provided with DNSSEC signing of zones. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by Windows 2012 DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000420-DNS-000053<GroupDescription></GroupDescription>WDNS-SC-000003The Windows 2012 DNS Servers IP address must be statically defined and configured locally on the server.<VulnDiscussion>The major threat associated with DNS forged responses or failures are the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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, such as with DNSSEC, between the name servers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73085V-58655CCI-000366CCI-002463Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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.Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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.SRG-APP-000420-DNS-000053<GroupDescription></GroupDescription>WDNS-SC-000004The Windows 2012 DNS Server must return data information in responses to internal name/address resolution queries.<VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58657SV-73087CCI-000366CCI-002463Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. + +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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +By default, when DNS servers are configured with DNSSEC signed zones, they will automatically respond to query requests, providing validating data in the response, whenever the query requests that validation. Since this takes place inherently when the zone is signed with DNSSEC, the requirement is satisfied by ensuring zones are signed. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000421-DNS-000054<GroupDescription></GroupDescription>WDNS-SC-000005The Windows 2012 DNS Server must use DNSSEC data within queries to confirm data origin to DNS resolvers.<VulnDiscussion>The major threat associated with DNS forged responses or failures are the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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. + +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. + +In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73089V-58659CCI-000366CCI-002464Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. + +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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000422-DNS-000055<GroupDescription></GroupDescription>WDNS-SC-000006WINS lookups must be disabled on the Windows 2012 DNS Server.<VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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. + +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. + +In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries. + +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. In order to be assured only the DNSSEC-signed data is being returned, WINS lookups must be disabled.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58661SV-73091CCI-002462Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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, 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”.Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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, 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.SRG-APP-000422-DNS-000055<GroupDescription></GroupDescription>WDNS-SC-000007The Windows 2012 DNS Server must use DNSSEC data within queries to confirm data integrity to DNS resolvers.<VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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. + +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. + +In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73093V-58663CCI-002462Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. + +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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000214-DNS-000025<GroupDescription></GroupDescription>WDNS-SC-000008The Windows 2012 DNS Server must be configured with the DS RR carrying the signature for the RR that contains the public key of the child zone.<VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. + +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. + +In DNS, trust in the public key of the source is established by starting from a trusted name server and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. + +A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and Domain Name System Security Extensions (DNSSEC). + +When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor. A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate. In DNS, a trust anchor is a DNSKEY that is placed into a validating resolver so the validator can cryptographically validate the results for a given request back to a known public key (the trust anchor). + +An example means to indicate the security status of child subspaces is through the use of delegation signer (DS) resource records in the DNS. + +Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Without path validation and a chain of trust, there can be no trust that the data integrity authenticity has been maintained during a transaction.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73095V-58665CCI-001179Sign, or re-sign, the hosted zone(s) on the DNS server being validated. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. + +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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000215-DNS-000003<GroupDescription></GroupDescription>WDNS-SC-000009The Windows 2012 DNS Server must enforce approved authorizations between DNS servers through the use of digital signatures in the RRSet.<VulnDiscussion>A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all application information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data. + +Application-specific examples of enforcement occur in systems that employ rule sets or establish configuration settings that restrict information system services or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics). + +Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy. + +Within the context of DNS, this is applicable in terms of controlling the flow of DNS information between systems, such as DNS zone transfers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73097V-58667CCI-001663Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. + +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters.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. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. + +Review the records for the zone and ensure the complete RRSet of records are present: RRSIG, NSEC3, DNSKEY, indicating DNSSEC compliance. + +If the RRSet of records are not in the zone, this is a finding.SRG-APP-000215-DNS-000003<GroupDescription></GroupDescription>WDNS-SC-000010The Name Resolution Policy Table (NRPT) must be configured in Group Policy to enforce clients to request DNSSEC validation for a domain.<VulnDiscussion>The Name Resolution Policy Table (NRPT) is used to require DNSSEC validation. The NRPT can be configured in local Group Policy for a single computer or domain Group Policy for some or all computers in the domain.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73099V-58669CCI-001663Implement this fix for configuring name resolvers, to include DNS servers configured for caching role only. + +On Domain Controller, on the Server Manager menu bar, click Tools, and then click Group Policy Management. + +In the Group Policy Management console tree, under Domains >; domainname >; Group Policy Objects, right-click Default Domain Policy, and then click Edit. + +In the Group Policy Management Editor console tree, navigate to Computer Configuration >; Policies >; Windows Settings >; Name Resolution Policy. + +In the details pane, under Create Rules and to which part of the namespace does this rule apply, choose Suffix from the drop-down list and type domain.mil next to Suffix. + +On the DNSSEC tab, select the Enable DNSSEC in this rule check box and then under Validation select the Require DNS clients to check that name and address data has been validated by the DNS server check box. + +In the bottom right corner, click Create and then verify that a rule for domain.mil was added under Name Resolution Policy Table. + +Click Apply, and then close the Group Policy Management Editor. + +Open a Windows PowerShell prompt and enter the following commands: +gpupdate /force <enter> +get-dnsclientnrptpolicy <enter> +In the results, select the True for "DnsSecValidationRequired" setting for the domain.mil namespace.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. + +The Name Resolution Policy Table (NRPT) is configured in, and deployed to clients from, Group Policy and will be pushed to all clients in the domain. The Active Directory zones will be signed and the clients, with NRPT, will require a validation of signed data when querying. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. + +At the Windows PowerShell prompt, type the following command: + +get-dnsclientnrptpolicy <enter> + +In the results, verify the "DnsSecValidationRequired" is True. + +If there are no results to the get-dnsclientnrptpolicy cmdlet or the "DnsSecValidationRequired" is not True, this is a finding.SRG-APP-000215-DNS-000026<GroupDescription></GroupDescription>WDNS-SC-000011The Windows 2012 DNS Server must be configured to validate an authentication chain of parent and child domains via response data.<VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. +Like the DNSKEY resource record, the delegation signer (DS) resource record can be used to create a trust anchor for a signed zone. The DS record is smaller in size than a DNSKEY record because it contains only a hash of the public key. +The DS record is not added to a zone during the signing process like some DNSSEC-related resource records, even if a delegation already exists in the zone. To add a DS record, you must manually add or import it. Fortunately, the DS resource record set (DSSET) is automatically added as a file to the Key Master when a zone is signed. The DSSET file can be used with the Import-DnsServerResourceRecordDS cmdlet to import DS records to the parent zone. + +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. + +DNSSEC provides the means to verify integrity assurances for the host/service name to network address resolution information obtained through the service. By using the delegation signer (DS) resource records in the DNS, the security status of a child domain can be validated. The DS resource record is used to identify the DNSSEC signing key of a delegated zone. + +Starting from a trusted name server (such as the root name server) and down to the current source of response through successive verifications of signature of the public key of a child by its parent, the chain of trust is established. The public key of the trusted name servers is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. This requires that responses consist of not only the requested RRs but also an authenticator associated with them. In DNSSEC, this authenticator is the digital signature of a Resource Record (RR) Set. The digital signature of an RRSet is encapsulated through a special RRType called RRSIG. The DNS client using the trusted public key of the source (whose trust has just been established) then verifies the digital signature to detect if the response is valid or bogus. + +This control enables the DNS to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Without indication of the security status of a child domain and enabling verification of a chain of trust, integrity and availability of the DNS infrastructure cannot be assured.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58671SV-73101CCI-001663A DS records must be added manually or imported. + +The DS resource record set (DSSET) is automatically added as a file to the Key Master when a zone is signed. + +This file can be used with the Import-DnsServerResourceRecordDS cmdlet to import DS records to the parent zone. + +Example: +PS C:\> Import-DnsServerResourceRecordDS -ZoneName adatum.com -DSSetFile "c:\windows\system32\dns\dsset-corp.adatum.com" + +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. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: + +PS C:\> Get-DnsServerResourceRecord -ZoneName adatum.com -RRType DS + +Replace adatum.com with the parent zone on the DNS server being evaluated. + +HostName RecordType Timestamp TimeToLive RecordData +-------- ---------- --------- ---------- ---------- +corp DS 0 01:00:00 [58555][Sha1][RsaSha1NSec3] +corp DS 0 01:00:00 [58555][Sha256][RsaSha1NSec3] +corp DS 0 01:00:00 [63513][Sha1][RsaSha1NSec3] +corp DS 0 01:00:00 [63513][Sha256][RsaSha1NSec3] + +If the results do not show the DS records for child domain(s), this is a finding. + +In the previous example, DS records for the child zone, corp.adatum.com, were imported into the parent zone, adatum.com, by using the DSSET file that is located in the c:\windows\system32\dns directory. The DSSET file was located in this directory because the local DNS server is the Key Master for the child zone. + +If the Key Master DNS server for a child zone is not the same computer as the primary authoritative DNS server for the parent zone where the DS record is being added, the DSSET file must be obtained for the child zone and made available to the primary authoritative server for the parent zone. Alternatively, the DS records can be added manually. +SRG-APP-000215-DNS-000026<GroupDescription></GroupDescription>WDNS-SC-000012Trust anchors must be exported from authoritative Windows 2012 DNS Servers and distributed to validating Windows 2012 DNS Servers.<VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. + +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. + +DNSSEC provides the means to verify integrity assurances for the host/service name to network address resolution information obtained through the service. By using the delegation signer (DS) resource records in the DNS, the security status of a child domain can be validated. The DS resource record is used to identify the DNSSEC signing key of a delegated zone. + +Starting from a trusted name server (such as the root name server) and down to the current source of response through successive verifications of signature of the public key of a child by its parent, the chain of trust is established. The public key of the trusted name servers is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. This requires that responses consist of not only the requested RRs but also an authenticator associated with them. In DNSSEC, this authenticator is the digital signature of a Resource Record (RR) Set. The digital signature of an RRSet is encapsulated through a special RRType called RRSIG. The DNS client using the trusted public key of the source (whose trust has just been established) then verifies the digital signature to detect if the response is valid or bogus. + +This control enables the DNS to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Without indication of the security status of a child domain and enabling verification of a chain of trust, integrity and availability of the DNS infrastructure cannot be assured. + +A trust anchor is a preconfigured public key associated with a specific zone. A validating DNS server must be configured with one or more trust anchors in order to perform validation. If the DNS server is running on a domain controller, trust anchors are stored in the forest directory partition in Active Directory Domain Services (AD DS) and can be replicated to all domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named TrustAnchors.dns. A DNS server running Windows Server 2012 or Windows Server 2012 R2 also displays configured trust anchors in the DNS Manager console tree in the Trust Points container. Trust anchors can also be viewed by executing Windows PowerShell commands or Dnscmd.exe at a Windows command prompt.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73103V-58673CCI-001663Log onto the primary DNS server and click Windows Explorer on the taskbar. + +Navigate to C:\Windows\System32, right-click the dns folder, point to Share with, and then click Advanced sharing. + +In the dns Properties dialog box, click Advanced Sharing, select the Share this folder check box, verify the Share name is dns, and then click OK. + +Click Close and then close Windows Explorer. + +Log onto each of the validating Windows 2012 DNS Servers. + +In the DNS Manager console tree, navigate to the Trust Points folder. + +Right-click Trust Points, point to Import, and then click DNSKEY. + +In the Import DNSKEY dialog box, type \\primaryhost\dns\keyset-domain.mil (where primaryhost represent the FQDN of the Primary DNS Server and domain.mil represents the zone(s)). + +Click OK. +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. + +Log onto each of the validating Windows 2012 DNS Servers. + +In the DNS Manager console tree, navigate to each hosted zone under the Trust Points folder. + +Two DNSKEY trust points should be displayed, one for the active key and one for the standby key. + +If each validating Windows 2012 DNS Servers does not reflect the DNSKEY trust points for each of the hosted zone(s), this is a finding. +SRG-APP-000215-DNS-000026<GroupDescription></GroupDescription>WDNS-SC-000013Automatic Update of Trust Anchors must be enabled on key rollover.<VulnDiscussion>A trust anchor is a preconfigured public key associated with a specific zone. A validating DNS server must be configured with one or more trust anchors in order to perform validation. If the DNS server is running on a domain controller, trust anchors are stored in the forest directory partition in Active Directory Domain Services (AD DS) and can be replicated to all domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named TrustAnchors.dns. A DNS server running Windows Server 2012 or Windows Server 2012 R2 also displays configured trust anchors in the DNS Manager console tree in the Trust Points container. Trust anchors can also be viewed by executing Windows PowerShell commands or Dnscmd.exe at a Windows command prompt.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58675SV-73105CCI-001663Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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. + +From the displayed context menu, click DNSSEC>>Properties. + +Click the KSK tab. + +For each KSK that is listed under Key signing keys (KSKs), click the KSK, click Edit, and in the Key Rollover section, select the "Enable automatic rollover" check box.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. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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. + +From the displayed context menu, click DNSSEC>>Properties. + +Click the KSK tab. + +For each KSK that is listed under Key signing keys (KSKs), click the KSK, click Edit, and in the Key Rollover section verify the "Enable automatic rollover" check box is selected. + +If the "Enable automatic rollover" check box is not selected for every KSK listed, this is a finding.SRG-APP-000423-DNS-000056<GroupDescription></GroupDescription>WDNS-SC-000014The Windows DNS secondary servers must request data origin authentication verification from the primary server when requesting name/address resolution.<VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data origin authentication must be performed to thwart these types of attacks. + +Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58677SV-73107CCI-002465Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters.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. + +Validate this check from either a Windows 8 client or a Windows 2008 or higher server, authenticated as a Domain Administrator. + +Determine a valid host in the zone. + +Open the Windows PowerShell prompt on the Windows 8/Windows 2008 or higher client. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding.SRG-APP-000424-DNS-000057<GroupDescription></GroupDescription>WDNS-SC-000015The Windows DNS secondary server must request data integrity verification from the primary server when requesting name/address resolution.<VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks. + +Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73109V-58679CCI-002466Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. + +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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000425-DNS-000058<GroupDescription></GroupDescription>WDNS-SC-000017The Windows DNS secondary server must validate data integrity verification on the name/address resolution responses received from primary name servers.<VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks. + +Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58681SV-73111CCI-002467Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. + +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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000426-DNS-000059<GroupDescription></GroupDescription>WDNS-SC-000018The Windows DNS secondary server must validate data origin verification authentication on the name/address resolution responses received from primary name servers.<VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data origin authentication verification must be performed to thwart these types of attacks. + +Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58683SV-73113CCI-002468Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. + +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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000219-DNS-000028<GroupDescription></GroupDescription>WDNS-SC-000019The Windows 2012 DNS Server must protect the authenticity of zone transfers via transaction signing.<VulnDiscussion>Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. This applies to server-to-server (zone transfer) transactions 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 2012 DNS Server. + +To meet the requirement for authentication between Windows DNS servers, IPsec will be implemented between the Windows DNS servers which hosts any non-AD-integrated zones.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73115V-58685CCI-001184Complete the following procedures twice for each pair of name servers. + +First create a rule for UDP connections, and then create a rule for TCP connections. + +Refer to the U_Windows_Domain_Name_Service_2012_Overview.pdf for Microsoft links for this procedure. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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 generated by the internally-managed server performing the Active Directory Certificate Services (AD CS) role, click Next. + +On Profile, accept default selections, click Next. + +On Name, enter a name applicable to the rule's function (i.e., DNSSEC UDP), click Finish.NOTE: This requirement applies to any Windows 2012 DNS Servers which host non-AD-integrated zones (file based) even if the DNS servers host AD-integrated zones, too. + +If the Windows 2012 DNS Servers only host AD-integrated zones, this requirement is not applicable. + +To protect authenticity of zone transfers between Windows 2012 DNS Servers with file based zones, IPsec must be configured on each pair of name servers in a zone transfer transaction for those zones. + +Log on to the DNS server which hosts non-AD-integrated, file based zones, using the Administrator, 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. + +Consult with the SA to determine which Rules meet the intent of the server-to-server authentication. + +If Rules exist, double-click on each Rule to verify the following: + +For the "Authentication:" tab, click on the "Customize..." button. + +On the Authentication tab, verify "Authentication mode:" is set to "Request authentication for inbound and outbound connections". + +Confirm the "Signing Algorithm" is set to "RSA (default)". + +Under "Method", ensure the "Advanced:" radio button is selected. + +Click on the "Customize" button. + +For "First authentication methods:", double-click on the entry. + +Verify the "Select the credential to use for first authentication:" has "Computer certificate from this certification authority (CA):" radio button selected. + +Review the certificate specified and verify the certificate used was generated by the internally-managed server performing the Active Directory Certificate Services (AD CS) role. + +If rules do not exist for server-to-server authentication, this is a finding. + +If rules exist for this server to authenticate to other name servers hosting the same file based zones when transacting zone transfers, but the rules are not configured with the above settings, this is a finding.SRG-APP-000219-DNS-000029<GroupDescription></GroupDescription>WDNS-SC-000020The Windows 2012 DNS Server must protect the authenticity of dynamic updates via transaction signing.<VulnDiscussion>DNS is a fundamental network service that is prone to various attacks, such as cache poisoning and man-in-the middle attacks. If communication sessions are not provided appropriate validity protections, such as the employment of DNSSEC, the authenticity of the data cannot be guaranteed. + +The combination of signing DNS zones by DNSSEC and requiring clients to send their dynamic updates securely assures the authenticity of those DNS records when providing query responses for them.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73117V-58687CCI-001184Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. + +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. + +In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. + +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +Once resource records are received by a DNS server via a secure dynamic update, the resource records will automatically become signed by DNSSEC as long as the zone was originally signed by DNSSEC. Authenticity of query responses for resource records dynamically updated can be validated by querying for whether the zone/record is signed by DNSSEC. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace 131.77.60.235 with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an Expirations, date signed, signer and signature, similar to the following: + +Name : www.zonename.mil +QueryType : RRSIG +TTL : 189 +Section : Answer +TypeCovered : CNAME +Algorithm : 8 +LabelCount : 3 +OriginalTtl : 300 +Expiration : 11/21/2014 10:22:28 PM +Signed : 10/22/2014 10:22:28 PM +Signer : zonename.mil +Signature : {87, 232, 34, 134...} + +Name : origin-www.zonename.mil +QueryType : A +TTL : 201 +Section : Answer +IP4Address : 156.112.108.76 + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000219-DNS-000030<GroupDescription></GroupDescription>WDNS-SC-000021The Windows 2012 DNS Server must protect the authenticity of query responses via DNSSEC.<VulnDiscussion>The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. An integral part of integrity verification is to ensure that valid data has originated from the right source. DNSSEC is required for securing the DNS query/response transaction by providing data origin authentication and data integrity verification through signature verification and the chain of trust.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58689SV-73119CCI-001184Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. + +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. +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. + +Authenticity of query responses is provided with DNSSEC signing of zones. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. + +Fix Text: Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. + +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. +SRG-APP-000427-DNS-000060<GroupDescription></GroupDescription>WDNS-SC-000022The Windows 2012 DNS Server must only allow the use of an approved DoD PKI-established certificate authorities for verification of the establishment of protected transactions.<VulnDiscussion>Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established. + +The DoD will only accept PKI certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates. + +TSIG and SIG(0) are not configurable in Windows 2012 DNS Server. To meet the requirement for authentication between Windows DNS servers, IPsec must be implemented between the Windows DNS servers. + +NOTE: If multiple certificates from the same CA are present on the DNS server, IPsec authentication might fail due to an incorrect certificate being chosen. For this purpose, an Active Directory Certificate Services (AD CS) role must be installed and configured as an Enterprise certification authority (CA). + +Refer to the U_Windows_Domain_Name_Service_2012_Overview.pdf for references on deploying certificates for this procedure.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73121V-58691CCI-002470Complete the following procedures twice for each pair of name servers. + +First create a rule for UDP connections, and then create a rule for TCP connections. + +Refer to the U_Windows_Domain_Name_Service_2012_Overview.pdf for Microsoft links for this procedure. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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 generated by the internally-managed server performing the Active Directory Certificate Services (AD CS) role, click Next. + +On Profile, accept default selections, click Next. + +On Name, enter a name applicable to the rule's function (i.e., DNSSEC UDP), click Finish.NOTE: This requirement applies to any Windows 2012 DNS Servers which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. + +Note: This requirement is not applicable to servers with only a caching role. + +If the Windows 2012 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. + +Consult with the SA to determine which Rules meet the intent of DNSSEC server-to-server authentication. + +Double-click on each Rule to verify the following: +For the "Authentication:" tab, click on the "Customize..." button. + +On the Authentication tab, verify "Authentication mode:" is set to "Request authentication for inbound and outbound connections". + +Confirm the "Signing Algorithm" is set to "RSA (default)". + +Under "Method", ensure the "Advanced:" radio button is selected. Click on the "Customize" button. + +For "First authentication methods:", double-click on the entry. + +Verify the "Select the credential to use for first authentication:" has "Computer certificate from this certification authority (CA):" radio button selected. + +Review the certificate specified and verify the certificate used was generated by the internally-managed server performing the Active Directory Certificate Services (AD CS) role. + +If the certificate used does not meet the requirements, this is a finding.SRG-APP-000231-DNS-000033<GroupDescription></GroupDescription>WDNS-SC-000024The Windows 2012 DNS Server must protect secret/private cryptographic keys while at rest.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58693SV-73123CCI-001199To 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. 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. +SRG-APP-000428-DNS-000061<GroupDescription></GroupDescription>WDNS-SC-000025The Windows 2012 DNS Server must not contain zone records that have not been validated in over a year.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73125V-58695CCI-002475Create 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 or Local 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 the zone. + +Select the zone records which have not been validated in over a year and revalidate.This requirement is not applicable for a Windows DNS Server which is only hosting AD-integrated zones. + +For a Windows 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 or Local 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 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. +SRG-APP-000246-DNS-000035<GroupDescription></GroupDescription>WDNS-SC-000026The Windows 2012 DNS Server must restrict individuals from using it for launching Denial of Service (DoS) attacks against other information systems.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58697SV-73127CCI-001094Configure 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 GroupReview 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 GroupSRG-APP-000247-DNS-000036<GroupDescription></GroupDescription>WDNS-SC-000027The Windows 2012 DNS Server must use DNS Notify to prevent denial of service through increase in workload.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58699SV-73129CCI-001095Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 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 or Local Administrator 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.Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 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.SRG-APP-000439-DNS-000063<GroupDescription></GroupDescription>WDNS-SC-000028The Windows 2012 DNS Server must protect the integrity of transmitted information.<VulnDiscussion>Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. + +Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. + +Confidentiality is not an objective of DNS, but integrity is. DNSSEC and TSIG/SIG(0) both digitally sign DNS information to authenticate its source and ensure its integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73131V-58701CCI-002418Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. + +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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000441-DNS-000066<GroupDescription></GroupDescription>WDNS-SC-000029The Windows 2012 DNS Server must maintain the integrity of information during preparation for transmission.<VulnDiscussion>Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58703SV-73133CCI-002421Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. + +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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000442-DNS-000067<GroupDescription></GroupDescription>WDNS-SC-000030The Windows 2012 DNS Server must maintain the integrity of information during reception.<VulnDiscussion>Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73135V-58705CCI-002420Sign, or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the Windows 2012 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 to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +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. + +Validate this check from the Windows 2012 DNS server being configured/reviewed. +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +NOTE: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000514-DNS-000075<GroupDescription></GroupDescription>WDNS-SC-000031The Windows 2012 DNS Server must implement NIST FIPS-validated cryptography for provisioning digital signatures, generating cryptographic hashes, and protecting unclassified information requiring confidentiality.<VulnDiscussion>Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. + +The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) [FIPS186] provides three algorithm choices: +* Digital Signature Algorithm (DSA) +* RSA +* Elliptic Curve DSA (ECDSA). + +Of these three algorithms, RSA and DSA are more widely available and considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. RSA is the recommended algorithm as far as this guideline is concerned. + +RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e. RSA/SHA-256, ECDSA) are also specified. + +It can be expected that name servers and clients will be able to use the RSA algorithm at the minimum. It is suggested that at least one ZSK for a zone use the RSA algorithm. + +NIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in the NIST's DSS[FIPS186]. It is expected that there will be support for Elliptic Curve Cryptography in the DNSSEC. The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before September 30th, 2015.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58557SV-72987CCI-002450Sign or re-sign, the hosted zone(s) on the DNS server being validated. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click “Sign the Zone”, either using approved saved parameters or approved custom parameters.Note: This requirement applies to any Windows DNS Server which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server only hosts AD-integrated zones and does not host any file-based zones, this is not applicable. +Validate this check from the Windows 2012 DNS server being configured/reviewed. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. + +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +Note: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. +SRG-APP-000251-DNS-000037<GroupDescription></GroupDescription>WDNS-SI-000001The Windows 2012 DNS Server must be configured to only allow zone information that reflects the environment for which it is authoritative, to include IP ranges and IP versions.<VulnDiscussion>DNS zone data for which a Windows 2012 DNS server is authoritative should represent the network for which it is responsible. If a Windows 2012 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73137V-58707CCI-001310Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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.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 or Local Administrator 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.SRG-APP-000451-DNS-000069<GroupDescription></GroupDescription>WDNS-SI-000002The Windows 2012 DNS Server must follow procedures to re-role a secondary name server as the master name server should the master name server permanently lose functionality.<VulnDiscussion>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). + +If a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly anyway in this state.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73139V-58709CCI-002754Active 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.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.SRG-APP-000333-DNS-000104<GroupDescription></GroupDescription>WDNS-SI-000003The DNS Name Server software must be configured to refuse queries for its version information.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58737SV-73167CCI-001312To disable the version being returned in queries, execute the following command: + +dnscmd /config /EnableVersionQuery 0 <enter>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 or Local Administrator 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.SRG-APP-000333-DNS-000107<GroupDescription></GroupDescription>WDNS-SI-000004The HINFO, RP, TXT and LOC RR types must not be used in the zone SOA.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58739SV-73169CCI-001312Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. + +Remove all HINFO, RP, TXT, and LOC RRs from all zones hosted by the DNS Server.Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 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.SRG-APP-000268-DNS-000039<GroupDescription></GroupDescription>WDNS-SI-000005The Windows 2012 DNS Server must, when a component failure is detected, activate a notification to the system administrator.<VulnDiscussion>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. + +If a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly anyway in this state.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58711SV-73141CCI-001328CCI-000366Implement 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.Notification to system administrator is not configurable in Windows DNS Server. 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. +SRG-APP-000473-DNS-000072<GroupDescription></GroupDescription>WDNS-SI-000006The Windows 2012 DNS Server must perform verification of the correct operation of security functions: upon system start-up and/or restart; upon command by a user with privileged access; and/or every 30 days.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73143V-58713CCI-000366CCI-002775Follow the HBSS guidance to install all HBSS products to the Windows DNS Server. 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 DNS Server. + +If all required HBSS products are not installed and/or the installed products are not enabled, this is a finding. +SRG-APP-000474-DNS-000073<GroupDescription></GroupDescription>WDNS-SI-000007The Windows 2012 DNS Server must log the event and notify the system administrator when anomalies in the operation of the signed zone transfers are discovered.<VulnDiscussion>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. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. + +If anomalies are not acted upon, security functions may fail to secure the system. + +The DNS server does not have the capability of shutting down or restarting the information system. The DNS server can be configured to generate audit records when anomalies are discovered, and the OS/NDM can then trigger notification messages to the system administrator based on the presence of those audit records.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58715SV-73145CCI-002699Implement a third-party monitoring system to detect and notify the ISSO/ISSM/DNS administrator if functionality of DNSSEC/TSIG 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.Note: If only zones hosted are AD-integrated zones, this check is not applicable. + +Notification to system administrator is not configurable in Windows 2012. In order for administrator to be notified if functionality of DNSSEC/TSIG 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 DNSSEC/TSIG 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.SRG-APP-000275-DNS-000040<GroupDescription></GroupDescription>WDNS-SI-000008The Windows 2012 DNS Server must be configured to notify the ISSO/ISSM/DNS administrator when functionality of DNSSEC/TSIG has been removed or broken.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58717SV-73147CCI-001294Implement 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.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 DNS Server. 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. +SRG-APP-000001-DNS-000115<GroupDescription></GroupDescription>WDNS-AC-000001The Windows 2012 DNS Server must restrict incoming dynamic update requests to known clients.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58237SV-72667CCI-000054Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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.Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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.SRG-APP-000348-DNS-000042<GroupDescription></GroupDescription>WDNS-AU-000001The Windows 2012 DNS Server must be configured to record, and make available to authorized personnel, who added/modified/deleted DNS zone information.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58543SV-72973CCI-001902CCI-000366Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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”.Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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.SRG-APP-000350-DNS-000044<GroupDescription></GroupDescription>WDNS-AU-000003The Windows 2012 DNS Server must, in the event of an error validating another DNS servers identity, send notification to the DNS administrator.<VulnDiscussion>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 DNS server should audit all failed attempts at server authentication through DNSSEC and TSIG/SIG(0). The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-72977V-58547CCI-000366CCI-001906To 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.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. +SRG-APP-000089-DNS-000004<GroupDescription></GroupDescription>WDNS-AU-000005The Windows 2012 DNS Server log must be enabled.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58549SV-72979CCI-000169Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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”.Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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.SRG-APP-000089-DNS-000005<GroupDescription></GroupDescription>WDNS-AU-000006The Windows 2012 DNS Server logging must be enabled to record events from all DNS server functions.<VulnDiscussion>DNS server performance can be affected when additional logging is enabled, however the enhanced DNS logging and diagnostics feature in Windows Server 2012 R2 is designed to have a very low impact on performance. Enhanced DNS logging and diagnostics in Windows Server 2012 R2 and later includes DNS Audit events and DNS Analytic events. DNS audit logs are enabled by default, and do not significantly affect DNS server performance. DNS analytical logs are not enabled by default and typically will only affect DNS server performance at very high DNS query rates. + +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. + +In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. + +Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-72981V-58551CCI-000169Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. + +Open an elevated Windows PowerShell prompt on the DNS server to which event logging needs to be enabled. + +Use the “Set-DnsServerDiagnostics” cmdlet to enable the required diagnostic events. + +Set-DnsServerDiagnostics -<diagnostic event> $true <enter> for the required diagnostic events. +For example, to set EnableLoggingForLocalLookupEvent to true, enter the following at the command line: +Set-DnsServerDiagnostics -EnableLoggingForLocalLookupEvent $true <enter> +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. + +Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account. + +Use the “Get-DnsServerDiagnostics” cmdlet to view the status of individual diagnostic events. + +Verify following diagnostic events are set to "True": +Queries, Answers, Notifications, Update, QuestionTransactions, UnmatcheResponse, SendPackets, ReceivePackets, TcpPackets, UdpPackets, FullPackets, UseSystemEventLog +Also set to “True” should be: +EnableLoggingForLocalLookupEvent +EnableLoggingForPluginDLLEvent +EnableLoggingForRecursiveLookupEvent +EnableLoggingForRemoteServerEvent +EnableLoggingForRemoteServerEvent +EnableLoggingForServerStartStopEvent +EnableLoggingForTombstoneEvent +EnableLoggingForZoneDataWriteEvent +EnableLoggingForZoneLoadingEvent + +Note: The UseSystemEventLog does not have to be set to true if all other variables are logged per the requirement and it can be validated that the events are being logged to a different log file destination. + +If all required diagnostic events are not set to "True", this is a finding. +SRG-APP-000516-DNS-000500<GroupDescription></GroupDescription>WDNS-AU-000007The Windows 2012 DNS Server logging criteria must only be configured by the ISSM or individuals appointed by the ISSM.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58553SV-72983CCI-000171CCI-000366Configure 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.evtxVerify 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. +SRG-APP-000125-DNS-000012<GroupDescription></GroupDescription>WDNS-AU-000016The Windows 2012 DNS Servers audit records must be backed up at least every seven days onto a different system or system component than the system or component being audited.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73003V-58573CCI-001348Document and implement a backup policy to back up the DNS Server's audit records at least every seven days.Consult with the System Administrator to determine the backup policy in place for Windows 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 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. +SRG-APP-000214-DNS-000079<GroupDescription></GroupDescription>WDNS-CM-000001The validity period for the RRSIGs covering the DS RR for a zones delegated children must be no less than two days and no more than one week.<VulnDiscussion>The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing. + +To prevent the impact of a compromised KSK, a delegating parent should set the signature validity period for RRSIGs covering DS RRs in the range of a few days to 1 week. This re-signing does not require frequent rollover of the parent's ZSK, but scheduled ZSK rollover should still be performed at regular intervals.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016SV-73005V-58575CCI-000366Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. + +Right-click on the zone, choose DNSSEC->Properties. + +On the ZSK tab, for DS signature validity period (hours), choose more than 48 and less than 168.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. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. + +View the validity period for the DS Resource Record. + +If the validity period for the DS Resource Record for the child domain is less than two days (48 hours) or more than one week (168 hours), this is a finding.SRG-APP-000218-DNS-000027<GroupDescription></GroupDescription>WDNS-CM-000002The Windows DNS name servers for a zone must be geographically dispersed.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Microsoft Windows 2012 Server Domain Name SystemDISADPMS TargetMicrosoft Windows 2012 Server Domain Name System4016V-58577SV-73007CCI-000366For non-AD-integrated Windows DNS Servers, distribute secondary authoritative servers to be located in different buildings from the primary authoritative server.Windows DNS Servers that are Active Directory integrated must be located where required to meet the Active Directory services. + +If all of the Windows DNS Servers are AD integrated, this check is Not Applicable. + +If any or all of the Windows 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. diff --git a/source/StigData/Processed/WindowsDnsServer-2012R2-1.14.org.default.xml b/source/StigData/Processed/WindowsDnsServer-2012R2-2.1.org.default.xml similarity index 77% rename from source/StigData/Processed/WindowsDnsServer-2012R2-1.14.org.default.xml rename to source/StigData/Processed/WindowsDnsServer-2012R2-2.1.org.default.xml index 979f25635..2fb0afb1f 100644 --- a/source/StigData/Processed/WindowsDnsServer-2012R2-1.14.org.default.xml +++ b/source/StigData/Processed/WindowsDnsServer-2012R2-2.1.org.default.xml @@ -5,7 +5,7 @@ Each setting in this file is linked by STIG ID and the valid range is in an associated comment. --> - + - + diff --git a/source/StigData/Processed/WindowsDnsServer-2012R2-1.14.xml b/source/StigData/Processed/WindowsDnsServer-2012R2-2.1.xml similarity index 84% rename from source/StigData/Processed/WindowsDnsServer-2012R2-1.14.xml rename to source/StigData/Processed/WindowsDnsServer-2012R2-2.1.xml index 71e6a73d5..aa0ce8375 100644 --- a/source/StigData/Processed/WindowsDnsServer-2012R2-1.14.xml +++ b/source/StigData/Processed/WindowsDnsServer-2012R2-2.1.xml @@ -1,6 +1,6 @@ - + - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> $null @@ -19,50 +19,8 @@ If "Root Hints" is not empty or entries on the "Root Hints" tab under "Name serv - - <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - - False - False - - EventLogLevel - 4 - 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. - - - <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - V-58543 - False - False - - EventLogLevel - 4 - 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. - - - <VulnDiscussion>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. + + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -79,7 +37,7 @@ 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. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -94,11 +52,11 @@ If forwarders are not enabled, click on the “Advanced” tab and ensure the "D 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. - - <VulnDiscussion>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. + + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - V-58579 + V-215573 False False @@ -110,7 +68,7 @@ Note: In Windows DNS Server, if forwarders are configured, the recursion setting 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. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -127,30 +85,51 @@ If the DNS Server does not forward to another DoD-managed DNS server or to the D If the "Use root hints if no forwarders are available" is selected, this is a finding. - - - - <VulnDiscussion>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. + + <VulnDiscussion>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. -The DNS server should audit all failed attempts at server authentication through DNSSEC and TSIG/SIG(0). The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> +This requirement ensures organizational personnel have a means to identify who produced or changed specific information in transfers, zone information, or DNS configuration changes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False - 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. + EventLogLevel + 4 + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. -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. +Press Windows Key + R, execute dnsmgmt.msc. -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. +Right-click the DNS server, select “Properties”. -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. +Click on the “Event Logging” tab. By default, all events are logged. -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. - +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. + + + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> + V-215648 + False + False + + EventLogLevel + 4 + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator 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. - + + + <VulnDiscussion>If a name server were able to claim authority for a resource record in a domain for which it was not authoritative, this would pose a security risk. In this environment, an adversary could use illicit control of a name server to impact IP address resolution beyond the scope of that name server (i.e., by claiming authority for records outside of that server's zones). Fortunately, all but the oldest versions of BIND and most other DNS implementations do not allow for this behavior. Nevertheless, the best way to eliminate this risk is to eliminate from the zone files any records for hosts in another zone. 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -158,27 +137,27 @@ The exceptions are glue records supporting zone delegations, CNAME records suppo False False - Log on to the DNS server using the Domain Admin or Enterprise Admin account. + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. - + Confirm with the DNS administrator that the hosts defined in the zone files do not resolve to hosts in another zone with its fully qualified domain name. 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. 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 resource records are maintained that resolve to a fully qualified domain name in another zone, and the usage is not for resource records resolving to hosts that 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 with a documented and approved mission need, this is a finding. - + <VulnDiscussion>The use of CNAME records for exercises, tests, or zone-spanning (pointing to zones with lesser security) aliases should be temporary (e.g., to facilitate a migration) and not be in place for more than six months. 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False - Log on to the DNS server using the Domain Admin or Enterprise Admin account. + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -190,10 +169,9 @@ 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 (i.e., zones of lesser security)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. - +If there are zone-spanning (i.e., zones of lesser security)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. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -207,7 +185,7 @@ If there is, verify if a documented procedure is in place to store a copy of the If there is no local cache of revocation data, this is a finding. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -219,7 +197,7 @@ For a Windows DNS Server which hosts a mix of AD-integrated zones and manually m 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. +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 or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -234,7 +212,7 @@ 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. - + <VulnDiscussion>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). If a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly anyway in this state.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -250,7 +228,7 @@ Consult with the System Administrator to determine if there are documented proce 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. - + <VulnDiscussion>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. @@ -265,7 +243,7 @@ If a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fa 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. - + <VulnDiscussion>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. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. If anomalies are not acted upon, security functions may fail to secure the system. @@ -281,7 +259,7 @@ Notification to system administrator is not configurable in Windows 2012. In ord If a third-party monitoring system is not in place to detect and notify the ISSO/ISSM/DNS administrator if functionality of DNSSEC/TSIG 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. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -296,188 +274,30 @@ Notification to system administrator is not configurable in Windows DNS Server. 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. - - - - <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - - False - False - - 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. - - - <VulnDiscussion>DNS server performance can be affected when additional logging is enabled, however the enhanced DNS logging and diagnostics feature in Windows Server 2012 R2 is designed to have a very low impact on performance. Enhanced DNS logging and diagnostics in Windows Server 2012 R2 and later includes DNS Audit events and DNS Analytic events. DNS audit logs are enabled by default, and do not significantly affect DNS server performance. DNS analytical logs are not enabled by default and typically will only affect DNS server performance at very high DNS query rates. - -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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - - False - False - - Log on to the DNS server using the Domain Admin or Enterprise Admin account. - -Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account. - -Use the “Get-DnsServerDiagnostics” cmdlet to view the status of individual diagnostic events. - -Verify following diagnostic events are set to "True": -Queries, Answers, Notifications, Update, QuestionTransactions, UnmatcheResponse, SendPackets, ReceivePackets, TcpPackets, UdpPackets, FullPackets, UseSystemEventLog -Also set to “True” should be: -EnableLoggingForLocalLookupEvent -EnableLoggingForPluginDLLEvent -EnableLoggingForRecursiveLookupEvent -EnableLoggingForRemoteServerEvent -EnableLoggingForRemoteServerEvent -EnableLoggingForServerStartStopEvent -EnableLoggingForTombstoneEvent -EnableLoggingForZoneDataWriteEvent -EnableLoggingForZoneLoadingEvent - -If all required diagnostic events are not set to "True", this is a finding. - - - - <VulnDiscussion>Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. - -The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) [FIPS186] provides three algorithm choices: -* Digital Signature Algorithm (DSA) -* RSA -* Elliptic Curve DSA (ECDSA). - -Of these three algorithms, RSA and DSA are more widely available and considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. RSA is the recommended algorithm as far as this guideline is concerned. - -RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e. RSA/SHA-256, ECDSA) are also specified. - -It can be expected that name servers and clients will be able to use the RSA algorithm at the minimum. It is suggested that at least one ZSK for a zone use the RSA algorithm. - -NIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in the NIST's DSS[FIPS186]. It is expected that there will be support for Elliptic Curve Cryptography in the DNSSEC. The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before September 30th, 2015.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - - False - False - - Note: This requirement applies to any Windows DNS Server which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server only hosts AD-integrated zones and does not host any file-based zones, this is not applicable. -Validate this check from the Windows 2012 DNS server being configured/reviewed. - -Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. -Determine a valid host in the zone. - -Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. - -Issue the following command: -(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) - -resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> - -Note: It is important to use the -server switch followed by the DNS Server name/IP address. - -The result should show the "A" record results. - -In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: - -Name: www.zonename.mil -QueryType: RRSIG -TTL: 189 -Section: Answer -TypeCovered: CNAME -Algorithm: 8 -LabelCount: 3 -OriginalTtl: 300 -Expiration: 11/21/2014 10:22:28 PM -Signed: 10/22/2014 10:22:28 PM -Signer: zonename.mil -Signature: {87, 232, 34, 134...} - -Name: origin-www.zonename.mil -QueryType: A -TTL: 201 -Section: Answer -IP4Address: ###.###.###.### - -If the results do not show the RRSIG and signature information, this is a finding. - - - - <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - - False - False - - Consult with the System Administrator to determine the backup policy in place for Windows 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. + + <VulnDiscussion>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. -If the organization does not have a backup policy in place for backing up the Windows 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. - - - - <VulnDiscussion>The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing. +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. -To prevent the impact of a compromised KSK, a delegating parent should set the signature validity period for RRSIGs covering DS RRs in the range of a few days to 1 week. This re-signing does not require frequent rollover of the parent's ZSK, but scheduled ZSK rollover should still be performed at regular intervals.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> +The DNS server should audit all failed attempts at server authentication through DNSSEC and TSIG/SIG(0). The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False - 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. - -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. - -View the validity period for the DS Resource Record. - -If the validity period for the DS Resource Record for the child domain is less than two days (48 hours) or more than one week (168 hours), this is a finding. - - - <VulnDiscussion>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. + 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. -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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - - False - False - - Windows DNS Servers that are Active Directory integrated must be located where required to meet the Active Directory services. +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 all of the Windows DNS Servers are AD integrated, this check 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. -If any or all of the Windows DNS Servers are standalone and non-AD-integrated, verify with the System Administrator their geographic location. +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 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. +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. - + + + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -493,7 +313,7 @@ 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. - + <VulnDiscussion>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. @@ -510,7 +330,7 @@ The non-AD-integrated, standalone, caching Windows 2012 DNS Server must be confi If the non-AD-integrated, standalone, caching Windows 2012 DNS Server is not configured to be DNSSEC-aware, this is a finding. - + <VulnDiscussion>Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. Confidentiality is not an objective of DNS, but integrity is. DNSSEC and TSIG/SIG(0) both digitally sign DNS information to authenticate its source and ensure its integrity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -561,7 +381,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing. To minimize the impact of a compromised ZSK, a zone administrator should set a signature validity period of 1 week for RRSIGs covering the DNSKEY RRSet in the zone (the RRSet that contains the ZSK and KSK for the zone). The DNSKEY RRSet can be re-signed without performing a ZSK rollover, but scheduled ZSK rollovers should still be performed at regular intervals.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -583,15 +403,15 @@ Right-click the zone and select DNSSEC, Properties. Select the KSK Tab. -Verify the "DNSKEY signature validity period (hours):” is set to at least 48 hours and no more than 168 hours. +Verify the "DNSKEY signature validity period (hours):” is set to at least 48 hours and no more than 168 hours. -Select the ZSK Tab. +Select the ZSK Tab. Verify the "DNSKEY signature validity period (hours):" is set to at least 48 hours and no more than 168 hours. If either the KSK or ZSK Tab "DNSKEY signature validity period (hours):" values are set to less than 48 hours or more than 168 hours, this is a finding. - + <VulnDiscussion>NSEC records list the resource record types for the name, as well as the name of the next resource record. With this information it is revealed that the resource record type for the name queried, or the resource record name requested, does not exist. NSEC uses the actual resource record names, whereas NSEC3 uses a one-way hash of the name. In this way, walking zone data from one record to the next is prevented, at the expense of some CPU cycles both on the authoritative server as well as the resolver. To prevent giving access to an entire zone file, NSEC3 should be configured and in order to use NSEC3, RSA/SHA-1 should be used as the algorithm, as some resolvers that understand RSA/SHA-1 might not understand NSEC3. Using RSA/SHA-256 is a safe alternative.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -599,11 +419,11 @@ If either the KSK or ZSK Tab "DNSKEY signature validity period (hours):" values 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. -Log on to the DNS server using the Domain Admin or Enterprise Admin account. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account. -Type the following command: +Type the following command: PS C:\> Get-DnsServerResourceRecord -ZoneName example.com <enter> @@ -616,14 +436,14 @@ If NSEC3 RRs are not returned for the zone, this is a finding. 2vf77rkf63hrgismnuvnb8... NSEC3 0 01:00:00 [RsaSha1][False][50][F2738D980008F73C] 7ceje475rse25gppr3vphs... NSEC3 0 01:00:00 [RsaSha1][False][50][F2738D980008F73C] - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False 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. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press “Windows Key + R”, execute “dnsmgmt.msc”. @@ -639,17 +459,17 @@ At a command prompt on any system, type: nslookup <enter>; -At the nslookup prompt, type: +At the nslookup prompt, type: server ###.###.###.### <enter>; -(where the ###.###.###.### is replaced by the IP of each NS record) +(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. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -667,7 +487,7 @@ If all of the authoritative name servers are located on the same network segment - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -688,12 +508,12 @@ 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. - + <VulnDiscussion>The specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF's DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. DNSSEC mechanisms involve two main processes: sign and serve, and verify signature. Before a DNSSEC-signed zone can be deployed, a name server must be configured to enable DNSSEC processing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -703,15 +523,15 @@ Before a DNSSEC-signed zone can be deployed, a name server must be configured to 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. -Log on to the DNS server using the Domain Admin or Enterprise Admin account. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 each zone. - -Review the RRs for each zone and verify all of the DNSEC record types are included for the zone. + +Review the RRs for each zone and verify all of the DNSEC record types are included for the zone. NOTE: The DS (Delegation Signer)record should also exist but the requirement for it is validated under WDNS-SC-000011. @@ -721,12 +541,12 @@ NSEC3 (Next Secure 3) If the zone does not show all of the DNSSEC record types, this is a finding. - + <VulnDiscussion>The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) [FIPS186] provides three algorithm choices: * Digital Signature Algorithm (DSA) * RSA * Elliptic Curve DSA (ECDSA). -Of these three algorithms, RSA and DSA are more widely available and hence are considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. +Of these three algorithms, RSA and DSA are more widely available and hence are considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. RSA is the recommended algorithm as far as this guideline is concerned. RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e. RSA/SHA-256, ECDSA) are also specified. It can be expected that name servers and clients will be able to use the RSA algorithm at the minimum. It is suggested that at least one ZSK for a zone use the RSA algorithm. @@ -737,13 +557,13 @@ NIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256 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. -Log on to the DNS server using the Domain Admin or Enterprise Admin account. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. +From the expanded list, click to select the zone. Review the zone's RRs in the right window pane. @@ -753,19 +573,19 @@ Confirm the encryption algorithm specified in the DNSKEY's Data is at RsaSha1, a If the specified encryption algorithm is not RsaSha1 or stronger, this is a finding. - - <VulnDiscussion>Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients. + + <VulnDiscussion>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.) +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. +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).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False - Log on to the DNS server using the Domain Admin or Enterprise Admin account. + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -779,10 +599,10 @@ If any RRs (Resource Records) on an internal DNS server resolve to IP addresses If any RRs (Resource Records) on an external DNS server resolve to IP addresses located inside the network, this is a finding. - - <VulnDiscussion>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. + + <VulnDiscussion>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.) +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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -799,7 +619,7 @@ If neither the DNS server's HBSS firewall policy nor the network firewall is con - + <VulnDiscussion>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.) @@ -818,7 +638,7 @@ If the HBSS firewall policy is not configured with the restriction, consult with 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. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -832,7 +652,7 @@ If the authoritative primary name server is AD-integrated and all secondary name 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. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -850,7 +670,7 @@ If the "Allow zone transfers:" check box is selected, verify either "Only to ser If the "To any server" option is selected, this is a finding. - + <VulnDiscussion>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. @@ -864,7 +684,7 @@ When applications provide a DAC mechanism, the DNS implementation must be able t For an Active Directory-integrated DNS implementation, this is Not Applicable by virtue of being compliant with the Windows 2008/2012 AD STIG, since DNS data within an AD-integrated zone is kept within the Active Directory. -For a file-based Windows DNS implementation, log on to the DNS server using the Domain Admin or Enterprise Admin account. +For a file-based Windows DNS implementation, Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -881,13 +701,13 @@ Review the permissions applied to the zone. No group or user should have greater If any other account/group has greater than READ privileges, this is a finding. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False - Log on to the DNS server using the Domain Admin or Enterprise Admin account. + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -901,7 +721,7 @@ If the zone is split between internal and external networks, verify separate DNS 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. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -912,7 +732,7 @@ If internal and external DNS servers have not been implemented for zones which r If all Microsoft Operating System IAVMs have not been applied to the DNS server, this is a finding. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -934,13 +754,13 @@ Verify this column does not contain any IP addresses that begin with the prefixe If any non-routable IPv6 link-local scope addresses are in any zone, this is a finding. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False - Log on to the DNS server using the Domain Admin or Enterprise Admin account. + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -954,7 +774,7 @@ If any hostnames contain both IPv4 and IPv6 addresses, confirm with the SA that If any zone contains hosts with both IPv4 and IPv6 addresses but are determined to be non-IPv6-aware, this is a finding. - + <VulnDiscussion>In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. Applications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services); however, doing so increases risk over limiting the services provided by any one component. @@ -983,7 +803,7 @@ Find Windows 2012 DNS Server service and verify the State is "LISTENING" on TCP If the server shows UDP 53 in results list and shows TCP port 53 as “LISTENING”, this is not a finding. - + <VulnDiscussion>Without re-authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. In addition to the re-authentication requirements associated with session locks, organizations may require re-authentication of devices, including, but not limited to, the following other situations: @@ -1000,7 +820,7 @@ DNS does perform server authentication when DNSSEC or TSIG/SIG(0) are used, but Authentication of dynamic updates is accomplished in Windows Server 2012 DNS by configuring the zones to only accept secure dynamic updates. -Log on to the DNS server using the Domain Admin or Enterprise Admin account. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -1018,7 +838,7 @@ 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. - + <VulnDiscussion>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 2012 DNS Server. @@ -1046,7 +866,7 @@ Click “Connection Security Rules”. Confirm at least one rule is configured for TCP 53. -Double-click on each Rule to verify the following: +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". @@ -1059,7 +879,7 @@ On the “Protocols and Ports” tab, "Protocol type:" is set to either TCP (dep If there are not rules(s) configured with the specified requirements, this is a finding. - + <VulnDiscussion>Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices can access the system. This requirement 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)).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -1111,7 +931,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, indicating the zone has been signed with DNSSEC, this is a finding. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -1143,7 +963,7 @@ If the "Allow zone transfers" check box is selected, verify that either the "Onl If the "To any server" radio button is selected, this is a finding. - + <VulnDiscussion>Weakly bound credentials can be modified without invalidating the credential; therefore, non-repudiation can be violated. This requirement supports audit requirements that provide organizational personnel with the means to identify who produced specific information in the event of an information transfer. Organizations and/or data owners determine and approve the strength of the binding between the information producer and the information based on the security category of the information and relevant risk factors. @@ -1193,7 +1013,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept off-line.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -1203,13 +1023,15 @@ This strategy is not feasible in situations in which the DNSSEC-aware name serve 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. +Note: This requirement is not applicable to servers with only a caching role. + For Active Directory-integrated zones, private zone signing keys replicate automatically to all primary DNS servers through Active Directory replication. Each authoritative server signs its own copy of the zone when it receives the key. For optimal performance, and to prevent increasing the size of the Active Directory database file, the signed copy of the zone remains in memory for Active Directory-integrated zones. A DNSSEC-signed zone is only committed to disk for file-backed zones. Secondary DNS servers pull a full copy of the zone, including signatures, from the primary DNS server. If all DNS servers are AD integrated, this check is not applicable. If a DNS server is not AD integrated and has file-backed zones, does not accept dynamic updates and has a copy of the private key corresponding to the ZSK, this is a finding. - + <VulnDiscussion>NSEC records list the resource record types for the name, as well as the name of the next resource record. With this information it is revealed that the resource record type for the name queried, or the resource record name requested, does not exist. NSEC uses the actual resource record names, whereas NSEC3 uses a one-way hash of the name. In this way, walking zone data from one record to the next is prevented, at the expense of some CPU cycles both on the authoritative server as well as on the resolver. To prevent giving access to an entire zone file, NSEC3 should be configured, and, in order to use NSEC3, RSA/SHA-1 should be used as the algorithm, as some resolvers that understand RSA/SHA-1 might not understand NSEC3. Using RSA/SHA-256 is a safe alternative.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -1220,13 +1042,13 @@ If a DNS server is not AD integrated and has file-backed zones, does not accept In Windows 2012, the NSEC3 salt values are automatically changed when the zone is resigned. To validate: -Log on to the DNS server using the Domain Admin or Enterprise Admin account. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. +From the expanded list, click to select the zone. Review the zone's RRs in the right window pane. @@ -1234,7 +1056,7 @@ Determine the RRSIG NSEC3PARAM's Inception (in the Data column). Compare the Inc If the NSEC3PARAM's Inception date and time is different than the DNSKEY Inception Date and Time, this is a finding. - + <VulnDiscussion>The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. The security objective is to verify the integrity of each response received. An integral part of integrity verification is to ensure that valid data has originated from the right source. Establishing trust in the source is called data origin authentication. The security objectives--and consequently the security services--that are required for securing the DNS query/response transaction are data origin authentication and data integrity verification. @@ -1286,15 +1108,15 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - - <VulnDiscussion>The major threat associated with DNS forged responses or failures are the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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. + + <VulnDiscussion>The major threat associated with DNS forged responses or failures are the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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, such as with DNSSEC, between the name servers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False - Log on to the DNS server using the Domain Admin or Enterprise Admin account. + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Locate the “Network Internet Access” icon, right-click on it and select "Open Network & Sharing Center". @@ -1308,7 +1130,7 @@ Verify the “Use the following IP address” is selected, with an IP address, s If the “Use the following IP address” is not selected with a configured IP address, subnet mask, and default gateway, this is a finding. - + <VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -1356,7 +1178,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>The major threat associated with DNS forged responses or failures are the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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. 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. @@ -1406,10 +1228,10 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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. -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. +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. In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries. @@ -1418,7 +1240,7 @@ If/when WINS lookups are enabled, the validity of the data becomes questionable False False - Log on to the DNS server using the Domain Admin or Enterprise Admin account. + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -1432,10 +1254,10 @@ 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. - + <VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. 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. -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. +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. In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -1482,10 +1304,10 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. -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. +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. In DNS, trust in the public key of the source is established by starting from a trusted name server and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. @@ -1540,7 +1362,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all application information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data. Application-specific examples of enforcement occur in systems that employ rule sets or establish configuration settings that restrict information system services or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics). @@ -1554,19 +1376,19 @@ Within the context of DNS, this is applicable in terms of controlling the flow o 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. -Log on to the DNS server using the Domain Admin or Enterprise Admin account. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. +From the expanded list, click to select the zone. Review the records for the zone and ensure the complete RRSet of records are present: RRSIG, NSEC3, DNSKEY, indicating DNSSEC compliance. If the RRSet of records are not in the zone, this is a finding. - + <VulnDiscussion>The Name Resolution Policy Table (NRPT) is used to require DNSSEC validation. The NRPT can be configured in local Group Policy for a single computer or domain Group Policy for some or all computers in the domain.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -1576,7 +1398,7 @@ If the RRSet of records are not in the zone, this is a finding. The Name Resolution Policy Table (NRPT) is configured in, and deployed to clients from, Group Policy and will be pushed to all clients in the domain. The Active Directory zones will be signed and the clients, with NRPT, will require a validation of signed data when querying. -Log on to the DNS server using the Domain Admin or Enterprise Admin account. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. At the Windows PowerShell prompt, type the following command: @@ -1586,8 +1408,8 @@ In the results, verify the "DnsSecValidationRequired" is True. If there are no results to the get-dnsclientnrptpolicy cmdlet or the "DnsSecValidationRequired" is not True, this is a finding. - - <VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. + + <VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. Like the DNSKEY resource record, the delegation signer (DS) resource record can be used to create a trust anchor for a signed zone. The DS record is smaller in size than a DNSKEY record because it contains only a hash of the public key. The DS record is not added to a zone during the signing process like some DNSSEC-related resource records, even if a delegation already exists in the zone. To add a DS record, you must manually add or import it. Fortunately, the DS resource record set (DSSET) is automatically added as a file to the Key Master when a zone is signed. The DSSET file can be used with the Import-DnsServerResourceRecordDS cmdlet to import DS records to the parent zone. @@ -1597,8 +1419,7 @@ DNSSEC provides the means to verify integrity assurances for the host/service na Starting from a trusted name server (such as the root name server) and down to the current source of response through successive verifications of signature of the public key of a child by its parent, the chain of trust is established. The public key of the trusted name servers is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. This requires that responses consist of not only the requested RRs but also an authenticator associated with them. In DNSSEC, this authenticator is the digital signature of a Resource Record (RR) Set. The digital signature of an RRSet is encapsulated through a special RRType called RRSIG. The DNS client using the trusted public key of the source (whose trust has just been established) then verifies the digital signature to detect if the response is valid or bogus. -This control enables the DNS to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Without indication of the security status of a child domain and enabling verification of a chain of trust, integrity and availability of the DNS infrastructure cannot be assured. -</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> +This control enables the DNS to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Without indication of the security status of a child domain and enabling verification of a chain of trust, integrity and availability of the DNS infrastructure cannot be assured.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False @@ -1630,7 +1451,7 @@ In the previous example, DS records for the child zone, corp.adatum.com, were im If the Key Master DNS server for a child zone is not the same computer as the primary authoritative DNS server for the parent zone where the DS record is being added, the DSSET file must be obtained for the child zone and made available to the primary authoritative server for the parent zone. Alternatively, the DS records can be added manually. - + <VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. 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. @@ -1657,7 +1478,7 @@ Two DNSKEY trust points should be displayed, one for the active key and one for If each validating Windows 2012 DNS Servers does not reflect the DNSKEY trust points for each of the hosted zone(s), this is a finding. - + <VulnDiscussion>A trust anchor is a preconfigured public key associated with a specific zone. A validating DNS server must be configured with one or more trust anchors in order to perform validation. If the DNS server is running on a domain controller, trust anchors are stored in the forest directory partition in Active Directory Domain Services (AD DS) and can be replicated to all domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named TrustAnchors.dns. A DNS server running Windows Server 2012 or Windows Server 2012 R2 also displays configured trust anchors in the DNS Manager console tree in the Trust Points container. Trust anchors can also be viewed by executing Windows PowerShell commands or Dnscmd.exe at a Windows command prompt.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -1665,7 +1486,7 @@ If each validating Windows 2012 DNS Servers does not reflect the DNSKEY trust po 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. -Log on to the DNS server using the Domain Admin or Enterprise Admin account. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. If not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen. @@ -1687,7 +1508,7 @@ For each KSK that is listed under Key signing keys (KSKs), click the KSK, click If the "Enable automatic rollover" check box is not selected for every KSK listed, this is a finding. - + <VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data origin authentication must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -1735,7 +1556,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -1783,7 +1604,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -1831,7 +1652,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service. Data origin authentication verification must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching DNS servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -1879,7 +1700,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. This applies to server-to-server (zone transfer) transactions 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 2012 DNS Server. @@ -1890,7 +1711,7 @@ To meet the requirement for authentication between Windows DNS servers, IPsec wi False NOTE: This requirement applies to any Windows 2012 DNS Servers which host non-AD-integrated zones (file based) even if the DNS servers host AD-integrated zones, too. - + If the Windows 2012 DNS Servers only host AD-integrated zones, this requirement is not applicable. To protect authenticity of zone transfers between Windows 2012 DNS Servers with file based zones, IPsec must be configured on each pair of name servers in a zone transfer transaction for those zones. @@ -1914,7 +1735,7 @@ If Rules exist, double-click on each Rule to verify the following: For the "Authentication:" tab, click on the "Customize..." button. On the Authentication tab, verify "Authentication mode:" is set to "Request authentication for inbound and outbound connections". - + Confirm the "Signing Algorithm" is set to "RSA (default)". Under "Method", ensure the "Advanced:" radio button is selected. @@ -1931,7 +1752,7 @@ If rules do not exist for server-to-server authentication, this is a finding. If rules exist for this server to authenticate to other name servers hosting the same file based zones when transacting zone transfers, but the rules are not configured with the above settings, this is a finding. - + <VulnDiscussion>DNS is a fundamental network service that is prone to various attacks, such as cache poisoning and man-in-the middle attacks. If communication sessions are not provided appropriate validity protections, such as the employment of DNSSEC, the authenticity of the data cannot be guaranteed. The combination of signing DNS zones by DNSSEC and requiring clients to send their dynamic updates securely assures the authenticity of those DNS records when providing query responses for them.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -1981,7 +1802,7 @@ IP4Address : 156.112.108.76 If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. An integral part of integrity verification is to ensure that valid data has originated from the right source. DNSSEC is required for securing the DNS query/response transaction by providing data origin authentication and data integrity verification through signature verification and the chain of trust.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -2032,10 +1853,10 @@ Fix Text: Sign, or re-sign, the hosted zone(s) on the DNS server being validated In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. - + <VulnDiscussion>Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established. The DoD will only accept PKI certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates. @@ -2051,6 +1872,8 @@ Refer to the U_Windows_Domain_Name_Service_2012_Overview.pdf for references on d NOTE: This requirement applies to any Windows 2012 DNS Servers which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. +Note: This requirement is not applicable to servers with only a caching role. + If the Windows 2012 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. @@ -2071,7 +1894,7 @@ Double-click on each Rule to verify the following: For the "Authentication:" tab, click on the "Customize..." button. On the Authentication tab, verify "Authentication mode:" is set to "Request authentication for inbound and outbound connections". - + Confirm the "Signing Algorithm" is set to "RSA (default)". Under "Method", ensure the "Advanced:" radio button is selected. Click on the "Customize" button. @@ -2084,7 +1907,7 @@ Review the certificate specified and verify the certificate used was generated b If the certificate used does not meet the requirements, this is a finding. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -2094,20 +1917,20 @@ The DNS server must protect the confidentiality and integrity of shared keys (fo 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. +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. - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False - Log on to the DNS server using the Domain Admin or Enterprise Admin account. + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -2128,7 +1951,7 @@ If the "Allow zone transfers" check box is selected, click on the “Notify” b If the “Notify” button is not enabled for non-AD-integrated DNS servers, this is a finding. - + <VulnDiscussion>Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. @@ -2178,7 +2001,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -2224,7 +2047,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + <VulnDiscussion>Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -2270,7 +2093,67 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. - + + <VulnDiscussion>Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. + +The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) [FIPS186] provides three algorithm choices: +* Digital Signature Algorithm (DSA) +* RSA +* Elliptic Curve DSA (ECDSA). + +Of these three algorithms, RSA and DSA are more widely available and considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. RSA is the recommended algorithm as far as this guideline is concerned. + +RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e. RSA/SHA-256, ECDSA) are also specified. + +It can be expected that name servers and clients will be able to use the RSA algorithm at the minimum. It is suggested that at least one ZSK for a zone use the RSA algorithm. + +NIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in the NIST's DSS[FIPS186]. It is expected that there will be support for Elliptic Curve Cryptography in the DNSSEC. The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before September 30th, 2015.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> + + False + False + + Note: This requirement applies to any Windows DNS Server which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server only hosts AD-integrated zones and does not host any file-based zones, this is not applicable. +Validate this check from the Windows 2012 DNS server being configured/reviewed. + +Log on to the Windows 2012 DNS server using the account designated as Administrator or DNS Administrator. +Determine a valid host in the zone. + +Open the Windows PowerShell prompt on the Windows 2012 DNS server being configured/reviewed. + +Issue the following command: +(Replace www.zonename.mil with a FQDN of a valid host in the zone being validated. Replace ###.###.###.### with the FQDN or IP address of the Windows 2012 DNS Server hosting the signed zone.) + +resolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter> + +Note: It is important to use the -server switch followed by the DNS Server name/IP address. + +The result should show the "A" record results. + +In addition, the results should show QueryType: RRSIG with an expiration, date signed, signer and signature, similar to the following: + +Name: www.zonename.mil +QueryType: RRSIG +TTL: 189 +Section: Answer +TypeCovered: CNAME +Algorithm: 8 +LabelCount: 3 +OriginalTtl: 300 +Expiration: 11/21/2014 10:22:28 PM +Signed: 10/22/2014 10:22:28 PM +Signer: zonename.mil +Signature: {87, 232, 34, 134...} + +Name: origin-www.zonename.mil +QueryType: A +TTL: 201 +Section: Answer +IP4Address: ###.###.###.### + +If the results do not show the RRSIG and signature information, this is a finding. + + + <VulnDiscussion>DNS zone data for which a Windows 2012 DNS server is authoritative should represent the network for which it is responsible. If a Windows 2012 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False @@ -2278,7 +2161,7 @@ If the results do not show the RRSIG and signature information, this is a findin 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. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. If not automatically started, initialize the “Server Manager” window by clicking its icon from the bottom left corner of the screen. @@ -2296,24 +2179,7 @@ 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. - - <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - - False - False - - 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 DNS Server. - -If all required HBSS products are not installed and/or the installed products are not enabled, this is a finding. - - - + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -2323,7 +2189,7 @@ In some installations, it may not be possible to switch over to the latest versi 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. +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Open a command window and execute the command: @@ -2338,7 +2204,7 @@ version.bind <enter> If the response returns something similar to text = "Microsoft DNS 6.1.7601 (1DB14556)", this is a finding. - + <VulnDiscussion>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. @@ -2352,7 +2218,7 @@ RRs such as HINFO and TXT provide information about software name and versions ( False False - Log on to the DNS server using the Domain Admin or Enterprise Admin account. + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. Press Windows Key + R, execute dnsmgmt.msc. @@ -2364,85 +2230,146 @@ Review the zone's Resource Records (RR) and verify HINFO, RP, and LOC RRs are no If there are any HINFO, RP, LOC, or revealing TXT RRs in any zone hosted by the DNS Server, this is a finding. - - - - - - - - Eventlog - False - - - FullControl - - - - - SYSTEM - False - - - FullControl - - - - - Administrators - False - - - FullControl - - - <VulnDiscussion>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. + + <VulnDiscussion>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. -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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> +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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - True False False - %windir%\SYSTEM32\WINEVT\LOGS\DNS Server.evtx - Verify the effective setting in Local Group Policy Editor. + This functionality should be performed by the Host Based Security System (HBSS), mandatory on all DoD systems. -Run "gpedit.msc". +Check to ensure McAfee HBSS is installed and fully operational on the Windows DNS Server. -Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment. +If all required HBSS products are not installed and/or the installed products are not enabled, this is a finding. + + + + <VulnDiscussion>Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) on any system. -If any accounts or groups other than the following are granted the "Manage auditing and security log" user right, this is a finding: +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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> + + False + False + + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. -Administrators -Auditors (if the site has an Auditors group that further limits this privilege.) +Press Windows Key + R, execute dnsmgmt.msc. -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. +On the opened DNS Manager snap-in from the left pane, expand the server name and then expand Forward Lookup Zones. -Verify the permissions on the DNS logs. +From the expanded list, click to select the zone. -Standard user accounts or groups must not have greater than READ access. +Once selected, right-click the name of the zone. -The default locations are: +From the displayed context menu, click the “Properties” option. -DNS Server %SystemRoot%\System32\Winevt\Logs\DNS Server.evtx +On the opened domain's properties box, click the “General” tab. -Using the file explorer tool navigate to the DNS Server log file. +Verify the Type: is Active Directory-Integrated. -Right click on the log file, select the “Security” tab. +Verify the Dynamic updates has "Secure only" selected. -The default permissions listed below satisfy this requirement: +If the zone is Active Directory-Integrated and the Dynamic updates are not configured for "Secure only", this is a finding. + + + <VulnDiscussion>DNS server performance can be affected when additional logging is enabled, however the enhanced DNS logging and diagnostics feature in Windows Server 2012 R2 is designed to have a very low impact on performance. Enhanced DNS logging and diagnostics in Windows Server 2012 R2 and later includes DNS Audit events and DNS Analytic events. DNS audit logs are enabled by default, and do not significantly affect DNS server performance. DNS analytical logs are not enabled by default and typically will only affect DNS server performance at very high DNS query rates. -Eventlog - Full Control -SYSTEM - Full Control -Administrators - Full Control +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. -If the permissions for these files are not as restrictive as the ACLs listed, this is a finding. +In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. + +Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> + + False + False + + Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. + +Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account. + +Use the “Get-DnsServerDiagnostics” cmdlet to view the status of individual diagnostic events. + +Verify following diagnostic events are set to "True": +Queries, Answers, Notifications, Update, QuestionTransactions, UnmatcheResponse, SendPackets, ReceivePackets, TcpPackets, UdpPackets, FullPackets, UseSystemEventLog +Also set to “True” should be: +EnableLoggingForLocalLookupEvent +EnableLoggingForPluginDLLEvent +EnableLoggingForRecursiveLookupEvent +EnableLoggingForRemoteServerEvent +EnableLoggingForRemoteServerEvent +EnableLoggingForServerStartStopEvent +EnableLoggingForTombstoneEvent +EnableLoggingForZoneDataWriteEvent +EnableLoggingForZoneLoadingEvent + +Note: The UseSystemEventLog does not have to be set to true if all other variables are logged per the requirement and it can be validated that the events are being logged to a different log file destination. + +If all required diagnostic events are not set to "True", this is a finding. + + + + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> + + False + False + + Consult with the System Administrator to determine the backup policy in place for Windows 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 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. - + + <VulnDiscussion>The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing. + +To prevent the impact of a compromised KSK, a delegating parent should set the signature validity period for RRSIGs covering DS RRs in the range of a few days to 1 week. This re-signing does not require frequent rollover of the parent's ZSK, but scheduled ZSK rollover should still be performed at regular intervals.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> + + False + False + + 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. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local 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 the zone. + +View the validity period for the DS Resource Record. + +If the validity period for the DS Resource Record for the child domain is less than two days (48 hours) or more than one week (168 hours), this is a finding. + + + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> + + False + False + + Windows DNS Servers that are Active Directory integrated must be located where required to meet the Active Directory services. + +If all of the Windows DNS Servers are AD integrated, this check is Not Applicable. + +If any or all of the Windows 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. + + + + @@ -2483,7 +2410,7 @@ If any other user or group has greater than READ privileges to the %ALLUSERSPROF - + @@ -2503,7 +2430,7 @@ If any other user or group has greater than READ privileges to the %ALLUSERSPROF <VulnDiscussion>To enable zone transfer (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 most key generation utilities used with DNSSEC is Base64-encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - V-58641 + V-215604 True False False @@ -2511,7 +2438,7 @@ If any other user or group has greater than READ privileges to the %ALLUSERSPROF %ALLUSERSPROFILE%\Microsoft\Crypto\Keys Access Services on the Windows DNS Server and locate the DNS Server Service. -Determine the account under which the DNS Server Service is running. +Determine the account under which the DNS Server Service is running. Access Windows Explorer. @@ -2527,7 +2454,7 @@ Verify the Owner on the folder, sub-folders, and files are the account under whi If any other user or group is listed as OWNER of the %ALLUSERSPROFILE%\Microsoft\Crypto folder, sub-folders, and files, this is a finding. - + @@ -2547,7 +2474,7 @@ If any other user or group is listed as OWNER of the %ALLUSERSPROFILE%\Microsoft <VulnDiscussion>To enable zone transfer (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 most key generation utilities used with DNSSEC is Base64-encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - V-58641 + V-215604 True False False @@ -2564,48 +2491,45 @@ Verify the permissions on the folder, sub-folders and files are limited to “SY If any other user or group has greater than READ permissions to the %ALLUSERSPROFILE%\Microsoft\Crypto folder, sub-folders and files, this is a finding. - - - - <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - - Present - False - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters - True - ValueData is set to 255 which disables IPv6 - Note: If the Windows 2012 DNS server is hosting IPv6 records, this requirement is not applicable. - -Log on to the DNS server using the Domain Admin or Enterprise Admin account. - -From a command prompt, run regedit. -In the User Account Control dialog box, click Continue. -In Registry Editor, locate and then click the following registry subkey: -HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters \ -Verify the value for “DisabledComponents” is “255 (0xff)”. - -If the “DisabledComponents” entry is nonexistent, this is a finding. - -If the “DisabledComponents” exists but is not set to “255 (0xff)”, and the DNS server is not hosting any AAAA records, this is a finding. - - - DisabledComponents - DWord - - - - - SeSecurityPrivilege + + + + + + Eventlog + False + + + FullControl + + + + + SYSTEM + False + + + FullControl + + + + + Administrators + False + + + FullControl + + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - Manage auditing and security log True - Administrators False False + %windir%\SYSTEM32\WINEVT\LOGS\DNS Server.evtx Verify the effective setting in Local Group Policy Editor. Run "gpedit.msc". @@ -2614,12 +2538,12 @@ Navigate to Local Computer Policy >> Computer Configuration >> Windo If any accounts or groups other than the following are granted the "Manage auditing and security log" user right, this is a finding: -Administrators +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. +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. @@ -2643,7 +2567,37 @@ Administrators - Full Control If the permissions for these files are not as restrictive as the ACLs listed, this is a finding. - + + + + <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> + + Present + False + HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters + True + ValueData is set to 255 which disables IPv6 + Note: If the Windows 2012 DNS server is hosting IPv6 records, this requirement is not applicable. If the Windows 2012 DNS server is only hosting IPv4 records, this requirement must be met. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. + +From a command prompt, run regedit. +In the User Account Control dialog box, click Continue. +In Registry Editor, locate and then click the following registry subkey: +HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters \ +Verify the value for “DisabledComponents” is “255 (0xff)”. + +If the “DisabledComponents” entry is nonexistent, this is a finding. + +If the “DisabledComponents” exists but is not set to “255 (0xff)”, and the DNS server is not hosting any AAAA records, this is a finding. + + + DisabledComponents + DWord + + + + SeRemoteInteractiveLogonRight <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> Allow log on through Remote Desktop Services @@ -2657,7 +2611,7 @@ If the permissions for these files are not as restrictive as the ACLs listed, th Administrators - + SeDenyNetworkLogonRight <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> Deny access to this computer from the network @@ -2671,7 +2625,7 @@ Administrators Guests Group - + SeDenyInteractiveLogonRight <VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> Deny log on locally @@ -2685,316 +2639,54 @@ Guests Group Guests Group - - - + + SeSecurityPrivilege <VulnDiscussion>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. -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> +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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> + Manage auditing and security log - True + True + Administrators,Auditors,Verify the permissions on the DNS logs.,Standard user accounts or groups must not have greater than READ access.,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.,Eventlog - Full Control,SYSTEM - Full Control,Administrators - Full Control False - Microsoft-Windows-DnsServer/Analytical False - Log on to the DNS server using the Domain Admin or Enterprise Admin account. -Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account. + Verify the effective setting in Local Group Policy Editor. -Use the “Get-DnsServerDiagnostics” cmdlet to view the status of individual diagnostic events. +Run "gpedit.msc". -Verify following diagnostic events are set to "True": -UseSystemEventLog +Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment. -Press “Windows Key + R”, execute “dnsmgmt.msc”. +If any accounts or groups other than the following are granted the "Manage auditing and security log" user right, this is a finding: -Right-click on the DNS server, select “Properties”. +Administrators +Auditors (if the site has an Auditors group that further limits this privilege.) -Click the “Event Logging” tab. By default, all events are logged. +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 "Errors and warnings" or "All events" is selected. +Verify the permissions on the DNS logs. -If any option other than "Errors and warnings" or "All events" is selected, this is a finding. +Standard user accounts or groups must not have greater than READ access. -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. +The default locations are: -Run “eventvwr.msc” at an elevated command prompt. +DNS Server %SystemRoot%\System32\Winevt\Logs\DNS Server.evtx -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. +Using the file explorer tool navigate to the DNS Server log file. -Right-click on the DNS Server, point to View, and then click "Show Analytic and Debug Logs". +Right click on the log file, select the “Security” tab. -Right-click on Analytical and then click “Properties”. +The default permissions listed below satisfy this requirement: -Confirm the "Enable logging" check box is selected. +Eventlog - Full Control +SYSTEM - Full Control +Administrators - Full Control -If the checkbox to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding. +If the permissions for these files are not as restrictive as the ACLs listed, this is a finding. - - <VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - V-58555 - True - False - Microsoft-Windows-DnsServer/Analytical - False - - Log on to the DNS server using the Domain Admin or Enterprise Admin account. - -Press Windows Key + R, execute dnsmgmt.msc. - -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. 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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding. - - - <VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - V-58555 - True - False - Microsoft-Windows-DnsServer/Analytical - False - - 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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding. - - - <VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - V-58555 - True - False - Microsoft-Windows-DnsServer/Analytical - False - - 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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding. - - - <VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - V-58555 - True - False - Microsoft-Windows-DnsServer/Analytical - False - - 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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding. - - - <VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - V-58555 - True - False - Microsoft-Windows-DnsServer/Analytical - False - - 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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding. - - - <VulnDiscussion>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. - -In order to compile an accurate risk assessment, it is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. It is important, therefore, to log all possible data related to events so that they can be correlated and analyzed to determine the risk. - -Data required to be captured include: whether an event was successful or failed, the event type or category, timestamps for when the event occurred, where the event originated, who/what initiated the event, affect the event had on the DNS implementation and any processes associated with the event.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - V-58555 - True - False - Microsoft-Windows-DnsServer/Analytical - False - - 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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding. - - - <VulnDiscussion>Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered, in order to compile an accurate risk assessment. Logging the actions of specific events provides a means to investigate an attack, to recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> - V-58555 - True - False - Microsoft-Windows-DnsServer/Analytical - False - - 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. - -For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. - -In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. - -Right-click DNS Server, point to View, and then click "Show Analytic and Debug Logs". - -Right-click Analytical and then click on Properties. - -Confirm the "Enable logging" check box is selected. - -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding. - - +