我花了好几个月的时间来设置我认为对我们组织的DNS基础设施来说是一个高效和最好的实践configuration。
DNS1 – 托pipe内部区域文件的主服务器，并将外部查询转发给NS1 / NS2
DNS2 – 从属服务器到DNS1用于相同的目的
NS1 – 承载面向WAN的区域文件的DNS服务器，并执行从DNS1 / 2传递给内部客户端的recursion查询
NS2 – 奴隶NS1出于同样的目的
所有四个DNS服务器都是VMware环境中的OpenBSD 5.4虚拟机。
在正常情况下，这个设置在过去的几个月里工作得很好。 但是，我们看到，当DNS1发生故障（虚拟机或ESX服务器崩溃）时， 我们整个组织parsingIP的能力都会下降。
我实施了这个整个解决scheme，意图是如果DNS1不可用，我们的客户会迅速解决DNS2问题。 客户端通过DHCP接收两个DNS IP。 在今天这个特殊的故障中，DNS1是可以ping通的，可以通过SSH访问端口53（netstat -an），但telnet到端口53是从客户端命令行超时（可能是由于ESX主机崩溃问题）。 但是，无论DNS1出了什么问题，我都会假定从客户端查询parsing的angular度来看，DNS2不会影响DNS2（DNS2位于不同的ESX主机上）。
通过进一步的研究 ，我看到Mac OS X（99％的内部客户端）没有为IPparsing设置服务器顺序 – 这意味着它将select所需的任何提供的DNS服务器。 我也看到，在DNS服务器被认为“不合格”之前，DNSparsing超时可能需要30秒到15分钟。
在这个网站上的另一个问题似乎也面临着几年前类似的问题，但没有提供解决scheme。
问题 ：
1）由于大家试图首先使用DNS1并超时（我认为现在在Mac中没有发生），我们的客户是否报告了“停机”？ 他们为什么不试图查询DNS2？
2）如果他们试图查询DNS2，为什么当我的主DNS服务器不可用时（即当它是可ping通的而不能ping的时候），它对直接查询（甚至使用挖掘）作出响应？
2）有什么我需要configuration在Mac客户端，以确保他们能够成功地查询第二个DNS服务器时，另一个closures及时？ （例如： 超时选项 ）
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每次出现故障时拒绝查询，这是预期的行为，这似乎毫无意义，只会增加不必要的复杂性。 任何和所有的帮助表示赞赏！
// $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 { }; };
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
$ cat /etc/resolv.conf lookup file bind nameserver 127.0.0.1 nameserver 10.10.250.36 (NS1) nameserver 10.10.250.37 (NS2)
我在想，DNS1在这样一个奇怪的“大部分但不完全”的状态，它可能已经以某种方式影响DNS2（但是如何以及为什么是真正的问题）。 我将通过closuresDNS1并确保DNS2function按预期进行再次testing。 假设DNS2正常响应查询，这将使我找出如何减lessMac OS X客户端移动到其configuration中的第二个DNS服务器所需的时间。 对此有何build议？ 如上所述，修改resolv.conf文件是超时选项的最佳方法吗？
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