主页 / user-193604

André Fernandes's questions

Martin Hope
André Fernandes
Asked: 2017-06-07 05:16:42 +0800 CST
  • 0

我正在为反向 /16 区域运行权威名称服务器，其中每个 IP 都映射到自定义子域。这是通过具有 256 个$GENERATE指令的区域文件来实现的，例如（子网 11.22.0.0/16）：

$GENERATE 0-255 $.1 PTR $.1.22.11.rev.example.com.
$GENERATE 0-255 $.2 PTR $.2.22.11.rev.example.com.
(...)

这很好用，唯一的问题是，每当我们添加“有意义的”反向记录 ( 4.3.22.11.in-addr.arpa. IN PTR www.example.com.) 时，都会导致同一 IP 地址有 2 个 PTR 记录：

4.3.22.11.in-addr.arpa. IN PTR www.example.com.
4.3.22.11.in-addr.arpa. IN PTR 4.3.22.11.rev.example.com.

在大多数情况下，这很好，但在某些情况下，我们需要有一个 PTR 记录。

解决方案是将块“展开”$GENERATE成单独的 PTR 记录并替换有问题的记录。有没有办法覆盖生成的记录而不必扩展整个范围？

此名称服务器在 RHEL6 上运行 BIND 9.8.2。

domain-name-system
Martin Hope
André Fernandes
Asked: 2017-03-25 07:58:26 +0800 CST
  • 1

在调查影响同时受到影响的代理集群的问题时，我发现在建立 SSL 连接时出现了奇怪的行为。

症状是当影响发生时传出的 HTTPS 请求比平时慢，我将其归结为完成 SSL 握手的速度很慢。HTTP 请求/连接不会以同样的方式受到影响。

该问题似乎是由 TCP 3 次握手结束与Client Hello代理发送之间的延迟在出站连接上引起的。之后，握手正常完成，没有延迟。

以下是流量捕获的一些示例：

到api.twitter.com（2.4 秒延迟）： api.twitter.com

到graph.facebook.com（28.4 秒延迟）： 图.facebook.com

即使在第二个示例中进行了重传，Client Hello数据包也不应该花费那么长时间才能发出。

一些事实/考虑：

  • 该问题在一天中的特定时间（大约 1000 小时和 1700 小时）暂时发生，影响所有主机并在大约 30 分钟后消失。后来，同时
  • 这表明存在外部原因（可能是网络），但 tcpdump 输出似乎将责任归咎于本地服务器
  • CPU、负载、内存等所有监控的性能指标当时都正常
  • 它影响所有 SSL 远程主机
  • 随机影响连接，有些行为正常，但许多非常慢
  • 吞吐量（握手后）似乎没有受到影响
  • 一旦问题通过，与相同远程主机的 SSL 连接始终快速
  • curl使用和进行了测试openssl s_client connect，结果相同

需要说明的是：

  1. 是什么原因导致本地出现这种延迟？
  2. Wireshark 会不会骗我？
  3. 我可以查看哪些其他性能指标/统计信息/命令来进一步解决延迟的原因？
  4. 是否有任何网络因素（MTU、接收缓冲区、碎片）可以证明这种行为是合理的？
  5. 我如何找到证据来澄清这是否是我的服务器外部的网络问题？

软件版本：

  • 红帽企业 Linux 服务器版本 5.11 (Tikanga)
  • OpenSSL 0.9.8e-fips-rhel5 2008 年 7 月 1 日
  • 内核 2.6.18-416.el5 #1 SMP 10 月 26 日星期三 12:04:18 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux

编辑：strace信息

按照以下答案的建议做了一些 straces，捕获了这些缓慢的调用：

strace -T -o output.strace openssl s_client -connect 104.244.42.66:443 </dev/null

connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("104.244.42.66")}, 16) = 0 <2.266597>
poll([{fd=4, events=POLLIN}], 1, 5000)  = 1 ([{fd=4, revents=POLLIN}]) <2.387366>
write(3, "\26\3\1\0S\1\0\0O\3\1X\342\24\3556c\354\270T\302\225[\236\317\327\305\205r\177\t/"..., 88) = 88 <0.000034>
read(3, "\26\3\1\0001\2\0", 7)          = 7 <2.556229>
read(3, "\0-\3\1\332\37\254+\240\320\236qA\375\275L\23l\340\355\205x\264\274\273\213\377\323&\345\307O"..., 47) = 47 <0.000011>
read(3, "\26\3\1\v\273", 5)             = 5 <0.000007>
(...)
read(3, "\24\3\1\0\1", 5)               = 5 <2.223115>

