Atualização dinâmica

A atualização dinâmica permite que os computadores cliente DNS registrem e atualizem seus registros de recursos com um servidor DNS sempre que ocorrerem alterações. Esse recurso reduz a necessidade de administração manual de registros de zona, especialmente para clientes que frequentemente movem ou alteram locais e usam DHCP para obter um endereço IP.

Os serviços Cliente e Servidor DNS suportam a atualização dinâmica, conforme descrito na RFC 2136. O serviço Servidor DNS pode ativar ou desativar atualizações dinâmicas por zona. Por padrão, o serviço Cliente DNS do Windows Server atualiza dinamicamente os registros de recursos do host (A) no DNS quando configurado para TCP/IP. O serviço Servidor DNS está configurado para permitir apenas atualizações dinâmicas seguras por padrão.

Visão geral do protocolo

O RFC 2136 introduz o formato de mensagem UPDATE, que permite adicionar e excluir registros de recursos em uma zona especificada enquanto verifica as condições de pré-requisito. A atualização é atômica, o que significa que todas as condições devem ser atendidas para que a atualização ocorra.

A atualização de zona deve ser confirmada em um servidor DNS primário para essa zona. O servidor DNS secundário encaminha uma atualização usando a topologia de replicação até chegar ao servidor DNS primário. Quando você usa uma zona integrada ao Ative Directory, uma atualização para um registro de recurso em uma zona pode ser enviada para qualquer servidor DNS em execução em um controlador de domínio do Ative Directory cujo armazenamento de dados contém a zona.

Quando um processo de transferência de zona é iniciado, ele bloqueia a zona. Esse bloqueio garante que um servidor DNS secundário receba uma exibição consistente da zona durante a transferência dos dados. Durante esse período, a zona não pode aceitar atualizações dinâmicas. Se a zona for grande e frequentemente bloqueada para transferências, pode privar os clientes de atualização dinâmica e causar instabilidade no sistema. Para evitar esse problema, o serviço Servidor DNS do Windows Server enfileira as solicitações de atualização que chegam durante a transferência de zona e as processa após a conclusão da transferência.

Como os computadores atualizam seus nomes DNS

Por padrão, os computadores configurados estaticamente para TCP/IP tentam registrar dinamicamente registros de recursos de host (A) e ponteiro (PTR) para endereços IP configurados e usados por suas conexões de rede instaladas. Todos os computadores registram registros com base em seu FQDN.

Os clientes DNS não tentam a atualização dinâmica dos seguintes itens:

• Através de uma ligação de acesso remoto ou de rede privada virtual (VPN). Para modificar essa configuração, você pode modificar as configurações avançadas de TCP/IP da conexão de rede específica ou modificar o registro.

• Zonas de domínio de topo (TLD). Qualquer zona nomeada com um nome de rótulo único é considerada uma zona TLD, por exemplo, com, edu, blank, my-company.

Também por padrão, a parte do sufixo DNS primário do FQDN de um computador é igual ao nome do domínio do Ative Directory ao qual o computador está associado. Para permitir diferentes sufixos DNS primários, um administrador de domínio pode criar uma lista restrita de sufixos permitidos modificando o atributo msDS-AllowedDNSSuffixes no contêiner de objeto de domínio. Um administrador de domínio pode gerenciar o atributo usando o Ative Directory Service Interfaces (ADSI) ou o Lightweight Directory Access Protocol (LDAP). As atualizações dinâmicas podem ser enviadas por qualquer um dos seguintes motivos ou eventos:

• Um endereço IP é adicionado, removido ou modificado na configuração das propriedades TCP/IP para qualquer uma das conexões de rede instaladas.
• No momento da inicialização, quando o computador está ligado.
• Um servidor membro é promovido a controlador de domínio.
• Uma concessão de endereço IP altera ou renova com o servidor DHCP qualquer uma das conexões de rede instaladas, por exemplo, quando o computador é iniciado ou se o comando ipconfig /renew é usado.
• O comando ipconfig /registerdns é usado para forçar manualmente uma atualização do registro de nome do cliente no DNS.

