coredns不提供IP,只提供名称



通过在我的kubernetes集群中为服务运行dig命令,coredns只提供服务名称,而不提供IP。有人知道为什么会发生这种事吗?

这与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

您会注意到digCoreDNS请求my-release-mysql.A记录,正如我已经提到的,这甚至不是一个有效的域名。

请注意,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请求my-release-mysql.default.svc.cluster.local.A记录时,该记录恰好是该DNS服务器为其保留记录的有效FQDN(与my-release-mysql.不同),我们会在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.

dig不同,像hostnslookup这样的工具在进行DNS查找时会利用/etc/resolv.conf的内容。因此,不向CoreDNS询问原始my-release-mysql,而是添加default.svc.cluster.local后缀,并将此查询发送到Core DNS,例如:

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

相关内容

  • 没有找到相关文章

最新更新