关于程序员:云原生-使用-CoreDNS-构建高性能插件化的DNS服务器

文章目录:

原文连贯:https://mp.weixin.qq.com/s/hAMvwSqWfCQmGM_XzeqOOQ

设为「⭐️ 星标」带你从根底入门到全栈实际再到放弃学习！
波及网络安全运维、利用开发、物联网IOT、学习门路、集体感悟等常识分享。

心愿各位看友多多反对【关注、点赞、评论、珍藏、投币】，助力每一个幻想。

0X00 前言简述

在企业高可用DNS架构部署计划中咱们应用的是传统老牌DNS软件Bind, 然而当初不少企业外部风行容器化部署，所以也能够将Bind替换为 CoreDNS ，因为 CoreDNS 是 Kubernetes 的一个重要组件，稳定性不用放心，于此同时还可将K8S集群SVC解析退出到企业外部的公有的CoreDNS中。

CoreDNS 介绍

什么是CoreDNS?

CoreDNS 由 Go 语言编写是一个高度可扩大和灵便的(插件式) DNS 服务器，能够在多平台环境上运行，来自Cloud Native Computing Foundation（云原生基金会）的开源毕业我的项目，它的设计指标是易于应用且具备弱小的性能。

除此之外，CoreDNS与其余DNS服务器不同，例如（所有优良的）BIND，Knot，PowerDNS 和 Unbound（技术上是一个解析器，但依然值得一提）因为它非常灵活，简直所有性能都外包到插件中，插件能够是独立的，也能够协同工作以执行“DNS性能”，这使得 CoreDNS 不仅能够用作传统的 DNS 服务器，还能够用作服务发现、负载平衡和其余用处。

coredns 官网文档：https://coredns.io/manual/toc/
coredns 公布版本: https://github.com/coredns/coredns/releases/

那么什么是“DNS性能”呢？

CoreDNS 其目标是易于应用且具备弱小的性能，咱们将其定义为一个软件实现 CoreDNS 插件 API, 实现的性能可能会天壤之别,有自身不会创立响应（例如指标或缓存）但会增加性能的插件,而后有一些插件的确会生成一个回应。这些也能够做任何事件：有与 Kubernetes 通信以提供服务发现的插件，从中读取数据的插件文件或数据库。

CoreDNS 外围特点

插件架构（Plugins）：通过插件，能够轻松扩大 CoreDNS 的性能。插件能够用于解决 DNS 申请、转发申请、缓存后果、记录日志等。插件的应用和配置都非常简单。
性能和可靠性：CoreDNS 应用 Go 语言编写，具备很高的性能。同时，它具备主动重试、健康检查和负载平衡等性能，以确保 DNS 服务的可靠性。
易于配置：CoreDNS 应用名为 Caddyfile 的配置文件格式，这种格局简略易懂，易于编写和保护。
Kubernetes 集成：CoreDNS 能够与 Kubernetes 集成，作为集群内的 DNS 服务器。自 Kubernetes 1.11 版本起，CoreDNS 成为 Kubernetes 的默认 DNS 服务器，代替了之前的 kube-dns。

其实从性能角度来看，CoreDNS 更像是一个通用 DNS 计划（相似于 BIND），而后通过插件模式来极大地扩大本身性能，从而能够实用于不同的场景（比方 Kubernetes）。正如官网博客所说：CoreDNS is powered by plugins.

0x01 装置部署

1.编译形式装置

$ git clone -b v1.11.1 https://github.com/coredns/coredns$ cd coredns$ make# 如果本地没有go环境，能够应用docker 的go镜像进行编译$ docker run --rm -i -t -v $PWD:/v -w /v golang:1.21 make

2.二进制形式装置

