CL-2026-03-10-BK-112 · BK-112 Monitor DNS/rede externa para parar o diagnóstico em looping

• Status: (V) conferido e aprovado
• Escopo: plataforma
• Projetos afetados: cerebro, rionoteatro, seuimovel, legalizarj
• BK relacionado: BK-112
• Aprovação humana obrigatória: nao
• Data: 2026-03-10
• Autor: Codex (GeJoRei-VPS)

Resumo

Implantado monitor externo de DNS/rede no Cérebro para separar falha de resolução, falha de saída HTTPS por IPv4 e comportamento de IPv6. O objetivo é interromper o ciclo de correções repetidas baseadas apenas em smoke tests curtos após mudanças em IPv4/IPv6.

Contexto

• Já havia uma intervenção anterior registrada em CHANGELOG_DNS_FIX_20260306.md, com ativação de precedência IPv4 em /etc/gai.conf.
• Em 2026-03-10, a VPS voltou a apresentar falha intermitente em git push com Could not resolve host: github.com, apesar de gai.conf continuar configurado.
• Conclusão operacional: a alteração de precedência IPv4 permaneceu válida, mas não foi suficiente para eliminar a intermitência de DNS/rede externa.

Entregas Técnicas

1) Monitor dedicado de DNS/rede externa

• Criado o script monitor_dns_network_external.sh.
• O script verifica:
• resolução do sistema via getent
• resolução por DoH via dns.google e cloudflare-dns.com, independente do resolver do sistema
• saída HTTPS por IPv4
• saída HTTPS por IPv6
• Alvos monitorados:
• github.com
• api.github.com
• acme-v02.api.letsencrypt.org

2) Critério de alerta mais preciso

• Falha crítica: getent do sistema falha, DoH em A falha nos dois provedores, ou HTTPS em IPv4 falha.
• Telemetria de apoio: status de IPv6 e AAAA fica em log como WARN, sem virar alerta sozinho.
• O alerta usa o mesmo canal WhatsApp já empregado pelos monitores externos do Cérebro.

3) Frequência e persistência operacional

• Agendado no crontab do root para rodar a cada 5 minutos.
• Log dedicado em /www/server/cron/cerebro_dns_network_monitor.log.
• Rotação diária do log com retenção de 14 arquivos.
• Estado local com fail_streak e cooldown para evitar flood.

Evidências Objetivas

• Estado observado em 2026-03-10:
• /etc/gai.conf ainda com precedence ::ffff:0:0/96 100
• /etc/resolv.conf com 1.1.1.1, 8.8.8.8, 9.9.9.9
• Execução validada do monitor:
• github.com: sistema ok, DoH ok, HTTPS IPv4 200, HTTPS IPv6 000
• api.github.com: sistema ok, DoH ok, HTTPS IPv4 200, HTTPS IPv6 000
• acme-v02.api.letsencrypt.org: sistema ok, DoH ok, HTTPS IPv4 200, HTTPS IPv6 200
• Agendamento instalado:
• /5 * /root/cerebro/tools/monitor_dns_network_external.sh >> /www/server/cron/cerebro_dns_network_monitor.log 2>&1
• Logrotate instalado:
• /etc/logrotate.d/cerebro_dns_network_monitor
• Interpretação: o problema recorrente não pode mais ser tratado apenas como “IPv6 antes de IPv4”; agora existe separação objetiva por camada.

Riscos Residuais

• A VPS ainda pode sofrer intermitência real de DNS ou de rota externa; o monitor reduz o tempo de diagnóstico, mas não substitui correção de infraestrutura do provedor.
• github.com e api.github.com seguem sem conectividade IPv6 útil na prática (https6=000), o que hoje fica como telemetria e não como incidente.