Hohe Systemlast durch named

[pibi]

Hallo zusammen

Ich habe hier "auf Arbeit" eine virtuelle Maschine, die unter anderem Nameserver fuer ein Netzwerksegment bzw. eine Domain im Firmennetz ist. Diese Maschine hat jetzt eine Uptime von 472 Tagen und lief bis gestern vollkommen problemlos. Auch named lief absolut zuverlaessig und stoerungsfrei. Die letzt Aenderung an einem Zonenfile erfolgte am 13.Feb 2014.

Gestern um 18:24 Uhr fingen die Probleme an. Dank Ueberwachung durch Nagios wurde eine erhoehe Systemlast festgestellt
CRITICAL - load average: 4.89, 4.54, 4.10Zu dieser Zeit sollte eigentlich niemand mehr am Arbeiten sein. Die Systemlast schwankt seither immer zwischen 3 und 5 hin und her. "top" zeigt fuer den Prozess "named" eine prozentuale CPU-Usage zwischen 60 und 120 (mehrere CPUs zugewiesen).

Wenn ich mittels "tcpdump" anschaue, was so laeuft, sehe ich das hier:
[root@tgz1 ~]# tcpdump -nn net xx.yy.18.36 and port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:22:24.986692 IP xx.yy.18.47.37996 > xx.yy.18.36.53: 62754+ AAAA? geo.tg.ch. (27)
10:22:25.272566 IP xx.yy.18.40.45935 > xx.yy.18.36.53: 48113+ AAAA? wms1.domain.ch. (33)
10:22:25.272665 IP xx.yy.18.36.53 > xx.yy.18.40.45935: 48113* 0/1/0 (85)
10:22:25.272830 IP xx.yy.18.40.41984 > xx.yy.18.36.53: 47262+ AAAA? wms1.domain.ch.domain.ch. (44)
10:22:25.272916 IP xx.yy.18.36.53 > xx.yy.18.40.41984: 47262 NXDomain* 0/1/0 (96)
10:22:25.273130 IP xx.yy.18.40.50927 > xx.yy.18.36.53: 42433+ A? wms1.domain.ch. (33)
10:22:25.273332 IP xx.yy.18.36.53 > xx.yy.18.40.50927: 42433* 1/3/3 A xx.yy.18.52 (163)
10:22:25.637726 IP xx.yy.18.40.43856 > xx.yy.18.36.53: 24184+ AAAA? wms2.domain.ch. (33)
10:22:25.638049 IP xx.yy.18.36.53 > xx.yy.18.40.43856: 24184* 0/1/0 (85)
10:22:25.638222 IP xx.yy.18.40.44712 > xx.yy.18.36.53: 55191+ AAAA? wms2.domain.ch.domain.ch. (44)
10:22:25.638395 IP xx.yy.18.36.53 > xx.yy.18.40.44712: 55191 NXDomain* 0/1/0 (96)
10:22:25.638572 IP xx.yy.18.40.47846 > xx.yy.18.36.53: 34904+ A? wms2.domain.ch. (33)
10:22:25.638701 IP xx.yy.18.36.53 > xx.yy.18.40.47846: 34904* 1/3/3 A xx.yy.18.53 (163)
10:22:25.924535 IP xx.yy.18.40.37516 > xx.yy.18.36.53: 18764+ AAAA? wms.domain.ch. (32)
10:22:25.924623 IP xx.yy.18.36.53 > xx.yy.18.40.37516: 18764* 0/1/0 (84)
10:22:25.924851 IP xx.yy.18.40.36645 > xx.yy.18.36.53: 12136+ AAAA? wms.domain.ch.domain.ch. (43)
10:22:25.924928 IP xx.yy.18.36.53 > xx.yy.18.40.36645: 12136 NXDomain* 0/1/0 (95)
10:22:25.925139 IP xx.yy.18.40.57982 > xx.yy.18.36.53: 60063+ A? wms.domain.ch. (32)
10:22:25.925228 IP xx.yy.18.36.53 > xx.yy.18.40.57982: 60063* 1/3/3 A xx.yy.18.60 (162)
10:22:26.027926 IP xx.yy.18.40.39410 > xx.yy.18.36.53: 24645+ AAAA? wms.domain.ch. (32)
10:22:26.028026 IP xx.yy.18.36.53 > xx.yy.18.40.39410: 24645* 0/1/0 (84)
10:22:26.028254 IP xx.yy.18.40.37011 > xx.yy.18.36.53: 50207+ AAAA? wms.domain.ch.domain.ch. (43)
10:22:26.028346 IP xx.yy.18.36.53 > xx.yy.18.40.37011: 50207 NXDomain* 0/1/0 (95)
10:22:26.028560 IP xx.yy.18.40.37118 > xx.yy.18.36.53: 42115+ A? wms.domain.ch. (32)
10:22:26.028704 IP xx.yy.18.36.53 > xx.yy.18.40.37118: 42115* 1/3/3 A xx.yy.18.60 (162)
10:22:28.566945 IP xx.yy.18.40.44570 > xx.yy.18.36.53: 43613+ PTR? 176.35.yy.xx.in-addr.arpa. (44)
10:22:28.567170 IP xx.yy.18.36.53 > xx.yy.18.40.44570: 43613 NXDomain* 0/1/0 (106)
10:22:28.570096 IP xx.yy.18.40.37396 > xx.yy.18.36.53: 42563+ AAAA? wms.domain.ch. (32)
10:22:28.570308 IP xx.yy.18.36.53 > xx.yy.18.40.37396: 42563* 0/1/0 (84)
10:22:28.570472 IP xx.yy.18.40.54887 > xx.yy.18.36.53: 26858+ AAAA? wms.domain.ch.domain.ch. (43)
10:22:28.570562 IP xx.yy.18.36.53 > xx.yy.18.40.54887: 26858 NXDomain* 0/1/0 (95)
10:22:28.570712 IP xx.yy.18.40.46984 > xx.yy.18.36.53: 41628+ A? wms.domain.ch. (32)
10:22:28.570833 IP xx.yy.18.36.53 > xx.yy.18.40.46984: 41628* 1/3/3 A xx.yy.18.60 (162)
10:22:28.651308 IP xx.yy.18.40.39020 > xx.yy.18.36.53: 33818+ PTR? 176.35.yy.xx.in-addr.arpa. (44)
10:22:28.651400 IP xx.yy.18.36.53 > xx.yy.18.40.39020: 33818 NXDomain* 0/1/0 (106)
10:22:28.652333 IP xx.yy.18.40.59459 > xx.yy.18.36.53: 1670+ AAAA? wms.domain.ch. (32)
10:22:28.652429 IP xx.yy.18.36.53 > xx.yy.18.40.59459: 1670* 0/1/0 (84)
10:22:28.652596 IP xx.yy.18.40.48750 > xx.yy.18.36.53: 9038+ AAAA? wms.domain.ch.domain.ch. (43)
10:22:28.652696 IP xx.yy.18.36.53 > xx.yy.18.40.48750: 9038 NXDomain* 0/1/0 (95)
10:22:28.652857 IP xx.yy.18.40.60458 > xx.yy.18.36.53: 44049+ A? wms.domain.ch. (32)
10:22:28.653108 IP xx.yy.18.36.53 > xx.yy.18.40.60458: 44049* 1/3/3 A xx.yy.18.60 (162)
10:22:28.655464 IP xx.yy.18.40.45585 > xx.yy.18.36.53: 38630+ AAAA? wms.domain.ch. (32)
10:22:28.655539 IP xx.yy.18.36.53 > xx.yy.18.40.45585: 38630* 0/1/0 (84)
10:22:28.655701 IP xx.yy.18.40.54921 > xx.yy.18.36.53: 10692+ AAAA? wms.domain.ch.domain.ch. (43)
10:22:28.655777 IP xx.yy.18.36.53 > xx.yy.18.40.54921: 10692 NXDomain* 0/1/0 (95)
10:22:28.655933 IP xx.yy.18.40.45621 > xx.yy.18.36.53: 42006+ A? wms.domain.ch. (32)
10:22:28.656026 IP xx.yy.18.36.53 > xx.yy.18.40.45621: 42006* 1/3/3 A xx.yy.18.60 (162)
10:22:28.872723 IP xx.yy.18.40.52841 > xx.yy.18.36.53: 353+ PTR? 176.35.yy.xx.in-addr.arpa. (44)
10:22:28.872803 IP xx.yy.18.36.53 > xx.yy.18.40.52841: 353 NXDomain* 0/1/0 (106)
10:22:28.923301 IP xx.yy.18.40.56793 > xx.yy.18.36.53: 31675+ AAAA? wms.domain.ch. (32)
10:22:28.923373 IP xx.yy.18.36.53 > xx.yy.18.40.56793: 31675* 0/1/0 (84)
10:22:28.923532 IP xx.yy.18.40.47349 > xx.yy.18.36.53: 10967+ AAAA? wms.domain.ch.domain.ch. (43)
10:22:28.923679 IP xx.yy.18.36.53 > xx.yy.18.40.47349: 10967 NXDomain* 0/1/0 (95)
10:22:28.923835 IP xx.yy.18.40.52202 > xx.yy.18.36.53: 3434+ A? wms.domain.ch. (32)

