Cyber Trackr - Free Compliance Library
Cyber Trackr
The Free Compliance Library

DNS Policy

  • Version/Release: V4R1.22
  • Published: 2018-04-05
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

The DNS Policy Security Technical Implementation Guide (STIG) is published as a tool to improve the security of Department of Defense (DoD) information systems. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.
b
Servers do not employ Host Based Intrusion Detection (HIDS).
Medium - V-4027 - SV-4027r1_rule
RMF Control
Severity
Medium
CCI
Version
EN540
Vuln IDs
  • V-4027
Rule IDs
  • SV-4027r1_rule
Servers without a HID may allow unauthorized access to go undetected and limit the ability of security personnel to stop malicious or unauthorized use of the device. In order to ensure that an attempted or existing attack goes unnoticed, the data from the HID must be monitored continuously.trueInformation Assurance Officer
Checks: C-4321r1_chk

Interview the IAO to determine if there is a process and policy in place to ensure Host Based IDS is installed on all servers. Work with the reviewers to determine compliance. **This check applies to Enhanced Compliance Validation visits.

Fix: F-3960r1_fix

The IAO will ensure all servers employ HIDS, if technically feasible. This requirement may not pertain to legacy systems and cutting edge devices that do not yet have the capability. Documentation must exist from the vendor to approve any variance from this requirement.

b
A name server is not protected by equivalent or better physical access controls than the clients it supports.
Medium - V-13032 - SV-13600r1_rule
RMF Control
Severity
Medium
CCI
Version
DNS0100
Vuln IDs
  • V-13032
Rule IDs
  • SV-13600r1_rule
If an adversary can compromise a name server, then the adversary can redirect most network traffic sent to the hosts defined on that name server. Therefore, the security of the name server is as critical as the security of the hosts it protects. It is understood that different hosts require different levels of physical security. Nevertheless, the name server should not have weaker physical access controls than the computers it supports because this would, in effect, reduce the security of those hosts as well.Information Assurance Officer
Checks: C-3336r1_chk

Ask to see the locations at the facility where computers supported by the listed name server(s) under evaluation are located (e.g., server closets, raised floor space, etc.). Note those areas that have the most extensive physical security controls. Also ask to see the locations of the name servers themselves. Then compare the physical security of the most secure computers against the physical security of the name server under evaluation. If the name server has substantially weaker physical security controls than the hosts it supports (e.g., the name server is in the DNS administrator’s cube while the servers are in a locked cage in a secure raised floor area), then this is a finding.

Fix: F-4336r1_fix

Working with appropriate technical and facility personnel, the IAO should arrange to relocate the name server into the same physical location as the most sensitive hosts it supports.

b
The DNS log archival requirements do not meet or exceed the log archival requirements of the operating system on which the DNS software resides.
Medium - V-13034 - SV-13602r1_rule
RMF Control
Severity
Medium
CCI
Version
DNS0110
Vuln IDs
  • V-13034
Rule IDs
  • SV-13602r1_rule
Name servers are dedicated to the DNS function and, as a result, the most critical security and operations events on those name servers will appear in the DNS logs. Different sites may have different policies regarding archival, but the DNS logs should be maintained in an equivalent (or better) manner as the operating system logs. Therefore, if operating system logs are stored for a year, then DNS logs should be stored for at least a year. If operating system logs are written to read-only media, then the DNS logs should be written to read-only media as well.Information Assurance Officer
Checks: C-3355r1_chk

This check is only applicable if DNS logs are independent from system logs. If the log archival scheme for the DNS logs is weaker than the one for the system logs, then this is a finding.This check is only applicable if DNS logs are independent from system logs. If the log archival scheme for the DNS logs is weaker than the one for the system logs, then this is a finding. Windows DNS log files are normally kept in two locations. The system event logs which can be viewed from Event Viewer found under the Administrative tools from the Start Menu. In addition, debug logging options such as query, notify, and update requirements can be viewed in a file named %systemroot%\system32\dns\dns.log. BIND BIND logging files can be found by viewing the /etc/named.conf file. Within the named.conf will be an option for logging that will display the file path to the log files. In addition, most Unix machines will also log information in the syslog on the system.

Fix: F-4338r1_fix

Working with appropriate technical and facility personnel, the IAO should implement an archival strategy that is at least as extensive as the current archival operation for operating system logs.

b
DNS logs are not reviewed daily or a real-time log analysis or network management tool is not employed to immediately alert an administrator of critical DNS system messages.
Medium - V-13035 - SV-13603r2_rule
RMF Control
Severity
Medium
CCI
Version
DNS0115
Vuln IDs
  • V-13035
Rule IDs
  • SV-13603r2_rule
