SC-8 Transaction Integrity

Text: The information system protects the integrity of transmitted information.

Who it applies to: Moderate and High level systems.

How it applies to DNS: This control covers DNS messaging such as zone transfers and dynamic updates. Following the recommendations in NIST SP800-81 on securing zone transfers and dynamic update using TSIG or SIG(0) would address this control with regards to the DNS. Using TSIG (or SIG(0)) allows for message authentication between a primary master server and secondary slave servers using as shared secret string and a one way hash function (or digital signature in the case of SIG(0)).

SC-20 Secure Name/Address Resolution Service (Authoritative Source)

Text: The information system that provides name/address resolution service provides additional data origin and integrity artifacts along with the authoritative data it returns in response to resolution queries.

Who it applies to: Low, Moderate and High level systems (i.e. All levels)

How it applies to DNS: Data origin and integrity artifact basically means RRSIG RRs and DNSKEY RRs, so a primary authoritative server serving a signed zone would meet this control. Note that servers should also be configured to send signed responses when receiving DNSSEC-enabled queries. NIST SP800-81 contains guidance for zone administrators for setting up and maintaining signed zones. For server implementations that do not fully understand DNSSEC (e.g. Windows Server 2003), simply being able to load the zone without failure may be sufficient. Current testing has proven that MS Windows Server 2003 can act as a secondary to a primary that serves a signed zone without problem (e.g. a BIND or NSD primary master with a signed zone can have a MS Windows 2003 secondary).

Currently, the control does not require the zone to have a signed delegation from its parent, nor have signed child delegations. It is encouraged however, but not required at this time. Future revisions off this control may make that a requirement.

SC-21 Secure Name/Address Resolution Service (Recursive or Caching Service)

Text: The information system that provides name/address resolution service for local clients performs data origin authentication and data integrity verification on the resolution responses it receives from authoritative sources when requested by client systems.

Who it applies to: High level systems, but may be pushed down to lower levels in future revisions.

How it applies to DNS: This control basically states that if a recursive caching server receives a query requesting recursion and DNSSEC processing, that server must attempt to perform validation on any DNSSEC enabled responses it receives and returning the appropriate response code (for DNSSEC, setting the Authenticated Data (AD) bit in the response header). This also means that the server administrator for these recursive caching servers maintain a trust anchor list for each server. There is no direct guidance on which public keys must be treated as trust anchors and it may be up to each organization's security policy as to which trust anchors should be maintained.

Note that to meet the minimum of the control, the server needs to only validate queries that request validation, however, most implementations treat validation as a on/off switch: Either all the incoming queries get validation or none of them are validated.

SC-22: Architecture and Provisioning for Name/Address Resolution Service

Text: The information systems that collectively provide name/address resolution service for an organization are fault tolerant and implement role separation.

Who it applies to: Moderate and High level systems, but may be pushed down in future revisions

How it applies to DNS: This control was designed to cover the current set of best common practices with regards to DNS server operation. This includes such things as maintaining secondaries for each zone, strict separation of authoritative and recursive caching roles (different servers for each role), restricting recursion for internal hosts via Access Control Lists (or similar methods), etc. NIST SP800-81 contains sections on best common practices for DNS server operation. There is an effort underway to provide SCAP content to automate this configuration and checklist auditing procedure.

Questions or comments should be sent to the SNIP admin

NIST is an agency of the U.S. Department of Commerce. Privacy policy / security notice / accessibility statement / Disclaimer / Freedom of Information Act (FOIA) / No Fear Act Data
Date created 6/2/2008. Last updated 08/02/2010.