Working on applications for a cloud deployment means that one typically will hit the need for setting up a few domain names for testing purposes. Those come in handy you configure Ingress objects with the attribute host set to a domain name. And in general this is also convenient because there is no need to remember all the internal IP addresses anymore.
The general idea is to use a Helm chart for CoreDNS to deploy it into a Kubernetes cluster, the command to deploy it could look as follows:
helm upgrade --install coredns coredns \ --repo https://coredns.github.io/helm \ --namespace dns --create-namespace \ --values ./values-coredns.yaml
The interesting part is then the file values-coredns.yaml which configures the Helm chart.
The file values-coredns.yaml would contain something like the following example:
# We want a dedicated instance and not mess with the cluster's DNS service. isClusterService: false # This example requires MetalLB to be installed, so that you can grab an IP # address for the DNS server. service: annotations: # Take an IP Address which is available to MetalLB metallb.universe.tf/loadBalancerIPs: "192.0.2.2" serviceType: "LoadBalancer" servers: # This is the "test" zone which is configured by the file "test.db". # The content of the file is specified below. - zones: - zone: test port: 53 plugins: - name: log - name: errors - name: file parameters: /etc/coredns/test.db # This is the default configuration, keeping it means that the DNS server # will also resolve all other domain names by forwarding to another DNS # server. - zones: - zone: . port: 53 plugins: - name: errors - name: health configBlock: |- lameduck 5s - name: ready - name: kubernetes parameters: cluster.local in-addr.arpa ip6.arpa configBlock: |- pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 - name: prometheus parameters: 0.0.0.0:9153 - name: forward parameters: . /etc/resolv.conf - name: cache parameters: 30 - name: loop - name: reload - name: loadbalance # This allows to provide the zone configuration as files to the DNS server. zoneFiles: - filename: test.db domain: test contents: | test. IN SOA dns.test. admin.dns.test. 2023081802 600 60 360000 600 dns IN A 192.0.2.2 local-cluster IN TXT "Local cluster" local-cluster IN A 127.0.0.1 *.local-cluster IN A 127.0.0.1 k8s IN TXT "Default ingress of test-k8s" k8s IN A 192.0.2.4 *.k8s IN A 192.0.2.4
With the configuration above you would have a nameserver which would respond to queries in the test top level domain. You could verify this by using a tool like dig:
dig @192.0.2.2 example.k8s.test dig @192.0.2.2 example.local-cluster.test