If a responsible administrator does not review DNS logs daily, then there is the potential that an attack or other security issue can go unnoticed for a day or more, which is unacceptable in DOD environments.Information Assurance Officer
Checks: C-3356r3_chk

If reviewing of logs is anything less than daily, or isn't performed by the ISSO/ISSM or under the ISSO/ISSM oversight, then this is a finding. In many cases, DNS logs are included within the system logs. If this is the case, then daily review of the system logs meets the requirement. If the site employs special software to scan logs for special events or key words, then this is also acceptable so long as the system issues real time alerts or is monitored at least daily. Windows DNS log files are normally kept in two locations. The system event logs which can be viewed from Event Viewer found under the Administrative tools from the Start Menu. In addition, debug logging options such as query, notify, and update requirements can be viewed in a file named %systemroot%\system32\dns\dns.log. BIND BIND logging files can be found by viewing the /etc/named.conf file. Within the named.conf will be an option for logging that will display the file path to the log files. In addition, most Unix machines will also log information in the syslog on the system. Windows DNS log files are normally kept in two locations. The system event logs which can be viewed from Event Viewer found under the Administrative tools from the Start Menu. In addition, debug logging options such as query, notify, and update requirements can be viewed in a file named %systemroot%\system32\dns\dns.log. BIND BIND logging files can be found by viewing the /etc/named.conf file. Within the named.conf will be an option for logging that will display the file path to the log files. In addition, most Unix machines will also log information in the syslog on the system.

Fix: F-4339r2_fix

The ISSO/ISSM should commit to reviewing logs daily or have oversight of the review daily, perhaps establishing a rotation for this purpose to ensure that days are not missed. Having a primary administrator and backup administrators rotate this responsibility will prevent a problem or warning sign from being missed because of an error in judgment.

a
A list of personnel authorized to administer each zone and name server is not maintained.
Low - V-13036 - SV-13604r3_rule
RMF Control
Severity
Low
CCI
Version
DNS0120
Vuln IDs
  • V-13036
Rule IDs
  • SV-13604r3_rule
If an organization does not document who is responsible for the DNS function, then there is a significant potential that unauthorized individuals will obtain privileged access to name servers. During a security breach, it will be difficult to assign accountability for improper transactions if it is not known who is responsible for this function. The roles of the SA and the DNS administrator or DNS manager are generally understood but are often used interchangeably. The SA is responsible for the OS, while the DNS administrator or DNS manager usually manages the DNS zones. In some cases, the SA is also the DNS administrator/DNS manager, which is why guidance tends to be written in a certain fashion. The application development group should refer to the supporting organization for the application when application issues arise from meeting DNS server requirements. Information Assurance Officer
Checks: C-3358r4_chk

Interview the ISSO and ask for the DNS server’s documented procedures and processes. Verify the documented procedures and processes explicitly document the roles and responsibilities for the DNS server management. These documented roles will be used to validate access controls in respective DNS technology STIGs. In some environments, the SA is also the DNS manager. In such case, the roles should still be documented. If the organization does not have the DNS server roles documented, this is a finding.

Fix: F-4340r2_fix

The ISSO must create and maintain a list of authorized DNS administrators for each zone and name server under the ISSOs scope of responsibility.

a
A patch and DNS software upgrade log; to include the identity of the administrator, date and time each patch or upgrade was implemented, is not maintained.
Low - V-13037 - SV-13605r1_rule
RMF Control
Severity
Low
CCI
Version
DNS0130
Vuln IDs
  • V-13037
Rule IDs
  • SV-13605r1_rule
DNS software has a history of vulnerabilities and new ones may be discovered at any time. To ensure that attackers cannot take advantage of known DNS vulnerabilities applicable software patches and patches must be applied. Patch and DNS software upgrade documentation must be maintained to ensure the DNS name servers are protected from these vulnerabilities and current with required patches and software upgrades.System Administrator
Checks: C-3360r1_chk

DNS patch and upgrade change records must include records of the date and time each patch or upgrade to DNS software was implemented, and by whom. The method of verification may be considered weak, but the requirement is merely to document the dates and times of DNS software patch and upgrades. Instruction: If there is no patch and upgrade log, then this is a finding. If there is such a log, then entries must include the date and time of any change as well as the identity of the administrator. Failure to include this information for any entry is a finding.

Fix: F-4342r1_fix

The SA should establish and maintain a log of the date and time each patch and upgrade to DNS software was implemented.

b
Operating procedures do not require that DNS configuration, keys, zones, and resource record data are backed up on any day on which there are changes.
Medium - V-13038 - SV-13606r1_rule
RMF Control
Severity
Medium
CCI
Version
DNS0135
Vuln IDs
  • V-13038
Rule IDs
  • SV-13606r1_rule
