SysAdmin Urbano: Infoblox — do DNS ao Tuning [Capítulo 01]

Infoblox — do DNS ao Tuning [Capítulo 01] O que é DNS — muito além do A e do CNAME

Publicado por Sysadmin Urbano | Infraestrutura, SysOps e DevOps

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

1) Introdução à série

Bem-vindo à série “Infoblox — do DNS ao Tuning”. Cada capítulo começa em DNS puro, traduz o conceito no Infoblox e fecha com boas práticas e validação. Vamos do alicerce ao fine-tuning, cobrindo também os tópicos chaves da jornada de certificação Infoblox.

Estrutura Conceito ➜ Implementação no Infoblox ➜ Boas práticas ➜ Testes e Troubleshooting

2) DNS — conceitos que importam

Autoridade: quem “manda” numa zona/subzona (quem publica o SOA/NS).
Recursão x Iteração: o resolvedor recursivo pergunta “em cadeia” até chegar à autoridade.
Cache: respostas são guardadas pelo TTL (quanto menor, mais tráfego; quanto maior, mais lentidão para propagar mudanças).
Zonas: porção do namespace servida por um conjunto de servidores autoritativos (definida por SOA e NS).

3) Registros essenciais

3.1 SOA (Start of Authority)

Define o início de autoridade da zona, serial e timers.

; SOA mínimo e didático (exemplo)
example.com. IN SOA ns1.example.com. hostmaster.example.com. (
  2025101601 ; serial (YYYYMMDDnn)
  3600       ; refresh
  900        ; retry
  1209600    ; expire
  300        ; minimum/negative TTL
)

3.2 NS, A/AAAA e CNAME

NS apontam para os servidores autoritativos. Se o NS está dentro da própria zona/subzona, é necessário o glue (A/AAAA do host NS).

; NS do apex + glue
example.com.     IN NS ns1.example.com.
example.com.     IN NS ns2.example.com.
ns1.example.com. IN A  198.51.100.11
ns2.example.com. IN A  198.51.100.12

; CNAME (não use CNAME no apex e não conflita com A/MX/NS)
www.example.com. IN CNAME app.example.net.

3.3 MX, PTR e TXT

; MX (e o A do host de mail)
example.com.   IN MX 10 mail.example.com.
mail.example.com. IN A 198.51.100.20

; PTR (zona reversa)
11.100.51.198.in-addr.arpa. IN PTR server11.example.com.

; TXT (usos diversos: SPF, verificações, etc.)
example.com. IN TXT "v=spf1 -all"

4) Delegação, glue e autoridade

Delegar uma subzona (ex.: dev.example.com) significa publicar, na zona-pai (example.com), os NS que “mandam” naquela subzona. Se os NS forem dentro de dev.example.com, crie os glue records (A/AAAA) para o recursor saber o IP desses NS.

; Na zona-pai (example.com)
dev.example.com. IN NS ns1.dev.example.com.
dev.example.com. IN NS ns2.dev.example.com.
; Glue (pode estar na própria pai, se necessário)
ns1.dev.example.com. IN A 198.51.100.31
ns2.dev.example.com. IN A 198.51.100.32

Atenção Sem glue, muitos resolvedores não conseguem chegar nos NS da subzona → falhas intermitentes.

5) Como isso se traduz no Infoblox

5.1 Zonas e Views

Views são “universos DNS” distintos (ex.: internal, external).
A zona-pai e a subzona precisam estar na mesma View para a delegação valer naquela audiência.

5.2 Onde criar NS

Subzona Authoritative/None (local): crie NS dentro da subzona (Add → Record → NS), com A/AAAA dos hosts NS.
Subzona Delegated: crie/edite NS na zona-pai (Delegation da subzona) e garanta o glue.
Forward/Stub: não criam NS locais (são modos especiais).

5.3 Erro comum que veremos muito

Erro clássico “An NS record requires at least one name server address.” — Crie o A/AAAA do host NS (glue) antes ou informe o IP ao cadastrar o NS externo.

6) Boas práticas desde o Dia 1

Serial SOA no formato YYYYMMDDnn e incremente a cada mudança.
TTL razoável: 300–600s para ambientes em mudança; 3.600–14.400s para estáveis.
Naming claro para NS (ex.: ns1, ns2) e serviços (api, auth).
Evite CNAME no apex e conflitos CNAME ↔ A/MX/NS.
Delegação: sempre garantir glue quando necessário.
Manter Views coerentes (pai e subzona na mesma view).

7) Validação com dig/nslookup

7.1 SOA/NS da zona-pai (autoridade local, sem recursão):

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

7.2 Cadeia de delegação até a subzona:

dig +trace dev.example.com NS

7.3 Consultas Windows (nslookup):

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

8) Checklist do capítulo

SOA e NS definidos para example.com.
Subzona dev.example.com com delegação correta e glue quando necessário.
Entendimento de Views e onde editar NS (pai vs. subzona).
TTL ajustado ao seu contexto.
Validações com dig e nslookup realizadas.

Pro tip Em janelas de mudança, reduza o TTL horas antes. Após estabilizar, volte ao padrão.

9) Próximo capítulo

Capítulo 02 — Zonas, Subzonas e Views: como o Infoblox organiza o DNS
Hierarquia prática, tipos de zona (Authoritative, Delegated, Forward, Stub), quando usar cada um e como manter consistência entre Views.

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

SysAdmin Urbano

terça-feira, 21 de outubro de 2025

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