Boas práticas para uso de Alias em DNS (e armadilhas a evitar) | Sysadmin Urbano 2025

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 para uso de Alias em DNS (e armadilhas a evitar)

Alias em DNS — normalmente implementados via registros CNAME — são ferramentas extremamente úteis para a gestão de domínios e subdomínios. No entanto, seu uso inadequado pode gerar atrasos, falhas de resolução e até vulnerabilidades operacionais.

Neste artigo, vamos falar sobre boas práticas no uso de alias em DNS e, tão importante quanto, sobre o que **não** se deve fazer.

1. Entendendo o que é um Alias no DNS

Um alias, geralmente configurado como um registro do tipo CNAME, é uma maneira de dizer: "este nome de domínio é apenas um apelido para outro nome existente".

Exemplo típico:

app.example.com → www.example.com

O objetivo é simplificar a manutenção de domínios. Atualizando o destino do CNAME, todos os aliases apontam corretamente sem precisar alterar múltiplos registros A.

2. Quando usar um Alias é uma boa ideia

• 🔹 Para subdomínios que dependem de serviços externos (ex: plataformas SaaS, clouds públicas).
• 🔹 Para criar "atalhos" internos em ambientes complexos de múltiplos servidores.
• 🔹 Para abstrair o endereço real de serviços que podem mudar de IP frequentemente.

Ao usar alias estrategicamente, você reduz erros operacionais e torna a gestão de DNS mais sustentável a longo prazo.

3. O que NÃO fazer com Alias em DNS

• ⚠️ Não use CNAME no domínio raiz (example.com) — a maioria dos provedores e a RFC 1034 desencorajam isso.
• ⚠️ Não empilhe CNAMEs em sequência longa (chaining) — cada salto aumenta a latência de resolução DNS.
• ⚠️ Não aponte para domínios instáveis ou temporários — se o destino cair, seu alias também falha.
• ⚠️ Não use CNAME para serviços críticos internos — preferir IPs fixos ou registros A/AAAA diretos.

Aliases mal utilizados podem tornar seus sistemas vulneráveis a falhas de terceiros, gerar lentidão e aumentar a complexidade desnecessariamente.

4. Alternativas e soluções modernas

Hoje, alguns provedores oferecem registros do tipo "ALIAS" ou "ANAME", que permitem comportamento similar a CNAME no domínio raiz. Vale verificar se sua infraestrutura suporta.

Além disso, integrar DNS dinâmico (DDNS) para IPs variáveis ou usar balanceadores de carga com registros A pode ser mais eficiente em alguns cenários.

Conclusão

Alias em DNS são aliados poderosos — mas precisam ser usados com inteligência.

Evite cadeias de CNAMEs, proteja o domínio raiz e avalie o impacto de dependências externas antes de definir um alias. Boas práticas simples podem salvar horas de troubleshooting e garantir maior estabilidade para seus ambientes.

Sobre o Sysadmin Urbano

O Sysadmin Urbano nasceu da vivência real no front das operações de infraestrutura moderna. Aqui falamos de servidores, containers, automação, boas práticas e também dos desafios invisíveis da rotina de quem mantém sistemas vivos. Sem fórmulas mágicas, sem tutoriais pela metade — apenas conteúdo prático, direto e feito para quem sabe que a TI é tanto técnica quanto sobrevivência.

🔗 Confira mais artigos ou volte para a página inicial.

Gostou deste conteúdo?

Siga o Sysadmin Urbano para mais artigos técnicos sobre Infraestrutura, SysOps e DevOps.

Voltar para a página inicial

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