André Fernandes's questions

Estou executando um servidor de nomes autoritativo para uma zona /16 reversa, onde cada IP é mapeado para um subdomínio personalizado. Isso é obtido por um arquivo de zona com 256 $GENERATEdiretivas, por exemplo (sub-rede 11.22.0.0/16):

$GENERATE 0-255 $.1 PTR $.1.22.11.rev.example.com.
$GENERATE 0-255 $.2 PTR $.2.22.11.rev.example.com.
(...)

Isso funciona bem, o único problema é que sempre que adicionarmos um registro reverso "significativo" ( 4.3.22.11.in-addr.arpa. IN PTR www.example.com.) resultará em uma situação em que existem 2 registros PTR para o mesmo endereço IP:

4.3.22.11.in-addr.arpa. IN PTR www.example.com.
4.3.22.11.in-addr.arpa. IN PTR 4.3.22.11.rev.example.com.

Na maioria das vezes isso é bom, mas em alguns casos precisamos ter um único registro PTR.

A solução foi "desenrolar" o $GENERATEbloco em registros PTR individuais e substituir o que ofendeu. Existe uma maneira de substituir um registro gerado sem precisar expandir todo o intervalo?

Este servidor de nomes executa o BIND 9.8.2 no RHEL6.

Ao investigar um problema que aflige um cluster de proxies que são todos afetados simultaneamente, descobri um comportamento estranho no estabelecimento de conexões SSL.

O sintoma é que as solicitações HTTPS de saída são mais lentas do que o normal quando o impacto ocorre. Eu atribuí isso à lentidão ao concluir o handshake SSL. As solicitações/conexões HTTP não são afetadas da mesma forma.

O problema parece ser causado em conexões de saída por um atraso entre o final do handshake TCP de 3 vias e o envio do Client Hellopelos proxies. Depois disso, o handshake é concluído normalmente, sem atrasos.

Aqui estão alguns exemplos de capturas de tráfego:

Para api.twitter.com(atraso de 2,4 segundos):

Para graph.facebook.com(atraso de 28,4 segundos):

Mesmo com as retransmissões do segundo exemplo, o Client Hellopacote não deveria demorar tanto para sair.

Alguns fatos/considerações:

• O problema ocorre temporariamente em horários específicos do dia (por volta das 10h e 17h), afeta todos os hosts e desaparece em cerca de 30min. mais tarde, simultaneamente
• isso indicaria uma causa externa (rede, talvez), mas a saída do tcpdump parece colocar a culpa no servidor local
• CPU, carga, memória e todos os outros indicadores de desempenho monitorados estão normais naquele momento
• afeta todos os hosts remotos SSL
• afeta conexões aleatoriamente, algumas se comportam normalmente, mas muitas são extremamente lentas
• a taxa de transferência (após o aperto de mão) não parece ser afetada
• depois que o problema passa, as conexões SSL com os mesmos hosts remotos são consistentemente rápidas
• testes foram feitos com curle openssl s_client connect, com os mesmos resultados

O que precisa de esclarecimento:

1. O que poderia estar causando tal atraso no lado local?
2. Poderia o wireshark estar me enganando?
3. que outros indicadores/estatísticas/comandos de desempenho eu poderia examinar para solucionar melhor as causas do atraso?
4. existe algum fator de rede (MTU, buffers de recebimento, fragmentação) que possa justificar esse comportamento?
5. como posso encontrar evidências para esclarecer se é um problema de rede externo aos meus servidores?

Versões de software :

• Red Hat Enterprise Linux Server versão 5.11 (Tikanga)
• OpenSSL 0.9.8e-fips-rhel5 01 de julho de 2008
• kernel 2.6.18-416.el5 #1 SMP qua 26 de outubro 12:04:18 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux

Editar: informações do strace

Fiz alguns straces conforme recomendado por uma resposta abaixo, peguei essas chamadas lentas:

strace -T -o output.strace openssl s_client -connect 104.244.42.66:443 </dev/null

connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("104.244.42.66")}, 16) = 0 <2.266597>
poll([{fd=4, events=POLLIN}], 1, 5000)  = 1 ([{fd=4, revents=POLLIN}]) <2.387366>
write(3, "\26\3\1\0S\1\0\0O\3\1X\342\24\3556c\354\270T\302\225[\236\317\327\305\205r\177\t/"..., 88) = 88 <0.000034>
read(3, "\26\3\1\0001\2\0", 7)          = 7 <2.556229>
read(3, "\0-\3\1\332\37\254+\240\320\236qA\375\275L\23l\340\355\205x\264\274\273\213\377\323&\345\307O"..., 47) = 47 <0.000011>
read(3, "\26\3\1\v\273", 5)             = 5 <0.000007>
(...)
read(3, "\24\3\1\0\1", 5)               = 5 <2.223115>

A poll()chamada é uma pesquisa DNS reversa, está fazendo:

sendto(4, "\3623\1\0\0\1\0\0\0\0\0\0\00266\00242\003244\003104\7in-ad"..., 44, MSG_NOSIGNAL, NULL, 0) = 44 <0.000157>

Outras poll()chamadas no mesmo rastreamento são rápidas.

Depois de atualizar o BIND para 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2alguns servidores de nomes de cache, notei que ele está fazendo 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.1ou 9.8.2-0.30.rc1.el6_6.3(a última versão no CentOS 6.6), e pude ver a mudança nos gráficos correspondentes ao momento da atualização.

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

consultas recebidas:

consultas de saída:

Um tcpdump mostra milhares de consultas/s solicitando registros NS para cada nome de host consultado. Isso é estranho, pois eu esperava ver uma consulta NS para o domínio (example.com) e não para o host (www.example.com).

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 da solicitação de um cliente mostra:

## 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)

Eu pensei que isso poderia ser um problema de preenchimento de cache, mas não diminuiu mesmo depois que o servidor estiver em execução por uma semana.

Alguns detalhes:

• O problema não acontecia no CentOS 6.6 x86_64 totalmente corrigido
• Os servidores estão executando o CentOS 6.7 x86_64 (totalmente corrigido, a partir de 2015-08-13).
• BIND está rodando em um ambiente chroot'ed com argumentos extrasROOTDIR=/var/named/chroot ; OPTIONS="-4 -n4 -S 8096"
• named.confconteúdo editado 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) }; };

Estou usando o webmin para gerenciar as zonas BIND DNS que até agora eram gerenciadas manualmente.

Quando adiciono um novo registro no webmin (A ou CNAME), ele está gravando o FQDN (host + zona) no arquivo de zona. Embora isso não esteja quebrando nada, está adicionando muito texto desnecessário ao já enorme arquivo de zona.

Exemplo:

# /var/named/master/some.zone.com
# manually-added record
somehost01                    IN    A    10.10.10.1
# added via webmin
somehost02.some.zone.com.     IN    A    10.10.10.2

Existe uma maneira de configurar o webmin para não gravar o FQDN quando um registro é adicionado a uma zona mestre?