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) }; };
Können Sie überprüfen, ob die Server tatsächlich noch zwischengespeichert werden? Dieses Verhalten sieht aus wie ein reiner Weiterleitungs-Nameserver.
—
Tomstephens89
Können Sie uns auch mitteilen, ob Sie die Abfrage protokollieren, die Ihr DNS von legitimen Clients erhält ? Eine kurze Beschreibung (falls erforderlich) finden Sie hier . Ich frage, weil es aus Ihrem tcpdump so aussieht, als hätten Sie Ihre DNS-Haupt-IP-Adresse verschleiert, während es noch interessanter sein sollte, zu überprüfen, "wer" "was" fragt.
—
Damiano Verzulli
Können Sie bitte auch etwas mehr über das von Ihnen durchgeführte Upgrade erfahren? Sind Sie absolut sicher, dass keine der Konfigurationsdateien durch die in der neuen Version / RPMs enthaltenen ersetzt wurde?
—
Damiano Verzulli
Wenn sich keine Konfiguration geändert hat, sollten Sie sich das Änderungsprotokoll von Redhat zwischen diesen Versionen genau ansehen, um festzustellen, was möglicherweise für dieses Problem relevant sein könnte. Es wäre wahrscheinlich einfacher gewesen zu sagen, welche Änderung es verursacht hat, wenn die Updates bei ihrer Veröffentlichung installiert worden wären, anstatt ein Jahr lang auf einmal einen Sprung nach vorne zu machen.
—
Håkan Lindqvist
Meine C6.7-Bindung tut dies nicht, daher muss ich mir vorstellen, dass es sich möglicherweise um eine Konfiguration handelt. In diesem Fall könnten wir die (nicht redigierten) Konfigurationsdateien wirklich sehen.
—
MadHatter