Estou tentando configurar o dnsmasq como um cache local para o consul. Embora isso pareça funcionar bem para escavações normais, o dnsmasq parece permitir apenas transferências parciais de zonas.
Meu resolv.conf:
search x.domain.com y.domain.com z.domain.com domain.com
nameserver 127.0.0.1
nameserver 10.0.0.1
nameserver 10.0.0.2
nameserver 10.0.0.3
options timeout: 2 attempts: 3
As configurações do meu dnsmasq são simplesmente definidas para encaminhar solicitações de .consul para a porta 3000 na mesma caixa, que é minha porta de consul dns. Caso contrário, estou usando o padrão dnsmasq (que encaminha solicitações para os outros dns no resolv.conf).
server=/consul/127.0.0.1#3000
Isso funciona bem para escavações normais e retorna o resultado do servidor localhost, por exemplo. dig consul.service.consul +short retornará:
10.22.1.15
10.22.1.16
10.22.1.17
como esperado. DNS normal (encaminhamento para servidores DNS BIND) também funciona bem, por exemplo. dig host.hosts.domain.com +short retornará 10.22.1.23
No entanto, ao fazer uma transferência de zona dig axfr us1.domain.com , em seguida, a escavação retornará cerca de 700 linhas e, em seguida, travará, sempre no mesmo local. Se eu incluir +retry=0 dig coloca um ;; connection timed out; no servers could be reached na parte inferior após as 700 linhas.
Ao fazer uma transferência de zona do servidor de dns upstream (bind), ele retorna todos os 22k resultados conforme o esperado.
Com a depuração de memória ativada para dig ( -m flag), ela parece travar em
del 0x7f5c8131e010 size 152 file timer.c line 390 mctx 0x17572d0
quando ctrl + c é pressionado, ele mostra um backtrace que consegui rastrear para descobrir que a solicitação não foi concluída, o que suponho ser verdade:
dighost.c:3831: REQUIRE(sockcount == 0) failed, back trace
#0 0x7f5c802c4227 in ??
#1 0x7f5c802c417a in ??
#2 0x41212d in ??
#3 0x405e0e in ??
#4 0x7f5c7de2f445 in ??
#5 0x405e6e in ??
Aborted (core dumped)
Com log extra dnsmasq ativado, posso ver isso para o axfr:
Oct 04 12:17:41 hostname.hosts.adeptra.com dnsmasq[16055]: forwarded us1.domain.com to 10.0.0.1
Oct 04 12:17:41 hostname.hosts.adeptra.com dnsmasq[16055]: reply _kerberos.us1.domain.com is DOMAIN.COM
Oct 04 12:17:41 hostname.hosts.adeptra.com dnsmasq[16055]: reply consul-acl.prod.us1.domain.com is us4
E nos logs de ligação do upstream:
Oct 4 12:20:07 upstreamdns named[17388]: client 10.22.10.20#42228: transfer of 'us1.domain.com/IN': AXFR started
Oct 4 12:20:07 upstreamdns named[17388]: client 10.22.10.20#42228: transfer of 'us1.domain.com/IN': AXFR ended
Eu suspeito que isso tenha algo a ver com tamanhos máximos de pacotes ou algo assim, mas eu tentei configurações variadas de diferentes tamanhos de cache, para aumentar os encaminhamentos de dns e o edns-packet-max. É muito estranho que requisitar o axfr do dns upstream funcione bem, mas através do dnsmasq ele só retorna um resultado parcial antes de fazer com que o dig seja interrompido.
Edit: Eu tentei a versão 1.76, e também compilei o último commit oficial 7cbf497da4100ea0d1c1974b59f9503e15a0cf80 com os mesmos resultados.
Estou rodando o CentOS Linux release 7.5.1804 (Core).
Depois de fazer um tcpdump de ambos com / sem dnsmasq, posso ver que a resposta está sendo dividida em dois pacotes. Por alguma razão, o dig nunca recebe este segundo pacote ao consultar o dnsmasq, então ele simplesmente trava. Os tamanhos dos pacotes são 2521 bytes e 189 bytes, se isso significa alguma coisa para ninguém.
De acordo com o Prof. Simon Kelly (criador do dnsmasq), esse problema é causado pela transferência de zona excedendo 65536 bytes e o dnsmasq não implementa os métodos de continuação usados para enviar as transferências para múltiplas mensagens.
Portanto, grandes transferências de zona não funcionarão e a solução recomendada é falar diretamente com o servidor autoritativo upstream.