Fundamentação Teórica: Configure Azure DNS

1. Intuição Inicial

O DNS (Domain Name System) é a agenda telefônica da internet. Quando você digita www.microsoft.com, seu computador não sabe qual é o endereço IP desse servidor. Ele consulta o DNS, que responde com algo como 20.112.52.29. Só então a conexão é estabelecida. Sem DNS, você precisaria memorizar endereços IP para acessar qualquer site.

No Azure, existem dois contextos completamente diferentes onde o DNS é relevante, e entender essa distinção é o ponto de partida de tudo:

O primeiro é o DNS público: a resolução de nomes para recursos acessíveis pela internet, como meusite.com ou api.minhaempresa.com. O Azure DNS hospeda zones públicas e responde a consultas vindas de qualquer lugar do mundo.

O segundo é o DNS privado: a resolução de nomes dentro das suas VNets, como vm-backend.interno.contoso.com ou db.producao.local. O Azure Private DNS hospeda zones privadas visíveis apenas para as VNets que você vincular.

Os dois serviços têm o mesmo nome na plataforma e parecem similares, mas servem a propósitos distintos com comportamentos diferentes.

2. Contexto

O Azure DNS se integra com vários outros serviços e é um componente central da infraestrutura de rede:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Para o AZ-104, o Azure DNS é especialmente relevante no contexto de Private Endpoints: quando um serviço PaaS (Storage, Key Vault, SQL) recebe um Private Endpoint, seu FQDN padrão (minhaconta.blob.core.windows.net) precisa ser resolvido para o IP privado do endpoint, não para o IP público padrão. Isso é feito com uma Private DNS Zone específica para cada serviço.

3. Construção dos Conceitos

3.1 DNS Público: Azure DNS Public Zones

Uma DNS Zone é o contêiner que hospeda os registros DNS de um domínio. Quando você cria uma zone no Azure DNS para contoso.com, o Azure se torna o servidor autoritativo para esse domínio, respondendo a consultas de qualquer lugar do mundo.

Para que o Azure DNS funcione como servidor autoritativo do seu domínio, você precisa delegar o domínio para os nameservers do Azure. Isso é feito no registrador do domínio (onde você comprou o domínio): você configura os nameservers do registrador para apontar para os 4 nameservers que o Azure atribui à sua zone.

Os nameservers têm o formato:

ns1-01.azure-dns.com
ns2-01.azure-dns.net
ns3-01.azure-dns.org
ns4-01.azure-dns.info

O Azure usa TLDs diferentes (.com, .net, .org, .info) para aumentar a resiliência: um ataque ou problema em um TLD específico não derruba a resolução.

3.2 Tipos de Registros DNS

Os registros DNS são as entradas dentro de uma zone. Cada registro tem um tipo que define o que representa:

Tipo	Nome	Uso	Exemplo
A	Address	IP IPv4 de um host	`www` → `20.112.52.29`
AAAA	IPv6 Address	IP IPv6 de um host	`www` → `2001:db8::1`
CNAME	Canonical Name	Alias para outro nome (não para IP)	`www` → `contoso.azurewebsites.net`
MX	Mail Exchanger	Servidores de e-mail do domínio	`@` → `10 mail.contoso.com`
TXT	Text	Verificação de domínio, SPF, DKIM	`@` → `"v=spf1 include:..."`
NS	Name Server	Servidores autoritativos da zone	(automático)
SOA	Start of Authority	Informações da zone	(automático)
PTR	Pointer	Resolução reversa (IP → nome)	`4.1.0.10.in-addr.arpa` → `vm-web.contoso.com`
SRV	Service	Localização de serviços (ex: SIP, XMPP)	`_sip._tcp` → prioridade, peso, porta, alvo
CAA	Certification Authority Authorization	Define quais CAs podem emitir certificados	`@` → `0 issue "letsencrypt.org"`

Registro especial: Alias Record (A/AAAA/CNAME)

O Azure DNS suporta um tipo especial de registro chamado Alias Record. Diferente de um A record normal que aponta para um IP fixo, um Alias Record aponta para um recurso Azure (Load Balancer, Traffic Manager, CDN, IP público). Quando o IP do recurso muda, o Alias Record se atualiza automaticamente, sem intervenção manual.

Isso resolve o problema clássico de usar CNAME no apex do domínio: registros CNAME no apex (@, ou seja, contoso.com sem subdomínio) são proibidos pelo protocolo DNS. Um Alias Record no apex que aponta para um recurso Azure é permitido e recomendado.

