21.1 Core Dns入门

title: CoreDNS文档

CoreDNS 是什么?

CoreDNS 是一个DNS服务器。使用 Go编写。

CoreDNS 和其他DNS服务器不同，比如 (其实都不错的) BIND, Knot, PowerDNS 以及 Unbound (其实仅作为resolver, 但是还是值得关注), 因为其运行非常流畅，而且几乎所有功能都使用插件实现。

插件可以单独运行或者组合为 “DNS function” 来运行。

那么，什么是 “DNS function” 呢? 我们定义CoreDNS是实现CoreDNS 插件 API 的部分软件。功能的实现差异可以很大。有些插件自身不作任何响应，比如 metrics 或cache，仅增加功能。有些插件会发出响应(response)。这些插件功能强大：有插件协同Kubernetes 来提供服务发现，有插件从file or database读取数据。

在默认安装中，已经包含了大约30个插件。但是还有大量的 external 插件你可以编译到CoreDNS中来扩展功能。

CoreDNS 因插件而强大

开发新的 plugins 非常容易，但是需要懂GO语言并且深入了解DNS如何工作。CoreDNS 抽象出了大量的DNS细节，所以你只需要关注你需要开发的功能即可。

安装

CoreDNS 使用GO语言开发，除非你想开发插件或者编译CoreDNS ，否则你无需担心。如下章节展示了如何获取CoreDNS 的编译文件（可执行版本）或从源码编译安装。

编译文件

对 CoreDNS 的每个版本，我们给多种操作系统提供了 pre-compiled binaries 。对 Linux，还提供了面向ARM，PowerPC和其他架构的cross-compiled编译文件。

Docker

我们同样将每个版本都发布到Docker images。你可以在 public Docker hub 内的 CoreDNS organization找到。Docker image 的格式如 scratch + CoreDNS + TLS 认证 (for DoT, DoH, and gRPC).

源码编译

要编译 CoreDNS，我们建议你有一个工作的GO设置。如果你还没有配置，请参考文档。 CoreDNS 使用Go模块来实现它的依赖管理。

关于编译的最新文档参见 coredns source.

测试

如果你有 coredns 编译文件，你可以使用 -plugins flag 来列出所有的插件。如果找不到 Corefile (See Configuration) 文件， CoreDNS 会加载 whoami 插件，插件会返回client的IP地址和端口。我们启动 CoreDNS，运行在端口 1053 ，使用 dig 进行查询测试：

$ ./coredns -dns.port=1053
.:1053
2018/02/20 10:40:44 [INFO] CoreDNS-1.0.5
2018/02/20 10:40:44 [INFO] linux/amd64, go1.10,
CoreDNS-1.0.5
linux/amd64, go1.10,

从另外一个 terminal 窗口， dig 会返回类似于下面的内容：

$ dig @localhost -p 1053 a whoami.example.org

;; QUESTION SECTION:
;whoami.example.org.        IN  A

;; ADDITIONAL SECTION:
whoami.example.org. 0   IN  AAAA    ::1
_udp.whoami.example.org. 0  IN  SRV 0 0 39368 .

插件

当 CoreDNS 启动并且加载配置文件了，DNS服务器就启动了。

每个服务器由服务的zone和运行port来定义。
每个服务器都有它自己的插件链。

query查询步骤(最长后缀匹配)

当一个查询提交到 CoreDNS，会执行如下的步骤：

匹配服务器：如果有多个服务器运行在同一个监听端口，它会检查哪个zone最匹配该次查询（最长后缀匹配）比如：如果存在两个服务器，一个服务于 example.org ，一个服务于 a.example.org，查询请求是 www.a.example.org，CoreDNS会将查询请求路由向后者。
当服务器被发现后，查询通过该服务器预先定义的插件链，路由向该服务器。这些总是按照同样的顺序处理的。顺序定义在 plugin.cfg.
每个插件都会检查查询，并且判断是否被处理 (有些查询允许基于query name 或其他属性过滤). 会产生如下操作:
1. query 被插件处理.
2. query 不被插件处理
3. query 被插件处理，但是话说虽然决定处理了，还是需要调用链中的下个插件。我们称为 fallthrough。
4. query 被插件处理， “hint” 被添加，下个插件被调用。这个 hint 提供了一个办法来 “see” the (eventual) response and act upon that.