Importante

Se você usar ipconfig /registerdns, o serviço de cliente DNS tentará registrar diretamente seu registro DNS, ignorando o servidor DHCP. Esse registro ocorre mesmo se o servidor DHCP estiver configurado para Sempre atualizar dinamicamente os registros DNS A e PTR. Se o cliente não tiver permissão para atualizar seu registro de recurso, o registro falhará silenciosamente. Se o cliente DNS tiver essa permissão, o registro de recurso será atualizado. As permissões podem ser redefinidas de modo que o servidor DHCP não seja mais capaz de executar atualizações futuras no registro de recurso.
O método recomendado para atualizar o registro DNS para clientes DHCP que executam o Windows é usar ipconfig /renew. Não use ipconfig /registerdns.

Quando um dos eventos anteriores dispara uma atualização dinâmica, o serviço Cliente DNS envia atualizações. Esse gatilho foi projetado para que, se ocorrer uma alteração nas informações de endereço IP, as atualizações correspondentes no DNS sejam executadas para sincronizar mapeamentos de nome para endereço para o computador. O serviço Cliente DNS executa essa função para todas as conexões de rede usadas no sistema, incluindo conexões não configuradas para usar DHCP.

Esse processo de atualização pressupõe que os padrões de instalação estejam em vigor para servidores que executam o Windows Server. Nomes específicos e comportamento de atualização são ajustáveis onde as propriedades avançadas de TCP/IP são configuradas para usar configurações de DNS não padrão.

Além do nome completo do computador (ou nome principal) do computador, nomes DNS específicos da conexão podem ser configurados e, opcionalmente, registrados ou atualizados no DNS.

Como funciona a atualização dinâmica

As atualizações dinâmicas são normalmente solicitadas quando um nome DNS ou endereço IP é alterado no computador. Por exemplo, suponha que um cliente chamado oldhost seja configurado pela primeira vez com os seguintes nomes:

• Nome do computador: oldhost
• Nome de domínio DNS: example.contoso.com
• Nome completo do computador: oldhost.example.contoso.com

Neste exemplo, nenhum nome de domínio DNS específico da conexão é configurado para o computador. Mais tarde, o computador é renomeado de oldhost para newhost, resultando nas seguintes alterações de nome no sistema:

• Nome do computador: newhost
• Nome de domínio DNS: example.contoso.com
• Nome completo do computador: newhost.example.contoso.com

Depois que a alteração de nome for aplicada nas propriedades do sistema, você será solicitado a reiniciar o computador. Quando o computador reinicia o Windows, o serviço Cliente DNS executa a seguinte sequência para atualizar o DNS:

1. O serviço Cliente DNS envia uma consulta de tipo SOA usando o nome de domínio DNS do computador.

   O computador cliente usa o FQDN atualmente configurado do computador (como newhost.example.contoso.com) como o nome especificado nesta consulta.

2. O servidor DNS autoritativo para a zona que contém o FQDN do cliente responde à consulta do tipo SOA.

   Para zonas primárias padrão, o servidor primário (proprietário) retornado na resposta de consulta SOA é fixo e estático. Isso sempre corresponde exatamente ao nome DNS como aparece no registo de recurso SOA armazenado com a zona. Se a zona que está sendo atualizada estiver integrada ao diretório, qualquer servidor DNS em execução em um controlador de domínio para o domínio do Ative Directory no FQDN poderá responder. Ele pode inserir dinamicamente seu próprio nome como o servidor primário (proprietário) da zona na resposta de consulta SOA.

