Linked Questions

Popular Questions

I have a Kubernetes 1.13.1 cluster with CoreDNS and a number of services running in the default namespace that I'd like to be reachable via <servicename>.nsc in addition to the default <servicename>.default.svc.cluster.local.

The first thing I've tried was manually rewriting each service, like this:

rewrite name gitea.nsc gitea.default.svc.cluster.local

Running nslookup gitea.nsc returns the expected output:

Server:     10.245.0.10
Address:    10.245.0.10#53

Name:   gitea.nsc
Address: 10.245.64.203

I can curl it, all is fine.

But then I tried abstracting this somewhat, as manually adding a line for each service is tedious.

I ended up with this:

rewrite name suffix .nsc .default.svc.cluster.local

But now, curling suddenly fails. nslookup gives a possible clue as to why:

Server:     10.245.0.10
Address:    10.245.0.10#53

Name:   gitea.default.svc.cluster.local
Address: 10.245.64.203

Now the name in the response contains the rewritten host, not the original input. My guess is that this throws off ping, curl, wget.

My Corefile currently looks like this:

.:53 {
        errors
        health
        rewrite name git.nsc gitea.default.svc.cluster.local
        rewrite name suffix .nsc .default.svc.cluster.local
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          upstream
          fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        proxy . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

Everything apart from the two rewrite lines is autogenerated by my hosting provider. I'm using git.nsc in one case so I can have both rewrites in the Corefile simultaneously while I'm debugging this.

I'm puzzled. How do I get CoreDNS to rewrite <servicename>.nsc, yet not return the rewritten host in its response?

Related Questions