处理一个 query 意思是插件会向client返回消息。

注意，插件也可以不按照如上方式处理。虽然现在所有的在CoreDNS工作的插件都包含在如上4个组里了。 blog post 提供了query routing 的相关内容。

Query 被处理

插件处理这个query。它找到 looks up (or 生成， or 插件拥有者决定插件做的任何事情) 一个反馈，然后发送回 client 。然后查询的处理就在这结束了，不会调用下个插件了。以如此方式工作的一个 (简单) 插件，比如 whoami.

Query 不被处理

如果插件决定不处理这个query，它就直接调用链中的下一个插件。如果链中的最后一个插件也觉得不处理这个查询，CoreDNS 就会返回 SERVFAIL 给 client。

Query 以 Fallthrough 的方式处理

在某种情况下，一个插件完整的处理这个查询，但是答复来自后台 (i.e. maybe it got NXDOMAIN)，它希望链中的其他插件查询。如果fallthrough被配置了，下一个插件将会被调用。

以这种方式工作的插件，比如 hosts 插件。首先，先从主机列表文件 (/etc/hosts) 进行查询，如果查到了，就将起返回；如果没有查询到，它会 fallthrough 到下一个，以希望其他插件可以返回结果给 client 。

fallthrough : 下坠。CoreDNS里面的意思，应该是自己不处理，让下个插件接替这个任务。

Query 以 Hint 的方式处理

这类插件处理查询，总是 always 调用下一个插件。但是，它提供了一个 hint ，允许查看到被写回 client 的响应内容。比如插件 prometheus。它计量某个周期的时间It times the duration (among other things)，但是不做跟DNS 请求有关的任何事情。它只是透传和检查返回路径的源数据。

Hint : 暗示，示意。我的理解，啥都不干，偷偷看着。

未注册插件

还有一个特殊的插件不处理任何DNS的数据，但是以其他方式影响着 CoreDNS 的工作。比如， bind 插件用于控制 CoreDNS 会绑定到哪个接口上。如下的插件都是这个类型的：

bind - 绑定接口。
root - set the root directory where CoreDNS plugins should look for files.
health - 开启 HTTP health 检查接口。
ready - support readiness reporting for a plugin.

插件结构解析

插件由 Setup, Registration, and Handler 部分构成。

Setup 解析配置文件和插件的指令 (参见插件的 README 文档)。

Handler 是用于查询处理和逻辑实现的代码。

Registration 将插件注册到 CoreDNS - 当 CoreDNS 编译后。所有已注册的插件都可以被服务器使用。在运行的时候，会决定哪个服务器用哪个插件，由CoreDNS 的配置文件 Corefile 来完成。

插件文档

每个插件都有自己的 README 文档，告诉你如何配置。这些 README 包含了范例和用户应该留意的注意点。 READMEs 参见 https://coredns.io/plugins,并且我们也已经将其编译到了 manual pages.

配置文件

在CoreDNS有几个部分可以配置。

首先，确定哪些插件被编译进CoreDNS。我们提供的编译后的二进制可执行包（binaries）已经包含了所有的插件，列在plugin.cfg。增加和删除都很 easy，但是需要对CoreDNS重新编译。
大多数用户使用文件 Corefile 来配置 CoreDNS。当 CoreDNS 启动的时候，如果 -conf flag 没有被配置，就会在当前目录查找 Corefile 文件。
文件包含了一个或者多个服务器块 (Server Blocks)。每个服务器块列出了一个或多个插件。那些插件也可以在后面使用指令配置。
在Corefile 文件中，插件的顺序不决定插件链的顺序。插件执行的顺序，配置在文件plugin.cfg中。
Corefile 文件的备注以 # 开头。行的其他部分会被识别为备注。

环境变量

CoreDNS 在配置中支持环境变量。环境变量可以被使用在任何地方。语法是 {$ENV_VAR} ( Windows-类型的语法{%ENV_VAR%} 也是支持的)。CoreDNS 会在解析Corefile的时候替换这些变量内容。

导入其他文件

参考 import plugin。这个插件有些特殊，可以被用在Corefile的任何地方。

可复用的 Snippets

一个很特殊的可导入文件是 snippet。一个 snippet 通过命名一个块（block）的特殊语法来定义。名字需要被放到圆括号内: (name)。然后，它就可以随着导入插件放置到配置文件的任何地方了。

