DNS [operator.openshift.io/v1] - Operator APIs | API reference

Description: DNS manages the CoreDNS component to provide a name resolution service for pods and services in the cluster. This supports the DNS-based service discovery specification: https://github.com/kubernetes/dns/blob/master/docs/specification.md More details: https://kubernetes.io/docs/tasks/administer-cluster/coredns Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
Type: object

Specification

Property Type Description

Property	Type	Description
`apiVersion`	`string`	APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
`kind`	`string`	Kind is a string value representing the ReST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
`metadata`	`ObjectMeta`	Standard object’s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
`spec`	`object`	spec is the specification of the desired behavior of the DNS.
`status`	`object`	status is the most recently observed status of the DNS.

apiVersion

string

APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

kind

string

Kind is a string value representing the ReST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

metadata

ObjectMeta

Standard object’s metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec

object

spec is the specification of the desired behavior of the DNS.

status

object

status is the most recently observed status of the DNS.

.spec

Description: spec is the specification of the desired behavior of the DNS.
Type: object

Property Type Description

Property	Type	Description
`cache`	`object`	cache describes the caching configuration that applies to all server blocks listed in the Corefile. This field allows a cluster admin to optionally configure: * positiveTTL which is a duration for which positive responses should be cached. * negativeTTL which is a duration for which negative responses should be cached. If this is not configured, OpenShift will configure positive and negative caching with a default value that is subject to change. At the time of writing, the default positiveTTL is 900 seconds and the default negativeTTL is 30 seconds or as noted in the respective Corefile for your version of OpenShift.
`logLevel`	`string`	logLevel describes the desired logging verbosity for CoreDNS. Any one of the following values may be specified: * Normal logs errors from upstream resolvers. * Debug logs errors, NXDOMAIN responses, and NODATA responses. * Trace logs errors and all responses. Setting logLevel: Trace will produce extremely verbose logs. Valid values are: "Normal", "Debug", "Trace". Defaults to "Normal".
`managementState`	`string`	managementState indicates whether the DNS operator should manage cluster DNS
`nodePlacement`	`object`	nodePlacement provides explicit control over the scheduling of DNS pods. Generally, it is useful to run a DNS pod on every node so that DNS queries are always handled by a local DNS pod instead of going over the network to a DNS pod on another node. However, security policies may require restricting the placement of DNS pods to specific nodes. For example, if a security policy prohibits pods on arbitrary nodes from communicating with the API, a node selector can be specified to restrict DNS pods to nodes that are permitted to communicate with the API. Conversely, if running DNS pods on nodes with a particular taint is desired, a toleration can be specified for that taint. If unset, defaults are used. See nodePlacement for more details.
`operatorLogLevel`	`string`	operatorLogLevel controls the logging level of the DNS Operator. Valid values are: "Normal", "Debug", "Trace". Defaults to "Normal". setting operatorLogLevel: Trace will produce extremely verbose logs.
`servers`	`array`	servers is a list of DNS resolvers that provide name query delegation for one or more subdomains outside the scope of the cluster domain. If servers consists of more than one Server, longest suffix match will be used to determine the Server. For example, if there are two Servers, one for "foo.com" and another for "a.foo.com", and the name query is for "www.a.foo.com", it will be routed to the Server with Zone "a.foo.com". If this field is nil, no servers are created.
`servers[]`	`object`	Server defines the schema for a server that runs per instance of CoreDNS.
`upstreamResolvers`	`object`	upstreamResolvers defines a schema for configuring CoreDNS to proxy DNS messages to upstream resolvers for the case of the default (".") server If this field is not specified, the upstream used will default to /etc/resolv.conf, with policy "sequential"

cache

object

cache describes the caching configuration that applies to all server blocks listed in the Corefile. This field allows a cluster admin to optionally configure: * positiveTTL which is a duration for which positive responses should be cached. * negativeTTL which is a duration for which negative responses should be cached. If this is not configured, OpenShift will configure positive and negative caching with a default value that is subject to change. At the time of writing, the default positiveTTL is 900 seconds and the default negativeTTL is 30 seconds or as noted in the respective Corefile for your version of OpenShift.

logLevel

string

logLevel describes the desired logging verbosity for CoreDNS. Any one of the following values may be specified: * Normal logs errors from upstream resolvers. * Debug logs errors, NXDOMAIN responses, and NODATA responses. * Trace logs errors and all responses. Setting logLevel: Trace will produce extremely verbose logs. Valid values are: "Normal", "Debug", "Trace". Defaults to "Normal".

managementState

string

managementState indicates whether the DNS operator should manage cluster DNS

nodePlacement

object

nodePlacement provides explicit control over the scheduling of DNS pods. Generally, it is useful to run a DNS pod on every node so that DNS queries are always handled by a local DNS pod instead of going over the network to a DNS pod on another node. However, security policies may require restricting the placement of DNS pods to specific nodes. For example, if a security policy prohibits pods on arbitrary nodes from communicating with the API, a node selector can be specified to restrict DNS pods to nodes that are permitted to communicate with the API. Conversely, if running DNS pods on nodes with a particular taint is desired, a toleration can be specified for that taint. If unset, defaults are used. See nodePlacement for more details.

operatorLogLevel

string

operatorLogLevel controls the logging level of the DNS Operator. Valid values are: "Normal", "Debug", "Trace". Defaults to "Normal". setting operatorLogLevel: Trace will produce extremely verbose logs.

servers

array

