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

# Resolve internal (on-premise) DNS Server in AWS EKS via CoreDNS

> Configure CoreDNS on AWS EKS and Domino environments to resolve on-premise DNS hostnames from Domino Workspaces via a VPN tunnel.

# Resolve internal (on-premise) DNS server in AWS EKS via CoreDNS

Domino users often need to access on-premise services from their Domino workspace. This article explains how to configure Amazon Web Services (AWS) Elastic Kubernetes Service (EKS) CoreDNS to forward DNS queries to an on-premise DNS server, then update a Domino environment to resolve the corresponding search domain.

This configuration assumes you have already established a VPN tunnel or equivalent network connectivity between AWS and your on-premise network.

## Prerequisites

* CoreDNS running on your EKS cluster (default since EKS v1.12). If CoreDNS isn't installed, follow the [AWS CoreDNS documentation](https://docs.aws.amazon.com/eks/latest/userguide/coredns.html) to install it.
* `kubectl` access to the EKS cluster running your Domino deployment. Update your local kubeconfig or connect directly in AWS before proceeding.

## Update the CoreDNS configmap

1. Open the CoreDNS configmap for editing:

   ```
   kubectl -n kube-system edit configmap coredns
   ```
2. Locate the `Corefile` section. It looks similar to this:

   ```
   Corefile: |
     .:53 {
       log
       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
       cache 30
       loop
       reload
       loadbalance
     }
   ```
3. Add a new forwarding block after the closing `}` of the existing stanza. Replace `google.com` with your on-premise domain and `8.8.8.8` with the IP address of your DNS server (for example, the load balancer IP for your VPN tunnel). Keep the period (`.`) between `forward` and the IP address.

   The updated `Corefile` section should look like this:

   ```
   Corefile: |
     .:53 {
       log
       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
       cache 30
       loop
       reload
       loadbalance
     }
     google.com:53 {
      forward . 8.8.8.8
     }
   ```
4. Save the file. The editor displays a confirmation message when the configmap saves successfully.
5. Restart the CoreDNS pods to apply the change immediately:

   ```
   kubectl get pods -n kube-system -oname |grep coredns |xargs kubectl delete -n kube-system
   ```
6. Verify that the CoreDNS pods return to a **Running** status:

   ```
   kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
   ```

   All listed pods should show `Running` in the **STATUS** column before you proceed.

## Configure the Domino environment

Add a pre-setup script to the Domino environment. This script appends the search domain to `/etc/resolv.conf` inside each workspace container.

1. In Domino, navigate to **Environments** and select the environment you want to update.
2. Click **Edit Definition**.
3. Scroll down and expand the **Advanced** section.
4. Enter the following script in the **Pre Setup Script** field, replacing `google.com` with your on-premise domain:

   ```
   cat /etc/resolv.conf >> /tmp/resolv.conf.tmp
   sed -i '2s/$/ google.com/' /tmp/resolv.conf.tmp
   cat /tmp/resolv.conf.tmp > /etc/resolv.conf
   ```
5. Save and build the environment.

## Verify DNS resolution

1. Start a new Jupyter workspace and open a terminal.
2. Run an `nslookup` for a hostname in your domain. Using the Google example:

   ```
   nslookup maps
   ```
3. Confirm that the output resolves the short hostname to a fully qualified domain name (FQDN). Expected output:

   ```
   ubuntu@run-5ea9d22e84e7430006080fdb-7bfkr:/mnt$ nslookup maps
   Server:     10.100.0.10
   Address:    10.100.0.10#53

   Non-authoritative answer:
   Name:  maps.google.com
   Address: 172.217.14.206
   Name:  maps.google.com
   Address: 2607:f8b0:400a:808::200e
   ```

   Successful output shows the short name resolving to the FQDN (for example, `maps` → `maps.google.com`), confirming that on-premise DNS resolution is working


## Related topics

- [How-to guides](/knowledge-base/how-to-guides-overview.md)
- [Control plane security](/cloud/admin/security-and-compliance/control-plane-security.md)
- [Access additional domains and hostnames](/cloud/platform-capabilities/core-concepts/compute-environments/access-additional-domains-and-hostnames.md)
- [Data Planes administration](/cloud/admin/platform-configuration/manage-data-planes.md)