BIND9: DNS resolve algumas vezes (!) demora muito ou não funciona

Question

BIND9: DNS resolve algumas vezes (!) demora muito ou não funciona

#1 resposta do (2 votos)

6

Eu tenho um servidor DNS BIND 9.9.5-9 + deb8u8-Raspbian sendo executado em um RPi3 na minha rede. É - para tudo o que não é minha zona de casa - configurado como "somente encaminhamento" com os encaminhadores "{8.8.8.8; 8.8.4.4; 208.67.222.222; 208.67.220.220;};"

a) o caso normal

Normalmente, a resolução do DNS funciona perfeitamente. Mesmo quando os resultados não estão no cache, eles são obtidos dos servidores de encaminhamento e devolvidos aos meus clientes com frequência em menos de 100 ms. Aqui está um exemplo:

client:~ $ time nslookup faz.net
Server:     [my_server]
Address:    [my_server]#53

Non-authoritative answer:
Name:   faz.net
Address: 40.118.6.229

real    0m0.095s […]

É assim que o tráfego parece no tcpdump, tudo é perfeito até onde eu posso ver, e a validação do DNSSEC parece funcionar bem também:

06:48:21.880240 IP [my_client].59563 > [my_server].domain: 614+ A? faz.net. (25)
06:48:21.881246 IP [my_server].28766 > google-public-dns-a.google.com.domain: 30021+% [1au] A? faz.net. (36)
06:48:21.916031 IP google-public-dns-a.google.com.domain > [my_server].28766: 30021 1/0/1 A 40.118.6.229 (52)
06:48:21.917093 IP [my_server].44792 > google-public-dns-a.google.com.domain: 10551+% [1au] DS? faz.net. (36)
06:48:21.952356 IP google-public-dns-a.google.com.domain > [my_server].44792: 10551 0/6/1 (757)
06:48:21.956635 IP [my_server].domain > [my_client].59563: 614 1/0/0 A 40.118.6.229 (41)

b) o caso problemático

No entanto, em alguns casos, leva muito tempo - até 14 segundos - para entregar um resultado. Ou eu não obtenho nenhum (mesmo que um domínio dig @ 8.8.4.4 me dê um endereço apropriado dentro de cerca de 50 ms). Aqui está um exemplo:

client:~ $ time nslookup sueddeutsche.net
Server:     [my_server]
Address:    [my_server]#53

Non-authoritative answer:
Name:   sueddeutsche.net
Address: 213.61.179.40
Name:   sueddeutsche.net
Address: 213.61.179.41

real    0m4.994s […]

E isso é o que acontece nesses 4,9 segundos no tráfego via tcpdump:

