CoreDNS是使用go语言编写的快速灵活的DNS服务，采用链式插件模式，每个插件实现独立的功能，底层协议可以是tcp/udp，也可以是TLS，gRPC等。默认监听所有ip地址，可使用bind插件指定监听指定地址。
在垣曲等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供成都网站制作、网站设计 网站设计制作按需网站建设,公司网站建设,企业网站建设,高端网站设计,网络营销推广,外贸网站制作,垣曲网站建设费用合理。
格式如下
SCHEME是可选的，默认值为dns://，也可以指定为tls://，grpc://或者https://。
ZONE是可选的，指定了此dnsserver可以服务的域名前缀，如果不指定，则默认为root，表示可以接收所有的dns请求。
PORT是选项的，指定了监听端口号，默认为53，如果这里指定了端口号，则不能通过参数-dns.port覆盖。
一块上面格式的配置表示一个dnsserver，称为serverblock，可以配置多个serverblock表示多个dnsserver。
下面通过一个例子说明，如下配置文件指定了4个serverblock，即4个dnsserver，第一个监听端口5300，后面三个监听同一个端口53，每个dnsserver指定了特定的插件。
下图为配置的简略图
a. 从图中可看到插件执行顺序不是配置文件中的顺序，这是因为插件执行顺序是在源码目录中的plugin.cfg指定的，一旦编译后，顺序就固定了。
b. .根serverblock虽然指定了health，但是图中却没有，这是因为health插件不参与dns请求的处理。能处理dns请求的插件必须提供如下两个接口函数。
dns请求处理流程
收到dns请求后，首先根据域名匹配zone找到对应的dnsserver(最长匹配优先)，如果没有匹配到，则使用默认的root dnsserver。
找到dnsserver后，就要按照插件顺序执行其中配置的插件，当然并不是配置的插件都会被执行，如果某个插件成功找到记录，则返回成功，否则根据插件是否配置了fallthrough等来决定是否执行下一个插件。
plugin.cfg
源码目录下的plugin.cfg指定了插件执行顺序，如果想添加插件，可按格式添加到指定位置。
源码目录下的Makefile根据plugin.cfg生成了两个go文件：zplugin.go和zdirectives.go。
core/dnsserver/zdirectives.go将所有插件名字放在一个数组中。
codedns 主函数
codedns.go 首先导入了包"github.com/coredns/coredns/core/plugin"，此包内只有一个文件zplugin.go，此文件为自动生成的，主要导入了所有的插件，执行每个插件的init函数。
接着执行 run.go Run
此文件又引入了包"github.com/coredns/coredns/core/dnsserver"，其init函数在 dnsserver/register.go 文件中，如下所示，主要是注册了serverType
剩下的就是解析参数，解析配置文件后，执行caddy.Start。
这里就是根据配置文件中指定的serverblock，执行插件的setup进行初始化，创建对应的server，开始监听dns请求
tcp协议调用Serve，udp协议调用ServePacket
收到DNS请求后，调用ServeDNS，根据域名匹配dnsserver，如果没有匹配不到则使用根dnsserver，然后执行dnsserver中配置的插件
以k8s插件为例
参考
//如何写coredns插件
//coredns源码分析
//NodeLocal DNSCache
当浏览器访问某个网站域名或者应用服务通过域名方式访问API接口的时候，需要用IP和port建立TCP连接或者复用底层连接，IP地址的获取依赖对域名的解析，完成解析的角色称为域名解析器（dns resolver）。解析的大致过程就是检查cache是否有该记录，本地hosts文件是否有，都没有命中就查询dns server进行CNAME和A记录的查询。在linux系统下，dns server的IP一般在/etc/resolv.conf文件中。
域名解析常用dig命令，以及在 进行域名解析测试。
考虑到域名IP地址不是经常变动，减少查询dns的冗余，并显著降低高QPS应用服务查询dns的压力(最后一节有benchmark对比)，需要对dns信息进行缓存。因为软件应用不同、开发语言不同、操作系统不同，dns resolver的实现和封装也不同，会遇到不同的层面的cache。比如windows的dns resolver会有cache，linux默认不缓存；go语言可以选择cgo或者自己实现的dns resolver；chrome浏览器也会有自己的cache。
dns cache除了好处以外，也带来了其他问题。比如dns cache可能被恶意病毒修改，将真实IP改成钓鱼网站的IP，对用户进行诱导和钓鱼。还有在服务发现的这种特定场景下，dns cache是不被允许的，会出现IP更新不及时导致API流量的损失和错误，例如部署上线或者宕机，相比之下，运维响应的时长会造成更大的损失。但为了解决这个问题，在client和server端中间增加一层代理，dns记录指向这个代理。如图：
代理职责一般有：
代理一般分为：
四层代理对外暴露的IP一般称为虚IP(VIP)
example_test.go
性能对比：
从对比中可看出：go的pure resolver因没有cache和网络不稳定的因素，总耗时较多。而cgo的resolver比较稳定且耗时较低。
linux或类unix系统是没有操作系统级别的dns cache。除非安装了dnsmasq或者
nscd(Name Service Caching Daemon)，并开启。
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中来扩展功能。
开发新的 plugins 非常容易，但是需要懂GO语言并且深入了解DNS如何工作 。CoreDNS 抽象出了大量的DNS细节，所以你只需要关注你需要开发的功能即可。
从Kubernetes 1.11版本开始，Kubernetes集群的DNS服务由CoreDNS提供。CoreDNS是CNCF基金会的一个项目，是用Go语言实现的高性能、插件式、易扩展的DNS服务端。CoreDNS解决了KubeDNS的一些问题，例如dnsmasq的安全漏洞、externalName不能使用stubDomains设置，等等。
CoreDNS支持自定义DNS记录及配置upstream DNS Server，可以统一管理Kubernetes基于服务的内部DNS和数据中心的物理DNS。
CoreDNS没有使用多个容器的架构，只用一个容器便实现了KubeDNS内3个容器的全部功能。
从kubernetes官方提供的 coredns.yml 文件中，不难看出coredns服务配置至少需要一个ConfigMap、一个Deployment和一个Service共3个资源对象。ConfigMap coredns 主要配置文件Corefile的内容：
其中主要有二个地方来解析配置
1、这段配置的意思是cluster.local后缀的域名都是kubernetes内部域名，coredns会监控service的变化来修改域名的记录
2、如果coredns没有找到dns记录，则去找 /etc/resolv.conf 中的 nameserver 解析
接下来使用一个带有nslookup工具的Pod来验证DNS服务能否正常工作：
通过nslookup进行测试。
查找defaul命名空间存在的ng-deploy-80服务
如果某个Service属于不同的命名空间，那么在进行Service查找时，需要补充Namespace的名称，组合成完整的域名。下面以查找kubernetes-dashboard服务为例，
众所周知, DNS 服务器用于将域名转换为 IP (具体为啥要转换建议复习下 7 层网络模型). Linux 服务器中 DNS 解析配置位于 /etc/resolv.conf , 在 Pod 中也不例外,
DNS 策略可以逐个 Pod 来设定。当前kubernetes支持这4中DNS 策略
如果我们不填dnsPolicy, 默认策略就是 ClusterFirst 。
kubelet 在起 pause 容器的时候，会将其 DNS 解析配置初始化成集群内的配置。配置: 它的 nameserver 就是指向 coredns 的
k8s里面有4种DNS策略， 而coredns使用的DNS策略就是Default， 这个策略的意思就是继承宿主机上的/etc/resolve.conf, 所以coredns Pod 里面的/etc/resolve.conf 的内容就是宿主机上的内容。
在集群中 pod 之间互相用 svc name 访问的时候，会根据 resolv.conf 文件的 DNS 配置来解析域名，下面来分析具体的过程。
pod 的 resolv.conf 文件主要有三个部分，分别为 nameserver、search 和 option。而这三个部分可以由 K8s 指定，也可以通过 pod.spec.dnsConfig 字段自定义。
nameserver
resolv.conf 文件的第一行 nameserver 指定的是 DNS 服务的 IP，这里就是 coreDNS 的
clusterIP：
也就是说所有域名的解析，都要经过coreDNS的虚拟IP 10.100.0.2 进行解析， 不论是内部域还是外部域名。
search 域
resolv.conf 文件的第二行指定的是 DNS search 域。解析域名的时候，将要访问的域名依次带入 search 域，进行 DNS 查询。
比如我要在刚才那个 pod 中访问一个域名为 ng-deploy-80的服务，其进行的 DNS 域名查询的顺序是：
options
resolv.conf 文件的第三行指定的是其他项，最常见的是 dnots。dnots 指的是如果查询的域名包含的点 “.” 小于 5，则先走 search 域，再用绝对域名；如果查询的域名包含点数大于或等于 5，则先用绝对域名，再走 search 域。K8s 中默认的配置是 5。
也就是说，如果我访问的是 a.b.c.e.f.g ，那么域名查找的顺序如下：
通过 svc 访问
在 K8s 中，Pod 之间通过 svc 访问的时候，会经过 DNS 域名解析，再拿到 ip 通信。而 K8s 的域名全称为 "service-name.namespace.svc.cluster.local"，而我们通常只需将 svc name 当成域名就能访问到 pod，这一点通过上面的域名解析过程并不难理解。
参考
（1）K8S落地实践 之 服务发现（CoreDNS）
（2）自定义 DNS 服务
（3）Kubernetes 服务发现之 coreDNS
（4）Kubernetes 集群 DNS 服务发现原理
（5）Kubernetes之服务发现和域名解析过程分析
方法如下：
1、打开网络和共享中心；
2、选择本地连接；
3、选择属性，双击IPv4协议即可设置本地局域网IP和DNS。
