BIND - 升級到 CentOS 6.7 後傳出的 NS 查詢增加？

在將 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) }; };

行為的變化似乎與此更改日誌有關（來自 RedHat 的網站）：

2015-02-19 12:00:00
Tomas Hozza <thozza@redhat.com> 32:9.8.2-0.35.rc1:
- Enable RPZ-NSIP and RPZ-NSDNAME during compilation (#1176476)

NSDNAME啟用基於權威名稱伺服器的過濾策略，例如：

a.ns.facebook.com.rpz-nsdname CNAME .

這會阻止對具有a.ns.facebook.com權威伺服器的任何記錄的響應。

我們的 RPZ 區域文件頂部有一個雜散條目：

ns.none.somewhere.rpz-nsdname   CNAME   .

刪除此條目會使行為停止。

不幸的是，添加任何 NSDNAME 指令將再次觸發相同的行為。

根據這篇文章，在 BIND 9.10 中優化了 RPZ 功能的 CPU 消耗。僅適用於 RHEL7 的更新檔。

引用自：https://serverfault.com/questions/713969