servers is a list of DNS resolvers that provide name query delegation for one or more subdomains outside the scope of the cluster domain. If servers consists of more than one Server, longest suffix match will be used to determine the Server. For example, if there are two Servers, one for "foo.com" and another for "a.foo.com", and the name query is for "www.a.foo.com", it will be routed to the Server with Zone "a.foo.com". If this field is nil, no servers are created.

servers[]

object

Server defines the schema for a server that runs per instance of CoreDNS.

upstreamResolvers

object

upstreamResolvers defines a schema for configuring CoreDNS to proxy DNS messages to upstream resolvers for the case of the default (".") server If this field is not specified, the upstream used will default to /etc/resolv.conf, with policy "sequential"

.spec.cache

Description: cache describes the caching configuration that applies to all server blocks listed in the Corefile. This field allows a cluster admin to optionally configure: * positiveTTL which is a duration for which positive responses should be cached. * negativeTTL which is a duration for which negative responses should be cached. If this is not configured, OpenShift will configure positive and negative caching with a default value that is subject to change. At the time of writing, the default positiveTTL is 900 seconds and the default negativeTTL is 30 seconds or as noted in the respective Corefile for your version of OpenShift.
Type: object

Property Type Description

Property	Type	Description
`negativeTTL`	`string`	negativeTTL is optional and specifies the amount of time that a negative response should be cached. If configured, it must be a value of 1s (1 second) or greater up to a theoretical maximum of several years. This field expects an unsigned duration string of decimal numbers, each with optional fraction and a unit suffix, e.g. "100s", "1m30s", "12h30m10s". Values that are fractions of a second are rounded down to the nearest second. If the configured value is less than 1s, the default value will be used. If not configured, the value will be 0s and OpenShift will use a default value of 30 seconds unless noted otherwise in the respective Corefile for your version of OpenShift. The default value of 30 seconds is subject to change.
`positiveTTL`	`string`	positiveTTL is optional and specifies the amount of time that a positive response should be cached. If configured, it must be a value of 1s (1 second) or greater up to a theoretical maximum of several years. This field expects an unsigned duration string of decimal numbers, each with optional fraction and a unit suffix, e.g. "100s", "1m30s", "12h30m10s". Values that are fractions of a second are rounded down to the nearest second. If the configured value is less than 1s, the default value will be used. If not configured, the value will be 0s and OpenShift will use a default value of 900 seconds unless noted otherwise in the respective Corefile for your version of OpenShift. The default value of 900 seconds is subject to change.

negativeTTL

string

negativeTTL is optional and specifies the amount of time that a negative response should be cached. If configured, it must be a value of 1s (1 second) or greater up to a theoretical maximum of several years. This field expects an unsigned duration string of decimal numbers, each with optional fraction and a unit suffix, e.g. "100s", "1m30s", "12h30m10s". Values that are fractions of a second are rounded down to the nearest second. If the configured value is less than 1s, the default value will be used. If not configured, the value will be 0s and OpenShift will use a default value of 30 seconds unless noted otherwise in the respective Corefile for your version of OpenShift. The default value of 30 seconds is subject to change.

positiveTTL

string

positiveTTL is optional and specifies the amount of time that a positive response should be cached. If configured, it must be a value of 1s (1 second) or greater up to a theoretical maximum of several years. This field expects an unsigned duration string of decimal numbers, each with optional fraction and a unit suffix, e.g. "100s", "1m30s", "12h30m10s". Values that are fractions of a second are rounded down to the nearest second. If the configured value is less than 1s, the default value will be used. If not configured, the value will be 0s and OpenShift will use a default value of 900 seconds unless noted otherwise in the respective Corefile for your version of OpenShift. The default value of 900 seconds is subject to change.

.spec.nodePlacement

Description: nodePlacement provides explicit control over the scheduling of DNS pods. Generally, it is useful to run a DNS pod on every node so that DNS queries are always handled by a local DNS pod instead of going over the network to a DNS pod on another node. However, security policies may require restricting the placement of DNS pods to specific nodes. For example, if a security policy prohibits pods on arbitrary nodes from communicating with the API, a node selector can be specified to restrict DNS pods to nodes that are permitted to communicate with the API. Conversely, if running DNS pods on nodes with a particular taint is desired, a toleration can be specified for that taint. If unset, defaults are used. See nodePlacement for more details.
Type: object

Property Type Description

Property	Type	Description
`nodeSelector`	`object (string)`	nodeSelector is the node selector applied to DNS pods. If empty, the default is used, which is currently the following: kubernetes.io/os: linux This default is subject to change. If set, the specified selector is used and replaces the default.
`tolerations`	`array`	tolerations is a list of tolerations applied to DNS pods. If empty, the DNS operator sets a toleration for the "node-role.kubernetes.io/master" taint. This default is subject to change. Specifying tolerations without including a toleration for the "node-role.kubernetes.io/master" taint may be risky as it could lead to an outage if all worker nodes become unavailable. Note that the daemon controller adds some tolerations as well. See https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
`tolerations[]`	`object`	The pod this Toleration is attached to tolerates any taint that matches the triple <key,value,effect> using the matching operator <operator>.

nodeSelector

object (string)

nodeSelector is the node selector applied to DNS pods. If empty, the default is used, which is currently the following: kubernetes.io/os: linux This default is subject to change. If set, the specified selector is used and replaces the default.

tolerations

array