该poll()调用是反向 DNS 查找，它正在执行以下操作：

sendto(4, "\3623\1\0\0\1\0\0\0\0\0\0\00266\00242\003244\003104\7in-ad"..., 44, MSG_NOSIGNAL, NULL, 0) = 44 <0.000157>

poll()同一跟踪中的其他此类调用很快。

ssl
Martin Hope
André Fernandes
Asked: 2015-08-14 07:26:20 +0800 CST
  • 7

在将 BIND 升级到9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2一些缓存名称服务器后，我注意到它正在执行大量传出的 NS 查询，而不会改变传入的流量或模式。结果，服务器消耗了更多的 CPU 和网络带宽，这导致了性能和容量问题。

9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.1以前安装的版本或（CentOS 6.6 上的最后一个版本）没有发生这种情况9.8.2-0.30.rc1.el6_6.3，我可以看到与升级时间匹配的图表中的变化。

图表如下，棕色带对应于 NS 查询。中断是由于升级 BIND 后服务器重新启动。

传入查询： 查询输入

传出查询： 查询输出

tcpdump 显示每秒数千次查询，要求为每个查询的主机名提供 NS 记录。这很奇怪，因为我希望看到域 (example.com) 而不是主机 (www.example.com) 的 NS 查询。

16:19:42.299996 IP xxx.xxx.xxx.xxx.xxxxx > 198.143.63.105.53:  45429% [1au] NS? e2svi.x.incapdns.net. (49)
16:19:42.341638 IP xxx.xxx.xxx.xxx.xxxxx > 198.143.61.5.53:    53265% [1au] NS? e2svi.x.incapdns.net. (49)
16:19:42.348086 IP xxx.xxx.xxx.xxx.xxxxx > 173.245.59.125.53:  38336% [1au] NS? www.e-monsite.com. (46)
16:19:42.348503 IP xxx.xxx.xxx.xxx.xxxxx > 205.251.195.166.53: 25752% [1au] NS? moneytapp-api-us-1554073412.us-east-1.elb.amazonaws.com. (84)
16:19:42.367043 IP xxx.xxx.xxx.xxx.xxxxx > 205.251.194.120.53: 24002% [1au] NS? LB-lomadee-adservernew-678401945.sa-east-1.elb.amazonaws.com. (89)
16:19:42.386563 IP xxx.xxx.xxx.xxx.xxxxx > 205.251.194.227.53: 40756% [1au] NS? ttd-euwest-match-adsrvr-org-139334178.eu-west-1.elb.amazonaws.com. (94)

客户端请求的 tcpdump 显示：

## client query
17:30:05.862522 IP <client> > <my_server>.53: 1616+ A? cid-29e117ccda70ff3b.users.storage.live.com. (61)

    ## recursive resolution (OK)
    17:30:05.866190 IP <my_server> > 134.170.107.24.53: 64819% [1au] A? cid-29e117ccda70ff3b.users.storage.live.com. (72)
    17:30:05.975450 IP 134.170.107.24.53 > <my_server>: 64819*- 1/0/1 A 134.170.111.24 (88)

    ## garbage NS queries
    17:30:05.984892 IP <my_server> > 134.170.107.96.53: 7145% [1au] NS? cid-29e117ccda70ff3b.users.storage.live.com. (72)
    17:30:06.105388 IP 134.170.107.96.53 > <my_server>: 7145- 0/1/1 (158)

    17:30:06.105727 IP <my_server> > 134.170.107.72.53: 36798% [1au] NS? cid-29e117ccda70ff3b.users.storage.live.com. (72)
    17:30:06.215747 IP 134.170.107.72.53 > <my_server>: 36798- 0/1/1 (158)

    17:30:06.218575 IP <my_server> > 134.170.107.48.53: 55216% [1au] NS? cid-29e117ccda70ff3b.users.storage.live.com. (72)
    17:30:06.323909 IP 134.170.107.48.53 > <my_server>: 55216- 0/1/1 (158)

    17:30:06.324969 IP <my_server> > 134.170.107.24.53: 53057% [1au] NS? cid-29e117ccda70ff3b.users.storage.live.com. (72)
    17:30:06.436166 IP 134.170.107.24.53 > <my_server>: 53057- 0/1/1 (158)