# 指定最新版本COREDNS_VERSION="1.11.1"# 官网下载wget -O /tmp/coredns_${COREDNS_VERSION}_linux_amd64.tgz https://github.com/coredns/coredns/releases/download/v${COREDNS_VERSION}/coredns_${COREDNS_VERSION}_linux_amd64.tgz# 代理下载wget -O /tmp/coredns_${COREDNS_VERSION}_linux_amd64.tgz https://ghproxy.com/https://github.com/coredns/coredns/releases/download/v${COREDNS_VERSION}/coredns_${COREDNS_VERSION}_linux_amd64.tgz# 解压tar xf /tmp/coredns_${COREDNS_VERSION}_linux_amd64.tgz -C /usr/local/bin# 软连贯设置ln -s /usr/local/bin/coredns /usr/bin/coredns

3.部署配置&验证

Step 1.为了平安，此处为 coredns 服务创立独立用户，以及应用systemd治理此服务。

# 增加独立用户useradd coredns -s /sbin/nologin# 创立配置目录文件及权限mkdir -vp /etc/coredns/touch /etc/coredns/Corefilechown -R coredns /etc/coredns/Corefile# 创立systemd服务治理清单tee -a /usr/lib/systemd/system/coredns.service <<'EOF'[Unit]Description=CoreDNS DNS serverDocumentation=https://coredns.ioAfter=network.target[Service]LimitNOFILE=1048576LimitNPROC=512CapabilityBoundingSet=CAP_NET_BIND_SERVICEAmbientCapabilities=CAP_NET_BIND_SERVICEPermissionsStartOnly=trueNoNewPrivileges=trueWorkingDirectory=/etc/corednsUser=corednsExecStart=/usr/bin/coredns -conf=/etc/coredns/CorefileExecReload=/bin/kill -SIGUSR1 $MAINPIDRestart=on-failure[Install]WantedBy=multi-user.targetEOF# Reload systemd manager configurationsystemctl daemon-reload                       # Auto Start Configurationsystemctl enable coredns

Step 2.设置防火墙规定，以及创立生成coredns服务所需应用的配置文件。

# 设置防火墙容许DNS服务53端口网络通行firewall-cmd --permanent --add-service=dnsfirewall-cmd --reload# 应用 host 插件配置一个简略解析tee -a /etc/coredns/Corefile <<'EOF'.:53 {  # 绑定所有接口  bind 0.0.0.0  # hosts 插件: https://coredns.io/plugins/hosts/  hosts {    # 自定义 weiyigeek.top 子域名解析    # 因为解析的域名少咱们这里间接用hosts插件即可实现需要    # 如果有大量自定义域名解析那么倡议用file插件应用 合乎RFC 1035标准的DNS解析配置文件    192.168.1.2 www.weiyigeek.top    192.168.1.3 blog.weiyigeek.top    192.168.1.250 gitlab.weiyigeek.top    192.168.1.251 harbor.weiyigeek.top    # ttl    ttl 60    # 重载hosts配置    reload 1m    # 继续执行    fallthrough  }  # file enables serving zone data from an RFC 1035-style master file.  # 最初所有的都转发到系统配置的上游dns服务器去解析  forward . 223.6.6.6  # 缓存工夫ttl  cache 120  # 主动加载配置文件的间隔时间  reload 6s  # 输入日志  log  # 输入谬误  errors}EOF# 启动并查看coredns服务systemctl start coredns && systemctl status coredns# 查看监听端口服务lsof -i :53  # COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME  # coredns 4548 coredns    7u  IPv6  36174      0t0  TCP *:domain (LISTEN)  # coredns 4548 coredns    8u  IPv6  36176      0t0  UDP *:domain

Step 3.简略测试部署的Coredns服务是否失常工作。

在 Windows 中应用 nslookup 工具解析指定子域名