3.3 TTL (Time to Live)

O TTL é um campo em cada registro DNS que indica por quantos segundos outros resolvedores DNS podem cachear aquele registro. Valores comuns:

TTL	Segundos	Quando usar
300	5 minutos	Registros que mudam frequentemente, ou durante migrações
3600	1 hora	Registros estáveis de produção
86400	1 dia	Registros muito estáveis (MX, NS)

Durante migrações: reduza o TTL para 300 segundos pelo menos 24 horas antes de fazer a mudança. Isso garante que, quando você alterar o registro, a propagação global ocorra em no máximo 5 minutos. Após a migração estável, aumente o TTL novamente.

3.4 DNS Privado: Azure Private DNS Zones

Uma Private DNS Zone funciona como uma zone DNS, mas é visível apenas para as VNets que você vincular a ela. Nomes resolvidos por uma Private DNS Zone não são acessíveis da internet.

O mecanismo é simples: o Azure tem um servidor DNS interno em cada VNet acessível pelo IP 168.63.129.16. Por padrão, esse servidor resolve nomes de hosts dentro da VNet. Quando você vincula uma Private DNS Zone a uma VNet, o servidor DNS 168.63.129.16 passa a consultar também a zone privada.

Autoregistro: quando uma VNet é vinculada a uma Private DNS Zone com autoregistro habilitado, toda VM criada naquela VNet tem seu hostname registrado automaticamente na zone. Por exemplo, se a zone é producao.internal e você cria uma VM chamada vm-backend, o registro vm-backend.producao.internal é criado automaticamente apontando para o IP privado da VM.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.5 Private DNS Zones para Private Endpoints

Este é o caso de uso mais importante das Private DNS Zones no contexto do AZ-104. Quando um serviço PaaS recebe um Private Endpoint, o Azure cria um IP privado para esse serviço. Para que aplicações acessem o serviço pelo nome (não pelo IP), é necessária uma Private DNS Zone específica para cada tipo de serviço.

Serviço	FQDN original	Private DNS Zone necessária
Azure Blob Storage	`minhaconta.blob.core.windows.net`	`privatelink.blob.core.windows.net`
Azure File Storage	`minhaconta.file.core.windows.net`	`privatelink.file.core.windows.net`
Azure Key Vault	`meukeyvault.vault.azure.net`	`privatelink.vaultcore.azure.net`
Azure SQL Database	`meuserver.database.windows.net`	`privatelink.database.windows.net`
Azure Cosmos DB	`meucosmos.documents.azure.com`	`privatelink.documents.azure.com`

O mecanismo é o seguinte: o FQDN original do serviço (minhaconta.blob.core.windows.net) tem um CNAME que aponta para um nome privatelink (minhaconta.privatelink.blob.core.windows.net). A Private DNS Zone privatelink.blob.core.windows.net tem um registro A mapeando esse nome para o IP privado do endpoint.

4. Visão Estrutural

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

Configurar uma DNS Zone Pública: Fluxo Completo

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Verificar propagação: após configurar os nameservers, você pode verificar se a delegação está funcionando:

# Consultar qual nameserver está sendo usado para o domínio
nslookup -type=NS contoso.com

# Consultar um registro específico diretamente no nameserver do Azure
nslookup www.contoso.com ns1-01.azure-dns.com

Comportamentos Importantes e Não Óbvios

Zone Apex e CNAME: a raiz do domínio (contoso.com, sem prefixo) é chamada de zone apex e é representada por @ nos registros. Pelo protocolo DNS, não é possível criar um CNAME no apex. Se você precisa que contoso.com aponte para um serviço Azure (como um App Service ou Front Door), use um Alias Record no Azure DNS, que é uma extensão proprietária que contorna essa limitação.

Delegação de subdomain: você pode delegar um subdomínio para outro servidor DNS. Por exemplo, delegar subdivisao.contoso.com para um servidor DNS on-premises ou para outra zone no Azure DNS. Isso é feito criando um registro NS no subdomínio apontando para os servidores autoritativos do subdomínio.

Resolução split-horizon: em alguns cenários você quer que api.contoso.com resolva para um IP público quando consultado da internet, mas para um IP privado quando consultado de dentro da VNet. Isso é possível com uma Private DNS Zone contoso.com vinculada à VNet com o registro api apontando para o IP privado, enquanto a zone pública tem o mesmo registro apontando para o IP público. O resolvedor da VNet (168.63.129.16) consulta a zone privada primeiro.

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: configuração inicial, adição de registros pontuais, verificação visual.

