SERVFAIL no Unbound com uma única interface

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

SERVFAIL no Unbound com uma interface: O que pode ser?

Se você configurou o Unbound como servidor DNS local e ao tentar uma consulta está recebendo o erro SERVFAIL, especialmente quando o Unbound está configurado para ouvir em apenas uma interface, há algumas possíveis causas para investigar.

🔎 Entendendo o erro

SERVFAIL indica que o servidor não conseguiu resolver a requisição, mesmo sendo tecnicamente funcional. O problema pode estar em:

• Falta de acesso externo (internet/firewall)
• Restrições no arquivo de configuração
• Escopo de rede limitado pela diretiva interface:
• Restrições no access-control

📄 Verifique o arquivo de configuração (unbound.conf)

Se o Unbound está ouvindo apenas em 127.0.0.1, ele não poderá atender clientes externos. Exemplo de problema:

interface: 127.0.0.1
access-control: 192.168.0.0/16 deny

Para permitir requisições externas, adicione:

interface: 0.0.0.0
access-control: 192.168.0.0/16 allow

🧪 Testes úteis

Use ferramentas como:

• dig @127.0.0.1 google.com
• dig @localhost -p 53 google.com
• unbound-checkconf – verifica erros de sintaxe
• journalctl -u unbound – veja os logs

📌 Outras dicas

• Habilite logs com verbosity: 2 ou superior para depurar
• Verifique se o servidor tem acesso à internet para consultas externas (forwarding ou root hints)
• Use local-zone e stub-zone apenas quando necessário

---

“Um servidor DNS só é útil quando sabe escutar — e quando está no canal certo.”

Existe algum problema em fazer uma subzona de uma subzona em DNS?

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

É problemático criar subzonas de subzonas no DNS?

No gerenciamento de DNS, é comum lidar com domínios e subdomínios. Mas uma dúvida frequente surge quando falamos de delegar zonas aninhadas, como por exemplo:

exemplo.com → ti.exemplo.com → dev.ti.exemplo.com

Será que criar uma subzona dentro de outra subzona é um problema?

🔍 A resposta curta: Não necessariamente

O DNS foi projetado como uma estrutura hierárquica. É totalmente possível — e tecnicamente válido — delegar subzonas de subzonas.

No exemplo acima, dev.ti.exemplo.com pode ter seu próprio servidor autoritativo, independente de ti.exemplo.com, se houver delegação correta com registros NS e glue records (se necessário).

🧠 Quando isso pode ser útil?

• Divisão de responsabilidade entre equipes (ex: devops, segurança, TI).
• Ambientes isolados para projetos, clusters ou serviços.
• Separação de zonas por ambientes (ex: prod, dev, qa).

⚠️ Mas fique atento a:

• Delegações mal feitas podem gerar falhas de resolução (SERVFAIL).
• Dependências entre servidores autoritativos diferentes tornam o sistema mais complexo.
• Manter documentação clara de quem gerencia o quê é essencial.

✅ Boas práticas

• Use subzonas de subzonas apenas quando houver justificativa administrativa ou técnica.
• Garanta que cada zona tenha servidores NS consistentes.
• Teste a resolução com ferramentas como dig, host ou nslookup.

---

“O DNS é como um mapa de responsabilidades — e quanto mais complexas forem as rotas, maior deve ser o cuidado ao desenhá-las.”

Roteiro de Troubleshooting LBDN

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

🔍 Roteiro de Troubleshooting - Falha de LBDN no Infoblox

Objetivo: Diagnosticar problemas relacionados a LBDN (Local BIND DNS Name) no ambiente Infoblox, garantindo que as resoluções DNS funcionem corretamente.

✅ 1. Verificar se o LBDN está corretamente configurado

• Acesse: Data Management > DNS > Zones
• Verifique se o LBDN está associado ao nome correto e à zone correta.
• Confirme se possui os registros DNS (A, AAAA, CNAME) necessários.
• Verifique se está na DNS View esperada.
• Certifique-se de que a opção Enable está ativada.

✅ 2. Verificar a view DNS

