Nach dem Upgrade von BIND auf 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2einige Caching-Nameserver habe ich festgestellt, dass viele ausgehende NS-Abfragen ausgeführt werden, ohne dass Änderungen am eingehenden Datenverkehr oder an den Mustern vorgenommen werden. Infolgedessen verbrauchen die Server viel mehr CPU- und Netzwerkbandbreite, was zu Leistungs- und Kapazitätsproblemen geführt hat.
Dies war bei der zuvor installierten Version 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.1oder 9.8.2-0.30.rc1.el6_6.3(der letzten Version unter CentOS 6.6) nicht der Fall , und ich konnte die Änderung in den Diagrammen sehen, die zum Zeitpunkt des Upgrades passten.
Die Grafiken sind unten, das braune Band entspricht NS-Abfragen. Die Unterbrechungen sind auf den Neustart des Servers nach dem Upgrade von BIND zurückzuführen.
eingehende Anfragen:
ausgehende Anfragen:
Ein tcpdump zeigt Tausende von Abfragen pro Sekunde an, in denen nach NS-Datensätzen für jeden abgefragten Hostnamen gefragt wird. Dies ist seltsam, da ich erwartet habe, dass eine NS-Abfrage für die Domain (example.com) und nicht für den Host (www.example.com) angezeigt wird.
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 der Anfrage eines Kunden zeigt:
## 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)
Ich dachte, dies könnte ein Problem mit der Cache-Population sein, aber es ließ nicht nach, selbst nachdem der Server eine Woche lang ausgeführt wurde.
Ein paar Details:
- Das Problem trat in CentOS 6.6 x86_64 nicht vollständig gepatcht auf
- Auf den Servern wird CentOS 6.7 x86_64 ausgeführt (vollständig gepatcht, Stand 13.08.2015).
- BIND wird in einer Chroot-Umgebung mit zusätzlichen Argumenten ausgeführt
ROOTDIR=/var/named/chroot ; OPTIONS="-4 -n4 -S 8096" - redigierter
named.confInhalt unten
Was geht hier vor sich? Gibt es eine Möglichkeit, die Konfiguration zu ändern, um dieses Verhalten zu vermeiden?
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) }; };
quelle
Antworten:
Die Verhaltensänderung scheint mit diesem Änderungsprotokoll (von RedHats Website) in Zusammenhang zu stehen:
NSDNAME ermöglicht eine Filterrichtlinie basierend auf einem autorisierenden Nameserver. Sie können beispielsweise Folgendes schreiben:
Hiermit werden Antworten für alle Datensätze blockiert, die
a.ns.facebook.comals autorisierender Server fungieren.Wir hatten einen streunenden Eintrag oben in unserer RPZ-Zonendatei:
Durch Entfernen dieses Eintrags wird das Verhalten beendet.
Leider löst das Hinzufügen einer NSDNAME-Direktive das gleiche Verhalten erneut aus.
Gemäß diesem Artikel wurde in BIND 9.10 der CPU-Verbrauch der RPZ-Funktion optimiert. Ein Patch dafür ist nur in RHEL7 verfügbar.
quelle