In Part 8 we completed the GitOps stack. But all those services are useless if you cannot reach them by name. In this article I cover the full DNS and networking setup that makes http:\/\/grafana.rezaops.com work from any device on the home network.<\/p>
This was the most complex part of the entire build. We went through three different approaches before landing on the right solution. I will explain what we tried, why each failed, and what finally worked.<\/p>
This is the fundamental challenge. You type http:\/\/grafana.rezaops.com and your browser asks what IP is grafana.rezaops.com. Your ISP’s DNS server has no idea that grafana.rezaops.com should resolve to 10.0.0.200 on your local network.<\/p>
Three approaches I tried, in order.<\/p>
The simplest fix, add entries to \/etc\/hosts on your Mac:<\/p>
10.0.0.200 grafana.rezaops.com\n10.0.0.200 jenkins.rezaops.com<\/code><\/pre>Works on Mac. Does not work on phone, tablet, or other laptops.<\/p>
Approach 2 – Route 53 Private Hosted Zone (Does Not Work)<\/h3>
Route 53 private hosted zones seem perfect but there is a hard AWS requirement:<\/p>
Error: When creating a private hosted zone you must specify VPCId and VPCRegion<\/p>
Private hosted zones must be associated with an AWS VPC. Your home servers are not in AWS. Private zones are only for AWS infrastructure.<\/p>
What we did instead was create a public hosted zone with private IP records:<\/p>
grafana.rezaops.com, 10.0.0.200 (public record, private IP)<\/p>
The record is publicly visible but 10.0.0.200 is a private RFC1918 address unreachable from the internet. This still does not solve the device problem because your home devices use your ISP’s DNS, not Route 53 directly.<\/p>
Approach 3 – Pi-hole (Broken in v6)<\/h3>
Pi-hole v6 completely rewrote its internals, replacing dnsmasq with its own FTL DNS engine. As a result:<\/p>
- \/etc\/dnsmasq.d\/ config files are ignored, the FTL engine does not read them<\/li>
- pihole restartdns command no longer works, returns an error about a readonly variable<\/li>
- pihole reloaddns partially broken, cannot reload custom config<\/li><\/ul>
After multiple attempts to work around the v6 changes, I abandoned Pi-hole entirely.<\/p>
Final Solution – CoreDNS on Kubernetes<\/h3>
CoreDNS is what K3s uses internally for pod DNS. It is battle-tested, runs natively in Kubernetes, and has a simple configuration format called a Corefile.<\/p>
I deployed a second CoreDNS instance specifically for external home network DNS, separate from K3s’s internal CoreDNS.<\/p>
The Corefile<\/h3>apiVersion: v1\nkind: ConfigMap\nmetadata:\n name: coredns-external\n namespace: kube-system\ndata:\n Corefile: |\n rezaops.com {\n hosts {\n 10.0.0.200 grafana.rezaops.com\n 10.0.0.200 prometheus.rezaops.com\n 10.0.0.200 jenkins.rezaops.com\n 10.0.0.200 argocd.rezaops.com\n 10.0.0.200 vault.rezaops.com\n 10.0.0.200 longhorn.rezaops.com\n 10.0.0.200 home.rezaops.com\n fallthrough\n }\n }\n . {\n forward . 1.1.1.1 8.8.8.8\n cache 30\n }<\/code><\/pre>Corefile explained block by block.<\/p>
The rezaops.com block handles all queries for rezaops.com and its subdomains. The hosts plugin works like \/etc\/hosts. Each line maps a hostname to an IP. When any device asks what grafana.rezaops.com is, CoreDNS returns 10.0.0.200.<\/p>
fallthrough means if a hostname is not in the hosts list, pass the query to the next block instead of returning NXDOMAIN.<\/p>
The dot block matches everything. Any query that is not for rezaops.com, like google.com or github.com, gets forwarded to Cloudflare (1.1.1.1) or Google (8.8.8.8).<\/p>
cache 30 caches DNS responses for 30 seconds, reducing upstream queries and making browsing faster.<\/p>
Deploying CoreDNS<\/h3>- name: Deploy CoreDNS external\n shell: |\n cat <<EOF | kubectl apply -f -\n apiVersion: apps\/v1\n kind: Deployment\n metadata:\n name: coredns-external\n namespace: kube-system\n spec:\n replicas: 1\n selector:\n matchLabels:\n app: coredns-external\n template:\n metadata:\n labels:\n app: coredns-external\n spec:\n nodeSelector:\n workload: monitoring\n containers:\n - name: coredns\n image: coredns\/coredns:1.11.1\n args: [\"-conf\", \"\/etc\/coredns\/Corefile\"]\n ports:\n - containerPort: 53\n protocol: UDP\n - containerPort: 53\n protocol: TCP\n livenessProbe:\n httpGet:\n path: \/health\n port: 8080\n initialDelaySeconds: 10\n volumeMounts:\n - name: config\n mountPath: \/etc\/coredns\n volumes:\n - name: config\n configMap:\n name: coredns-external\n EOF<\/code><\/pre>args: [“-conf”, “\/etc\/coredns\/Corefile”] tells CoreDNS to use our ConfigMap-mounted Corefile.<\/p>
The volumes section mounts the ConfigMap as a file at \/etc\/coredns\/Corefile. When we update the ConfigMap, CoreDNS picks up the change automatically without restarting.<\/p>
The livenessProbe checks \/health on port 8080. If it fails, Kubernetes restarts the pod automatically.<\/p>
The TCP\/UDP Split – A MetalLB Limitation<\/h3>
DNS uses both TCP and UDP on port 53. A typical service with mixed protocols stays pending forever with MetalLB. This is a known MetalLB limitation in L2 mode.<\/p>
The fix is to split into two services with the same allow-shared-ip annotation:<\/p>
# TCP service\nmetadata:\n annotations:\n metallb.universe.tf\/allow-shared-ip: \"coredns-dns\"\nspec:\n ports:\n - port: 53\n protocol: TCP\n\n# UDP service (same annotation value means same IP)\nmetadata:\n annotations:\n metallb.universe.tf\/allow-shared-ip: \"coredns-dns\"\nspec:\n ports:\n - port: 53\n protocol: UDP<\/code><\/pre>Both services get the same MetalLB IP (10.0.0.209 in our setup).<\/p>
Testing CoreDNS<\/h3># Query CoreDNS directly from your Mac\ndig @10.0.0.209 grafana.rezaops.com\n\n# Expected output\n;; ANSWER SECTION:\ngrafana.rezaops.com. 3600 IN A 10.0.0.200\n\n# Test forwarding works for external domains\ndig @10.0.0.209 google.com\n# Should resolve to Google's IPs via 1.1.1.1 forwarding<\/code><\/pre>Pointing Devices at CoreDNS<\/h3>
Mac, System Settings, WiFi, your network, Details, DNS tab:<\/p>
10.0.0.209 CoreDNS (home lab)\n1.1.1.1 Cloudflare fallback\n8.8.8.8 Google fallback<\/code><\/pre>iPhone, Settings, WiFi, your network, Configure DNS, Manual:<\/p>
10.0.0.209\n1.1.1.1<\/code><\/pre>Docker Desktop on Mac, Settings, Docker Engine, add to JSON:<\/p>
{\n \"dns\": [\"10.0.0.209\", \"1.1.1.1\"]\n}<\/code><\/pre>Docker Desktop runs in a VM with its own DNS and does not inherit your Mac’s system DNS settings. Without this, docker push registry.rezaops.com\/myapp:latest fails with no such host.<\/p>
How NGINX Ingress Routes Traffic<\/h3>
With DNS working, every request to *.rezaops.com resolves to 10.0.0.200, the NGINX Ingress controller’s MetalLB IP. NGINX then routes the request to the right service based on the Host header.<\/p>
Request: GET http:\/\/grafana.rezaops.com\/dashboards\n |\n | DNS: grafana.rezaops.com, 10.0.0.200\n v\nNGINX Ingress Controller (10.0.0.200:80)\n reads Host header: grafana.rezaops.com\n checks Ingress rules\n |\n | matches rule in monitoring namespace\n v\nService: kube-prometheus-stack-grafana\n |\n v\nGrafana Pod (on jarvis)<\/code><\/pre>The Ingress resource is the routing rule:<\/p>
apiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n name: monitoring-ingress\n namespace: monitoring\nspec:\n ingressClassName: nginx\n rules:\n - host: grafana.rezaops.com\n http:\n paths:\n - path: \/\n pathType: Prefix\n backend:\n service:\n name: kube-prometheus-stack-grafana\n port:\n number: 80\n - host: prometheus.rezaops.com\n http:\n paths:\n - path: \/\n pathType: Prefix\n backend:\n service:\n name: kube-prometheus-stack-prometheus\n port:\n number: 9090<\/code><\/pre>Key insight: you only need one LoadBalancer IP (the ingress IP) for all your services. Every additional service just needs an Ingress resource with a different hostname, not a new LoadBalancer IP.<\/p>
Adding a New App Domain<\/h3>
For every new app you deploy, two steps:<\/p>
Step 1, update the CoreDNS ConfigMap:<\/p>
kubectl edit configmap coredns-external -n kube-system\n# add: 10.0.0.200 myapp.rezaops.com<\/code><\/pre>CoreDNS picks up ConfigMap changes automatically.<\/p>
Step 2, create an Ingress resource:<\/p>
apiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n name: myapp-ingress\n namespace: myapp\nspec:\n ingressClassName: nginx\n rules:\n - host: myapp.rezaops.com\n http:\n paths:\n - path: \/\n pathType: Prefix\n backend:\n service:\n name: myapp-service\n port:\n number: 8000<\/code><\/pre>Two steps, under 2 minutes, and your new app is accessible at http:\/\/myapp.rezaops.com from every device on the network.<\/p>
DNS Resolution Full Picture<\/h3>Device: \"What is grafana.rezaops.com?\"\n |\n | DNS query sent to 10.0.0.209 (CoreDNS)\n v\nCoreDNS checks hosts block for rezaops.com\n finds: 10.0.0.200 grafana.rezaops.com\n |\n | returns: 10.0.0.200\n v\nDevice connects to 10.0.0.200:80\n |\n v\nNGINX Ingress Controller\n reads Host: grafana.rezaops.com\n routes to Grafana service\n |\n v\nGrafana pod responds<\/code><\/pre>For external domains (google.com), CoreDNS forwards to 1.1.1.1 automatically.<\/p>
What’s Next<\/h3>
In Part 10 I will cover the homepage and container registry setup, how I deployed a static HTML dashboard as a Kubernetes pod and configured the Docker registry so every machine on the network can push and pull images with a proper domain name.<\/p>","protected":false},"excerpt":{"rendered":"
Overview In Part 8 we completed the GitOps stack. But all those services are useless if you cannot reach them by name.…<\/p>\n","protected":false},"author":2,"featured_media":124,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_rezaops_part":"9","_rezaops_linkedin_url":"https:\/\/www.linkedin.com\/pulse\/part-09-dns-networking-coredns-route-53-nginx-ingress-reza-chegini-s6kwc\/","footnotes":""},"categories":[10,62,9],"tags":[71,8,70,66,3,73,72],"series":[64],"class_list":["post-121","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","category-home-lab","category-kubernetes","tag-coredns","tag-devops","tag-dns","tag-home-lab","tag-kubernetes","tag-nginx-ingress","tag-route-53","series-home-lab"],"jetpack_featured_media_url":"https:\/\/rezachegini.com\/wp-content\/uploads\/2026\/10\/part-09-dns-networking-cover.png","_links":{"self":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/121","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=121"}],"version-history":[{"count":1,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/121\/revisions"}],"predecessor-version":[{"id":122,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/posts\/121\/revisions\/122"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=\/wp\/v2\/media\/124"}],"wp:attachment":[{"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=121"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=121"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=121"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/rezachegini.com\/index.php?rest_route=%2Fwp%2Fv2%2Fseries&post=121"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}