我已经在VPS服务器上安装了ISPConfig面板的预configuration系统。 当我创buildDNS区域并configuration它们时，服务器工作一段时间，然后一段时间超时和全球DNS（如8.8.8.8）丢失logging和域无法访问（找不到服务器）。
港口是开放的。 虽然有DNS服务器（正在运行，我检查）超时，我可以没有问题通过telnet端口53连接。
操作系统：Centos 6，BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4
当我查询服务器与dig ANY dekorate.pl @5.133.13.32我得到超时。 过了一会儿，它会正常工作。
named-checkconf /var/named/pri.dekorate.pl
/var/named/pri.dekorate.pl:1: unknown option '$TTL' /var/named/pri.dekorate.pl:3: unknown option 'serial,' /var/named/pri.dekorate.pl:4: unknown option 'refresh,' /var/named/pri.dekorate.pl:5: unknown option 'retry,' /var/named/pri.dekorate.pl:6: unknown option 'expire,' /var/named/pri.dekorate.pl:7: unknown option 'minimum,' /var/named/pri.dekorate.pl:10: unknown option '*' /var/named/pri.dekorate.pl:20: unexpected token near end of file
ISPConfig生成的configuration文件。
$TTL 3600 @ IN SOA ns1.dekorate.pl. admin.dekorate.pl. ( 2015040604 ; serial, todays date + todays serial # 7200 ; refresh, seconds 540 ; retry, seconds 604800 ; expire, seconds 86400 ) ; minimum, seconds ; * 86400 A 5.133.13.32 dekorate.pl. 3600 A 5.133.13.32 dekorate.pl. 3600 MX 10 mail.dekorate.pl. dekorate.pl. 3600 NS ns1.dekorate.pl. dekorate.pl. 3600 NS ns2.dekorate.pl. mail 3600 A 5.133.13.32 ns1 86400 A 5.133.13.32 ns2 86400 A 5.133.13.32 www 3600 A 5.133.13.32
要注意：在我的域名注册商的面板上，我将域名委托给ns1.dokrate.pl和ns2.dekorate.pl 并填写IP地址
UPDATE
目前它再次停止工作。 我做了（在我的本地机器上）：
nc -u -z -v 5.133.13.32 53 Connection to 5.133.13.32 53 port [udp/domain] succeeded!
和：
dig ANY dekorate.pl @5.133.13.32 ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.4 <<>> ANY dekorate.pl @5.133.13.32 ;; global options: printcmd ;; connection timed out; no servers could be reached
并在服务器上我做到了：
dig ANY dekorate.pl @localhost ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> ANY dekorate.pl @localhos t ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39 ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;dekorate.pl. IN ANY ;; ANSWER SECTION: dekorate.pl. 3600 IN A 5.133.13.32 dekorate.pl. 3600 IN MX 10 mail.dekorate.pl. dekorate.pl. 3600 IN NS ns2.dekorate.pl. dekorate.pl. 3600 IN NS ns1.dekorate.pl. dekorate.pl. 3600 IN SOA ns1.dekorate.pl. admin.dekorate. pl. 2015040604 7200 540 604800 86400 ;; ADDITIONAL SECTION: mail.dekorate.pl. 3600 IN A 5.133.13.32 ns1.dekorate.pl. 86400 IN A 5.133.13.32 ns2.dekorate.pl. 86400 IN A 5.133.13.32 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Apr 6 17:23:53 2015 ;; MSG SIZE rcvd: 192
每当它发生。 Google DNS服务器无法解决问题。
dig ANY dekorate.pl @8.8.8.8 ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.4 <<>> ANY dekorate.pl @8.8.8.8 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29463 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dekorate.pl. IN ANY ;; Query time: 3081 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon Apr 6 15:28:47 2015 ;; MSG SIZE rcvd: 29
首先，我目前无法重现这个问题。
我不确定这些问题是否真的能够回答这个问题（我不确定这个问题是否真的是一个明确的问题），但是这里是我提出的问题：
named-checkzone是适用于testing区域文件的工具（ named-checkconf用于指定的configuration文件）。
你应该有多个名称服务器 。 我假设你的注册服务商有一个规则，你通过创build两个NSlogging（ ns{1,2}.dekorate.pl ）来解决这个问题，但是如果这些parsing到相同的地址，你实际上已经find了解决方法而不是接受多个域名服务器（尽可能地位于不同位置）的规范来提高可靠性。
DNS主要使用UDP ，而不是TCP。 使用telnettesting使用TCP ，它只与某些边缘情况相关。 （要实际做一个dnstesting，在连接方面与telnet相匹配，你可以做dig +tcp ... ）
从已经尝试了示例查询我已经注意到，你似乎允许从每个人的recursion请求 。 这是一个非常糟糕的主意 ，实际上是在引诱滥用。
总而言之，你真的想要运行你自己的名字服务器吗？
如果你的实际目标是别的，除非真的有必要，否则最好不要运行你自己的附加基础设施。
经过与ISP的一些研究后发现，对这个谜题的回答是：我们被IP上的UDP连接限制所捕获。 限制被取下，一切正常。