☰

在 OS X 上快速传播内部 DNS 更改

tag-icon • tag-icon domain-name-system mac-osx mac-osx-server cache internal-dns
在 OS X 上快速传播内部 DNS 更改

今天早上，我们发现（由于转换）我们一个重要服务的 DNS 记录有误。它已在我们的主 DNS 服务器上更改，但辅助站点的客户端看不到此更改。（我们的网络几乎完全运行 OS X 10.5 服务器和 OS X 10.5 客户端）。

为了举例，我先举几个机器的例子：

  • primary = 主 DNS 服务器
  • secondary = 辅助 DNS 服务器
  • 客户端 = 辅助站点上的客户端
  • service.ourdomain.com = DNS 记录已更改的服务

在客户端（通过辅助服务器进行 DNS 查找）上，当探测配置方式时，我得到：

nslookup service.ourdomain.com
** server can't find service.ourdomain.com: NXDOMAIN

nslookup service.ourdomain.com secondary
** server can't find service.ourdomain.com: NXDOMAIN

nslookup service.ourdomain.com primary
(returns appropriate information about how to contact the service)

当我 ssh 进入

  • 次要的，它通过主
  • 或者主要本身，它自己进行 DNS 查找

我得到：

nslookup service.ourdomain.com
(returns appropriate information about how to contact the service)

nslookup service.ourdomain.com secondary
** server can't find service.ourdomain.com: NXDOMAIN

nslookup service.ourdomain.com primary
(returns appropriate information about how to contact the service)

我很困惑。Secondary 似乎知道服务在哪里，但在查询时不返回值。（当然，DNS 条目可以完全独立，或者在查询域名时返回什么，但仍然——它看起来应该知道！）

我已尝试刷新辅助服务器和客户端上的 DNS。（dscacheutil -flushcache）。我还停止并重新启动了辅助服务器上的 DNS。（sudo serveradmin stop dns和sudo serveradmin start dns）

在我们的主站点，我的同事重新启动了主站点和客户端，以便正确解析名称。不幸的是，我们有 14 个辅助站点，如果可能的话，我宁愿不在白天重新启动共享文件的服务器，但如果能解决问题，我会这么做。

根据请求：

host -C ourdomain.com   # [with names substituted]:
ourdomain.com SOA record primary.ourdomain.com. admin.ourdomain.com. 2009121410 21600 3600 604800 345600

[我不知道 admin.ourdomain.com 是什么——我不相信我们有这个名字的盒子；我肯定无法 ping 通它。不过，主 DNS 服务器显示正确。]

此外，根据要求，以下是输出dig service.ourdomain.com @secondary（带有名称替换）：

; <<>> DiG 9.4.3-P1 <<>> service.ourdomain.com @secondary
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19207
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;service.ourdomain.com. IN  A

;; AUTHORITY SECTION:
ourdomain.com.      10800   IN  SOA primary.ourdomain.com. admin.ourdomain.com. 2009121409 21600 3600 604800 345600

;; Query time: 3 msec
;; SERVER: [IP of secondary]#53([IP of secondary])
;; WHEN: Mon Dec 14 10:34:11 2009
;; MSG SIZE  rcvd: 88

输出如下dig service.ourdomain.com @primary：

; <<>> DiG 9.4.3-P1 <<>> service.ourdomain.com @primary
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47885
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;service.ourdomain.com. IN  A

;; ANSWER SECTION:
service.ourdomain.com. 10800    IN  A   [IP of service]

;; AUTHORITY SECTION:
ourdomain.com.      10800   IN  NS  primary.ourdomain.com.

;; ADDITIONAL SECTION:
primary.ourdomain.com.  10800   IN  A   [IP of primary]

;; Query time: 8 msec
;; SERVER: [IP of primary]#53([IP of primary])
;; WHEN: Mon Dec 14 10:34:18 2009
;; MSG SIZE  rcvd: 92

最显著的差异是，次要的没有回复，而主要的说，“；；警告：请求递归但不可用”。

答案1

您可以使用以下方式手动强制区域传输伦德克实用程序。在所有辅助 DNS 服务器上运行此命令：

rndc -p 54 retransfer mydomain.example.com IN com.apple.ServerAdmin.DNS.public

您还可以使用此实用程序重新加载配置，而无需重新启动命名。

rndc -p 54 reload

答案2

在不知道您的配置的情况下，我猜测这是一个缓存问题或 DNS 传播问题。

如果不知道您使用的域名，我无法真正从这里进行测试。我个人不明白为什么人们会忽略这类相关信息，但他们经常这样做。

  • 尝试“host -C yourdomain.com”并告诉我您看到了什么。如果您看到具有不同序列号的不同 SOA 记录，则需要修复 DNS 传播。如果辅助服务器未在此区域的 NS 记录中列出，则在运行 BIND 时添加“also-notify”行。

  • 尝试更改主服务器上的序列号，以确保其被正确更改，并测试传播。

  • 尝试设置更小的更好的负缓存时间，例如 600（10 分钟）左右。这是 SOA 记录中的值之一。

  • 尝试“dig hostname.yourdomain.com @secondaryserver”并查看返回的内容。在主服务器上执行相同操作。如果结果不同，则问题就出在了这里。

  • 如果每个返回坏数据的站点都有很长的缓存时间，您应该能够通过 ssh 连接到它们并简单地重新启动名称服务器，而不必完全重新启动每个站点。如果正在使用 BIND，它将快速重新启动。

答案3

您的辅助服务器正在尝试以递归方式回答（RD- 需要递归，RA- 可用递归）但失败（NXDOMAIN），同时还SOA以权威方式提供记录（AA- 权威答案）。

你在这里似乎有一个稍微奇怪的混合...我们需要确定你的辅助服务器如何知道区域（记录SOA）但不知道区域内的记录。

我会采纳迈克尔的建议 - 在主服务器上增加序列号，然后在辅助服务器上重新启动 BIND 以确保其缓存已被清除。

相关内容