tolerations is a list of tolerations applied to DNS pods. If empty, the DNS operator sets a toleration for the "node-role.kubernetes.io/master" taint. This default is subject to change. Specifying tolerations without including a toleration for the "node-role.kubernetes.io/master" taint may be risky as it could lead to an outage if all worker nodes become unavailable. Note that the daemon controller adds some tolerations as well. See https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/

tolerations[]

object

The pod this Toleration is attached to tolerates any taint that matches the triple <key,value,effect> using the matching operator <operator>.

.spec.nodePlacement.tolerations

Description: tolerations is a list of tolerations applied to DNS pods. If empty, the DNS operator sets a toleration for the "node-role.kubernetes.io/master" taint. This default is subject to change. Specifying tolerations without including a toleration for the "node-role.kubernetes.io/master" taint may be risky as it could lead to an outage if all worker nodes become unavailable. Note that the daemon controller adds some tolerations as well. See https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
Type: array

.spec.nodePlacement.tolerations[]

Description: The pod this Toleration is attached to tolerates any taint that matches the triple <key,value,effect> using the matching operator <operator>.
Type: object

Property Type Description

Property	Type	Description
`effect`	`string`	effect indicates the taint effect to match. empty means match all taint effects. When specified, allowed values are NoSchedule, PreferNoSchedule and Noexecute.
`key`	`string`	Key is the taint key that the toleration applies to. empty means match all taint keys. If the key is empty, operator must be exists; this combination means to match all values and all keys.
`operator`	`string`	Operator represents a key’s relationship to the value. Valid operators are exists and equal. Defaults to equal. exists is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category.
`tolerationSeconds`	`integer`	TolerationSeconds represents the period of time the toleration (which must be of effect Noexecute, otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately) by the system.
`value`	`string`	Value is the taint value the toleration matches to. If the operator is exists, the value should be empty, otherwise just a regular string.

effect

string

effect indicates the taint effect to match. empty means match all taint effects. When specified, allowed values are NoSchedule, PreferNoSchedule and Noexecute.

key

string

Key is the taint key that the toleration applies to. empty means match all taint keys. If the key is empty, operator must be exists; this combination means to match all values and all keys.

operator

string

Operator represents a key’s relationship to the value. Valid operators are exists and equal. Defaults to equal. exists is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category.

tolerationSeconds

integer

TolerationSeconds represents the period of time the toleration (which must be of effect Noexecute, otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately) by the system.

value

string

Value is the taint value the toleration matches to. If the operator is exists, the value should be empty, otherwise just a regular string.

.spec.servers

Description: servers is a list of DNS resolvers that provide name query delegation for one or more subdomains outside the scope of the cluster domain. If servers consists of more than one Server, longest suffix match will be used to determine the Server. For example, if there are two Servers, one for "foo.com" and another for "a.foo.com", and the name query is for "www.a.foo.com", it will be routed to the Server with Zone "a.foo.com". If this field is nil, no servers are created.
Type: array

.spec.servers[]

Description: Server defines the schema for a server that runs per instance of CoreDNS.
Type: object

Property Type Description

Property	Type	Description
`forwardPlugin`	`object`	forwardPlugin defines a schema for configuring CoreDNS to proxy DNS messages to upstream resolvers.
`name`	`string`	name is required and specifies a unique name for the server. Name must comply with the Service Name Syntax of rfc6335.
`zones`	`array (string)`	zones is required and specifies the subdomains that Server is authoritative for. Zones must conform to the rfc1123 definition of a subdomain. Specifying the cluster domain (i.e., "cluster.local") is invalid.

forwardPlugin

object

forwardPlugin defines a schema for configuring CoreDNS to proxy DNS messages to upstream resolvers.

name

string

name is required and specifies a unique name for the server. Name must comply with the Service Name Syntax of rfc6335.

zones

array (string)

zones is required and specifies the subdomains that Server is authoritative for. Zones must conform to the rfc1123 definition of a subdomain. Specifying the cluster domain (i.e., "cluster.local") is invalid.

.spec.servers[].forwardPlugin

Description: forwardPlugin defines a schema for configuring CoreDNS to proxy DNS messages to upstream resolvers.
Type: object

Property Type Description

Property	Type	Description
`policy`	`string`	policy is used to determine the order in which upstream servers are selected for querying. Any one of the following values may be specified: * "Random" picks a random upstream server for each query. * "RoundRobin" picks upstream servers in a round-robin order, moving to the next server for each new query. * "Sequential" tries querying upstream servers in a sequential order until one responds, starting with the first server for each new query. The default value is "Random"
`protocolStrategy`	`string`	protocolStrategy specifies the protocol to use for upstream DNS requests. Valid values for protocolStrategy are "TCP" and omitted. When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. The current default is to use the protocol of the original client request. "TCP" specifies that the platform should use TCP for all upstream DNS requests, even if the client request uses UDP. "TCP" is useful for UDP-specific issues such as those created by non-compliant upstream resolvers, but may consume more bandwidth or increase DNS response time. Note that protocolStrategy only affects the protocol of DNS requests that CoreDNS makes to upstream resolvers. It does not affect the protocol of DNS requests between clients and CoreDNS.
`transportConfig`	`object`	transportConfig is used to configure the transport type, server name, and optional custom CA or CA bundle to use when forwarding DNS requests to an upstream resolver. The default value is "" (empty) which results in a standard cleartext connection being used when forwarding DNS requests to an upstream resolver.
`upstreams`	`array (string)`	upstreams is a list of resolvers to forward name queries for subdomains of Zones. each instance of CoreDNS performs health checking of Upstreams. When a healthy upstream returns an error during the exchange, another resolver is tried from Upstreams. The Upstreams are selected in the order specified in Policy. each upstream is represented by an IP address or IP:port if the upstream listens on a port other than 53. A maximum of 15 upstreams is allowed per ForwardPlugin.

