{"stig":{"title":"BIND 9.x Security Technical Implementation Guide","version":"3","release":"2"},"checks":[{"vulnId":"V-272364","ruleId":"SV-272364r1124029_rule","severity":"medium","ruleTitle":"A BIND 9.x primary name server must limit the number of concurrent zone transfers between authorized secondary name servers.","description":"Limiting the number of concurrent sessions reduces the risk of denial of service (DoS) to the DNS implementation. \n\nName servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed DoS, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.\n\nPrimary name servers also make outbound connection to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to only be made to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the primary zone server and result in DoS to legitimate users. Primary name servers should be configured to limit the hosts from which they will accept dynamic updates.\n\nAdditionally, the number of concurrent clients, especially TCP clients, needs to be kept to a level that does not risk placing the system in a DoS state.","checkContent":"If this is not a primary name server, this requirement is not applicable.\n\nVerify that the name server is configured to limit the number of zone transfers from authorized secondary name servers.\n\nInspect the \"named.conf\" file for the following:\n\nserver {\ntransfers 2;\n};\n\nIf each \"server\" statement does not contain a \"transfers\" sub-statement, this is a finding.\n\nIf the transfers value is greater than three, this is a finding.","fixText":"Edit the \"named.conf\" file. \n\nAdd the \"transfers\" sub-statement to each \"server\" statement block.\n\nThe value of the \"transfers\" option can be increased to a value no greater than three based on organizational requirements needed to support DNS operations.\n\nRestart the BIND 9.x process.","ccis":["CCI-000054"]},{"vulnId":"V-272365","ruleId":"SV-272365r1124031_rule","severity":"medium","ruleTitle":"The BIND 9.x secondary name server must limit the number of zones requested from a single primary name server.","description":"Limiting the number of concurrent sessions reduces the risk of denial of service (DoS) to the DNS implementation. \n\nName servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed DoS, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.\n\nPrimary name servers also make outbound connection to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to only be made to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the primary zone server and result in DoS to legitimate users. Primary name servers should be configured to limit the hosts from which they will accept dynamic updates.\n\nAdditionally, the number of concurrent clients, especially TCP clients, needs to be kept to a level that does not risk placing the system in a DoS state.","checkContent":"If this is not a secondary name server, this requirement is not applicable.\n\nVerify that the secondary name server is configured to limit the number of zones requested from a single primary name server.\n\nInspect the \"named.conf\" file for the following:\n\noptions {\ntransfers-per-ns 2;\n};\n\nIf the \"options\" statement does not contain a \"transfers-per-ns\" sub-statement, this is a finding.\n\nIf the transfers-per-ns value is greater than three, this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nAdd the \"transfers-per-ns\" sub-statement to the \"options\" statement block.\n\nThe value of the \"transfers-per-ns\" option can be increased to a value no greater than three based on organizational requirements needed to support DNS operations.\n\nRestart the BIND 9.x process.","ccis":["CCI-000054"]},{"vulnId":"V-272366","ruleId":"SV-272366r1124033_rule","severity":"medium","ruleTitle":"The BIND 9.x secondary name server must limit the total number of zones the name server can request at any one time.","description":"Limiting the number of concurrent sessions reduces the risk of denial of service (DoS) to the DNS implementation. \n\nName servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.\n\nPrimary name servers also make outbound connection to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to only be made to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the Primary zone server and result in DoS to legitimate users. Primary name servers should be configured to limit the hosts from which they will accept dynamic updates.\n\nAdditionally, the number of concurrent clients, especially TCP clients, needs to be kept to a level that does not risk placing the system in a DoS state.","checkContent":"If this is not a secondary name server, this requirement is not applicable.\n\nVerify the name server is configured to limit the total number of zones that can be requested at one time.\n\nInspect the \"named.conf\" file for the following:\n\noptions {\ntransfers-in 10;\n};\n\nIf the \"options\" statement does not contain a \"transfers-in\" sub-statement, this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nAdd the \"transfers-in\" sub-statement to the \"options\" statement block.\n\nThe value of the \"transfers-in\" will be based on organizational requirements needed to support DNS operations.\n\nRestart the BIND 9.x process.","ccis":["CCI-000054"]},{"vulnId":"V-272367","ruleId":"SV-272367r1123978_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must limit the number of concurrent session client connections.","description":"Limiting the number of concurrent sessions reduces the risk of denial of service (DoS) to the DNS implementation. \n\nName servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.\n\nPrimary name servers also make outbound connections to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to only be made to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the primary zone server and result in DoS to legitimate users. Primary name servers should be configured to limit the hosts from which they will accept dynamic updates.\n\nAdditionally the number of concurrent clients, especially TCP clients, needs to be kept to a level that does not risk placing the system in a DoS state.","checkContent":"Verify the name server is configured to limit the number of concurrent client connections:\n\nInspect the \"named.conf\" file for the following:\n\noptions {\ntransfers-out 10;\n};\n\nIf the \"options\" statement does not contain a \"transfers-out\" sub-statement, this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nAdd the \"transfers-out\" sub-statement to the \"options\" statement block.\n\nThe value of the \"transfers-out\" will be based on organizational requirements needed to support DNS operations.\n\nRestart the BIND 9.x process.","ccis":["CCI-000054"]},{"vulnId":"V-272368","ruleId":"SV-272368r1123822_rule","severity":"medium","ruleTitle":"The print-severity variable for the configuration of BIND 9.x server logs must be configured to produce audit records containing information to establish what type of events occurred.","description":"Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered, to compile an accurate risk assessment. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS implementation. Without log records that aid in the establishment of what types of events occurred and when those events occurred, there is no traceability for forensic or analytical purposes, and the cause of events is severely hindered.","checkContent":"For each logging channel that is defined, verify that the \"print-severity\" substatement is listed.\n\nInspect the \"named.conf\" file for the following:\n\nlogging {\nchannel channel_name {\nprint-severity yes;\n};\n};\n\nIf the \"print-severity\" statement is missing, this is a finding.\n\nIf the \"print-severity\" statement is not set to \"yes\", this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nAdd the \"print-severity\" substatement to the \"channel\" statement.\n\nConfigure the \"print-severity\" sub statement to \"yes\".\n\nRestart the BIND 9.x process.","ccis":["CCI-000130"]},{"vulnId":"V-272369","ruleId":"SV-272369r1123825_rule","severity":"medium","ruleTitle":"The print-time variable for the configuration of BIND 9.x server logs must be configured to establish when (date and time) the events occurred.","description":"Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident.\n\nAssociating event types with detected events in the application and audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. To compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know when events occurred (date and time).","checkContent":"For each logging channel that is defined, verify that the \"print-time\" substatement is listed.\n\nInspect the \"named.conf\" file for the following:\n\nlogging {\nchannel channel_name {\nprint-time yes;\n};\n};\n\nIf the \"print-time\" statement is missing, this is a finding.\n\nIf the \"print-time\" statement is not set to \"yes\", this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nAdd the \"print-time\" substatement to the \"channel\" statement.\n\nConfigure the \"print-time\" sub statement to \"yes\".\n\nRestart the BIND 9.x process.","ccis":["CCI-000131"]},{"vulnId":"V-272370","ruleId":"SV-272370r1123423_rule","severity":"medium","ruleTitle":"The print-category variable for the configuration of BIND 9.x server logs must be configured to record information indicating which process generated the events.","description":"Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident. Associating information about where the event occurred within the application provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. To compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know where events occurred, such as application components, modules, session identifiers, filenames, host names, and functionality.","checkContent":"For each logging channel that is defined, verify that the \"print-category\" sub statement is listed.\n\nInspect the \"named.conf\" file for the following:\n\nlogging {\nchannel channel_name {\nprint-category yes;\n};\n};\n\nIf the \"print-category\" statement is missing, this is a finding.\n\nIf the \"print-category\" statement is not set to \"yes\", this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nAdd the \"print-category\" sub statement to the \"channel\" statement.\n\nConfigure the \"print-category\" sub statement to \"yes\".\n\nRestart the BIND 9.x process.","ccis":["CCI-000132"]},{"vulnId":"V-272371","ruleId":"SV-272371r1156965_rule","severity":"medium","ruleTitle":"A BIND 9.x server implementation must be configured to allow DNS administrators to audit all DNS server components based on selectable event criteria and produce audit records within all DNS server components that contain information for failed security verification tests, information to establish the outcome and source of the events, any information necessary to determine cause of failure, and any information necessary to return to operations with least disruption to mission processes.","description":"Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server.\n\nThe list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. \n\nThe DOD has defined the list of events for which the application will provide an audit record generation capability as the following: \n\n(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n(ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and\n\n(iii) All account creation, modification, disabling, and termination actions.\n\nThe DOD has defined the data which the application will provide an audit record generation capability for an event as the following: \n\n(i) Establish the source of the event;\n\n(ii) The outcome of the event; and\n\n(iii) Identify the application itself as the source of the event.\n\nWithout establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. Associating information about the source of the event within the application provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. \n\nWithout information about the outcome of events, security personnel cannot make an accurate assessment about whether an attack was successful or if changes were made to the security state of the system.\n\nEvent outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.\n\nFailure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving application state information helps to facilitate application restart and return to the operational mode of the organization with less disruption to mission-essential processes.\n\nThe DNS server should be configured to generate audit records whenever a self-test fails. The OS/NDM is responsible for generating notification messages related to this audit record.\n\nIf authorized individuals do not have the ability to modify auditing parameters in response to a changing threat environment, the organization may not be able to effectively respond, and important forensic information may be lost.\n\nThis requirement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours.\n\nIn addition to logging where events occur within the application, the application must also produce audit records that identify the application itself as the source of the event. To compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know the source of the event, particularly in the case of centralized logging. In the case of centralized logging, the source would be the application name accompanied by the host or client name.\n\nSatisfies: SRG-APP-000089-DNS-000004, SRG-APP-000098-DNS-000009, SRG-APP-000099-DNS-000010, SRG-APP-000275-DNS-000040, SRG-APP-000226-DNS-000032","checkContent":"Verify the name server is configured to generate audit records:\n\nInspect the \"named.conf\" file for the following:\n\nlogging {\nchannel channel_name {\nseverity info;\nprint-time yes;\nprint-category yes;\nprint-severity yes;\n};\ncategory default { channel_name; };\n};\n\nIf there is no \"logging\" statement, this is a finding.\n\nIf the \"logging\" statement does not contain a \"channel\", this is a finding.\n\nIf the \"logging\" statement does not contain a \"category\" that uses a \"channel\", this is a finding.","fixText":"Configure the logging statement in the \"named.conf\" file: \n\nlogging {\nchannel {\nfile \"\";\nseverity info;\nprint-time yes;\nprint-category yes;\nprint-severity yes;\n};\ncategory default { ; };\n};\n\nReplace and with names that distinctively identify the purpose of the channel and the log file.\n\nRestart the BIND 9.x process.","ccis":["CCI-000169","CCI-000133","CCI-000134","CCI-001294","CCI-001665"]},{"vulnId":"V-272372","ruleId":"SV-272372r1123853_rule","severity":"medium","ruleTitle":"The BIND 9.x server private key corresponding to the zone-signing key (ZSK) pair must be the only DNSSEC key kept on a name server that supports dynamic updates.","description":"The private key in the ZSK key pair must be protected from unauthorized access. If possible, the private key should be stored offline (with respect to the internet-facing, DNSSEC-aware name server) in a physically secure, nonnetwork-accessible machine along with the zone file primary copy. \n\nThis strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file primary copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets.\n\nFailure to protect the private ZSK opens it to being maliciously obtained and opens the DNS zone to being populated with invalid data. The integrity of the DNS zone would be compromised, leading to a loss of trust whether a DNS response has originated from an authentic source, the response is complete and has not been tampered with during transit.","checkContent":"Verify that the ZSK private key is the only key stored on the name server.\n\nFor each signed zone file, identify the ZSK \"key id\" number:\n\n# cat | grep -i \"zsk\"\nZSK; alg = ECDSAP256SHA256; key id = 22335\n\nUsing the ZSK \"key id\", verify that the only private key stored on the system matches the \"key id\".\n\nKexample.com.+008+22335.private\n\nIf any ZSK private keys exist on the server other than the one corresponding to the active ZSK pair, this is a finding.","fixText":"Remove any ZSK private keys existing on the server other than the one corresponding to the active ZSK pair.","ccis":["CCI-000186"]},{"vulnId":"V-272373","ruleId":"SV-272373r1192864_rule","severity":"medium","ruleTitle":"The BIND 9.x server signature generation using the key signing key (KSK) must be done offline, using the KSK-private key stored offline.","description":"The private key in the KSK key pair must be protected from unauthorized access. The private key must be stored offline (with respect to the internet-facing, DNSSEC-aware name server) in a physically secure, nonnetwork-accessible machine along with the zone file primary copy. \n\nFailure to protect the private KSK may have significant effects on the overall security of the DNS infrastructure. A compromised KSK could lead to an inability to detect unauthorized DNS zone data resulting in network traffic being redirected to a rogue site.","checkContent":"Verify that no private KSKs are stored on the name server. \n\nWith the assistance of the DNS administrator, obtain a list of all DNSSEC private keys that are stored on the name server. \n\nInspect the signed zone files(s) and if there are local zones, look for the KSK key ID:\n\nDNSKEY 257 3 8 ( \n-rw-r-----. 1 root named 76 May 10 20:35 tsig-example.key\n\nIf the key files are more permissive than 640, this is a finding.","fixText":"Change the permissions of the TSIG key files:\n\n# chmod 640 ","ccis":["CCI-000186"]},{"vulnId":"V-272376","ruleId":"SV-272376r1156963_rule","severity":"medium","ruleTitle":"A unique TSIG key used by a BIND 9.x server must be generated for each pair of communicating hosts.","description":"To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64 encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.\n\nThe process of authenticating the source of a message and its integrity through hash-based message authentication codes (HMAC) is specified through a set of DNS specifications known collectively as TSIG. The sender of the message uses the HMAC function to generate a MAC and sends this MAC along with the message to the receiver. The receiver, who shares the same secret key, uses the key and HMAC function used by the sender to compute the MAC on the received message. The receiver then compares the computed MAC with the received MAC; if the two values match, it provides assurance that the message has been received correctly and that the sender belongs to the community of users sharing the same secret key. Thus, message source authentication and integrity verification are performed in a single process. To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64 encoded. TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.","checkContent":"Verify that the BIND 9.x server is configured to use separate TSIG key-pairs when securing server-to-server transactions.\n\nInspect the \"named.conf\" file for the presence of TSIG key statements:\n\nOn the primary name server, this is an example of a configured key statement:\n\nkey tsig_example. {\nalgorithm hmac-SHA256;\ninclude \"tsig-example.key\";\n};\n\nzone \"disa.mil\" {\ntype Primary;\nfile \"db.disa.mil\";\nallow-transfer { key tsig_example.; };\n};\n\nOn the secondary name server, this is an example of a configured key statement:\n\nkey tsig_example. {\nalgorithm hmac-SHA256;\ninclude \"tsig-example.key\";\n};\n\nserver {\nkeys { tsig_example };\n};\n\nzone \"disa.mil\" {\ntype Secondary;\nPrimarys { ; };\nfile \"db.disa.mil\";\n};\n\nVerify that each TSIG key-pair listed is only used by a single key statement:\n\n# cat \n\nIf any TSIG key-pair is being used by more than one key statement, this is a finding.","fixText":"Create a separate TSIG key-pair for each key statement listed in the named.conf file.\n\nConfigure the name server to use separate TSIG key-pairs for each key statement listed in the named.conf file.\n\nRestart the BIND 9.x process.","ccis":["CCI-000186"]},{"vulnId":"V-272377","ruleId":"SV-272377r1123862_rule","severity":"medium","ruleTitle":"The TSIG keys used with the BIND 9.x implementation must be owned by a privileged account.","description":"Incorrect ownership of a TSIG key file could allow an adversary to modify the file, thus defeating the security objective.","checkContent":"With the assistance of the DNS administrator, identify all of the TSIG keys used by the BIND 9.x implementation.\n\nIdentify the account that the \"named\" process is running as:\n\n# ps -ef | grep named\nnamed 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot\n\nWith the assistance of the DNS administrator, determine the location of the TSIG keys used by the BIND 9.x implementation.\n\n# ls -al \n-rw-r-----. 1 root named 76 May 10 20:35 tsig-example.key\n\nIf any of the TSIG keys are not owned by the above account, this is a finding.","fixText":"Change the ownership of the TSIG keys to the named process it is running as.\n\n# chown .","ccis":["CCI-000186"]},{"vulnId":"V-272378","ruleId":"SV-272378r1123864_rule","severity":"medium","ruleTitle":"The TSIG keys used with the BIND 9.x implementation must be group owned by a privileged account.","description":"Incorrect ownership of a TSIG key file could allow an adversary to modify the file, thus defeating the security objective.","checkContent":"With the assistance of the DNS administrator, identify all of the TSIG keys used by the BIND 9.x implementation.\n\nIdentify the account that the \"named\" process is running as:\n\n# ps -ef | grep named\nnamed 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot\n\nWith the assistance of the DNS administrator, determine the location of the TSIG keys used by the BIND 9.x implementation.\n\n# ls -al \n-rw-r-----. 1 root named 76 May 10 20:35 tsig-example.key\n\nIf any of the TSIG keys are not group owned by the above account, this is a finding.","fixText":"Change the group ownership of the TSIG keys to the named process group.\n\n# chgrp ","ccis":["CCI-000186"]},{"vulnId":"V-272379","ruleId":"SV-272379r1124035_rule","severity":"medium","ruleTitle":"On a BIND 9.x server, for zones split between the external and internal sides of a network, the RRs for the external hosts must be separate from the RRs for the internal hosts.","description":"Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients. \n\nExternal clients need to receive RRs that pertain only to public services (public web server, mail server, etc.).\n\nInternal clients need to receive RRs pertaining to public services as well as internal hosts. \n\nThe zone information that serves the RRs on both the inside and outside of a firewall must be split into different physical files for these two types of clients (one file for external clients and one file for internal clients).","checkContent":"If the BIND 9.x name server is not configured for split DNS, this is not applicable.\n\nVerify that the BIND 9.x server is configured to use separate views and address space for internal and external DNS operations when operating in a split configuration.\n\nInspect the \"named.conf\" file for the following:\n\nview \"internal\" {\nmatch-clients { | };\nzone \"example.com\" {\ntype Primary;\nfile \"internals.example.com\";\n};\n};\nview \"external\" {\nmatch-clients { | };\nzone \"example.com\" {\ntype Primary;\nfile \"externals.db.example.com\";\nallow-transfer { Secondarys; };\n};\n};\n\nIf the internal and external view statements are configured to use the same zone file, this is a finding.\n\nInspect the zone file defined in the internal and external view statements.\n\nIf any resource record is listed in both the internal and external zone files, this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nConfigure the internal and external view statements to use separate zone files.\n\nEdit the internal and external zone files.\n\nConfigure the zone file to use RRs designated for internal or external use. The zone files must not share any RR.","ccis":["CCI-000366"]},{"vulnId":"V-272380","ruleId":"SV-272380r1124037_rule","severity":"medium","ruleTitle":"On a BIND 9.x server in a split DNS configuration, where separate name servers are used between the external and internal networks, the internal name server must be configured to not be reachable from outside resolvers.","description":"Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. \n\nOne set, called external name servers, can be located within a DMZ. These would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (web servers that serve external web pages or provide B2C services, mail servers, etc.).\n\nThe other set, called internal name servers, must be located within the firewall. They must be configured so they are not reachable from outside and therefore provide naming services exclusively to internal clients.","checkContent":"If the BIND 9.x name server is not configured for split DNS, this is not applicable.\n\nVerify that the BIND 9.x server is configured to use the \"match-clients\" sub-statement to limit the reach of the internal view from the external view.\n\nInspect the \"named.conf\" file for the following:\n\nview \"internal\" {\nmatch-clients { | ; };\n};\n\nIf the \"match-clients\" sub-statement is missing for the internal view, this is a finding.\n\nIf the \"match-clients\" sub-statement for the internal view does not limit the view to authorized hosts, this is a finding.\n\nIf any of the IP addresses defined for the \"match-clients\" sub-statement in the internal view are assigned to external hosts, this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nConfigure the internal view statement to limit use authorized internal hosts:\n\nview \"internal\" {\nmatch-clients { | ; };\n};\n\nRemove any IP address that is assigned to an external host from the internal view statement.\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272381","ruleId":"SV-272381r1124039_rule","severity":"medium","ruleTitle":"On a BIND 9.x server in a split DNS configuration, where separate name servers are used between the external and internal networks, the external name server must be configured to not be reachable from inside resolvers.","description":"Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. \n\nOne set, called external name servers, can be located within a DMZ. These would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (web servers that serve external web pages or provide B2C services, mail servers, etc.).\n\nThe other set, called internal name servers, must be located within the firewall. They must be configured so they are not reachable from outside and therefore provide naming services exclusively to internal clients.","checkContent":"If the BIND 9.x name server is not configured for split DNS, this is not applicable.\n\nVerify that the external view of the BIND 9.x server is configured to only serve external hosts.\n\nInspect the \"named.conf\" file for the following:\n\nview \"external\" {\nmatch-clients { | ; };\n};\n\nIf the \"match-clients\" sub-statement does not limit the external view to external hosts only, this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nConfigure the external view statement to server external hosts only:\n\nview \"external\" {\nmatch-clients { | ; };\n};\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272382","ruleId":"SV-272382r1124041_rule","severity":"medium","ruleTitle":"A BIND 9.x implementation operating in a split DNS configuration must be approved by the organization's authorizing official (AO).","description":"BIND 9.x has implemented an option to use \"view\" statements to allow for split DNS architecture to be configured on a single name server. \n\nIf the split DNS architecture is improperly configured, there is a risk that internal IP addresses and host names could leak into the external view of the DNS server. \n\nAllowing private IP space to leak into the public DNS system may provide a person with malicious intent the ability to footprint the network and identify potential attack targets residing on the private network.","checkContent":"If the BIND 9.x name server is not configured for split DNS, this is not applicable.\n\nVerify that the split DNS implementation has been approved by the organizations AO.\n\nWith the assistance of the DNS administrator, obtain the AO's letter of approval for the split DNS implementation.\n\nIf the split DNS implementation has not been approved by the organizations AO, this is a finding.","fixText":"Obtain approval for the split DNS implementation from the AO.","ccis":["CCI-000366"]},{"vulnId":"V-272383","ruleId":"SV-272383r1124043_rule","severity":"medium","ruleTitle":"On the BIND 9.x server the IP address for hidden primary authoritative name servers must not appear in the name servers set in the zone database.","description":"A hidden primary authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. All of the name servers that do appear in the zone database as designated name servers get their zone data from the hidden primary via a zone transfer request. In effect, all visible name servers are actually secondary servers. This prevents potential attackers from targeting the primary name server because its IP address may not appear in the zone database.","checkContent":"With the assistance of the DNS administrator, identify if the BIND 9.x implementation is using a hidden primary name server. If it is not, this is not applicable.\n\nIn a split DNS configuration that is using a hidden primary name server, verify that the name server IP address is not listed in the zone file.\n\nWith the assistance of the DNS administrator, obtain the IP address of the hidden primary name server.\n\nInspect each zone file used by the hidden primary name server and its secondary zones.\n\nIf the IP address for the hidden primary name server is listed in any of the zone files, this is a finding.","fixText":"Edit the zone file(s).\n\nRemove all references to the hidden primary name server.\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272384","ruleId":"SV-272384r1156952_rule","severity":"medium","ruleTitle":"A BIND 9.x server NSEC3 must be used for all internal DNS zones.","description":"To ensure that RRs associated with a query are really missing in a zone file and have not been removed in transit, the DNSSEC mechanism provides a means for authenticating the nonexistence of an RR. It generates a special RR called an NSEC (or NSEC3) RR that lists the RRTypes associated with an owner name as well as the next name in the zone file. It sends this special RR, along with its signatures, to the resolving name server. By verifying the signature, a DNSSEC-aware resolving name server can determine which authoritative owner name exists in a zone and which authoritative RRTypes exist at those owner names.","checkContent":"If the server is on an internal, restricted network with reserved IP space, this is Not Applicable.\n\nWith the assistance of the DNS administrator, identify each internal DNS zone listed in the \"named.conf\" file.\n\nFor each internal zone identified, inspect the signed zone file for the NSEC resource records:\n\n86400 NSEC example.com. A RRSIG NSEC\n\nIf the zone file does not contain an NSEC record for the zone, this is a finding.","fixText":"Re-sign each zone that is missing NSEC records.\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272385","ruleId":"SV-272385r1156961_rule","severity":"medium","ruleTitle":"On the BIND 9.x server, the private keys corresponding to both the zone signing key (ZSK) and the key signing key (KSK) must not be kept on the BIND 9.x DNSSEC-aware primary authoritative name server when the name server does not support dynamic updates.","description":"The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored offline (with respect to the internet-facing, DNSSEC-aware name server) in a physically secure, nonnetwork-accessible machine along with the zone file primary copy. \n\nThis strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file primary copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept offline.","checkContent":"Determine if the BIND 9.x server is configured to allow dynamic updates.\n\nReview the \"named.conf\" file for any instance of the \"allow-update\" statement. The following example disables dynamic updates:\n\nallow-update {none;};\n\nIf the BIND 9.x implementation is not configured to allow dynamic updates or inline signing, verify with the system administrator (SA) that the private ZSKs and private KSKs are stored offline. If not, this is a finding.","fixText":"Remove any ZSK or KSK private key from any BIND 9.x server that does not support dynamic updates.\n\nNote: Any ZSK or KSK that is not needed to support dynamic updates must be stored offline in a secure location.","ccis":["CCI-000366"]},{"vulnId":"V-272386","ruleId":"SV-272386r1123985_rule","severity":"medium","ruleTitle":"The two files generated by the BIND 9.x server dnssec-keygen program must be owned by the administrator account or deleted once they have been copied to the key file in the name server.","description":"To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64 encoded. A TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.","checkContent":"With the assistance of the DNS administrator, identify all dnssec-keygen key files that reside on the BIND 9.x server.\n\nAn example dnssec-keygen key file will look like the following:\n\nKns1.example.com_ns2.example.com.+161+28823.key\nOR\nKns1.example.com_ns2.example.com.+161+28823.private\n\nFor each key file identified, verify that the key file is owned by \"named\":\n\n# ls -al\n-rw-r-----. 1 named named 76 May 10 20:35 dnssec-example.key\n\nIf the key files are not owned by named, this is a finding.","fixText":"Change the ownership of the keys to the administrator account.\n\n# chown named:named .","ccis":["CCI-000366"]},{"vulnId":"V-272387","ruleId":"SV-272387r1123881_rule","severity":"medium","ruleTitle":"The two files generated by the BIND 9.x server dnssec-keygen program must be group owned by the server administrator account or deleted once they have been copied to the key file in the name server.","description":"To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64 encoded. A TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.","checkContent":"With the assistance of the DNS administrator, identify all dnssec-keygen key files that reside on the BIND 9.x server.\n\nAn example dnssec-keygen key file will look like the following:\n\nKns1.example.com_ns2.example.com.+161+28823.key\nOR\nKns1.example.com_ns2.example.com.+161+28823.private\n\nFor each key file identified, verify that the key file is owned by \"named\":\n\n# ls -al\n-rw-r-----. 1 named named 77 Jul 1 15:00 Kns1.example.com_ns2.example.com+161+28823.key\n\nIf the key files are not owned by named, this is a finding.","fixText":"Change the group ownership of the keys to the root group.\n\n# chgrp named:named .","ccis":["CCI-000366"]},{"vulnId":"V-272388","ruleId":"SV-272388r1124010_rule","severity":"medium","ruleTitle":"Permissions assigned to the dnssec-keygen keys used with the BIND 9.x implementation must enforce read-only access to the key owner and deny access to all other users.","description":"To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64 encoded. A TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message. Weak permissions could allow an adversary to modify the file(s), thus defeating the security objective.","checkContent":"With the assistance of the DNS administrator, identify all dnssec-keygen key files that reside on the BIND 9.x server.\n\nAn example dnssec-keygen key file will look like the following:\n\nKns1.example.com_ns2.example.com.+161+28823.key\nOR\nKns1.example.com_ns2.example.com.+161+28823.private\n\nFor each key file identified, verify that the key file is owned by \"named\" and permissions are set to 400:\n\n# ls -al\n-r-------- 1 named named 77 Jul 1 15:00 Kns1.example.com_ns2.example.com+161+28823.key\n\nIf the key files are not owned by “named”, this is a finding.\n\nIf the key files are more permissive than 400, this is a finding.","fixText":"Change the permissions of the dnssec-keygen key files:\n\n# chmod 400 ","ccis":["CCI-000366"]},{"vulnId":"V-272389","ruleId":"SV-272389r1123885_rule","severity":"medium","ruleTitle":"A BIND 9.x server validity period for the RRSIGs covering a zones DNSKEY RRSet must be no less than two days and no more than one week.","description":"The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a zone signing key (ZSK) can use that key only during the key signing key's (KSK's) signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing.","checkContent":"With the assistance of the DNS administrator, identify the RRSIGs that cover the DNSKEY resource record set for each zone.\n\nEach record will list an expiration and inception date, the difference of which will provide the validity period. This check also applies to inline signing.\n\nThe dates are listed in the following format:\n\nYYYYMMDDHHMMSS\n\nFor each RRSIG identified, verify that the validity period is no less than two days and no longer than seven days.\n\nIf the validity period is outside of the specified range, this is a finding.","fixText":"Re-sign each zone that is outside of the validity period.\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272390","ruleId":"SV-272390r1156960_rule","severity":"medium","ruleTitle":"On the BIND 9.x server, the private key corresponding to the zone signing key (ZSK), stored on name servers accepting dynamic updates, must be owned by named.","description":"The private keys in the key signing key (KSK) and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored offline (with respect to the internet-facing, DNSSEC-aware name server) in a physically secure, nonnetwork-accessible machine along with the zone file primary copy. \n\nThis strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file primary copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept offline.","checkContent":"Note: This check only verifies for ZSK key file ownership. Permissions for key files are required under BIND-9X-001132 and BIND-9X-001142.\n\nFor each signed zone file, identify the ZSK \"key id\" number:\n\n# cat | grep -i \"zsk\"\nZSK; alg = ECDSAP256SHA256; key id = 22335\n\nUsing the ZSK \"key id\", identify the private ZSK:\n\nKexample.com.+008+22335.private\n\nVerify that the private ZSK is owned by named:\n\n# ls -l \n-r------- 1 named named 1776 Jul 3 17:56 Kexample.com.+008+22335.private\n\nIf the key file is not owned by named, this is a finding.","fixText":"Change the ownership of the ZSK private key to the root account:\n\n# chown named ","ccis":["CCI-000366"]},{"vulnId":"V-272391","ruleId":"SV-272391r1156960_rule","severity":"medium","ruleTitle":"On the BIND 9.x server, the private key corresponding to the zone signing key (ZSK), stored on name servers accepting dynamic updates, must be group owned by named.","description":"The private keys in the key signing key (KSK) and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored offline (with respect to the internet-facing, DNSSEC-aware name server) in a physically secure, nonnetwork-accessible machine along with the zone file primary copy. \n\nThis strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file primary copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept offline.","checkContent":"Note: This check only verifies for ZSK key file ownership. Permissions for key files are required under BIND-9X-001132 and BIND-9X-001142.\n\nFor each signed zone file, identify the ZSK \"key id\" number:\n\n# cat | grep -i \"zsk\"\nZSK; alg = ECDSAP256SHA256; key id = 22335\n\nUsing the ZSK \"key id\", verify the private ZSK.\n\nKexample.com.+008+22335.private\n\nVerify that the private ZSK is owned by \"named\":\n\n# ls -l \n-r------- 1 named named 1776 Jul 3 17:56 Kexample.com.+008+22335.private\n\nIf the key file is not group owned by named, this is a finding.","fixText":"Change the group ownership of the ZSK private key to the root group account.\n\n# chgrp named ","ccis":["CCI-000366"]},{"vulnId":"V-272392","ruleId":"SV-272392r1124046_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must prohibit the forwarding of queries to servers controlled by organizations outside of the U.S. government.","description":"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. \n\nThe 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.\n\nOrganizations 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 U.S. government.","checkContent":"If the server is not a caching server, this is not applicable.\n\nNote: The use of the Defense Research and Engineering Network (DREN) Enterprise Recursive DNS servers, as mandated by the DODIN service provider DREN, meets the intent of this requirement. \n\nVerify that the server is configured to forward all DNS traffic to the DISA ERS anycast IP addresses ( ; ).\n\nInspect the \"named.conf\" file for the following:\n\nforward only;\nforwarders { ; };\n\nIf the \"named.conf\" options are not set to forward queries only to the ERS anycast IPs, this is a finding.","fixText":"Configure the BIND 9.x caching name server to use the DISA ERS anycast IP addresses.\n\nEdit the \"named.conf\" file and add the following to the global options statement:\n\nforward only;\nforwarders { ; };\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272393","ruleId":"SV-272393r1124048_rule","severity":"medium","ruleTitle":"The secondary name servers in a BIND 9.x implementation must be configured to initiate zone update notifications to other authoritative zone name servers.","description":"It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a change to the zone has occurred and a zone transfer should be performed. The serial number used in the SOA record provides the DNS administrator a method to verify the integrity of the zone file based on the serial number of the last update and ensure that all secondary servers are using the correct zone file.\n\nWhen a primary name server notices that the serial number of a zone has changed, it sends a special announcement to all of the secondary name servers for that zone. The primary name server determines which servers are the secondaries for the zone by looking at the list of NS records in the zone and taking out the record that points to the name server listed in the MNAME field of the zone's SOA record as well as the domain name of the local host.\n\nWhen a secondary name server receives a NOTIFY announcement for a zone from one of its configured primary name servers, it responds with a NOTIFY response. The response tells the primary that the secondary received the NOTIFY announcement so that the primary can stop sending it NOTIFY announcements for the zone. Then the secondary proceeds just as if the refresh timer for that zone had expired: it queries the primary name server for the SOA record for the zone that the primary claims has changed. If the serial number is higher, the secondary transfers the zone.\n\nThe secondary should next issue its own NOTIFY announcements to the other authoritative name servers for the zone. The idea is that the primary may not be able to notify all of the secondary name servers for the zone itself, since it is possible some secondaries cannot communicate directly with the primary (they use another secondary as their primary). Older BIND 8 secondaries do not send NOTIFY messages unless explicitly configured to do so.","checkContent":"If this is a primary name server, this is not applicable.\n\nOn a secondary name server, verify that the global notify is disabled. The global entry for the name server is under the \"Options\" section, and notify must be disabled at this section.\n\nInspect the \"named.conf\" file for the following:\n\noptions {\nnotify no;\n};\n\nIf the \"notify\" statement is missing, this is a finding.\n\nIf the \"notify\" statement is set to \"yes\", this is a finding.\n\nVerify that zones for which the secondary server is authoritative are configured to notify other authorized secondary name servers when a zone file update has been received from the primary name server for the zone. Each zone has its own zone section.\n\nInspect the \"named.conf\" file for the following:\n\nzone example.com {\nnotify explicit;\nalso-notify { ; | ; };\n\nIf an \"address match list\" is used, verify that each IP address listed is an authorized secondary name server for that zone.\n\nIf the \"notify explicit\" statement is missing, this is a finding.\n\nIf the \"also-notify\" statement is missing, this is a finding.\n\nIf the \"also-notify\" statement is configured to notify name servers that are not authorized for that zone, this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nConfigure the \"notify\" sub-statement in the \"options\" statement block to \"no\":\n\noptions { \nnotify no;\n};\n\nConfigure the \"notify explicit\" and \"also-notify\" sub-statements in the zone statement block to limit zone transfer notifications to authorized secondary name servers:\n\nzone example.com {\nnotify explicit;\nalso-notify { ; | ; };\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272394","ruleId":"SV-272394r1156949_rule","severity":"medium","ruleTitle":"A BIND 9.x server implementation must prohibit recursion on authoritative name servers.","description":"A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to nonexistent hosts (which constitutes a denial of service), or worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords. \n\nTo guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine: one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation.\n\nDNSSEC ensures that the answer received when querying for name resolution actually comes from a trusted name server. Since DNSSEC is still far from being globally deployed external to DOD, and many resolvers either have not been updated or do not support DNSSEC, maintaining cached zone data separate from authoritative zone data mitigates the gap until all DNS data is validated with DNSSEC. \n\nSince DNS forwarding of queries can be accomplished in some DNS applications without caching locally, DNS forwarding is the method to be used when providing external DNS resolution to internal clients.\n\nSatisfies: SRG-APP-000383-DNS-000047, SRG-APP-000246-DNS-000035","checkContent":"If this is a recursive name server, this is not applicable.\n\nNote: A recursive name server must NOT be configured as an authoritative name server for any zone.\n\nVerify that the BIND 9.x server is configured to prohibit recursion on authoritative name servers.\n\nInspect the \"named.conf\" file for the following:\n\noptions {\nrecursion no;\nallow-recursion {none;};\nallow-query {none;};\n};\n\nIf the \"recursion\" sub-statement is missing or set to \"yes\", this is a finding.","fixText":"Configure the authoritative name server to prohibit recursion.\n\nEdit the \"named.conf\" file and add the following sub-statements to the options statement:\n\nrecursion no;\n\nRestart the BIND 9.x process.","ccis":["CCI-000366","CCI-001094"]},{"vulnId":"V-272395","ruleId":"SV-272395r1124052_rule","severity":"medium","ruleTitle":"The primary servers in a BIND 9.x implementation must notify authorized secondary name servers when zone files are updated.","description":"It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a change to the zone has occurred and a zone transfer should be performed. The serial number used in the SOA record provides the DNS administrator a method to verify the integrity of the zone file based on the serial number of the last update and ensure that all secondary servers are using the correct zone file.\n\nWhen a primary name server notices that the serial number of a zone has changed, it sends a special announcement to all of the secondary name servers for that zone. The primary name server determines which servers are the secondaries for the zone by looking at the list of NS records in the zone and taking out the record that points to the name server listed in the MNAME field of the zone's SOA record as well as the domain name of the local host.\n\nWhen a secondary name server receives a NOTIFY announcement for a zone from one of its configured primary name servers, it responds with a NOTIFY response. The response tells the primary that the secondary received the NOTIFY announcement so that the primary can stop sending it NOTIFY announcements for the zone. Then the secondary proceeds just as if the refresh timer for that zone had expired: it queries the primary name server for the SOA record for the zone that the primary claims has changed. If the serial number is higher, the secondary transfers the zone.\n\nThe secondary should issue its own NOTIFY announcements to the other authoritative name servers for the zone. The idea is that the primary may not be able to notify all of the secondary name servers for the zone itself, since it is possible some secondaries cannot communicate directly with the primary (they use another secondary as their primary). Older BIND 8 secondaries do not send NOTIFY messages unless explicitly configured to do so.","checkContent":"If this is a secondary name server, this is not applicable.\n\nOn a primary name server, verify that the global notify is disabled. The global entry for the name server is under the \"Options\" section, and \"notify\" must be disabled at this section.\n\nInspect the \"named.conf\" file for the following:\n\noptions {\nnotify no;\n};\n\nIf the \"notify\" statement is missing, this is a finding.\n\nIf the \"notify\" statement is set to \"yes\", this is a finding.\n\nVerify that each zone is configured to notify authorized secondary name servers when a zone file has been updated. Each zone has its own zone section.\n\nInspect the \"named.conf\" file for the following:\n\nzone example.com {\nnotify explicit;\nalso-notify { ; | ; };\n\nIf an \"address match list\" is used, verify that each IP address listed is an authorized secondary name server for that zone.\n\nIf the \"notify explicit\" statement is missing, this is a finding.\n\nIf the \"also-notify\" statement is missing, this is a finding.\n\nIf the \"also-notify\" statement is configured to notify name servers that are not authorized for that zone, this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nConfigure the \"notify\" sub-statement in the \"options\" statement block to \"no\":\n\noptions { \nnotify no;\n};\n\nConfigure the \"notify explicit\" and \"also-notify\" sub-statements in the zone statement block to limit zone transfer notifications to authorized secondary name servers:\n\nzone example.com {\nnotify explicit;\nalso-notify { ; | ; };\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272396","ruleId":"SV-272396r1192866_rule","severity":"medium","ruleTitle":"On a BIND 9.x server, all root name servers listed in the local root zone file hosted on a BIND 9.x authoritative name server must be valid for that zone.","description":"All caching name servers must be authoritative for the root zone because, without this starting point, they would have no knowledge of the DNS infrastructure and thus would be unable to respond to any queries. The security risk is that an adversary could change the root hints and direct the caching name server to a bogus root server. At that point, every query response from that name server is suspect, which would give the adversary substantial control over the network communication of the name servers' clients.","checkContent":"If this is an authoritative name server, this is not applicable.\n\nUse command dig @ . ns and examine results.\n\nAnswer results\n. 518400 IN NS e.root-servers.net.\n. 518400 IN NS a.root-servers.net.\n. 518400 IN NS g.root-servers.net.\n. 518400 IN NS i.root-servers.net.\n. 518400 IN NS h.root-servers.net.\n. 518400 IN NS d.root-servers.net.\n. 518400 IN NS c.root-servers.net.\n. 518400 IN NS k.root-servers.net.\n. 518400 IN NS f.root-servers.net.\n. 518400 IN NS m.root-servers.net.\n. 518400 IN NS b.root-servers.net.\n. 518400 IN NS j.root-servers.net.\n. 518400 IN NS l.root-servers.net.\n \n;; ADDITIONAL SECTION:\nm.root-servers.net. 518400 IN A 202.12.27.33\nl.root-servers.net. 518400 IN A 199.7.83.42\nk.root-servers.net. 518400 IN A 193.0.14.129\nj.root-servers.net. 518400 IN A 192.58.128.30\ni.root-servers.net. 518400 IN A 192.36.148.17\nh.root-servers.net. 518400 IN A 198.97.190.53\ng.root-servers.net. 518400 IN A 192.112.36.4\nf.root-servers.net. 518400 IN A 192.5.5.241\ne.root-servers.net. 518400 IN A 192.203.230.10\nd.root-servers.net. 518400 IN A 199.7.91.13\nc.root-servers.net. 518400 IN A 192.33.4.12\nb.root-servers.net. 518400 IN A 170.247.170.2\na.root-servers.net. 518400 IN A 198.41.0.4\nm.root-servers.net. 518400 IN AAAA 2001:dc3::35\nl.root-servers.net. 518400 IN AAAA 2001:500:9f::42\nk.root-servers.net. 518400 IN AAAA 2001:7fd::1\nj.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30\ni.root-servers.net. 518400 IN AAAA 2001:7fe::53\nh.root-servers.net. 518400 IN AAAA 2001:500:1::53\ng.root-servers.net. 518400 IN AAAA 2001:500:12::d0d\nf.root-servers.net. 518400 IN AAAA 2001:500:2f::f\ne.root-servers.net. 518400 IN AAAA 2001:500:a8::e\nd.root-servers.net. 518400 IN AAAA 2001:500:2d::d\nc.root-servers.net. 518400 IN AAAA 2001:500:2::c\nb.root-servers.net. 518400 IN AAAA 2801:1b8:10::b\na.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30\n\nIf names and addresses do not match the current IANA list, this is a finding.\n\nPerform command dig @ . dnskey +multi and examine results.\n\nanswer results\n77555 IN DNSKEY 257 3 8 (\n AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO\n iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN\n 7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5\n LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8\n efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7\n pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY\n A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws\n 9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=\n ) ; KSK; alg = RSASHA256 ; key id = 20326\n. 77555 IN DNSKEY 256 3 8 (\n AwEAAbEbGCpGTDrcZTWqWWE72nphyshpRcILdzCVlBGU\n 9Ln1Fui9kkseUOP+g5GLUeVFKdTloeRTA9+EYiQdXgWX\n mXmuW/nGxZjAikluF/O9NzLVrr5iZnth2xu+F48nrJlA\n gWWiMNau54NI5sZ3iVQfhFsq2pZmf43RauRPniYMShOL\n O7EBWWXr5glDSgZGS9fSm6xHwwF+g8D4m8oanjvdCBNx\n XzSEKS31ibxjLifTfvwCg3y4XXcNW9U6Nu3JmoKUdxqp\n PPIkBvVQbIz4UO2FwaR13uXC03ALP1Yx2QNSS4SZlcIM\n tAftQR9wtCiuPWQnFv4jkzWqlhp1Lmf7bcoL9yk=\n ) ; ZSK; alg = RSASHA256 ; key id = 53148\n. 77555 IN DNSKEY 257 3 8 (\n AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC\n 6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeH\n spaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vr\n hbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAx\n m9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7\n CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+\n u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxP\n vYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc=\n ) ; KSK; alg = RSASHA256 ; key id = 38696\n\nNote: May use \"nslookup\" as an alternative to \"dig\".\n\nIf the DNSSEC keys and root anchors do not match the IANA list, this is a finding.","fixText":"Edit the local root zone file.\n\nEnsure that the root servers listed match the IANA list.\n\nEnsure that the DNS keys and trust anchors listed match the IANA list.\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272397","ruleId":"SV-272397r1124056_rule","severity":"medium","ruleTitle":"On a BIND 9.x server, all root name servers listed in the local root zone file hosted on a BIND 9.x authoritative name server must be empty or removed.","description":"A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. 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 is to delete the root hints file.\n\nWhen authoritative servers are sent queries for zones that they are not authoritative for and they are configured as a noncaching server (as recommended), they can either be configured to return a referral to the root servers or 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 for its intended purpose of answering authoritatively for its zone.","checkContent":"If this server is a caching name server, this is not applicable.\n\nVerify there is not a local root zone on the name server.\n\nInspect the \"named.conf\" file for the following:\n\nzone \".\" IN {\ntype hint;\nfile \"\"\n};\n\nIf the file name identified is not empty or does exist, this is a finding.","fixText":"Remove the local root zone file from the name server.","ccis":["CCI-000366"]},{"vulnId":"V-272399","ruleId":"SV-272399r1124058_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must implement internal/external role separation.","description":"DNS servers with an internal role only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks, including the internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization using address ranges, explicit access control lists, etc. To protect internal DNS resource information, it is important to isolate the requests to internal DNS servers. \n\nFailure to separate internal and external roles in DNS may lead to 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. Allowing private IP space to leak into the public DNS system may provide a person with malicious intent the ability to footprint the network and identify potential attack targets residing on the private network.","checkContent":"Severity override guidance:\n\nIf the internal and external views are on separate network segments, this finding may be downgraded to a CAT II.\n\nIf the BIND 9.x name server is not configured for split DNS, this is not applicable.\n\nVerify that the BIND 9.x server is configured to use separate views and address space for internal and external DNS operations when operating in a split configuration.\n\nInspect the \"named.conf\" file for the following:\n\nview \"internal\" {\nmatch-clients { | };\nzone \"example.com\" {\ntype Primary;\nfile \"internals.example.com\";\n};\n};\nview \"external\" {\nmatch-clients { | };\nzone \"example.com\" {\ntype Primary;\nfile \"externals.db.example.com\";\nallow-transfer { Secondarys; };\n};\n};\n\nIf an external view is listed before an internal view, this is a finding.\n\nIf the internal and external views are on the same network segment, this is a finding.\n\nNote: BIND 9.x reads the \"named.conf\" file from top to bottom. If a less stringent \"match-clients\" statement is processed before a more stringent \"match-clients\" statement, the more stringent statement will be ignored. With this in mind, all internal view statements must be listed before any external view statement in the \"named.conf\" file.","fixText":"Edit the \"named.conf\" file.\n\nConfigure the internal and external view statements to use separate network segments.\n\nConfigure all internal view statements to be listed before any external view statement.\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272400","ruleId":"SV-272400r1123993_rule","severity":"medium","ruleTitle":"Every NS record in a zone file on a BIND 9.x server must point to an active name server and that name server must be authoritative for the domain specified in that record.","description":"Poorly constructed NS records pose a security risk because they create conditions under which an adversary might be able to provide the missing authoritative name services that are improperly specified in the zone file. The adversary could issue bogus responses to queries that clients would accept because they learned of the adversary's name server from a valid authoritative name server, one that need not be compromised for this attack to be successful. \n\nThe list of secondary servers must remain current with any changes to the zone architecture that would affect the list of secondaries. If a secondary server has been retired or is not operational but remains on the list, an adversary might have a greater opportunity to impersonate that secondary without detection, rather than if the secondary were actually online. For example, the adversary may be able to spoof the retired secondary's IP address without an IP address conflict, which would not be likely to occur if the true secondary were active.","checkContent":"Verify that each name server listed on the BIND 9.x server is authoritative for the domain it supports.\n\nInspect the \"named.conf\" file and identify all of the zone files that the BIND 9.x server is using.\n\nzone \"example.com\" {\nfile \"zone_file\";\n};\n\nInspect each zone file and identify each NS record listed.\n\n86400 NS ns1.example.com\n86400 NS ns2.example.com\n\nWith the assistance of the DNS administrator, verify that each name server listed is authoritative for that domain.\n\nIf name servers are listed in the zone file that are not authoritative for the specified domain, this is a finding.","fixText":"Edit the zone file(s).\n\nRemove any name server for which the BIND 9.x server is not authoritative.\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272401","ruleId":"SV-272401r1156953_rule","severity":"medium","ruleTitle":"On a BIND 9.x server, all authoritative name servers for a zone must be located on different network segments.","description":"Most enterprises have an authoritative primary server and a host of authoritative secondary name servers. It is essential that these authoritative name servers for an enterprise be located on different network segments. This dispersion ensures the availability of an authoritative name server not only in situations in which a particular router or switch fails but also during events involving an attack on an entire network segment.","checkContent":"Verify that each name server listed on the BIND 9.x server is on a separate network segment.\n\nInspect the \"named.conf\" file and identify all of the zone files that the BIND 9.x server is using.\n\nzone \"example.com\" {\nfile \"zone_file\";\n};\n\nInspect each zone file and identify each A record for each NS record listed:\n\nns1.example.com 86400 IN A 192.168.1.4\nns2.example.com 86400 IN A 192.168.2.4\n\nIf name servers are listed in the zone file that are not on different network segments for the specified domain, this is a finding.","fixText":"Edit the zone file and configure each name server on a separate network segment.","ccis":["CCI-000366"]},{"vulnId":"V-272402","ruleId":"SV-272402r1124060_rule","severity":"medium","ruleTitle":"On the BIND 9.x server, the platform on which the name server software is hosted must be configured to send outgoing DNS messages from a random port.","description":"OS configuration practices as issued by the U.S. Computer Emergency Response Team (US CERT) and the National Institute of Standards and Technology's (NIST's) National Vulnerability Database (NVD), based on identified vulnerabilities that pertain to the application profile into which the name server software fits should be always followed. In particular, hosts that run the name server software should not provide any other services and therefore should be configured to respond to DNS traffic only. In other words, the only allowed incoming ports/protocols to these hosts should be 53/udp and 53/tcp. \n\nOutgoing DNS messages should be sent from a random port to minimize the risk of an attacker guessing the outgoing message port and sending forged replies.","checkContent":"Verify that the BIND 9.x server does not limit outgoing DNS messages to a specific port.\n\nInspect the \"named.conf\" file. The \"query-source\" and \"query-source-v6\" must not limit the ports available to be used.\n\noptions {\nquery-source address ;\nquery-source-v6 address ;\n};\n\nIf the port flag is used on the query-source address or query-source-v6 address, this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nConfigure the BIND 9.x server to not specify ports for the query-source address or query-source-v6 address statements:\n\noptions {\nquery-source address ;\nquery-source-v6 address ;\n};\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272403","ruleId":"SV-272403r1156957_rule","severity":"medium","ruleTitle":"A BIND 9.x server implementation must be operating on a Current-Stable version as defined by ISC.","description":"The BIND STIG was written to incorporate capabilities and features provided in BIND version 9.9.x. However, security vulnerabilities in BIND are identified and then addressed on a regular, ongoing basis. Therefore, the product must be maintained at the latest stable versions to address vulnerabilities that are subsequently identified and can then be remediated via product updates.\n\nFailure to run a version of BIND that has the capability to implement all of the required security features and provide services compliant with the DNS RFCs can have a severe impact on the security posture of a DNS infrastructure. Without the required security in place, a DNS implementation is vulnerable to many types of attacks and could be used as a launching point for further attacks on the organizational network that is using the DNS implementation.","checkContent":"Verify that the BIND 9.x server is at a version that is considered \"Current-Stable\" by ISC or the latest supported version of BIND when BIND is installed as part of a specific vendor implementation where the vendor maintains the BIND patches.\n\n# named -v\n\nThe above command should produce a version number similar to the following:\n\nBIND 9.18.36-RedHat-9.9.4-29.el7_2.3\n\nIf the server is running a version that is not listed as \"Current-Stable\" by ISC, this is a finding.","fixText":"Update the BIND 9.x server to a version that is listed as \"Current-Stable\" by ISC or the latest supported version of BIND when BIND is installed as part of a specific vendor implementation where the vendor maintains the BIND patches.","ccis":["CCI-000366"]},{"vulnId":"V-272404","ruleId":"SV-272404r1156959_rule","severity":"medium","ruleTitle":"The host running a BIND 9.x implementation must use a dedicated management interface to separate management traffic from DNS-specific traffic.","description":"Providing out-of-band (OOB) management is the best first step in any management strategy. No production traffic resides on an OOB network. The biggest advantage to implementation of an OOB network is providing support and maintenance to the network that has become degraded or compromised. During an outage or degradation period, the in-band management link may not be available.","checkContent":"Verify that the BIND 9.x server is configured to use a dedicated management interface:\n\n# ifconfig -a\neth0: flags=4163 mtu 1500\ninet 10.0.1.252 netmask 255.255.255.0 broadcast 10.0.1.255\ninet6 fd80::21c:d8ff:fab7:1dba prefixlen 64 scopeid 0x20\nether 00:1a:b8:d7:1a:bf txqueuelen 1000 (Ethernet)\nRX packets 2295379 bytes 220126493 (209.9 MiB)\nRX errors 0 dropped 31 overruns 0 frame 0\nTX packets 70507 bytes 12284940 (11.7 MiB)\nTX errors 0 dropped 0 overruns 0 carrier 0 collisions 0\n\neth1: flags=4163 mtu 1458\ninet 10.0.0.5 netmask 255.255.255.0 broadcast 10.0.0.255\ninet6 fe81::21c:a8bf:fad7:1dca prefixlen 64 scopeid 0x20\nether 00:1d:d8:b5:1c:dd txqueuelen 1000 (Ethernet)\nRX packets 39090 bytes 4196802 (4.0 MiB)\nRX errors 0 dropped 0 overruns 0 frame 0\nTX packets 93250 bytes 18614094 (17.7 MiB)\nTX errors 0 dropped 0 overruns 0 carrier 0 collisions 0\n\nIf one of the interfaces listed is not dedicated to only process management traffic, this is a finding.","fixText":"On the host machine, configure an interface that is dedicated to management traffic.\n\nRestart the host machine.","ccis":["CCI-000366"]},{"vulnId":"V-272405","ruleId":"SV-272405r1156959_rule","severity":"medium","ruleTitle":"The host running a BIND 9.x implementation must use an interface that is configured to process only DNS traffic.","description":"Configuring hosts that run a BIND 9.x implementation to only accept DNS traffic on a DNS interface allows a system to be configured to segregate DNS traffic from all other host traffic.\n\nThe TCP/IP stack in DNS hosts (stub resolver, caching/resolving/recursive name server, authoritative name server, etc.) could be subjected to packet flooding attacks (such as SYNC and smurf), resulting in disruption of communication. \n\nThe use of a dedicated interface for DNS traffic allows for these threats to be mitigated by creating a means to limit what types of traffic can be processed using a host-based firewall solution.","checkContent":"Verify that the BIND 9.x server is configured to use an interface that is configured to process only DNS traffic.\n\n# ifconfig -a\neth0: flags=4163 mtu 1500\ninet 10.0.1.252 netmask 255.255.255.0 broadcast 10.0.1.255\ninet6 fd80::21c:d8ff:fab7:1dba prefixlen 64 scopeid 0x20\nether 00:1a:b8:d7:1a:bf txqueuelen 1000 (Ethernet)\nRX packets 2295379 bytes 220126493 (209.9 MiB)\nRX errors 0 dropped 31 overruns 0 frame 0\nTX packets 70507 bytes 12284940 (11.7 MiB)\nTX errors 0 dropped 0 overruns 0 carrier 0 collisions 0\n\neth1: flags=4163 mtu 1458\ninet 10.0.0.5 netmask 255.255.255.0 broadcast 10.0.0.255\ninet6 fe81::21c:a8bf:fad7:1dca prefixlen 64 scopeid 0x20\nether 00:1d:d8:b5:1c:dd txqueuelen 1000 (Ethernet)\nRX packets 39090 bytes 4196802 (4.0 MiB)\nRX errors 0 dropped 0 overruns 0 frame 0\nTX packets 93250 bytes 18614094 (17.7 MiB)\nTX errors 0 dropped 0 overruns 0 carrier 0 collisions 0\n\nIf one of the interfaces listed is not dedicated to only process DNS traffic, this is a finding.","fixText":"On the host machine, configure an interface to only process DNS traffic.\n\nRestart the host machine.","ccis":["CCI-000366"]},{"vulnId":"V-272406","ruleId":"SV-272406r1156959_rule","severity":"medium","ruleTitle":"The platform on which the name server software is hosted must only run processes and services needed to support the BIND 9.x implementation.","description":"Hosts that run the name server software must not provide any other services. Unnecessary services running on the DNS server can introduce additional attack vectors, leading to the compromise of an organization's DNS architecture.","checkContent":"Verify that the BIND 9.x server is dedicated for DNS traffic.\n\nWith the assistance of the DNS administrator, identify all of the processes running on the BIND 9.x server:\n\n# ps -ef | less\n\nIf any of the identified processes are not in support of normal OS functionality or in support of the BIND 9.x process, this is a finding.","fixText":"Disable or uninstall all non-DNS related applications from the BIND 9.x server.","ccis":["CCI-000366"]},{"vulnId":"V-272407","ruleId":"SV-272407r1156956_rule","severity":"medium","ruleTitle":"The core BIND 9.x server files must be group owned by a group designated for DNS administration only.","description":"Discretionary Access Control (DAC) is based on the premise that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired because of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.","checkContent":"Verify that the core BIND 9.x server files are group owned by a group designated for DNS administration only.\n\nWith the assistance of the DNS administrator, identify the following files:\n\nnamed.conf\nroot hints \nPrimary zone file(s)\nSecondary zone file(s)\n\nNote: The name of the root hints file is defined in named.conf. Common names for the file are root.hints, named.cache, or db.cache.\n\nIf the identified files are not group owned by a group designated for DNS administration, this is a finding.","fixText":"Change the ownership of the core BIND 9.x server files to the process account group.\n\n# chgrp (BIND 9.x process account) ","ccis":["CCI-000366"]},{"vulnId":"V-272408","ruleId":"SV-272408r1156956_rule","severity":"medium","ruleTitle":"The core BIND 9.x server files must be owned by the root or BIND 9.x process account.","description":"Discretionary Access Control (DAC) is based on the premise that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired because of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.","checkContent":"Verify that the core BIND 9.x server files are owned by the root or BIND 9.x process account.\n\nWith the assistance of the DNS administrator, identify the following files:\n\nnamed.conf\nroot hints \nPrimary zone file(s)\nSecondary zone file(s)\n\nNote: The name of the root hints file is defined in named.conf. Common names for the file are root.hints, named.cache, or db.cache.\n\nIf the identified files are not owned by the root or BIND 9.x process account, this is a finding.","fixText":"Change the ownership of the files to the root or BIND 9.x process account.\n\n# chown ","ccis":["CCI-000366"]},{"vulnId":"V-272410","ruleId":"SV-272410r1124061_rule","severity":"medium","ruleTitle":"On a BIND 9.x server, all authoritative name servers for a zone must have the same version of zone information.","description":"It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a change to the zone has occurred and a zone transfer should be performed. The serial number used in the SOA record provides the DNS administrator a method to verify the integrity of the zone file based on the serial number of the last update and ensure that all secondary servers are using the correct zone file.","checkContent":"Verify that the SOA record is at the same version for all authoritative servers for a specific zone.\n\nWith the assistance of the DNS administrator, identify each name server that is authoritative for each zone.\n\nInspect each zone file that the server is authoritative for and identify the following:\n\nexample.com. 86400 IN SOA ns1.example.com. root.example.com. (17760704;serial) \n\nIf the SOA \"serial\" numbers are not identical on each authoritative name server, this is a finding.","fixText":"Edit the zone file.\n\nUpdate the SOA record serial number.","ccis":["CCI-000366"]},{"vulnId":"V-272411","ruleId":"SV-272411r1156962_rule","severity":"medium","ruleTitle":"On the BIND 9.x server, CNAME records must not point to a zone with lesser security for more than six months.","description":"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 alias's canonical name. This configuration also reduces the speed of client resolution because it requires a second lookup after obtaining the canonical name. Furthermore, in the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers and thus compounds the vulnerability.","checkContent":"Verify that the zone files used by the BIND 9.x server do not contain resource records for a domain in which the server is not authoritative.\n\nInspect the \"named.conf\" file for the following:\n\nzone example.com {\nfile \"db.example.com.signed\";\n};\n\nInspect each zone file for \"CNAME\" records and verify with the DNS administrator that these records are less than six months old.\n\nThe exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated.\n\nIf there are CNAME records that point to third-party Content Delivery Networks (CDNs) or cloud computing platforms without an authorizing official (AO)-approved and documented mission need, this is a finding.\n\nIf a CNAME record is more than six months old, excluding the above, this is a finding.","fixText":"In the case of third-party CDNs or cloud offerings, document the mission need with the AO.\n\nEdit the zone file.\n\nRemove CNAME records that are older than six months that do not meet the CDN or cloud offering criteria.\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272412","ruleId":"SV-272412r1124064_rule","severity":"medium","ruleTitle":"On the BIND 9.x server, a zone file must not include resource records that resolve to a fully qualified domain name residing in another zone.","description":"If a name server were able to claim authority for a resource record in a domain for which it was not authoritative, this would pose a security risk. In this environment, an adversary could use illicit control of a name server to impact IP address resolution beyond the scope of that name server (i.e., by claiming authority for records outside of that server's zones). Fortunately, all but the oldest versions of BIND and most other DNS implementations do not allow for this behavior. Nevertheless, the best way to eliminate this risk is to eliminate from the zone files any records for hosts in another zone.\n\nThe exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated.","checkContent":"Verify that the zone files used by the BIND 9.x server do not contain resource records for a domain in which the server is not authoritative.\n\nThe exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated.\n\nInspect the \"named.conf\" file to identify the zone files, for which the server is authoritative:\n\nzone example.com {\nfile \"db.example.com.signed\";\n};\n\nInspect each zone file for which the server is authoritative. \n\nIf there are CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms without an authorizing official (AO)-approved and documented mission need, this is a finding.\n\nIf a zone file contains records that resolve to another zone, excluding the above, this is a finding.","fixText":"In the case of third-party CDNs or cloud offerings, document the mission need with the AO.\n\nEdit the zone file.\n\nRemove any record that points to a different zone, with the exception of approved CDNs or cloud offerings.\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272413","ruleId":"SV-272413r1156958_rule","severity":"medium","ruleTitle":"The BIND 9.x name server software must run with restricted privileges.","description":"Failure to provide logical access restrictions associated with changes to application configuration may have significant effects on the overall security of the system. When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system and/or application can have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications. \n\nLogical access restrictions include, for example, controls that restrict access to workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover).\n\nIf the name server software is run as a privileged user (e.g., root in Unix systems), any break-in into the software can have disastrous consequences in terms of resources resident in the name server platform. Specifically, a hacker who breaks into the software acquires unrestricted access and therefore can execute any commands or modify or delete any files. It is necessary to run the name server software as a nonprivileged user with access restricted to specified directories to contain damages resulting from break-in.","checkContent":"Verify the BIND 9.x process is not running as root:\n\n# ps -ef | grep named\n\nnamed 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot\n\nIf the owner of the process is root, this is a finding.","fixText":"Configure the BIND 9.x process to run as a nonprivileged user.\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272414","ruleId":"SV-272414r1123797_rule","severity":"medium","ruleTitle":"The BIND 9.x implementation must not use a TSIG or DNSSEC key for more than one year.","description":"Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the application, including the parameters required to satisfy other security control requirements.\n\nConfiguring the DNS server implementation to follow organizationwide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DOD that reflects the most restrictive security posture consistent with operational requirements.","checkContent":"With the assistance of the DNS administrator, identify all of the cryptographic key files used by the BIND 9.x implementation.\n\nWith the assistance of the DNS administrator, determine the location of the cryptographic key files used by the BIND 9.x implementation.\n\n# ls -al \n-rw-------. 1 named named 76 May 10 20:35 crypto-example.key\n\nIf the server is in a classified network, the DNSSEC portion of the requirement is Not Applicable.\n\nFor DNSSEC keys:\n\nVerify that the \"Created\" date is less than one year from the date of inspection:\n\nNote: The date format will be displayed in YYYYMMDDHHMMSS.\n\n# cat | grep -i \"created\"\nCreated: 20160704235959\n\nIf the \"Created\" date is more than one year old, this is a finding.\n\nFor TSIG keys:\n\nVerify with the information system security officer (ISSO)/information system security manager (ISSM) that the TSIG keys are less than one year old.\n\nIf a TSIG key is more than one year old, this is a finding.","fixText":"Generate new DNSSEC and TSIG keys.\n\nFor DNSSEC keys:\n\nUse the newly generated keys to resign all of the zone files on the name server.\n\nFor TSIG keys:\n\nUpdate the named.conf file with the new keys.\n\nRestart the BIND 9.x process.","ccis":["CCI-000366"]},{"vulnId":"V-272415","ruleId":"SV-272415r1156956_rule","severity":"medium","ruleTitle":"The permissions assigned to the core BIND 9.x server files must be set to use the least privilege possible.","description":"Discretionary Access Control (DAC) is based on the premise that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired because of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.","checkContent":"With the assistance of the DNS administrator, identify the following files:\n\nnamed.conf : rw-r----- \nroot hints : rw-r-----\nPrimary zone file(s): rw-rw----\nSecondary zone file(s): rw-rw----\n\nNote: The name of the root hints file is defined in named.conf. Common names for the file are root.hints, named.cache, or db.cache.\n\nVerify that the permissions for the core BIND 9.x server files are at least as restrictive as listed above. \n\nIf the identified files are not as least as restrictive as listed above, this is a finding.","fixText":"Configure the permissions of each file to the following:\n\nnamed.conf : rw-r----- \nroot hints : rw-r-----\nPrimary zone file(s): rw-rw----\nSecondary zone file(s): rw-rw----","ccis":["CCI-000366"]},{"vulnId":"V-272416","ruleId":"SV-272416r1156959_rule","severity":"medium","ruleTitle":"The host running a BIND 9.x implementation must implement a set of firewall rules that restrict traffic on the DNS interface.","description":"Configuring hosts that run a BIND 9.x implementation to only accept DNS traffic on a DNS interface allows a system firewall to be configured to limit the allowed incoming ports/protocols to 53/tcp and 53/udp. Sending outgoing DNS messages from a random port minimizes the risk of an attacker guessing the outgoing message port and sending forged replies.\n\nThe TCP/IP stack in DNS hosts (stub resolver, caching/resolving/recursive name server, authoritative name server, etc.) could be subjected to packet flooding attacks (such as SYNC and smurf), resulting in disruption of communication. By implementing a specific set of firewall rules that limit accepted traffic to the interface, these risk of packet flooding and other TCP/IP based attacks is reduced.","checkContent":"With the assistance of the DNS administrator, verify that the OS firewall is configured to only allow incoming messages on ports 53/tcp and 53/udp.\n\nNote: The following rules are for the IPTables firewall. If the system is using a different firewall, the rules may be different.\n\nInspect the hosts firewall rules for the following rules:\n\n-A INPUT -i [DNS Interface] -p tcp --dport 53 -j ACCEPT\n-A INPUT -i [DNS Interface] -p udp --dport 53 -j ACCEPT\n-A INPUT -i [DNS Interface] -j DROP\n\nIf any of the above rules do not exist, this is a finding.\n\nIf rules are listed that allow traffic on ports other than 53/tcp and 53/udp, this is a finding.","fixText":"Configure the OS firewall to only allow incoming DNS traffic on ports 53/tcp and 53/udp.\n\nAdd the following rules to the host firewall rule set:\n\n# iptables -A INPUT -i [DNS Interface] -p tcp --dport 53 -j ACCEPT\n# iptables -A INPUT -i [DNS Interface] -p udp --dport 53 -j ACCEPT\n# iptables -A INPUT -i [DNS Interface] -j DROP\n\nNote: If the system is not using an IPTables firewall, the appropriate firewall rules that limit traffic to ports 53/tcp and 53/udp must be configured on the active firewall.","ccis":["CCI-000366"]},{"vulnId":"V-272417","ruleId":"SV-272417r1156947_rule","severity":"high","ruleTitle":"A BIND 9.x server implementation must maintain the integrity and confidentiality of DNS information while it is being prepared for transmission, in transmission, and in use and must perform integrity verification and data origin verification for all DNS information.","description":"DNSSEC is required for securing the DNS query/response transaction by providing data origin authentication and data integrity verification through signature verification and the chain of trust.\n\nFailure to accomplish data origin authentication and data integrity verification could have significant effects on DNS infrastructure. The resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service.\n\nFailure to validate name server replies would cause many networking functions and communications to be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its subdomain, from the top of the DNS hierarchy down.\n\nFailure to validate the chain of trust used with DNSSEC would have a significant impact on the security posture of the DNS server. Nonvalidated trust chains may contain rouge DNS servers and allow those unauthorized servers to introduce invalid data into an organization's DNS infrastructure. A compromise of this type would be difficult to detect and may have devastating effects on the validity and integrity of DNS zone information.\n\nSatisfies: SRG-APP-000348-DNS-000042, SRG-APP-000420-DNS-000053, SRG-APP-000213-DNS-000024, SRG-APP-000219-DNS-000028, SRG-APP-000219-DNS-000029, SRG-APP-000219-DNS-000030, SRG-APP-000215-DNS-000026, SRG-APP-000347-DNS-000041, SRG-APP-000349-DNS-000043, SRG-APP-000441-DNS-000066, SRG-APP-000442-DNS-000067, SRG-APP-000422-DNS-000055, SRG-APP-000421-DNS-000054, SRG-APP-000423-DNS-000056, SRG-APP-000424-DNS-000057, SRG-APP-000425-DNS-000058, SRG-APP-000426-DNS-000059, SRG-APP-000251-DNS-000037","checkContent":"For a recursive server, verify that dnssec-validation yes is enabled.\n\nInspect the \"named.conf\" file for the following:\n\ndnssec-validation yes;\n\nIf \"dnssec-validation yes\" does not exist or is not set to \"yes\", this is a finding.\n\nFor an authoritative server, verify that each zone on the name server has been signed.\n\nIdentify each zone file for which the name server is responsible and search each file for the \"DNSKEY\" entries:\n\n# less \n86400 DNSKEY 257 3 8 ( HASHED_KEY ) ; KSK; alg = ECDSAP256SHA256; key id = 31225\n86400 DNSKEY 256 3 8 ( HASHED_KEY ) ; ZSK; alg = ECDSAP256SHA256; key id = 52179\n\nVerify that there are separate \"DNSKEY\" entries for the \"KSK\" and the \"ZSK\".\n\nIf the \"DNSKEY\" entries are missing, the zone file is not signed.\n\nIf the zone files are not signed, this is a finding.","fixText":"Set the \"dnssec-validation\" option to \"yes\".\n\nSign each zone file for which the name server is responsible.\n\nConfigure each zone for which the name server is responsible to use a DNSSEC signed zone.","ccis":["CCI-000366","CCI-001902","CCI-002463","CCI-001178","CCI-001184","CCI-001663","CCI-001901","CCI-001904","CCI-002420","CCI-002422","CCI-002462","CCI-002464","CCI-002465","CCI-002466","CCI-002467","CCI-002468","CCI-001310"]},{"vulnId":"V-272418","ruleId":"SV-272418r1156948_rule","severity":"medium","ruleTitle":"In the event of an error when validating the binding of other DNS servers' identity to the BIND 9.x information, when anomalies in the operation of the signed zone transfers are discovered, for the success and failure of start and stop of the name server service or daemon, and for the success and failure of all name server events, a BIND 9.x server implementation must generate a log entry.","description":"Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered to compile an accurate risk assessment. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis.\n\nThe DNS server must audit all failed attempts at server authentication through DNSSEC and TSIG. The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server.\n\nFailing to act on the validation errors may result in the use of invalid, corrupted, or compromised information. The validation of bindings can be achieved, for example, by the use of cryptographic checksums. Validations must be performed automatically.\n\nThe DNS server does not have the capability of shutting down or restarting the information system. The DNS server can be configured to generate audit records when anomalies are discovered.\n\nSatisfies: SRG-APP-000350-DNS-000044, SRG-APP-000089-DNS-000005, SRG-APP-000504-DNS-000074, SRG-APP-000504-DNS-000082, SRG-APP-000474-DNS-000073","checkContent":"Verify the name server is configured to log error messages with a severity of \"info\":\n\nInspect the \"named.conf\" file for the following:\n\nlogging {\nchannel channel_name {\nseverity info;\n};\n\nIf the \"severity\" sub-statement is not set to \"info\", this is a finding.\n\nNote: Setting the \"severity\" sub-statement to \"info\" will log all messages for the following severity levels: Critical, Error, Warning, Notice, and Info.","fixText":"Edit the \"named.conf\" file.\n\nAdd the \"severity\" sub-statement to the \"channel\" statement.\n\nConfigure the \"severity\" sub-statement to \"info\".\n\nRestart the BIND 9.x process.","ccis":["CCI-000366","CCI-001906","CCI-000169","CCI-000172","CCI-002702"]},{"vulnId":"V-272419","ruleId":"SV-272419r1123570_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must be configured to use only approved ports and protocols.","description":"To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.\n\nApplications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services); however, doing so increases risk over limiting the services provided by any one component.\n\nTo support the requirements and principles of least functionality, the application must support the organizational requirements by providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.","checkContent":"Verify the BIND 9.x server is configured to listen on UDP/TCP port 53.\n\nInspect the \"named.conf\" file for the following:\n\noptions {\nlisten-on port 53 { ; };\n};\n\nIf the \"port\" variable is missing, this is a finding.\n\nIf the \"port\" variable is not set to \"53\", this is a finding.\n\nNote: \"\" should be replaced with the DNS server IP address.","fixText":"Edit the \"named.conf\" file.\n\nAdd the following line to the \"options\" statement:\n\nlisten-on port 53 { ; };\n\nReplace \"\" with the IP of the name server.\n\nRestart the BIND 9.x process.","ccis":["CCI-000382"]},{"vulnId":"V-272421","ruleId":"SV-272421r1124019_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must use separate TSIG key-pairs when securing server-to-server transactions.","description":"Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. This applies to server-to-server (zone transfer) transactions only and is provided by TSIG/SIG(0), which enforces mutual server authentication using a key that is unique to each server pair (TSIG) or using PKI-based authentication (SIG[0]), thus uniquely identifying the other server.","checkContent":"Verify that the BIND 9.x server is configured to use separate TSIG key-pairs when securing server-to-server transactions.\n\nInspect the \"named.conf\" file for the presence of TSIG key statements:\n\nOn the primary name server, this is an example of a configured key statement:\n\nkey tsig_example. {\nalgorithm hmac-SHA256;\ninclude \"tsig-example.key\";\n};\n\nzone \"disa.mil\" {\ntype Primary;\nfile \"db.disa.mil\";\nallow-transfer { key tsig_example.; };\n};\n\nOn the secondary name server, this is an example of a configured key statement:\n\nkey tsig_example. {\nalgorithm hmac-SHA256;\ninclude \"tsig-example.key\";\n};\n\nserver {\nkeys { tsig_example };\n};\n\nzone \"disa.mil\" {\ntype Secondary;\nPrimarys { ; };\nfile \"db.disa.mil\";\n};\n\nVerify that each TSIG key-pair listed is only used by a single key statement:\n\n# cat \n\nIf any TSIG key-pair is being used by more than one key statement, this is a finding.","fixText":"Create a separate TSIG key-pair for each key statement listed in the named.conf file.\n\nConfigure the name server to use separate TSIG key-pairs for each key statement listed in the named.conf file.\n\nRestart the BIND 9.x process.","ccis":["CCI-000778"]},{"vulnId":"V-272422","ruleId":"SV-272422r1137672_rule","severity":"medium","ruleTitle":"A BIND 9.x server implementation must be running in a chroot(ed) directory structure.","description":"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, 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 itself or others. A more technical term is a chroot(ed) directory structure.\n\nBIND must be configured to run in a padded cell or chroot(ed) directory structure.","checkContent":"Verify that the directory structure where the primary BIND 9.x server configuration files are stored is running in a chroot(ed) environment or a containerized environment: \n\n# ps -ef | grep named\n\nnamed 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot\n\nIf the output does not contain \"-t \" and the named process is not running in a container, this is a finding.","fixText":"Configure the BIND 9.x server to operate in a chroot(ed) directory structure.","ccis":["CCI-001090"]},{"vulnId":"V-272423","ruleId":"SV-272423r1123940_rule","severity":"medium","ruleTitle":"A BIND 9.x implementation configured as a caching name server must restrict recursive queries to only the IP addresses and IP address ranges of known supported clients.","description":"Any host that can query a resolving name server has the potential to poison the server's 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.\n\nTo guard against poisoning, name servers authoritative for .mil domains must be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine: one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation.","checkContent":"This check is only applicable to caching name servers.\n\nVerify the allow-query and allow-recursion phrases are properly configured.\n\nInspect the \"named.conf\" file for the following:\n\nallow-query {trustworthy_hosts;};\nallow-recursion {trustworthy_hosts;};\n\nThe name of the ACL does not need to be \"trustworthy_hosts\", but the name must match the ACL name defined earlier in \"named.conf\" for this purpose. If not, this is a finding.\n\nVerify noninternal IP addresses do not appear in either the referenced ACL (e.g., trustworthy_hosts) or directly in the statements themselves.\n\nIf noninternal IP addresses appear, this is a finding.","fixText":"Configure the caching name server to accept recursive queries only from the IP addresses and address ranges of known supported clients.\n\nEdit the \"named.conf\" file and add the following to the options statement:\n\nallow-query {trustworthy_hosts;};\nallow-recursion {trustworthy_hosts;}; \n\nRestart the BIND 9.x process.","ccis":["CCI-001094"]},{"vulnId":"V-272424","ruleId":"SV-272424r1124066_rule","severity":"medium","ruleTitle":"A BIND 9.x server implementation must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of denial-of-service (DoS) attacks.","description":"A DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. \n\nA DoS attack against the DNS infrastructure has the potential to cause a DoS to all network users. As the DNS is a distributed backbone service of the internet, various forms of amplification attacks resulting in DoS, while using the DNS, are still prevalent on the internet today. Some potential DoS flooding attacks against the DNS include malformed packet flood, spoofed source addresses, and distributed DoS. Without the DNS, users and systems would not have the ability to perform simple name to IP resolution. \n\nConfiguring the DNS implementation to defend against cache poisoning, employing increased capacity and bandwidth, building redundancy into the DNS architecture, using DNSSEC, limiting and securing recursive services, DNS black holes, etc., may reduce the susceptibility to some flooding types of DoS attacks.","checkContent":"If this is a recursive name server, this is not applicable.\n\nExcessive, almost-identical UDP responses can be controlled by configuring a rate-limit clause in an options or view statement. This mechanism keeps authoritative BIND 9 from being used to amplify reflection denial-of-service (DoS) attacks.\n\nInspect the \"named.conf\" file for the following:\n\noptions {\n ...\n rate-limit {\n responses-per-second ;\n window ; \n };\n\nIf the rate-limit sub-statements are missing, this is a finding.","fixText":"Configure the authoritative name server to prohibit recursion.\n\nEdit the \"named.conf\" file and add the following sub-statements to the options statement:\n\noptions {\n rate-limit {\n responses-per-second ;\n window ; \n };\n\nRestart the BIND 9.x process.","ccis":["CCI-001095"]},{"vulnId":"V-272425","ruleId":"SV-272425r1123944_rule","severity":"medium","ruleTitle":"A BIND 9.x server must provide secure delegation to all child zones.","description":"If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its subdomain, from the top of the DNS hierarchy down.\n\nA DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to ensure the authenticity and integrity of response data.\n\nIn DNS, trust in the public key of the source is established by starting from a trusted name server and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent.\n\nA trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC.\n\nWhen there is a chain of trust, usually the top entity to be trusted becomes the trust anchor. A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate. In DNS, a trust anchor is a DNSKEY that is placed into a validating resolver so the validator can cryptographically validate the results for a given request back to a known public key (the trust anchor).\n\nAn example means to indicate the security status of child subspaces is using delegation signer (DS) resource records in the DNS.\n\nPath validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Without path validation and a chain of trust, there can be no trust that the data integrity authenticity has been maintained during a transaction.","checkContent":"Verify that there is a DS record set for each child zone defined in \"/etc/named.conf\" file.\n\nFor each child zone listed in \"/etc/named.conf\" file, verify there is a corresponding \"dsset-zone_name\" file.\n\nIf any child zone does not have a corresponding DS record set, this is a finding.","fixText":"Sign each child zone. During the zone signing process, ensure that a DS record is created and is stored on the parent zone name server.","ccis":["CCI-001179"]},{"vulnId":"V-272426","ruleId":"SV-272426r1124021_rule","severity":"medium","ruleTitle":"The BIND 9.x server validity period for the RRSIGs covering the DS RR for zones delegated children must be no less than two days and no more than one week.","description":"The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a zone-signing key (ZSK) can use that key only during the key signing key's (KSK's) signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing.\n\nTo prevent the impact of a compromised KSK, a delegating parent should set the signature validity period for RRSIGs covering DS RRs in the range of a few days to 1 week. This re-signing does not require frequent rollover of the parent's ZSK, but scheduled ZSK rollover should still be performed at regular intervals.","checkContent":"Note: This requirement does not validate the sig-validity-interval. This requirement ensures the signature validity period (i.e., the time from the signature's inception until the signature's expiration). It is recommended to ensure the Start of Authority (SOA) expire period (how long a secondary will still treat its copy of the zone data as valid if it cannot contact the primary) is configured to ensure the SOA does not expire during the period of signature inception and signature expiration.\n\nWith the assistance of the DNS administrator, identify the RRSIGs that cover the DS resource records for each child zone.\n\nEach record will list an expiration and inception date, the difference of which will provide the validity period.\n\nThe dates are listed in the following format:\n\nYYYYMMDDHHMMSS\n\nFor each RRSIG identified, verify that the validity period is no less than two days and no longer than seven days.\n\nIf the validity period is outside of the specified range, this is a finding.","fixText":"Resign the child zone files and have the zone administrator provide updated DS resource records for the child zone.","ccis":["CCI-001179"]},{"vulnId":"V-272427","ruleId":"SV-272427r1124022_rule","severity":"medium","ruleTitle":"Permissions assigned to the DNSSEC keys used with the BIND 9.x implementation must enforce read-only access to the key owner and deny access to all other users.","description":"Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and nonvolatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use.\n\nThe DNS server must protect the confidentiality and integrity of the DNSSEC keys and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.","checkContent":"Verify permissions assigned to the DNSSEC keys enforce read-only access to the key owner and deny access to group or system users.\n\nWith the assistance of the DNS administrator, determine the location of the DNSSEC keys used by the BIND 9.x implementation:\n\n# ls -al \n-r--------. 1 named named 76 May 10 20:35 DNSSEC-example.key\n\nIf the key files are more permissive than 400, this is a finding.","fixText":"Change the permissions of the DNSSEC key files:\n\n# chmod 400 ","ccis":["CCI-001199"]},{"vulnId":"V-272428","ruleId":"SV-272428r1123761_rule","severity":"medium","ruleTitle":"The DNSSEC keys used with the BIND 9.x implementation must be owned by a privileged account.","description":"Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and nonvolatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use.\n\nThe DNS server must protect the confidentiality and integrity of the DNSSEC keys and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.","checkContent":"With the assistance of the DNS administrator, identify all of the DNSSEC keys used by the BIND 9.x implementation.\n\nIdentify the account that the \"named\" process is running as:\n\n# ps -ef | grep named\nnamed 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot\n\nWith the assistance of the DNS administrator, determine the location of the DNSSEC keys used by the BIND 9.x implementation.\n\n# ls -al \n-r--------. 1 named named 76 May 10 20:35 DNSSEC-example.key\n\nIf any of the DNSSEC keys are not owned by the above account, this is a finding.","fixText":"Change the ownership of the DNSSEC keys to the named process it is running as.\n\n# chown .","ccis":["CCI-001199"]},{"vulnId":"V-272429","ruleId":"SV-272429r1123762_rule","severity":"medium","ruleTitle":"The DNSSEC keys used with the BIND 9.x implementation must be group owned by a privileged account.","description":"Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and nonvolatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use.\n\nThe DNS server must protect the confidentiality and integrity of the DNSSEC keys and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.","checkContent":"With the assistance of the DNS administrator, identify all of the DNSSEC keys used by the BIND 9.x implementation.\n\nIdentify the account that the \"named\" process is running as:\n\n# ps -ef | grep named\nnamed 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot\n\nWith the assistance of the DNS administrator, determine the location of the DNSSEC keys used by the BIND 9.x implementation.\n\n# ls -al \n-r--------. 1 named named 76 May 10 20:35 DNSSEC-example.key\n\nIf any of the DNSSEC keys are not group owned by the above account, this is a finding.","fixText":"Change the group ownership of the DNSSEC keys to the named process it is running as.\n\n# chgrp .","ccis":["CCI-001199"]},{"vulnId":"V-272430","ruleId":"SV-272430r1123947_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must maintain at least three file versions of the local log file.","description":"DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. Ensuring that the DNS transaction logs are recorded on the local system will provide the capability needed to support these actions.","checkContent":"Verify that the BIND 9.x server is configured to retain at least three versions of the local log file.\n\nInspect the \"named.conf\" file for the following:\n\nlogging {\nchannel local_file_channel {\nfile \"path_name\" versions 3;\nsize 10m;\n};\n\nIf the \"versions\" variable is not defined, this is a finding.\n\nIf the \"versions\" variable is configured to retain fewer than three versions of the local log file, this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nAdd the \"versions\" variable to the end of the \"file\" sub-statement in the channel statement.\n\nConfigure the \"versions\" sub-statement to a number that is greater than or equal to \"3\".\n\nRestart the BIND 9.x process.","ccis":["CCI-001348"]},{"vulnId":"V-272431","ruleId":"SV-272431r1123606_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must be configured with a channel to send audit records to a local file.","description":"DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. Ensuring that the DNS transaction logs are recorded on the local system will provide the capability needed to support these actions.","checkContent":"Verify that the BIND 9.x server is configured to send audit logs to a local log file.\n\nNote: syslog and local file channel must be defined for every defined category.\n\nInspect the \"named.conf\" file for the following:\n\nlogging {\nchannel local_file_channel {\nfile \"path_name\" versions 3;\nprint-time yes;\nprint-severity yes;\nprint-category yes;\n};\n\ncategory category_name { local_file_channel; };\n\nIf a logging channel is not defined for a local file, this is a finding.\n\nIf a category is not defined to send messages to the local file channel, this is a finding.","fixText":"Edit the \"named.conf\" file and add the following:\n\nlogging {\nchannel local_file_channel {\nfile \"path_name\" versions 3;\nprint-time yes;\nprint-severity yes;\nprint-category yes;\n};\ncategory category_name { local_file_channel; };\n};\n\nRestart the BIND 9.x process.","ccis":["CCI-001348"]},{"vulnId":"V-272432","ruleId":"SV-272432r1123950_rule","severity":"high","ruleTitle":"The BIND 9.x server implementation must be configured with a channel to send audit records to at least two remote syslogs.","description":"Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on a defined frequency helps to ensure, in the event of a catastrophic system failure, the audit records will be retained. \n\nThis helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records.","checkContent":"Verify that the BIND 9.x server is configured to send audit logs to at least two syslog servers.\n\nNote: syslog and local file channel must be defined for every defined category.\n\nInspect the \"named.conf\" file for the following:\n\nlogging {\nchannel {\nsyslog ;\n};\n\ncategory { ; };\n\nlogging {\nchannel {\nsyslog ;\n};\n\ncategory { ; };\n\nIf a logging channel is not defined for each syslog, this is a finding.\n\nIf a category is not defined to send messages to the syslog channels, this is a finding.","fixText":"Configure the \"logging\" statement to send audit logs to the syslog daemons.\n\nlogging {\nchannel {\nsyslog ;\n};\ncategory { ; };\n};\n\nlogging {\nchannel {\nsyslog ;\n};\ncategory { ; };\n};\n\nNote: It is recommended to use a local syslog facility (i.e., local0 -7) when configuring the syslog channel. \n\nRestart the BIND 9.x process.","ccis":["CCI-001348"]},{"vulnId":"V-272433","ruleId":"SV-272433r1123612_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must not be configured with a channel to send audit records to null.","description":"DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. Ensuring that the DNS transaction logs are recorded on the local system will provide the capability needed to support these actions. Sending DNS transaction data to the null channel would cause a loss of important data.","checkContent":"Verify that the BIND 9.x server is not configured to send audit logs to the null channel.\n\nInspect the \"named.conf\" file for the following:\n\ncategory null { null; }\n\nIf there is a category defined to send audit logs to the \"null\" channel, this is a finding.","fixText":"Edit the \"named.conf\" file.\n\nRemove any instance of the following:\n\ncategory null { null; };\n\nRestart the BIND 9.x process.","ccis":["CCI-001348"]},{"vulnId":"V-272435","ruleId":"SV-272435r1124068_rule","severity":"high","ruleTitle":"The BIND 9.x server implementation must uniquely identify and authenticate the other DNS server before responding to a server-to-server transaction, zone transfer, and/or dynamic update request using cryptographically based bidirectional authentication to protect the integrity of the information in transit.","description":"Server-to-server (zone transfer) transactions are provided by TSIG, which enforces mutual server authentication using a key that is unique to each server pair (TSIG), thus uniquely identifying the other server. DNS does perform server authentication when TSIG is used, but this authentication is transactional in nature (each transaction has its own authentication performed).\n\nEnforcing mutually authenticated communication sessions during zone transfers provides the assurance that only authorized servers are requesting and receiving DNS zone data. Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.\n\nFailure to properly implement transactional security may have significant effects on the overall security of the DNS infrastructure. The lack of mutual authentication between name servers during a DNS transaction would allow a threat actor to launch a Man-In-The-Middle attack against the DNS infrastructure. This attack could lead to unauthorized DNS zone data being introduced, resulting in network traffic being redirected to a rogue site.\n\nSatisfies: SRG-APP-000439-DNS-000063, SRG-APP-000394-DNS-000049, SRG-APP-000395-DNS-000050, SRG-APP-000440-DNS-000065","checkContent":"If zone transfers are disabled with the \"allow-transfer { none; };\" directive, this is not applicable.\n\nVerify that the BIND 9.x server is configured to uniquely identify a name server before responding to a zone transfer.\n\nInspect the \"named.conf\" file for the presence of TSIG key statements.\n\nOn the primary name server, this is an example of a configured key statement:\n\nkey tsig_example. {\nalgorithm hmac-SHA256;\ninclude \"tsig-example.key\";\n};\n\nzone \"disa.mil\" {\ntype Primary;\nfile \"db.disa.mil\";\nallow-transfer { key tsig_example.; };\n};\n\nOn the secondary name server, this is an example of a configured key statement:\n\nkey tsig_example. {\nalgorithm hmac-SHA256;\ninclude \"tsig-example.key\";\n};\n\nserver {\nkeys { tsig_example };\n};\n\nzone \"disa.mil\" {\ntype Secondary;\nPrimarys { ; };\nfile \"db.disa.mil\";\n};\n\nIf a primary name server does not have a key defined in the \"allow-transfer\" block, this is a finding.\n\nIf a secondary name server does not have a server statement that contains a \"keys\" sub-statement, this is a finding.","fixText":"Configure the BIND 9.x server to use TSIG keys.\n\nAdd a key statement to the \"named.conf\" file for TSIG that is being used:\n\nkey tsig_example. {\nalgorithm hmac-SHA256;\ninclude \"tsig-example.key\";\n};\n\nAdd key statements to the allow-transfer statements on a primary name server:\n\nallow-transfer { key tsig_example.; };\n\nAdd key statements to the server statements on a secondary name server:\n\nserver {\nkeys { tsig_example };\n};\n\nRestart the BIND 9.x process.","ccis":["CCI-002418","CCI-001958","CCI-001967","CCI-002421","CCI-000778"]},{"vulnId":"V-272436","ruleId":"SV-272436r1137676_rule","severity":"medium","ruleTitle":"A BIND 9.x server must implement NIST FIPS-validated cryptography for provisioning digital signatures and generating cryptographic hashes.","description":"Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.","checkContent":"Verify that the DNSSEC and TSIG keys used by the BIND 9.x implementation are FIPS compliant.\n\nIf the server is in a classified network, the DNSSEC portion of the requirement is Not Applicable.\n\nDNSSEC keys:\n\nInspect the \"named.conf\" file and identify all of the DNSSEC signed zone files:\n\nzone \"example.com\" {\nfile \"signed_zone_file\";\n};\n\nFor each signed zone file identified, inspect the file for the \"DNSKEY\" records: \n\n86400 DNSKEY 257 3 8 (\n\n) ; KSK; \n86400 DNSKEY 256 3 8 (\n\n) ; ZSK; \n\nThe fifth field in the above example identifies what algorithm was used to create the DNSKEY. \n\nIf the fifth field, if the KSK DNSKEY is less than \"8\" (SHA256), this is a finding.\n\nIf the algorithm used to create the ZSK is less than \"8\" (SHA256), this is a finding.\n\nTSIG keys: \n\nInspect the \"named.conf\" file and identify all of the TSIG key statements: \n\nkey tsig_example. {\nalgorithm hmac-SHA256;\ninclude \"tsig-example.key\";\n};\n\nIf each key statement does not use \"hmac-SHA256\" or a stronger algorithm, this is a finding.","fixText":"Create new DNSSEC and TSIG keys using a FIPS-approved cryptographic algorithm that meets or exceeds the strength of SHA-256.","ccis":["CCI-002450"]},{"vulnId":"V-275935","ruleId":"SV-275935r1124025_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must have QNAME minimization set to \"strict\".","description":"QNAME minimization limits the amount of information sent in DNS queries to intermediate nameservers, improving privacy by reducing the potential for DNS leak. It modifies the flow of DNS queries to reveal only what is necessary for the current server to find the next one in the resolution chain.","checkContent":"Verify QNAME minimization is set to \"strict\".\n\nInspect the named.conf file for the following:\n\noptions {\nqname-minimization strict;\n\nIf the qname minimization is not set to \"strict\", this is a finding.","fixText":"Edit the named.conf file \n\n options {\n \n qname-minimization strict; \n };\n\nAfter making changes, save the named.conf file and restart the BIND service to apply the changes.","ccis":["CCI-000366"]},{"vulnId":"V-275936","ruleId":"SV-275936r1156959_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must have fetches-per-zone enabled.","description":"The fetches-per-zone option in BIND 9.x is a configuration parameter that controls the maximum number of simultaneous iterative queries a recursive resolver can send to a single authoritative server for a specific domain. This helps protect authoritative servers from being overwhelmed by queries, especially during a denial-of-service (DoS) attack.","checkContent":"Verify fetches-per-zone is enabled with an organization-defined number. \n\nInspect the named.conf file for the following:\n\noptions {\nfetches-per-zone drop ;\n\nIf fetches-per-zone is not enabled and set to drop, this is a finding.","fixText":"Modify the BIND configuration file (/etc/named.conf ).\n\nAdd the fetches-per-zone option to the options section of the configuration file:\n \nfetches-per-zone drop; \n \nAfter making changes, reload or restart BIND to apply the new settings.","ccis":["CCI-000366"]},{"vulnId":"V-275937","ruleId":"SV-275937r1156959_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must have fetches-per-server enabled.","description":"The fetches-per-server option in BIND 9.x configures a limit on the number of outstanding requests (fetches) allowed for a single DNS server. This rate-limiting mechanism helps protect the BIND 9.x server from being overwhelmed by excessive requests to a specific server, particularly when that server is slow or unresponsive.","checkContent":"Verify fetches-per-server is enabled with an organization-defined number. \n\nInspect the named.conf file for the following:\n\noptions {\nfetches-per-server drop ;\n\nIf fetches-per-server is not enabled and set to drop, this is a finding.","fixText":"Modify the BIND configuration file (/etc/named.conf ).\n\nAdd the fetches-per-server option to the \"options\" section of the configuration file.\n\nfetches-per-server drop; \n \nAfter making changes, reload or restart BIND to apply the new settings.","ccis":["CCI-000366"]},{"vulnId":"V-275938","ruleId":"SV-275938r1156959_rule","severity":"medium","ruleTitle":"The host running a BIND 9.x implementation must have DNS cookies enabled.","description":"DNS cookies can help prevent spoofing and cache poisoning attacks by verifying the identity of both the client and server. They do this by including a cryptographic identifier (the cookie) in DNS messages, which can be verified in future messages. This makes it difficult for an attacker to learn the cookie values and thus spoof them.","checkContent":"Verify answer-cookie is enabled.\n\nInspect the named.conf file for the following:\n\noptions {\nanswer-cookie yes;\n\nIf answer-cookie is missing or set to \"no\", this is a finding.","fixText":"Edit the named.conf file:\n\n options {\n answer-cookie yes;\n };\n\nAfter making changes, save the named.conf file and restart the BIND service to apply the changes.","ccis":["CCI-000366"]},{"vulnId":"V-275939","ruleId":"SV-275939r1156959_rule","severity":"medium","ruleTitle":"The BIND 9.x server implementation must limit the number of allowed dynamic update clients.","description":"Limiting the number of concurrent sessions reduces the risk of denial of service (DoS) to the DNS implementation. \n\nName servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.\n\nPrimary name servers also make outbound connections to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to be made only to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the primary zone server and result in DoS to legitimate users. Primary name servers should be configured to limit the hosts from which they will accept dynamic updates.\n\nAdditionally, the number of concurrent clients, especially TCP clients, must be kept to a level that does not risk placing the system in a DoS state.","checkContent":"Verify the update-quota option is present and set to an organization defined limit. \n\nInspect the named.conf file for the following\n\noptions {\n ...\n update-quota ;\n ...\n};\n\nIf update-quota option is missing or limit not set, this is a finding.","fixText":"Edit the named.conf file\n\noptions {\n ...\n update-quota ;\n ...\n};\n\nAfter making changes, save the named.conf file and restart the BIND service to apply the changes.","ccis":["CCI-000054"]}]}