{"stig":{"title":"Microsoft Windows Server Domain Name System (DNS) Security Technical Implementation Guide","version":"2","release":"4"},"checks":[{"vulnId":"V-259334","ruleId":"SV-259334r960735_rule","severity":"medium","ruleTitle":"The Windows DNS Server must restrict incoming dynamic update requests to known clients.","description":"Limiting the number of concurrent sessions reduces the risk of denial of service (DoS) on any system.\n\nA DNS server's function requires it to be able to handle multiple sessions at a time, so limiting concurrent sessions could impact availability.\n\nPrimary name servers must be configured to limit the actual hosts from which they will accept dynamic updates and 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.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\". \n\nOn the opened DNS Manager snap-in from the left pane, expand the server name and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nOnce selected, right-click the name of the zone.\n\nFrom the displayed context menu, click the \"Properties\" option.\n\nOn the opened domain's properties box, click the \"General\" tab.\n\nVerify the \"Type:\" is \"Active Directory-Integrated\".\n\nVerify \"Dynamic updates\" has \"Secure only\" selected.\n\nIf the zone is \"Active Directory-Integrated\" and \"Dynamic updates\" are not configured for \"Secure only\", this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nOnce selected, right-click the name of the zone.\n\nFrom the displayed context menu, click the \"Properties\" option.\n\nOn the opened domain's properties box, click the \"General\" tab.\n\nIf the \"Type:\" is not \"Active Directory-Integrated\", configure the zone for Active Directory integration.\n\nSelect \"Secure only\" from the \"Dynamic updates:\" drop-down list.","ccis":["CCI-000054"]},{"vulnId":"V-259335","ruleId":"SV-259335r1156947_rule","severity":"medium","ruleTitle":"The Windows DNS Server must be configured to record who added/modified/deleted DNS zone information.","description":"Without a means for identifying the individual that produced the information, the information cannot be relied on. Identifying the validity of information may be delayed or deterred.\n\nThis requirement ensures organizational personnel have a means to identify who produced or changed specific information in transfers, zone information, or DNS configuration changes.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nRight-click the DNS server and select \"Properties\".\n\nClick the \"Event Logging\" tab. By default, all events are logged.\n\nVerify \"Errors and warnings\" or \"All events\" is selected.\n\nIf any option other than \"Errors and warnings\" or \"All events\" is selected, this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nIf not automatically started, initialize the \"Server Manager\" window by clicking its icon from the bottom left corner of the screen.\n\nOn the opened \"Server Manager\" window, from the left pane, click to select \"DNS\".\n\nFrom the right pane, under the \"SERVERS\" section, right-click the DNS server.\n\nFrom the displayed context menu, click the \"DNS Manager\" option.\n\nClick the \"Event Logging\" tab.\n\nSelect the \"Errors and warnings\" or \"All events\" option.\n\nClick \"Apply\".\n\nClick \"OK\".","ccis":["CCI-000366","CCI-001902"]},{"vulnId":"V-259336","ruleId":"SV-259336r1156948_rule","severity":"medium","ruleTitle":"The Windows DNS Server must notify the DNS administrator in the event of an error validating another DNS server's identity.","description":"Failing to act on validation errors may result in the use of invalid, corrupted, or compromised information. The validation of bindings can be achieved, for example, using cryptographic checksums. Validations must be performed automatically.\n\nAt 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.\n\nThe DNS server should audit all failed attempts at server authentication through DNSSEC and TSIG/SIG(0). The actual auditing is performed by the operating system/network device manager, but the configuration to trigger the auditing is controlled by the DNS server.","checkContent":"Windows DNS Servers hosting Active Directory (AD)-integrated zones transfer zone information via AD replication. Windows DNS Servers hosting non-AD-integrated zones as a secondary name server and/or not hosting AD-integrated zones use zone transfer to sync zone data.\n\nIf the Windows DNS Server hosts only AD-integrated zones and all other name servers for the zones hosted are Active Directory Domain Controllers, this requirement is not applicable.\n\nIf the Windows 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.\n\nAdministrator 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.\n\nIf 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.","fixText":"To detect and notify the administrator, configure a third-party event monitoring system or, at a minimum, document and implement a procedure to require the administrator to check the DNS logs on a routine, daily basis.","ccis":["CCI-000366","CCI-001906"]},{"vulnId":"V-259337","ruleId":"SV-259337r1156965_rule","severity":"medium","ruleTitle":"The Windows DNS Server log must be enabled.","description":"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 operating system/network device manager, but the configuration to trigger the auditing is controlled by the DNS server.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nRight-click the DNS server and select \"Properties\".\n\nClick the \"Event Logging\" tab. By default, all events are logged.\n\nVerify \"Errors and warnings\" or \"All events\" is selected.\n\nIf any option other than \"Errors and warnings\" or \"All events\" is selected, this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nRight-click the DNS server and select \"Properties\".\n\nClick the \"Event Logging\" tab. By default, all events are logged.\n\nSelect the \"Errors and warnings\" or \"All events\" option.\n\nClick \"Apply\".\n\nClick \"OK\".","ccis":["CCI-000169"]},{"vulnId":"V-259338","ruleId":"SV-259338r1028386_rule","severity":"medium","ruleTitle":"The \"Manage auditing and security log\" user right must be assigned only to authorized personnel.","description":"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 operating system/network device manager, but the configuration to trigger the auditing is controlled by the DNS server.\n\nBecause the configuration of the audit logs on the DNS server dictates which events are logged to correlate events, the permissions for configuring the audit logs must be restricted to only those with the role of information system security manager (ISSM) or those appointed by the ISSM.","checkContent":"Verify the effective setting in Local Group Policy Editor.\n\nRun \"gpedit.msc\".\n\nNavigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.\n\nIf any accounts or groups other than the following are granted the \"Manage auditing and security log\" user right, this is a finding:\n\nAdministrators \nAuditors (if the site has an Auditors group that further limits this privilege)\n\nIf an application requires this user right, this is not 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.\n\nVerify the permissions on the DNS logs.\n\nStandard user accounts or groups must not have greater than READ access.\n\nThe default locations are:\n\nDNS Server %SystemRoot%\\System32\\Winevt\\Logs\\DNS Server.evtx\n\nUse PowerShell and go to PS C:\\Windows\\System32\\winevt\\logs> icacls.exe 'dns server .evtx'\n\nThe default permissions listed below satisfy this requirement:\n\nEventlog - Full Control (I)(F)\nSYSTEM - Full Control (I)(F)\nAdministrators (I)(F)\n\nIf the permissions for these files are not as restrictive as the access control lists above, this is a finding.","fixText":"Configure the permissions on the DNS logs.\n\nStandard user accounts or groups must not have greater than READ access.\n\nThe default permissions listed below satisfy this requirement:\n\nEventlog - Full Control\nSYSTEM - Full Control\nAdministrators - Full Control\n\nThe default locations are:\n\nDNS Server %SystemRoot%\\System32\\Winevt\\Logs\\DNS Server.evtx","ccis":["CCI-000366"]},{"vulnId":"V-259339","ruleId":"SV-259339r961104_rule","severity":"medium","ruleTitle":"The validity period for the Resource Record Signatures (RRSIGs) covering the Delegation Signer (DS) Resource Record (RR) for a zone's delegated children must be no less than two days and no more than one week.","description":"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 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 zone signing key (ZSK) can use that key only during the key signing key's (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.\n\nTo 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 one 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone. \n\nView the validity period for the DS RR. \n\nIf the validity period for the DS RR for the child domain is less than two days (48 hours) or more than one week (168 hours), this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone. \n\nRight-click on the zone and choose DNSSEC >> Properties.\n \nOn the ZSK tab, for DS signature validity period (hours), choose more than 48 and less than 168.","ccis":["CCI-001179"]},{"vulnId":"V-259340","ruleId":"SV-259340r1156964_rule","severity":"medium","ruleTitle":"The Windows DNS name servers for a zone must be geographically dispersed.","description":"In addition to network-based separation, authoritative name servers should be dispersed geographically. In other words, in addition to being located on different network segments, the authoritative name servers should not all be located in the same building. One approach is to locate some authoritative name servers in their own premises and others in their internet service provider's data centers or in partnering organizations.\n\nA network administrator may choose to use a \"hidden\" primary authoritative server and have only secondary servers visible on the network. A hidden primary authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the primary authoritative name server is hidden, a secondary authoritative name server may reside in the same building as the hidden primary.","checkContent":"Windows DNS Servers that are Active Directory (AD) integrated must be located where required to meet the AD services. \n\nIf all the Windows DNS Servers are AD integrated, this check is not applicable.\n\nIf any or all the Windows DNS Servers are standalone and non-AD integrated, verify their geographic location with the system administrator.\n\nIf any or all of the authoritative name servers are located in the same building as the primary authoritative name server and the primary authoritative name server is not \"hidden\", this is a finding.","fixText":"For non-AD integrated Windows DNS Servers, distribute secondary authoritative servers to be in different buildings from the primary authoritative server.","ccis":["CCI-000366"]},{"vulnId":"V-259341","ruleId":"SV-259341r1156949_rule","severity":"medium","ruleTitle":"The Windows DNS Server must prohibit recursion on authoritative name servers for which forwarders have not been configured for external queries.","description":"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 nonexistent hosts (which constitutes a denial of service) or hosts that masquerade as legitimate ones to obtain sensitive data or passwords. \n\nTo 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.","checkContent":"Note: In Windows DNS Server, if forwarders are configured, the recursion setting must also be enabled because disabling recursion will disable forwarders.\n\nIf forwarders are not used, recursion must be disabled.\n\nIn both cases, the use of root hints must be disabled. The root hints configuration requirement is addressed in WDNS-22-000012.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select \"Properties\".\n\nClick the \"Forwarders\" tab.\n\nIf forwarders are enabled and configured, this check is not applicable.\n\nIf forwarders are not enabled, click the \"Advanced\" tab and verify the \"Disable recursion (also disables forwarders)\" check box is selected.\n\nIf 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. This is not applicable for classified networks.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select \"Properties\".\n\nClick the \"Forwarders\" tab.\n\nIf forwarders are not being used, click the \"Advanced\" tab. \n\nSelect the \"Disable recursion (also disables forwarders)\" check box.","ccis":["CCI-000366"]},{"vulnId":"V-259342","ruleId":"SV-259342r1156949_rule","severity":"medium","ruleTitle":"Forwarders on an authoritative Windows DNS Server, if enabled for external resolution, must forward only to an internal, non-Active Directory (AD)-integrated DNS server or to the DOD Enterprise Recursive Services (ERS).","description":"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 nonexistent hosts (which constitutes a denial of service) or hosts that masquerade as legitimate ones to obtain sensitive data or passwords. \n\nTo 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.","checkContent":"Note: If the Windows DNS Server is in the classified network, this check is not applicable. If forwarders are not being used, this is not applicable.\n\nNote: In Windows DNS Server, if forwarders are configured, the recursion setting must also be enabled because disabling recursion will disable forwarders.\n\nIf forwarders are not used, recursion must be disabled. In both cases, the use of root hints must be disabled.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select \"Properties\".\n\nClick the \"Forwarders\" tab.\n\nReview the IP address(es) for the forwarder(s) use.\n\nIf the DNS server does not forward to another DOD-managed DNS server or to the DOD ERS, this is a finding.\n\nIf \"Use root hints if no forwarders are available\" is selected, this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, right-click on the server name for the DNS server and select \"Properties\".\n\nClick the \"Forwarders\" tab.\n\nReplace the forwarders being used with another DOD-managed DNS server or the DOD ERS.\n\nDeselect \"Use root hints if no forwarders are available\".","ccis":["CCI-000366"]},{"vulnId":"V-259343","ruleId":"SV-259343r1156949_rule","severity":"high","ruleTitle":"The Windows 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.","description":"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 nonexistent hosts (which constitutes a denial of service) or hosts that masquerade as legitimate ones to obtain sensitive data or passwords.\n\nTo guard against poisoning, name servers specifically fulfilling the role of providing recursive query responses for external zones must be segregated from name servers authoritative for internal zones.","checkContent":"Note: Sinkhole name servers host records that are manually added and for which the name server is not authoritative. It is configured and intended to block resolvers from reaching a destination by directing the query to a sinkhole. If the sinkhole name server is not authoritative for any zones and serves only as a caching/forwarding name server, this check is not applicable.\n\nThe non-Active Directory (AD)-integrated, standalone, caching Windows 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 (ZSK) 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.\n\nIf the non-AD-integrated, standalone, caching Windows DNS Server is not configured to be DNSSEC aware, this is a finding.","fixText":"Implement DNSSEC on all non-AD-integrated, standalone, caching Windows DNS Servers to ensure the caching server validates signed zones when resolving and caching.","ccis":["CCI-000366"]},{"vulnId":"V-259344","ruleId":"SV-259344r1137675_rule","severity":"medium","ruleTitle":"The Windows DNS Server must implement cryptographic mechanisms to detect changes to information during transmission.","description":"Encrypting information for transmission protects it from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions that have common application in digital signatures, checksums, and message authentication codes.\n\nConfidentiality 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.","checkContent":"Note: If the Windows DNS Server hosts only Active Directory (AD)-integrated zones and does not host any file-based zones, this is not applicable. \n\nNote: This requirement does not apply for classified environments.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2022 10:22:28 AM\nSigned: 10/22/2022 10:22:28 AM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the DNS server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-002421"]},{"vulnId":"V-259345","ruleId":"SV-259345r961863_rule","severity":"medium","ruleTitle":"The validity period for the Resource Record Signatures (RRSIGs) covering a zone's DNSKEY RRSet must be no less than two days and no more than one week.","description":"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 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 zone signing key (ZSK) can use that key only during the key signing key's (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 Delegation Signer (DS) Resource Record (RR) in the delegating parent. These validity periods should be short, which will require frequent re-signing.\n\nTo minimize the impact of a compromised ZSK, a zone administrator should set a signature validity period of one 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or Windows DNS Servers on a classified network.\n\nLog on to the DNS server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nRight-click the zone and select DNSSEC >> Properties.\n\nSelect the \"KSK\" tab.\n\nVerify the \"DNSKEY signature validity period (hours):\" is set to at least 48 hours and no more than 168 hours. \n\nSelect the \"ZSK\" tab. \n\nVerify the \"DNSKEY signature validity period (hours):\" is set to at least 48 hours and no more than 168 hours.\n\nIf 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.","fixText":"Log on to the DNS server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nRight-click the zone and select DNSSEC >> Properties.\n\nSelect the \"KSK\" tab. For the \"DNSKEY RRSET signature validity period (hours):\" setting, configure to a value between 48 and 168 hours. \n\nSelect the \"ZSK\" tab. For the \"DNSKEY signature validity period (hours):\" setting, configure to a value between 48 and 168 hours.","ccis":["CCI-000366"]},{"vulnId":"V-259346","ruleId":"SV-259346r1156952_rule","severity":"medium","ruleTitle":"NSEC3 must be used for all internal DNS zones.","description":"NSEC records list the resource record types for the name, as well as the name of the next resource record. This information reveals that the resource record type for the name queried, or the resource record name requested, does not exist. \n\nNSEC 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 on the authoritative server and the resolver. To prevent giving access to an entire zone file, NSEC3 should be configured. 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nOpen an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account.\n\nType the following command, where example.com is replaced with the zone hosted on the DNS Server: \n\nPS C:\\> Get-DnsServerResourceRecord -ZoneName example.com <enter>\n\nAll of the zone's resource records will be returned. This should include the NSEC3 RRs, as depicted below.\n\nIf NSEC3 RRs are not returned for the zone, this is a finding.\n\n2vf77rkf63hrgismnuvnb8... NSEC3      0                    01:00:00        [RsaSha1][False][50][F2738D980008F73C]\n7ceje475rse25gppr3vphs... NSEC3      0                    01:00:00        [RsaSha1][False][50][F2738D980008F73C]","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nIf not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.\n\nOnce the Server Manager window is initialized, from the left pane, click to select the DNS category.\n\nFrom the right pane, under the \"SERVERS\" section, right-click the DNS server.\n\nFrom the context menu that appears, click \"DNS Manager\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nRight-click the zone and select DNSSEC >> Sign the Zone.\n\nRe-sign the zone using an NSEC3 algorithm (RSA/SHA-1 (NSEC3), RSA/SHA-256, RSA/SHA-512).","ccis":["CCI-000366"]},{"vulnId":"V-259347","ruleId":"SV-259347r961863_rule","severity":"high","ruleTitle":"The Windows DNS Server's zone files must have NS records that point to active name servers authoritative for the domain specified in that record.","description":"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. \n\nThe list of secondary servers must remain current within 72 hours of any changes to the zone architecture that would affect the list of secondaries. If a secondary server has been retired or is not operational but remains on the list, an adversary might have a greater opportunity to impersonate that secondary without detection, rather than if the secondary was online. For example, the adversary may be able to spoof the retired secondary's IP address without an IP address conflict, which would not be likely to occur if the true secondary were active.","checkContent":"Note: This check is not applicable if Windows DNS Server is only serving as a caching server and does not host any zones authoritatively.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nReview the NS records for the zone.\n\nVerify each of the name servers, represented by the NS records, is active.\n\nAt a command prompt on any system, type:\n\nnslookup <enter>;\n\nAt the nslookup prompt, type: \n\nserver ###.###.###.### <enter>;\n(where the ###.###.###.### is replaced by the IP of each NS record) \n\nEnter a FQDN for a known host record in the zone.\n\nIf the NS server does not respond at all or responds with a nonauthoritative answer, this is a finding.","fixText":"If DNS servers are Active Directory (AD) integrated, troubleshoot and remedy the replication problem where the nonresponsive name server is not being updated.\n\nIf DNS servers are not AD integrated, log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone. \n\nReview the NS records for the zone.\n\nSelect the NS record for the nonresponsive name server and remove the record.","ccis":["CCI-000366"]},{"vulnId":"V-259348","ruleId":"SV-259348r1156953_rule","severity":"medium","ruleTitle":"All authoritative name servers for a zone must be located on different network segments.","description":"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.\n\nA network administrator may choose to use a \"hidden\" primary authoritative server and have only secondary servers visible on the network. A hidden primary authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the primary authoritative name server is hidden, a secondary authoritative name server may reside on the same network as the hidden primary.","checkContent":"Windows DNS Servers that are Active Directory (AD) integrated must be located where required to meet the Active Directory services.\n\nIf all of the Windows DNS Servers are AD integrated, this check is not applicable.\n\nIf any or all the Windows DNS Servers are standalone and non-AD integrated, verify their geographic location with the system administrator.\n\nIf all of the authoritative name servers are located on the same network segment and the primary authoritative name server is not \"hidden\", this is a finding.","fixText":"For non-AD-integrated Windows DNS Servers, distribute secondary authoritative servers on separate network segments from the primary authoritative server.","ccis":["CCI-000366"]},{"vulnId":"V-259349","ruleId":"SV-259349r961863_rule","severity":"medium","ruleTitle":"All authoritative name servers for a zone must have the same version of zone information.","description":"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 on 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.\n\nThe 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 primary authoritative name server.","checkContent":"Note: Due to the manner in which Active Directory replication increments SOA records for zones when transferring zone information via Active Directory (AD) replication, this check is not applicable for AD-integrated zones.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nReview the SOA information for the zone and obtain the Serial Number.\n\nAccess each secondary name server for the same zone and review the SOA information.\n\nVerify the Serial Number is the same on all authoritative name servers.\n\nIf the Serial Number is not the same on one or more authoritative name servers, this is a finding.","fixText":"If all DNS servers are AD integrated, determine why the replication is not taking place to the out-of-sync secondary name servers and mitigate the issue.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nInitiate a zone transfer to all secondary name servers for the zone.","ccis":["CCI-000366"]},{"vulnId":"V-259350","ruleId":"SV-259350r1156954_rule","severity":"high","ruleTitle":"The Windows DNS Server must be configured to enable DNSSEC Resource Records (RRs).","description":"The specification for a digital signature mechanism in the context of the DNS infrastructure is in the Internet Engineering Task Force's (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.\n\nBefore a DNSSEC-signed zone can be deployed, a name server must be configured to enable DNSSEC processing.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select each zone.\n \nReview the RRs for each zone and verify all of the DNSSEC record types are included for the zone. \n\nNote: The DS (Delegation Signer) record should also exist but the requirement for it is validated under WDNS-22-000054.\n\nRRSIG (Resource Read Signature)\nDNSKEY (Public Key)\nNSEC3 (Next Secure 3)\n\nIf the zone does not show all the DNSSEC record types, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\", using either approved saved parameters or approved custom parameters.","ccis":["CCI-000366"]},{"vulnId":"V-259351","ruleId":"SV-259351r961863_rule","severity":"medium","ruleTitle":"The digital signature algorithm used for DNSSEC-enabled zones must be FIPS-compatible.","description":"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:\n- Digital Signature Algorithm (DSA).\n- RSA.\n- Elliptic Curve DSA (ECDSA).\n\nOf these three algorithms, RSA and DSA are more widely available and hence are considered candidates of choice for DNSSEC. Both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. \n\nRSA is the recommended algorithm for this guideline. 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 a minimum. It is suggested that at least one zone signing key (ZSK) for a zone use the RSA algorithm.\n\nNIST'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 30 September 2015.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone. \n\nReview the zone's RRs in the right windowpane.\n\nReview the DNSKEY encryption in the Data column. Example: [DNSKEY][RsaSha1][31021]\n\nConfirm the encryption algorithm specified in the DNSKEY's data is at RsaSha1, at a minimum.\n\nIf the specified encryption algorithm is not RsaSha1 or stronger, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-000366"]},{"vulnId":"V-259352","ruleId":"SV-259352r961863_rule","severity":"medium","ruleTitle":"For zones split between the external and internal sides of a network, the resource records (RRs) for the external hosts must be separate from the RRs for the internal hosts.","description":"Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients. \n\nExternal clients need to receive RRs that pertain only to public services (public web server, mail server, etc.). \n\nInternal clients need to receive RRs pertaining to public services as well as internal hosts. \n\nThe 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).","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nFor each zone, review the records.\n\nIf any RRs on an internal DNS server resolve to IP addresses located outside the internal DNS server's network, this is a finding.\n\nIf any RRs on an external DNS server resolve to IP addresses located inside the network, this is a finding.","fixText":"Remove any RRs from the internal zones for which the resolution is for an external IP address.\n\nRemove any RRs from the external zones for which the resolution is for an internal IP address.","ccis":["CCI-000366"]},{"vulnId":"V-259353","ruleId":"SV-259353r961863_rule","severity":"medium","ruleTitle":"In a split DNS configuration between the external and internal networks, the external name server must be configured to not be reachable from inside resolvers.","description":"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. \n\nOne 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 resource records (RRs) pertaining to hosts with public services (web servers that serve external web pages or provide business-to-consumer services, mail servers, etc.).\n\nThe other set, called internal name servers, is to be located within the firewall and should be configured so the servers are not reachable from outside and hence provide naming services exclusively to internal clients.","checkContent":"Consult with the system administrator to review the external Windows DNS Server's DOD approved firewall policy.\n\nThe inbound TCP and UDP ports 53 rule should be configured to only restrict IP addresses from the internal network.\n\nIf the DOD-approved firewall policy is not configured with the restriction, consult with the network firewall administrator to confirm the restriction on the network firewall.\n\nIf neither the DNS server's DOD approved firewall policy nor the network firewall is configured to block internal hosts from querying the external DNS server, this is a finding.","fixText":"Configure the external DNS server's firewall policy, or the network firewall, to block queries from internal hosts.","ccis":["CCI-000366"]},{"vulnId":"V-259354","ruleId":"SV-259354r961863_rule","severity":"medium","ruleTitle":"Primary authoritative name servers must be configured to only receive zone transfer requests from specified secondary name servers.","description":"Authoritative name servers (especially primary name servers) should be configured with an allow-transfer access control substatement 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. \n\nBased 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 substatement should consist of IP addresses of secondary name servers and stealth secondary name servers.","checkContent":"Determine if the authoritative primary name server is Active Directory (AD) integrated.\n\nDetermine if all secondary name servers for every zone for which the primary name server is authoritative are AD-integrated in the same Active Directory.\n\nIf the authoritative primary name server is AD integrated and all secondary name servers are part of the same AD, this check is not a finding because AD handles the replication of DNS data.\n\nIf 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.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nRight-click the zone and select \"Properties\".\n\nSelect the \"Zone Transfers\" tab.\n\nIf the \"Allow zone transfers:\" check box is not selected, this is not a finding.\n\nIf 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.\n\nIf the \"To any server\" option is selected, this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nRight-click the zone and select \"Properties\".\n\nSelect the \"Zone Transfers\" tab.\n\nSelect 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.\n\nClick \"OK\".","ccis":["CCI-000366"]},{"vulnId":"V-259355","ruleId":"SV-259355r1156956_rule","severity":"medium","ruleTitle":"The Windows DNS Servers zone database files must not be accessible for edit/write by users and/or processes other than the Windows DNS Server service account and/or the DNS database administrator.","description":"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.\n\nThe 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 primary servers for the relevant zones. Integrity is best ensured through authentication and access control features within the name server software and the file system the name server resides on. To protect the zone files and configuration data, which should only be accessed by the name service or an administrator, access controls must 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 and creates the potential for a denial of service to network resources.\n\nDAC 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 objects.\n\nWhen applications provide a DAC mechanism, the DNS implementation must be able to limit the propagation of those access rights.","checkContent":"For an Active Directory (AD)-integrated DNS implementation, this is not applicable by virtue of being compliant with the Windows 2022 AD STIG because DNS data within an AD-integrated zone is kept within the Active Directory.\n\nFor a file-based Windows DNS implementation, log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select each zone.\n\nRight-click each zone and select \"Properties\".\n\nSelect the \"Security\" tab.\n\nReview the permissions applied to the zone. No group or user should have greater than READ privileges other than the DNS administrators and the system service account under which the DNS Server Service is running.\n\nIf any other account/group has greater than READ privileges, this is a finding.","fixText":"For a file-back Windows DNS implementation, log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select each zone.\n\nRight-click each zone and select \"Properties\".\n\nSelect the \"Security\" tab.\n\nDowngrade to READ privileges any group or user that has greater than READ privileges other than the DNS administrators and the system service account under which the DNS Server Service is running.","ccis":["CCI-000366"]},{"vulnId":"V-259356","ruleId":"SV-259356r961863_rule","severity":"medium","ruleTitle":"The Windows DNS Server must implement internal/external role separation.","description":"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). \n\nThe 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. 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 otherwise concealed by some form of Network Address Translation from leaking into the public DNS system.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, review each zone.\n\nConsult with the DNS Admin to determine if any of the zones also have hostnames that need to be resolved from the external network.\n\nIf the zone is split between internal and external networks, verify separate DNS servers have been implemented for each network.\n\nIf internal and external DNS servers have not been implemented for zones that require resolution from both the internal and external networks, this is a finding.","fixText":"Configure separate DNS servers for each of the external and internal networks.","ccis":["CCI-000366"]},{"vulnId":"V-259357","ruleId":"SV-259357r961863_rule","severity":"medium","ruleTitle":"The Windows DNS Server authoritative for local zones must only point root hints to the DNS servers that host the internal root domain.","description":"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. \n\nThe 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 noncaching server (as recommended), they can be configured to either return a referral to the root servers or refuse to answer the query. \n\nThe 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 fulfilling its intended purpose of answering authoritatively for its zone.","checkContent":"Note: If the Windows DNS Server is in the classified network, this check is not applicable.\n\nLog on to the authoritative DNS server using the Domain Admin or Enterprise Admin account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nRight-click the DNS server and select \"Properties\".\n\nSelect the \"Root Hints\" tab.\n\nVerify \"Root Hints\" is empty or only has entries for internal zones under \"Name servers:\". All internet root server entries must be removed.\n\nIf \"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.","fixText":"Log on to the authoritative DNS server using the Domain Admin or Enterprise Admin account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nRight-click the DNS server and select \"Properties\".\n\nSelect the \"Root Hints\" tab.\n\nRemove the root hints from the DNS Manager, the CACHE.DNS file, and from Active Directory for name servers outside the internal network. \n\nReplace the existing root hints with new root hints of internal servers. \n\nIf 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 ensure the root hints will not be used.","ccis":["CCI-000366"]},{"vulnId":"V-259358","ruleId":"SV-259358r961863_rule","severity":"medium","ruleTitle":"The Windows DNS Servers zone files must not include resource records that resolve to a fully qualified domain name residing in another zone.","description":"If a name server could 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. The best way to eliminate this risk is to eliminate from the zone files any records for hosts in another zone.\n\nThe exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party content delivery networks (CDNs) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n \nConfirm 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.\n\nThe exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party CDNs 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 multidomain Active Directory environment pointing to hosts in other internal domains in the same multidomain environment.\n\nIf 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 CDNs or cloud computing platforms with a documented and approved mission need, this is a finding.","fixText":"Remove any resource records in a zone file if the resource record resolves to a fully qualified domain name residing in another zone.","ccis":["CCI-000366"]},{"vulnId":"V-259359","ruleId":"SV-259359r1156962_rule","severity":"medium","ruleTitle":"The Windows DNS Server's zone files must not include CNAME records pointing to a zone with lesser security for more than six months.","description":"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. \n\nWhen 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. In the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers, which compounds the vulnerability.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nReview the resource records to confirm there are no CNAME records older than six months.\n\nThe exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDNs) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated. (Authorizing Official approval of use of a commercial cloud offering would satisfy this requirement.) Additional exceptions are CNAME records in a multidomain Active Directory environment pointing to hosts in other internal domains in the same multidomain environment.\n\nIf there are zone-spanning (i.e., zones of lesser security) CNAME records older than six 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 CDNs or cloud computing platforms with an AO-approved and documented mission need, this is a finding.","fixText":"Remove any zone-spanning CNAME records that have been active for more than six months, which are not supporting zone delegations, CNAME records supporting a system migration, or CNAME records pointing to third-party CDNs or cloud computing platforms.\n\nIn 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).","ccis":["CCI-000366"]},{"vulnId":"V-259360","ruleId":"SV-259360r961863_rule","severity":"medium","ruleTitle":"Nonroutable IPv6 link-local scope addresses must not be configured in any zone.","description":"IPv6 link-local scope addresses are not globally routable and must not be configured in any DNS zone. Like 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.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nExpand the \"Forward Lookup Zones\" folder.\n\nExpand each zone folder and examine the host record entries. The third column titled \"Data\" will display the IP.\n\nVerify this column does not contain any IP addresses that begin with the prefixes \"FE8\", \"FE9\", \"FEA\", or \"FEB\".\n\nIf any nonroutable IPv6 link-local scope addresses are in any zone, this is a finding.","fixText":"Remove any link-local addresses and replace with appropriate Site-Local or Global scope addresses.","ccis":["CCI-000366"]},{"vulnId":"V-259361","ruleId":"SV-259361r1018796_rule","severity":"medium","ruleTitle":"AAAA addresses must not be configured in a zone for hosts that are not dual stack.","description":"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. \n\nA denial of service could easily be implemented for an application that is not IPv6 if the user is not running dual stack or any other systems utilizing IPv6. 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 in a dual stack records into the same domain can lead to application problems that are beyond the scope of the DNS administrator.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, select each zone and examine the host record entries. The third column titled \"Data\" will display the IP.\n\nDetermine if any contain both IPv4 and IPv6 addresses.\n\nIf any hostnames contain both IPv4 and IPv6 addresses, confirm with the system administrator that the actual hosts are in a dual stack.\n\nIf any zones contain hosts with both IPv4 and IPv6 addresses but are determined to be not in a dual stack, this is a finding.","fixText":"Remove any IPv6 records for hosts that are not in a dual stack configuration.","ccis":["CCI-000366"]},{"vulnId":"V-259363","ruleId":"SV-259363r960999_rule","severity":"medium","ruleTitle":"The Windows DNS Server must uniquely identify the other DNS server before responding to a server-to-server transaction.","description":"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.\n\nTSIG and SIG(0) are not configurable in Windows DNS Server.\n\nTo meet the requirement for authentication between Windows DNS Servers, IPsec will be implemented between the Windows DNS Servers that host any non-Active Directory (AD)-integrated zones.","checkContent":"Note: This requirement applies to any Windows DNS Server that hosts non-AD-integrated zones, even if the DNS servers host AD-integrated zones, too.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"gpme.msc\" to open the Group Policy Management feature.\n\nIn the \"Browse for Group Policy Object\" dialog box, double-click \"Domain Controllers.domain.com\".\n\nClick \"Default Domain Controllers Policy\" and click \"OK\".\n\nIn the console tree, open Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Windows Firewall with Advanced Security\\Windows Firewall with Advanced Security - LDAP.\n\nClick \"Connection Security Rules\".\n\nConfirm at least one rule is configured for TCP 53.\n\nDouble-click on each rule to verify the following: \n\nOn the \"Authentication\" tab, \"Authentication mode:\" is set to \"Request authentication for inbound and outbound connections\".\n\nThe \"Signing Algorithm\" is set to \"RSA (default)\".\n\nOn the \"Remote Computers\" tab, \"Endpoint1\" and \"Endpoint2\" are configured with the IP addresses of all DNS servers.\n\nOn the \"Protocols and Ports\" tab, \"Protocol type:\" is set to either TCP (depending on which rule is being reviewed) and the \"Endpoint 1 port:\" is set to \"Specific ports\" and \"53\".\n\nIf no rules are configured with the specified requirements, this is a finding.","fixText":"Complete the following procedures twice for each pair of name servers.\n\nCreate a rule for TCP connections.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"gpme.msc\" to open the Group Policy Management feature.\n\nIn the \"Browse for Group Policy Object\" dialog box, double-click \"Domain Controllers.domain.com\".\n\nClick \"Default Domain Controllers Policy\" and click \"OK\".\n\nIn the console tree, open Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Windows Firewall with Advanced Security\\Windows Firewall with Advanced Security - LDAP.\n\nRight-click \"Connection Security Rules\" and select \"New\".\n\nFor \"Rule Type\", select the \"Server-to-server\" radio button and click \"Next\".\n\nFor Endpoint 1 and Endpoint 2, select \"These IP addresses:\" and add the IP addresses of all DNS servers. Click \"Next\".\n\nFor \"Requirements\", select \"Request authentication for inbound and outbound connections\" and click \"Next\".\n\nFor \"Authentication Method\", select Computer certificate and from the \"Signing Algorithm:\" drop-down, select \"RSA (default)\".\n\nFrom the \"Certificate store type:\" drop-down, select \"Root CA (default)\".\n\nFrom the \"CA name:\", click \"Browse\", select the certificate for the CA, and click \"Next\".\n\nOn \"Profile\", accept default selections and click \"Next\".\n\nOn \"Name\", enter a name applicable to the rule's function.\n\nClick \"Finish\".","ccis":["CCI-000778"]},{"vulnId":"V-259364","ruleId":"SV-259364r961503_rule","severity":"medium","ruleTitle":"The secondary Windows DNS name servers must cryptographically authenticate zone transfers from primary name servers.","description":"Authenticity of zone transfers within Windows Active Directory (AD)-integrated zones is accomplished by AD replication. 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 preauthorized devices can access the system.\n\nThis 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).","checkContent":"For zones that are completely AD-integrated, this check is not a finding.\n\nFor authenticity of zone transfers between non-AD-integrated zones, DNSSEC must be implemented.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 12/21/2022 10:215:28 AM\nSigned: 11/22/2022 10:15:28 AM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, indicating the zone has been signed with DNSSEC, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the DNS server using the account designated as Administrator or DNS Administrator.\n\nIf not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.\n\nOnce the Server Manager window is initialized, from the left pane, click to select the DNS category.\n\nFrom the right pane, under the \"SERVERS\" section, right-click the DNS server.\n\nFrom the context menu that appears, click \"DNS Manager\".\n\nIn the DNS Manager console tree on the DNS server being validated, navigate to \"Forward Lookup Zones\".\n\nRight-click the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-001958"]},{"vulnId":"V-259365","ruleId":"SV-259365r960735_rule","severity":"medium","ruleTitle":"The Windows DNS primary server must only send zone transfers to a specific list of secondary name servers.","description":"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 be made only 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 a denial of service to legitimate users.\n\nActive Directory (AD)-integrated DNS servers replicate zone information via AD replication. Non-AD-integrated DNS servers replicate zone information via zone transfers.","checkContent":"If the DNS server hosts only AD-integrated zones and there are no non-AD-integrated DNS servers acting as secondary DNS servers for the zones, this check is not applicable.\n\nFor a non-AD-integrated DNS server:\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select and then right-click the zone name.\n\nFrom the displayed context menu, click the \"Properties\" option.\n\nOn the opened zone's properties box, go to the \"Zone Transfers\" tab.\n\nOn the displayed interface, determine if the \"Allow zone transfers\" check box is selected.\n\nIf the \"Allow zone transfers\" check box is not selected, this is not a finding.\n\nIf the \"Allow zone transfers\" check box is selected, determine if 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.\n\nIf the \"To any server\" radio button is selected, this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nFrom the displayed context menu, click the \"Properties\" option.\n\nOn the opened zone's properties box, go to the \"Zone Transfers\" tab.\n\nOn the displayed interface, select the \"Allow zone transfers\" check box.\n\nSelect the \"Only to servers listed on the Name Servers tab\" radio button OR select the \"Only to the following servers\" radio button.\n\nClick \"Apply\".\n\nClick \"OK\".","ccis":["CCI-000054"]},{"vulnId":"V-259366","ruleId":"SV-259366r1156946_rule","severity":"medium","ruleTitle":"The Windows DNS Server must provide its identity with returned DNS information by enabling DNSSEC and TSIG/SIG(0).","description":"Weakly bound credentials can be modified without invalidating the credential; therefore, nonrepudiation can be violated.\n\nThis 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.\n\nDNSSEC and TSIG/SIG(0) both use digital signatures to establish the identity of the producer of pieces of information.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2014 10:22:28 PM\nSigned: 10/22/2014 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the DNS server using the account designated as Administrator or DNS Administrator.\n\nIn the DNS Manager console tree on the DNS server being validated, navigate to \"Forward Lookup Zones\".\n\nRight-click the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either saved parameters or custom parameters.","ccis":["CCI-000366","CCI-001901"]},{"vulnId":"V-259367","ruleId":"SV-259367r1192655_rule","severity":"medium","ruleTitle":"The Windows DNS Server must be configured to enforce authorized access to the corresponding private key.","description":"The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, it will lead to the compromise of the authentication and nonrepudiation 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.\n\nSIG(0) is used for server-to-server authentication for DNS transactions, and it uses PKI-based authentication. In cases where SIG(0) is being used instead of TSIG (which uses a shared key, not PKI-based authentication), this requirement is applicable.\n\nSatisfies: SRG-APP-000176-DNS-000017, SRG-APP-000176-DNS-000019","checkContent":"Navigate to the following location:\n\n%ALLUSERSPROFILE%\\Microsoft\\Crypto\\Keys\n\nNote: If the folder above does not exist, this is not applicable.\n\nVerify the permissions on the folder, subfolders, and files are limited to SYSTEM and Administrators FULL CONTROL.\n\nIn File Explorer:\n\nFor each folder, subfolder, and file, view the Properties.\n\nSelect the \"Security\" tab, and then click \"Advanced\".\n\nDefault permissions:\nC:\\ProgramData\\Microsoft\\Crypto\\Keys\nType - \"Allow\" for all\nInherited from - \"None\" for all\n\nPrincipal - Access - Applies to\n\nSYSTEM - Full control - This folder, subfolders and files\nAdministrators - Full control - This folder, subfolders and files\nEveryone - Read  - This folder, subfolders, and files\n\nAlternately, use icacls:\n\nOpen a command prompt and enter \"icacls\" followed by the directory. \nFor each folder, subfolder, and file, view the Properties.\n\n\"icacls %ALLUSERSPROFILE%\\Microsoft\\Crypto\\Keys\"\n\nC:\\ProgramData\\microsoft\\crypto\\keys\nNT AUTHORITY\\SYSTEM:(OI)(CI)(F)\nBUILTIN\\Administrators:(OI)(CI)(F)\nEveryone:(OI)(CI)(R)\nSuccessfully processed 1 files; Failed processing 0 files\n\nIf any other user or group has greater than READ privileges to the %ALLUSERSPROFILE%\\Microsoft\\Crypto\\Keys folder, subfolders, and files, this is a finding.","fixText":"Navigate to the following location:\n\n%ALLUSERSPROFILE%\\Microsoft\\Crypto\\Keys\n\nModify permissions on the keys folder, subfolders, and files to be limited to SYSTEM and Administrators FULL CONTROL, and to limit all other users/groups to READ. If additional permissions are needed, it must be documented and approved by the information system security officer (ISSO) or information system security manager (ISSM).","ccis":["CCI-000186"]},{"vulnId":"V-259368","ruleId":"SV-259368r961041_rule","severity":"medium","ruleTitle":"The Windows DNS Server key file must be owned by the account under which the Windows DNS Server service is run.","description":"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. Transaction Signature (TSIG) is a string used to generate the message authentication hash stored in a TSIG Resource Record (RR) and used to authenticate an entire DNS message.","checkContent":"Access Services on the Windows DNS Server and locate the DNS Server Service.\n\nDetermine the account under which the DNS Server Service is running. \n\nAccess Windows Explorer.\n\nNavigate to the following location:\n\n%ALLUSERSPROFILE%\\Microsoft\\Crypto\n\nNote: If the folder above does not exist, this check is not applicable.\n\nRight-click on each subfolder, choose \"Properties\", click the \"Security\" tab, and click the \"Advanced\" button.\n\nVerify the Owner on the folder, subfolders, and files is the account under which the DNS Server Service is running.\n\nIf any other user or group is listed as OWNER of the %ALLUSERSPROFILE%\\Microsoft\\Crypto folder, subfolders, and files, this is a finding.","fixText":"Access Windows Explorer.\n\nNavigate to the following location:\n\n%ALLUSERSPROFILE%\\Microsoft\\Crypto\n\nRight-click on each subfolder, choose \"Properties\", click the \"Security\" tab, and click the \"Advanced\" button.\n\nClick \"Change\" next to the listed Owner and change to be the account under which the DNS Server Service is running.","ccis":["CCI-000186"]},{"vulnId":"V-259370","ruleId":"SV-259370r961041_rule","severity":"medium","ruleTitle":"The private key corresponding to the zone signing key (ZSK) must only be stored on the name server that does support dynamic updates.","description":"The private keys in the key signing key (KSK) and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored offline (with respect to the internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file primary copy.\n\nThis strategy is not feasible in situations in which the DNSSEC-aware name server must support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) must 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 resource record (RR) sets. The private key corresponding to the key signing key (KSK-private) can still be kept offline.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory (AD)-integrated zones or for Windows DNS Servers on a classified network.\n\nNote: This requirement is not applicable to servers with only a caching role.\n\nFor AD-integrated zones, private zone signing keys replicate automatically to all primary DNS servers through AD 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 AD database file, the signed copy of the zone remains in memory for AD-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.\n\nIf all DNS servers are AD integrated, this check is not applicable.\n\nIf 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.","fixText":"Ensure the private key corresponding to the ZSK is only stored on the name server accepting dynamic updates.","ccis":["CCI-000186"]},{"vulnId":"V-259371","ruleId":"SV-259371r1015766_rule","severity":"medium","ruleTitle":"The Windows DNS Server must implement a local cache of revocation data for PKI authentication.","description":"Not configuring a local cache of revocation data could allow access to users who are no longer authorized (users with revoked certificates).\n\nSIG(0) is used for server-to-server authentication for DNS transactions, and it uses PKI-based authentication. In cases where SIG(0) is being used instead of TSIG (which uses a shared key, not PKI-based authentication), this requirement is applicable.","checkContent":"Consult with the system administrator to determine if a third-party CRL server is being used for certificate revocation lookup.\n\nIf there is, determine 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.\n\nIf there is no local cache of revocation data, this is a finding.","fixText":"Configure local revocation data to be used in the event access to Certificate Authorities is hindered.","ccis":["CCI-004068","CCI-001991"]},{"vulnId":"V-259372","ruleId":"SV-259372r961863_rule","severity":"medium","ruleTitle":"The salt value for zones signed using NSEC3 resource records (RRs) must be changed every time the zone is completely re-signed.","description":"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.\n\nNSEC 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 on the authoritative server and the resolver. To prevent giving access to an entire zone file, NSEC3 should be configured. 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nIn Windows, the NSEC3 salt values are automatically changed when the zone is re-signed.\n\nTo validate:\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS Server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone. \n\nReview the zone's RRs in the right windowpane.\n\nDetermine 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.\n\nIf the NSEC3PARAM's Inception date and time is different than the DNSKEY Inception date and time, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.\n\nRevalidate the NSEC3PARAM Inception date and time against the DNSKEY date and time.","ccis":["CCI-000366"]},{"vulnId":"V-259373","ruleId":"SV-259373r961101_rule","severity":"medium","ruleTitle":"The Windows DNS Server must include data origin with authoritative data the system returns in response to external name/address resolution queries.","description":"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 valid data has originated from the right source. Establishing trust in the source is called data origin authentication.\n\nThe 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.\n\nThe 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nAuthenticity of query responses is provided with DNSSEC signing of zones.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by Windows DNS Server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2014 10:22:28 PM\nSigned: 10/22/2014 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the DNS server using the account designated as Administrator or DNS Administrator.\n\nIf not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.\n\nOnce the Server Manager window is initialized, from the left pane, click to select the DNS category.\n\nFrom the right pane, under the \"SERVERS\" section, right-click the DNS server.\n\nFrom the context menu that appears, click \"DNS Manager\".\n\nIn the DNS Manager console tree on the DNS server being validated, navigate to \"Forward Lookup Zones\".\n\nRight-click the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-001178"]},{"vulnId":"V-259374","ruleId":"SV-259374r1156950_rule","severity":"medium","ruleTitle":"The Windows DNS Server's IP address must be statically defined and configured locally on the server.","description":"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. \n\nEnsuring all name servers have static IP addresses makes it possible to configure restricted DNS communication, such as with DNSSEC, between the name servers.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nUse \"ipconfig /all\" to identify all network adapters. \nor\nLocate the \"Network Internet Access\" icon, right-click on it, and select \"Open Network & Sharing Center\".\n\nClick \"Change adapter settings\".\n\nRight-click on the Ethernet and click \"Properties\".\n\nSelect \"Internet Protocol Version 4 (TCP/IPv4)\" and click \"Properties\".\n\nVerify the \"Use the following IP address\" is selected, with an IP address, subnet mask, and default gateway assigned.\n\nIf the \"Use the following IP address\" is not selected with a configured IP address, subnet mask, and default gateway, this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account. \n\nUse \"ipconfig /all\" to identify all network adapters. \nor\nLocate the \"Network Internet Access\" icon, right-click on it, and select \"Open Network & Sharing Center\".\n\nClick \"Change adapter settings\".\n\nRight-click on the Ethernet and click \"Properties\".\n\nSelect \"Internet Protocol Version 4 (TCP/IPv4)\" and click \"Properties\".\n\nSelect \"Use the following IP address\" and populate with an IP address, subnet mask, and default gateway.","ccis":["CCI-000366","CCI-002463"]},{"vulnId":"V-259375","ruleId":"SV-259375r1156950_rule","severity":"medium","ruleTitle":"The Windows DNS Server must return data information in response to internal name/address resolution queries.","description":"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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nBy 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. Because this takes place inherently when the zone is signed with DNSSEC, the requirement is satisfied by ensuring zones are signed.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2014 10:22:28 PM\nSigned: 10/22/2014 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-000366","CCI-002463"]},{"vulnId":"V-259376","ruleId":"SV-259376r987696_rule","severity":"medium","ruleTitle":"The Windows DNS Server must use DNSSEC data within queries to confirm data origin to DNS resolvers.","description":"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.\n\nA 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 ensure the authenticity and integrity of response data.\n\nIn 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2014 10:22:28 PM\nSigned: 10/22/2014 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-000366","CCI-002464"]},{"vulnId":"V-259377","ruleId":"SV-259377r961581_rule","severity":"medium","ruleTitle":"WINS lookups must be disabled on the Windows DNS Server.","description":"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.\n\nA 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. \n\nIn 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.\n\nIf/when WINS lookups are enabled, the validity of the data becomes questionable because the WINS data is provided to the requestor unsigned and invalidated. To ensure only the DNSSEC-signed data is being returned, WINS lookups must be disabled.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click each zone and then click \"Properties\".\n\nIn the \"Properties\" dialog box for the zone, click the \"WINS\" tab.\n\nVerify the \"Use WINS forward lookup\" check box is not selected.\n\nIf the \"Use WINS forward lookup\" check box is selected, this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click each zone and then click \"Properties\".\n\nIn the \"Properties\" dialog box for the zone, click the \"WINS\" tab.\n\nUncheck the \"Use WINS forward\" lookup check box.\n\nClick \"OK\".","ccis":["CCI-002462"]},{"vulnId":"V-259378","ruleId":"SV-259378r961581_rule","severity":"medium","ruleTitle":"The Windows DNS Server must use DNSSEC data within queries to confirm data integrity to DNS resolvers.","description":"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.\n\nA 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. \n\nIn 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2014 10:22:28 PM\nSigned: 10/22/2014 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-002462"]},{"vulnId":"V-259379","ruleId":"SV-259379r961104_rule","severity":"medium","ruleTitle":"The Windows DNS Server must be configured with the Delegation Signer (DS) Resource Records (RR) carrying the signature for the RR that contains the public key of the child zone.","description":"If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of 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 subdomain from the top of the DNS hierarchy down.\n\nA 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 ensure the authenticity and integrity of response data. \n\nIn 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.\n\nA 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 DNSSEC.\n\nWhen 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 several 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).\n\nOne way to indicate the security status of child subspaces is through the use of DS RRs in the DNS.\n\nPath 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2014 10:22:28 PM\nSigned: 10/22/2014 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-001179"]},{"vulnId":"V-259380","ruleId":"SV-259380r961107_rule","severity":"medium","ruleTitle":"The Windows DNS Server must enforce approved authorizations between DNS servers using digital signatures in the Resource Record Set (RRSet).","description":"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.\n\nApplication-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).\n\nApplications 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.\n\nWithin the context of DNS, this is applicable in terms of controlling the flow of DNS information between systems, such as DNS zone transfers.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone. \n\nReview the records for the zone and ensure the complete RRSet of records is present: RRSIG, NSEC3, DNSKEY, indicating DNSSEC compliance.\n\nIf the RRSet of records is not in the zone, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n \nRight-click the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-001663"]},{"vulnId":"V-259381","ruleId":"SV-259381r961107_rule","severity":"medium","ruleTitle":"The Name Resolution Policy Table (NRPT) must be configured in Group Policy to enforce clients to request DNSSEC validation for a domain.","description":"The 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nThe 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.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nAt the Windows PowerShell prompt, type the following command:\n\nget-dnsclientnrptpolicy <enter>\n\nIn the results, verify the \"DnsSecValidationRequired\" is \"True\".\n\nIf there are no results to the \"get-dnsclientnrptpolicy\" cmdlet or the \"DnsSecValidationRequired\" is not \"True\", this is a finding.","fixText":"Implement this fix for configuring name resolvers, including DNS servers configured for the caching role only.\n\nOn Domain Controller, on the Server Manager menu bar, click \"Tools\" and then click \"Group Policy Management\".\n\nIn the Group Policy Management console tree, under Domains >> domainname >> Group Policy Objects, right-click \"Default Domain Policy\" and then click \"Edit\".\n\nIn the Group Policy Management Editor console tree, navigate to Computer Configuration >> Policies >> Windows Settings >> Name Resolution Policy.\n\nIn 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\".\n \nOn the \"DNSSEC\" tab, select \"Enable DNSSEC\" in this rule check box and then under \"Validation\", select the check box for \"Require DNS clients to check that name and address data has been validated by the DNS server\".\n\nIn the bottom right corner, click \"Create\" and then verify that a rule for domain.mil was added under the NRPT.\n\nClick \"Apply\" and then close the Group Policy Management Editor.\n\nOpen a Windows PowerShell prompt and enter the following commands:\ngpupdate /force <enter>\nget-dnsclientnrptpolicy <enter>\n\nIn the results, select \"True\" for the \"DnsSecValidationRequired\" setting for the domain.mil namespace.","ccis":["CCI-001663"]},{"vulnId":"V-259382","ruleId":"SV-259382r961107_rule","severity":"medium","ruleTitle":"The Windows DNS Server must be configured to validate an authentication chain of parent and child domains via response data.","description":"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 subdomain, from the top of the DNS hierarchy down. \n\nLike the DNSKEY resource record, the DS Resource Record (RR) 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.\n\nThe DS record is not added to a zone during the signing process like some DNSSEC-related RRs, even if a delegation already exists in the zone. To add a DS record, it must be manually added or imported. Fortunately, the DS resource record set (DSSET) is automatically added as a file to the Key Primary when a zone is signed. The DSSET file can be used with the \"Import-DnsServerResourceRecordDS\" cmdlet to import DS records to the parent zone.\n\nA 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 ensure the authenticity and integrity of response data.\n\nDNSSEC provides the means to verify integrity assurances for the host/service name to network address resolution information obtained through the service. By using the DS RRs in the DNS, the security status of a child domain can be validated. The DS RR is used to identify the DNSSEC signing key of a delegated zone.\n\nStarting 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. \n\nAfter 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 an RRSet. 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.\n\nThis 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 ensured.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n\nPS C:\\> Get-DnsServerResourceRecord -ZoneName adatum.com -RRType DS\n\nReplace \"adatum.com\" with the parent zone on the DNS server being evaluated.\n\nHostName RecordType Timestamp TimeToLive RecordData\n-------- ---------- --------- ---------- ----------\ncorp DS 0 01:00:00 [58555][Sha1][RsaSha1NSec3]\ncorp DS 0 01:00:00 [58555][Sha256][RsaSha1NSec3]\ncorp DS 0 01:00:00 [63513][Sha1][RsaSha1NSec3]\ncorp DS 0 01:00:00 [63513][Sha256][RsaSha1NSec3]\n\nIf the results do not show the DS records for the child domain(s), this is a finding.\n\nIn 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 in the c:\\windows\\system32\\dns directory. The DSSET file was located in this directory because the local DNS server is the Key primary for the child zone.\n\nIf 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.","fixText":"A DS record must be added manually or imported.\n\nThe DSSET is automatically added as a file to the Key primary when a zone is signed. \n\nThis file can be used with the \"Import-DnsServerResourceRecordDS\" cmdlet to import DS records to the parent zone.\n\nExample:\nPS C:\\> Import-DnsServerResourceRecordDS -ZoneName adatum.com -DSSetFile \"c:\\windows\\system32\\dns\\dsset-corp.adatum.com\"","ccis":["CCI-001663"]},{"vulnId":"V-259383","ruleId":"SV-259383r961107_rule","severity":"medium","ruleTitle":"Trust anchors must be exported from authoritative Windows DNS Servers and distributed to validating Windows DNS Servers.","description":"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.\n\nA 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.\n\nDNSSEC provides the means to verify integrity assurances for the host/service name to network address resolution information obtained through the service. By using the DS Resource Records (RRs) in the DNS, the security status of a child domain can be validated. The DS RR is used to identify the DNSSEC signing key of a delegated zone.\n\nStarting 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. \n\nAfter 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 an RRSet. 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.\n\nThis 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.\n\nA 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 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 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nLog onto each of the validating Windows DNS Servers.\n\nIn the DNS Manager console tree, navigate to each hosted zone under the \"Trust Points\" folder.\n\nTwo DNSKEY trust points should be displayed, one for the active key and one for the standby key.\n\nIf each validating Windows DNS Server does not reflect the DNSKEY trust points for each of the hosted zone(s), this is a finding.","fixText":"Log onto the primary DNS server and click Windows Explorer on the taskbar.\n\nNavigate to C:\\Windows\\System32, right-click the DNS folder, point to \"Share with\", and then click \"Advanced sharing\".\n\nIn 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\".\n\nClick \"Close\" and then close Windows Explorer.\n\nLog on to each of the validating Windows DNS Servers.\n\nIn the DNS Manager console tree, navigate to the \"Trust Points\" folder.\n\nRight-click \"Trust Points\", point to \"Import\", and then click \"DNSKEY\".\n\nIn 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 or zones).\n\nClick \"OK\".","ccis":["CCI-001663"]},{"vulnId":"V-259384","ruleId":"SV-259384r961107_rule","severity":"medium","ruleTitle":"Automatic Update of Trust Anchors must be enabled on key rollover.","description":"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 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. \n\nOn standalone DNS servers, trust anchors are stored in a file named \"TrustAnchors.dns\". A DNS server running Windows Server 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nIf not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.\n\nOnce the Server Manager window is initialized, from the left pane, click to select the DNS category.\n\nFrom the right pane, under the \"SERVERS\" section, right-click the DNS server.\n\nFrom the context menu that appears, click \"DNS Manager\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select and then right-click the zone name.\n\nFrom the displayed context menu, click DNSSEC >> Properties.\n\nClick the \"KSK\" tab.\n\nFor 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.\n\nIf the \"Enable automatic rollover\" check box is not selected for every KSK listed, this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nIf not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.\n\nOnce the Server Manager window is initialized, from the left pane, click to select the DNS category.\n\nFrom the right pane, under the \"SERVERS\" section, right-click the DNS server.\n\nFrom the context menu that appears, click \"DNS Manager\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select and then right-click the zone name.\n\nFrom the displayed context menu, click DNSSEC >> Properties.\n\nClick the \"KSK\" tab.\n\nFor 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.","ccis":["CCI-001663"]},{"vulnId":"V-259385","ruleId":"SV-259385r961584_rule","severity":"medium","ruleTitle":"The Windows DNS secondary servers must request data origin authentication verification from the primary server when requesting name/address resolution.","description":"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.\n\nEach 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from either a Windows 8 client or a Windows 2008 or higher server, authenticated as a Domain Administrator or Local Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows 10 or higher client.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2022 10:22:28 PM\nSigned: 10/22/2022 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-002465"]},{"vulnId":"V-259386","ruleId":"SV-259386r961587_rule","severity":"medium","ruleTitle":"The Windows DNS secondary server must request data integrity verification from the primary server when requesting name/address resolution.","description":"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.\n\nEach 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2022 10:22:28 PM\nSigned: 10/22/2022 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-002466"]},{"vulnId":"V-259387","ruleId":"SV-259387r961590_rule","severity":"medium","ruleTitle":"The Windows DNS secondary server must validate data integrity verification on the name/address resolution responses received from primary name servers.","description":"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.\n\nEach 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2014 10:22:28 PM\nSigned: 10/22/2014 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-002467"]},{"vulnId":"V-259388","ruleId":"SV-259388r961593_rule","severity":"medium","ruleTitle":"The Windows DNS secondary server must validate data origin verification authentication on the name/address resolution responses received from primary name servers.","description":"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.\n\nEach 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2022 10:22:28 PM\nSigned: 10/22/2022 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-002468"]},{"vulnId":"V-259389","ruleId":"SV-259389r1043178_rule","severity":"medium","ruleTitle":"The Windows DNS Server must protect the authenticity of zone transfers via transaction signing.","description":"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.\n\nTSIG and SIG(0) are not configurable in Windows DNS Server.\n\nTo meet the requirement for authentication between Windows DNS Servers, IPsec will be implemented between the Windows DNS Servers that hosts any non-Active Directory (AD)-integrated zones.","checkContent":"Note: This requirement applies to any Windows DNS Servers that host non-AD-integrated zones (file based) even if the DNS servers host AD-integrated zones, too.\n\nIf the Windows DNS Servers host only AD-integrated zones, this requirement is not applicable.\n\nTo protect authenticity of zone transfers between Windows DNS Servers with file-based zones, IPsec must be configured on each pair of name servers in a zone transfer transaction for those zones.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"gpme.msc\" to open the Group Policy Management feature.\n\nIn the \"Browse for Group Policy Object\" dialog box, double-click \"Domain Controllers.domain.com\".\n\nClick \"Default Domain Controllers Policy\" and click \"OK\".\n\nIn the console tree, open Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Windows Defender Firewall with Advanced Security\\Windows Defender Firewall with Advanced Security - Local Group Policy Object.\n\nClick Connection Security Rules.\n\nConsult with the SA to determine which Rules meet the intent of the server-to-server authentication.\n\nIf Rules exist, double-click on each Rule to verify the following:\n\nFor the \"Authentication:\" tab, click on the \"Customize...\" button.\n\nOn the Authentication tab, verify \"Authentication mode:\" is set to \"Request authentication for inbound and outbound connections\".\n\nConfirm the \"Signing Algorithm\" is set to \"RSA (default)\".\n\nUnder \"Method\", ensure the \"Advanced:\" radio button is selected.\n\nClick the \"Customize\" button.\n\nFor \"First authentication methods:\", double-click on the entry.\n\nVerify the \"Select the credential to use for first authentication:\" has \"Computer certificate from this certification authority (CA):\" radio button selected.\n\nReview the certificate specified and verify the certificate used was generated by the internally-managed server performing the Active Directory Certificate Services (AD CS) role.\n\nIf rules do not exist for server-to-server authentication, this is a finding.\n\nIf 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.","fixText":"Complete the following procedures twice for each pair of name servers.\n \nCreate a rule for UDP connections and then create a rule for TCP connections.\n \nRefer to the Microsoft Windows Server DNS Overview.pdf for Microsoft links for this procedure.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"gpme.msc\" to open the Group Policy Management feature.\n\nIn the \"Browse for Group Policy Object\" dialog box, double-click \"Domain Controllers.domain.com\".\n\nClick \"Default Domain Controllers Policy\" and click \"OK\".\n\nIn the console tree, open Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Windows Defender Firewall with Advanced Security\\Windows Defender Firewall with Advanced Security - Local Group Policy Object.\n\nRight-click \"Connection Security Rules\" and select \"New\".\n\nFor \"Rule Type\", select the \"Server-to-server\" radio button and click \"Next\".\n\nFor Endpoint 1 and Endpoint 2, select \"These IP addresses:\" and add the IP addresses of all DNS servers. Click \"Next\".\n\nFor \"Requirements\", select \"Request authentication for inbound and outbound connections\" and click \"Next\".\n\nFor \"Authentication Method\", select Computer certificate and from the \"Signing Algorithm:\" drop-down, select \"RSA (default)\".\n\nFrom the \"Certificate store type:\" drop-down, select \"Root CA (default).\n\nFrom \"CA name:\", click \"Browse\" and select the certificate generated by the internally managed server performing the AD CS role. Click \"Next\".\n\nOn \"Profile\", accept the default selections and click \"Next\".\n\nOn \"Name\", enter a name applicable to the rule's function (i.e., DNSSEC UDP).\n\nClick \"Finish\".","ccis":["CCI-001184"]},{"vulnId":"V-259390","ruleId":"SV-259390r1043178_rule","severity":"high","ruleTitle":"The Windows DNS Server must protect the authenticity of dynamic updates via transaction signing.","description":"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.\n\nThe combination of signing DNS zones by DNSSEC and requiring clients to send their dynamic updates securely ensures the authenticity of those DNS records when providing query responses for them.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nOnce resource records are received by a DNS server via a secure dynamic update, the resource records will automatically become signed by DNSSEC if 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.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an Expirations, date signed, signer, and signature, similar to the following:\n\nName : www.zonename.mil\nQueryType : RRSIG\nTTL : 189\nSection : Answer\nTypeCovered : CNAME\nAlgorithm : 8\nLabelCount : 3\nOriginalTtl : 300\nExpiration : 11/21/2014 10:22:28 PM\nSigned : 10/22/2014 10:22:28 PM\nSigner : zonename.mil\nSignature : {87, 232, 34, 134...}\n\nName : origin-www.zonename.mil\nQueryType : A\nTTL : 201\nSection : Answer\nIP4Address : 156.112.108.76\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nIf not automatically started, initialize the Server Manager window by clicking its icon from the bottom left corner of the screen.\n\nOnce the Server Manager window is initialized, from the left pane, click to select the DNS category.\n\nFrom the right pane, under the \"SERVERS\" section, right-click the DNS server.\n\nFrom the context menu that appears, click \"DNS Manager\".\n\nIn the DNS Manager console tree on the DNS server being validated, navigate to \"Forward Lookup Zones\".\n\nRight-click the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-001184"]},{"vulnId":"V-259391","ruleId":"SV-259391r1043178_rule","severity":"medium","ruleTitle":"The Windows DNS Server must protect the authenticity of query responses via DNSSEC.","description":"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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nAuthenticity of query responses is provided with DNSSEC signing of zones.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2014 10:22:28 PM\nSigned: 10/22/2014 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nIn the DNS Manager console tree on the DNS server being validated, navigate to \"Forward Lookup Zones\".\n\nRight-click the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either saved parameters or custom parameters.","ccis":["CCI-001184"]},{"vulnId":"V-259392","ruleId":"SV-259392r961596_rule","severity":"medium","ruleTitle":"The Windows DNS Server must use an approved DOD PKI certificate authority.","description":"Untrusted certificate authorities (CA) can issue certificates, but the certificates 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.\n\nThe 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.\n\nTSIG and SIG(0) are not configurable in Windows DNS Server. To meet the requirement for authentication between Windows DNS Servers, IPsec must be implemented between the Windows DNS Servers.\n\nNote: 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 certificate authority (CA).\n\nRefer to the Microsoft Windows Server DNS Overview.pdf for references on deploying certificates for this procedure.","checkContent":"Note: This requirement applies to any Windows DNS Servers that host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too.\n\nThis requirement is not applicable to servers with only a caching role.\n\nIf the Windows DNS Servers host only AD-integrated zones, this requirement is not applicable.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"gpme.msc\" to open the Group Policy Management feature.\n\nIn the \"Browse for Group Policy Object\" dialog box, double-click \"Domain Controllers.domain.com\".\n\nClick \"Default Domain Controllers Policy\" and click \"OK\".\n\nIn the console tree, open Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Windows Firewall with Advanced Security\\Windows Firewall with Advanced Security - LDAP.\n\nClick \"Connection Security Rules\".\n\nConsult with the system administrator to determine which Rules meet the intent of DNSSEC server-to-server authentication.\n\nDouble-click on each \"Rule\" to verify the following:\n\nFor the \"Authentication\" tab, click on the \"Customize...\" button.\n\nOn the \"Authentication\" tab, verify \"Authentication mode:\" is set to \"Request authentication for inbound and outbound connections\".\n\nConfirm the \"Signing Algorithm\" is set to \"RSA (default)\".\n\nUnder \"Method\", verify the \"Advanced:\" radio button is selected. Click the \"Customize\" button.\n\nFor \"First authentication methods:\", double-click on the entry.\n\nVerify the \"Select the credential to use for first authentication:\" has \"Computer certificate from this certification authority (CA):\" radio button selected.\n\nReview the certificate specified and verify the certificate used was generated by the internally managed server performing the AD CS role.\n\nIf the certificate used does not meet the requirements, this is a finding.","fixText":"Complete the following procedures twice for each pair of name servers.\n \nCreate a rule for UDP connections and then create a rule for TCP connections.\n \nRefer to the Microsoft Windows Server DNS Overview.pdf for Microsoft links for this procedure.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"gpme.msc\" to open the Group Policy Management feature.\n\nIn the \"Browse for Group Policy Object\" dialog box, double-click \"Domain Controllers.domain.com\".\n\nClick \"Default Domain Controllers Policy\" and click \"OK\".\n\nIn the console tree, open Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Windows Firewall with Advanced Security\\Windows Firewall with Advanced Security - LDAP.\n\nRight-click \"Connection Security Rules\" and select \"New\".\n\nFor \"Rule Type\", select the \"Server-to-server\" radio button and click \"Next\".\n\nFor Endpoint 1 and Endpoint 2, select \"These IP addresses:\" and add the IP addresses of all DNS servers. Click \"Next\".\n\nFor \"Requirements\", select \"Request authentication for inbound and outbound connections\" and click \"Next\".\n\nFor \"Authentication Method\", select Computer certificate and from the \"Signing Algorithm:\" drop-down, select \"RSA (default)\".\n\nFrom the \"Certificate store type:\" drop-down, select \"Root CA (default)\".\n\nFrom the \"CA name:\", click \"Browse\" and select the certificate generated by the internally managed server performing the AD CS role. Click \"Next\".\n\nOn \"Profile\", accept the default selections and click \"Next\".\n\nOn \"Name\", enter a name applicable to the rule's function (i.e., DNSSEC UDP).\n\nClick \"Finish\".","ccis":["CCI-002470"]},{"vulnId":"V-259393","ruleId":"SV-259393r1028387_rule","severity":"medium","ruleTitle":"The Windows DNS Server must protect secret/private cryptographic keys while at rest.","description":"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 nonvolatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use.\n\nThe 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.","checkContent":"This check is not applicable for Windows DNS Servers that only host Active Directory-integrated zones or for Windows DNS servers on a classified network.\n\nTo verify 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.\n\nIf a backup policy does not exist or the backup policy does not specify the protection required for the backup medium to be at or above the level as the server, this is a finding.","fixText":"To ensure the cryptographic keys are protected after being backed up to tape or other medium, develop a backup policy that includes the protection of backup date at or above the level as the DNS server.","ccis":["CCI-001199"]},{"vulnId":"V-259394","ruleId":"SV-259394r961599_rule","severity":"medium","ruleTitle":"The Windows DNS Server must only contain zone records that have been validated annually.","description":"If zone information has not been validated in more than a year, there is no assurance that it is still valid. If invalid records are in a zone, an adversary could potentially use their existence for improper purposes. A standard operating procedure detailing this process can resolve this requirement.","checkContent":"This requirement is not applicable for a Windows DNS Server that is hosting only Active Directory (AD)-integrated zones.\n\nFor a Windows DNS Server that 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. Verify that the record's last verified date is less than one year prior to the date of the review.\n\nIf a separate database with record documentation is not maintained for the non-AD-integrated zone information, this is a finding.\n\nIf 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.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nReview the zone records of the non-AD-integrated zones and compare to the separate documentation maintained.\n\nDetermine if any records have not been validated in more than a year.\n\nIf zone records exist that have not been validated in more than a year, this is a finding.","fixText":"Create a separate database to maintain record documentation for non-AD-integrated zones.\n\nDevelop a procedure to validate annually all zone information on the DNS server against the separately maintained database.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nSelect the zone records that have not been validated in more than a year and revalidate.","ccis":["CCI-002475"]},{"vulnId":"V-259395","ruleId":"SV-259395r961152_rule","severity":"medium","ruleTitle":"The Windows DNS Server must restrict individuals from using it for launching denial-of-service (DoS) attacks against other information systems.","description":"Applications and application developers must take steps 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.","checkContent":"Review the DNS server to confirm the server restricts direct and remote console access to users other than Administrators.\n\nVerify the effective setting in Local Group Policy Editor.\n\nRun \"gpedit.msc\".\n\nNavigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.\n\nIf any accounts or groups other than the following are granted the \"Allow log on through Remote Desktop Services\" user right, this is a finding: \n\nAdministrators\n\nNavigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.\n\nIf the following accounts or groups are not defined for the \"Deny access to this computer from the network\" user right, this is a finding: \n\nGuests Group\n\nNavigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment.\n\nIf the following accounts or groups are not defined for the \"Deny log on locally\" user right, this is a finding: \n\nGuests Group","fixText":"Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> Allow log on through Remote Desktop Services to include only the following accounts or groups:\n\nAdministrators\n\nConfigure 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:\n\nGuests Group\n\nConfigure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment >> Deny log on locally to include the following:\n\nGuests Group","ccis":["CCI-001094"]},{"vulnId":"V-259396","ruleId":"SV-259396r961155_rule","severity":"medium","ruleTitle":"The Windows DNS Server must use DNS Notify to prevent denial of service (DoS) through increase in workload.","description":"In the case of application DoS attacks, care must be taken when designing the application to ensure it 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.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nIn the list of hosts, review the Name Server (NS) records. Determine if any of the hosts listed as NS records are non-Active Directory (AD)-integrated servers.\n\nIf the DNS server hosts only AD-integrated zones and no non-AD-integrated DNS servers are acting as secondary DNS servers for the zones, this check is not applicable.\n\nFor a non-AD-integrated DNS server, right-click on the \"Forward Lookup Zone\" and select \"Properties\".\n\nOn the opened zone's properties box, go to the \"Zone Transfers\" tab.\n\nOn the displayed interface, determine if the \"Allow zone transfers\" check box is selected.\n\nIf the \"Allow zone transfers\" check box is selected, click the \"Notify\" button and verify \"Automatically notify with Servers\" is listed on the \"Name Servers\" tab.\n\nIf the \"Notify\" button is not enabled for non-AD-integrated DNS servers, this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nIn the list of hosts, review the NS records. Determine if any of the hosts listed as NS records are non-AD-integrated servers.\n\nIf the DNS server hosts only AD-integrated zones and no non-AD-integrated DNS servers are acting as secondary DNS servers for the zones, this is not applicable.\n\nFor a non-AD-integrated DNS server, log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select and then right-click the zone name.\n\nFrom the displayed context menu, click the \"Properties\" option.\n\nOn the opened zone's properties box, go to the \"Zone Transfers\" tab.\n\nOn the displayed interface, determine if the \"Allow zone transfers\" check box is selected.\n\nIf the \"Allow zone transfers\" check box is selected, click the \"Notify\" button and enable Notify to the non-AD-integrated DNS servers.","ccis":["CCI-001095"]},{"vulnId":"V-259397","ruleId":"SV-259397r961632_rule","severity":"high","ruleTitle":"The Windows DNS Server must protect the integrity of transmitted information.","description":"Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered.\n\nCommunication 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, logical means (cryptography) do not have to be employed, and vice versa.\n\nConfidentiality 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2014 10:22:28 PM\nSigned 10/22/2014 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-002418"]},{"vulnId":"V-259398","ruleId":"SV-259398r961638_rule","severity":"medium","ruleTitle":"The Windows DNS Server must maintain the integrity of information during preparation for transmission.","description":"Information can be 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2014 10:22:28 PM\nSigned: 10/22/2014 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-002420"]},{"vulnId":"V-259399","ruleId":"SV-259399r961641_rule","severity":"medium","ruleTitle":"The Windows DNS Server must maintain the integrity of information during reception.","description":"Information can be 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.","checkContent":"Note: This check is not applicable for Windows DNS Servers that host only Active Directory-integrated zones or for Windows DNS Servers on a classified network.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the Windows DNS Server using the account designated as Administrator or DNS Administrator.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2022 10:22:28 PM\nSigned: 10/22/2022 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the Windows DNS Server using the Domain Admin or Enterprise Admin account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-002422"]},{"vulnId":"V-259400","ruleId":"SV-259400r1137676_rule","severity":"medium","ruleTitle":"The Windows DNS Server must implement NIST FIPS-validated cryptography for provisioning digital signatures, generating cryptographic hashes, and protecting unclassified information requiring confidentiality.","description":"Use of weak or untested encryption algorithms undermines the purposes of using 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.\n\nThe 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:\n- Digital Signature Algorithm (DSA).\n- RSA.\n- Elliptic Curve DSA (ECDSA).\n\nOf these three algorithms, RSA and DSA are more widely available and considered candidates of choice for DNSSEC. Both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. RSA is the recommended algorithm for this guideline. \n\nRSA 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.\n\nIt can be expected that name servers and clients will be able to use the RSA algorithm at a minimum. It is suggested that at least one ZSK for a zone use the RSA algorithm.\n\nNIST'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 30 September 2015.","checkContent":"Note: This requirement applies to any Windows DNS Server that hosts non-Active Directory (AD)-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server hosts only AD-integrated zones and does not host any file-based zones, this is not applicable.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2014 10:22:28 PM\nSigned: 10/22/2014 10:22:28 PM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign, the hosted zone(s) on the DNS server being validated.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\". \n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\", using either approved saved parameters or approved custom parameters.","ccis":["CCI-002450"]},{"vulnId":"V-259401","ruleId":"SV-259401r961158_rule","severity":"medium","ruleTitle":"The Windows DNS Server must be configured to only allow zone information that reflects the environment for which it is authoritative, including IP ranges and IP versions.","description":"DNS zone data for which a Windows DNS Server is authoritative should represent the network for which it is responsible. If a Windows DNS Server hosts zone records for other networks or environments, the records could become invalid or stale or be redundant/conflicting with a DNS server truly authoritative for the other network environment.","checkContent":"Consult with the system administrator to determine the IP ranges for the environment.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nIf not automatically started, initialize the \"Server Manager\" window by clicking its icon from the bottom left corner of the screen.\n\nOnce the \"Server Manager\" window is initialized, from the left pane, click to select the DNS category.\n\nFrom the right pane, under the \"SERVERS\" section, right-click the DNS server.\n\nFrom the context menu that appears, click \"DNS Manager\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select and then right-click the zone name.\n\nReview the zone information and compare it to the IP ranges for the environment.\n\nIf any zone information is for a different IP range or domain, this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nIf not automatically started, initialize the \"Server Manager\" window by clicking its icon from the bottom left corner of the screen.\n\nOnce the \"Server Manager\" window is initialized, from the left pane, click to select the DNS category.\n\nFrom the right pane, under the \"SERVERS\" section, right-click the DNS server.\n\nFrom the context menu that appears, click \"DNS Manager\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name and then expand \"Forward Lookup Zones\".\n\nRemove any zone information that is not part of the environment.","ccis":["CCI-001310"]},{"vulnId":"V-259402","ruleId":"SV-259402r1156951_rule","severity":"medium","ruleTitle":"The Windows DNS Server must follow procedures to re-role a secondary name server as the primary name server if the primary name server permanently loses functionality.","description":"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).\n\nIf 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 in this state.","checkContent":"Active Directory (AD)-integrated DNS servers will handle the promotion of a secondary DNS server when a primary DNS server loses functionality.\n\nIf all of the DNS servers are AD integrated, this is not a finding.\n\nConsult with the system administrator to determine if there are documented procedures to re-role a non-AD-integrated secondary name server to a master name server role if a master name server loses functionality.\n\nIf there are no documented procedures to re-role a non-AD-integrated secondary name server to primary if a master name server loses functionality, this is a finding.","fixText":"AD-integrated DNS servers will handle the promotion of a secondary DNS server when a primary DNS server loses functionality.\n\nDevelop, test, and implement documented procedures to re-role a non-AD-integrated secondary name server to a master name server role if a master name server loses functionality.","ccis":["CCI-000366","CCI-002775"]},{"vulnId":"V-259403","ruleId":"SV-259403r1001264_rule","severity":"medium","ruleTitle":"The DNS Name Server software must be configured to refuse queries for its version information.","description":"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 address those vulnerabilities. The 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.\n\nIn some installations, it may not be possible to switch 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 looking for a specific version of the software that 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.","checkContent":"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.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nOpen a command window and execute the command:\n\nnslookup <enter>\nNote: Confirm the Default Server is the DNS server on which the command is being run.\n\nAt the nslookup prompt, type:\n\nset type=TXT <enter>\nset class=CHAOS <enter>\nversion.bind <enter>\n\nIf the response returns something similar to text = \"Microsoft DNS 6.1.7601 (1DB14556)\", this is a finding.","fixText":"To disable the version being returned in queries, execute the following command:\n\ndnscmd /config /EnableVersionQuery 0 <enter>","ccis":["CCI-002201"]},{"vulnId":"V-259404","ruleId":"SV-259404r1001265_rule","severity":"medium","ruleTitle":"The HINFO, RP, TXT, and LOC RR types must not be used in the zone SOA.","description":"Several types of resource records (RRs) in the DNS 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 operating system or platform known to have exploits.\n\nTherefore, great care should be taken before including these record types in a zone. They are best left out completely.\n\nMore 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 RRs 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.\n\nA 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.\n\nRRs 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.","checkContent":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nReview the zone's RRs and verify HINFO, RP, and LOC RRs are not used. If TXT RRs are used, they must not reveal any information about the organization that could be used for malicious purposes.\n\nIf there are any HINFO, RP, LOC, or revealing TXT RRs in any zone hosted by the DNS server, this is a finding.","fixText":"Log on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\".\n\nFrom the expanded list, click to select the zone.\n\nRemove all HINFO, RP, TXT, and LOC RRs from all zones hosted by the DNS server.","ccis":["CCI-002201"]},{"vulnId":"V-259405","ruleId":"SV-259405r1156945_rule","severity":"medium","ruleTitle":"The Windows DNS Server must, when a component failure is detected, activate a notification to the system administrator.","description":"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.\n\nThis 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.\n\nIf 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 in this state.","checkContent":"Notification to the system administrator is not configurable in Windows DNS Server. For system administrators to be notified when a component fails, the system administrator would have 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.\n\nIf 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.","fixText":"Implement a third-party monitoring system to detect and notify the system administrator upon component failure or, at a minimum, document and implement a procedure to review the diagnostic logs on a routine basis every day.","ccis":["CCI-000366","CCI-001328"]},{"vulnId":"V-259406","ruleId":"SV-259406r961734_rule","severity":"medium","ruleTitle":"The Windows DNS Server must verify the correct operation of security functions upon startup and/or restart, upon command by a user with privileged access, and/or every 30 days.","description":"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. \n\nNotifications provided by information systems include, for example, electronic alerts to system administrators, messages to local computer consoles, and/or hardware indications, such as lights.\n\nThe DNS server should perform self-tests, such as at server startup, to confirm that its security functions are working properly.","checkContent":"Note: This requirement applies to any Windows DNS Server that hosts non-Active Directory (AD)-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server hosts only AD-integrated zones and does not host any file-based zones, this is not applicable.\n\nValidate this check from the Windows DNS Server being configured/reviewed.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nDetermine a valid host in the zone.\n\nOpen the Windows PowerShell prompt on the Windows DNS Server being configured/reviewed.\n\nIssue the following command:\n(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 DNS Server hosting the signed zone.)\n\nresolve-dnsname www.zonename.mil -server ###.###.###.### -dnssecok <enter>\n\nNote: It is important to use the -server switch followed by the DNS server name/IP address.\n\nThe result should show the \"A\" record results.\n\nIn addition, the results should show QueryType: RRSIG with an expiration, date signed, signer, and signature, similar to the following:\n\nName: www.zonename.mil\nQueryType: RRSIG\nTTL: 189\nSection: Answer\nTypeCovered: CNAME\nAlgorithm: 8\nLabelCount: 3\nOriginalTtl: 300\nExpiration: 11/21/2022 10:22:28 AM\nSigned: 10/22/2022 10:22:28 AM\nSigner: zonename.mil\nSignature: {87, 232, 34, 134...}\n\nName: origin-www.zonename.mil\nQueryType: A\nTTL: 201\nSection: Answer\nIP4Address: ###.###.###.###\n\nIf the results do not show the RRSIG and signature information, this is a finding.","fixText":"Sign or re-sign the hosted zone(s) on the DNS server being validated.\n\nLog on to the DNS server using the Domain Admin or Enterprise Admin account or Local Administrator account.\n\nPress the Windows key + R and execute \"dnsmgmt.msc\".\n\nOn the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server and then expand \"Forward Lookup Zones\". \n\nFrom the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click \"Sign the Zone\" using either approved saved parameters or approved custom parameters.","ccis":["CCI-002699"]},{"vulnId":"V-259407","ruleId":"SV-259407r961734_rule","severity":"medium","ruleTitle":"The Windows DNS Server must verify the correct operation of security functions upon system startup and/or restart, upon command by a user with privileged access, and/or every 30 days.","description":"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. \n\nNotifications provided by information systems include, for example, electronic alerts to system administrators, messages to local computer consoles, and/or hardware indications, such as lights.\n\nThe DNS server should perform self-tests, such as at server startup, to confirm that its security functions are working properly.","checkContent":"This functionality should be performed by an approved and properly configured DOD system monitoring solution. \n\nIf all required DOD products are not installed and /or the installed productions are not enabled, this is a finding.","fixText":"Install an approved DOD system monitoring solution.","ccis":["CCI-002699"]},{"vulnId":"V-259408","ruleId":"SV-259408r961737_rule","severity":"medium","ruleTitle":"The Windows DNS Server must log the event and notify the system administrator when anomalies in the operation of the signed zone transfers are discovered.","description":"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.\n\nIf anomalies are not acted on, security functions may fail to secure the system.\n\nThe 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 operating system/network device manager can then trigger notification messages to the system administrator based on the presence of those audit records.","checkContent":"Note: If the only zones hosted are AD-integrated zones, this check is not applicable.\n\nNotification to the system administrator is not configurable in Windows. For the administrator to be notified if functionality of DNSSEC/TSIG has been removed or broken, the information system security officer (ISSO), information system security manager (ISSM), or 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.\n\nIf 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.","fixText":"Implement 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.","ccis":["CCI-002702"]},{"vulnId":"V-259409","ruleId":"SV-259409r961185_rule","severity":"medium","ruleTitle":"The Windows DNS Server must be configured to notify the information system security officer (ISSO), information system security manager (ISSM), or DNS administrator when functionality of DNSSEC/TSIG has been removed or broken.","description":"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.\n\nThe DNS server should be configured to generate audit records whenever a self-test fails. The operating system/network device manager is responsible for generating notification messages related to this audit record.","checkContent":"Note: This check is not applicable for Windows DNS Servers that only host Active Directory-integrated zones or for Windows DNS servers on a classified network.\n\nNotification to the system administrator is not configurable in Windows DNS Server. For the 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.\n\nIf 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.","fixText":"Implement a third-party monitoring system to detect and notify the ISSO/ISSM/DNS administrator if functionality of Secure Updates has been removed or broken or, at a minimum, document and implement a procedure to review the diagnostic logs on a routine basis every day.","ccis":["CCI-001294"]},{"vulnId":"V-259410","ruleId":"SV-259410r1156963_rule","severity":"medium","ruleTitle":"A unique Transaction Signature (TSIG) key must be generated for each pair of communicating hosts.","description":"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 also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string 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 Resource Record (RR) and used to authenticate an entire DNS message.","checkContent":"This check is not applicable for Windows DNS Servers that only host Active Directory-integrated zones or for Windows DNS servers on a classified network.\n\nReview the DNS implementation. Verify that each pair of communicating hosts has a unique TSIG key (i.e., a separate key for each secondary name server to authenticate transactions with the primary name server, etc.).\n\nIf a unique TSIG key has not been generated for each pair of communicating hosts, this is a finding.\n\nIf using DNSSEC, this requirement is not applicable.","fixText":"Regenerate a unique TSIG key for each pair of communicating hosts within the DNS architecture.","ccis":["CCI-000186"]},{"vulnId":"V-259411","ruleId":"SV-259411r961062_rule","severity":"medium","ruleTitle":"The DNS server implementation must employ strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions.","description":"If unauthorized personnel use maintenance tools, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data.\n\nNonlocal maintenance and diagnostic activities are conducted by individuals communicating through an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, public key infrastructure (PKI) where certificates are stored on a token protected by a password, passphrase, or biometric.\n\nThis requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing \"ping\", \"ls\", or \"ipconfig\" or the hardware and software implementing the monitoring port of an Ethernet switch).\n\nLack of authentication enables anyone to gain access to the network or possibly a network element that provides opportunity for intruders to compromise resources within the network infrastructure. Network access control mechanisms interoperate to prevent unauthorized access and enforce the organization's security policy. Authorization for access to any network element requires an individual account identifier that has been approved, assigned, and configured on an authentication server. Authentication of all administrator accounts for all privilege levels must be accomplished using two or more factors that include the following:\n\n(i) something the user knows (e.g., password/PIN); \n(ii) something the user has (e.g., cryptographic identification device, token); or \n(iii) something the user is (e.g., biometric).","checkContent":"Review the DNS implementation's authentication methods and settings to determine if multifactor authentication is used to gain nonlocal access for maintenance and diagnostics.\n\nIf multifactor authentication is not used, this is a finding.","fixText":"Configure the DNS system to use multifactor authentication for nonlocal access for maintenance and diagnostics.","ccis":["CCI-000877"]},{"vulnId":"V-259412","ruleId":"SV-259412r961125_rule","severity":"medium","ruleTitle":"In the event of a system failure, the Windows DNS Server must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes.","description":"Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving application state information helps to facilitate application restart and return to the operational mode of the organization with less disruption to mission-essential processes.","checkContent":"Use the AuditPol tool to review the current Audit Policy configuration:\n\nOpen a Command Prompt with elevated privileges (\"Run as Administrator\").\n\nEnter \"AuditPol /get /category:*\".\n\nCompare the AuditPol settings with the following. If the system does not audit the following, this is a finding.\n\nObject Access >> File System - Failure","fixText":"Configure the policy value for Computer Configuration >> Windows Settings >> Security Settings >> Advanced Audit Policy Configuration >> System Audit Policies >> Object Access >> Audit File System with \"Failure\" selected.","ccis":["CCI-001665"]},{"vulnId":"V-259414","ruleId":"SV-259414r1156961_rule","severity":"medium","ruleTitle":"The private keys corresponding to both the zone signing key (ZSK) and the key signing key (KSK) must not be kept on the DNSSEC-aware primary authoritative name server when the name server does not support dynamic updates.","description":"The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored offline (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.\n\nThis strategy is not feasible in situations in which the DNSSEC-aware name server must support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) must 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 Resource Record Sets. The private key corresponding to the key signing key (KSK-private) can still be kept offline.","checkContent":"This check is not applicable for Windows DNS Servers that only host Active Directory-integrated zones or for Windows DNS servers on a classified network. \n\nReview the DNS name server and documentation to determine if it accepts dynamic updates. \n\nIf dynamic updates are not accepted, verify the private keys corresponding to both the ZSK and KSK are not located on the name server.\n\nIf the private keys to the ZSK and/or the KSK are located on the name server, this is a finding.","fixText":"Store the private keys of the ZSK and KSK offline in an encrypted file system.","ccis":["CCI-000366"]},{"vulnId":"V-259415","ruleId":"SV-259415r960948_rule","severity":"medium","ruleTitle":"The Windows DNS Server 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.","description":"Protection of log data includes ensuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto media separate from the system being audited on a defined frequency helps to ensure the audit records will be retained in the event of a catastrophic system failure.\n\nThis helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records.\n\nThis requirement applies only to applications that have a native backup capability for audit records. Operating system backup requirements cover applications that do not provide native backup functions.","checkContent":"Consult with the system administrator to determine the backup policy in place for Windows DNS Server.\n\nReview 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.\n\nIf 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.","fixText":"Document and implement a backup policy to back up the DNS server's audit records at least every seven days.","ccis":["CCI-001348"]},{"vulnId":"V-259416","ruleId":"SV-259416r961863_rule","severity":"medium","ruleTitle":"In 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.","description":"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. \n\nOne 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 resource records (RRs) pertaining to hosts with public services (web servers that serve external web pages or provide business-to-consumer services, mail servers, etc.).\n\nThe other set, called internal name servers, is to be located within the firewall and should be configured so the servers are not reachable from outside and hence provide naming services exclusively to internal clients.","checkContent":"Consult with the system administrator to review the internal Windows DNS Server's firewall policy.\n\nThe inbound TCP and UDP ports 53 rule should be configured to only allow hosts from the internal network to query the internal DNS server.\n\nIf the firewall policy is not configured with the restriction, consult with the network firewall administrator to confirm the restriction on the network firewall.\n\nIf neither the DNS server's firewall policy nor the network firewall is configured to block external hosts from querying the internal DNS server, this is a finding.","fixText":"Configure the internal DNS server's firewall policy, or the network firewall, to block queries from external hosts.","ccis":["CCI-000366"]},{"vulnId":"V-259417","ruleId":"SV-259417r961155_rule","severity":"medium","ruleTitle":"Windows DNS response rate limiting (RRL) must be enabled.","description":"This setting can prevent someone from sending a denial-of-service attack using the DNS servers. For instance, a bot net can send requests to the DNS server using the IP address of a third computer as the requestor. Without RRL, the DNS servers might respond to all the requests, flooding the third computer.","checkContent":"As an administrator, run PowerShell and enter the following command: \n\"Get-DnsServerResponseRateLimiting\". \n\nIf \"Mode\" is not set to \"Enable\", this is a finding.","fixText":"As an administrator, run PowerShell and enter the command \"Set-DnsServerResponseRateLimiting\" to apply default values or \"Set-DnsServerResponseRateLimiting -WindowInSec 7 -LeakRate 4 -TruncateRate 3 -ErrorsPerSec 8 -ResponsesPerSec 8\". \n\nThese settings are just an example. For more information, go to:\nhttps://learn.microsoft.com/en-us/powershell/module/dnsserver/set-dnsserverresponseratelimiting?view=windowsserver2022-ps","ccis":["CCI-001095"]}]}