Search filters this STIG's checks locally. Separate terms must all match (use quotes for an exact phrase). A search you ran on the Search page carries over here.
Assessment Title
Rule Text
Recursion must be disabled on Infoblox DNS service members that are configured as External Authoritative DNS service members.
Description
Discussion Text
External Authoritative DNS service members should *only* be providing External Authoritative and no other "DNS Service". Internal Authoritative servers commonly require that recursion is enabled in order to resolve DNS that is located on a different server (whether it's via forwarding, the Internet, STUB'ing, etc.)
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 to obtain sensitive data or passwords.
To 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 split DNS: internal name server and external name server.
The use of DNSSEC ensures 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 DoW, 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.
Since DNS forwarding of queries can be accomplished in some DNS applications without caching locally, DNS forwarding is the method to be use when providing external DNS resolution to internal clients.
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 to obtain sensitive data or passwords.
To 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 split DNS: internal name server and external name server.
The use of DNSSEC ensures 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 DoW, 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.
Since DNS forwarding of queries can be accomplished in some DNS applications without caching locally, DNS forwarding is the method to be use when providing external DNS resolution to internal clients.
New to STIG checklists? Read What is a STIG checklist? and CKL vs CKLB.