## response to client (OK)
17:30:06.438420 IP <my_server>.53 > <client>: 1616 1/1/4 A 134.170.111.24 (188)

我认为这可能是缓存填充问题，但即使在服务器运行一周后它也没有消退。

一些细节：

  • 在完全修补的 CentOS 6.6 x86_64 中没有发生此问题
  • 服务器正在运行 CentOS 6.7 x86_64（完全修补，截至 2015-08-13）。
  • BIND 在带有额外参数的 chroot 环境中运行ROOTDIR=/var/named/chroot ; OPTIONS="-4 -n4 -S 8096"
  • named.conf以下内容已删减

这里发生了什么？有没有办法更改配置以避免这种行为？

acl xfer {
(snip)
};

acl bogusnets {
0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3;
};

acl clients {
(snip)
};

acl privatenets {
127.0.0.0/24; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
};

acl ops {
(snip)
};

acl monitoring {
(snip)
};

include "/etc/named.root.key";
key rndckey {
        algorithm       hmac-md5;
        secret          (snip);
};

key "monitor" {
        algorithm hmac-md5;
        secret (snip);
};

controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; };
           inet (snip) allow { monitoring; } keys { monitor; }; };

logging {
        channel default_syslog { syslog local6; };
        category lame-servers { null; };
        channel update_debug {
                 file "/var/log/named-update-debug.log";
                 severity  debug 3;
                 print-category yes;
                 print-severity yes;
                 print-time     yes;
        };
        channel security_info    {
                 file "/var/log/named-auth.info";
                 severity  info;
                 print-category yes;
                 print-severity yes;
                 print-time     yes;
        };
        channel querylog{
                file "/var/log/named-querylog" versions 3 size 10m;
                severity info;
                print-category yes;
                print-time     yes;
        };

        category queries { querylog; };
        category update { update_debug; };
        category security { security_info; };
        category query-errors { security_info; };
};

options {
        directory "/var/named";
        pid-file "/var/run/named/named.pid";
        statistics-file "/var/named/named.stats";
        dump-file "/var/named/named_dump.db";
        zone-statistics yes;
        version "Not disclosed";

        listen-on-v6 { any; };
        allow-query { clients; privatenets; };
        recursion yes;                             // default
        allow-recursion { clients; privatenets; };
        allow-query-cache { clients; privatenets; };
        recursive-clients 10000;
        resolver-query-timeout 5;
        dnssec-validation no;
        querylog no;

        allow-transfer { xfer; };
        transfer-format many-answers;
        max-transfer-time-in 10;
        notify yes;                                // default

        blackhole { bogusnets; };

        response-policy {
                zone "rpz";
                zone "netrpz";
        };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.zones";

statistics-channels { inet (snip) port 8053 allow { ops; }; inet 127.0.0.1 port 8053 allow { 127.0.0.1; }; };

zone "rpz" { type slave; file "slaves/rpz"; masters { (snip) }; };
zone "netrpz" { type slave; file "slaves/netrpz"; masters { (snip) }; };
domain-name-system
Martin Hope
André Fernandes
Asked: 2015-04-23 06:27:07 +0800 CST
  • 1

我正在使用 webmin 来管理 BIND DNS 区域，到目前为止这些区域都是手动管理的。

当我在 webmin（A 或 CNAME）中添加新记录时，它会将 FQDN（主机 + 区域）写入区域文件。虽然这并没有破坏任何东西，但它在已经很大的区域文件中添加了许多不必要的文本。

例子：

# /var/named/master/some.zone.com
# manually-added record
somehost01                    IN    A    10.10.10.1
# added via webmin
somehost02.some.zone.com.     IN    A    10.10.10.2

有没有办法将 webmin 配置为在将记录添加到主区域时不写入 FQDN？

domain-name-system