policy

string

policy is used to determine the order in which upstream servers are selected for querying. Any one of the following values may be specified: * "Random" picks a random upstream server for each query. * "RoundRobin" picks upstream servers in a round-robin order, moving to the next server for each new query. * "Sequential" tries querying upstream servers in a sequential order until one responds, starting with the first server for each new query. The default value is "Random"

protocolStrategy

string

protocolStrategy specifies the protocol to use for upstream DNS requests. Valid values for protocolStrategy are "TCP" and omitted. When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. The current default is to use the protocol of the original client request. "TCP" specifies that the platform should use TCP for all upstream DNS requests, even if the client request uses UDP. "TCP" is useful for UDP-specific issues such as those created by non-compliant upstream resolvers, but may consume more bandwidth or increase DNS response time. Note that protocolStrategy only affects the protocol of DNS requests that CoreDNS makes to upstream resolvers. It does not affect the protocol of DNS requests between clients and CoreDNS.

transportConfig

object

transportConfig is used to configure the transport type, server name, and optional custom CA or CA bundle to use when forwarding DNS requests to an upstream resolver. The default value is "" (empty) which results in a standard cleartext connection being used when forwarding DNS requests to an upstream resolver.

upstreams

array (string)

upstreams is a list of resolvers to forward name queries for subdomains of Zones. each instance of CoreDNS performs health checking of Upstreams. When a healthy upstream returns an error during the exchange, another resolver is tried from Upstreams. The Upstreams are selected in the order specified in Policy. each upstream is represented by an IP address or IP:port if the upstream listens on a port other than 53. A maximum of 15 upstreams is allowed per ForwardPlugin.

.spec.servers[].forwardPlugin.transportConfig

Description: transportConfig is used to configure the transport type, server name, and optional custom CA or CA bundle to use when forwarding DNS requests to an upstream resolver. The default value is "" (empty) which results in a standard cleartext connection being used when forwarding DNS requests to an upstream resolver.
Type: object

Property Type Description

Property	Type	Description
`tls`	`object`	tls contains the additional configuration options to use when Transport is set to "TLS".
`transport`	`string`	transport allows cluster administrators to opt-in to using a DNS-over-TLS connection between cluster DNS and an upstream resolver(s). Configuring TLS as the transport at this level without configuring a CABundle will result in the system certificates being used to verify the serving certificate of the upstream resolver(s). Possible values: "" (empty) - This means no explicit choice has been made and the platform chooses the default which is subject to change over time. The current default is "Cleartext". "Cleartext" - Cluster admin specified cleartext option. This results in the same functionality as an empty value but may be useful when a cluster admin wants to be more explicit about the transport, or wants to switch from "TLS" to "Cleartext" explicitly. "TLS" - This indicates that DNS queries should be sent over a TLS connection. If Transport is set to TLS, you MUST also set ServerName. If a port is not included with the upstream IP, port 853 will be tried by default per RFC 7858 section 3.1; https://datatracker.ietf.org/doc/html/rfc7858#section-3.1.

tls

object

tls contains the additional configuration options to use when Transport is set to "TLS".

transport

string

transport allows cluster administrators to opt-in to using a DNS-over-TLS connection between cluster DNS and an upstream resolver(s). Configuring TLS as the transport at this level without configuring a CABundle will result in the system certificates being used to verify the serving certificate of the upstream resolver(s). Possible values: "" (empty) - This means no explicit choice has been made and the platform chooses the default which is subject to change over time. The current default is "Cleartext". "Cleartext" - Cluster admin specified cleartext option. This results in the same functionality as an empty value but may be useful when a cluster admin wants to be more explicit about the transport, or wants to switch from "TLS" to "Cleartext" explicitly. "TLS" - This indicates that DNS queries should be sent over a TLS connection. If Transport is set to TLS, you MUST also set ServerName. If a port is not included with the upstream IP, port 853 will be tried by default per RFC 7858 section 3.1; https://datatracker.ietf.org/doc/html/rfc7858#section-3.1.

.spec.servers[].forwardPlugin.transportConfig.tls

Description

tls contains the additional configuration options to use when Transport is set to "TLS".

Type

object

Required

serverName

Property Type Description

Property	Type	Description
`caBundle`	`object`	caBundle references a ConfigMap that must contain either a single CA Certificate or a CA Bundle. This allows cluster administrators to provide their own CA or CA bundle for validating the certificate of upstream resolvers. 1. The configmap must contain a `ca-bundle.crt` key. 2. The value must be a PeM encoded CA certificate or CA bundle. 3. The administrator must create this configmap in the openshift-config namespace. 4. The upstream server certificate must contain a Subject Alternative Name (SAN) that matches ServerName.
`serverName`	`string`	serverName is the upstream server to connect to when forwarding DNS queries. This is required when Transport is set to "TLS". ServerName will be validated against the DNS naming conventions in RFC 1123 and should match the TLS certificate installed in the upstream resolver(s).

caBundle

object

