Diário de bordo: do frontend ao DNS - resolvendo b.o.s de next.js, performance e automação no Bash

Quem trabalha botando a mão na massa sabe que um dia normal de trabalho nunca se resume a uma única stack. Em questão de horas, você pode ir de debugar a configuração de build do frontend para a otimização de performance de mídia e, logo em seguida, estar rodando loops no terminal para corrigir zonas de DNS na unha.

Neste post, documento três batalhas técnicas reais enfrentadas recentemente e como solucionei cada uma delas, expandindo o cenário de infraestrutura de DNS com foco em backups, integridade sintática do BIND9, propagação multilateral e segurança.

1. O pesadelo do bundle analyzer no next.js com Bun e turbopack#

Ao tentar analisar o peso do bundle em um projeto Next.js utilizando o Bun como runtime, a primeira tentativa foi rodar a CLI diretamente:

bunx @next/bundle-analyzer

Erro: could not determine executable to run.

A falha aqui é conceitual: o @next/bundle-analyzer não é uma ferramenta binária de linha de comando autônoma; é um plugin de configuração para o next.config.ts. Ele precisa interceptar o processo de compilação do Next.js para injetar os hooks de análise.

Ajustei o next.config.ts para habilitar o plugin via variável de ambiente:

import type { NextConfig } from "next";
import withBundleAnalyzer from '@next/bundle-analyzer';

const configureBundleAnalyzer = withBundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
});

const nextConfig: NextConfig = {
  reactCompiler: true,
  turbopack: {}, // Configurações do novo motor Rust
  // ... outras configurações de headers e imagens
};

export default configureBundleAnalyzer(nextConfig);

Ao tentar rodar ANALYZE=true bun run build, encontrei uma nova barreira: O Bundle Analyzer atual não é compatível com o Turbopack (o sucessor do Webpack no Next.js 16+).

Para contornar isso e obter o relatório visual do bundle, forcei o build utilizando o Webpack via flag, lembrando de usar o -- para redirecionar os argumentos para o processo interno:

ANALYZE=true bun run build -- --webpack

(Nota: Para quem prefere não sair do ecossistema Rust, o comando bunx next experimental-analyze é a alternativa nativa experimental para o Turbopack).

2. Otimização de performance: tag video vs animações webp#

Em um projeto com requisitos rigorosos de payload (meta de 200kb por seção), as animações Lottie estavam consumindo demasiada CPU devido à renderização via JavaScript/DOM. A tentativa de converter para WebP animado resultou em perda drástica de fluidez para manter o limite de tamanho (frames reduzidos e artefatos de compressão).

Substituí as imagens animadas pela tag <video> configurada para emular comportamento de imagem:

<video
  autoPlay
  loop
  muted
  playsInline // Crucial para evitar overlay fullscreen automático no iOS
  preload="auto"
  poster="/assets/poster-estatico.jpg" 
>
  <source src="/assets/animacao.webm" type="video/webm" />
  <source src="/assets/animacao.mp4" type="video/mp4" />
</video>

Para vetores complexos, a alternativa moderna seria o Rive (.riv), mas para elementos rasterizados ou 3D, o <video> permanece invicto em relação de peso/performance.