• Confirme se a consulta está sendo feita pela view correta.
• Verifique as ACLs para garantir que o IP de origem tem permissão.
• Confirme se o LBDN está presente nessa view.

✅ 3. Regras baseadas em atributos

• Se for um LBDN com DNS Policy, revise as condições da regra.
• Verifique se a ação está permitindo a resposta (ex: respond, redirect, refuse).

✅ 4. Verificar logs de DNS

• Acesse: Grid > Grid Manager > Members > (selecione o membro DNS) > Logs
• Verifique o arquivo dns.log ou os query logs.
• Busque por erros como: REFUSED, NXDOMAIN, SERVFAIL.

grep 'nomedohost' /var/log/named/query.log

✅ 5. Testar resolução localmente no Infoblox

dig @127.0.0.1 nome-do-lbdn.exemplo.local

• Verifique se há resposta e qual membro responde.

✅ 6. Verificar serviço DNS do membro

• Acesse: Grid > Members > Services > DNS
• Garanta que o serviço DNS está ativo.
• Reinicie o serviço, se necessário.

✅ 7. Conferir replicação e sincronização

• Verifique o status de sincronização do grid.
• Confirme se há falhas na propagação das configurações.

✅ 8. Verificar políticas de firewall e segurança

• Confirme que o tráfego DNS está permitido entre clientes e os membros do Grid.
• Reveja as regras de firewall e segmentações de rede.

✅ 9. Verificar o cliente

• Verifique se o cliente está apontando para o DNS correto.
• Utilize ferramentas como nslookup ou dig.

✅ 10. Testar fallback e redundância

• Valide se outro Grid Member responde ao LBDN.
• Teste HA e failover, se aplicável.

🛠️ Comandos úteis via SSH (Infoblox Appliance)

dig nome-do-lbdn.exemplo.com @127.0.0.1 +short
tail -f /var/log/named/query.log
tail -f /var/log/messages
grep 'LBDN' /var/log/messages

IPv6 em Datacenters – Parte 4

IPv6 em Datacenters – Parte 4: Dual Stack na Prática

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

O sonho de uma internet totalmente em IPv6 ainda não é uma realidade para a maioria dos datacenters — e por isso, a coexistência de IPv4 e IPv6 continua sendo um desafio técnico e estratégico. Essa abordagem é conhecida como dual stack, e apesar de parecer simples na teoria, sua implementação exige atenção e planejamento.

Por que dual stack?

Porque apesar de o IPv6 resolver de forma definitiva a escassez de endereços, muitos sistemas, provedores, clientes e aplicações ainda dependem de IPv4. Adotar dual stack permite transicionar sem interromper serviços nem limitar a interoperabilidade com o mundo externo.

Principais desafios

• Duplicação de regras: Toda configuração de firewall, roteamento, NAT ou DNS precisa existir para ambas as pilhas.
• Testes em dobro: O monitoramento deve verificar se os serviços estão acessíveis em AAA.AAA.AAA.AAA e em 2001:db8::/32.
• Comportamentos inesperados: Alguns aplicativos escolhem automaticamente IPv6 (se disponível), o que pode causar problemas se a pilha não estiver bem configurada.
• Segurança: IPv6 pode “vazar” por túneis automáticos ou interfaces desprotegidas se não houver vigilância.

Boas práticas para uma operação dual stack eficiente

• Separar serviços internos e externos por políticas claras de rede: use IPv6 apenas quando necessário em aplicações críticas.
• Evite NAT64 e DNS64 salvo se estiver migrando serviços antigos sem dual stack.
• Eduque sua equipe: DNS reverso em IPv6 funciona de forma distinta. Ferramentas como ping6 e traceroute6 são essenciais.
• Documente rotas, sub-redes e escopos: A complexidade do IPv6 exige visibilidade e controle.

Validação e testes

Algumas abordagens úteis incluem:

• Rodar serviços locais com ::1 e 127.0.0.1 e validar comportamento cruzado
• Simular ambientes externos com NAT66 (quando possível)
• Ferramentas como nmap, ip -6 route, netstat -6, ss -6