# 配置在coredns中的子域解析[weiyigeek@localhost] C:\Users\WeiyiGeek $  nslookup -qt=a gitlab.weiyigeek.top 10.20.176.120服务器:  UnKnownAddress:  10.20.176.120名称:    gitlab.weiyigeek.topAddress:  192.168.1.250# coredns 不存在的子域解析将转发给上游DNS服务器解析[weiyigeek@localhost] C:\Users\WeiyiGeek $  nslookup -qt=a api.weiyigeek.top 10.20.176.120服务器:  UnKnownAddress:  10.20.176.120非权威应答:名称:    api.weiyigeek.topAddress:  82.156.18.253

在 Linux (redhat/centos/kylinos) 中 dig 工具解析指定子域名

dnf install bind-utils -ydig harbor.weiyigeek.top @10.20.176.120dig api.weiyigeek.top @10.20.176.120

0x02 CoreDNS 配置阐明

形容: 通常状况下，一个典型的 Corefile 格局如下所示：

# ZONE : 定义 server 负责的 zone，PORT 是可选项，默认为 53；ZONE:[PORT] {# PLUGIN : 定义 server 所要加载的 plugin, 并且每个 plugin 能够有多个参数； [PLUGIN] ...}

例如，设置根域 . 的解析以及自定义域名的正向与反向解析。

# 根域, 监听 53 端口.:53 {  # whoami 插件：返回解析器的本地 IP 地址、端口和传输，且申请完结时下一个插件将不会被调用。  whoami  # .....}# 定义 Server Zone （正向解析）weiyigeek.top {  whoami  # 可应用 host 或者 file 办法指定解析记录。  file db.weiyigeek.top}  # 同一个 server 然而负责不同 zone 的解析，有不同插件链。weiyigeek.cn {  whoami  # 应用 host 或者 file 办法指定解析记录。  host db.weiyigeek.top}# 定义 Reverse Zone （反向解析 IP 地址对应的域名）  # 形式10.0.10.in-addr.arpa {  whoami}  # 形式210.0.0.0/24 {  whoami}# CoreDNS 除了反对 DNS 协定，也反对 TLS 和 gRPC，即 DNS-over-TLS[3] 和 DNS-over-gRPC 模式tls://example.org:1443 {  #...}

示例演示:
假若，CoreDNS 的 Corefile 配置文件的内容如下所示:

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  proxy . 8.8.8.8  log  health  errors  cache}

从配置文件来看，咱们定义了两个 server（只管有 4 个区块），别离监听在 5300 和 53 端口, 每个进入到某个 server 的申请将依照 plugin.cfg 定义程序执行其曾经加载的插件。

其逻辑图可如下所示, 从图中咱们须要留神只管在 .:53 配置了 health 插件，然而它并为在下面的逻辑图中呈现，其起因是，该插件并未参加申请相干的逻辑（即并没有在插件链上），只是批改了 server 配置。
个别地，咱们能够将插件分为两种：Normal 插件(参加申请相干的逻辑，且插入到插件链中) 和 Other 插件 (不参加申请相干的逻辑，也不呈现在插件链中，只是用于批改 server 的配置, 例如 health，tls 等插件.)

0x03 CoreDNS 插件阐明

插件分类

形容: coredns官网对于插件的分类根本能够分为三种：Plugins(默认)、External Plugins和其余，其中Plugins个别都会被默认编译到coredns的预编译版本中，而External Plugins则不会，官网的文档对外部插件的定义有着明确的解释，次要要求大略是有用、高效、符合标准、文档齐全、通过测试等。

官网插件帮忙文档: https://coredns.io/plugins/

通过官网的二进制部署的coredns可应用--plugins参数验证可用的coredns插件，

$ coredns -pluginsServer types:  dnsCaddyfile loaders:  flag  defaultOther plugins:  dns.acl  dns.any  dns.auto  dns.autopath  dns.azure  dns.bind  dns.bufsize  dns.cache  dns.cancel  dns.chaos  dns.clouddns  dns.debug  dns.dns64  dns.dnssec  dns.dnstap  dns.erratic  dns.errors  dns.etcd  dns.file  dns.forward  dns.geoip  dns.grpc  dns.header  dns.health  dns.hosts  dns.k8s_external  dns.kubernetes  dns.loadbalance  dns.local  dns.log  dns.loop  dns.metadata  dns.minimal  dns.nsid  dns.pprof  dns.prometheus  dns.ready  dns.reload  dns.rewrite  dns.root  dns.route53  dns.secondary  dns.sign  dns.template  dns.timeouts  dns.tls  dns.trace  dns.transfer  dns.tsig  dns.view  dns.whoami  on