caBundle references a ConfigMap that must contain either a single CA Certificate or a CA Bundle. This allows cluster administrators to provide their own CA or CA bundle for validating the certificate of upstream resolvers. 1. The configmap must contain a ca-bundle.crt key. 2. The value must be a PeM encoded CA certificate or CA bundle. 3. The administrator must create this configmap in the openshift-config namespace. 4. The upstream server certificate must contain a Subject Alternative Name (SAN) that matches ServerName.

serverName

string

serverName is the upstream server to connect to when forwarding DNS queries. This is required when Transport is set to "TLS". ServerName will be validated against the DNS naming conventions in RFC 1123 and should match the TLS certificate installed in the upstream resolver(s).

.spec.servers[].forwardPlugin.transportConfig.tls.caBundle

Description

Type

object

Required

name

Property Type Description

Property	Type	Description
`name`	`string`	name is the metadata.name of the referenced config map

name

string

name is the metadata.name of the referenced config map

.spec.upstreamResolvers

Description: upstreamResolvers defines a schema for configuring CoreDNS to proxy DNS messages to upstream resolvers for the case of the default (".") server If this field is not specified, the upstream used will default to /etc/resolv.conf, with policy "sequential"
Type: object

Property Type Description

Property	Type	Description
`policy`	`string`	Policy is used to determine the order in which upstream servers are selected for querying. Any one of the following values may be specified: * "Random" picks a random upstream server for each query. * "RoundRobin" picks upstream servers in a round-robin order, moving to the next server for each new query. * "Sequential" tries querying upstream servers in a sequential order until one responds, starting with the first server for each new query. The default value is "Sequential"
`protocolStrategy`	`string`	protocolStrategy specifies the protocol to use for upstream DNS requests. Valid values for protocolStrategy are "TCP" and omitted. When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. The current default is to use the protocol of the original client request. "TCP" specifies that the platform should use TCP for all upstream DNS requests, even if the client request uses UDP. "TCP" is useful for UDP-specific issues such as those created by non-compliant upstream resolvers, but may consume more bandwidth or increase DNS response time. Note that protocolStrategy only affects the protocol of DNS requests that CoreDNS makes to upstream resolvers. It does not affect the protocol of DNS requests between clients and CoreDNS.
`transportConfig`	`object`	transportConfig is used to configure the transport type, server name, and optional custom CA or CA bundle to use when forwarding DNS requests to an upstream resolver. The default value is "" (empty) which results in a standard cleartext connection being used when forwarding DNS requests to an upstream resolver.
`upstreams`	`array`	Upstreams is a list of resolvers to forward name queries for the "." domain. each instance of CoreDNS performs health checking of Upstreams. When a healthy upstream returns an error during the exchange, another resolver is tried from Upstreams. The Upstreams are selected in the order specified in Policy. A maximum of 15 upstreams is allowed per ForwardPlugin. If no Upstreams are specified, /etc/resolv.conf is used by default
`upstreams[]`	`object`	Upstream can either be of type SystemResolvConf, or of type Network. * For an Upstream of type SystemResolvConf, no further fields are necessary: The upstream will be configured to use /etc/resolv.conf. * For an Upstream of type Network, a NetworkResolver field needs to be defined with an IP address or IP:port if the upstream listens on a port other than 53.

policy

string

Policy is used to determine the order in which upstream servers are selected for querying. Any one of the following values may be specified: * "Random" picks a random upstream server for each query. * "RoundRobin" picks upstream servers in a round-robin order, moving to the next server for each new query. * "Sequential" tries querying upstream servers in a sequential order until one responds, starting with the first server for each new query. The default value is "Sequential"

protocolStrategy

string

transportConfig

object

upstreams

array

Upstreams is a list of resolvers to forward name queries for the "." domain. each instance of CoreDNS performs health checking of Upstreams. When a healthy upstream returns an error during the exchange, another resolver is tried from Upstreams. The Upstreams are selected in the order specified in Policy. A maximum of 15 upstreams is allowed per ForwardPlugin. If no Upstreams are specified, /etc/resolv.conf is used by default

upstreams[]

object

Upstream can either be of type SystemResolvConf, or of type Network. * For an Upstream of type SystemResolvConf, no further fields are necessary: The upstream will be configured to use /etc/resolv.conf. * For an Upstream of type Network, a NetworkResolver field needs to be defined with an IP address or IP:port if the upstream listens on a port other than 53.

.spec.upstreamResolvers.transportConfig

Description: transportConfig is used to configure the transport type, server name, and optional custom CA or CA bundle to use when forwarding DNS requests to an upstream resolver. The default value is "" (empty) which results in a standard cleartext connection being used when forwarding DNS requests to an upstream resolver.
Type: object

Property Type Description

Property	Type	Description
`tls`	`object`	tls contains the additional configuration options to use when Transport is set to "TLS".
`transport`	`string`	transport allows cluster administrators to opt-in to using a DNS-over-TLS connection between cluster DNS and an upstream resolver(s). Configuring TLS as the transport at this level without configuring a CABundle will result in the system certificates being used to verify the serving certificate of the upstream resolver(s). Possible values: "" (empty) - This means no explicit choice has been made and the platform chooses the default which is subject to change over time. The current default is "Cleartext". "Cleartext" - Cluster admin specified cleartext option. This results in the same functionality as an empty value but may be useful when a cluster admin wants to be more explicit about the transport, or wants to switch from "TLS" to "Cleartext" explicitly. "TLS" - This indicates that DNS queries should be sent over a TLS connection. If Transport is set to TLS, you MUST also set ServerName. If a port is not included with the upstream IP, port 853 will be tried by default per RFC 7858 section 3.1; https://datatracker.ietf.org/doc/html/rfc7858#section-3.1.

