coredns 不放弃，只是命名

Question

通过为我的 kubernetes 集群中的服务运行 dig 命令，coredns 只提供服务名称而不提供 IP。有谁知道为什么会这样？

Answer 1

这与 dig 实用程序和 DNS 的工作方式有关。

请注意，当您运行时：

dig <your-service-name>

您是从字面上向您的 CoreDNS 询问这个特定的字符串，而简单的服务名称甚至不是有效的域名。看看下面的例子：

root@python-client:/# dig my-release-mysql

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> my-release-mysql
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27445
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;my-release-mysql.              IN      A

;; AUTHORITY SECTION:
.                       86399   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2021012500 1800 900 604800 86400

;; Query time: 19 msec
;; SERVER: 10.3.240.10#53(10.3.240.10)
;; WHEN: Mon Jan 25 16:22:12 UTC 2021
;; MSG SIZE  rcvd: 120

如您所见，它甚至不包含 "ANSWER" 部分 (ANSWER: 0)，如果您仔细查看 "QUESTION" 部分：

;; QUESTION SECTION:
;my-release-mysql.              IN      A

您会注意到 dig 向 CoreDNS 请求 A 记录 my-release-mysql.，正如我已经提到的，它甚至不是一个有效的域名.

请注意，CoreDNS 不会为 my-release-mysql. 保留任何记录，因此当您向它询问此类“域”时，它对此一无所知。

如果您要求 A 记录一个有效的完全合格的域名 (FQDN)，您将得到预期的响应：

root@python-client:/# dig my-release-mysql.default.svc.cluster.local

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> my-release-mysql.default.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47573
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;my-release-mysql.default.svc.cluster.local. IN A

;; ANSWER SECTION:
my-release-mysql.default.svc.cluster.local. 30 IN A 10.3.244.87

;; Query time: 0 msec
;; SERVER: 10.3.240.10#53(10.3.240.10)
;; WHEN: Mon Jan 25 15:59:55 UTC 2021
;; MSG SIZE  rcvd: 76

再次仔细查看"QUESTION" 和"ANSWER" 部分：

;; QUESTION SECTION:
;my-release-mysql.default.svc.cluster.local. IN A

;; ANSWER SECTION:
my-release-mysql.default.svc.cluster.local. 30 IN A 10.3.244.87

如您所见，当我们在 QUESTION SECTION 中向 CoreDNS 询问 A 记录时，my-release-mysql.default.svc.cluster.local. 恰好是一个有效的 FQDN（不像 @ 987654339@)，此 DNS 服务器为其保留记录，我们在 ANSWER SECTION 中得到正确响应。

请注意，dig 实用程序不会使用您的 /etc/resolv.conf 中的条目，这些条目可能如下所示：

root@python-client:/# cat /etc/resolv.conf
nameserver 10.3.240.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

但是，它会向 DNS 服务器查询原始字符串 my-release-mysql.。

host 或 nslookup 等工具与 dig 不同，在进行 DNS 查找时会利用 /etc/resolv.conf 的内容。因此，不是向 CoreDNS 询问原始 my-release-mysql，而是添加 default.svc.cluster.local 后缀并将此类查询发送到 CoreDNS，例如：

root@python-client:/# host my-release-mysql
my-release-mysql.default.svc.cluster.local has address 10.3.244.87

注意，虽然我们将my-release-mysql 作为host 命令的参数，但它与/etc/resolv.conf 文件的search 部分中的第一个条目相匹配，恰好是default.svc.cluster.local 和向 DNS 服务器查询的不是my-release-mysql，而是一个完全合格的域名my-release-mysql.default.svc.cluster.local，它保留了记录。

与nslookup 工具相同：

root@python-client:/# nslookup my-release-mysql
Server:         10.3.240.10
Address:        10.3.240.10#53

Name:   my-release-mysql.default.svc.cluster.local
Address: 10.3.244.87