54 packets captured
55 packets received by filter
0 packets dropped by kernel
[root@tgz1 ~]#Mehrere Eintraege pro Sekunde, xx.yy.18.36 ist die IP dieser Maschine, "Domain" ist diejenige Domain, fuer die der named zustaendig ist. Komisch ist auch, dass waehrend der Zeit, in der der tcpdump laueft, die Load und die CPU-Usage auf normale Werte heruntergehen. Sobald ich tcpdump stoppe, schnellen beide wieder nach oben.

Wo kann ich mit der Suche nach der Ursache bzw. der Fehlerbehebung ansetzen? Welche Angaben fehlen noch? Das Netz ist gegen aussen abgeschottet (Firewall), es sind nur interne Abfragen moeglich.

Was mir komisch scheint, sind Eintraege im Dump wie
AAAA? wms.domain.ch.domain.ch. (43)

Falls es wichtig ist:
BIND 9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.2
CentOS release 6.2 (Final)

Alle Tips sind willkommen. Danke und Gruss
Pit.

/edit: die Logs zeigen meiner Meinung nach nix besonderes.

[marce]

Absicht, daß die Manschine noch auf CentOS 6.2 läuft?

Zu named und high load findet sich per Google das eine oder andere, daß evtl. auch auf enien Konfigurations-"bug" schließen lässt bzw. auch auf Bugs in der Version.