3. Em seguida, o serviço Cliente DNS tenta contactar o servidor DNS primário.

   O cliente processa a resposta de consulta SOA para seu nome para determinar o endereço IP do servidor DNS autorizado como o servidor primário para aceitar seu nome. Em seguida, ele continua a executar a seguinte sequência de etapas, conforme necessário, para contatar e atualizar dinamicamente seu servidor primário:

   • Ele envia uma solicitação de atualização dinâmica para o servidor primário determinado na resposta da consulta SOA.
   • Se a atualização for bem-sucedida, nenhuma outra ação será executada.
   • Se essa atualização falhar, o cliente enviará em seguida uma consulta do tipo NS para o nome da zona especificado no registro SOA.
   • Quando recebe uma resposta a essa consulta, envia uma consulta SOA para o primeiro servidor DNS listado na resposta.

   Depois que a consulta SOA é resolvida, o cliente envia uma atualização dinâmica para o servidor especificado no registro SOA retornado.

   • Se a atualização for bem-sucedida, nenhuma outra ação será executada.
   • Se essa atualização falhar, o cliente repetirá o processo de consulta SOA enviando uma solicitação para o próximo servidor DNS listado na resposta.

4. Depois que o servidor DNS primário que pode executar a atualização é contatado, o cliente envia a solicitação de atualização e o servidor DNS a processa.

   O conteúdo da solicitação de atualização inclui instruções para adicionar registros de recursos A (e possivelmente PTR) para newhost.example.contoso.com e remover esses mesmos tipos de registro para oldhost.example.contoso.com, o nome que foi registrado anteriormente.

   O servidor DNS também verifica se as atualizações são permitidas para a solicitação do cliente. Para zonas primárias padrão, as atualizações dinâmicas não são protegidas, portanto, qualquer tentativa de atualização do cliente é bem-sucedida. Para zonas integradas ao Ative Directory, as atualizações são protegidas e executadas usando configurações de segurança baseadas em diretório. Para obter mais informações, consulte a seção Atualização dinâmica segura mais adiante neste artigo.

As atualizações dinâmicas são enviadas ou atualizadas periodicamente. Por padrão, os computadores enviam uma atualização a cada sete dias. Se a atualização não resultar em alterações nos dados da zona, a zona permanecerá em sua versão atual e nenhuma alteração será gravada. As atualizações resultam em alterações de zona ou aumento das transferências de zona apenas quando os nomes ou endereços são alterados.

Os nomes não são removidos das zonas DNS se ficarem inativos ou não forem atualizados dentro do intervalo de atualização (sete dias). O DNS não tem um mecanismo para liberar ou marcar nomes. No entanto, os clientes DNS tentam excluir registros de nome antigos quando um novo nome é aplicado. Os clientes DNS também tentam atualizar os registros de nome quando ocorre uma alteração de endereço.

Quando o serviço Cliente DNS registra registros de recursos A e PTR para um computador, ele usa um tempo de vida em cache padrão (TTL) de 15 minutos para registros de host. Esse TTL determina por quanto tempo outros servidores DNS e clientes armazenam em cache os registros de um computador quando eles são incluídos em uma resposta de consulta.

Tempo de Viver

Sempre que um cliente de atualização dinâmica se registra no DNS, os registros de recursos A e PTR associados incluem o Time to Live (TTL). Por padrão, o TTL é definido como 10 minutos para registros registrados pelo serviço Netlogon. Para registos registados pelo serviço Cliente DHCP, o TTL é definido como 15 minutos. Se o serviço Servidor DNS registrar registros dinamicamente para suas próprias zonas, o TTL padrão será de 20 minutos. Você pode alterar a configuração padrão no registro. Um valor pequeno faz com que as entradas armazenadas em cache expirem mais cedo, o que aumenta o tráfego DNS, mas diminui o risco de os registros armazenados em cache ficarem desatualizados. Expirar entradas rapidamente é útil para computadores que frequentemente renovam suas concessões DHCP. Tempos de retenção longos são úteis para computadores que renovam suas concessões DHCP com pouca frequência.

Resolução de conflitos de nomes

Quando o serviço Cliente DNS tenta registar um registo A, verifica se a zona DNS autoritativa já contém um registo A para o mesmo nome, mas com um endereço IP diferente. Por padrão, o serviço Cliente DNS tenta substituir o registro A existente (ou registros) pelo novo registro A que contém o endereço IP do cliente DNS. Como resultado, qualquer computador na rede pode modificar o registro A existente, a menos que a atualização dinâmica segura seja usada. As zonas configuradas para atualização dinâmica segura permitem que apenas usuários autorizados modifiquem o registro de recurso.