If a name servers configuration, keys, zones, and resource record information is not backed up on any day in which there are changes, there is a risk that an organization cannot quickly recover from the loss of the server. In addition, forensic analysis of security incidents is considerably more difficult if there is not reliable evidence of when changes may have occurred.Information Assurance Officer
Checks: C-3361r1_chk

Fortunately, by design, the DNS architecture provides built-in redundancy support. There should always be a hot backup of zone information present whenever the primary name server is unavailable for any reason (i.e., the authoritative slave server maintains a copy of the zone files on the master). This built-in redundancy, however, does not extend to configuration files and logs. Therefore, name servers should be backed up to an external media (e.g., tape, optical disk, etc.) on a regular basis. At some locations, an automated enterprise backup system supports many servers. In this case, name servers can simply be added to the enterprise system. At other locations, backups must be performed manually, placing a considerably higher burden on administrators. In circumstances in which zone and configuration information is very static, remaining the same for several months at a time, it would make little sense to conduct daily full backups. Backups should occur as frequently as needed to capture changes on the name server. If there are no written procedures for the backup of name servers, then this is a finding. Backup in this context refers to copying the name server’s DNS configuration, keys, zones, and resource record data, at a minimum, in case it is needed for recovery at a later time. A full file system backup of the name server is preferred. If there are written backup procedures, then it must call for the backup of DNS configuration, keys, zones, and resource record data on any day in which they were modified, it this is not the case, then this is a finding. Any traditional daily tape backup scheme – whether it involves a full, incremental or differential scheme – will satisfy the requirement. Less frequent backups will also suffice if the configuration and resource record data are backed up whenever they are modified.

Fix: F-4343r1_fix

The IAO will establish operating procedures that will ensure that, at a minimum, DNS configuration, keys, zones, and resource record data is backed up on any day on which there are changes.

b
Configuration change logs and justification for changes are not maintained.
Medium - V-13039 - SV-13607r1_rule
RMF Control
Severity
Medium
CCI
Version
DNS0140
Vuln IDs
  • V-13039
Rule IDs
  • SV-13607r1_rule
If changes are made to the configuration without documentation, it is often difficult to determine the root cause of an operational problem or understand the circumstances in which a security breach occurred. Without adequate configuration change records, it is also more difficult for the IAO and other oversight personnel to track major activity, which is critical to information assurance.Information Assurance Officer
Checks: C-3362r1_chk

The DNS configuration change log must note the date and time any DNS configuration files were modified and the business justification for that modification. Unless the business justification is routinely so vague as to be meaningless (e.g., “user request” for every entry), the reviewer should not second-guess what constitutes an acceptable business rationale. Instruction: If there is no configuration change log, then this is a finding. If there are such records, then entries must include the date and time of any change and the business rationale for the change. Failure to include this information for any entry is a finding.

Fix: F-4344r1_fix

The IAO should implement, maintain, and periodically check compliance with configuration management requirements. The configuration change log should include, at a minimum, the date and time of any modifications to the DNS configuration files and the business justification for that modification.

b
Written procedures for the replacement of cryptographic keys used to secure DNS transactions does not exist.
Medium - V-13040 - SV-13608r1_rule
RMF Control
Severity
Medium
CCI
Version
DNS0145
Vuln IDs
  • V-13040
Rule IDs
  • SV-13608r1_rule
Without adequate TSIG supersession procedures, there is the potential that an unauthorized person may be able to compromise the key. Once in possession of the key, that individual might be able to update DNS records by configuring a machine to masquerade as a zone partner. Since name servers are configured to accept updates signed by a valid key, there may be no other administrative or technical controls to prevent this type of security breach.Information Assurance Officer
Checks: C-3363r1_chk

Windows This check should be marked not applicable for all windows servers. Windows utilizes Active Directory for it’s key management or no keys at all. BIND Like user account passwords, cryptographic keys such as TSIG keys must be changed periodically to minimize the probability that they will be compromised. If there is a known compromise of a TSIG key, then it needs to be replaced immediately. One of the most important aspects of key supersession is the method that will be used to transfer newly generated keys. Possibilities, in rough order of preference, are as follows: - SSH - Encrypted e-mail using DoD PKI certificates - Secure fax (STU-III) - Regular mail (using the expedited mailing service holding the current GSA contract for "small package overnight delivery service") - Hand courier Instruction: If there are no procedures for TSIG key supersession, then this is a finding. If there are such procedures, then it must cover the following: - Frequency of key supersession - Criteria for triggering emergency supersession events - Notification of relevant personnel during emergency and non-emergency supersession - Methods for securely transferring newly generated keys This is a finding if any of these elements are missing from the supersession procedures.

Fix: F-4345r1_fix

