我花了几个月的时间来为我们组织的 DNS 基础设施设置我认为是高效且最佳实践的配置。
DNS1- 主服务器托管内部区域文件并将外部查询转发到 NS1/NS2
DNS2- 从属服务器 DNS1 用于相同目的
NS1- DNS 服务器托管面向 WAN 的区域文件，并为内部客户端执行从 DNS1/2 传递的递归查询
NS2- 从属于 NS1，用于相同目的
所有四台DNS服务器都是VMware环境中的OpenBSD 5.4虚拟机。
在正常情况下，这种设置在过去几个月里运行良好。然而，我们发现，当 DNS1 出现故障（VM 或 ESX 服务器崩溃）时，我们整个组织的 IP 解析能力下降了。
我实施整个解决方案的目的是，如果 DNS1 不可用，我们的客户端将快速解析到 DNS2。客户端通过 DHCP 接收两个 DNS IP。在今天的这次特定中断中，DNS1 可以 ping 通，可以通过 SSH 访问，监听端口 53（netstat -an），但从客户端命令行到端口 53 的 telnet 超时（可能是由于 ESX 主机崩溃问题）。但是，无论 DNS1 出了什么问题，我都认为从客户端查询解析的角度来看它不会影响 DNS2（DNS2 位于不同的 ESX 主机上）。
通过进一步研究，我发现 Mac OS X（我们 99% 的内部客户端）没有设置 IP 解析的服务器顺序 - 这意味着它将选择它想要的任何提供的 DNS 服务器。我还发现 DNS 解析的超时时间可能需要 30 秒到 15 分钟，之后 DNS 服务器才会被视为“不合格”。
此网站的另一个问题似乎几年前就面临过类似的问题，但没有解决方案。
问题：
1) 我们客户报告的“停机”是否是由于每个人都尝试先使用 DNS1 并超时（我认为 Mac 现在不会发生这种情况）？为什么他们不尝试查询 DNS2？
2) 如果他们尝试查询 DNS2，为什么当我的主 DNS 服务器不可用时（无论是可 ping 通还是不可 ping 通），它不响应直接查询（即使使用 dig）？
2）我需要在 Mac 客户端上进行什么配置，以确保当另一个 DNS 服务器发生故障时，它们能够及时成功查询第二个 DNS 服务器？（例如：超时选项）
DNS1/2 示例区域文件头：
$TTL 10800 @ IN SOA dns1.myorganization.edu. admin.myorganization.edu. ( 2014111301 ;Serial 3600 ;Refresh for secondary servers to check for updates 600 ;Retry wait time if secondary server update fails 604800 ;Expire 86400 ;Negative caching TTL )
如果需要的话，我也可以提供named.conf文件。
我想继续认为冗余 DNS 设置是明智的，但如果辅助服务器每次 DNS1 出现故障时都会拒绝查询，并且这是预期的行为，那么这似乎毫无意义，只会增加不必要的复杂性。任何帮助都值得感谢！
编辑：附件是 DNS2 的 named.conf 文件 - TSIG 机密和域名已更改以保护无辜者
// $OpenBSD: named-simple.conf,v 1.10 2009/11/02 21:12:56 jakob Exp $
//
// Example file for a simple named configuration, processing both
// recursive and authoritative queries using one cache.
// Update this list to include only the networks for which you want
// to execute recursive queries. The default setting allows all hosts
// on any IPv4 networks for which the system has an interface, and
// the IPv6 localhost address.
//
acl "internal" {
127/8; 10.0.0.0/8; 192.168.1.0/24;
};
options {
version "BIND"; // remove this to allow version queries
#listen-on { any; };
listen-on port 53 { 127.0.0.1; 10.10.250.35; };
listen-on-v6 { none; };
dump-file "data/cache_dump.db";
statistics-file "data/named_stats.txt";
memstatistics-file "data/named_mem_stats.txt";
#empty-zones-enable yes;
# This DNS server is responsible for fully answering the query
recursion yes;
allow-recursion { "internal"; };
allow-query { "internal"; };
# Forward all non-authoritative queries to external DNS servers (ns1/2)
forwarders { 10.10.250.36; 10.10.250.37; };
# Only forward these queries, don't attempt to find it yourself
forward only;
# Don't notify the other NS servers in the zone files of zone updates
notify no;
allow-transfer { none; };
max-cache-size 512M;
zone-statistics yes;
};
key dns1-dns2.myorganization.edu. {
algorithm hmac-md5;
secret "xBBxdjaocjbe33js99zsAG0s/+3g==";
};
# Master server IP
server 10.10.250.1 {
keys { dns1-dns2.myorganization.edu.; };
};
logging {
channel my_query_logging {
#file "log/queries.log";
syslog local6;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel my_security {
#file "log/security.log";
syslog local6;
severity notice;
print-time yes;
print-severity yes;
print-category yes;
};
channel my_default {
#file "log/messages.log";
syslog local6;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category queries { my_query_logging; };
category default { my_default; };
category security { my_security; };
category lame-servers { null; };
};
key "rndc-key" {
algorithm hmac-md5;
secret "PId3xd9Swlc7sniOSGntyDxw==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; }
keys { "rndc-key"; };
};
// Standard zones
//
zone "." {
type hint;
file "etc/root.hint";
};
zone "localhost" {
type master;
file "standard/localhost";
allow-transfer { localhost; };
};
zone "127.in-addr.arpa" {
type master;
file "standard/loopback";
allow-transfer { localhost; };
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "standard/loopback6.arpa";
allow-transfer { localhost; };
};
zone "myorganization.edu" IN {
type slave;
file "slave/db.myorganization.edu.zone";
masters { 10.10.250.1; };
forwarders { };
};
zone "250.10.10.in-addr.arpa" IN {
type slave;
file "slave/db.250.10.10.in-addr.arpa.zone";
masters { 10.10.250.1; };
forwarders { };
};
EDIT2：包括挖掘输出
client-osx$ dig @10.10.250.35 server1.myorganization.edu
; <<>> DiG 9.8.5-P1 <<>> @10.10.250.35 server1.myorganization.edu
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
EDIT3：包括 DNS2 服务器的 resolv.conf 文件
$ cat /etc/resolv.conf
lookup file bind
nameserver 127.0.0.1
nameserver 10.10.250.36 (NS1)
nameserver 10.10.250.37 (NS2)
EDIT4：额外的想法和测试
我认为 DNS1 处于一种奇怪的“基本正常但尚未完全启动”状态，可能在某种程度上影响了 DNS2（但真正的问题是如何以及为什么）。我将再次通过关闭 DNS1 并确保 DNS2 正常运行来测试这一点。假设 DNS2 正常响应查询，这将使我找到如何减少 Mac OS X 客户端在其配置中移动到第二个 DNS 服务器所需的时间的方法。对此有什么建议吗？如上所述，修改 resolv.conf 文件是否是最好的方法？超时选项？
EDIT5：DNS2 路由表
admin@dns2:~ $ route -nv show
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface Label
default 10.10.250.254 UGS 2 469221 - 8 em0
10.10.250/24 link#1 UC 12 0 - 4 em0
10.10.250.1 (DNS1) 00:50:56:a2:01:fe UHLc 1 1658 - 4 em0
10.10.250.4 40:6c:8f:39:f6:81 UHLc 0 1617 - 4 em0
10.10.250.27 00:0c:29:84:9c:3d UHLc 0 16 - 4 em0
10.10.250.36 (NS1) 00:50:56:a2:09:06 UHLc 0 1480 - 4 em0
10.10.250.37 (NS2) 00:50:56:a2:41:7c UHLc 0 2591 - 4 em0
10.10.250.41 00:24:36:f4:83:84 UHLc 0 108 - 4 em0
10.10.250.46 3c:07:54:10:b2:ba UHLc 0 1 - 4 em0
10.10.250.48 00:50:56:a2:04:a6 UHLc 1 663 - 4 em0
10.10.250.49 00:50:56:a2:2d:fb UHLc 1 577 - 4 em0
10.10.250.60 00:50:56:a2:73:2e UHLc 0 45587 - 4 em0
10.10.250.253 00:17:c5:16:53:80 UHLc 0 0 - 4 em0
10.10.250.254 02:04:96:35:e1:8a UHLc 1 0 - 4 em0
127/8 127.0.0.1 UGRS 0 0 33192 8 lo0
127.0.0.1 127.0.0.1 UH 2 3599 33192 4 lo0
224/4 127.0.0.1 URS 0 0 33192 8 lo0