Você pode alterar a configuração padrão para que o serviço Cliente DNS encerre o processo de registro e registre o erro no Visualizador de Eventos, em vez de substituir o registro A existente. Para obter mais informações, consulte a seção Atualização dinâmica segura mais adiante neste artigo.

DNS e DHCP

Os clientes DNS do Windows reconhecem atualizações dinâmicas e podem iniciar o processo de atualização dinâmica. Um cliente DNS negocia o processo de atualização dinâmica com o servidor DHCP quando o cliente concede um endereço IP ou renova a concessão. Essa negociação determina qual computador atualiza os registros de recursos A e PTR do cliente. O cliente DNS e o servidor DHCP negociam quem atualiza os registros. O cliente e o servidor enviam solicitações de atualização dinâmica para os servidores DNS primários que são autorizados para os nomes a serem atualizados.

O serviço Servidor DHCP do Windows Server pode atualizar registros DNS para clientes que não oferecem suporte à opção FQDN do serviço Cliente DHCP. Esta funcionalidade pode ser ativada no separador DNS das propriedades do servidor para a consola DHCP. O servidor DHCP obtém primeiro o nome dos clientes herdados do pacote DHCP REQUEST. Em seguida, ele acrescenta o nome de domínio dado para esse escopo e registra os registros de recursos A e PTR.

Em alguns casos, registros de recursos PTR ou A obsoletos podem aparecer em servidores DNS quando a concessão de um cliente DHCP expira. Por exemplo, quando um cliente DNS tenta negociar um procedimento de atualização dinâmica com um servidor DHCP, o cliente DNS deve registrar os próprios registros de recursos A e PTR. Mais tarde, se o cliente for removido indevidamente da rede, o cliente não poderá cancelar o registro de seus registros de recursos A e PTR e eles se tornarão obsoletos.

Se um registro de recurso A obsoleto aparecer em uma zona que permite apenas atualizações dinâmicas seguras, nenhum computador poderá registrar qualquer outro registro de recurso para o nome nesse registro de recurso A. Para evitar problemas com registos de recursos PTR e A obsoletos, pode-se habilitar o recurso de envelhecimento e limpeza. Para obter mais informações sobre a funcionalidade de envelhecimento e limpeza, consulte envelhecimento e limpeza de DNS.

Para fornecer tolerância a falhas para atualizações dinâmicas, considere a integração do Ative Directory para as zonas que aceitam atualizações dinâmicas de clientes Windows. Para acelerar a descoberta de servidores DNS autoritativos, você pode configurar cada cliente com uma lista de servidores DNS preferenciais e alternativos que são primários para essa zona integrada ao diretório. Se um cliente não conseguir atualizar a zona com seu servidor DNS preferencial porque o servidor DNS não está disponível, o cliente poderá tentar um servidor alternativo. Quando o servidor DNS preferencial fica disponível, ele carrega a zona atualizada e integrada ao diretório que inclui a atualização do cliente.

Processo de atualização dinâmica

Nesta seção, descrevemos o processo de atualização dinâmica para clientes DHCP, clientes configurados estaticamente, clientes de acesso remoto e clientes multihomed.

Processo do cliente DHCP

Para iniciar o processo de atualização dinâmica, o cliente DHCP envia seu FQDN para o servidor DHCP no pacote DHCPREQUEST usando a opção FQDN do serviço Cliente DHCP. Em seguida, o servidor DHCP responde ao cliente DHCP enviando uma mensagem de confirmação de DHCP (DHCPACK) que inclui a opção FQDN (código de opção 81).

A tabela a seguir lista os campos da opção FQDN do pacote DHCPREQUEST.

Campo	Explicação
Código	Especifica o código para esta opção (81).
Len	Especifica o comprimento, em octetos, desta opção (mínimo de 4).
Bandeiras	Pode ser um dos seguintes valores: 0. O cliente deseja registrar o registro de recurso A e solicita que o servidor atualize o registro de recurso PTR. 1. O cliente deseja que o servidor registre os registros de recursos A e PTR. 3. O servidor DHCP regista os registos de recursos A e PTR independentemente do pedido do cliente.
RCODE1 e RCODE2	O servidor DHCP usa esses campos para especificar o código de resposta dos registros de recursos A e PTR realizados em nome do cliente e para indicar se ele tentou a atualização antes de enviar DHCPACK.
Nome de Domínio	Especifica o FQDN do cliente.

