BIND - Zunahme der ausgehenden NS-Abfragen nach dem Upgrade auf CentOS 6.7?

7

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: queries_in

ausgehende Anfragen: queries_out

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) }; };
André Fernandes
quelle
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
2
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

Antworten:

7

Die Verhaltensänderung scheint mit diesem Änderungsprotokoll (von RedHats Website) in Zusammenhang zu stehen:

2015-02-19 12:00:00
Tomas Hozza <[email protected]> 32:9.8.2-0.35.rc1:
- Enable RPZ-NSIP and RPZ-NSDNAME during compilation (#1176476)

NSDNAME ermöglicht eine Filterrichtlinie basierend auf einem autorisierenden Nameserver. Sie können beispielsweise Folgendes schreiben:

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

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:

ns.none.somewhere.rpz-nsdname   CNAME   .

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.

André Fernandes
quelle