The IAO should establish standard operating procedures for TSIG key supersession. These procedures should include, at a minimum, frequency of key supersession, criteria for triggering emergency supersession events, notification of relevant personnel during emergency and non-emergency supersession, and methods for securely transferring newly generated keys.

b
The IAO has not established written procedures for the process of updating zone records, who is authorized to submit and approve update requests, how the DNS administrator verifies the identity of the person from whom he/she received the request, and how the DNS administrator documents any changes made.
Medium - V-13041 - SV-13609r1_rule
RMF Control
Severity
Medium
CCI
Version
DNS0150
Vuln IDs
  • V-13041
Rule IDs
  • SV-13609r1_rule
If the procedures for updating zone records are inadequate, then this increases the probability that adversary perhaps even an insider will be able to modify the DNS records using weaknesses in administrative processes rather than weaknesses in technical controls.Information Assurance Officer
Checks: C-3364r1_chk

To best assure the integrity of zone files, one must not only carefully manage the manner in which requests are processed but also periodically check that the current records are valid. For example, when equipment is retired, people often fail to remove the associated host from the DNS. Without periodic checks, an attacker may use a retired host IP address to obtain valuable information from another user who was unaware of the change. Instruction: If there are no written procedures for manual updates of zone files (e.g., a new host entry), then this is a finding. If there are such procedures, then it must cover the following: - The process for updating zone records - Who is authorized to submit and approve update requests - How the DNS database administrator verifies the identity of the person from whom he or she received the request - How the DNS database administrator documents any changes made This is a finding if any of these elements are missing from the procedures for manually updating zone records. *Note: If secure dynamic updates are being utilized without any administrator interaction, then this check can be marked Not Applicable.

Fix: F-4346r1_fix

The IAO should establish standard operating procedures for updating zone records. These procedures should include, at a minimum, the process for updating zone records, who is authorized to submit and approve update requests, how the DNS database administrator verifies the identity of the person from whom he or she received the request, and how the DNS database administrator documents any changes made.

c
An authoritative master name server does not have at least one and preferably two or more active slave servers for each of its zones. The slave server does not reside on a separate host.
High - V-13042 - SV-13610r2_rule
RMF Control
Severity
High
CCI
Version
DNS0200
Vuln IDs
  • V-13042
Rule IDs
  • SV-13610r2_rule
A critical component of securing an information system is ensuring its availability. The best way to ensure availability is to eliminate any single point of failure in the system itself and in the network architecture that supports it. Fortunately, the inherent design of DNS supports a high-availability environment. Master and slave servers regularly communicate zone information, so if any name server is disabled at any time, another can immediately provide the same service. The task for the network architect is to ensure that a disaster or outage cannot simultaneously impact both the master and all of its slave servers. If a disaster occurs, the DNS protocols cannot prevent total loss of name resolution services for hosts within affected zones. Information Assurance Officer
Checks: C-3424r3_chk

The intent of this check is to ensure zone queries can be answered in the event of failure of the primary name server. By requiring at least one other name server, queries will still be answered by one name server in the event of another name server failure. Using the name server configuration files, identify any zone that does not have multiple name servers. An authoritative server for each zone must have more than one name server. If there is only one name server for a zone, this is a finding. If the secondary server does not reside on a separate host, this is a finding. Windows (with Active Directory) For servers integrated with Active Directory, verify there are other domain controllers that can take over as Domain naming operations master. Open the Active Users and Computer snap in console under the Administrative tools menu. Expand the active directory domain and then expand the domain controllers folder. Ensure there are multiple domain controllers available within the domain. BIND Examine each zone file and check the NS records. There should be multiple records for the same domain with different servers authoritative for the zone. The path to the zone file can be found by examining the named.conf.

Fix: F-4347r2_fix

The ISSO must work with appropriate personnel to obtain and configure another name server to act as a slave to the server hosting this zone.

c
Name servers authoritative for a zone are not located on separate network segments if the host records described in the zone are themselves located across more than one network segment.
High - V-13043 - SV-13611r3_rule
RMF Control
Severity
High
CCI
Version
DNS0205
Vuln IDs
  • V-13043
Rule IDs
  • SV-13611r3_rule
A critical component of securing an information system is ensuring its availability. The best way to ensure availability is to eliminate any single point of failure in the system itself and in the network architecture that supports it. Fortunately, the inherent design of DNS supports a high-availability environment. Master and slave servers regularly communicate zone information, so if any name server is disabled at any time, another can immediately provide the same service. The task for the network architect is to ensure that a disaster or outage cannot simultaneously impact both the master and all of its slave servers. If a disaster occurs, the DNS protocols cannot prevent total loss of name resolution services for hosts within affected zones. The solution is to disperse name servers in such a way as to avoid single points of failure. At minimum, authoritative name servers for the same zone should be on different network segments in order that at least one name server is available in the event that a router or switch fails. This fault tolerance should also extend to wide area data communications lines. For example, if a site has multiple leased lines connecting the network on which the name server resides to a larger network such as the NIPRNet, routing protocols should be configured such that if one of the lines fails, another one will still be available to support the name server. Information Assurance Officer
Checks: C-3425r5_chk