06:48:47.608104 IP [my_client].53592 > [my_server].domain: 51417+ A? sueddeutsche.net. (34)
06:48:47.609158 IP [my_server].1507 > google-public-dns-a.google.com.domain: 56678+% [1au] A? sueddeutsche.net. (45)
06:48:48.809517 IP [my_server].27279 > google-public-dns-b.google.com.domain: 22525+% [1au] A? sueddeutsche.net. (45)
06:48:50.009592 IP [my_server].37926 > resolver2.opendns.com.domain: 41597+% [1au] A? sueddeutsche.net. (45)
06:48:50.081468 IP resolver2.opendns.com.domain > [my_server].37926: 41597 2/0/1 A 213.61.179.41, A 213.61.179.40 (77)
06:48:50.082768 IP [my_server].1301 > resolver2.opendns.com.domain: 24793+% [1au] DS? sueddeutsche.net. (45)
06:48:50.233748 IP resolver2.opendns.com.domain > [my_server].1301: 24793 0/1/1 (121)
06:48:50.235373 IP [my_server].57628 > resolver1.opendns.com.domain: 8635+% [1au] DS? sueddeutsche.net. (45)
06:48:50.282862 IP resolver1.opendns.com.domain > [my_server].57628: 8635 0/1/1 (121)
06:48:50.287796 IP [my_server].32127 > google-public-dns-a.google.com.domain: 924+% [1au] DS? sueddeutsche.net. (45)
06:48:51.487853 IP [my_server].61208 > google-public-dns-b.google.com.domain: 39031+% [1au] DS? sueddeutsche.net. (45)
06:48:51.547262 IP google-public-dns-b.google.com.domain > [my_server].61208: 39031 0/6/1 (766)
06:48:51.551509 IP [my_server].52786 > resolver2.opendns.com.domain: 28853+% [1au] Type32769? sueddeutsche.net.dlv.isc.org. (57)
06:48:51.589595 IP resolver2.opendns.com.domain > [my_server].52786: 28853 NXDomain 0/1/1 (125)
06:48:51.592942 IP [my_server].30477 > resolver2.opendns.com.domain: 17693+% [1au] DS? sueddeutsche.net.dlv.isc.org. (57)
06:48:51.790903 IP resolver2.opendns.com.domain > [my_server].30477: 17693 NXDomain 0/1/1 (125)
06:48:51.792342 IP [my_server].6503 > resolver1.opendns.com.domain: 17946+% [1au] DS? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.005244 IP resolver1.opendns.com.domain > [my_server].6503: 17946 NXDomain 0/1/1 (125)
06:48:52.006662 IP [my_server].52356 > google-public-dns-b.google.com.domain: 39821+% [1au] DS? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.334093 IP google-public-dns-b.google.com.domain > [my_server].52356: 39821 NXDomain 0/6/1 (748)
06:48:52.342161 IP [my_server].56473 > resolver1.opendns.com.domain: 17279+% [1au] Type32769? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.382211 IP resolver1.opendns.com.domain > [my_server].56473: 17279 NXDomain 0/1/1 (125)
06:48:52.383674 IP [my_server].52741 > google-public-dns-b.google.com.domain: 65018+% [1au] Type32769? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.424757 IP google-public-dns-b.google.com.domain > [my_server].52741: 65018 NXDomain$ 0/6/1 (748)
06:48:52.430544 IP [my_server].domain > [my_client].53592: 51417 2/0/0 A 213.61.179.40, A 213.61.179.41 (66)

Agora, pelo que eu consigo entender, parece que no 06: 48: 50.081468 o my_server recebeu uma resposta adequada do resolver2.opendns.com, enquanto o google não entregou nada. Em seguida, o my_server pediu a validação do DNSSEC para a qual o resolver2.opendns.com respondeu. Esse não deveria ser o ponto no qual my_server entrega o resultado de volta para my_client? Por que isso não acontece?

Aqui está um segundo caso, para dasoertliche.de, um domínio que deve funcionar sem problemas:

