Parâmetros de registro do DNS da Microsoft Server, parte 3 de 3

Este artigo consiste em três partes e descreve as configurações para o servidor de serviço de nomes Microsoft domínio (DNS). Você pode modificar a maioria das configurações usando a ferramenta DNSADMIN, embora algumas configurações só podem ser alteradas usando o Editor do Registro.

Para obter informações adicionais, leia os seguintes artigos na Base de dados de Conhecimento da Microsoft:

Aviso : se você usar o Editor do Registro incorretamente, poderá causar problemas sérios que talvez exijam a reinstalação do sistema operacional. A Microsoft não garante que você pode resolver problemas resultantes do uso incorreto do Editor do Registro. Use o Editor do registro por sua própria conta e risco.


Para alterar esses parâmetros, use o procedimento a seguir:

1. Inicie o Editor do Registro (Regedt32.exe).
2. Da subárvore HKEY_LOCAL_MACHINE, vá para a seguinte chave:
   

        <B>SYSTEM\CurrentControlSet\Services </B>
   						

3. No menu Editar , clique em Adicionar valor e adicione um valor à chave descrita na entrada apropriada abaixo. Digite o valor e use a caixa de seleção "Tipo de dados" para definir o tipo de valor.
4. Clique em OK .
5. Feche o Editor do Registro.
6. Reinicie o servidor DNS para que as alterações acima tenham efeito.

Parâmetros de servidor

Vários parâmetros de registro determinam o comportamento de todo o servidor. Cada uma delas é um valor de registro em Observação : essas chaves do Registro são lidos somente na inicialização. Alguns podem ser redefinidas e, em alguns casos, o comportamento do servidor alterada dinamicamente, por meio do administrador do DNS. Mas se redefinir manualmente, o servidor DNS deverá ser reiniciado para configurar o novo valor.

SendOnNonDnsPort

Por padrão, o servidor DNS envia consultas a outros servidores DNS em um soquete vinculado à porta DNS. Às vezes, essa situação não é desejável. O caso mais óbvio quando um administrador firewalls desativar a porta DNS, para evitar fora acesso ao servidor DNS, mas ainda quer o servidor DNS para ser capaz de contatar servidores DNS de Internet para fornecer resolução de nomes de Internet para clientes internos. Isso também é desejável se o servidor estiver servindo redes separados (consulte a discussão abaixo para DisjointNets chave). Definição da chave SendOnNonDnsPort para um valor diferente de zero, fazendo com que o servidor DNS vincular a uma porta arbitrária para enviar para servidores DNS remotos. Se o valor SendOnNoDnsPort é definido > 1024, em seguida, o servidor DNS irá vincular explicitamente para o valor de porta fornecido. Isso é útil é o administrador deseja corrigir a porta para fins de firewall.

Exemplos:

DisjointNets

Comportamento de resolução determina que servidores DNS se vinculam explicitamente a endereços IP (consulte a discussão em ListenAddresses acima). Isso, por sua vez, significa que há uma compensação de determinar a vinculação do soquete usado para consultar servidores DNS remotos. A ligação deve ser tal que o servidor remoto pode responder para o endereço no endereço de origem IP da consulta.

Se houver um único endereço IP para o computador que executa o servidor DNS, não há nenhum problema. No entanto se o computador tiver diversas bases, um problema pode surgir como o soquete de envio pode ter ser escolhidas em uma destas duas maneiras:

1. Vincular soquete de enviar a INADDR_ANY.
   
   Nesse caso, a pilha TCP/IP determina o endereço IP de origem quando a consulta é enviada para o DNS remoto. Isso é ideal em que a pilha sempre escolherá o endereço de origem do IP do adaptador que o pacote é enviado e, portanto, o endereço IP será acessível quando o DNS remoto envia de volta. No entanto, isso significa que o servidor DNS deve ser escuta o endereço que escolhe a pilha. Se o servidor está configurado para escutar apenas em alguns dos endereços IP no computador, podem surgir problemas.
2. Use um DNS soquetes como enviar soquete de escuta.
   
   Nesse caso, o pacote é sempre enviado com uma fonte de endereços de escuta de IP que corresponde a uma do DNS. Infelizmente, este IP pode não ser no adaptador a pilha deve enviar para acessar o DNS remoto servidor. E, nesse caso, quando o servidor DNS remoto tenta responder, ele não deve ter uma rota de volta para este IP. Isso poderia acontecer quando o servidor DNS tem "Redes com ramificações"; em outras palavras, ele está conectado a duas (ou mais) redes que não estão conectados caso contrário. Isso é o caso clássico do servidor DNS localizado em um firewall ou servidor proxy.

A chave de registro DisjointNets permite substituição do comportamento de servidor padrão, forçando envia em soquete vinculado INADDR_ANY (método 1 acima). Se a chave de registro DisjointNets existe e é diferente de zero, um soquete de envio será criado acoplado INADDR_ANY. Se a chave de registro DisjointNets não existe ou é zero, ocorrerá o comportamento de servidor padrão.

