BIND - aumenta as consultas NS de saída após a atualização para o CentOS 6.7?

Question

Depois de atualizar o BIND para 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2 em alguns servidores de nomes de armazenamento em cache, notei que ele está realizando muitas consultas NS de saída, sem alterações no volume ou padrões de tráfego de entrada. Como resultado, os servidores estão consumindo muito mais CPU e largura de banda de rede, o que levou a problemas de desempenho e capacidade.

Isso não aconteceu com a versão instalada anteriormente 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.1 ou 9.8.2-0.30.rc1.el6_6.3 (a última versão no CentOS 6.6), e eu pude ver a mudança nos gráficos correspondendo à hora da atualização.

Os gráficos estão abaixo, a faixa marrom corresponde a consultas NS. As quebras são devidas à reinicialização do servidor após a atualização do BIND.

consultas recebidas:

consultasdesaída:

Umtcpdumpmostramilharesdeconsultas/ssolicitandoregistrosNSparacadanomedehostconsultado.Issoéestranho,comoeuesperavaverumaconsultaNSparaodomínio(example.com)enãoohost(www.example.com).

16:19:42.299996IPxxx.xxx.xxx.xxx.xxxxx>198.143.63.105.53:45429%[1au]NS?e2svi.x.incapdns.net.(49)16:19:42.341638IPxxx.xxx.xxx.xxx.xxxxx>198.143.61.5.53:53265%[1au]NS?e2svi.x.incapdns.net.(49)16:19:42.348086IPxxx.xxx.xxx.xxx.xxxxx>173.245.59.125.53:38336%[1au]NS?www.e-monsite.com.(46)16:19:42.348503IPxxx.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.367043IPxxx.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.386563IPxxx.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)

tcpdumpdasolicitaçãodeumclientemostra:

##clientquery17:30:05.862522IP<client>><my_server>.53:1616+A?cid-29e117ccda70ff3b.users.storage.live.com.(61)##recursiveresolution(OK)17:30:05.866190IP<my_server>>134.170.107.24.53:64819%[1au]A?cid-29e117ccda70ff3b.users.storage.live.com.(72)17:30:05.975450IP134.170.107.24.53><my_server>:64819*-1/0/1A134.170.111.24(88)##garbageNSqueries17:30:05.984892IP<my_server>>134.170.107.96.53:7145%[1au]NS?cid-29e117ccda70ff3b.users.storage.live.com.(72)17:30:06.105388IP134.170.107.96.53><my_server>:7145-0/1/1(158)17:30:06.105727IP<my_server>>134.170.107.72.53:36798%[1au]NS?cid-29e117ccda70ff3b.users.storage.live.com.(72)17:30:06.215747IP134.170.107.72.53><my_server>:36798-0/1/1(158)17:30:06.218575IP<my_server>>134.170.107.48.53:55216%[1au]NS?cid-29e117ccda70ff3b.users.storage.live.com.(72)17:30:06.323909IP134.170.107.48.53><my_server>:55216-0/1/1(158)17:30:06.324969IP<my_server>>134.170.107.24.53:53057%[1au]NS?cid-29e117ccda70ff3b.users.storage.live.com.(72)17:30:06.436166IP134.170.107.24.53><my_server>:53057-0/1/1(158)##responsetoclient(OK)17:30:06.438420IP<my_server>.53><client>:16161/1/4A134.170.111.24(188)

Euacheiqueissopoderiaserumproblemadepreenchimentodecache,maselenãodiminuiumesmodepoisqueoservidorfoiexecutadoporumasemana.

Algunsdetalhes:

• OproblemanãoaconteceunoCentOS6.6x86_64totalmentecorrigido
• OsservidoresestãoexecutandooCentOS6.7x86_64(totalmentecorrigido,de2015-08-13).
• OBINDestásendoexecutadoemumambientechroot'edcomargumentosextrasROOTDIR=/var/named/chroot;OPTIONS="-4 -n4 -S 8096"
• redacted named.conf conteúdo abaixo

O que está acontecendo aqui? Existe uma maneira de alterar a configuração para evitar esse comportamento?

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

    

Answer 1

A mudança no comportamento parece estar relacionada a este changelog (do site da RedHat):

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 ativa uma política de filtragem baseada em nameserver autoritativo, pode-se escrever por exemplo:

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

que bloqueia respostas para qualquer registro que tenha a.ns.facebook.com como servidor autoritativo.

Tivemos uma entrada perdida no topo do nosso arquivo de zona RPZ:

ns.none.somewhere.rpz-nsdname   CNAME   .

Remover esta entrada faz com que o comportamento pare.

Infelizmente, adicionar qualquer diretiva NSDNAME acionará o mesmo comportamento novamente.

De acordo com artigo , no BIND 9.10 o consumo de CPU do recurso RPZ é otimizado. Um patch para isso só estará disponível no RHEL7.