The intent of this requirement is to ensure all hosts in a zone can access an authoritative name server hosting their zone. Either a name server must reside on every subnet where hosts are located for each zone or name server on other subnets must be accessible for DNS queries by the hosts on subnets without a name server. NOTE: For networks with only Active Directory authoritative zones, the Microsoft Windows 2012 Server Domain Name System Security Technical Implementation Guide should be followed for explicit guidance. Determine if host records in a zone are on the same subnet. If the records are on one subnet primary and at least one secondary nameserver is required on that same subnet. If multiple subnets are found, then a server should be available for each subnet. Determine if there is a name server on each of the subnets where hosts are located. If name servers are not on each subnet where hosts are located, validate the installed name servers on other subnets are accessible by the hosts on the subnets without a name server. If each subnet hosting hosts for a zone does not have a name server on the same subnet and name servers on other subnets are not accessible by the hosts on the subnet without a name server, this is a finding. The reviewer can manually check the IP addresses of the servers being reviewed to determine if they are on the same subnet.

Fix: F-4348r2_fix

Working with appropriate technology and facility personnel, the ISSO should arrange to relocate one of the name servers so that it resides on a different network segment than any other name server that hosts one or more of the same zones or ensure connectivity exists to allow for accessibility across subnets from hosts to existing name servers. In cases where the zones are small and not subject to frequent change, consideration should be given to the use of hosts or lmhost files to resolve host names.

b
A zone includes hosts located in more than one building or site, yet at least one of the authoritative name servers supporting the zone is not as geographically and topologically distributed as the most remote host.
Medium - V-13044 - SV-13612r1_rule
RMF Control
Severity
Medium
CCI
Version
DNS0210
Vuln IDs
  • V-13044
Rule IDs
  • SV-13612r1_rule
When authoritative name servers are co-located in the same facility, the loss of the facility likely leads to the loss of access to all servers defined in their zones (i.e., nobody can resolve their names). If one or more of the hosts in the supported zones are located at a different site, they would be effectively down even though they would otherwise be fully operational. This scenario can only be prevented with geographic dispersal of name servers. Organizations should also be prepared for greater disasters, such as the destruction of a building, an entire campus, or in the case of a hurricane, an entire city. In situations in which all the hosts defined on an authoritative name server are located in the same building as the name server, then loss of DNS will not impact availability of service simply because the computing infrastructure is already down. On the other hand, if all the authoritative name servers for a zone reside in a single building, but hosts defined within the zone are located elsewhere, then the loss of the DNS will impact service. The loss of service occurs because users (and other infrastructure devices and servers) will not be able to resolve host names for servers/services that are otherwise still operational at an unaffected site. Information Assurance Officer
Checks: C-3427r1_chk

By examining the zone file, the reviewer can determine whether there are hosts defined on one of the name server’s zones that reside in more than one building. If they all reside in the same building, then this check does not apply. If the defined hosts reside in different buildings, then one of the evaluated name server’s zone partners (slave or master) must reside in an alternate building. In this case, if all of the authoritative name servers for a zone reside in the same building, then this a finding. *Note: If the the zones records are on one subnet a single nameserver is required.

Fix: F-4349r1_fix

Working with DNS administrators and appropriate technical and facility personnel, the IAO should either arrange for one of the existing name servers to be moved to different location, deploy an additional name server at another location, or arrange to have an existing name server at another location act as slave to the zones hosted at the current location.

a
Private IP space is used within an Enclave without the use of split DNS to prevent private IPs from leaking into the public DNS system.
Low - V-13045 - SV-13613r1_rule
RMF Control
Severity
Low
CCI
Version
DNS0215
Vuln IDs
  • V-13045
Rule IDs
  • SV-13613r1_rule
DNS operators should assume that any data placed in the DNS would be available to anyone connected to the Internet. Split DNS shall not be considered a mitigating factor or technique to deny DNS information to an attacker. Split DNS will continue to be required in one situation only: to prevent address space that is private (e.g., 10.0.0.0/24) or is otherwise concealed by some form of Network Address Translation from leaking into the public DNS system.Information Assurance OfficerECSC-1
Checks: C-3428r1_chk

