DNS Policy

24procedures

Search filters the loaded procedure list locally. Separate terms must all match (use quotes for an exact phrase). Cached STIG Search results apply when you arrive from Search.

Severity
CurrentPublished Fri Apr 27 2018
Objective ID
Severity
Discussion
V-13032
medium
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.
V-13034
medium
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.
V-13035
medium
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.
V-13036
low
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.
V-13037
low
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.
V-13038
medium
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.
V-13039
medium
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.
V-13040
medium
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.
V-13041
medium
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.
V-13042
high
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.
V-13043
high
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.
V-13044
medium
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.

V-13045
low
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.
V-13046
low
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.
V-13047
medium
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.
V-13048
medium
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.
V-13050
low
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.
V-13051
high
V-13052
low
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.
V-13053
low
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.
V-13313
medium
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).
V-13314
medium
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.
V-14763
high
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.
V-4027
medium
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.