tls

object

tls contains the additional configuration options to use when Transport is set to "TLS".

transport

string

.spec.upstreamResolvers.transportConfig.tls

Description

tls contains the additional configuration options to use when Transport is set to "TLS".

Type

object

Required

serverName

Property Type Description

Property	Type	Description
`caBundle`	`object`	caBundle references a ConfigMap that must contain either a single CA Certificate or a CA Bundle. This allows cluster administrators to provide their own CA or CA bundle for validating the certificate of upstream resolvers. 1. The configmap must contain a `ca-bundle.crt` key. 2. The value must be a PeM encoded CA certificate or CA bundle. 3. The administrator must create this configmap in the openshift-config namespace. 4. The upstream server certificate must contain a Subject Alternative Name (SAN) that matches ServerName.
`serverName`	`string`	serverName is the upstream server to connect to when forwarding DNS queries. This is required when Transport is set to "TLS". ServerName will be validated against the DNS naming conventions in RFC 1123 and should match the TLS certificate installed in the upstream resolver(s).

caBundle

object

serverName

string

.spec.upstreamResolvers.transportConfig.tls.caBundle

Description

Type

object

Required

name

Property Type Description

Property	Type	Description
`name`	`string`	name is the metadata.name of the referenced config map

name

string

name is the metadata.name of the referenced config map

.spec.upstreamResolvers.upstreams

Description: Upstreams is a list of resolvers to forward name queries for the "." domain. each instance of CoreDNS performs health checking of Upstreams. When a healthy upstream returns an error during the exchange, another resolver is tried from Upstreams. The Upstreams are selected in the order specified in Policy. A maximum of 15 upstreams is allowed per ForwardPlugin. If no Upstreams are specified, /etc/resolv.conf is used by default
Type: array

.spec.upstreamResolvers.upstreams[]

Description

Type

object

Required

type

Property Type Description

Property	Type	Description
`address`	`string`	Address must be defined when Type is set to Network. It will be ignored otherwise. It must be a valid ipv4 or ipv6 address.
`port`	`integer`	Port may be defined when Type is set to Network. It will be ignored otherwise. Port must be between 65535
`type`	`string`	Type defines whether this upstream contains an IP/IP:port resolver or the local /etc/resolv.conf. Type accepts 2 possible values: SystemResolvConf or Network. * When SystemResolvConf is used, the Upstream structure does not require any further fields to be defined: /etc/resolv.conf will be used * When Network is used, the Upstream structure must contain at least an Address

address

string

Address must be defined when Type is set to Network. It will be ignored otherwise. It must be a valid ipv4 or ipv6 address.

port

integer

Port may be defined when Type is set to Network. It will be ignored otherwise. Port must be between 65535

type

string

Type defines whether this upstream contains an IP/IP:port resolver or the local /etc/resolv.conf. Type accepts 2 possible values: SystemResolvConf or Network. * When SystemResolvConf is used, the Upstream structure does not require any further fields to be defined: /etc/resolv.conf will be used * When Network is used, the Upstream structure must contain at least an Address

.status

Description

status is the most recently observed status of the DNS.

Type

object

Required

clusterDomain
clusterIP

Property Type Description

Property	Type	Description
`clusterDomain`	`string`	clusterDomain is the local cluster DNS domain suffix for DNS services. This will be a subdomain as defined in RFC 1034, section 3.5: https://tools.ietf.org/html/rfc1034#section-3.5 example: "cluster.local" More info: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service
`clusterIP`	`string`	clusterIP is the service IP through which this DNS is made available. In the case of the default DNS, this will be a well known IP that is used as the default nameserver for pods that are using the default ClusterFirst DNS policy. In general, this IP can be specified in a pod’s spec.dnsConfig.nameservers list or used explicitly when performing name resolution from within the cluster. example: dig foo.com @<service IP> More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
`conditions`	`array`	conditions provide information about the state of the DNS on the cluster. These are the supported DNS conditions: * Available - True if the following conditions are met: * DNS controller daemonset is available. - False if any of those conditions are unsatisfied.
`conditions[]`	`object`	OperatorCondition is just the standard condition fields.

clusterDomain

string

clusterDomain is the local cluster DNS domain suffix for DNS services. This will be a subdomain as defined in RFC 1034, section 3.5: https://tools.ietf.org/html/rfc1034#section-3.5 example: "cluster.local" More info: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service

clusterIP

string

clusterIP is the service IP through which this DNS is made available. In the case of the default DNS, this will be a well known IP that is used as the default nameserver for pods that are using the default ClusterFirst DNS policy. In general, this IP can be specified in a pod’s spec.dnsConfig.nameservers list or used explicitly when performing name resolution from within the cluster. example: dig foo.com @<service IP> More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

conditions

array

conditions provide information about the state of the DNS on the cluster. These are the supported DNS conditions: * Available - True if the following conditions are met: * DNS controller daemonset is available. - False if any of those conditions are unsatisfied.

conditions[]

object

OperatorCondition is just the standard condition fields.

.status.conditions

Description: conditions provide information about the state of the DNS on the cluster. These are the supported DNS conditions: * Available - True if the following conditions are met: * DNS controller daemonset is available. - False if any of those conditions are unsatisfied.
Type: array

.status.conditions[]

Description: OperatorCondition is just the standard condition fields.
Type: object