# define a snippet
(snip) {
    prometheus
    log
    errors
}

. {
    whoami
    import snip
}

服务器块 Server Blocks

每个服务器块（Server Block）以server应该服务的zones开头。在zone名字或者zone列表名（以空格分隔）之后，一个服务器块以大括号作为开头和结束。如下的服务器块定义了一个 server，负责root zone: .下所有的zones；基本上，这个 server 应该处理所有的查询：

. {
    # Plugins defined here.
}

服务器块（Server blocks）还可以指定监听端口。默认同时监听TCP和UDP 53端口 (DNS 服务标准端口)。指定端口，以冒号作为分隔符在zone后列出端口号。如下的 Corefile 指示 CoreDNS 创建一个 Server ，监控端口 1053：

.:1053 {
    # Plugins defined here.
}

注意：如果你明确的定义了监听端口，你就不可以使用 -dns.port参数覆盖了。

给服务器块定义一个zone，但是这个zone已经被配置到一台服务器上，并且已经运行了，运行在同一个端口。Corefile 会在启动的时候报错：

.:1054 {

}

.:1054 {

}

变更第二个端口为 1055 可以让这两个服务器块变成两个不同的服务器。

支持协议

当前 CoreDNS 接受4种协议: DNS, DNS over TLS (DoT), DNS over HTTP/2 (DoH) and DNS over gRPC。可以通过在服务器配置文件，在zone 前加个前缀来指定服务器接收哪种协议。

dns:// for plain DNS (the default if no scheme is specified).
tls:// for DNS over TLS, see RFC 7858.
https:// for DNS over HTTPS, see RFC 8484.
grpc:// for DNS over gRPC.

大陆的网络环境非常复杂，UDP非标准端口也只在某些地区某些运营商有用，现在比较好的一个选择是DoT，即DNS over TLS，知名的支持DoT的公共DNS服务有Quad9的9.9.9.9，Google的8.8.8.8以及Cloudflare的1.1.1.1，可以这么使用：

.:53{
    forward . 127.0.0.1:5301 127.0.0.1:5302 127.0.0.1:5303
    log
    health
}
.:5301 {
   forward . tls://9.9.9.9 {
       tls_servername dns.quad9.net
       except www.taobao.com
   }
   cache
}
.:5302 {
    forward . tls://1.1.1.1 tls://1.0.0.1 {
        tls_servername 1dot1dot1dot1.cloudflare-dns.com
    }
    cache
}
.:5303 {
    forward . tls://8.8.8.8 tls://8.8.4.4 {
        tls_servername dns.google
    }
    cache
}

插件

每个服务器块都定义了一系列插件。最简单的方式，就是在服务器块内添加插件的名字：

. {
    chaos
}

插件 chaos 让 CoreDNS 以 CH class 应答查询 - 在确认服务器的时候很有用。通过如上配置，CoreDNS 会在收到请求后，应答它的版本：

$ dig @localhost -p 1053 CH version.bind TXT
...
;; ANSWER SECTION:
version.bind.       0   CH  TXT "CoreDNS-1.0.5"
...

大多数插件允许以指令提供更多配置。比如 chaos插件，我们可以在语法内定义 VERSION 和AUTHORS：

Syntax
  chaos [VERSION] [AUTHORS...]
VERSION 返回版本。默认 CoreDNS-<version>，如果没设置的话。
AUTHORS 返回作者。默认定义在 OWNER 文件内。

这样，这就给 chaos 插件增加了指令，让 CoreDNS 以CoreDNS-001的格式答复版本：

. {
    chaos CoreDNS-001 info@coredns.io
}

其他插件有更多配置，使用插件块（Plugin Block），跟服务器块一样，以大括号作为开头和结束：

. {
    plugin {
       # Plugin Block
    }
}

我们将其全部融合起来，就生成下面的 Corefile，设置 4 zones 运行与2个不同的端口：

coredns.io:5300 {
    file db.coredns.io
}

example.io:53 {
    log
    errors
    file db.example.io
}

example.net:53 {
    file db.example.net
}

.:53 {
    kubernetes
    forward . 8.8.8.8
    log
    errors
    cache
}