舒适提醒: 若所需的插件不存在，请自行下载插件源码到cordns源码的plugin目录，而后在plugin.cfg文件中增加下载的插件名称例如etcd:etcd，又或者间接指定Github中的插件地址他会自行下载，例如 dump:github.com/miekg/dump，最初手动编译coredns源码。

# plugin.cfg.....# 对于在plugin目录下曾经存在的插件，则能够间接写成plugin中的目录名：sign:sign# 对于在plugin目录下不存在的插件dump:github.com/miekg/dump# 需提前准备Golang环境$ git clone -b v1.11.1 https://github.com/coredns/coredns$ cd coredns$ go get github.com/miekg/dump$ go generate$ go build && make

插件工作模式

形容: 当 CoreDNS 启动后，它将依据配置文件启动不同 server ，每台 server 都领有本人的插件链。当有 DNS 申请时，它将顺次经验如下 3 步逻辑：

如果有以后申请的 server 有多个 zone，将采纳贪婪准则抉择最匹配的 zone；
一旦找到匹配的 server，依照 plugin.cfg 定义的程序执行插件链上的插件；
每个插件将判断以后申请是否应该解决，将有以下几种可能：
- 申请被以后插件解决 : 插件将生成对应的响应并回给客户端，此时申请完结，下一个插件将不会被调用，如 whoami 插件；
- 申请被以后插件以 Fallthrough 模式解决 : 如果申请在该插件处理过程中有可能将跳转至下一个插件，该过程称为 fallthrough，并以关键字 fallthrough来决定是否容许此项操作，例如 host 插件，当查问域名未位于 /etc/hosts，则调用下一个插件；
- 申请在处理过程被携带 Hint : 申请被插件解决，并在其响应中增加了某些信息（hint）后持续交由下一个插件解决。这些额定的信息将组成对客户端的最终响应，如 metric 插件

罕用插件介绍

host 插件

形容: 此对于为文件中的区域提供服务很有用，然而仅反对 A、AAAA 和 PTR 记录，如果要在主机插件中没有匹配项的状况下将申请传递给插件链的其余部分，则必须指定该fallthrough选项,请留神每个块{}只能应用一次此插件。

插件参考: https://coredns.io/plugins/hosts/

舒适提醒: 反向查找的 PTR 记录由 CoreDNS 主动生成（基于hosts文件条目）

语法参数:

hosts [FILE [ZONES...]] {  # 条目标模式基于 IETF RFC 952 格局  # IP_address canonical_hostname [aliases...]  [INLINE]  # 生成的记录的 DNS TTL，默认 3600s  ttl SECONDS  # 重载工夫，若为0s示意不重载  reload DURATION  # 禁用生成反向解析    no_reverse  # 如果区域匹配并且无奈生成任何记录，请将申请传递给下一个插件。  fallthrough [ZONES...]}

示例演示:
示例1.大量不同域名解析间接写在 Corefile 配置文件中

.:53 {  # 绑定interface ip  bind 127.0.0.1  # 先走本机的hosts  hosts {    # 因为解析的域名少咱们这里间接用hosts插件即可实现需要    192.168.1.2 www.weiyigeek.top weiyigeek.top    192.168.1.3 blog.weiyigeek.top    # ttl    ttl 60    # 重载hosts配置    reload 1m    # 继续执行    fallthrough  }  # file enables serving zone data from an RFC 1035-style master file.  # 最初所有的都转发到系统配置的上游dns服务器去解析  forward . /etc/resolv.conf  # 缓存工夫ttl  cache 120  # 主动加载配置文件的间隔时间  reload 6s  # 输入日志  log  # 输入谬误  errors}

示例2.将解析写在独立的/etc/coredns/hosts文件中，也能够写在 /etc/hosts 看集体爱好。

tee /etc/coredns/Corefile <<'EOF'.:53 {  bind 10.20.176.120  hosts /etc/coredns/hosts  # 未配置解析的将转发到上游服务器。  forward . 8.8.8.8:53  # 缓存工夫ttl  cache 120  # 主动加载配置文件的间隔时间  reload 6s  # 输入日志  log  # 输入谬误  errors}EOFtee /etc/coredns/hosts <<'EOF'# weiyigeek.com192.168.1.2 www.weiyigeek.com192.168.1.3 blog.weiyigeek.com# weiyigeek.top192.168.1.250 gitlab.weiyigeek.top192.168.1.251 harbor.weiyigeek.topEOF

批改配置文件后重启coredns以便于验证解析:

[weiyigeek@localhost] C:\Users\WeiyiGeek $  nslookup -qt=a www.weiyigeek.com 10.20.176.120服务器:  UnKnownAddress:  10.20.176.120名称:    www.weiyigeek.comAddress:  192.168.1.2[weiyigeek@localhost] C:\Users\WeiyiGeek $  nslookup -qt=a harbor.weiyigeek.top 10.20.176.120服务器:  UnKnownAddress:  10.20.176.120名称:    harbor.weiyigeek.top

file 插件（罕用）

形容: 如果有大量自定义域名记录解析那么则倡议应用file插件，配置须要合乎RFC 1035标准的DNS解析配置文件，如果区域文件蕴含签名（即，应用 DNSSEC），返回正确的 DNSSEC 答案

语法参数

# DBFILE : 要读取和剖析的数据库文件# ZONES：它应该是权威的, 若为空则配置块中的区域被应用。file DBFILE [ZONES...] {  # 在 SOA 版本更改时执行区域从新加载的工夫距离  reload DURATION}

示例演示:
示例1.应用file插件创立外部域名的正向以及反向解析。

tee /etc/coredns/Corefile <<'EOF'.:53 {  forward . 223.6.6.6:53 114.114.114.114:53 /etc/resolv.conf  # 下面etcd未查问到的申请转发给设置的DNS服务器解析  # 启用缓存，放弃正高速缓存大小 5000 和 负高速缓存大小 2500.  cache {    success 5000    denial 2500  }  log  errors}# 正向解析weiyigeek.top {  file /etc/coredns/weiyigeek.top.conf  forward . 223.6.6.6:53   log  errors}# 反向解析20.10.in-addr.arpa {  file /etc/coredns/db.20.10.conf  log  errors}EOF# 正向解析配置文件，合乎 RFC 1035 规范格局tee /etc/coredns/weiyigeek.top.conf <<'EOF'$TTL 86400$ORIGIN weiyigeek.top.@ 3600 IN  SOA  dns1.weiyigeek.top. master.weiyigeek.top. (                          20210313      ; Serial                          50400         ; Refresh                          86400         ; Retry                         604800         ; Expire                          86400 )       ; Negative Cache TTL;; name servers - NS records@ IN NS dns1dns1 IN A 10.20.176.120; root server - A records@ IN A 192.168.10.71; child server recordswww IN A 192.168.10.71blog IN A 192.168.10.70EOFtee /etc/coredns/db.20.10.conf <<'EOF'$TTL 86400@ 3600 IN  SOA  20.10.in-addr.arpa. master.weiyigeek.top. (                          20210313      ; Serial                          50400         ; Refresh                          86400         ; Retry                         604800         ; Expire                          86400 )       ; Negative Cache TTL;; name servers - NS records@ IN NS dns1.weiyigeek.top.; PTR Records120.176 IN PTR dns1.weiyigeek.top.EOF

重启cordns服务验证服务: systemctl restart coredns && sleep 6 &&systemctl status coredns

$ nslookup -qt=a weiyigeek.top 10.20.176.120$ nslookup -qt=ns weiyigeek.top 10.20.176.120$ nslookup -qt=ptr weiyigeek.top 10.20.176.120

执行后果:

etcd 插件

形容: 应用etcd插件咱们能够将解析存入到etcd的解析记录进行读取，它能够实现了DNS服务发现，然而它不适宜作为一个通用的DNS区域数据插件, 只实现了DNS记录类型的一个子集。

语法示例

etcd [ZONES...] {  fallthrough [ZONES...]  path PATH  endpoint ENDPOINT...  credentials USERNAME PASSWORD  tls CERT KEY CACERT  stubzones}# 参数解析fallthrough: 如果区域匹配但没有记录能够生成，将申请传递给下一个插件path: etcd中的门路，默认值/skydnsendpoint: etcd endpointcredentials: etcd的用户名和明码tls： CAstubzones 启用存根区域性能

示例演示:

.:53 {  forward . 223.6.6.6}weiyigeek.local {  file weiyigeek.local {     reload 30s   }}etcd-weiyigeek.local:53 {  etcd {    stubzones # 启用存根区域性能,stubzone仅在位于指定的第一个区域下方的etcd树中实现    path /root    endpoint http://172.22.50.98:2379   # 此处依据本人部署的etcd地址进行填写。    fallthrough # 如果区域匹配但不能生成记录，则将申请传递给下一个插件  }  forward . 8.8.8.8:53 8.8.4.4:53 /etc/resolv.conf  # 下面etcd未查问到的申请转发给设置的DNS服务器解析  cache 160  loadbalance   # 开启DNS记录轮询策略  log           # 打印日志}

应用 etcd 插件利用目录构造查问相干条目，已下面的 etcd-weiyigeek.local 为例，配置的etcd的path为/root 。

# etcd-weiyigeek.local 的 A 记录 为 172.22.50.28$./etcdctl put /root/local/etcd-weiyigeek/ '{"host":"172.22.50.28","ttl":60}'# demo1.etcd-weiyigeek.local 的 A 记录 为 172.22.50.128$./etcdctl put /root/local/etcd-weiyigeek/demo1 '{"host":"172.22.50.128","ttl":60}'# demo2.etcd-weiyigeek.local 的 A 记录 为 172.22.50.228$./etcdctl put /root/local/etcd-weiyigeek/demo2 '{"host":"172.22.50.228","ttl":60}'

kubernetes 插件

形容: kubernetes 插件容许从kubernetes集群读取区域数据, 插件地址: https://coredns.io/plugins/kubernetes/

语法参数:

kubernetes [ZONES...] {  endpoint URL  tls CERT KEY CACERT  kubeconfig KUBECONFIG [CONTEXT]  namespaces NAMESPACE...  labels EXPRESSION  pods POD-MODE  endpoint_pod_names  ttl TTL  noendpoints  fallthrough [ZONES...]  ignore empty_service}

示例演示:
在 K8S 集群中的 Pod 内的 DNS 域名解析配置文件为 /etc/resolv.conf，文件内容如下所示。

#定义 DNS 服务器的 IP 地址。nameserver xx.xx.0.10 # 设置域名的查找后缀规定，查找配置越多，阐明域名解析查找匹配次数越多。# Kubernetes 集群匹配有 kube-system.svc.cluster.local、svc.cluster.local、cluster.local 3 个后缀，最多进行 8 次查问能力失去正确解析后果。search kube-system.svc.cluster.local svc.cluster.local cluster.local #定义域名解析配置文件选项，例如该参数设置成 ndots:5，阐明如果拜访的域名字符串内的点字符数量超过 ndots 值，则认为是残缺域名，并被间接解析；如果有余 ndots 值，则追加 search 段后缀再进行查问。options ndots:5

CoreDNS 配置:

$ kubectl get cm -n kube-system coredns  -o yaml.....Corefile: |  .:53 {      errors  # 输入错误信息，若需调试请设置为debug      log     # 输入客户端申请解析信息      health { # 健康检查配置        lameduck 15s # 敞开延迟时间      }      ready # CoreDNS 插件，个别用来做可读性查看，能够通过 http://localhost:8181/ready 读取。      # CoreDNS Kubernetes 插件，提供集群内服务解析能力。      kubernetes {{.ClusterDomain}} in-addr.arpa ip6.arpa {        pods verified        fallthrough in-addr.arpa ip6.arpa      }      # 增加自定义 hosts。      hosts {        192.168.1.41  www.weiyigeek.top        192.168.1.40  harbor.weiyigeek.top        fallthrough in-addr.arpa ip6.arpa      }      prometheus :9153 # CoreDNS 本身 metrics 数据接口。      # 当域名不在 Kubernetes 域时，将申请转发到预约义的解析器。      forward . /etc/resolv.conf {         max_concurrent 1000      }      cache 30 # DNS 查问缓存。      loop  #环路检测，如果检测到环路，则进行 CoreDNS。      reload #容许主动从新加载已更改的 Corefile, 编辑 ConfigMap 配置后，请期待两分钟以使更改失效。      loadbalance #循环 DNS 负载均衡器，能够在答案中随机 A、AAAA、MX 记录的程序。  }

dnssec 插件

形容: DNSSEC 反对对服务的数据进行动静 DNSSEC 签名，每个服务器块只能应用此插件一次。
插件地址: https://coredns.io/plugins/dnssec/

语法参数:

dnssec [ZONES... ] {  # 指定读取的Key文件  key file KEY...  # 应用缓存来存储 RRSIGs，缺省值为 10000  cache_capacity CAPACITY}

示例演示:

$ mkdir -vp /etc/coredns/dnssec && cd /etc/coredns/dnssec# 应用 dnssec-keygen 工具生成密钥文件$ dnssec-keygen -a ECDSAP256SHA256 -f KSK weiyigeek.top  Generating key pair.  # 生成的密钥的根本名称  Kweiyigeek.top.+013+29388# 生成的 public key 与 private key$ lsKweiyigeek.top.+013+29388.key  Kweiyigeek.top.+013+29388.private # 配置文件 Corefile 示例$ cat /etc/coredns/Corefile.:53 {  forward . 223.6.6.6:53  log  errors}# 正向解析weiyigeek.top {  file /etc/coredns/db.weiyigeek.top.conf  dnssec {    key file /etc/coredns/dnssec/Kweiyigeek.top.+013+29388.key  }  log  errors}

常识扩大: 应用dnssec-keygen生成DNSSEC密钥对，您须要依照以下步骤操作：

关上命令行工具，并确保您的计算机上曾经装置了BIND软件包，该软件包通常蕴含在DNS服务器软件包中。
运行以下命令来生成DNSSEC密钥对：
```
dnssec-keygen -a <algorithm> -b <bits> -n <type> -f KSK/ZSK <domain>
```
- <algorithm>：抉择用于生成密钥对的加密算法，常见的算法有RSA、DSA、ECDSA等。
- <bits>：指定密钥的位数，个别为1024、2048、4096等。
- <type>：指定密钥的类型，能够是KSK（Key Signing Key）或ZSK（Zone Signing Key）。
- <domain>：指定域名，生成的密钥对将与该域名相关联。
运行命令后，将会生成两个密钥文件，一个是私钥文件（以".private"结尾），另一个是公钥文件（以".key"结尾）。

请留神，生成的密钥对须要妥善保存，私钥文件应窃密，而公钥文件须要增加到您的域名的DNS记录中。接下来，咱们将探讨如何将公钥增加到DNS记录中。

sign 插件

形容: sign 插件用于对区域进行签名并将 DNSSEC 记录增加到区域文件。
插件地址: https://coredns.io/plugins/sign/

语法参数:

# DBFILE 读取和剖析的区域数据库文件, 即合乎 RFC 1035 规范格式文件sign DBFILE [ZONES...] {  # 指定用于对区域进行签名的密钥（能够有多个）  key file|directory KEY...|DIR...  # 指定 CoreDNS 应在其中保留已签名区域的 DIR，默认为 /var/lib/coredns 目录（须要自行验证）  directory DIR}

应用示例:

# 1.应用 dnssec-keygen 生成 KSK 类型的 密钥$ cd /etc/coredns/dnssec/$ dnssec-keygen -a ECDSAP256SHA256 -f KSK weiyigeek.top  # Generating key pair.  # Kweiyigeek.top.+013+04352$ ls  # Kweiyigeek.top.+013+04352.key  Kweiyigeek.top.+013+04352.private# 2.创立已签名区域的 DIR 目录 /var/lib/coredns mkdir -vp /var/lib/coredns # 3.Corefile 配置示例文件$ cat /etc/coredns/Corefile# 正向解析weiyigeek.top {  file /etc/coredns/db.weiyigeek.top.conf  sign /etc/coredns/db.weiyigeek.top.conf {    key file /etc/coredns/dnssec/Kweiyigeek.top.+013+29388.key  }}# 4.运行后生成的signd文件cat /var/lib/coredns/db.weiyigeek.top.signed

tsig 插件

形容: tsig 定义 TSIG 密钥，验证传入的 TSIG 签名申请并签订响应。
插件地址: https://coredns.io/plugins/tsig/

舒适提醒: 对于 Secondary 主从区域传输暂不反对此插件，心愿后续官网欠缺。

语法参数:

tsig [ZONE...] {  # 显式的设置密钥的名称 以及 TSIG 密钥  secret NAME KEY  # 应用文件形式的加载TSIG 密钥（举荐）  secrets FILE  # 指定用于的查问类型，例如 `AXFR IXFR`  require [QTYPE...]}

应用示例:

# 1.应用 tsig-keygen 工具生成TSIG 密钥tsig-keygen -a hmac-sha256 dns-tsig-keygen. >  /etc/coredns/dnssec/dns-tsig-keygen.secretscat /etc/coredns/dnssec/dns-tsig-keygen.secrets# key "dns-tsig-keygen." {#   algorithm hmac-sha256;#   secret "ec5onpRjGTIaOBZa+zGl2VJbwdJl1qlzj+NZNHrhhk4=";# };# 2.Corefile 配置文件示例# 要求 TSIG 签名的事务能力收回 AXFR IXFRweiyigeek.top {  file /etc/coredns/db.weiyigeek.top.conf  tsig {    secrets /etc/coredns/dnssec/dns-tsig-keygen.secrets    require AXFR IXFR  }  transfer {    to *  }}# 要求 TSIG 签名的事务能力收回所有申请auth.zone {  tsig {    secret auth.zone.key. NoTCJU+DMqFWywaPyxSijrDEA/eC3nK0xi3AMEZuPVk=    require all  }  forward . 10.1.0.2}

本文至此结束，更多技术文章，纵情期待下篇好文！

参考起源:【 WeiyiGeek Blog's - 花开堪折直须折，莫待无花空折枝】

作者主页: 【 https://weiyigeek.top 】

博客地址: 【 https://blog.weiyigeek.top 】

本文由mdnice多平台公布

0X00 前言简述

CoreDNS 介绍

0x01 装置部署

1.编译形式装置

2.二进制形式装置

3.部署配置&验证

0x02 CoreDNS 配置阐明

0x03 CoreDNS 插件阐明

插件分类

插件工作模式

罕用插件介绍

host 插件

file 插件 （罕用）

etcd 插件

kubernetes 插件

dnssec 插件

sign 插件

tsig 插件

file 插件（罕用）