Parâmetros de registo de servidor de DNS da Microsoft, parte 3 de 3

Este artigo é formada por 3 partes e descreve as definições para o servidor de Microsoft DNS (DNS). Pode modificar a maior parte das definições utilizando a ferramenta DNSADMIN, apesar de só podem ser alteradas algumas definições utilizando o Editor de registo.

Para obter informações adicionais, consulte os seguintes artigos na base de dados de conhecimento da Microsoft:

aviso : a utilização incorrecta do Editor de registo poderá provocar problemas graves que poderão forçar a reinstalação do sistema operativo. Microsoft não garante que os problemas resultantes da utilização incorrecta do Editor de registo possam ser resolvidos. As suas próprias risco da utilização do Editor de registo.


Para alterar estes parâmetros, utilize o seguinte procedimento:

1. Inicie o Editor de registo (Regedt32.exe).
2. A partir da subárvore HKEY_LOCAL_MACHINE, vá para a seguinte chave:
   

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

3. A partir do menu Editar , clique em Adicionar valor e adicione um valor na chave descrita na entrada adequada abaixo. Escreva o valor e utilize a caixa de verificação "Tipo de dados" para definir o tipo de valor.
4. Clique em OK .
5. Saia do Editor de registo.
6. Reinicie o servidor DNS para os acima alterações sejam aplicadas.

Parâmetros de servidor

Vários parâmetros de registo determinam o comportamento de todo o servidor. Cada um destes é um valor de registo em Nota : estas chaves de registo são lidos durante o arranque. Alguns podem ser repostas e, em alguns casos, o servidor comportamento dinamicamente alterado, através do administrador de DNS. Mas se repor manualmente, o servidor de DNS tem de ser reiniciado para escolher configurar o novo valor.

SendOnNonDnsPort

Por predefinição, o servidor DNS envia consultas a outros servidores DNS num socket ligado à porta de DNS. Por vezes, esta situação não é desejável. O incidente mais óbvio a ser quando um administrador firewalls desactivar a porta DNS, para impedir fora acesso ao servidor de DNS, mas ainda quer o servidor de DNS conseguir contactar os servidores de DNS da Internet para fornecer resolução de nomes de Internet para clientes internos. Isto também é útil se o servidor está a servir disjuntos redes (consulte as informações abaixo para DisjointNets chave). Definir a chave SendOnNonDnsPort para um valor diferente de zero, fazendo com que o servidor de DNS ligar a uma porta arbitrária para enviar para servidores de DNS remotos. Se for definido o valor de SendOnNoDnsPort > 1024, em seguida, o servidor de DNS irá ligar explicitamente ao valor de porta fornecido. Isto é útil é o administrador pretende corrigir a porta firewalling fins.

Exemplos:

DisjointNets

Comportamento de resolução determina que os servidores de DNS explicitamente ligar a endereços IP (consulte as informações em ListenAddresses acima). Esta situação, por sua vez, significa que existe uma solução de compromisso em determinar o enlace do socket utilizado para consultar servidores de DNS remotos. O enlace tem de ser que o servidor remoto pode responder para o endereço em endereço de origem IP da consulta.

Se existir um único endereço IP para o computador a executar o servidor de DNS, não existe nenhum problema. No entanto se o computador for multihomed, poderá surgir um problema como o socket de envio pode ser escolheu das duas formas:

1. Ligar o socket de envio INADDR_ANY.
   
   Neste caso, a pilha de TCP/IP determina o endereço de origem quando a consulta é enviada para o DNS remoto. Este é ideal nessa pilha sempre escolherá o endereço de origem IP da placa que o pacote é enviado e, por conseguinte, o endereço IP será acessível quando o DNS remoto envia de volta. No entanto, isso significa que o servidor DNS tem ser escutar no endereço que escolhe a pilha. Se o servidor estiver configurado para escutar apenas alguns dos endereços IP no computador, podem surgir problemas.
2. Utilize um DNS escutar sockets como enviar socket.
   
   Neste caso, o pacote é sempre enviado com uma origem de endereços de escuta IP que corresponde a um do DNS. Infelizmente, este IP não é possível na placa a pilha deve enviar para alcançar o DNS remoto servidor. E neste caso, quando o servidor DNS remoto tenta responder, poderá não ter uma rota para este IP. Isto iria acontecer quando o servidor de DNS tem "Redes desligue"; por outras palavras, está ligado a duas (ou mais) redes que caso contrário, não estão ligados. Isto acontece clássico do servidor DNS sentado num firewall ou servidor proxy.

A chave de registo DisjointNets permite a substituição de comportamento do servidor predefinido, forçar envia num socket ligado INADDR_ANY (método 1 acima). Se a chave de registo DisjointNets existe e é diferente de zero, é criado dependente INADDR_ANY um socket de envio. Se a chave de registo DisjointNets não existe ou é zero, ocorrerá o comportamento de servidor predefinido.