As condições sob as quais os clientes DHCP enviam a opção FQDN dependem do sistema operacional que o cliente está executando e de como o cliente está configurado. As ações executadas pelos servidores DHCP também dependem do sistema operacional que o servidor está executando e de como o servidor está configurado.

Por padrão, o serviço Cliente DHCP do Windows usa o seguinte processo.

1. O serviço Cliente DHCP do Windows envia a opção FQDN com o campo Sinalizadores definido como 0. Esse sinalizador solicita que o cliente atualize o registro de recurso A e o serviço do servidor DHCP atualize o registro de recurso PTR.

2. O cliente aguarda uma resposta do servidor DHCP. A menos que o servidor DHCP defina o campo Sinalizadores como 3, o cliente DNS inicia uma atualização para o registro de recurso A.

3. Se o servidor DHCP não suportar ou não estiver configurado para o registo do registo DNS, não será incluído um FQDN na resposta. Nesse caso, o cliente DNS tenta registrar os registros de recursos A e PTR.

Dependendo do que o cliente DHCP solicitar, o servidor DHCP pode executar ações diferentes.

Se o cliente DHCP enviar uma mensagem DHCPREQUEST sem a opção FQDN, o comportamento dependerá do tipo de servidor DHCP e sua configuração. O servidor DHCP atualiza ambos os registos se o configurar para atualizar registos em nome de clientes DHCP que não suportam a opção FQDN.

Nos seguintes casos, o servidor DHCP não executa nenhuma ação:

• O servidor DHCP não suporta a atualização dinâmica.

• O servidor DHCP está configurado para não fazer atualizações dinâmicas para clientes que não suportam a opção FQDN.

• O servidor DHCP está configurado para não registar registos de recursos DNS.

Se o cliente DHCP do Windows solicitar que o servidor atualize o registro de recurso PTR, mas não o registro de recurso A, o comportamento dependerá do tipo de servidor DHCP e sua configuração.

O servidor pode executar qualquer uma das seguintes ações:

• Se o servidor DHCP do Windows estiver configurado para não executar atualizações dinâmicas, ele não incluirá a opção FQDN em sua resposta. Ele também não atualiza nenhum dos registros de recursos. Nesse caso, o cliente DNS tenta atualizar os registros de recursos A e PTR se for capaz.

• Se o servidor DHCP do Windows estiver configurado para atualizar de acordo com a solicitação do cliente DHCP, o servidor tentará atualizar o registro de recurso PTR. O servidor DHCP envia uma mensagem DHCPACK para o cliente DHCP. Esta mensagem contém a opção FQDN com o campo Sinalizadores definido como 0. A mensagem DHCPACK confirma que o servidor DHCP atualiza o registo PTR. Em seguida, o cliente DNS tenta atualizar o registro de recurso A, se for capaz.

• Se o servidor DHCP estiver configurado para atualizar sempre A e PTR ambos os registros, o servidor DHCP tentará atualizar ambos os registros de recursos. A mensagem DHCPACK do servidor DHCP para o cliente DHCP contém a opção FQDN com o campo Sinalizadores definido como 3, notificando o cliente DHCP de que o servidor DHCP atualiza os registos A e PTR. Nesse caso, o cliente DNS não tenta atualizar nenhum dos registros de recursos.

Processo de clientes de acesso remoto e configurado estaticamente

Clientes configurados estaticamente e clientes de acesso remoto não dependem do servidor DHCP para registro DNS. Os clientes configurados estaticamente atualizam dinamicamente seus registros de recursos A e PTR sempre que são iniciados. Os clientes também atualizam a cada 24 horas para atualizar registros no banco de dados DNS.

