Understanding the DNS Operator | Networking | Red Hat OpenShift Service on AWS

Using DNS forwarding

The DNS Operator deploys and manages CoreDNS to provide a name resolution service to pods, enabling DNS-based Kubernetes Service discovery in Red Hat OpenShift Service on AWS.

edit

Using DNS forwarding

You can use DNS forwarding to override the default forwarding configuration in the /etc/resolv.conf file in the following ways:

Specify name servers for every zone. If the forwarded zone is the Ingress domain managed by Red Hat OpenShift Service on AWS, then the upstream name server must be authorized for the domain.

You must specify at least one zone. Otherwise, your cluster can lose functionality.
Provide a list of upstream DNS servers.
Change the default forwarding policy.

A DNS forwarding configuration for the default domain can have both the default servers specified in the /etc/resolv.conf file and the upstream DNS servers.

Procedure

Modify the DNS Operator object named default:

$ oc edit dns.operator/default

After you issue the previous command, the Operator creates and updates the config map named dns-default with additional server configuration blocks based on Server.

When specifying values for the zones parameter, ensure that you only forward to specific zones, such as your intranet. You must specify at least one zone. Otherwise, your cluster can lose functionality.

If none of the servers have a zone that matches the query, then name resolution falls back to the upstream DNS servers.

Configuring DNS forwarding

apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  servers:
  - name: example-server (1)
    zones: (2)
    - example.com
    forwardPlugin:
      policy: Random (3)
      upstreams: (4)
      - 1.1.1.1
      - 2.2.2.2:5353
  upstreamResolvers: (5)
    policy: Random (6)
    upstreams: (7)
    - type: SystemResolvConf (8)
    - type: Network
      address: 1.2.3.4 (9)
      port: 53 (10)

1	Must comply with the `rfc6335` service name syntax.
2	Must conform to the definition of a subdomain in the `rfc1123` service name syntax. The cluster domain, `cluster.local`, is an invalid subdomain for the `zones` field.
3	Defines the policy to select upstream resolvers. Default value is `Random`. You can also use the values `RoundRobin`, and `Sequential`.
4	A maximum of 15 `upstreams` is allowed per `forwardPlugin`.
5	Optional. You can use it to override the default policy and forward DNS resolution to the specified DNS resolvers (upstream resolvers) for the default domain. If you do not provide any upstream resolvers, the DNS name queries go to the servers in `/etc/resolv.conf`.
6	Determines the order in which upstream servers are selected for querying. You can specify one of these values: `Random`, `RoundRobin`, or `Sequential`. The default value is `Sequential`.
7	Optional. You can use it to provide upstream resolvers.
8	You can specify two types of `upstreams` - `SystemResolvConf` and `Network`. `SystemResolvConf` configures the upstream to use `/etc/resolv.conf` and `Network` defines a `Networkresolver`. You can specify one or both.
9	If the specified type is `Network`, you must provide an IP address. The `address` field must be a valid IPv4 or IPv6 address.
10	If the specified type is `Network`, you can optionally provide a port. The `port` field must have a value between `1` and `65535`. If you do not specify a port for the upstream, by default port 853 is tried.

Optional: When working in a highly regulated environment, you might need the ability to secure DNS traffic when forwarding requests to upstream resolvers so that you can ensure additional DNS traffic and data privacy.

Cluster administrators can configure transport layer security (TLS) for forwarded DNS queries.

Configuring DNS forwarding with TLS

apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  servers:
  - name: example-server (1)
    zones: (2)
    - example.com
    forwardPlugin:
      transportConfig:
        transport: TLS (3)
        tls:
          caBundle:
            name: mycacert
          serverName: dnstls.example.com  (4)
      policy: Random (5)
      upstreams: (6)
      - 1.1.1.1
      - 2.2.2.2:5353
  upstreamResolvers: (7)
    transportConfig:
      transport: TLS
      tls:
        caBundle:
          name: mycacert
        serverName: dnstls.example.com
    upstreams:
    - type: Network (8)
      address: 1.2.3.4 (9)
      port: 53 (10)

1	Must comply with the `rfc6335` service name syntax.
2	Must conform to the definition of a subdomain in the `rfc1123` service name syntax. The cluster domain, `cluster.local`, is an invalid subdomain for the `zones` field. The cluster domain, `cluster.local`, is an invalid `subdomain` for `zones`.
3	When configuring TLS for forwarded DNS queries, set the `transport` field to have the value `TLS`. By default, CoreDNS caches forwarded connections for 10 seconds. CoreDNS will hold a TCP connection open for those 10 seconds if no request is issued. With large clusters, ensure that your DNS server is aware that it might get many new connections to hold open because you can initiate a connection per node. Set up your DNS hierarchy accordingly to avoid performance issues.
4	When configuring TLS for forwarded DNS queries, this is a mandatory server name used as part of the server name indication (SNI) to validate the upstream TLS server certificate.
5	Defines the policy to select upstream resolvers. Default value is `Random`. You can also use the values `RoundRobin`, and `Sequential`.
6	Required. You can use it to provide upstream resolvers. A maximum of 15 `upstreams` entries are allowed per `forwardPlugin` entry.
7	Optional. You can use it to override the default policy and forward DNS resolution to the specified DNS resolvers (upstream resolvers) for the default domain. If you do not provide any upstream resolvers, the DNS name queries go to the servers in `/etc/resolv.conf`.
8	`Network` type indicates that this upstream resolver should handle forwarded requests separately from the upstream resolvers listed in `/etc/resolv.conf`. Only the `Network` type is allowed when using TLS and you must provide an IP address.
9	The `address` field must be a valid IPv4 or IPv6 address.
10	You can optionally provide a port. The `port` must have a value between `1` and `65535`. If you do not specify a port for the upstream, by default port 853 is tried.

If servers is undefined or invalid, the config map only contains the default server.

Verification

View the config map:

$ oc get configmap/dns-default -n openshift-dns -o yaml

Sample DNS ConfigMap based on previous sample DNS

apiVersion: v1
data:
  Corefile: |
    example.com:5353 {
        forward . 1.1.1.1 2.2.2.2:5353
    }
    bar.com:5353 example.com:5353 {
        forward . 3.3.3.3 4.4.4.4:5454 (1)
    }
    .:5353 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            upstream
            fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . /etc/resolv.conf 1.2.3.4:53 {
            policy Random
        }
        cache 30
        reload
    }
kind: ConfigMap
metadata:
  labels:
    dns.operator.openshift.io/owning-dns: default
  name: dns-default
  namespace: openshift-dns

1	Changes to the `forwardPlugin` triggers a rolling update of the CoreDNS daemon set.

Additional resources

For more information on DNS forwarding, see the CoreDNS forward documentation.

DNS Operator in Red Hat OpenShift Service on AWS

Using DNS forwarding