3. Planejamento de backups de zonas DNS (finding #1 & #8)#

Ao lidar com a alteração em lote de zonas de DNS (BIND9), a primeira regra de ouro do SysAdmin é nunca editar arquivos de zona sem um backup consistente. Um erro no regex do script pode corromper dezenas de domínios, derrubando a resolução de nomes.

Crie um diretório temporário e gere uma cópia compactada dos arquivos sob /var/named/ antes de prosseguir com qualquer loop de alteração:

# Criar diretório seguro de backups em root
mkdir -p /root/zones-backup/

# Backup completo de todos os arquivos .db em formato tar.gz
tar czf /root/zones-backup-$(date +%Y%m%d).tar.gz /var/named/*.db

# Backup individual com timestamp para cada arquivo de zona
for zona in $(cat dominios.txt); do
    cp /var/named/$zona.db /root/zones-backup/$zona.db.$(date +%Y%m%d) 2>/dev/null
done

# Validar o tamanho do diretório de backup criado
du -sh /root/zones-backup/

Isso garante um rollback imediato para o estado baseline operacional dos registros DNS.

4. Validação de sintaxe do BIND (finding #3)#

O daemon named rejeitará zonas inteiras caso haja falhas de sintaxe nos registros (ex: falta de ponto no final de FQDNs, IPs mal formatados ou serial SOA quebrado).

Utilize os binários nativos do BIND para verificar sintaxe antes de efetuar o reload:

# Validar a sintaxe global das zonas listadas no arquivo de lote
for zona in $(cat dominios.txt); do
    echo "Verificando integridade da zona: $zona"
    named-checkzone $zona /var/named/$zona.db
done

# Verificar a consistência sintática do arquivo de configuração principal
named-checkconf

Se a saída do comando acima acusar OK, os registros estão estruturados corretamente para recarga.

5. Verificação pós-alteração de registros (finding #2)#

Com as alterações do regex aplicadas, é fundamental realizar testes lógicos para certificar-se de que a zona foi carregada e de que os seriais SOA foram incrementados conforme planejado.

# Validar se o named aceitou a estrutura atualizada do domínio
named-checkzone dominio.com /var/named/dominio.com.db

# Confirmar se o serial do SOA foi atualizado para o timestamp atual (10 dígitos)
grep -o '[0-9]\{10\}' /var/named/dominio.com.db | head -1

# Verificar a presença e o novo IP do apontamento mail
grep "mail" /var/named/dominio.com.db

# Testar a resolução interna do registro contra o servidor DNS local
dig @localhost mail.dominio.com A +short

# Testar se a resolução retorna o IP correto usando o resolver externo
dig @8.8.8.8 mail.dominio.com A +short

6. Auditoria de segurança e hardening do DNS (finding #9)#

Um servidor DNS aberto pode ser explorado para ataques de amplificação de DNS ou vazamento de topologia de rede interna. O hardening básico envolve restringir transferências de zonas (AXFR) a IPs autorizados nas ACLs em /etc/named.conf:

# Verificar se há diretivas allow-transfer desprotegidas no named.conf
named-checkconf | grep -i "allow-transfer"

# Auditar a configuração principal procurando por restrições
grep -i "allow-transfer" /etc/named.conf

# Verificar a declaração de ACLs (Access Control Lists) autorizadas
grep -i "acl" /etc/named.conf

Certifique-se de configurar allow-transfer { none; }; ou limitar a IPs de servidores DNS secundários autorizados.

7. Diagnóstico avançado de logs do BIND (finding #4 & #7)#

Eventos de recusa de zona ou timeouts devem ser analisados nos logs em tempo real para diagnosticar falhas de sincronia (Split Brain):

# Tailing de erros e advertências nos logs do named
tail -50 /var/log/named.log
grep -i -E "error|warning" /var/log/named.log | tail -20

# Verificar logs específicos de queries DNS em tempo real (se habilitado)
tail -20 /var/log/named/query.log

# Consultar o status operacional geral do daemon
rndc status

# Consultar status individual de carregamento de uma zona específica
rndc zonestatus dominio.com

8. Auditoria de escopo de outras zonas (finding #5)#

Quando automatizamos alterações com scripts, zonas órfãs ou domínios não previstos podem ficar com registros inconsistentes. É prudente verificar os seriais de todas as zonas de forma preditiva para encontrar tabelas obsoletas:

# Listar todas as bases de zonas ativas no servidor
ls -la /var/named/*.db

# Consultar e exibir o serial de todas as zonas registradas
for zona in /var/named/*.db; do
    echo "$(basename $zona): $(grep -o '[0-9]\{10\}' $zona | head -1)"
done

# Alerta: Detectar zonas com seriais anteriores a uma data de corte (ex: ano de 2026)
for zona in /var/named/*.db; do
    SERIAL=$(grep -o '[0-9]\{10\}' $zona | head -1)
    if [ ! -z "$SERIAL" ] && [ "$SERIAL" -lt "2026010100" ]; then
        echo "ALERTA: Serial obsoleto detectado em $zona: $SERIAL"
    fi
done

9. Verificação multilateral de propagação (finding #6)#

A alteração do DNS no servidor autoritativo local não significa acesso imediato para o mundo exterior devido ao cache TTL (Time to Live). Execute checagens multilaterais contra servidores de DNS públicos populares:

# Verificar resposta em múltiplos servidores recursivos DNS públicos
for dns in 8.8.8.8 1.1.1.1 208.67.222.222; do
    echo "Consultando DNS $dns: $(dig @$dns mail.dominio.com A +short)"
done

# Auditar o tempo de vida restante do TTL do registro
dig mail.dominio.com A | grep -A1 "ANSWER SECTION"

# Garantir que o IP antigo não aparece na consulta
dig @8.8.8.8 mail.dominio.com A +short

10. Automação do roteiro e cron (finding #10)#

Para manter a conformidade do servidor a longo prazo e evitar erros sintáticos humanos, empacotamos o fluxo de alteração de zonas em um script bash modularizado de produção em /usr/local/bin/update-dns-serial.sh:

# Injetar o script seguro de automação
cat > /usr/local/bin/update-dns-serial.sh << 'EOF'
#!/bin/bash
# Script de automação segura para atualização de serial SOA do BIND9
set -euo pipefail

NEW_SERIAL=$(date +%Y%m%d%H)
ZONES_FILE="/etc/zones.txt"

if [ ! -f "$ZONES_FILE" ]; then
    echo "Erro: Arquivo contendo domínios ($ZONES_FILE) não encontrado." >&2
    exit 1
fi

# Backup preventivo antes da execução
tar czf /root/zones-cron-backup-$(date +%Y%m%d).tar.gz /var/named/*.db

for dominio in $(cat "$ZONES_FILE"); do
    db_file="/var/named/$dominio.db"
    if [ -f "$db_file" ]; then
        OLD_SERIAL=$(grep -o '[0-9]\{10\}' "$db_file" | head -n 1)
        if [ ! -z "$OLD_SERIAL" ]; then
            # Atualizar serial
            sed -i "s/$OLD_SERIAL/$NEW_SERIAL/" "$db_file"
            
            # Limpar registro A antigo e injetar o atualizado
            sed -i "/^mail/d" "$db_file"
            echo "mail IN A 203.0.113.50" >> "$db_file"
            
            # Validação sintática local
            named-checkzone "$dominio" "$db_file" >/dev/null
        fi
    fi
done

# Recarregar configurações do BIND
rndc reload
echo "Configurações DNS recarregadas com sucesso no BIND!"
EOF

# Permissões estritas de execução
chmod 755 /usr/local/bin/update-dns-serial.sh

Você pode agendar o script para rodar de forma agendada no cron do sistema (ex: diariamente às 02h da manhã):

# Adicionar regra no crontab do root
(crontab -l 2>/dev/null; echo "0 2 * * * /usr/local/bin/update-dns-serial.sh") | crontab -

11. Checklist de automação DNS#

Abaixo está o checklist operacional para manipulação e validação das zonas DNS do BIND:

Fase 1: Planejamento & backup#

• [ ] Validar a existência de backup compactado em /root/: tar czf /root/zones-backup.tar.gz /var/named/*.db
• [ ] Listar domínios alvos no arquivo /etc/zones.txt
• [ ] Registrar os seriais SOA iniciais para controle

Fase 2: Execução das regras#

• [ ] Executar o script de atualização do serial (formato AAAAMMDDHH)
• [ ] Limpar linhas de registros A legados conflitantes e injetar o IP 203.0.113.50
• [ ] Validar a sintaxe interna de cada arquivo de zona com named-checkzone
• [ ] Validar a sintaxe global das definições do daemon com named-checkconf

Fase 3: Recarga & propagação#

• [ ] Efetuar a recarga segura das zonas do BIND via CLI rndc reload
• [ ] Verificar logs operacionais recentes do named em /var/log/named.log
• [ ] Testar a resolução DNS em servidores recursivos locais e externos (dig @8.8.8.8)
• [ ] Verificar a correta expiração de cache TTL em múltiplas operadoras

12. Matriz de riscos e mitigações#

Considerações práticas#

Um dia completo: de erros de build Next.js a automações de rede via Regex no terminal. Identificar e sanar gargalos sintáticos e de infraestrutura nos assegura o controle absoluto da stack operacional de forma robusta e escalável.

Veja também

Desenvolvimento Turbopack Rust panic: decodificando e corrigindo inner_of_uppers_lost_follower no next.js 16

Desenvolvimento Inicialização bloqueada no `pnpm dev`

Desenvolvimento Portal de documentação técnica isolado em SaaS next.js: nextra, prisma e auth middleware sem poluição de banco

Este post está licenciado sob CC BY-NC.