Property Type Description

Property	Type	Description
`lastTransitionTime`	`string`
`message`	`string`
`reason`	`string`
`status`	`string`
`type`	`string`

lastTransitionTime

string

message

string

reason

string

status

string

type

string

API endpoints

The following API endpoints are available:

/apis/operator.openshift.io/v1/dnses
- DeLeTe: delete collection of DNS
- GeT: list objects of kind DNS
- POST: create a DNS
/apis/operator.openshift.io/v1/dnses/{name}
- DeLeTe: delete a DNS
- GeT: read the specified DNS
- PATCH: partially update the specified DNS
- PUT: replace the specified DNS
/apis/operator.openshift.io/v1/dnses/{name}/status
- GeT: read status of the specified DNS
- PATCH: partially update status of the specified DNS
- PUT: replace status of the specified DNS

/apis/operator.openshift.io/v1/dnses

Table 1. Global query parameters
Parameter	Type	Description
`pretty`	`string`	If 'true', then the output is pretty printed.

HTTP method: DeLeTe
Description: delete collection of DNS

Table 2. Query parameters
Parameter	Type	Description
`allowWatchBookmarks`	`boolean`	allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server’s discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored.
`continue`	`string`	The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 Resourceexpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key". This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.
`fieldSelector`	`string`	A selector to restrict the list of returned objects by their fields. Defaults to everything.
`labelSelector`	`string`	A selector to restrict the list of returned objects by their labels. Defaults to everything.
`limit`	`integer`	limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true. The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.
`resourceVersion`	`string`	resourceVersion sets a constraint on what resource versions a request may be served from. See https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions for details. Defaults to unset
`resourceVersionMatch`	`string`	resourceVersionMatch determines how resourceVersion is applied to list calls. It is highly recommended that resourceVersionMatch be set for list calls where resourceVersion is set See https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions for details. Defaults to unset
`timeoutSeconds`	`integer`	Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.
`watch`	`boolean`	Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.

Table 3. HTTP responses
HTTP code	Reponse body
200 - OK	`Status` schema
401 - Unauthorized	empty

HTTP method: GeT
Description: list objects of kind DNS

Table 4. Query parameters
Parameter	Type	Description
`allowWatchBookmarks`	`boolean`	allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server’s discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored.
`continue`	`string`	The continue option should be set when retrieving more results from the server. Since this value is server defined, clients may only use the continue value from a previous query result with identical query parameters (except for the value of continue) and the server may reject a continue value it does not recognize. If the specified continue value is no longer valid whether due to expiration (generally five to fifteen minutes) or a configuration change on the server, the server will respond with a 410 Resourceexpired error together with a continue token. If the client needs a consistent list, it must restart their list without the continue field. Otherwise, the client may send another list request with the token received with the 410 error, the server will respond with a list starting from the next key, but from the latest snapshot, which is inconsistent from the previous list results - objects that are created, modified, or deleted after the first list request will be included in the response, as long as their keys are after the "next key". This field is not supported when watch is true. Clients may start a watch from the last resourceVersion value returned by the server and not miss any modifications.
`fieldSelector`	`string`	A selector to restrict the list of returned objects by their fields. Defaults to everything.
`labelSelector`	`string`	A selector to restrict the list of returned objects by their labels. Defaults to everything.
`limit`	`integer`	limit is a maximum number of responses to return for a list call. If more items exist, the server will set the `continue` field on the list metadata to a value that can be used with the same initial query to retrieve the next set of results. Setting a limit may return fewer than the requested amount of items (up to zero items) in the event all requested objects are filtered out and clients should only use the presence of the continue field to determine whether more results are available. Servers may choose not to support the limit argument and will return all of the available results. If limit is specified and the continue field is empty, clients may assume that no more results are available. This field is not supported if watch is true. The server guarantees that the objects returned when using continue will be identical to issuing a single list call without a limit - that is, no objects created, modified, or deleted after the first request is issued will be included in any subsequent continued requests. This is sometimes referred to as a consistent snapshot, and ensures that a client that is using limit to receive smaller chunks of a very large result can ensure they see all possible objects. If objects are updated during a chunked list the version of the object that was present at the time the first list result was calculated is returned.
`resourceVersion`	`string`	resourceVersion sets a constraint on what resource versions a request may be served from. See https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions for details. Defaults to unset
`resourceVersionMatch`	`string`	resourceVersionMatch determines how resourceVersion is applied to list calls. It is highly recommended that resourceVersionMatch be set for list calls where resourceVersion is set See https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions for details. Defaults to unset
`timeoutSeconds`	`integer`	Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.
`watch`	`boolean`	Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.

Table 5. HTTP responses
HTTP code	Reponse body
200 - OK	`DNSList` schema
401 - Unauthorized	empty

HTTP method: POST
Description: create a DNS

Table 6. Query parameters
Parameter	Type	Description
`dryRun`	`string`	When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
`fieldManager`	`string`	fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.
`fieldValidation`	`string`	fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields, provided that the `ServerSideFieldValidation` feature gate is also enabled. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23 and is the default behavior when the `ServerSideFieldValidation` feature gate is disabled. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default when the `ServerSideFieldValidation` feature gate is enabled. - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.

Table 7. Body parameters
Parameter	Type	Description
`body`	`DNS` schema

Table 8. HTTP responses
HTTP code	Reponse body
200 - OK	`DNS` schema
201 - Created	`DNS` schema
202 - Accepted	`DNS` schema
401 - Unauthorized	empty