23:39:01.569234 IP [my_client].52174 > [my_server].domain: 57873+ A? dasoertliche.de. (33)
23:39:01.570413 IP [my_server].60368 > resolver2.opendns.com.domain: 39796+% [1au] A? dasoertliche.de. (44)
23:39:01.617721 IP resolver2.opendns.com.domain > [my_server].60368: 39796 1/0/1 A 82.98.79.52 (60)
23:39:01.618712 IP [my_server].41112 > resolver2.opendns.com.domain: 47487+% [1au] DS? dasoertliche.de. (44)
23:39:01.667144 IP resolver2.opendns.com.domain > [my_server].41112: 47487 0/1/1 (100)
23:39:01.668616 IP [my_server].24077 > resolver1.opendns.com.domain: 13310+% [1au] DS? dasoertliche.de. (44)
23:39:01.854327 IP resolver1.opendns.com.domain > [my_server].24077: 13310 0/1/1 (100)
23:39:01.856006 IP [my_server].38412 > google-public-dns-a.google.com.domain: 56597+% [1au] DS? dasoertliche.de. (44)
23:39:03.056263 IP [my_server].35182 > google-public-dns-b.google.com.domain: 45370+% [1au] DS? dasoertliche.de. (44)
23:39:04.256333 IP [my_server].47744 > google-public-dns-a.google.com.domain: 50222+% [1au] DS? dasoertliche.de. (44)
23:39:04.305620 IP google-public-dns-a.google.com.domain > [my_server].47744: 50222| 0/0/1 (44)
23:39:04.306296 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [S], seq 3961861791, win 29200, options [mss 1460,sackOK,TS val 11766745 ecr 0,nop,wscale 7], length 0
23:39:04.345835 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [S.], seq 2448404480, ack 3961861792, win 42408, options [mss 1380,sackOK,TS val 4100658423 ecr 11766745,nop,wscale 7], length 0
23:39:04.345899 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [.], ack 1, win 229, options [nop,nop,TS val 11766749 ecr 4100658423], length 0
23:39:04.346167 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [P.], seq 1:47, ack 1, win 229, options [nop,nop,TS val 11766749 ecr 4100658423], length 4662876+% [1au] DS? dasoertliche.de. (44)
23:39:04.385803 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [.], ack 47, win 332, options [nop,nop,TS val 4100658463 ecr 11766749], length 0
23:39:04.394945 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [P.], seq 1:752, ack 47, win 332, options [nop,nop,TS val 4100658472 ecr 11766749], length 75162876 0/6/1 (749)
23:39:04.394975 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [.], ack 752, win 240, options [nop,nop,TS val 11766753 ecr 4100658472], length 0
23:39:04.398143 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [F.], seq 47, ack 752, win 240, options [nop,nop,TS val 11766754 ecr 4100658472], length 0
23:39:04.401876 IP [my_server].37878 > resolver2.opendns.com.domain: 50849+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:04.437774 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [F.], seq 752, ack 48, win 332, options [nop,nop,TS val 4100658515 ecr 11766754], length 0
23:39:04.437858 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [.], ack 753, win 240, options [nop,nop,TS val 11766758 ecr 4100658515], length 0
23:39:04.456088 IP resolver2.opendns.com.domain > [my_server].37878: 50849 NXDomain 0/1/1 (124)
23:39:04.457411 IP [my_server].38743 > resolver2.opendns.com.domain: 45844+% [1au] DS? dasoertliche.de.dlv.isc.org. (56)
23:39:04.658497 IP resolver2.opendns.com.domain > [my_server].38743: 45844 NXDomain 0/1/1 (124)
23:39:04.659855 IP [my_server].39296 > resolver1.opendns.com.domain: 17204+% [1au] DS? dasoertliche.de.dlv.isc.org. (56)
23:39:04.708134 IP resolver1.opendns.com.domain > [my_server].39296: 17204 NXDomain 0/1/1 (124)
23:39:04.713195 IP [my_server].55899 > google-public-dns-a.google.com.domain: 5854+% [1au] DS? dasoertliche.de.dlv.isc.org. (56)
23:39:04.780837 IP google-public-dns-a.google.com.domain > [my_server].55899: 5854 NXDomain 0/6/1 (736)
23:39:04.786940 IP [my_server].27908 > resolver1.opendns.com.domain: 4148+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:05.267688 IP resolver1.opendns.com.domain > [my_server].27908: 4148 NXDomain 0/1/1 (124)
23:39:05.269026 IP [my_server].38523 > google-public-dns-a.google.com.domain: 60609+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:06.469277 IP [my_server].58501 > google-public-dns-b.google.com.domain: 5485+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:06.572296 IP [my_client].52174 > [my_server].domain: 57873+ A? dasoertliche.de. (33)
23:39:07.669762 IP [my_server].52520 > google-public-dns-a.google.com.domain: 43149+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:07.706440 IP google-public-dns-a.google.com.domain > [my_server].52520: 43149| 0/0/1 (56)
23:39:07.706903 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [S], seq 4227748459, win 29200, options [mss 1460,sackOK,TS val 11767085 ecr 0,nop,wscale 7], length 0
23:39:07.747595 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [S.], seq 719567413, ack 4227748460, win 42408, options [mss 1380,sackOK,TS val 3894129283 ecr 11767085,nop,wscale 7], length 0
23:39:07.747657 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [.], ack 1, win 229, options [nop,nop,TS val 11767089 ecr 3894129283], length 0
23:39:07.747982 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [P.], seq 1:59, ack 1, win 229, options [nop,nop,TS val 11767089 ecr 3894129283], length 5821405+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:07.788998 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [.], ack 59, win 332, options [nop,nop,TS val 3894129324 ecr 11767089], length 0
23:39:07.789344 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [P.], seq 1:739, ack 59, win 332, options [nop,nop,TS val 3894129325 ecr 11767089], length 73821405 NXDomain$ 0/6/1 (736)
23:39:07.789372 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [.], ack 739, win 240, options [nop,nop,TS val 11767093 ecr 3894129325], length 0
23:39:07.790414 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [F.], seq 59, ack 739, win 240, options [nop,nop,TS val 11767093 ecr 3894129325], length 0
23:39:07.796565 IP [my_server].domain > [my_client].52174: 57873 1/0/0 A 82.98.79.52 (49)
23:39:07.831137 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [F.], seq 739, ack 60, win 332, options [nop,nop,TS val 3894129366 ecr 11767093], length 0
23:39:07.831221 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [.], ack 740, win 240, options [nop,nop,TS val 11767097 ecr 3894129366], length 0