Criar DNS Zone pública: Create a resource > Networking > DNS zone > inserir nome do domínio

Criar Private DNS Zone: Create a resource > Networking > Private DNS zone > inserir nome da zone privada

Vincular Private DNS Zone a uma VNet: Private DNS zone > Virtual network links > Add

Na vinculação, você escolhe:

A VNet que será vinculada
Se o autoregistro está habilitado (VMs criadas nessa VNet são registradas automaticamente)

Criar registros: DNS zone > + Record set > escolher tipo, nome, TTL e valor

6.2 Azure CLI

Criar DNS Zone pública:

az network dns zone create \
  --name contoso.com \
  --resource-group rg-dns

Listar nameservers atribuídos (para configurar no registrador):

az network dns zone show \
  --name contoso.com \
  --resource-group rg-dns \
  --query "nameServers" \
  --output table

Criar registros DNS:

# Registro A
az network dns record-set a add-record \
  --resource-group rg-dns \
  --zone-name contoso.com \
  --record-set-name www \
  --ipv4-address 20.112.52.29 \
  --ttl 3600

# Registro CNAME
az network dns record-set cname set-record \
  --resource-group rg-dns \
  --zone-name contoso.com \
  --record-set-name api \
  --cname contoso.azurewebsites.net \
  --ttl 3600

# Registro MX
az network dns record-set mx add-record \
  --resource-group rg-dns \
  --zone-name contoso.com \
  --record-set-name "@" \
  --exchange mail.contoso.com \
  --preference 10 \
  --ttl 3600

# Registro TXT (verificação de domínio, SPF)
az network dns record-set txt add-record \
  --resource-group rg-dns \
  --zone-name contoso.com \
  --record-set-name "@" \
  --value "v=spf1 include:spf.protection.outlook.com -all" \
  --ttl 3600

Criar Alias Record apontando para IP público:

az network dns record-set a create \
  --resource-group rg-dns \
  --zone-name contoso.com \
  --name "@" \
  --ttl 300 \
  --target-resource /subscriptions/<sub-id>/resourceGroups/rg-networking/providers/Microsoft.Network/publicIPAddresses/pip-lb-frontend

Criar Private DNS Zone:

az network private-dns zone create \
  --resource-group rg-dns \
  --name producao.internal

Vincular Private DNS Zone a uma VNet com autoregistro:

az network private-dns link vnet create \
  --resource-group rg-dns \
  --zone-name producao.internal \
  --name link-vnet-producao \
  --virtual-network vnet-producao \
  --registration-enabled true

Criar registro em Private DNS Zone:

az network private-dns record-set a add-record \
  --resource-group rg-dns \
  --zone-name producao.internal \
  --record-set-name vm-backend \
  --ipv4-address 10.0.2.4

Criar Private DNS Zone para Private Endpoint de Storage:

# Criar a zone para blob storage
az network private-dns zone create \
  --resource-group rg-dns \
  --name privatelink.blob.core.windows.net

# Vincular à VNet de produção (sem autoregistro, gerenciada manualmente)
az network private-dns link vnet create \
  --resource-group rg-dns \
  --zone-name privatelink.blob.core.windows.net \
  --name link-vnet-producao-blob \
  --virtual-network vnet-producao \
  --registration-enabled false

6.3 PowerShell

# Criar DNS Zone
New-AzDnsZone -Name "contoso.com" -ResourceGroupName "rg-dns"

# Criar registro A
New-AzDnsRecordSet -Name "www" -RecordType A -ZoneName "contoso.com" `
  -ResourceGroupName "rg-dns" -Ttl 3600 `
  -DnsRecords (New-AzDnsRecordConfig -Ipv4Address "20.112.52.29")

# Criar Private DNS Zone
New-AzPrivateDnsZone -ResourceGroupName "rg-dns" -Name "producao.internal"