Conclusão

Operar em dual stack é como viver em dois mundos ao mesmo tempo — exige consciência das regras, sincronia nas configurações e capacidade de identificar o que está funcionando em qual pilha. Mas também é o caminho mais seguro e compatível para datacenters que desejam migrar com responsabilidade.

Na próxima parte, vamos explorar segurança em ambientes IPv6, com foco em ataques modernos e proteções nativas.

IPv6 em Datacenters – Parte 2

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

IPv6 em Datacenters – Parte 2: Integração com Monitoramento, Automação e Segurança

Após estruturar a arquitetura de endereçamento com IPv6 em um datacenter, o próximo passo é integrar esse ecossistema com as ferramentas de gestão, automação e segurança já utilizadas no ambiente. Essa etapa é essencial para garantir visibilidade, controle e estabilidade operacional.

📊 Integração com ferramentas de monitoramento

Zabbix

• O Zabbix suporta IPv6 nativamente, tanto para agentes quanto servidores.
• No zabbix_agentd.conf, use ListenIP=:: para aceitar conexões IPv6.
• No frontend, cadastre os hosts com IPs IPv6 diretamente ou use DNS AAAA.

# Exemplo de item com IPv6
zabbix_get -s fd00:abcd::1001 -k system.uptime

Prometheus

• Configure os targets com IPs IPv6 dentro de colchetes: [fd00::2001]:9100
• Certifique-se de que os node_exporters estão escutando em [::]:9100

Grafana e InfluxDB

• Suporte total a conexões em IPv6 se as ferramentas forem configuradas para escutar em [::]
• Use proxies reversos (como Nginx) para centralizar acessos IPv6/IPv4.

⚙️ Automação com Ansible e Shell

• Adicione hosts em IPv6 no inventário: [meus_servers]
[fd00::1001]
• Use o parâmetro ansible_ssh_extra_args='-6' para forçar IPv6.
• Evite dependência de DNS se usar endereços diretos.

[web_ipv6]
fd00:abcd::10 ansible_user=admin ansible_ssh_extra_args='-6'

🛡️ Segurança e firewalls para IPv6

• Use nftables ou ip6tables separadamente do IPv4.
• Habilite ICMPv6 essencial para funcionamento correto da rede (RA, ND).
• Crie regras por prefixo e não apenas por IP direto, ex: fd00::/8
• Bloqueie endereços de escopo global para tráfego interno não autorizado.

🔐 Validações e auditoria

• ping6 e traceroute6 para diagnóstico de latência e roteamento
• nmap -6 para varredura de portas e validação de exposição de serviços
• Ferramentas como tcpdump -i eth0 ip6 são vitais para depuração

📌 Dica importante

Evite misturar stacks duplas mal configuradas (dual-stack desbalanceado) em serviços críticos. Priorize ambientes 100% IPv6 ou 100% IPv4 onde for possível.

🧭 Conclusão

Integrar IPv6 não é apenas configurar IPs. Envolve ajustar toda a cadeia de operações — do monitoramento à automação, da segurança à validação. Com isso, o datacenter se torna mais escalável, moderno e pronto para o futuro.

IPv6 para Datacenters - parte 1

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Implementação Completa de IPv6 para Datacenters

No universo moderno de redes, o suporte ao IPv6 deixou de ser uma opção e passou a ser uma necessidade real para ambientes de datacenter, especialmente com a escassez de IPv4 e o crescimento de ambientes escaláveis em cloud e bare metal.

📌 Divisão lógica: Pública e Privada

Ao contrário do IPv4, o IPv6 não possui faixas NAT privadas clássicas. Mas é possível utilizar as faixas fd00::/8 para simular redes internas privadas (ULA – Unique Local Address).

• Rede pública: usada para frontend, acesso externo, APIs abertas.
• Rede ULA (fd00): usada para comunicação entre bancos de dados, aplicações, serviços internos e recursivos (como DNS).

🔧 Configuração típica de componentes internos

