> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/products/networking/direct-connect/about-direct-connect) or a peered [VPC](/products/networking/vpc/about-vpcs).
* 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](/support/networking/articles/why-is-dns-resolution-failing-from-my-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.

```yaml title="node-local-dns-overrides.yaml" theme={"system"}
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:

```bash theme={"system"}
# 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](/support/networking/articles/why-is-dns-resolution-failing-from-my-pod#read-the-node-local-dns-logs).

## Validate the forward rule

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

```bash theme={"system"}
# 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](/support/networking/articles/why-is-dns-resolution-failing-from-my-pod#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](/support/networking/articles/why-is-dns-resolution-failing-from-my-pod) and [Troubleshoot networking](/support/networking).

<Badge stroke shape="pill" color="blue" size="md">[Administrator](/support/networking/tags/administrator)</Badge>