Custom DNS Forwarding Settings

Configuring Upstream DNS Servers for Kubernetes DNS

By default, Kublr imports the content of node /etc/resolv.conf to pod resolver configuration.
Using pod dnsPolicy paramerer, you can control precedence of node resolver settings and Kubernetes DNS service. See Pod’s DNS Policy for more information.

Sometimes, relying on host resolver settings is not convenient or not possible. In this case you need to set upstream name servers (so called DNS forwarders) for Kubernetes cluster-level DNS service.

In Kublr 1.11.2 and later you can set upstream DNS servers using custom cluster spec.

  1. Before starting the cluster creation, open the cluster specification by clicking the CUSTOMIZE SPECIFICATION button. Cluster spec editor opens.

  2. Add the appropriate block to spec yaml data, for example:

    spec:
      network:
        upstreamNameservers:
          - 8.8.8.8
          - 8.8.8.4
    
  3. Customize other spec parameters if necessary.

  4. Initiate cluster creation.

To verify that settings were applied successfully, check the logs of kubedns container in kube-dns… pod in kube-system namespace. Actual pod name is generated by Kubernetes and looks like hexadecimal hash value. Log can be accessed using Kubernetes Dashboard or kubectl commands:

# find kube-dns pod name
kubectl get pods -n kube-system | grep kube-dns
kubectl logs -n kube-system kube-dns[pod name] kubedns

Log must contain messages like:

Updated upstreamNameservers to [8.8.8.8, 8.8.8.4]
I0225 10:05:32.359143       1 dns.go:184] Configuration updated: {TypeMeta:{Kind: APIVersion:} Federations:map[] StubDomains:map[] UpstreamNameservers:[8.8.8.8, 8.8.8.4]}

Warning: Do not use addresses from 127.0.0.0/8 network for upstreamNameservers, because node local interface is not accessible to Kubernetes DNS pod.

Configuring Stub Domains

It is possible not only to forward all the requests to some external Upstream Nameservers but specify DNS servers for specific domains.

For example, we use the private address of some “service.example.com” service, which is also available publicly on the Internet. Our internal DNS server resolves a private address, but we need a public one. In this case, a possible example of a cluster spec would be:

spec:
  network:
    upstreamNameservers:
      - 172.22.22.22
    stubDomains:
      - dns: service.example.com
        servers:
          - 8.8.8.8
          - 8.8.8.4
      - dns: global
        servers:
          - 100.70.70.70

These configurations can be useful when organizing the interaction of services through VPN or simply for redefining the DNS server for a specific domain.

In the example above, service.example.com will resolve to 8.8.8.8, but the global zone is already on the Kubernetes service 100.70.70.70, all other names will resolve to 172.22.22.22.

Localdns Cache

You can enable/disable a localdns cache via a cluster specification. To do that, in cluster specification, under the “network” elemend, set “localdns” to “true” of “false”.

spec:
  # ...
  network:
    # ...
    # Local DNS cache properties
    enableLocalDns: true
    localDnsIP: '169.254.20.10'

See this example among other cluster network parameters here.

Changing Cluster Domain Name

To specify/change the name of domain for your cluster, in cluster specification, under the “network” elemend, set the “dnsDomain” element.

spec:
  # ...
  network:
    # ...
    # Cluster-local DNS domain used for this cluster
    dnsDomain: 'cluster.local'

See this example among other cluster network parameters here.