How do I forward DNS queries to private or internal domains?

To resolve private or internal domain names from inside CoreWeave Kubernetes Service (CKS) Pods, such as a corporate domain reachable over a VPC or Direct Connect, add a CoreDNS forward stanza through the CoreWeave-supported node-local-dns-overrides ConfigMap. You manage the ConfigMap, and CoreWeave manages the DNS components that read it.

When to use this

Use DNS forwarding when Pods need to resolve names that the cluster’s default resolvers don’t know, for example:

A corporate domain such as corp.example.com reachable over Direct Connect or a peered VPC.
An internal service domain hosted on resolvers in your own network.

If a name should already resolve and doesn’t, troubleshoot first with Troubleshoot DNS resolution from a Pod before adding a forward rule.

The node-local-dns-overrides ConfigMap

CKS reads custom DNS configuration from a ConfigMap named node-local-dns-overrides in the kube-system namespace. You add entries to its data field, and CoreDNS picks them up automatically. The ConfigMap accepts two kinds of entries, distinguished by the suffix of the key:

.server entries define a new CoreDNS server block (a zone). Use these to forward a specific domain to upstream resolvers.
.include entries merge directives into the main zone. Most forwarding use cases need only a .server entry.

Two rules govern entry names:

Every entry name must end in .server (or .include).
An entry must not be named placeholder.server or placeholder.include. Those names are reserved and are reconciled by the platform, so any custom content placed under them is silently reverted.

Forward a private domain to upstream resolvers

The following example forwards corp.example.com to two upstream resolvers. Replace the domain and the resolver addresses with your own.

node-local-dns-overrides.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: node-local-dns-overrides
  namespace: kube-system
data:
  # Entry name must end in .server and must not be placeholder.server
  corp-example-com.server: |
    corp.example.com:53 {
      errors
      loop
      bind 0.0.0.0
      forward . [UPSTREAM-RESOLVER-1] [UPSTREAM-RESOLVER-2]
    }

Replace [UPSTREAM-RESOLVER-1] and [UPSTREAM-RESOLVER-2] with the IP addresses of the resolvers that serve your private domain. List multiple upstreams on a single forward . line. To forward more than one domain, add another .server entry with a distinct key. Apply or edit the ConfigMap:

# Edit the override ConfigMap in place.
# Modifies cluster DNS config; review the change before saving.
kubectl edit configmap node-local-dns-overrides -n kube-system

CoreDNS reloads the new configuration automatically. You don’t need to restart any DaemonSet or Pod. To confirm the reload, read the node-local-dns logs as described in Read the node-local-dns logs.

Validate the forward rule

Test resolution from a Pod that uses cluster DNS (the default dnsPolicy: ClusterFirst):

# Resolve a name in the forwarded private domain from inside a Pod.
# Safe to run anytime; read-only.
kubectl exec [POD-NAME] -n [NAMESPACE] -- nslookup [HOST].corp.example.com

A successful answer confirms the forward stanza is active. If the name returns SERVFAIL, the forward zone is being used but the upstream resolver is unreachable: confirm the resolver addresses are reachable from the cluster (over VPC, Direct Connect, or the appropriate route). If the name returns NXDOMAIN, the forward zone may not match the queried domain, so recheck the zone name in the ConfigMap.

hostNetwork Pods

A Pod with hostNetwork: true doesn’t use cluster DNS by default, so the override doesn’t apply to it. Set dnsPolicy: ClusterFirstWithHostNet so the Pod resolves cluster Services and your forwarded domains. See hostNetwork Pods use the wrong resolver.

What this is not

Keep the following limits in mind:

This is not a way to override cluster-internal resolution. Don’t forward cluster.local or svc.cluster.local. Those zones are served by the cluster, and overriding them breaks Service discovery.
This is not configured by editing CoreDNS or node-local-dns directly. Those components are managed by CoreWeave. The node-local-dns-overrides ConfigMap is the supported customer interface.
The placeholder.server and placeholder.include entries are not examples to copy. They are reserved and reconciled by the platform.

When to open a ticket

Open a support ticket when:

A forward rule returns SERVFAIL and you have confirmed the upstream resolvers are reachable from the cluster.
You need to resolve a private domain whose resolvers are reachable only over a network path you haven’t yet established.

Include the ConfigMap entry, the domain, the upstream resolver addresses, and the nslookup output. For related symptoms, see Troubleshoot DNS resolution from a Pod and Troubleshoot networking. Administrator

​When to use this

​The node-local-dns-overrides ConfigMap

​Forward a private domain to upstream resolvers

​Validate the forward rule

​hostNetwork Pods

​What this is not

​When to open a ticket