Comportamento do servidor padrão (Service Pack 3 ou posterior):

• Único IP do DNS, use também o soquete de escuta para enviar.
• Hospedagem múltipla, todos os endereços em uso pelo DNS (ou DisjointNets definido) usar INADDR_ANY soquete.
• Hospedagem múltipla, todos os endereços não está em uso pelo DNS, use primeiro escuta IP soquete como enviar soquete.

Observe que, no caso onde o computador tiver vários endereços IP e eles não estão em uso por DNS, não há garantia de comportamento correto no caso de rede separado. A chave DisjointNets pode ser ativada para forçar o uso do método 1, mas não há nenhuma garantia de que a pilha sempre irá selecionar um endereço IP que o servidor DNS está escutando. Se usar o servidor DNS em duas com ramificações redes (por exemplo, em um firewall), configurar o computador com apenas um pequeno número de endereços IP e permitem que DNS executados em todos eles (ou seja, não configurar ListenAddresses).

DisableAutoReverseZones

Cada servidor DNS deve (conforme a RFC) ser autoritativo para três zonas de pesquisa inversa:

• 0.in-addr.arpa.
• 127.in-addr.arpa.
• 255.in-addr.arpa

O motivo para isso é que os clientes às vezes, consultar para endereços IP padrão, como 0.0.0.0, 127.0.0.1 (auto-retorno) e 255.255.255.255 (difusão). Ao ser autoritativo para as zonas correspondentes a essas consultas, o servidor DNS evita a recursions desnecessários para os servidores raiz nessas consultas.

Se a chave DisableAutoReverseZones não existe ou é zero, o servidor DNS da Microsoft criará automaticamente essas zonas com as entradas corretas, exceto para um PTR para 127.0.0.1 para localhost (nenhum).

Se DisableAutoReverseZones for diferente de zero, o servidor não cria essas zonas.

AutoCacheUpdate

Quando um servidor DNS é iniciado, ele precisa de uma lista de servidor raiz "dicas"--registros NS e A para os servidores, historicamente chamados o arquivo de cache. Tradicionalmente os administradores de DNS podem manter este arquivo atual baixando uma nova cópia do InterNIC. Este método funciona adequadamente quando os servidores raiz permanecem relativamente estáticos, mas requer atenção na parte do administrador quando atualizações e alterações são feitas (por exemplo, a renomeação grande em 1995 atrasado).

Servidor DNS da Microsoft possui um recurso para permitir que o servidor tentar gravar de volta um novo arquivo cache com base na resposta de servidores raiz.

Se a chave AutoCacheUpdate não existe ou é diferente de zero, o servidor DNS da Microsoft será reconfigurar o arquivo de cache com base nos dados recebidos de consultar os servidores DNS de raiz na inicialização.

Se a chave for zero, o servidor DNS não faz essa atualização.

CleanupInterval

Observação : A chave de registro CleanupInterval não está disponível no Win2K.

Periodicamente, o servidor DNS reativado em um thread para percorrer o banco de dados e eliminar registros em cache e nós, que atingiram o tempo limite. (É a única finalidade recuperar a memória.) O thread também verificará zonas autoritativas e gravar de volta os que são "sujos"--possuem registros de atualização administrativa que não tenham sido escritos volta ao arquivo de banco de dados.

O valor dessa chave é o intervalo entre wakeups do segmento de limpeza em segundos. Se a chave não existir, o padrão é uma hora. Há nenhuma razão específica para alterar esse valor, embora em uma situação irrestrita de memória, uma ativação de mais (possivelmente um dia) pode melhorar desempenho um pouco. Em um ambiente restrita de memória, intervalos menores são desejáveis, mas tornando muito curto (como alguns minutos) causaria ciclos excessivos para ser perdido neste segmento de tempo limite.

StrictFileParsing

Implementações BIND geralmente foram liberal sobre permitindo RFC não compatível com registros em arquivos de zona. Entre os erros permitido:

• Registros para nomes fora da zona.
• Registros CNAME em nomes que contenham outros registros (e vice-versa).

Quando os arquivos do BIND com dados incorretos são movidos para um servidor DNS da Microsoft, o servidor falharia em Iniciar e indivíduos que não estavam cientes de que as explicações eram no log de eventos, foram sorte. Iniciando com o Service Pack 4, o servidor, por padrão, faça logon e ignorar erros de arquivo de zona, para que o servidor possa começar.

Se a chave StrictFileParsing não existe ou é zero, o servidor será fazer logon e ignorar dados inválidos no arquivo e continuar a carregar. Se o StrictFileParsing for diferente de zero, o servidor faça logon e falhar sobre erros de arquivo de zona.

Chaves de registro de zona

Vários parâmetros de registro determinam o comportamento das zonas individuais. Cada um deles é um valor do Registro sob a seguinte chave:

