SysadminUrbano • Infoblox DNS: alterando NS de subzona com Views e Delegation (procedimento seguro)

Infoblox DNS: alterando NS de subzona com Views e Delegation (procedimento seguro)

Exemplos seguros: dev.example.com e Infoblox em 198.51.100.10. Conceitos de autoridade, Views, delegação (Delegated/None), permissões e validações.

1) Conceitos essenciais

Autoridade: você só edita NS onde a zona/subzona é Authoritative no seu grid/view.
Delegation: NS da subzona residem na zona-pai; quando delegada, a subzona é servida por NS externos.
None (sem delegação): remove a delegação → a subzona passa a ser autoridade local (editável no grid).
Views: cada view é um DNS separado; pai e subzona devem estar na mesma View.
Tipos de zona: Authoritative, Delegated, Forward, Stub. Em Forward/Stub não se edita NS.

2) Diagnóstico rápido (o que está travando?)

Subzona delegada: tentar editar NS nela gera “sem permissão”? Edite os NS na zona-pai.
Forward/Stub: subzona não autoritativa → não há edição de NS.
Views diferentes: a delegação da view X não vale na view Y.
Permissão/ACL: seu grupo pode não ter Write naquela view/zona.
Grid secundário: zona controlada por outro Primário → alterações no master.

Tip No Infoblox: Data Management → DNS → Zones → Views → [view] e verifique Type (Authoritative/Delegated/Forward/Stub) e onde estão os NS.

3) DNS Views: mesma hierarquia, mundos diferentes

Cada View é um “universo” independente. A delegação (NS) precisa existir na mesma view que a zona-pai example.com.

Checklist Confirme: zona-pai e subzona estão na mesma View? A subzona aparece com ícone autoritativo nesta view?

4) Delegation x None: quem manda na subzona?

Delegated (na zona-pai) significa que NS externos respondem por dev.example.com. Você não edita NS dentro da subzona local.

None na zona-pai remove a delegação: dev.example.com vira Authoritative local → pode editar NS dentro dela. A resolução passa a ser servida pelo seu grid.

Atenção Ao trocar Delegated → None, você “puxa” a autoridade para o grid. Combine com times que usam NS externos.

5) Permissões/ACL e Grid primário/secundário

ACL/Groups: Administration → Groups → Permissions — garanta Write na view/zona.
Primário/Secundário: se o seu Member for secondary da zona, edite no primary.

6) Validações externas (dig/nslookup)

6.1 Cadeia de autoridade (raiz → TLD → domínio → subzona):

dig +trace dev.example.com NS

6.2 Consultar diretamente o Infoblox (sem recursão) e ver o SOA/NS servidos por ele:

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

6.3 Versão Windows (nslookup):

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

6.4 Limpar cache DNS do cliente após mudança:

ipconfig /flushdns

7) Procedimento seguro (passo a passo)

Planejamento

Confirme TTL dos registros NS atuais (reduza para 300–600s com antecedência, se necessário).
Garanta janela de mudança e comunicação com times impactados.
Confirme View comum entre example.com (pai) e dev.example.com (subzona).
Garanta permissão Write na view/zona (Groups/ACL).

Passo 1 — Diagnosticar estado atual

No Infoblox, abra a zona-pai example.com na view correta e verifique se dev.example.com está como Delegated (NS externos) ou None.
Verifique se a subzona é Authoritative local (editável) ou apenas placeholder.

Passo 2 — Escolha da estratégia

Trocar os NS delegados (manter autoridade externa): edite os NS na zona-pai example.com, mantendo Delegated.
Trazer a autoridade para o grid: na zona-pai, mude para None e torne dev.example.com Authoritative local; edite os NS dentro da subzona.

Passo 3 — Aplicar a mudança no Infoblox

Se Delegated → None: salve na zona-pai example.com; depois abra dev.example.com e cadastre os NS desejados localmente.
Se apenas trocar os NS mantendo delegação: edite os NS na zona-pai example.com (mesma view) e salve.

Passo 4 — Publicação e propagação

Aplicar alterações (Grid Master → Members).
Aguarde replicação do grid e respeite o TTL vigente.

Passo 5 — Validação técnica

Verificar SOA/NS no Infoblox (autoridade local):

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

Verificar cadeia externa (delegação pública):

dig +trace dev.example.com NS

Limpar cache do cliente, se necessário:

ipconfig /flushdns

Passo 6 — Observabilidade

Acompanhe logs de query nos Members.
Valide aplicações dependentes de dev.example.com.

Boas práticas Se reduziu TTL para a mudança, restaure para o valor padrão após estabilizar.

8) Rollback imediato

Se trouxe autoridade para o grid (None) e precisa reverter: volte à zona-pai example.com, defina Delegated e recoloque os NS externos.
Se apenas trocou NS na delegação e precisa reverter: restaure os NS anteriores na zona-pai example.com.
Valide novamente com dig +trace e consultas diretas ao Member 198.51.100.10.

9) Anexos úteis

Consultar SOA/NS via dig (autoridade local)

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

Consultar cadeia de delegação completa

dig +trace dev.example.com NS

nslookup (Windows)

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

Mantenha os exemplos por padrão para posts públicos. Substitua apenas se necessário.

SysAdmin Urbano

quarta-feira, 15 de outubro de 2025