☰

BIND DNS 中的镜头名称耗时过长

tag-icon • tag-icon domain-name-system bind
BIND DNS 中的镜头名称耗时过长

我已经设置了绑定 DNS，并尝试在其中放置一个用于解析短名称的条目。此操作已解决，但耗时太长，有时 DNS 会超时。短名称是 s3.ngsfdellpe

来自 named.conf 的条目

options {
    listen-on port 53 { 127.0.0.1;10.209.194.15; };
    listen-on-v6 port 53 { ::1; };
    directory   "/var/named";
    dump-file   "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query {any;};
    allow-recursion {any;};
    //recursion no;

    //dnssec-enable yes;
    //dnssec-validation yes;
    //dnssec-lookaside auto;

    /* Path to ISC DLV key */
    bindkeys-file "/etc/named.iscdlv.key";

    managed-keys-directory "/var/named/dynamic";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
    type hint;
    file "named.ca";
};


zone"vxctf8500.com" IN {
type master;
file "forward.vxctf8500.com";
allow-update { none; };
};
zone"106.209.10.in-addr.arpa" IN {
type master;
file "reverse.vxctf8500.com";
allow-update { none; };
};

前进区文件 ::

$TTL 1D
@   IN SOA ns1.vxctf8500.com. root.vxctf8500.com. (
                    0   ; serial
                    1D  ; refresh
                    1H  ; retry
                    1W  ; expire
                    3H )    ; minimum

       IN NS       vxctf8500.com.
       IN A     10.209.194.15



ns1   IN A 10.209.194.15

s3.ngsfdellpe   IN  A   10.209.106.59
s3.ngsfdellpe   IN  A   10.209.106.53
s3.ngsfdellpe   IN  A   10.209.106.54
s3.ngsfdellpe   IN  A   10.209.106.55
s3.ngsfdellpe   IN  A   10.209.106.56

反向区域文件::

$TTL 1D
@   IN SOA  ns1.vxctf8500.com. root.vxctf8500.com. (
                    0   ; serial
                    1D  ; refresh
                    1H  ; retry
                    1W  ; expire
                    3H )    ; minimum


                        IN NS   vxctf8500.com.
15                      IN PTR      ns1.vxctf8500.com.



59       IN PTR      s3.ngsfdellpe.
53       IN PTR      s3.ngsfdellpe.
54       IN PTR      s3.ngsfdellpe.
55       IN PTR      s3.ngsfdellpe.
56       IN PTR      s3.ngsfdellpe.

答案1

你能举个例子（命令/输出）吗？如何您正在尝试解析名称以及/etc/resolv.conf测试机器上的内容。

reverse-zonefile 中的尾随点表明 LHS 名称是 FQDN，但实际上并非如此，因此您的反向条目应如下所示：

59 IN PTR s3.ngsfdellpe.vxctf8500.com.

解析“短名称”与您如何配置权威 DNS 无关，它只取决于客户端（例如search或Linux 上domain的指令/etc/resolv.conf）如何处理这个问题并在进行实际 DNS 查找之前将后缀附加到名称后。

答案2

正如 powo 在他的回答中所说，这很可能是您的配置造成的/etc/resolv.conf。一般规则是，您拥有的搜索域越多，当服务器无法访问时，DNS 查找失败所需的时间就越长。

假设 glibc 中的 nss_dns 模块，查找失败的最大时间公式（不以 结尾）.将如下所示：

（w+1）xyz

  • 瓦是定义的域数search。除非服务器的 FQDN 没有域组件，否则不可能低于 1。（或者您设置了等效值，domain .）
  • X是timeout:x（默认值为 5），如 中所定义/etc/resolv.conf。
  • 是是attempts:y（默认值为 2），如 中所定义/etc/resolv.conf。
  • 是是DNS 查找时未响应的nameserver条目数。仅前三个条目有效，因此该数字始终为 0 到 3 之间的数字。/etc/resolv.conf

首选解决方案是确保您的 DNS 服务器始终响应，必要时使用负载平衡器。在无法实现此目的的情况下，应注意搜索域的数量（X) 对 DNS 查找失败所需的时间有巨大影响。

（是的，ndots这也会产生影响，但是这太过迂腐了。）

相关内容