Comportamento do servidor predefinido (Service Pack 3 e posterior):

• IP de DNS simples, utilize também o socket de escuta para enviar.
• Multihomed, todos os endereços em utilização pelo DNS (ou DisjointNets definido) utilizar INADDR_ANY socket.
• Multihomed, todos os endereços não está em utilização pelo DNS, utilize primeiro escuta IP socket como enviar socket.

Tenha em atenção que, no caso onde o computador tiver vários endereços IP e não são todos em utilização pelo DNS, não existe nenhuma garantia de comportamento correcto no caso de net disjunto. A chave DisjointNets pode ser activada para forçar a utilização do método 1, mas não existe nenhuma garantia de que a pilha será selecciona sempre um endereço IP que o servidor de DNS está a escutar. Se utilizar o servidor de DNS em duas desligue redes (por exemplo, num firewall), configurar o computador com apenas um pequeno número de endereços IP e permitem DNS executado em todos eles (ou seja, não não configurar ListenAddresses).

DisableAutoReverseZones

Todos os servidores DNS devem (acordo com a RFC) ser autoritário para zonas de reverse lookup três:

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

O motivo para isto é que os clientes, por vezes, consultar para endereços IP padrão como 0.0.0.0, 127.0.0.1 (loopback) e 255.255.255.255 (difusão). Ao ser autoritário para zonas correspondentes a estas consultas, o servidor de DNS evita recursions desnecessários para os servidores raiz nestas consultas.

Se a chave DisableAutoReverseZones não existe ou é zero, o servidor de DNS da Microsoft cria automaticamente estas zonas com as entradas correctas (nenhum excepto para um PTR para 127.0.0.1 para localhost).

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

AutoCacheUpdate

Quando um servidor de DNS é iniciado, necessita de uma lista de servidor de raiz "sugestões"--registos para os servidores, chamados historicamente o ficheiro de cache a e NS. Tradicionalmente os administradores de DNS podem manter este ficheiro actual, transferindo uma nova cópia do InterNIC. Este método funciona adequadamente quando os servidores raiz permanecem relativamente estáticos, mas requer a atenção na parte do administrador quando forem efectuadas actualizações e alterações (por exemplo, a mudar o nome grandes em 1995 atrasado).

O servidor de DNS da Microsoft tem uma funcionalidade para permitir que o servidor tenta escrever de volta um novo ficheiro de cache com base na resposta de servidores raiz.

Se a chave AutoCacheUpdate não existe ou é diferente de zero, o servidor de DNS da Microsoft irá voltar a escrever o ficheiro de cache baseado nos dados recebidos de consultar os servidores de DNS raiz no arranque.

Se a chave for zero, o servidor de DNS não esta actualização.

CleanupInterval

Nota : A chave de registo CleanupInterval não está disponível no Win2k.

Periodicamente, o servidor de DNS é reactivado um thread para ajudá-lo na base de dados e eliminar registos em cache e nós, que tenham excedido. (É o único objectivo recuperar a memória.) O thread também irá verificar as zonas autoritárias e escrever novamente as são "danificadas"--registos da actualização administrativa que não ter sido escritos novamente para ficheiro de base de dados.

O valor desta chave é o intervalo entre wakeups do thread de limpeza em segundos. Se a chave não existir, a predefinição é uma hora. Não existe nenhum motivo em particular para alterar este valor, embora uma situação de memória unconstrained, uma reactivação maior (possivelmente um dia) poderá ligeiramente melhorar o desempenho. Num ambiente memória restrita, intervalos mais curtos são desejáveis, mas tornar muito curto (tal como alguns minutos) pode causar ciclos excessivos para ser desperdiçados neste thread de limite de tempo.

StrictFileParsing

Implementações BIND geralmente foram liberal sobre como permitir não RFC compatível com registos de ficheiros de zona. Entre os erros permitidos:

• Registos de nomes fora da zona.
• Registos CNAME nos nomes que contenham outros registos (e vice-versa).

Quando os ficheiros BIND com dados incorrectos são movidos para um servidor de DNS da Microsoft, o servidor deve conseguir arrancar e indivíduos que não tenham em atenção que as explicações eram no registo de eventos, estavam fora dos sorte. A partir do Service Pack 4, o servidor será, por predefinição, iniciar sessão e ignorar erros de ficheiro de zona, para que o servidor possa começar.

Se a chave StrictFileParsing não existe ou é zero, o servidor irá iniciar sessão e ignorar dados danificados no ficheiro e continuar a carregar. Se o StrictFileParsing for diferente de zero, o servidor irá registar e falhar sobre erros de ficheiro de zona.

Chaves de registo de zona