Mehr kann ich leider vermutlich nicht beitragen...

[pibi]

Absicht, daß die Manschine noch auf CentOS 6.2 läuft?Nein.
Zu named und high load findet sich per Google das eine oder andere, daß evtl. auch auf enien Konfigurations-"bug" schließen lässt bzw. auch auf Bugs in der Version.Ich bin parallel auch schon am Suchen. Was mir komisch vorkommt ist die Tatsache, dass es bis gestern Abend ueber Jahre absolut fehlerfrei funktioniert hat. Daher schliesse ich einen Konfigurationsfehler etc. eigentlich aus.

Evtl. haben die Rechenzentrum-Fuzzis wieder irgendwas geaendert, ohne uns Bescheid zu geben. Waere nicht das erste Mal:-(

Gruss Pit.

[mbo]

Wie lange macht ihr den schon in IPv6? Seit gestern Abend?
Und wer ist denn der .18.40?

[pibi]

Wie lange macht ihr den schon in IPv6?Du sprichst die "AAAA?-Eintraege an? Wissentlich/Willentlich ueberhaupt nicht.
Seit gestern Abend?
Und wer ist denn der .18.40?xx.yy.18.40 ist ein Rechner im gleichen Netz-Segment, der relativ viel Traffic generiert. Aber der darf und muss das;-)

Wuerde es evtl. helfen, auf dieser Kiste einen Caching-only-Nameserver zu installieren?

Gruss Pit.

[mbo]

1) tcpdump mit -w und iptraf
2) prüfen, was tatsächlich Traffic und Bandbreite ausmacht (iptraf Log und dump zB im wireshark etc.)
3) Auf Quellsystem prüfen, welche Prozesse laufen und in Verbindung mit dem Ergebnis auf 2 bringen
4) Ggf. auf Quellhost mit tcpdump und iptraf Clients feststellen ...