Os clientes de acesso remoto podem atualizar dinamicamente os registros de recursos A e PTR quando uma conexão dial-up é feita. Eles também podem tentar retirar ou cancelar o registro dos registros de recursos A e PTR quando o usuário fecha a conexão explicitamente. Os computadores que executam o Windows Server com uma conexão de rede de acesso remoto tentam registrar dinamicamente os registros A e PTR para o endereço IP dessa conexão. Por padrão, o serviço Cliente DNS no cliente Windows não tenta atualização dinâmica por meio de uma conexão VPN ou de acesso remoto. Para modificar essa configuração, você pode modificar as configurações avançadas de TCP/IP da conexão de rede específica ou modificar o registro.

Em todos os sistemas operacionais, se um cliente de acesso remoto não receber uma resposta bem-sucedida da tentativa de cancelar o registro de um registro de recurso DNS ou falhar, por qualquer outro motivo, ao cancelar o registro de um registro de recurso em quatro segundos, o cliente DNS fechará a conexão. Nesses casos, o banco de dados DNS pode conter um registro obsoleto.

Se o cliente de acesso remoto não conseguir cancelar o registro de um registro de recurso DNS, ele adicionará uma mensagem ao log de eventos, que você poderá exibir usando o Visualizador de Eventos. O cliente de acesso remoto nunca exclui registros obsoletos, mas o servidor de acesso remoto tenta cancelar o registro de recurso PTR quando o cliente é desconectado.

Por padrão, o serviço Cliente DNS do Windows não tenta atualizar registros A e PTR automaticamente para conexões dial-up.

Processo de cliente multihomed

Se um cliente de atualização dinâmica for multihomed, o que significa que o cliente tem mais de uma conexão de rede e endereço IP associado, ele registra todos os endereços IP para cada conexão de rede. Se você não quiser que ele registre esses endereços IP, você pode configurar a conexão de rede para não registrar endereços IP.

O cliente de atualização dinâmica não registra todos os endereços IP com os servidores DNS em todos os namespaces aos quais o computador está conectado. Por exemplo, um computador multihomed, client1.example.contoso.com, está ligado tanto à Internet como à intranet corporativa. O cliente está conectado à intranet pelo adaptador A, um adaptador DHCP com o endereço IP 172.16.8.7. O cliente também está conectado à Internet pelo adaptador B, um adaptador de acesso remoto com o endereço IP 10.3.3.9. O cliente resolve nomes de intranet usando um servidor de nomes na intranet e resolve nomes de Internet usando um servidor de nomes na Internet.

Atualização dinâmica segura

A segurança de atualização de DNS está disponível apenas para zonas integradas ao Ative Directory. Quando você integra uma zona ao Ative Directory, as listas de controle de acesso (ACL) estão disponíveis no console DNS para você adicionar ou remover usuários e grupos da ACL para uma zona especificada ou registro de recurso. As ACLs são apenas para controle de acesso de administração de DNS e não influenciam a resolução de consultas DNS.

Por padrão, a segurança de atualização dinâmica para servidores e clientes DNS é tratada da seguinte maneira:

• Os clientes DNS tentam usar a atualização dinâmica não segura primeiro. Se uma atualização não segura for recusada, os clientes tentarão usar a atualização segura.

  A política de atualização padrão permite que os clientes tentem substituir um registro de recurso registrado anteriormente, a menos que seja bloqueado.

• Depois que uma zona se torna integrada ao Ative Directory, os servidores DNS que executam o Windows Server usam como padrão permitir apenas atualizações dinâmicas seguras.

  Quando você usa o armazenamento de zona baseado em arquivo, o padrão para o serviço Servidor DNS é não permitir atualizações dinâmicas em suas zonas. Para zonas que são integradas ao diretório ou usam armazenamento baseado em arquivo padrão, você pode alterar a zona para permitir todas as atualizações dinâmicas. Essa configuração permite que todas as atualizações sejam aceitas.

A atualização dinâmica é uma adição à especificação padrão DNS, definida na RFC 2136.

O registo dinâmico de registos de recursos DNS pode ser restringido com a utilização de entradas de registo.