Vários parâmetros de registo determinam o comportamento das zonas individuais. Cada um deles é um valor de registo na seguinte chave:

NOTA: A chave de registo acima é um caminho; foi translineada por questões de legibilidade.

Esta chave, por sua vez, contém uma chave de registo para cada zonas autoritárias e, se não raiz autoritários, uma para a cache (nome da chave "."). Esta secção descreve os parâmetros de registo que determinam o comportamento específico de zonas individuais. Cada um destes parâmetros de registo se encontra numa chave de registo para o nome da zona se aplica.

NOTA: Estas chaves de registo são lidas apenas durante o arranque. Alguns podem ser repostas e dinamicamente alterado o comportamento do servidor através do administrador de DNS. Mas, se repor manualmente, o servidor de DNS tem de ser reiniciado para recolher o novo valor.

Tipo

A chave de registo de tipo determina o tipo de zona quando iniciar a partir do registo. Mapeamentos de tipos de zona são:

A chave de registo de tipo é lido para determinar o tipo de zona no arranque do registo. Se este é eliminado ou inválido, o servidor não serão iniciados. Por conseguinte, não edite esta chave. Para alterar o tipo de zona, utilize a caixa de diálogo geral, as propriedades de zona de administrador de DNS.

NOTA: Se iniciar a partir de um ficheiro de arranque, esta chave é ignorada e substituída pelo tipo de zona especificado no ficheiro de arranque.

UseDatabase

Registrykey UseDatabase não utilizado.

DatabaseFile

A chave de registo DatabaseFile atribui o nome do ficheiro de base de dados de zona (se existir). Quando iniciar a partir do registo, esta chave determina o ficheiro que é lido para carregar a zona. Esta chave tem de existir para zonas primárias. As zonas secundárias poderão estar configuradas para não carregar a partir de um ficheiro de zona. Não edite esta chave. Para alterar o ficheiro de zona, utilize a caixa de diálogo geral, as propriedades de zona de administrador de DNS.

NOTA: Se iniciar a partir de um ficheiro de arranque, esta chave é ignorada e substituída pelo ficheiro de zona especificado no ficheiro de arranque.

MasterServers

Secundários para uma zona tem de ter uma lista de servidores podem efectuar consultas para receber informações para determinar a versão de zona actual e a receber transferências de zona, se necessário. A chave MasterServers é uma lista de endereços IP de modelos globais para a zona especificada. A lista não é cadeias IP com pontos, mas uma matriz de endereços IP não processados na ordem de bytes net contada. Deve ser configurado através de propriedades da zona, caixa de diálogo geral na ferramenta do administrador. Não editar a chave de registo é aconselhada.

NOTAS:

• Quando utilizar o arranque do registo, o servidor de DNS lê a chave MasterServers para uma zona secundária no arranque. Se a chave MasterServers não existe ou é inválida, o servidor de DNS não iniciará.
• Se iniciar a partir de um ficheiro de arranque, esta chave é ignorada e substituída com a lista principal de IP especificada no ficheiro de arranque.

SecondaryServers

O servidor de DNS da Microsoft permite a especificação de uma lista de servidor secundário. Note que é uma lista de secundários para esta zona neste servidor. É necessário que não seja uma lista completa dos secundários para a zona. O objectivo é proporcionar aos administradores um óptimo grau de controlo sobre o gráfico de replicação para uma zona.

Esta lista tem duas funções:

• Servidores nesta lista são notificados quando está disponível uma nova versão da zona.
• Se for utilizada a chave de registo SecureSecondaries (ver abaixo), zona

as transferências são recusou servidores nesta lista.

A chave SecondaryServers não é uma lista de cadeias IP com pontos, mas uma matriz de endereços IP não processados na ordem de bytes net contada. Deve ser configurado através de propriedades da zona, caixa de diálogo notificar da ferramenta do administrador. Não editar a chave de registo é aconselhada. Especialmente, não elimine esta chave de registo para tentar criar uma lista de secundária vazia.

SecureSecondaries

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

• Mantém as informações sobre as zonas privada. Informações de zona completa podem ser útil na escolha alvos para ataques de segurança. Ao limitar informações, o processo de aprender destinos possíveis é mais difícil e morosa, tornando barreira contra o ataque incrementalmente superior.
• Guarda ciclos da CPU e impede que o de negação de serviço ataques. Transferência de zona para uma zona grande é uma operação dispendiosa. Assim, é desejável para limitar a pedidos de servidores que necessitam para uma finalidade legítima.

Se a chave de registo SecureSecondaries diferente de zero, transferência de zona está limitada a pedidos de endereços IP fornecidos na chave de registo SecondaryServers (consultar acima). Se a lista de chave de registo SecondaryServers estiver vazia, não as transferências são enviadas para esta zona. Esta chave pode ser reposta através de propriedades da zona, caixa de diálogo de notificação.