Mais uma vez, em 23: 39: 01.617721 meu_servidor recebe a resposta adequada de resolver2.opendns.com, mas por uma razão eu não entendo toda uma inundação de comunicação entre my_server e os servidores do google dns.

Alguma idéia do que está acontecendo aqui e como posso melhorar a situação?

c) Atualizar

Conforme solicitado, veja a saída de free ...

[my_server]:~ $ free
             total       used       free     shared    buffers     cached
Mem:        996448     331696     664752      15752      29808     180668
-/+ buffers/cache:     121220     875228
Swap:            0          0          0

... e vmstat :

[my_server]:~ $ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 664752  29808 180676    0    0     0     1   20   23  0  0 100  0  0

d) Atualização 2:

Acabei de descobrir que meu /var/log/syslog tem entradas referentes ao problema de resolução com dasoertliche.de (o segundo caso problemático). É o seguinte:

Dec 13 23:39:01 raspi-server named[642]:   validating @0x713c0030: de SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:01 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de/DS/IN': 208.67.220.220#53
Dec 13 23:39:01 raspi-server named[642]:   validating @0x712c0030: de SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:01 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de/DS/IN': 208.67.222.222#53
Dec 13 23:39:04 raspi-server named[642]: success resolving 'dasoertliche.de/DS' (in '.'?) after reducing the advertised EDNS UDP packet size to 512 octets
Dec 13 23:39:04 raspi-server named[642]:   validating @0x711c2040: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:04 raspi-server named[642]:   validating @0x73401378: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:04 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de.dlv.isc.org/DS/IN': 208.67.220.220#53
Dec 13 23:39:04 raspi-server named[642]:   validating @0x713c0030: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:04 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de.dlv.isc.org/DS/IN': 208.67.222.222#53
Dec 13 23:39:04 raspi-server named[642]: error (insecurity proof failed) resolving 'dasoertliche.de.dlv.isc.org/DLV/IN': 208.67.220.220#53
Dec 13 23:39:05 raspi-server named[642]:   validating @0x712c0030: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:05 raspi-server named[642]: error (insecurity proof failed) resolving 'dasoertliche.de.dlv.isc.org/DLV/IN': 208.67.222.222#53
Dec 13 23:39:07 raspi-server named[642]: success resolving 'dasoertliche.de.dlv.isc.org/DLV' (in '.'?) after reducing the advertised EDNS UDP packet size to 512 octets

Agora tudo começa a fazer muito mais sentido, eu acredito. O que eu suponho que aconteceu: Parece que o OpenDNS não suporta DNSSEC, então quando my_server recuperou a resolução inicial (correta) do OpenDNS e pediu DNSSEC, deve ter percebido que a resposta é insegura, porque não houve resposta adequada do DNSSEC. Daqui a partir de 23: 39: 01.856006 em diante, ele tentou obter a confirmação do google DNS. Mas o que as linhas a seguir em syslog e tcpdump significam exatamente? Por que há segundos em que o Google não respondeu e o que significam as respostas e a seguinte troca de informações entre o google e o my_server?