当CoreDNS解析配置文件的时候，就会是如下的 Setups：

aNgfQp-1632567598087

扩展插件

扩展插件就是CoreDNS默认没有包含的插件。你可以开启扩展插件，但是你得自己编译CoreDNS。

可能的报错

插件 health 的文档声明 “This plugin only needs to be enabled once”，这可能导致你认为如下是一个符合规定的Corefile：

health

. {
    whoami
}

但是，这不能工作，并且导致一些简短的报错：

"Corefile:3 - Error during parsing: Unknown directive '.'".

为什么呢？ health 被看作一个 zone (and the start of a Server Block)。解析希望看到插件名字 (cache, etcd, etc.)，但是下一个标识是 .，这不是插件。正确的 Corefile 如下：

. {
    whoami
    health
}

插件 health 文档里面的那段话，意思是一旦 health 被定义，它对整个CoreDNS 进程来说就是全局的，哪怕你是在一个server中定义它。

常用插件

https://coredns.io/plugins

这里有大量的CoreDNS配置。所有的设置都基于非root账户，并且因此不能监听在port 53的情况下。我们使用port 1053替代，使用 -dns.port flag。在每个设置中，配置文件都使用CoreDNS默认配置文件Corefile。即我们不需要使用-conf flag 来指定配置文件。换句话说，我们启动CoreDNS 原来使用 ./coredns -dns.port=1053 -conf Corefile，可以被缩略为./coredns -dns.port=1053。

所有的 DNS queries 使用 dig 工具，调试DNS的黄金标准。完整的命令：

$ dig -p 1053 @localhost +noall +answer <name> <type>

但是在如下的步骤我们可以缩略，比如 dig www.example.org A 就等于dig -p 1053 @localhost +noall +answer www.example.org A

权威应答__ file插件

这个设置使用了file 插件。

注意，扩展插件 redis 也可以开启权威应答服务（authoritative serving），以Redis 数据库的形式。如下的操作还是使用 file。

这里，我们创建一个文件 DNS zone file，可以是任何名字 (file 插件不关心)。我们在文件内对zone example.org. 进行相关配置。

在当前目录，创建一个名为 db.example.org的文件，文件内容如下：

$ORIGIN example.org.  #指定当前zone的域名
@   3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. (  #起始授权记录SOA：指定主dns服务器及主从间的同步配置；@表示$ORIGIN后面的值“example.org.”
                2017042745 ; serial
                7200       ; refresh (2 hours)
                3600       ; retry (1 hour)
                1209600    ; expire (2 weeks)
                3600       ; minimum (1 hour)
                )

    3600 IN NS a.iana-servers.net.    #NS记录：指定该区域的权威dns server的FQDN
    3600 IN NS b.iana-servers.net.

www     IN A     127.0.0.1
        IN AAAA  ::1                  #name省略，表示同上一条的记录，此处为www

最后两行，定义了一个name www.example.org. 有如下两个地址， 127.0.0.1 和(the IPv6) ::1.

下面，创建一个迷你 Corefile，负责这个domain 的所有查询，添加插件log 来开启查询日志：

example.org {
    file db.example.org
    log
}

启动 CoreDNS，使用 dig 查询：

$ dig www.example.org AAAA

www.example.org.    3600    IN  AAAA    ::1

工作正常。

日志插件log

因为开启了 log 插件，我们可以看到上面的查询被记录到日志：

[INFO] [::1]:44390 - 63751 "AAAA IN www.example.org. udp 45 false 4096" NOERROR qr,aa,rd,ra 121 0.000106009s

如上日志，显示 CoreDNS 返回自 (::1) ，还返回了时间和日期。而且，还记录了查询类型，查询类，查询的名字，协议，进来请求的大小(bytes)， DO bit 状态，以及高级的UDP buffer size。这些都是进来的查询请求的数据。 NOERROR 是答复信息的开头，后面是答复信息的flag集合 qr,aa,rd,ra，答复信息的大小(bytes)(121)，以及收到答复的时间。

转发forward插件

CoreDNS 可以配置转发流量到递归器（recursor），使用插件forward。

这里, 我们将使用 forward 作最基础的设置：转发到Google Public DNS(8.8.8.8) 和Quad9 DNS (9.9.9.9).

