CoreDNS后缀重写导致DNS查询返回重写的名称 [英] CoreDNS suffix rewrite causes DNS queries to return the rewritten name

查看:171
本文介绍了CoreDNS后缀重写导致DNS查询返回重写的名称的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个带有CoreDNS的Kubernetes 1.13.1集群,除了默认的<servicename>.default.svc.cluster.local之外,我还希望通过<servicename>.nsc可以访问默认名称空间中运行的许多服务.

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

运行nslookup gitea.nsc返回预期的输出:

Server:     10.245.0.10
Address:    10.245.0.10#53

Name:   gitea.nsc
Address: 10.245.64.203

我可以curl,一切都很好.

但是后来我尝试将其抽象一些,因为为每个服务手动添加一行很繁琐.

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

我最终得到了这个

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

但是现在,curl突然失败. nslookup提供了有关原因的可能线索:

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

现在,响应中的名称包含重写的主机,而不是原始输入.我的猜测是,这会抛出pingcurlwget.

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

我的Corefile当前看起来像这样:

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
    }

我的托管服务提供商会自动生成除两条重写行以外的所有内容.我在一种情况下使用git.nsc,因此在调试时可以同时在Corefile中进行两次重写.

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.

我很困惑.如何获得CoreDNS重写<servicename>.nsc,但不返回重写的主机的响应?

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

推荐答案

事实证明,精确的重写(如我上面的git.nsc重写)可免费重写响应,默认是返回重写的主机.对于其他类型(例如正则表达式或后缀),您必须明确地执行此操作.这仅适用于正则表达式重写,因此后缀重写需要先重写为正则表达式重写.

As it turns out, exact rewrites like my git.nsc rewrite above get the response rewritten for free, the default is to return the rewritten host. For other types like regex or suffix, you have to do that explicitly. This is only possible for regex rewrites, so suffix rewrites need to be rewritten to regex rewrites first.

以下代码段对我有用:

rewrite stop {
    name regex (.*)\.nsc {1}.default.svc.cluster.local
    answer name (.*)\.default\.svc\.cluster\.local {1}.nsc
}

answer name部分基本上是相反的name regex部分.

The answer name part is basically the name regex part in reverse.

这篇关于CoreDNS后缀重写导致DNS查询返回重写的名称的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