Como funciona a atualização dinâmica segura

O processo de atualização dinâmica segura é descrito da seguinte forma:

1. Para iniciar uma atualização dinâmica segura, o cliente DNS primeiro inicia o processo de negociação do contexto de segurança, durante o qual os tokens são passados entre cliente e servidor usando registros de recursos TKEY. No final do processo de negociação, é estabelecido o contexto de segurança.

2. O cliente DNS envia a solicitação de atualização dinâmica para o servidor DNS. Essa solicitação contém registros de recursos para adicionar, excluir ou modificar dados.

   1. A solicitação é assinada usando o contexto de segurança previamente estabelecido.

   2. A assinatura é passada no registro de recurso TSIG, que está incluído no pacote de atualização dinâmica.

3. O servidor tenta atualizar o Ative Directory usando as credenciais do cliente e envia o resultado da atualização para o cliente. Esses resultados também são assinados usando o contexto de segurança e a assinatura passada no registo de recurso TSIG incluído na resposta.

Processo de atualização dinâmica segura

O processo de atualização dinâmica segura é descrito da seguinte forma:

1. O cliente DNS consulta o servidor DNS preferencial para determinar qual servidor DNS é autoritativo para o nome de domínio que está tentando atualizar. O servidor DNS preferencial responde com o nome da zona e o servidor DNS primário que é autoritativo para a zona.

2. O cliente DNS tenta uma atualização dinâmica padrão e, se a zona estiver configurada para permitir apenas atualizações dinâmicas seguras (a configuração padrão para zonas integradas ao Ative Directory), o servidor DNS recusará a atualização não segura. Se a zona estiver configurada para atualização dinâmica padrão em vez de atualização dinâmica segura, o servidor DNS aceitará a tentativa do cliente DNS de adicionar, excluir ou modificar registros de recursos nessa zona.

3. O cliente DNS e o servidor DNS iniciam a negociação TKEY.

   1. O cliente DNS e o servidor DNS negociam um mecanismo de segurança subjacente. Os clientes de atualização dinâmica do Windows e os servidores DNS só podem usar o protocolo Kerberos.

   2. Usando o mecanismo de segurança, o cliente DNS e o servidor DNS verificam suas respetivas identidades e estabelecem o contexto de segurança.

4. O cliente DNS envia a solicitação de atualização dinâmica para o servidor DNS, assinada usando o contexto de segurança estabelecido. A assinatura é incluída no campo de assinatura do registro de recurso TSIG incluído no pacote de solicitação de atualização dinâmica. O servidor DNS verifica a origem do pacote de atualização dinâmica usando o contexto de segurança e a assinatura TSIG.

5. O servidor DNS tenta adicionar, excluir ou modificar registros de recursos no Ative Directory. A atualização depende se o cliente DNS tem as permissões adequadas e se os pré-requisitos são satisfeitos.

6. O servidor DNS envia uma resposta ao cliente DNS informando se ele foi capaz de fazer a atualização, assinada usando o contexto de segurança estabelecido. A assinatura é incluída no campo de assinatura do registro de recurso TSIG incluído no pacote de resposta de atualização dinâmica. Se o cliente DNS receber uma resposta falsificada, ele a ignorará e aguardará uma resposta assinada.

Segurança para clientes DHCP que não suportam a opção FQDN

Os clientes DHCP do Windows que não suportam a opção FQDN (opção 81) não são capazes de atualizações dinâmicas. Se desejar que os registros de recursos A e PTR para esses clientes sejam registrados dinamicamente no DNS, configure o servidor DHCP para executar atualizações dinâmicas em seu nome.

Fazer com que o servidor DHCP execute atualizações dinâmicas seguras em nome de clientes DHCP que não suportam a opção FQDN requer configuração extra para evitar um problema de permissão. Quando um servidor DHCP executa uma atualização dinâmica segura em um nome, ele se torna o proprietário desse nome. Somente esse servidor DHCP pode atualizar qualquer registro para esse nome.

