Domain-Name-System
ISPConfig 上的綁定/命名 DNS 伺服器有時可以工作
我已經在 VPS 伺服器上安裝了帶有 ISPConfig 面板的預配置系統。當我創建 DNS 區域並配置它們時，伺服器會工作一段時間，然後超時，全域 dns（如 8.8.8.8）會失去記錄和無法訪問的域（找不到伺服器）。
埠是開放的。雖然 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我得到了超時。一段時間後它會正常工作。命名檢查配置 /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 fileISPConfig 生成的配置文件。
$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 地址
更新
它目前再次停止工作。我做了（在我的本地機器上）：
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
經過對 ISP 的一些研究，結果證明這個謎題的答案是：我們被 IP 上設置的 UDP 連接限制所擷取。限制被取消，一切正常。
首先，我目前無法重現該問題。
我不確定這是否真的回答了這個問題（我不確定是否真的有一個明確的問題），但這是我對所提出的內容的看法：
named-checkzone是適用於測試區域文件的工具 （named-checkconf適用於命名的配置文件）。- 您應該擁有多個名稱伺服器。我假設您的註冊商有一個規則，您可以通過製作兩條
NS記錄 (ns{1,2}.dekorate.pl) 來解決這些問題，但是由於這些記錄解析到同一個地址，您實際上只是找到了一種方法來繞過他們的策略執行，而不是接受擁有多個名稱伺服器的規範（盡可能不同的位置）以提高可靠性。- DNS 主要使用 UDP，而不是 TCP。您的測試**
telnet使用 TCP**，這僅與某些邊緣情況相關。（要實際進行與telnet連接性匹配的 dns 測試，您可以執行此操作dig +tcp ...。）- 通過嘗試範例查詢，我注意到您似乎允許來自所有人的遞歸請求。這是一個非常糟糕的主意，實際上會招致濫用。
總而言之，您真的準備好執行自己的名稱伺服器了嗎？
如果您的實際目標是其他東西，最好不要執行您自己的其他基礎設施，除非確實有必要。