☰

多播 IP 上的 DNS 解析

tag-icon • tag-icon domain-name-system bind multicast
多播 IP 上的 DNS 解析

编辑：看起来某些 mcast IP 上的 ns 查找不会立即得到失败的答案。有什么建议吗？

我有两个环境，我们新建的环境在 Linux 上运行 BIND。运行 lsof 或 tcpdump 时，它们在尝试解析多播 IP 范围内的地址时会卡住或变慢。是的，我可以忍受没有名称解析，但有些人不能。

在由一些离开公司的人建立的旧环境中，运行 lsof 没有问题。它不会尝试解析 mcast 地址。

有什么线索可以告诉我应该去哪里找吗？我检查了named.conf，没有任何不同。

谢谢W

答案1

诸如此类的工具lsof（事实上，所有工具）都不会专门将多播地址用于名称解析目的。它们会尝试像解析其他地址一样解析多播地址。这很有用，因为这些地址在 Internet 上确实具有有效的名称：

; <<>> DiG 9.7.3 <<>> -x 224.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65271
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;1.0.0.224.in-addr.arpa.                IN      PTR

;; ANSWER SECTION:
1.0.0.224.in-addr.arpa. 28800   IN      PTR     all-systems.mcast.net.

而那些没有这样做的人应该很快得到否定的答复。

; <<>> DiG 9.7.3 <<>> -x 235.255.255.255
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39854
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;255.255.255.235.in-addr.arpa.  IN      PTR

无论哪种情况，回答都应该很快，并且不应该超时。

检查您的缓存解析器名称服务器，确保它能够解析这些地址。如果不能，则可能是防火墙阻止它访问相应的权威服务器或类似的东西。

如果您愿意，您可以随时在本地对这些名称进行短路解析，并通过将它们定义为缓存解析器上的存根区域，指向权威名称服务器上的空区域，从而保证快速响应而无需互联网访问。我怀疑那里没有太多软件可以依赖，例如，224.0.0.1映射到全系统.mcast.net. 你应该服务的区域是224.in-addr.arpa通过239.in-addr.arpa也ffip6.arpa。

相关内容