除了Corefile 我们不需要创建任何文件，Corefile 定义了我们需要的配置。在这个范例中，我们期望所有的查询都转发到 8.8.8.8 or 9.9.9.9：

. {
    forward . 8.8.8.8 9.9.9.9 #forward插件支持多个上游服务器以实现简单的负载均衡
    log
}

注意， forward 允许你很好的调整需要发送upstream的names。这里，我们配置了所有的names (.)。范例： forward example.com 8.8.8.8 9.9.9.9 将只转发在example.com. domain的names。

upstream：个人理解为，DNS向上游查询的操作。

启动 CoreDNS ，然后使用 dig 测试：

$ dig www.example.org AAAA
www.example.org.    25837   IN  AAAA    2606:2800:220:1:248:1893:25c8:194

转发 Domains 到不同的Upstreams

一个常见场景，对example.org 的查询需要转发到 8.8.8.8 ，而其他查询需要通过配置在/etc/resolv.conf内的name servers解析。有两种Corefile配置方式可以实现：一种可能会有效 (取决与插件的实现) ，一种必然会生效。

注意： forward 插件在Server Block 中只能使用一次。

在 Corefile配置如下：

example.org {
    forward . 8.8.8.8
    log
}

. {
    forward . /etc/resolv.conf  #转发到/etc/resolv.conf文件中定义的nameserver
    log
}

这让 domain 路由到 CoreDNS，同时还可以处理特殊查询比如DS查询。使用两个小一些的Server Blocks 而不是一个，并没有副作用，除了Corefile 稍长了一些。像 snippets 和 import 会非常有帮助的。

递归DNS服务器_Recursive Resolver

CoreDNS 没有原生的recursive resolver，但是有一个利用lib unbound的扩展插件。要让这个设置工作起来，你首先要重新编译 CoreDNS 并且 enable the unbound plugin。

超简攻略 (你必须使用 CoreDNS source 安装):

添加 unbound:github.com/coredns/unbound 到 plugin.cfg
执行 go generate，然后执行 make

注意： unbound 插件的编译需要 cgo ，这同样意味着 coredns binary 绑定了 libunbound ，不再是一个 static binary。

假设都做完了，你可以在Corefile开启 unbound ：

. {
    unbound
    cache
    log
}

cache 也被配置在内，因为为使cache’s metrics 像平时那样工作， unbound带的内置cache是被禁用的。

解析主机hosts文件_hosts插件

hosts插件格式：

hosts [FILE [ZONES...]] {
    [INLINE]
    fallthrough [ZONES...]
}

FILE：需要读取与解析的hosts文件；如果省略，默认取值"/etc/hosts"；每5s扫描一次hosts文件的变更。
ZONES：如果为空，取配置块中的zone。
INLINE：宿主机hosts文件在corefile中的内联；在"fallthrough"之前的所有"INLINE"都可视为hosts文件的附加内容，hosts文件中相同条目将被覆盖，以"INLINE"为准。
fallthrough：如果zone匹配且无法生成记录，将请求传递给下一个插件；如果省略，对所有zones有效，如果列出特定zone，则只有列出的zone受到影响。

示例：以Kubernetes采用CoreDNS中的coredns-cm.yaml为基础变更，如下：

.:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    # 省略了”FILE“，"ZONES"等字段
    hosts {
      172.22.22.10 rencaiyoujia.com www.rencaiyoujia.com
      fallthrough
    }
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
    prometheus :9153
    forward . 114.114.114.114
    cache 30
    loop
    reload
    loadbalance
}

其他插件

.:53 {
    # 绑定interface ip
    bind 127.0.0.1
    # 先走本机的hosts，查询不到的，fallthrough进入下一个插件
    hosts /etc/hosts {
        fallthrough
    }
    # 转发上游dns服务器
    forward . 127.0.0.1:853 127.0.0.1:5301
    # 缓存时间ttl
    cache 120
    reload 10s
    log
    errors
}

.:853 {
    bind 127.0.0.1
    forward . tls://223.5.5.5:853 {
        tls_servername dns.alidns.com
        force_tcp
        max_fails 3
    }
    cache 120
    reload 10s
    log
    errors
}

.:5301 {
    bind 127.0.0.1
    forward . tls://1.1.1.1 tls://1.0.0.1 {
        tls_servername cloudflare-dns.com
        force_tcp
        health_check 5s
    }
    cache 120
    reload 10s
    log
    errors
}