This check is only applicable if the site is using private IP space within the Enclave. This is typically encountered when a site is using Network Address Translation (NAT) with private or non-routable IPs. BIND This configuration should be evidenced by the use of the view statement in the named.conf file. If it is not, then the DNS administrator must satisfactorily explain how an alternative mechanism achieves the same effect. If the site employs NAT and a split DNS configuration is not employed or a satisfactory alternative mechanism is not employed, then this is a finding. The objective is that an external DNS client should have no means of querying the DNS to obtain a host-to-IP-address mapping for an internal host that has a private or non-routable IP. Windows Review each zone and search for any private IP addresses. If private addresses are being utilized internally and their respective domain names are also capable of being accessed from outside the enclave, then ask the DNS administrator to explain if they are implementing a split DNS configuration. Note: Split DNS can also be referred to as split-horizon and split-brain DNS. The best approach is to maintain separate servers for the external/internal zone records. Most other approaches involve forwarding from the internal server, which is against the STIG guidelines.

Fix: F-4350r1_fix

The IAO will ensure, when using private IP address space within an Enclave, that a split-DNS configuration is implemented to prevent the private address space from leaking into the public DNS system.

a
The DNS database administrator has not documented the owner of each zone (or group of related records) and the date the zone was created, last modified, or verified. This documentation will preferably reside in the zone file itself through comments, but if this is not feasible, the DNS database administrator will maintain a separate database for this purpose.
Low - V-13046 - SV-13614r1_rule
RMF Control
Severity
Low
CCI
Version
DNS0220
Vuln IDs
  • V-13046
Rule IDs
  • SV-13614r1_rule
A zone file should contain adequate documentation that would allow an IAO or newly assigned administrator to quickly learn the scope and structure of that zone. In particular, each record (or related set of records, such as a group of LAN workstations) should be accompanied by a notation of the date the record was created, modified, or validated and record the owner’s name, title, and organizational affiliation. The owner of a record is an individual with the authority to request that the record be modified or deleted. If an organization cannot identify who is responsible for a host record, then there is no assurance that it is valid. If invalid records are in a zone, then an adversary could potentially use their existence for improper purposes. System Administrator
Checks: C-3429r1_chk

BIND DNS zone record documentation will preferably reside in the zone file itself through comments, but if this is not feasible, the DNS database administrator will maintain a separate database for this purpose. The zone file location can be found by examining the named.conf and searching for the zone statement. Within the zone statement will be a file option that will display the name of the zone file. Windows Ask the DNS database administrator if they maintain a separate database with record documentation. Windows DNS does not provide the capability to insert comments for records in a zone. Review the zone files/database. If the records are not fully documented, then this is a finding. The zone record documentation is to include, at a minimum: - The owner of each zone record - The date the zone record was created - The date the zone record was last modified - The date the zone record was last verified Records can be grouped (e.g., a number of workstations residing in the same area or a high-availability server cluster)

Fix: F-4351r1_fix

The DNS database administrator will document, at a minimum, the owner of each zone record (or group of related records) and the date the record was created, last modified, or verified. This documentation will preferably reside in the zone file itself through comments, but if this is not feasible, the DNS database administrator will maintain a separate database for this purpose.

b
The name server software on production name servers is not BIND, Windows 2003 or later DNS, or alternatives with equivalent security functionality and support, configured in a manner to satisfy the general security requirements listed in the STIG.
Medium - V-13047 - SV-13615r1_rule
RMF Control
Severity
Medium
CCI
Version
DNS0400
Vuln IDs
  • V-13047
Rule IDs
  • SV-13615r1_rule
If an organization runs DNS name server software other than BIND, Windows 2003 DNS or later, or an equivalent alternative, such as Infoblox running BIND; it cannot benefit from assurance testing of those implementations of DNS. As a result, there may be unknown vulnerabilities associated with the alternative product for which there are no compensating controls. Moreover, there is no detailed security implementation guidance for other name server implementations, which makes it considerably harder to conduct reviews or self assessments. An incomplete review means that an organization operates at a lower level of assurance than could have been realized with one of the approved products.Information Assurance Officer
Checks: C-3476r1_chk

Review the DNS name server software on the platform to determine what DNS software is running. If the name server is running a DNS implementation other than ISC BIND, Windows 2003 or later DNS, or equivalent DNS dedicated device such as Infoblox, then this is a finding. Cisco CSS DNS is limited to only those hosts defined in the csd.disa.mil domain. CSS DNS is subject both to these general security requirements, where applicable, and the specific STIG guidance for this product.

Fix: F-4356r1_fix

Working with DNS software administrators and other appropriate technical personnel, the IAO should oversee a migration to an approved name server software.

b
Hosts outside an enclave can directly query or request a zone transfer from a name server that resides on the internal network (i.e., not in a DMZ).
Medium - V-13048 - SV-13616r1_rule
RMF Control
Severity
Medium
CCI
Version
DNS0405
Vuln IDs
  • V-13048