Por exemplo, suponha que o servidor DHCP DHCP1 criou um objeto para o nome host1.example.com e, em seguida, parou de responder, e que mais tarde o servidor DHCP de backup, DHCP2, tentou atualizar um registro para o mesmo nome, host1.example.com. Nessa situação, DHCP2 não é capaz de atualizar o nome porque ele não possui o nome.

Para evitar esse problema, use o grupo de segurança interno chamado DnsUpdateProxy. Se você adicionar todos os servidores DHCP como membros do grupo DnsUpdateProxy, outro servidor poderá atualizar os registros de um servidor se o primeiro servidor falhar. Além disso, como todos os objetos criados pelos membros do grupo DnsUpdateProxy não são protegidos, o primeiro usuário a modificar o conjunto de registros associados a um nome DNS torna-se seu proprietário. Quando os clientes legados são atualizados, eles podem tomar posse dos seus registos de nome no servidor DNS. Se cada servidor DHCP que registra registros de recursos para clientes mais antigos for membro do grupo DnsUpdateProxy, os problemas discutidos anteriormente não ocorrerão.

Protegendo registros usando o grupo DnsUpdateProxy

Quando o servidor DHCP é membro do grupo DnsUpdateProxy, ele não protege os nomes de domínio DNS que registra. Como resultado, não use esse grupo em uma zona integrada do Ative Directory que permita apenas atualizações dinâmicas seguras sem executar mais etapas para permitir que os registros criados por membros do grupo sejam protegidos.

Para proteger contra registros não seguros ou permitir que membros do grupo DnsUpdateProxy registrem registros em zonas que permitem apenas atualizações dinâmicas seguras, crie uma conta de usuário dedicada. Usando as credenciais dessa conta de usuário, configure os servidores DHCP para executar atualizações dinâmicas de DNS. Vários servidores DHCP podem usar as credenciais de uma conta de usuário dedicada.

A conta de usuário dedicada é uma conta de usuário padrão usada apenas para fornecer aos servidores DHCP credenciais para registro de atualização dinâmica de DNS. Cada servidor DHCP fornece essas credenciais ao registrar nomes em nome de clientes DHCP usando a atualização dinâmica de DNS. A conta de usuário dedicada é criada na mesma floresta onde reside o servidor DNS primário da zona a ser atualizada. A conta de usuário dedicada também pode estar localizada em outra floresta, desde que a floresta em que reside tenha uma relação de confiança de floresta estabelecida com a floresta que contém o servidor DNS primário para a zona a ser atualizada.

Quando instalado em um controlador de domínio, o serviço do servidor DHCP herda as permissões de segurança do controlador de domínio. Ou seja, ele tem autoridade para atualizar ou excluir qualquer registro DNS registrado em uma zona segura integrada ao Ative Directory. Outros computadores que executam o Windows Server, como controladores de domínio, registram esses registros com segurança. Quando instalado em um controlador de domínio, configure o servidor DHCP com as credenciais da conta de usuário dedicada para impedir que o servidor herde e, possivelmente, use indevidamente os privilégios do controlador de domínio.

Configure uma conta de usuário dedicada e configure o serviço do Servidor DHCP com as credenciais da conta nas seguintes circunstâncias:

• Um controlador de domínio está configurado para funcionar como um servidor DHCP.
• O servidor DHCP está configurado para executar atualizações dinâmicas de DNS em nome de clientes DHCP.
• O servidor DHCP atualiza zonas DNS configuradas para permitir apenas atualizações dinâmicas seguras.

Depois de criar uma conta de usuário dedicada, você pode configurar os servidores DHCP com as credenciais da conta de usuário usando o console DHCP ou usando o comando netsh dhcp server set dnscredentials.

Observação

• Se as credenciais fornecidas pertencerem a um objeto que seja membro do grupo de segurança DnsUpdateProxy, o próximo objeto a registrar o mesmo registro de nome no DNS se tornará o proprietário do registro.

• Se você especificar credenciais para o servidor DHCP a ser usado ao registrar computadores cliente DHCP no DNS, não será feito backup dessas credenciais. Depois que um banco de dados DHCP é restaurado, novas credenciais devem ser configuradas.