# Vincular com autoregistro
$vnet = Get-AzVirtualNetwork -Name "vnet-producao" -ResourceGroupName "rg-networking"
New-AzPrivateDnsVirtualNetworkLink `
  -ResourceGroupName "rg-dns" `
  -ZoneName "producao.internal" `
  -Name "link-vnet-producao" `
  -VirtualNetworkId $vnet.Id `
  -EnableRegistration

6.4 Bicep

// DNS Zone pública
resource dnsZone 'Microsoft.Network/dnsZones@2018-05-01' = {
  name: 'contoso.com'
  location: 'global'  // DNS Zones são recursos globais
}

// Registro A
resource wwwRecord 'Microsoft.Network/dnsZones/A@2018-05-01' = {
  parent: dnsZone
  name: 'www'
  properties: {
    TTL: 3600
    ARecords: [
      {
        ipv4Address: '20.112.52.29'
      }
    ]
  }
}

// Private DNS Zone
resource privateDnsZone 'Microsoft.Network/privateDnsZones@2020-06-01' = {
  name: 'producao.internal'
  location: 'global'
}

// Link com VNet
resource vnetLink 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2020-06-01' = {
  parent: privateDnsZone
  name: 'link-vnet-producao'
  location: 'global'
  properties: {
    virtualNetwork: {
      id: vnet.id
    }
    registrationEnabled: true
  }
}

7. Controle e Segurança

RBAC para Azure DNS

O Azure DNS tem papéis específicos:

Papel	Permissões
DNS Zone Contributor	Criar e gerenciar zones e registros, mas não VNets
Private DNS Zone Contributor	Criar e gerenciar zones privadas e vínculos com VNets
Network Contributor	Inclui permissões de DNS além de outros recursos de rede

Para delegar o gerenciamento de DNS a uma equipe específica sem dar acesso a outros recursos de rede, use o papel DNS Zone Contributor na zone específica.

Proteção de Registros Críticos

O Azure DNS suporta record set locks via Azure Resource Locks: você pode aplicar um lock CanNotDelete nos registros SOA e NS para evitar exclusão acidental que poderia derrubar o domínio.

# Lock em um record set específico
az lock create \
  --name lock-ns-records \
  --lock-type CanNotDelete \
  --resource-group rg-dns \
  --resource-type Microsoft.Network/dnsZones/NS \
  --resource contoso.com \
  --parent dnsZones/contoso.com

Verificação de Domínio (TXT Records)

Serviços como Microsoft 365, Google Workspace e outros exigem que você prove que é o dono do domínio adicionando um registro TXT específico. O Azure DNS torna isso simples:

az network dns record-set txt add-record \
  --resource-group rg-dns \
  --zone-name contoso.com \
  --record-set-name "@" \
  --value "MS=ms12345678"  # Valor fornecido pelo serviço

8. Tomada de Decisão

DNS público vs. privado: quando usar cada um?

Situação	Solução	Motivo
Site acessível pela internet	DNS Zone pública no Azure DNS	Responde a consultas globais
Nomes de VMs dentro de VNets	Private DNS Zone com autoregistro	Resolução interna apenas
Private Endpoint para serviço PaaS	Private DNS Zone `privatelink.*`	Redireciona nome para IP privado
Domínio customizado no apex (`contoso.com`)	Alias Record no Azure DNS	Solução para limitação de CNAME no apex
Resolução diferente interno vs. externo	Split-horizon com zone pública + privada	Zone privada sobrepõe a pública para VNets

Autoregistro habilitado vs. desabilitado?

Situação	Autoregistro	Motivo
VMs com nomes previsíveis e estáveis	Habilitado	Elimina gerenciamento manual de registros
Serviços com IPs gerenciados manualmente	Desabilitado	Controle total sobre quais registros existem
Private Endpoints	Desabilitado	Registros criados pelo processo de PE, não por VMs
Múltiplas VNets vinculadas à mesma zone	Apenas uma com autoregistro	Limitação: apenas uma VNet por zone pode ter autoregistro

9. Boas Práticas

Separe os recursos de DNS em um Resource Group dedicado: coloque todas as DNS Zones (públicas e privadas) em um Resource Group específico (rg-dns ou rg-networking-global). Isso facilita a aplicação de RBAC específico para a equipe de DNS e evita exclusão acidental junto com outros recursos.

Use TTL baixo (300 segundos) antes de qualquer migração: pelo menos 24 horas antes de alterar um registro crítico (como o IP público de um site), reduza o TTL para 300 segundos. Isso minimiza o impacto de clientes com cache do valor antigo.

Crie registros de verificação de domínio para todos os serviços Microsoft que usa: registros TXT para SPF, DKIM e DMARC no domínio de e-mail, registros TXT de verificação para Microsoft 365 e outros serviços. Centralize tudo no Azure DNS para ter uma fonte única da verdade.

Documente o propósito de cada record set: use tags nos record sets (via API/CLI) ou mantenha documentação externa sobre qual recurso cada registro aponta e quem é o responsável. Em zones com dezenas de registros, isso evita conflitos e facilita diagnóstico.

Para Private Endpoints: crie as zones privadas centralmente no hub e vincule aos spokes: em uma arquitetura hub-spoke, crie as Private DNS Zones privatelink.* no Resource Group do hub e vincule tanto ao hub quanto a cada spoke. Isso evita criar zones duplicadas em cada spoke.

10. Erros Comuns

Configurar nameservers incorretos no registrador

O Azure atribui 4 nameservers específicos para cada zone. Se o administrador copiar os nameservers de outra zone (ou de um exemplo genérico), o domínio fica sem resposta ou aponta para a zone errada. Sempre copie os nameservers do portal diretamente da zone criada.

Tentar criar CNAME no apex do domínio

@ CNAME para outro nome é inválido pelo protocolo DNS. O Azure DNS permite criar o registro, mas isso viola o padrão e muitos resolvedores se comportam de forma imprevisível. A solução correta é usar um Alias Record apontando para um recurso Azure, ou um registro A com IP estático.

Vincular uma VNet a uma Private DNS Zone sem desabilitar o autoregistro em múltiplas VNets

Uma Private DNS Zone permite autoregistro em apenas uma VNet. Se você habilitar autoregistro em duas VNets diferentes vinculadas à mesma zone, o Azure rejeita a segunda com erro. Defina claramente qual VNet é a "principal" para autoregistro de cada zone.

Esquecer de criar a Private DNS Zone para Private Endpoints

Um Private Endpoint é criado para um Storage Account. O IP privado está funcionando. Mas quando a aplicação tenta acessar minhaconta.blob.core.windows.net, o DNS resolve para o IP público, não para o IP privado do endpoint. A solução é criar a Private DNS Zone privatelink.blob.core.windows.net e o registro A correspondente. Sem isso, a resolução de nome ignora o Private Endpoint.

Alterar TTL alto durante migração

Um registro A tem TTL de 86400 (1 dia). O administrador altera o IP para o novo servidor. Clientes que consultaram o DNS nas últimas 24 horas têm o cache do IP antigo e continuam acessando o servidor antigo por até 24 horas. A prática correta é reduzir o TTL dias antes da migração.

11. Operação e Manutenção

Verificar Resolução de DNS

Para testar se um registro está sendo resolvido corretamente:

# Resolver um registro público
nslookup www.contoso.com

# Resolver contra o nameserver do Azure explicitamente
nslookup www.contoso.com ns1-01.azure-dns.com

# Resolver registro privado de dentro de uma VM na VNet
# (executar na VM, não localmente)
nslookup vm-backend.producao.internal 168.63.129.16

Via Azure CLI para verificar registros existentes:

# Listar todos os records de uma zone
az network dns record-set list \
  --resource-group rg-dns \
  --zone-name contoso.com \
  --output table

# Verificar um record set específico
az network dns record-set a show \
  --resource-group rg-dns \
  --zone-name contoso.com \
  --name www

Monitoramento e Diagnóstico

O Azure DNS não tem métricas nativas no Azure Monitor para consultas individuais. Para monitoramento detalhado:

Use ferramentas externas de monitoramento de DNS (Pingdom, UptimeRobot) para verificar disponibilidade dos registros públicos
Para Private DNS, o diagnóstico é feito dentro das VMs usando nslookup ou dig

Limites Importantes

Item	Limite
Zones públicas por assinatura	250
Zones privadas por assinatura	1.000
Record sets por zone pública	10.000
Record sets por zone privada	25.000
VNets vinculadas por zone privada	1.000
Zones privadas por VNet (com resolução)	1.000
Queries por segundo por zone	Sem limite documentado (gerenciado pela Microsoft)

12. Integração e Automação

Integração com Private Endpoints: Fluxo Automático

Quando você cria um Private Endpoint pelo portal e escolha "Integrar com Private DNS Zone", o Azure pode criar automaticamente:

A Private DNS Zone privatelink.[serviço].core.windows.net
O registro A mapeando o nome para o IP do endpoint
O link da zone com a VNet selecionada

Isso é conveniente mas pode criar zones duplicadas em ambientes com múltiplas VNets. A prática recomendada em ambientes enterprise é não usar a integração automática e gerenciar as zones manualmente (ou via IaC) para ter controle centralizado.

Atualização Automática de Registros com Azure Functions

Em cenários onde IPs mudam frequentemente (VMs com IPs dinâmicos, serviços que escalam), uma Azure Function pode atualizar registros DNS automaticamente:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

DNS Hierárquico com Azure DNS Resolver

Para ambientes híbridos onde VMs na Azure precisam resolver nomes on-premises E nomes do Azure, o Azure DNS Private Resolver (serviço separado, mas relacionado) permite criar forwarding rules: consultas para corp.empresa.local são encaminhadas para o servidor DNS on-premises, enquanto consultas para producao.internal são respondidas pelas zones privadas do Azure.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

13. Resumo Final

Pontos essenciais:

DNS público (Azure DNS Zones): hospeda registros para domínios acessíveis da internet. Requer delegação dos nameservers no registrador do domínio.
DNS privado (Azure Private DNS Zones): hospeda registros visíveis apenas para VNets vinculadas. Usado para resolução interna de VMs e para Private Endpoints.
O Azure DNS usa o IP 168.63.129.16 como resolvedor padrão dentro de VNets.
Autoregistro em Private DNS Zones cria registros automaticamente para VMs criadas na VNet vinculada.
Private Endpoints requerem Private DNS Zones privatelink.* para resolver o FQDN do serviço para o IP privado do endpoint.

Diferenças críticas:

DNS Zone (pública) vs. Private DNS Zone: pública responde a qualquer consulta da internet; privada só responde a VNets vinculadas.
A record vs. Alias Record: A record aponta para um IP fixo; Alias Record aponta para um recurso Azure e se atualiza automaticamente quando o IP muda.
CNAME no apex é inválido pelo protocolo DNS. Use Alias Record para apontar o apex (@) para um recurso Azure.
Autoregistro habilitado em apenas uma VNet por zone privada. Múltiplas VNets podem ser vinculadas, mas só uma pode ter autoregistro.

O que precisa ser lembrado:

Ao criar uma DNS Zone, o Azure atribui 4 nameservers únicos. Esses nameservers devem ser configurados no registrador do domínio para que o Azure seja autoritativo.
Reduza o TTL para 300 segundos pelo menos 24 horas antes de fazer alterações em registros críticos.
Para Private Endpoints funcionarem por nome (não por IP), a Private DNS Zone privatelink.[serviço] deve existir, ter o registro A correto e estar vinculada às VNets que precisam resolver o nome.
Em arquiteturas hub-spoke, crie as Private DNS Zones privatelink.* centralmente e vincule tanto ao hub quanto aos spokes.
O Azure DNS é um serviço global: as zones são recursos location: global, não regionais.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 DNS Público: Azure DNS Public Zones​

3.2 Tipos de Registros DNS​

3.3 TTL (Time to Live)​

3.4 DNS Privado: Azure Private DNS Zones​

3.5 Private DNS Zones para Private Endpoints​

4. Visão Estrutural​

5. Funcionamento na Prática​

Configurar uma DNS Zone Pública: Fluxo Completo​

Comportamentos Importantes e Não Óbvios​

6. Formas de Implementação​

6.1 Portal do Azure​

6.2 Azure CLI​

6.3 PowerShell​

6.4 Bicep​

7. Controle e Segurança​

RBAC para Azure DNS​

Proteção de Registros Críticos​

Verificação de Domínio (TXT Records)​

8. Tomada de Decisão​

DNS público vs. privado: quando usar cada um?​

Autoregistro habilitado vs. desabilitado?​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

Verificar Resolução de DNS​

Monitoramento e Diagnóstico​

Limites Importantes​

12. Integração e Automação​

Integração com Private Endpoints: Fluxo Automático​

Atualização Automática de Registros com Azure Functions​

DNS Hierárquico com Azure DNS Resolver​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 DNS Público: Azure DNS Public Zones

3.2 Tipos de Registros DNS

3.3 TTL (Time to Live)

3.4 DNS Privado: Azure Private DNS Zones

3.5 Private DNS Zones para Private Endpoints

4. Visão Estrutural

5. Funcionamento na Prática

Configurar uma DNS Zone Pública: Fluxo Completo

Comportamentos Importantes e Não Óbvios

6. Formas de Implementação

6.1 Portal do Azure

6.2 Azure CLI

6.3 PowerShell

6.4 Bicep

7. Controle e Segurança

RBAC para Azure DNS

Proteção de Registros Críticos

Verificação de Domínio (TXT Records)

8. Tomada de Decisão

DNS público vs. privado: quando usar cada um?

Autoregistro habilitado vs. desabilitado?

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Verificar Resolução de DNS

Monitoramento e Diagnóstico

Limites Importantes

12. Integração e Automação

Integração com Private Endpoints: Fluxo Automático

Atualização Automática de Registros com Azure Functions

DNS Hierárquico com Azure DNS Resolver

13. Resumo Final