k8s中的coredns配置：

.:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
       pods insecure
       fallthrough in-addr.arpa ip6.arpa
       ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

Corefile 配置包括以下 CoreDNS 插件：

errors：错误记录到标准输出。
health：在 http://localhost:8080/health 处提供 CoreDNS 的健康报告。
ready：在端口 8181 上提供的一个HTTP请求接口，当所有能够表达自身就绪的插件都已就绪时，在此接口返回 200 OK。
kubernetes：CoreDNS 将为基于 Kubernetes 的svc和 Pod 的 IP 答复 DNS 查询。你可以在CoreDNS 网站阅读更多细节。你可以使用 ttl 来定制响应的 TTL。默认值是 5 秒钟。TTL 的最小值可以是 0 秒钟，最大值为 3600 秒。将 TTL 设置为 0 可以禁止对 DNS 记录进行缓存。
pods insecure 选项是为了与 kube-dns 向后兼容。你可以使用 pods verified 选项，该选项使得仅在相同名称空间中存在具有匹配 IP 的 Pod 时才返回 A 记录。如果你不使用 Pod 记录，则可以使用 pods disabled选项。
prometheus：CoreDNS 的度量指标值以 Prometheus 格式在http://localhost:9153/metrics 上提供。
forward: 不在 Kubernetes 集群域内的任何查询都将转发到预定义的解析器 (/etc/resolv.conf文件中定义的nameserver).
cache：启用前端缓存（缓存ttl）。
loop：检测到简单的转发环，如果发现死循环，则中止 CoreDNS 进程。`
reload：允许自动重新加载已更改的 Corefile。编辑 ConfigMap 配置后，请等待两分钟，以使更改生效。
loadbalance：这是一个轮转式 DNS 负载均衡器，它在应答中随机分配 A、AAAA 和 MX 记录的顺序
log ：记录dns查询日志
rewrie：重写记录

rewrite name tenant.msa.chinamcloud.com tenantapi.yunjiao.svc.cluster.local  #通过内部service直接访问外部服务。实现k8s集群内部访问tenant.msa.chinamcloud.com域名时，会将流量转发到tenantapi.yunjiao.svc.cluster.local域名，实现k8s集群内外域名访问一致。

hosts：解析主机hosts文件

CoreDNS作为kubernetes后端的DNS服务器

coredns之所以如此名声大噪，就是因为从kubernetes1.9开始引入，作为kubernetes内部服务发现的默认dns。毫无疑问kubernetes是coredns的后端之一，所以我们讲coredns，就从kubernetes作为其后端开始。

coredns的诸多特性网上很多文章都有提及，在这里不再赘述。简单对一下其相对于bind和skydns的优势：

bind可以将解析存储到mysql或者文件中，coredns也可以将解析存储到etcd或者文件中，也支持将kubernetes作为其后端，直接调用kubernetes的api获取解析数据，然后缓存到本地内存。coredns支持插件扩展，目前在第三方插件中还同时支持将powerdns及amazondns作为其后端，后续还会支持越来越来的后端。bind在kubernetes的应用场景下，基本无用武之地。

coredns本身就是skydns的继任者，支持skydns的所有特性，而且性能更好，更易于扩展。其插件式特性无论是bind还是skydns都无法比拟。

配置kubernetes后端存储

配置说明

其实官方有kubernetes插件的相关示例及配置说明，地址如下：

我这里就以官方的配置示例作说明：

kubernetes [ZONES...] {
    resyncperiod DURATION
    endpoint URL [URL...]
    tls CERT KEY CACERT
    namespaces NAMESPACE...
    labels EXPRESSION
    pods POD-MODE
    endpoint_pod_names
    upstream [ADDRESS...]
    ttl TTL
    fallthrough [ZONES...]
}

下面对一些常用参数作下说明：

resyncperiod：用于从kubernetes的api同步数据的时间间隔

endpoint：指定kubernetes的api地址，coredns会自动对其执行健康检查并将请求代理到健康的节点上。示例如下：

endpoint

tls：用于指定连接远程kubernetes api的相关证书。示例：

tls admin.pem admin-key.pem ca.pem

pods：指定POD-MODE，有以下三种：

disabled：默认

insecure：返回一个A记录对应的ip，但并不会检查这个ip对应的Pod当前是否存在。这个选项主要用于兼容kube-dns

verified：推荐的方式，返回A记录的同时会确保对应ip的pod存在。比insecure会消耗更多的内存。

upstream：定义外部域名解析转发的地址，可以是一个ip地址，也可以是一个resolv.conf文件。示例：

upstream 8.8.8.8:53 8.8.4.4:53

ttl：默认5s，最大3600s

示例

一个完整的配置示例：

# /opt/coredns/cfg/Corefile
.:53 {
    kubernetes wh01 {
        resyncperiod 10s
        endpoint 
        tls admin.pem admin-key.pem ca.pem
        pods verified
        endpoint_pod_names
        upstream /etc/resolv.conf
    }
    health
    log /var/log/coredns.log
    prometheus :9153
    proxy . /etc/resolv.conf
    cache 30
    reload 10s
}

也可以使用如下写法：

wh01 {
    kubernetes {
        resyncperiod 10s
        endpoint 
        tls admin.pem admin-key.pem ca.pem
        pods verified
        endpoint_pod_names
        upstream /etc/resolv.conf
    }
    health
    log
    errors
    prometheus :9153
    proxy . /etc/resolv.conf
    cache 30
    reload 10s
}

其他配置也简单作下说明：

health：插件，用于检测当前配置是否存活，默认监听http 8080端口，可配置

log：插件，将日志打印到标准输出

errors：将错误打印到标准输出

prometheus：插件，用于prometheus监控

proxy： wh01之外的域名解析都通过proxy指定的地址实现代理

cache：插件，用于在内存中缓存dns解析，单位为s

reload：插件，单位为s，如果配置文件发生变更，自动reload的间隔

启动coredns

nohup /opt/coredns/bin/coredns -conf /opt/coredns/cfg/Corefile &

使用systemd启动coredns

# cat /lib/systemd/system/coredns.service
[Unit]
Description=CoreDNS
Documentation=
[Service]
ExecStart=/opt/coredns/bin/coredns \
  -conf /opt/coredns/cfg/Corefile
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.targe
# systemctl start coredns
# systemctl enable coredns

生产环境配置文件示例

apiVersion: v1
data:
  Corefile: |2

    ljzsdutcloud.cn:53 {
        file /etc/coredns/db.ljzsdutcloud.cn
    }
    mgr-apig-jinan-lab.ljzsdutcloud.cn:53 {
        file /etc/coredns/db.mgr-apig-jinan-lab.ljzsdutcloud.cn
    }
    apig-jinan-lab.ljzsdutcloud.cn:53 {
        file /etc/coredns/db.apig-jinan-lab.ljzsdutcloud.cn
    }
    mgt-jinan-lab.ljzsdutcloud.cn:53 {
        file /etc/coredns/db.mgt-jinan-lab.ljzsdutcloud.cn
    }
    jinan-lab.ljzsdutcloudoss.com:53 {
        file /etc/coredns/db.jinan-lab.ljzsdutcloudoss.com
    }
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local region-jinan-lab.myljzsdutcloud.com in-addr.arpa ip6.arpa openstacklocal {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
        forward . 114.114.114.114
        prometheus :9153
        hosts {
          10.110.68.46 gitlab.ljzsdut.com
          10.110.68.46 postgres.ljzsdut.com
          100.200.108.71 cyborg.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 barbican.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 watcher.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 masakari.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 ironic.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 cve-rabbitmq.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 cinder.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 cloudformation.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 glance.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 heat.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 horizon.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 keystone.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 metadata.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 neutron.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 nova.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 novncproxy.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 placement.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.71 rabbitmq-mgr.openstack.svc.region-jinan-lab.myljzsdutcloud.com
          100.200.108.77 oss-innet.jinan-lab.ljzsdutcloudoss.com
          100.200.112.77 oss.jinan-lab.ljzsdutcloudoss.com
          10.110.68.73 pushgateway.myljzsdutcloud.com
          100.200.108.71 minio.jinan-lab.myljzsdutcloud.com
          100.200.108.71 log.myljzsdutcloud.com
          10.110.68.31 ntp01.myljzsdutcloud.com
          10.110.68.31 ntp02.myljzsdutcloud.com
          100.200.108.71 dbbk.jinan-lab.myljzsdutcloud.com
          100.200.108.71 cloudoss.jinan-lab.myljzsdutcloud.com
          100.200.108.71 kms.ecs.myljzsdutcloud.com
          100.200.108.71 apm.myljzsdutcloud.com
          100.200.108.76 mirrors.myljzsdutcloud.com
          100.200.108.46 registry-ga.ljzsdut.live
          100.200.108.46 git-ga.ljzsdut.live
          100.200.108.46 ossalert.myljzsdutcloud.com
          100.200.108.46 mail.ljzsdut.com
          100.200.108.71 dream.ljzsdut.live
          10.110.27.118 git.ljzsdut.com
          100.200.108.71 common-mq.jinan-lab.myljzsdutcloud.com
          ttl 60
          reload 1m
          fallthrough
        }
        cache 30
        loop
        reload
        loadbalance
    }
  db.apig-jinan-lab.ljzsdutcloud.cn: |
    $ORIGIN apig-jinan-lab.ljzsdutcloud.cn.
    @ 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. (
            2017042745 ; serial
            7200       ; refresh (2 hours)
            3600       ; retry (1 hour)
            1209600    ; expire (2 weeks)
            3600       ; minimum (1 hour)
            )


    *                                    IN A 10.110.68.74    
  db.ljzsdutcloud.cn: |
    $ORIGIN ljzsdutcloud.cn.
    @ 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. (
            2017042745 ; serial
            7200       ; refresh (2 hours)
            3600       ; retry (1 hour)
            1209600    ; expire (2 weeks)
            3600       ; minimum (1 hour)
            )


    ifcs-innet.jinan-lab                  IN A 100.113.5.197
    jinan-lab                             IN A 100.200.108.71
    registry-jinan-lab                    IN A 100.200.108.71
    git-jinan-lab                         IN A 100.200.108.71
    bssapi-proxy                          IN A 100.200.108.71
    service-boss-jinan-lab                IN A 100.200.108.71
    console-boss-jinan-lab                IN A 100.200.108.71
    service-jinan-lab                     IN A 100.200.108.71
    auth-jinan-lab                        IN A 100.200.108.71
    console-jinan-lab                     IN A 100.200.108.71
    posthouse-jinan-lab                   IN A 100.200.108.71
    jinan-lab                             IN A 100.200.108.71
    mail-jinan-lab                        IN A 100.200.108.71
    cpl-center                            IN A 100.200.108.46
    registry-center                       IN A 100.200.108.46
    *                                     IN A 100.200.108.71    
  db.jinan-lab.ljzsdutcloudoss.com: |
    $ORIGIN jinan-lab.ljzsdutcloudoss.com.
    @ 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. (
            2017042745 ; serial
            7200       ; refresh (2 hours)
            3600       ; retry (1 hour)
            1209600    ; expire (2 weeks)
            3600       ; minimum (1 hour)
            )


    oss                                   IN A 100.200.112.77
    oss-innet                             IN A 100.200.108.77
    *.oss                                 IN A 100.200.112.77    
  db.mgr-apig-jinan-lab.ljzsdutcloud.cn: |
    $ORIGIN mgr-apig-jinan-lab.ljzsdutcloud.cn.
    @ 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. (
            2017042745 ; serial
            7200       ; refresh (2 hours)
            3600       ; retry (1 hour)
            1209600    ; expire (2 weeks)
            3600       ; minimum (1 hour)
            )


    *                                       IN A 10.110.68.74    
  db.mgt-jinan-lab.ljzsdutcloud.cn: |
    $ORIGIN mgt-jinan-lab.ljzsdutcloud.cn.
    @ 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. (
            2017042745 ; serial
            7200       ; refresh (2 hours)
            3600       ; retry (1 hour)
            1209600    ; expire (2 weeks)
            3600       ; minimum (1 hour)
            )


    *                                       IN A 100.200.108.71    
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
  name: coredns
  namespace: kube-system

参考文档

https://laod.cn/dns/coredns-dns.html https://blog.csdn.net/CHAOS_ORDER/article/details/114147109 https://blog.csdn.net/xixihahalelehehe/article/details/113242433 https://blog.csdn.net/bingfan5073/article/details/100958025 https://www.jianshu.com/p/5af2c15f73c2