/apis/operator.openshift.io/v1/dnses/{name}

Table 9. Global path parameters
Parameter	Type	Description
`name`	`string`	name of the DNS

Table 10. Global query parameters
Parameter	Type	Description
`pretty`	`string`	If 'true', then the output is pretty printed.

HTTP method: DeLeTe
Description: delete a DNS

Table 11. Query parameters
Parameter	Type	Description
`dryRun`	`string`	When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
`gracePeriodSeconds`	`integer`	The duration in seconds before the object should be deleted. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period for the specified type will be used. Defaults to a per object value if not specified. zero means delete immediately.
`orphanDependents`	`boolean`	Deprecated: please use the PropagationPolicy, this field will be deprecated in 1.7. Should the dependent objects be orphaned. If true/false, the "orphan" finalizer will be added to/removed from the object’s finalizers list. either this field or PropagationPolicy may be set, but not both.
`propagationPolicy`	`string`	Whether and how garbage collection will be performed. either this field or OrphanDependents may be set, but not both. The default policy is decided by the existing finalizer set in the metadata.finalizers and the resource-specific default policy. Acceptable values are: 'Orphan' - orphan the dependents; 'Background' - allow the garbage collector to delete the dependents in the background; 'Foreground' - a cascading policy that deletes all dependents in the foreground.

Table 12. Body parameters
Parameter	Type	Description
`body`	`DeleteOptions` schema

Table 13. HTTP responses
HTTP code	Reponse body
200 - OK	`Status` schema
202 - Accepted	`Status` schema
401 - Unauthorized	empty

HTTP method: GeT
Description: read the specified DNS

Table 14. Query parameters
Parameter	Type	Description
`resourceVersion`	`string`	resourceVersion sets a constraint on what resource versions a request may be served from. See https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions for details. Defaults to unset

Table 15. HTTP responses
HTTP code	Reponse body
200 - OK	`DNS` schema
401 - Unauthorized	empty

HTTP method: PATCH
Description: partially update the specified DNS

Table 16. Query parameters
Parameter	Type	Description
`dryRun`	`string`	When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
`fieldManager`	`string`	fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.
`fieldValidation`	`string`	fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields, provided that the `ServerSideFieldValidation` feature gate is also enabled. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23 and is the default behavior when the `ServerSideFieldValidation` feature gate is disabled. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default when the `ServerSideFieldValidation` feature gate is enabled. - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.

Table 17. Body parameters
Parameter	Type	Description
`body`	`Patch` schema

Table 18. HTTP responses
HTTP code	Reponse body
200 - OK	`DNS` schema
401 - Unauthorized	empty

HTTP method: PUT
Description: replace the specified DNS

Table 19. Query parameters
Parameter	Type	Description
`dryRun`	`string`	When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
`fieldManager`	`string`	fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.
`fieldValidation`	`string`	fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields, provided that the `ServerSideFieldValidation` feature gate is also enabled. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23 and is the default behavior when the `ServerSideFieldValidation` feature gate is disabled. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default when the `ServerSideFieldValidation` feature gate is enabled. - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.

Table 20. Body parameters
Parameter	Type	Description
`body`	`DNS` schema

Table 21. HTTP responses
HTTP code	Reponse body
200 - OK	`DNS` schema
201 - Created	`DNS` schema
401 - Unauthorized	empty

/apis/operator.openshift.io/v1/dnses/{name}/status

Table 22. Global path parameters
Parameter	Type	Description
`name`	`string`	name of the DNS

Table 23. Global query parameters
Parameter	Type	Description
`pretty`	`string`	If 'true', then the output is pretty printed.

HTTP method: GeT
Description: read status of the specified DNS

Table 24. Query parameters
Parameter	Type	Description
`resourceVersion`	`string`	resourceVersion sets a constraint on what resource versions a request may be served from. See https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions for details. Defaults to unset

Table 25. HTTP responses
HTTP code	Reponse body
200 - OK	`DNS` schema
401 - Unauthorized	empty

HTTP method: PATCH
Description: partially update status of the specified DNS

Table 26. Query parameters
Parameter	Type	Description
`dryRun`	`string`	When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
`fieldManager`	`string`	fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.
`fieldValidation`	`string`	fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields, provided that the `ServerSideFieldValidation` feature gate is also enabled. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23 and is the default behavior when the `ServerSideFieldValidation` feature gate is disabled. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default when the `ServerSideFieldValidation` feature gate is enabled. - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.

Table 27. Body parameters
Parameter	Type	Description
`body`	`Patch` schema

Table 28. HTTP responses
HTTP code	Reponse body
200 - OK	`DNS` schema
401 - Unauthorized	empty

HTTP method: PUT
Description: replace status of the specified DNS

Table 29. Query parameters
Parameter	Type	Description
`dryRun`	`string`	When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
`fieldManager`	`string`	fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.
`fieldValidation`	`string`	fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields, provided that the `ServerSideFieldValidation` feature gate is also enabled. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23 and is the default behavior when the `ServerSideFieldValidation` feature gate is disabled. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default when the `ServerSideFieldValidation` feature gate is enabled. - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.

Table 30. Body parameters
Parameter	Type	Description
`body`	`DNS` schema

Table 31. HTTP responses
HTTP code	Reponse body
200 - OK	`DNS` schema
201 - Created	`DNS` schema
401 - Unauthorized	empty