Rule IDs
  • SV-13616r1_rule
If external hosts are able to query a name server on the internal network, then there is the potential that an external adversary can obtain information about internal hosts that could assist the adversary in a network attack. External hosts should never be able to learn about the internal network in this manner.Information Assurance Officer
Checks: C-3481r1_chk

Work with the Network administrator to determine whether external hosts are able to query a name server on the internal network. DNS runs on ports 53/TCP for zone transfers and 53/UDP for queries. These ports should be blocked at the firewall or router to internal DNS servers. If external hosts are able to query a name server on the internal network, then this is a finding.

Fix: F-4357r1_fix

Working with appropriate technical personnel, the IAO should establish firewall rules and/or router ACLs that prohibit access to the name server from external hosts.

a
The DNS architecture is not documented to include specific roles for each DNS server, the security controls in place, and what networks are able to query each server.
Low - V-13050 - SV-13618r1_rule
RMF Control
Severity
Low
CCI
Version
DNS0160
Vuln IDs
  • V-13050
Rule IDs
  • SV-13618r1_rule
Without current and accurate documentation, any changes to the network infrastructure may jeopardize the network’s integrity. To assist in the management, auditing, and security of the network, facility drawings and topology maps are a necessity; and those addressing critical network assets, such as the DNS server, are especially important. Topology maps (documentation) are important because they show the overall layout of the network infrastructure and where devices are physically located. They also show the relationship and inter-connectivity between devices and where possible intrusive attacks (wire taps) could take place. Additionally, documentation along with diagrams of the network topology are required to be submitted to the Connection Approval Process (CAP) for approval to connect to the NIPRNet or SIPRNet. Depending on the command, service, or activity, additional approval may be required.Information Assurance Officer
Checks: C-7861r1_chk

Interview the IAO or SA and ask to see the DNS architecture documentation to include roles for each server, security controls, and the list of networks that are able to query the DNS server.

Fix: F-11159r1_fix

Document the DNS architecture to include the location, function, role, and security controls for all DNS servers.

c
The DNS server software is either installed on or enabled on an operating system that is no longer supported by the vendor.
High - V-13051 - SV-13619r1_rule
RMF Control
Severity
High
CCI
Version
DNS0175
Vuln IDs
  • V-13051
Rule IDs
  • SV-13619r1_rule
Information Assurance OfficerVIVM-1
Checks: C-7863r1_chk

Review the Operating System to determine if it is supported by the vendor, e.g. Windows NT is no longer supported.

Fix: F-11161r1_fix

The IAO should develop a migration plan to upgrade or replace any out of date software or any software that is no longer vendor supported.

a
The SA has not subscribed to ISC's mailing list "bind announce" for updates on vulnerabilities and software notifications.
Low - V-13052 - SV-13620r1_rule
RMF Control
Severity
Low
CCI
Version
DNS0190
Vuln IDs
  • V-13052
Rule IDs
  • SV-13620r1_rule
Whether running the latest version or software or an earlier version, the administrator should be aware of the vulnerabilities, exploits, security fixes, and patches for the version that is in operation in the enterprise.System Administrator
Checks: C-8508r1_chk

