☰

ISPConfig 上的绑定/命名 DNS 服务器有时可以工作

tag-icon • tag-icon domain-name-system bind dns-zone named-conf
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 file

ISPConfig 生成的配置文件。

$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

答案1

首先，我目前无法重现该问题。

我不确定这些是否真的回答了这个问题（我不确定这是否真的是一个明确的问题）但是这是我对已经提出的内容的看法：

  • named-checkzone工具是否适合测试区域文件 （named-checkconf用于命名配置文件）。

  • 你应该有多个名称服务器。我假设您的注册商有一个规则，您可以通过创建两个NS记录（ns{1,2}.dekorate.pl）来解决这个问题，但由于这些记录解析到同一个地址，您实际上只是找到了一种绕过其策略执行的方法，而不是接受拥有多个名称服务器（尽可能分散）的常态以提高可靠性。

  • DNS 主要使用 UDP，而不是 TCP。您的测试telnet使用 TCP，这只与某些极端情况有关。（要实际进行与telnet连通性相匹配的 DNS 测试，您可以执行dig +tcp ...。）

  • 通过尝试示例查询，我注意到您似乎允许每个人的递归请求。 这是一个非常糟糕的想法这实际上会招致辱骂。


总而言之，您真的愿意运行自己的名称服务器吗？
如果您的实际目标是其他东西，那么除非真的有必要，否则最好不要运行自己的其他基础设施。

答案2

经过与 ISP 的一番研究，我们发现这个谜题的答案是：我们被 IP 上设置的 UDP 连接限制所困扰。限制被取消，一切正常。

答案3

我自己也遇到过这种情况。无论在 ISPconfig 上编辑多少次，DNS 记录都不会更新。解决方案相当简单。当您在区域配置中犯错误时，bind 将产生。呃/etc/bind 文件夹中的文件。该文件将包含您的“新”区域设置，但只要您的配置中仍存在错误，旧设置就会保留。在我的情况下，它是错误的服务车辆记录。删除后，ispconfig/bind 将使用正确的配置文件，而不是旧配置文件。

相关内容