Infoblox — do DNS ao Tuning [Capítulo 03]

Infoblox — do DNS ao Tuning [Capítulo 03] Delegation x None: autoridade, migração segura e rollback

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

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

Pilar 1: DNS ➜ Pilar 2: Infoblox ➜ Pilar 3: Boas práticas. Exemplos: example.com, dev.example.com, Member 198.51.100.10.

Índice

1. Visão geral: quem manda (autoridade) 2. Quando usar Delegation vs None 3. Planejamento da mudança (TTL, View e glue) 4. Procedimento A: trocar NS mantendo Delegation 5. Procedimento B: trazer autoridade (Delegation → None) 6. Validação pós-mudança 7. Rollback rápido 8. Troubleshooting 9. Trilha de certificação 10. Próximo capítulo

1) Visão geral: quem manda (autoridade)

• Autoridade é definida por SOA e NS da zona.
• Delegation: a zona-pai publica os NS da subzona → a autoridade fica nos servidores delegados.
• None (na zona-pai): remove a delegação → a subzona passa a ser Authoritative local no Infoblox.
• Views: tudo é por View. Delegar na internal não tem efeito na external.

Regra Edite os NS na zona-pai se a subzona está Delegated. Edite os NS dentro da subzona se a autoridade é local (None/Authoritative).

2) Quando usar Delegation vs None

• Delegation quando: outro time/appliance responde pela subzona; integração multi-ambiente; terceirização de operação.
• None quando: você quer administrar localmente (centralização), aplicar políticas de Grid, logging e tuning internos.
• Forward/Stub não publicam registros — não confundir com Delegation.

3) Planejamento da mudança (TTL, View e glue)

• TTL: reduza para 300–600s horas antes de mudanças de NS/autoridade.
• View: confirme que example.com e dev.example.com estão na mesma View.
• Glue: se os NS da subzona estão dentro dela (ex.: ns1.dev.example.com), garanta A/AAAA:

ns1.dev.example.com. IN A 198.51.100.31
ns2.dev.example.com. IN A 198.51.100.32

4) Procedimento A — Trocar NS mantendo Delegation

Use quando a autoridade permanece externa e você só precisa atualizar os NS.

1. Abra a zona-pai example.com (View correta) no Infoblox.
2. Edite a delegação da subzona dev.example.com e atualize os NS:

dev.example.com. IN NS ns1.dev.example.com.
dev.example.com. IN NS ns2.dev.example.com.

3. Garanta/atualize os glue quando necessário (A/AAAA para ns1/ns2).
4. Publique as alterações (Grid Master → Members) e respeite o TTL reduzido.

Atenção Não edite NS dentro da subzona quando ela está Delegated. O lugar correto é sempre a zona-pai.

5) Procedimento B — Trazer autoridade (Delegation → None)

Use quando você quer que o Infoblox passe a publicar e responder pela subzona.

1. No Infoblox, abra a zona-pai example.com na View correta.
2. Altere a subzona dev.example.com de Delegation para None (remoção da delegação).
3. Abra a própria subzona dev.example.com (agora Authoritative local) e crie os NS desejados:

dev.example.com. IN NS ns1.dev.example.com.
dev.example.com. IN NS ns2.dev.example.com.
ns1.dev.example.com. IN A 198.51.100.31
ns2.dev.example.com. IN A 198.51.100.32

4. Publique as alterações no Grid.
5. Se aplicável ao público externo, ajuste também na View external (mesma decisão de autoridade).

Impacto A resolução de dev.example.com passa a sair do seu Grid. Valide aplicações dependentes e ACLs de consulta.

6) Validação pós-mudança

6.1 Consultas diretas ao Member (sem recursão):

dig @198.51.100.10 dev.example.com SOA +norec
dig @198.51.100.10 dev.example.com NS  +norec

6.2 Cadeia completa de delegação:

dig +trace dev.example.com NS

6.3 Windows (nslookup):

nslookup -type=NS  dev.example.com 198.51.100.10
nslookup -type=SOA dev.example.com 198.51.100.10

6.4 Limpe o cache do cliente, se necessário:

ipconfig /flushdns

7) Rollback rápido

• Se trouxe autoridade (None) e quer reverter: volte à zona-pai e redefina Delegation com os NS antigos; remova/ignore os NS locais.
• Se apenas trocou NS na Delegation e quer reverter: restaure os NS anteriores na zona-pai.
• Valide novamente com dig +trace e consultas diretas ao Member.

8) Troubleshooting

• “An NS record requires at least one name server address”: crie A/AAAA (glue) do host NS ou anexe o IP ao NS externo.
• Sem permissão para editar NS na subzona: ela está Delegated; edite na zona-pai ou mude para None.
• Respostas diferentes por público: verifique a View (internal/external).
• Forward/Stub: não publicam registros; converta para Authoritative para servir a zona.
• Grid secundário: alterações só no Primary.

Pro tip Reduza o TTL antes, mude, valide, e só depois restaure o TTL padrão.

9) Trilha de certificação (mapa do capítulo)

• Conceito: autoridade, delegação, Views, glue.
• Infoblox: Delegation x None, edição por View, publicação e replicação de Grid.
• Prática: migração segura, validação com dig, rollback.

Objetivo Saber escolher entre Delegation e None, executar a transição com baixo risco e voltar rápido se necessário.

10) Próximo capítulo

Capítulo 04 — DNS Records em profundidade (A/AAAA/NS/CNAME/MX/PTR/TXT) no Infoblox
Criação correta, conflitos comuns (CNAME no apex, colisões CNAME↔A/MX/NS), TTLs e políticas de naming.

Parte da série “Infoblox — do DNS ao Tuning” no SysadminUrbano.

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