Observação: A chave do Registro acima é um caminho; foram quebrada para facilitar a leitura.

Essa chave, por sua vez, contém uma chave do Registro para cada zonas autoritativas e, se não raiz com autoridade, um para o cache (nome da chave "."). Esta seção aborda os parâmetros do registro que determinam o comportamento específico para zonas individuais. Cada um desses parâmetros do registro é localizada em uma chave do Registro para o nome da zona que ele se aplica ao.

Observação: Essas chaves do Registro são lidos somente na inicialização. Alguns podem ser redefinidas e o comportamento de servidor dinamicamente alterada pelo administrador do DNS. Mas, se redefinir manualmente, o servidor DNS deve ser reiniciado para pegar o novo valor.

Tipo

A chave de registro do tipo determina o tipo de zona ao iniciar a partir do Registro. Mapeamentos de tipos de zona são:

A chave de registro de tipo é lida para determinar o tipo de zona na inicialização do Registro. Se ela é excluída ou inválida, o servidor não serão iniciados. Portanto, não edite essa chave. Para alterar o tipo de zona, use a propriedades de zona de administrador do DNS, caixa de diálogo geral.

Observação: Se iniciando a partir de um arquivo de inicialização, essa chave é ignorada e substituída pelo tipo de zona especificado no arquivo de inicialização.

UseDatabase

Registrykey UseDatabase não é utilizado.

DatabaseFile

A chave de registro DatabaseFile fornece o nome do arquivo de banco de dados da zona (se houver). Ao iniciar a partir do Registro, essa chave determina o arquivo que é lido para carregar a zona. Essa chave deve existir em zonas primárias. Zonas secundárias podem ser configuradas para não carregar de um arquivo de zona. Não edite esta chave. Para alterar o arquivo de zona, use a propriedades de zona de administrador do DNS, caixa de diálogo geral.

Observação: Se iniciando a partir de um arquivo de inicialização, essa chave é ignorada e sobrescrita pelo arquivo de zona especificado no arquivo de inicialização.

MasterServers

Secundários de uma zona devem ter uma lista de servidores que eles desejam consultar para receber informações para determinar a versão de zona atual e para receber transferências de zona, se necessário. A chave MasterServers é uma lista de endereços IP de mestres para determinada zona. A lista não é pontilhadas seqüências IP, mas uma matriz contada de endereços IP não processados na ordem de byte net. Ele deve ser configurado por meio de propriedades de zona, caixa de diálogo geral na ferramenta de administrador. Editar a chave do registro é desencorajado.

OBSERVAÇÕES:

• Ao usar a inicialização do Registro, o servidor DNS lê a chave MasterServers para uma zona secundária na inicialização. Se a chave MasterServers não existe ou é inválida, o servidor DNS não será iniciado.
• Se iniciando a partir de um arquivo de inicialização, essa chave é ignorada e sobrescrita com a lista mestre de IP especificada no arquivo de inicialização.

SecondaryServers

O servidor DNS da Microsoft permite que a especificação de uma lista de servidor secundário. Observe que é uma lista de secundários para esta zona neste servidor. Ele não precisa ser uma lista completa de secundários para a zona. Sua finalidade é proporcionar aos administradores um bom grau de controle sobre o gráfico de replicação para uma zona.

Esta lista tem duas funções:

• Servidores nessa lista são notificados sobre quando uma nova versão da zona está disponível.
• Se a chave de registro SecureSecondaries (veja abaixo) for usada, zona

transferências são se recusou a servidores não esta lista.

A chave SecondaryServers não é uma lista de seqüências de caracteres IP pontilhadas, mas uma matriz contada de endereços IP não processados na ordem de byte net. Ele deve ser configurado por meio de propriedades de zona, caixa de diálogo Notificar na ferramenta de administrador. Editar a chave do registro é desencorajado. Especialmente, não exclua essa chave do Registro para tentar criar uma lista vazia secundária.

SecureSecondaries

O servidor DNS da Microsoft permite limitação de transferências de zona para uma lista de seleção (possivelmente vazia) de servidores. Isso é útil por dois motivos:

• Mantém informações sobre as zonas particular. Informações de zona completa podem ser útil na escolha de alvos de ataques de segurança. Limitando informações, o processo de aprendizado sobre possíveis alvos é mais difícil e demorado, tornando a barreira contra ataques incrementalmente mais altos.
• Salva os ciclos de CPU e impede ataques de negação de serviço. Transferência de zona para uma zona grande é uma operação cara. Portanto, é desejável para limitá-lo para solicitações de servidores que precisam dele para uma finalidade legítima.

Se for diferente de zero a chave de registro SecureSecondaries, transferência de zona está limitada a solicitações de endereços IP fornecidos na chave do Registro SecondaryServers (veja acima). Se a lista de chave do Registro SecondaryServers estiver vazia, não transferências são enviadas para esta zona. Essa chave pode ser redefinida por meio de propriedades de zona, caixa de diálogo Notificar.