BIND DNS STIG

U_BIND_DNS_V4R1-19_Manual-xccdf.xml

Details

Version / Release: V4R1

Published: 2015-10-01

Updated At: 2018-09-23 02:03:42

Download

Filter

Findings
Severity Open Not Reviewed Not Applicable Not a Finding
Overall 0 0 0 0
Low 0 0 0 0
Medium 0 0 0 0
High 0 0 0 0
Drop CKL or SCAP (XCCDF) results here.
    Vuln Rule Version CCI Severity Title Description Status Finding Details Comments
    SV-3617r2_rule DNS4440 LOW BIND is not configured to run as a dedicated non-privileged user account. BIND is running as a root user. If an intruder gains control of named (BIND), the intruder will acquire the privileges of the user ID under which it runs. Running as a non-privileged user account limits the extent of any breach. When BIND runs as root (the default) intruders gain full control of the system.System AdministratorECLP-1
    SV-3618r1_rule DNS4450 MEDIUM A UNIX or UNIX-based name server is running unnecessary daemon/services and/or is configured to start an unnecessary daemon, service, or program upon boot up. Unnecessary software running on a name server could introduce security vulnerabilities that would be avoided if it were not present.DNS4450If SNMP is used for network management it must be documented and configured in accordance with the UNIX STIG. SNMP is not a finding if operationally necessary and documented as such. System AdministratorECSC-1
    SV-3619r1_rule DNS4460 LOW It is possible to obtain a command shell by logging on to the DNS user account. If an intruder gains access to a command shell, the intruder may be able to execute unauthorized commands.System AdministratorECLP-1
    SV-3620r1_rule DNS4470 MEDIUM Permissions on critical UNIX name server files are not as restrictive as required. Weak permissions could allow an intruder to view or modify zone, configuration and/or program files.System AdministratorECCD-1, ECCD-2
    SV-3621r1_rule DNS4530 MEDIUM ISC BIND is not configured to run as a dedicated non-privileged service user account. If an intruder gains control of named (BIND), then the intruder will acquire the privileges of the user ID under which it runs. Running as a non-privileged user account limits the extent of any breach. When BIND runs as SYSTEM (the default) intruders gain full control of the system.System AdministratorECLP-1
    SV-3622r1_rule DNS4540 LOW The ISC BIND service user is a member of a group other than Everyone and Authenticated Users. Membership in configurable groups gives the BIND service user unnecessary privileges that could be used by an intruder to further breach name server security.System AdministratorECLP-1
    SV-3623r1_rule DNS4550 LOW The ISC BIND service does not have the appropriate user rights required for the proper configuration and security of ISC BIND. Having user rights beyond the minimum necessary gives the BIND service user unnecessary privileges that could be used by an intruder to further breach name server security.System AdministratorECLP-1
    SV-3624r1_rule DNS4570 MEDIUM The appropriate encryption software is not correctly installed and configured on Windows ISC BIND name servers and it is required that in-band remote management be performed from hosts outside the enclave in which the name server resides. In administrative network traffic is in the clear between external clients and name servers, then there is significant potential that authorized individuals can intercept and view that traffic, which may contain passwords and other sensitive information.System AdministratorECCT-1, ECCT-2
    SV-3626r1_rule DNS4590 MEDIUM The ownership and permissions on all Windows ISC BIND name servers are not as restrictive as required. Weak permissions could allow an intruder to view or modify zone, configuration and/or program files.System AdministratorECLP-1
    SV-4467r2_rule DNS0225 LOW Record owners will validate their zones no less than annually. The DNS database administrator will remove all zone records that have not been validated in over a year. If zone information has not been validated in over a year, then there is no assurance that it is still valid. If invalid records are in a zone, then an adversary could potentially use their existence for improper purposes. An SOP detailing this process can resolve this requirement. Information Assurance OfficerECSC-1
    SV-4468r3_rule DNS0230 LOW Resource records for a host in a zone file are included and their fully qualified domain name resides in another zone. The exception is a glue record or CNAME record supporting a system migration. If a name server were able to claim authority for a resource record in a domain for which it was not authoritative, this would pose a security risk. In this environment, an adversary could use illicit control of a name server to impact IP address resolution beyond the scope of that name server (i.e., by claiming authority for records outside of that servers zones). Fortunately, all but the oldest versions of BIND and most other DNS implementations do not allow for this behavior. Nevertheless, the best way to eliminate this risk is to eliminate from the zone files any records for hosts in another zone. The two key exceptions to this rule involve glue for NS records and CNAME records for legacy resolution supportSystem AdministratorECSC-1
    SV-4469r3_rule DNS0235 LOW Zone-spanning CNAME records, that point to a zone with lesser security, are active for more than six months. The use of CNAME records for exercises, tests or zone-spanning aliases should be temporary (e.g., to facilitate a migration). When a host name is an alias for a record in another zone, an adversary has two points of attack the zone in which the alias is defined and the zone authoritative for the aliases canonical name. This configuration also reduces the speed of client resolution because it requires a second lookup after obtaining the canonical name. Furthermore, in the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers and thus compounding the vulnerability.System AdministratorECSC-1
    SV-4470r2_rule DNS0240 HIGH The DNS database administrator has not ensured each NS record in a zone file points to an active name server authoritative for the domain specified in that record. Poorly constructed NS records pose a security risk because they create conditions under which an adversary might be able to provide the missing authoritative name services that are improperly specified in the zone file. The adversary could issue bogus responses to queries that clients would accept because they learned of the adversary’s name server from a valid authoritative name server, one that need not be compromised for this attack to be successful. The list of slave servers must remain current within 72 hours of any changes to the zone architecture that would affect the list of slaves. If a slave server has been retired or is not operational but remains on the list, then an adversary might have a greater opportunity to impersonate that slave without detection, rather than if the slave were actually online. For example, the adversary may be able to spoof the retired slave’s IP address without an IP address conflict, which would likely not occur if the true slave were active. System AdministratorECSC-1
    SV-4473r3_rule DNS0415 MEDIUM DNS software does not run on dedicated (running only those services required for DNS) hardware. The only currently accepted exception of this requirement is Windows 2000/2003 DNS, which must run on a domain controller that is integrated with Active Directory services. Even a securely configured operating system is vulnerable to the flaws of the programs that run on it. To prevent DNS software from being subjected to the vulnerabilities of other programs and services, the DNS server will not run other programs and services at all, or at least run only those programs that are necessary for either OS or DNS support.Information Assurance OfficerECSC-1
    SV-4475r2_rule DNS0420 MEDIUM Permissions on files containing DNS encryption keys are inadequate. Weak permissions could allow an intruder to view or modify DNS encryption key files. These keys should never be readable by Other or Everyone.System AdministratorECCD-1, ECCD-2, ECSC-1
    SV-4476r2_rule DNS0425 MEDIUM Users and/or processes other than the DNS software Process ID (PID) and/or the DNS database administrator have edit/write access to the zone database files. Weak permissions on key files could allow an intruder to view or modify DNS zone files. Permissions on these files will be 640 or more restrictive. System AdministratorECCD-1, ECCD-2
    SV-4477r4_rule DNS0430 MEDIUM Users or processes other than the DNS software administrator and the DNS software PID have write access to these files. Weak permissions on key DNS configuration files could allow an intruder to view or modify DNS name server configuration files.System AdministratorECCD-1, ECCD-2
    SV-4478r2_rule DNS0435 MEDIUM The name server’s IP address is NOT statically defined and configured locally on the server. The name server has a DHCP address. Static IP addresses permit a machine to offer Internet services like web, ftp, DNS, and email. Because a specific, known address is associated with your connection, other machines on the Internet know where to send traffic destined for your server. Required ACL restrictions at the router and or firewall are required to protect the DNS server from unauthorized access. Such ACLS require a static IP address to be effective.System AdministratorECSC-1
    SV-4479r2_rule DNS0440 MEDIUM An integrity checking tool is not installed or not monitoring for modifications to the root.hints and named.conf files. An integrity checking tool compares file and directory integrity to the baseline. It can alert the system administrator to unauthorized changes in files or directories. Unauthorized changes in files and directories can give a user unauthorized access to system resources. Undetected changes to DNS name server root hints and configuration files is the single greatest risk to the security and stability of the DNS name server. An integrity checking tool (e.g., Tripwire) aids in effectively monitoring and controlling changes to ensure improved security and system availability. This applies to both authoritative and caching name servers.System AdministratorECSC-1
    SV-4480r2_rule DNS0445 MEDIUM A cryptographic key used to secure DNS transactions has been utilized on a name server for more than one year. Keys are more likely to be compromised if they remain in use for over a year.System AdministratorDCNR-1
    SV-4481r2_rule DNS0450 HIGH Dynamic updates are not cryptographically authenticated. The dynamic update capability has considerable appeal in an environment in which IP addresses change so frequently that it would be unacceptably burdensome or expensive to dedicate the time of a DNS database administrator to this function. This condition would likely be met at sites that rely on the Dynamic Host Configuration Protocol (DHCP) to assign IP addresses to client devices such as workstations, laptops, and IP telephones. It would also apply to sites that utilize frequently changing service (SRV) records. On the other hand, dynamic updates can pose a security risk if the proper security controls are not implemented. When dynamic updates are permitted without any mitigating controls, a host with network access to the name server can modify any zone record with an appropriately crafted dynamic update request. The solution is to require cryptographic authentication of all dynamic update requests, but not all DNS software supports this functionality. System AdministratorDCNR-1
    SV-4482r2_rule DNS0455 HIGH The DNS software administrator will configure each master/slave server supporting a zone to cryptographically authenticate zone transfers. A slave updates its zone information by requesting a zone transfer from its master. In this transaction, the risk for the slave is that the response to its request is not in fact from its authorized master but from an adversary posing as the master. In this scenario, such an adversary would be able to modify and insert records into the slaves zone at will. To protect against this occurrence, the slave must be able to authenticate the master to provide assurance that any zone updates are valid.DNS0455A violation of this requirement can have one of two severity levels depending upon the extent of the violation. If slaves do not authenticate masters in any manner, then the discrepancy would be a Category I finding. If some form of authentication exists (i.e., based on IP address), but it is not based on cryptography, then the discrepancy would be a Category II finding.System AdministratorDCNR-1
    SV-4483r2_rule DNS0460 MEDIUM A zone master server does not limit zone transfers to a list of active slave name servers authoritative for that zone. The risk to the master in this situation, is that it would honor a request from a host that is not an authorized slave, but rather an adversary seeking information about the zone. To protect against this possibility, the master must first have knowledge of what machines are authorized slaves.System AdministratorECAN-1
    SV-4485r2_rule DNS0470 MEDIUM A name server is not configured to only accept notifications of zone changes from a host authoritative for that zone. A slave updates its zone information by requesting a zone transfer from its master. In this transaction, the risk for the slave is that the response to its request is not in fact from its authorized master but from an adversary posing as the master. In this scenario, such an adversary would be able to modify and insert records into the slaves zone at will. To protect against this occurrence, the slave must be able to authenticate the master to provide assurance that any zone updates are valid.System AdministratorECSC-1
    SV-4486r3_rule DNS0475 MEDIUM Recursion is not prohibited on an authoritative name server. A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to non-existent hosts (which constitutes a denial of service) or, worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords. To guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine; one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation.System AdministratorECSC-1
    SV-4487r2_rule DNS0480 MEDIUM A caching name server does not restrict recursive queries to only the IP addresses and IP address ranges of known supported clients. Any host that can query a resolving name server has the potential to poison the servers name cache or take advantage of other vulnerabilities that may be accessed through the query service. The best way to prevent this type of attack is to limit queries to internal hosts, which need to have this service available to them.System AdministratorECSC-1
    SV-4488r3_rule DNS0485 HIGH The DNS software must log success and failure events when starting and stopping of the name server service daemon, zone transfers, zone update notifications, and dynamic updates. Logging must be comprehensive to be useful for both intrusion monitoring and security investigations. Setting logging at the severity notice should capture most relevant events without requiring unacceptable levels of data storage. The severity levels info and debug are also available to organizations that require additional logging for certain events or applications.DNS0485A violation of this requirement can have one of two severity levels depending upon the extent of the violation. If no logging exists, then the discrepancy would be a Category I finding. If some logging exists, but not for all of the events listed, then the discrepancy would be a Category II finding.System AdministratorECAT-1, ECAT-2
    SV-4489r2_rule DNS0490 MEDIUM The DNS software administrator has not configured the DNS software to send all log data to either the system logging facility (e.g., UNIX syslog or Windows Application Event Log) or an alternative logging facility with security configuration equivalent to or more restrictive than the system logging facility. On name servers, DNS log data is typically more sensitive than system log data and, consequently, should benefit from security controls at least as restrictive as those for the system logging facility. DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. These logs should be appropriately secured, having file permissions that restrict unauthorized changes or viewing, and archived, being appropriately backed-up and stored in order for them to be examined at a future time. Furthermore, it is required that the logs be reviewed daily.System AdministratorCOBR-1
    SV-4490r2_rule DNS0495 LOW Entries in the name server logs do not contain timestamps and severity information. Forensic analysis of security incidents and day-to-day monitoring are substantially more difficult if there are no timestamps on log entries.System AdministratorECAR-1, ECAR-2, ECAR-3, ECSC-1
    SV-4492r2_rule DNS0505 LOW The DNS software administrator has not removed the root hints file on an authoritative name server in order for it to resolve only those records for which it is authoritative, and ensure that all other queries are refused. A potential vulnerability of DNS is that an attacker can poison a name servers 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. The DNS architecture needs to maintain one name server whose zone records are correct and the cache is not poisoned, in this effort the authoritative name server may not forward queries, one of the ways to prevent this, the root hints file is to be deleted. When authoritative servers are sent queries for zones that they are not authoritative for, and they are configured as a non-caching server (as recommended), they can either be configured to return a referral to the root servers or they can be configured to refuse to answer the query. The requirement is to configure authoritative servers to refuse to answer queries for any zones for which they are not authoritative. This is more efficient for the server, and allows it to spend more of its resources doing what its intended purpose is; answering authoritatively for its zone.System AdministratorECSC-1
    SV-4493r2_rule DNS0705 LOW The DNS software administrator has not utilized at least 160 bit HMAC-SHA1 keys if available. SHA-1 is the algorithm currently specified in the National Institute of Standards and Technology's (NISTs) Secure Hashing Standard (FIPS 180-1) and required throughout DoD. HMAC-MD5 will be replaced with HMAC-SHA1 or higher when available for DNS TSIG applications. In general, only NIST or National Security Agency (NSA) approved algorithms should be utilized in the DoD computing infrastructure. The US Government currently requires SHA-1 for hashing applications. It is considered an improvement over MD5, for which there are known instances of collisions.System AdministratorDCNR-1
    SV-4494r2_rule DNS0710 MEDIUM A TSIG key is not in its own dedicated file. Ideally, nobody even DNS and Systems Administrators should view the key. If it is included in named.conf, they will view it on a regular basis, which means computer forensics is less likely to determine who may have obtained the key if it is compromised. In addition, if the named.conf needs to be copied from the system for whatever reason (e.g., sent to an expert to troubleshoot a problem, appended to a change management work order, etc.), then others will see the key and could copy it. On the other hand, if the key is in a dedicated file, then the operating system can be configured to log any instance when the key is accessed, which would make it easy for security personnel to determine when users other than the DNS name server software performed this function.System AdministratorECCD-1, ECCD-2
    SV-4495r2_rule DNS0720 MEDIUM A unique TSIG key is not utilized for communication between name servers sharing zone information. If a secret key shared between two servers is not unique, then any breach of the key is not limited to those two servers. In particular, if all servers in a zone share the same key, then there is the possibility that an attack could modify records all of the servers. Recovering from a successful attack is considerably more difficult in this circumstance. Furthermore, the more copies of any one key are in existence, the greater the likelihood that the confidentiality of that key will be lost at some point in time.System AdministratorDCNR-1
    SV-4511r2_rule DNS0715 MEDIUM A BIND name server is not configured to accept control messages only when the control messages are cryptographically authenticated and sent from an explicitly defined list of DNS administrator workstations. The controls statement and the associated use of the rndc or ndc commands introduces the risk that an adversary could use them to remotely control the name server without having to authenticate to the operating system on which the name server resides.System AdministratorDCNR-1
    SV-12999r2_rule DNS0250 LOW A unique TSIG key is not generated and utilized for each type of transaction. 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.System AdministratorDCNR-1
    SV-13339r3_rule DNS0482 MEDIUM The forwarding configuration of DNS servers must prohibit the forwarding of queries to servers controlled by organizations outside of the U.S. Government. If remote servers to which DoD DNS servers send queries are controlled by entities outside of the U.S. Government the possibility of a DNS attack is increased. The Enterprise Recursive Service (ERS) provides the ability to apply enterprise-wide policy to all recursive DNS traffic that traverses the NIPRNet-to-Internet boundary. All recursive DNS servers on the NIPRNet must be configured to exclusively forward DNS traffic traversing NIPRNet-to-Internet boundary to the ERS anycast IPs. Organizations need to carefully configure any forwarding that is being used by their caching name servers. They should only configure "forwarding of all queries" to servers within the DoD. Systems configured to use domain-based forwarding should not forward queries for mission critical domains to any servers that are not under the control of the US Government.System AdministratorECSC-1
    SV-13534r3_rule DNS4480 MEDIUM Inadequate file permissions on BIND name servers. Weak permissions could allow an intruder to view or modify zone, configuration and/or program files.System AdministratorECCD-1, ECCD-2
    SV-13535r2_rule DNS4445 LOW The SA has not configured BIND in a chroot(ed) directory structure. With any network service, there is the potential that an attacker can exploit a vulnerability within the program that allows the attacker to gain control of the process and even run system commands with that control. One possible defense against this attack is to limit the software to particular quarantined areas of the file system, memory or both. This effectively restricts the service so that it will not have access to the full file system. If such a defense were in place, then even if an attacker gained control of the process, the attacker would be unable to reach other commands or files on the system. This approach often is referred to as a padded cell, jail, or sandbox. All of these terms allude to the fact that the software is contained in an area where it cannot harm either itself or others. A more technical term is a chroot(ed) directory structure. BIND should be configured to run in a padded cell or chroot(ed) directory structure if supported by the operating system System AdministratorECLP-1
    SV-15513r1_rule DNS4600 LOW The DNS administrator will ensure non-routeable IPv6 link-local scope addresses are not configured in any zone. Such addresses begin with the prefixes of “FE8”, “FE9”, “FEA”, or “FEB”. IPv6 link local scope addresses are not globally routable and must not be configured in any DNS zone. Similar to RFC1918, addresses, if a link-local scope address is inserted into a zone provided to clients, most routers will not forward this traffic beyond the local subnet.System AdministratorOtherECSC-1
    SV-15514r1_rule DNS4610 LOW AAAA addresses are configured on a host that is not IPv6 aware. DNS is only responsible for resolving a domain name to an ip address. Applications and operating systems are responsible for processing the IPv6 or IPv4 record that may be returned. With this in mind, a denial of service could easily be implemented for an application that is not IPv6 aware. When the application receives an i.p. address in hexadecimal, it is up to the application/operating system to decide how to handle the response. Combining both IPv6 and IPv4 records into the same domain can lead to application problems that are beyond the scope of the DNS administrator.OtherECSC-1
    SV-15515r1_rule DNS4620 MEDIUM The DNS software administrator will ensure the named.conf options statement does not include the option "listen-on-v6 { any; };” when an IPv6 interface is not configured and enabled. To prevent the possibility of a denial of service in relation to an IPv4 DNS server trying to respond to an IPv6 request, the server should be configured not to listen on any of its IPv6 interfaces unless it does contain IPv6 AAAA resource records in one of the zones.OtherECSC-1
    SV-15516r2_rule DNS4640 LOW The DNS administrator, when implementing DNSSEC, will create and maintain separate key-pairs for key signing and zone signing. DNSSEC specifies generation and verification of digital signatures using asymmetric keys. This requires generation of a public key-private key pair. Although the DNSSEC specification does not call for different keys (just one key pair), experience from pilot implementations suggests that for easier routine security administration operations such as key rollover (changing of keys) and zone re-signing, at least two different types of keys are needed.System AdministratorOtherECSC-1
    SV-15517r3_rule DNS4650 LOW The DNSSEC algorithm for digital signatures must be RSASHA1, RSASHA256, or RSASHA512. MD5 is not collision resistant; therefore, RSAMD5 is not permitted for use in DNSSEC. RSASHA1 is the minimum algorithm for zone signatures. SHA2-based algorithms RSASHA256 and RSASHA512 offer greater security and are preferred over RSASHA1.System AdministratorOtherECSC-1
    SV-15518r2_rule DNS4660 LOW The DNSSEC key signing key is not at least 2048 bits. The choice of key size is a tradeoff between the risk of key compromise and performance. The performance variables are signature generation and verification times. The size of the DNS response packet also is a factor because DNSKEY RRs may be sent in the additional section of the DNS response. Because the KSK is used only for signing the key set (DNSKEY RRSet), performance is not much of an issue. Compromise of a KSK could have a great impact, however, because the KSK is the entry point key for a zone. Rollover of a KSK in the event of a compromise involves potential update of trust anchors in many validating resolvers. Hence, a large key size is recommended for the KSK. A large key size decreases the chances of the key compromise and avoids the need for frequent rollovers as each rollover requires administrative monitoring and follow-up action.System AdministratorOtherECSC-1
    SV-15519r2_rule DNS4670 LOW The DNSSEC key signing key does not have a minimum roll over period of one year. A good practice is to generate an extra set of key signing keys for rollover purposes. The additional key will be readily available for emergency situations such as key compromise. The key signing key should be rolled over on an annual basis.System AdministratorOtherECSC-1
    SV-15521r2_rule DNS4680 LOW The DNSSEC zone signing key size is not at least 1024 bits. As far as the choice of key size for the ZSK is concerned, performance certainly will be a factor because the ZSK is used for signing all RRsets in the zone. In terms of impact, however, it is restricted to just a single zone because the ZSKs usage is limited to signing RRsets only for that zone but not for providing authenticated delegation for a child zone. Hence, a key size smaller than that for the KSK can be used for the ZSK. System AdministratorOtherECSC-1
    SV-15522r2_rule DNS4690 LOW The DNSSEC zone signing key minimum roll over period is not at least 60 days. In the case of ZSK, the risk of key guessing is higher because of larger key exposure. The larger key exposure is a result of the fact that the number of signature sets generated is very large (because the ZSK signs all RRsets in a zone and other RRsets change much more frequently than DNSKEY RRsets, so the number of fresh signatures generated is high). This factor, combined with the relatively smaller size of the key, implies that ZSKs must be rolled over more frequently than KSKs (usually a month or two).System AdministratorECSC-1
    SV-15523r2_rule DNS4700 HIGH The DNSSEC private key file is not owned by the DNS administrator or the permissions are not set to a minimum of 600. The private keys in the KSK and ZSK key pairs should be protected from unauthorized access. If possible, the private keys should be stored offline (with respect to the DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. The signatures generated by using the private keys should be transferred to the primary authoritative name servers through a load process, using a dynamically established network connection (rather than a permanent network link).System AdministratorECSC-1
    SV-15524r3_rule DNS4710 MEDIUM DNSSEC is not enabled for signing files between names servers with DNSSEC capabilities. A powerful feature of DNSSEC is the ability to sign record sets to ensure their integrity and authenticity throughout the DNS infrastructure and not just between the authoritative name server and its zone partner or local client. The advantages of this feature become apparent when DoD users wish to securely validate records from other organizations, including commercial vendors, business partners, and other Government agencies.System AdministratorECSC-1
    SV-30737r1_rule DNS4730 MEDIUM All DNS caching resolvers (A/K/A “recursive name servers”) will have port and Query ID randomization enabled for all DNS querypackets/frames. DNS queries are normally conducted over UDP for performance reasons, although the protocol will fall back to TCP in certain cases. Unfortunately, the lack of a true bi-directional connection in UDP greatly simplifies certain attacks that involve forged packets. While the connectionless UDP is in use, DNS servers will typically treat the first DNS response that matches certain characteristics of the outgoing query as the true response, and act upon the information provided. The relevant characteristics for a valid or forged response are the query source port (usually an “ephemeral” port above 1024), the responding IP address, the DNS transaction ID, and the Question section of the outgoing query. In the DNS protocol specification, none of these are required to have a great degree of randomness or unpredictability which makes certain attacks possible. Eugene Kashpureff demonstrated a fairly simple but effective attack in 1997, which led to software improvements that included verification that information included in the response was in fact something for which the responding server should be trusted (referred to as “in bailiwick”). Because this issue is fundamental to the DNS protocol over UDP, the IETF has devised the DNS Security Extensions (DNSSEC) and Transaction Authentication (TSIG) as protocol extensions to provide methods for cryptographic validation of data. TSIG has been widely adopted and has been a DNS STIG requirement for several years, but DNSSEC has only recently become sufficiently mature and supported to be suitable for operational deployment. Until DNSSEC is fully deployed, attacks on DNS-over-UDP, including cache poisoning attacks, will continue to be effective. System AdministratorECSC-1
    SV-50954r1_rule DNS4715 MEDIUM DNSSEC is not enabled for verifying signed files between names servers with DNSSEC capabilities. A powerful feature of DNSSEC is the ability to sign record sets to ensure their integrity and authenticity throughout the DNS infrastructure and not just between the authoritative name server and its zone partner or local client. The advantages of this feature become apparent when DoD users wish to securely validate records from other organizations, including commercial vendors, business partners, and other Government agencies.System AdministratorECSC-1