• Servidores e VMs: Defina endereços ULA por interface, ex: fd00:abcd:1234::10
• Bancos de Dados: Vincule ao IP ULA e restrinja conexões com bind-address ou listen_address
• DNS Recursivo (ex: Unbound): Use somente ULA como origem permitida e configure escopo local
• Hypervisores e switches virtuais: Separe VLANs ou bridges por finalidade (pública / interna)
• Firewalls: Permita ICMPv6 e controle com precisão os escopos de IP

🧪 Exemplo de configuração prática

# Interface interna
iface eth1 inet6 static
  address fd00:abcd:1234::1
  netmask 64

# Exemplo de configuração no Postgres
listen_addresses = 'fd00:abcd:1234::10'

🛡️ Segurança e performance

• Utilize ip6tables ou nftables com políticas explícitas.
• Monitore tráfego com tcpdump -i eth0 ip6 ou iftop.
• Prefira endereços estáticos para facilitar debugging e regras claras.

📐 Diagramas e hierarquia

Uma estrutura bem pensada facilita a escalabilidade e troubleshooting. Exemplo:

• Hypervisor: fd00:1000::1
• VM Web: fd00:1000::10
• DB: fd00:1000::20
• DNS interno: fd00:1000::53

✅ Validação da estrutura

• Ping ULA entre serviços: ping6 fd00:abcd:1234::10
• Valide com traceroute6, nmap -6, e testes de aplicação
• Documente rotas e relacionamentos lógicos (topologias simples ajudam muito)

📌 Conclusão

O uso de IPv6 vai além da camada de acesso externo. Integrá-lo de forma completa no ambiente interno — com camadas de segurança e isolamento — é o próximo passo na evolução de um datacenter moderno.

IPv6 pode parecer complexo no início, mas ao entender seus conceitos fundamentais, ele se torna um aliado poderoso em ambientes escaláveis e limpos.

IPv6 DC

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

Um guia prático para quem vive na linha de frente da operação de sistemas.

Boas Práticas de IPv6 para Datacenters

Com a progressiva adoção do IPv6 em ambientes corporativos e datacenters, torna-se essencial compreender como planejar e aplicar boas práticas tanto na estrutura de rede externa quanto internamente — entre servidores, aplicações e sistemas de suporte.

🌐 Rede externa: visibilidade e roteabilidade

Diferente do IPv4, onde comumente usamos blocos privados (como 10.0.0.0/8 ou 192.168.0.0/16), o IPv6 não utiliza o conceito de IPs não roteáveis da mesma forma. Cada datacenter deve provisionar um bloco de endereços globais válidos e usar políticas de roteamento e firewall bem definidas para isolar segmentos.

🏗️ Segmentação interna: como substituir a NAT

No lugar da NAT, utiliza-se o controle de acesso por ACLs, firewalls e roteamento segmentado. Internamente, recomenda-se usar sub-redes /64 para cada rede lógica (ex: servidores de aplicação, banco de dados, infraestrutura).

🗄️ Aplicações e banco de dados

As aplicações devem ser preparadas para aceitar e registrar endereços IPv6. Evite hardcoding de IPs e utilize DNS sempre que possível. Para bancos de dados, certifique-se de configurar corretamente o listener IPv6 e as permissões de acesso baseadas no endereço.

🔁 DNS recursivo e IPv6

Em ambientes IPv4, é comum usar um IP privado fixo (como 10.0.0.53) para o DNS interno. Com IPv6, recomenda-se usar endereços ULA (Unique Local Address) do prefixo fd00::/8 para serviços internos como DNS recursivo, mantendo a segmentação segura e não roteável externamente.

“IPv6 não é apenas uma substituição. É uma reestruturação da forma como pensamos redes internas e segurança.” — Adaptado

🔐 Considerações finais

IPv6 elimina muitas das gambiarras que criamos com NAT e endereços privados. Porém, ele exige maturidade: seus controles de acesso, roteamento e segmentação precisam ser muito mais bem planejados. A migração para IPv6 em um datacenter deve vir acompanhada de uma revisão conceitual — e não apenas de uma troca de IP.