If the site is using BIND, interview the SA to determine if they have subscribed to ISC’s mailing list called “bind-announce” (information on the Internet at ttp://www.isc.org/sw/bind/bind-lists.php) for vulnerabilities and software notifications.Note: This check only applies to Windows and Unix systems running BIND. It should be marked Not Applicable for those not running BIND. If the site is using BIND, interview the SA to determine if they have subscribed to ISC’s mailing list called “bind-announce” (information on the Internet at http://www.isc.org/sw/bind/bind-lists.php) for vulnerabilities and software notifications.

Fix: F-11675r1_fix

If BIND is utilized, the SA will subscribe to ISC’s mailing list called “bind-announce” (information on the Internet at http://www.isc.org/sw/bind/bind-lists.php) for vulnerabilities and software notifications.

a
The contents of zones are not reviewed at least annually.
Low - V-13053 - SV-13621r1_rule
RMF Control
Severity
Low
CCI
Version
DNS0185
Vuln IDs
  • V-13053
Rule IDs
  • SV-13621r1_rule
DNS administrators must review the contents of their zones at least as often as annually for content or aggregation of content that may provide an adversary information that can potentially compromise operational security. This specifically includes names that provide an outsider some indication as to the function of the referenced system unless the function is obvious in the context of other standard DNS information (e.g., naming a DNS server as dns.zone.mil or an SMTP mail server as mail.zone.mil is not an OPSEC violation given that the functions of these servers are easily identifiable during DNS queries). The DNS administrator is the final adjudicator of the sensitivity of DNS information, in concert with the OPSEC processes of the organization, but should make a conscious decision to include such information based on operational need. NIST guidance includes specific guidelines that HINFO, RP and LOC records not be included in the zone.System Administrator
Checks: C-9298r1_chk

Interview the DNS administrator and ask if there is a procedure in place to review and validate the contents of the zones he/she is responsible for, at least annually.

Fix: F-12295r1_fix

The IAO will ensure the DNS administrator reviews the contents of the zones they are responsible for, at least annually.

b
The underlying operating system of the DNS server is not in compliance with the appropriate OS STIG.
Medium - V-13313 - SV-13885r1_rule
RMF Control
Severity
Medium
CCI
Version
DNS0170
Vuln IDs
  • V-13313
Rule IDs
  • SV-13885r1_rule
A vulnerability in the underlying operating system of a DNS server could potentially impact not only the DNS server but the entire network infrastructure to include the Global Information Grid (GIG). System Administrator
Checks: C-9849r1_chk

Review the Operating System against the appropriate OS STIG. For a Windows system this would mean an evaluation with the Gold Disk; for a UNIX/LINUX system this would mean an evaluation using the SRR scripts. STIG compliance means that all findings are either closed, or there is a POA&M to address any outstanding vulnerabilities.

Fix: F-11160r1_fix

The underlying Operating System of the DNS server must be in compliance with the appropriate OS STIG.

b
A zone or name server does not have a backup administrator.
Medium - V-13314 - SV-13886r1_rule
RMF Control
Severity
Medium
CCI
Version
DNS0125
Vuln IDs
  • V-13314
Rule IDs
  • SV-13886r1_rule
If there is no backup DNS administrator, then there is nobody to assist during a security emergency when the primary administrator is unavailable. In some cases, a backup administrator can also detect problems introduced by the first administrator before these problems are allowed to propagate. Personnel redundancy is as important as technology redundancy for the DNS availability.Information Assurance Officer
Checks: C-9850r1_chk

If the site POC cannot produce a list of backup personnel authorized to administer each zone and name server, then this is a finding. If any zone or name server has only one DNS database administrator or only one DNS software administrator, then this is a finding. If there is not a backup administrator for both roles, then this is a finding.

Fix: F-12566r1_fix

Working with appropriate resource managers, the IAO should identify a backup DNS administrator for each zone and name server under the IAOs scope of responsibility.

c
The name server software on production name servers is not BIND, Windows 2003 or later DNS, or alternatives with equivalent vendor support, configured in a manner to satisfy the general security requirements listed in the STIG. The only currently approved alternative is CISCO CSS DNS.
High - V-14763 - SV-15520r1_rule
RMF Control
Severity
High
CCI
Version
DNS0402
Vuln IDs
  • V-14763
Rule IDs
  • SV-15520r1_rule
If an organization runs DNS name server software other than BIND, Windows 2003 DNS or later, or an equivalent alternative, it cannot benefit from assurance testing of those implementations of DNS. As a result, there may be unknown vulnerabilities associated with the alternative products for which there are no compensating controls. Moreover, there is no detailed security implementation guidance for other name server implementations, which makes it considerably harder to conduct reviews or self assessments. An incomplete review means that an organization operates at a lower level of assurance than could have been realized with one of the approved products. Those products without vendor support can not be maintained at relevant security patch levels to assure the product has no vulnerabilities.Information Assurance Officer
Checks: C-12986r1_chk

Validation of compliance with the requirements is determined via an operating system console. An authorized SA should perform the required actions. He or she will work side-by-side with the reviewer to determine which commands are most appropriate at certain points in the review. UNIX Instruction: In the presence of the reviewer, the SA should enter the following command: named –v or, what /usr/sbin/named | grep named If a version of BIND 9.4-ESV-R4, 9.6.2-P3, 9.6-ESV-R3, or 9.7.2-P3 above is not installed, then this is a finding. If subsequent IAVA guidance recommends a BIND upgrade, then that guidance will supersede this requirement. Windows (with BIND) Instruction: The reviewer must work with the SA to obtain the owner of the named.exe or dns.exe service. In the presence of the reviewer, the SA should right-click on the named.exe or dns.exe service name file and select Properties | Version tab. The version should be displayed in the “Description” field. If a version of BIND prior to BIND 9.4-ESV-R4, 9.6.2-P3, 9.6-ESV-R3, 9.7.2-P3 is running, then this is a finding. If subsequent IAVA guidance recommends a BIND upgrade, then that guidance will supersede this requirement. Windows (Native) Instruction: The reviewer must ensure the operating system is Windows 2003 or later. If it is not, then this is a finding.

Fix: F-14233r1_fix

Working with DNS software administrators and other appropriate technical personnel, the IAO should oversee a migration to an approved name server software version.