Problem description

To address the requirements of certain compliance benchmarks (namely FedRAMP moderate and high), having appropriate means of securing the cluster's DNS records from spoofing is necessary. Namely, we need to ensure the authenticity and integrity of resource records provided by our DNS deployments.

Specifically, the NIST SP 800-53 control SC-21 required by the aforementioned benchmarks states the following:

The information system requests and performs data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources.

Supplemental Guidance: Each client of name resolution services either performs this validation on its own, or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching domain name system (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. Information systems that use technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. Related controls: SC-20, SC-22.

References: NIST Special Publication 800-81.

While cloud deployments do provide means of meeting these controls for externally facing records (e.g. Route53 now has DNSSEC support). We still need to address this for the internal DNS records that the platform uses.

A possible way to provide origin authentication of the returned DNS as well as data integrity of the returned DNS data is to add support for CoreDNS's DNSSEC plugin configuration via the cluster-dns-operator.

A possible way to provide origin authentication as well as providing privacy protection and data integrity of the DNS data in transport is to add support for CoreDNS's TLS plugin configuration and support for configuring forwarding over DNS over TLS using CoreDNS's forward plugin via the cluster-dns-operator.

What is the business impact, if any, if this request will not be made available?

Customers that need to comply with the aforementioned benchmarks will be affected in their compliance audits.

What are your expectations for this feature

Any cryptographic material (e.g. private keys) need to be stored with appropriate and secure permissions and any cryptographic algorithms need to work and be compliant in FIPS mode.