dns bind bind9

por Nick 14.12.2016 / 07:39

1 resposta

Tags dns bind bind9

wayland e área de trabalho remota Erro de montagem: a montagem falhou: o arquivo existe

score 2 · Accepted Answer

Depois de mais pesquisas, o problema parece ser o seguinte:

A configuração inicial continha ambos os encaminhadores que eram DNSSEC -capable (GoogleDNS 8.8.8.8, 8.8.4.4) e alguns que não eram (OpenDNS 208.67.222.222, 208.67.220.220). Eu tinha o BIND9 rodando com o DNSSEC totalmente habilitado, conforme a seguinte configuração:

dnssec-enable      yes;
dnssec-validation  yes;
dnssec-lookaside   auto;

a) Sempre que uma solicitação (A?) foi encaminhada para os servidores GoogleDNS , o my_server recebeu uma resposta (A), enviou uma consulta DNSSEC (DS?) e tenho uma resposta adequada. Resolução finalizada, assinatura confirmada, tudo funcionando como um encanto, caso encerrado (veja acima, o caso normal ).

b) Sempre que uma solicitação (A?) é encaminhada para os servidores OpenDNS , o my_server recebe uma resposta (A), envia uma consulta DNSSEC (DS?) que o OpenDNS não conseguiu responder corretamente, pois não suporta DNSSEC. Então BIND9 jogou um erro em syslog , afirmando que got insecure response e tentou obter sua validação DNSSEC em outro lugar (veja acima, o caso problemático ).

Eu ainda não entendo completamente o que aconteceu então, mas obviamente é quando os soluços começaram. Agora eu não sei se os servidores do GoogleDNS não gostaram de fornecer respostas do DS sem ter primeiro o correspondente A? Mas em ambos os casos problemáticos (sueddeutsche.net, dasoertliche.de) parece que as entradas também não foram devidamente assinadas, então o DNSSEC não produziu a validação correta. Assim, a validação DNSSEC-lookaside (DLV) foi iniciada ( Type32769? ) e novamente tudo foi para o sul. Não faço ideia do porquê.

c) Solução: Depois de tudo isso, fiz o seguinte e ainda não encontrei nenhum problema (assim, parece que a pergunta está resolvida):

Primeiro, mudei encaminhadores para apenas

forwarders         { 8.8.8.8; 8.8.4.4; };

para que não haja mais uma mistura de suporte ao DNSSEC. Em segundo lugar, eu comentei

//dnssec-lookaside   auto;

porque depois de vasculhar muitos tcpdumps, parece que sempre que a resolução é lenta, os atrasos são causados pelo GoogleDNS, demorando algum tempo para retornar uma resposta (muito raramente acontece) ou - regularmente - acontecem durante o DLV. Como o DLV está sendo eliminado de qualquer maneira, com entradas que não estão mais disponíveis em 2017

link

Acredito que isso seja aceitável do ponto de vista da segurança.

Agora, uma solução alternativa seria abandonar os servidores do GoogleDNS e usar o OpenDNS como encaminhadores. Mas então eu tenho que comentar todas as entradas do dnssec mencionadas acima, desabilitando completamente o DNSSEC, porque o OpenDNS não suporta isso. Isso deixaria minhas consultas de DNS abertas a ataques que exigiriam adicionar uma camada alternativa de segurança como dnscrypt (como mencionado por Rui F Ribeiro). Embora isso pareça um projeto worthwile (pois ele criptografa completamente o tráfego de DNS, portanto, não apenas mantendo-o inalterado, mas também ilegível por invasores), está um pouco acima do meu orçamento atual.

Quaisquer especialistas em DNS que desejem entrar em contato se as explicações acima fizerem sentido?