DNS e Microsoft Windows NT 4.0Por Scott B. Suhy e Glenn Wood

 

Versão: 1.0

Um documento técnicoda Business Systems Division e daMicrosoft Consulting Services

Resumo

Este documento fornece uma visão geral do sistema de nomes de domínio (DNS, Domain Name System) e da maneira como pode ser implementado utilizando o Microsoft Windows NT 4.0.

 

Com a instalação dos Serviços de pasta avançados do Windows NT, que será fornecido com uma versão posterior do Windows NT, o Servidor de nomes de domínio será muito mais importante que nas outras versões do Windows NT. Em vista disso, a instalação e a criação de implementações eficientes de DNS serão úteis na futura migração para a próxima versão do Windows NT.

 

A série de documentos técnicos da Microsoft Business Systems Division destina-se ao treinamen-to dos profissionais de tecnologia da informação (IT, Information Technology) sobre o Windows NT e a família de produtos Microsoft BackOffice. Apesar de abordar com freqüência as tecnologias utilizadas nos produtos Microsoft, o verdadeiro propósito desses documentos é dar aos leitores uma idéia de como as principais tecnologias estão evoluindo, como estão sendo utilizadas pela Microsoft e como essas informações influenciam os desenvolvedores de tecnologia.

Para obter informações mais recentes sobre o Windows NT Server, consulte nosso site na World Wide Web em http://www.microsoft.com/backoffice ou o Windows NT Server Fórum na Microsoft Network (GO WORD: MSNTS).

 

 

Nota legal

 As informações contidas neste documento representam a posição atual da Microsoft Corporation no que diz respeito às questões abordadas na data de publicação. Como a Microsoft deve responder às condições de mudança de mercado, as informações não devem ser interpretadas como um compromisso por parte da Microsoft, sendo que esta pode garantir a precisão de qualquer informação apresentada após a data de publicação.

Este documento é fornecido apenas para fins informativos. A MICROSOFT NÃO OFERECE QUALQUER GARANTIA, EXPLÍCITAS OU IMPLÍCITAS, NESTE DOCUMENTO.

© 1996 Microsoft Corporation. Todos os direitos reservados.

Microsoft e Windows são marcas registradas, assim como Windows NT e BackOffice são marcas registradas da Microsoft Corporation.

0796Peça No. xxx-xxxxx

 

 

 

INTRODUÇÃO....................................................................................................................................

VISÃO GERAL DO DNS...................................................................................................................

HISTÓRICO......................................................................................................................................Histórico do DNS...........................................................................................................................

ENTENDENDO A TECNOLOGIA..................................................................................................Visão geral.....................................................................................................................................Servidores DNS e a Internet..........................................................................................................Domínios........................................................................................................................................Zonas..............................................................................................................................................Servidores de nome........................................................................................................................Resolução do nome........................................................................................................................Cache e tempo de vida...................................................................................................................

OS ARQUIVOS DO DNS.................................................................................................................Visão geral.....................................................................................................................................O arquivo de banco de dados........................................................................................................O arquivo de cache........................................................................................................................O arquivo de procura invertida.....................................................................................................O arquivo Arpa-127.rev.................................................................................................................O arquivo de inicialização BIND..................................................................................................

IMPLEMENTANDO O DNS UTILIZANDO O MICROSOFT WINDOWS NT 4.0...................

INTRODUÇÃO AO MICROSOFT DNS.........................................................................................O SERVIDOR...................................................................................................................................

Instalando o serviço DNS..............................................................................................................Configurando domínios e zonas do DNS.......................................................................................Integração com Procura WINS.....................................................................................................WINS e Procura inversa................................................................................................................O que você deve saber...................................................................................................................

O RESOLVEDOR (CLIENTE).........................................................................................................Configuração.................................................................................................................................O nome do host..............................................................................................................................O nome do domínio........................................................................................................................Os servidores DNS.........................................................................................................................A ordem de pesquisa do Sufixo de domínio...................................................................................Resolução de nomes.......................................................................................................................

O PERSONAGEM PRINCIPAL.......................................................................................................Nslookup........................................................................................................................................Pontos fracos da implementação atual..........................................................................................

CRIANDO SOLUÇÕES.....................................................................................................................

UTILIZANDO O SERVIDOR DE DNS DA MICROSOFT PARA CONEXÃO COM A INTERNET........................................................................................................................................

Considerações sobre segurança....................................................................................................Projeto típico de conectividade Internet........................................................................................

PLANEJAMENTO DE CAPACIDADE E DESEMPENHO...........................................................Estatísticas.....................................................................................................................................DNS de equilíbrio de carga...........................................................................................................A transferência de zona.................................................................................................................Memória consumida por registros DNS........................................................................................

DECISÕES DNS...............................................................................................................................EXEMPLO DE CONFIGURAÇÕES................................................................................................

Índice

Exemplos de Confiança Total........................................................................................................Exemplo de múltiplo principal.......................................................................................................

O FUTURO..........................................................................................................................................

INTRODUÇÃO.................................................................................................................................PADRÕES EM DESENVOLVIMENTO..........................................................................................

DNS dinâmico................................................................................................................................IPv6 (IPng)....................................................................................................................................Transferências incrementais – Duplicação múltipla mestre.........................................................DNS seguro....................................................................................................................................

MIGRAÇÃO......................................................................................................................................Por onde começar?........................................................................................................................

CONCLUSÃO...................................................................................................................................

APÊNDICES........................................................................................................................................

APÊNDICE A: A LIGAÇÃO...........................................................................................................Rastreando consultas DNS............................................................................................................

APÊNDICE B: MAIS INFORMAÇÕES..........................................................................................Internet...........................................................................................................................................Livros.............................................................................................................................................Documentos técnicos.....................................................................................................................Cursos............................................................................................................................................Misc................................................................................................................................................

APÊNDICE C: REGISTRANDO-SE NO NIC.................................................................................APÊNDICE D: REGISTROS DNS...................................................................................................

Nossos especiais agradecimentos às pessoas abaixo por sua ajuda neste projeto:......................

Introdução

A utilização do serviço DNS no Windows NT 4.0 é opcional. 

O serviço de sistema de nomes de domínio (DNS, Domain Name System) que acompanha o Microsoft Windows NT 4.0 estará disponível sempre que você precisar utilizá-lo; no entanto, nada existe atualmente no Serviços de pasta do Windows NT que precise dele. Gostaríamos que você o utilizasse para atividades gerais do tipo DNS.

 

É importante observar que o DNS NÃO é uma maneira alternativa para examinar seus domínios de serviços de pasta (isto é, não há suporte para Localizador ou para logon de rede etc.).

 

Se você optar por utilizar o DNS, este documento lhe mostrará como será possível criar hoje sua infra-estrutura de DNS, preparando-se para a futura versão de Serviços de pasta (DS, Directory Services) avançados do Windows NT.

 

O que teremos agora é uma mudança de padrão. Até hoje, o grupo Windows NT no âmbito de uma empresa podia ser executado em seu próprio ambiente e criar domínios, confianças, contas de usuários e compartilhamentos do Windows NT. Os grupos Windows NT nunca tiveram que se preocupar com o ambiente de Serviços de pasta — geralmente havia dentro da empresa algum outro grupo que se preocupava com X.500, DNS e outros serviços semelhantes. Com o início do DS avançado, que estará na próxima versão principal do Windows NT, haverá alterações e esses dois grupos precisarão trabalhar em conjunto. Isto será importante, pois o DS avançado será semelhante ao X.500 e utilizará o DNS para localizar servidores que forneçam esses Serviços de pasta. Por esse motivo, esse documento é muito importante. Ele permitirá que os grupos Windows NT adquiram conhecimentos sobre o ambiente dos outros Serviços de pasta. O objetivo desse documento é ajudar esses dois grupos a entenderem suas necessidades mútuas, propiciando assim uma migração sem dificuldades para os Serviços avançados de pasta.

 

Inicialmente, este documento definirá a tecnologia DNS (esta é uma seção para todos aqueles que ainda não conheçam o DNS). Examinará, então, o DNS específico da Microsoft (nesta seção explicamos o motivo da solução DNS da Microsoft ser a opção correta para um ambiente Microsoft ou misto), abordará, em seguida, algumas arquiteturas (esta seção é importante para qualquer pessoa que queira criar uma solução DNS) e, por fim, falará sobre o futuro do Windows NT (esta é uma seção importante que todos devem ler).

 

Esperamos que este documento lhe seja proveitoso e útil. Se você quiser comentar sobre o conteúdo deste documento, envie uma mensagem para Scott Suhy (scottsu@microsoft.com) ou Glenn Wood (glennwo@microsoft.com) na Microsoft Corporation.

Visão geral do DNS

Antes de examinarmos a implementação do DNS da Microsoft, é importante que o leitor conheça um pouco sobre a estória do DNS. Se você já estiver familiarizado com o DNS e suas funcionalidades, poderá omitir esta seção do documento e passar diretamente para “Implementando o DNS utilizando o Microsoft Windows NT 4.0”.

 

Histórico do DNSO sistema de nomes de domínio (DNS, Domain Name System) é um conjunto de protocolos e serviços em uma rede de Protocolo de controle de transmissão/Protocolo Internet (TCP/IP, Transmission Control Protocol/Internet Protocol) que permite aos usuários da rede a utilização de nomes hierárquicos amigáveis a fim de procurar por outros hosts (ou seja, computadores), em vez de precisarem se lembrar e utilizar seus endereços IP. Este sistema, hoje em dia, é bastante utilizado na Internet e em muitas empresas particulares. Se você utilizou um localizador de WEB, um aplicativo Telnet, um utilitário de Protocolo de transferência de arquivo (FTP, File Transfer Protocol) ou outros utilitários TCP/IP semelhantes na Internet, provavelmente você utilizou um servidor DNS.

 

A função mais conhecida dos protocolos DNS é o mapeamento de nomes amigáveis ao usuário em endereços IP. Suponha, por exemplo, que o endereço IP do site do FTP na Microsoft seja 157.55.100.1. A maioria das pessoas tem acesso a esse computador especificando ftp.microsoft.com em vez do endereço IP menos amigável. Além de ser mais fácil de lembrar, o nome é mais confiável. O endereço numérico poderá mudar por vários motivos, porém o nome poderá ser sempre utilizado.

 

Antes da implementação do DNS, o uso de nomes de computadores amigáveis ao usuário era feito através do uso de arquivos HOSTS que continham uma lista de nomes e endereços IP associados. Na Internet, esse arquivo era administrado de forma centralizada e cada localidade baixava periodicamente uma nova cópia. Conforme o número de máquinas na Internet foi aumentando, essa solução tornou-se difícil de administrar. A partir disso, surgiu uma necessidade de encontrar algo melhor. O DNS tornou-se a solução apropriada.

 

De acordo com o Dr. Paul Mockapetris, principal criador do DNS, a meta original de criação do DNS era substituir os arquivos HOSTS de administração extremamente complicada por um banco de dados de distribuição simples, que permitiria a possibilidade de um espaço hierárquico para nomes, distribuição de administração, tipos de dados expansíveis, tamanho do banco de dados virtualmente ilimitado e bom desempenho.

 

Histórico

O DNS mapeia para o nível 7 no modelo OSI, podendo utilizar Protocolo de datagrama do usuário (UDP, User Datagram Protocol) ou TCP como o protocolo básico. Os resolvedores primeiro enviam consultas UDP

aos servidores para obter melhor desempenho, recorrendo ao TCP somente se ocorrer truncamento dos dados retornados.

 

A implementação mais popular do protocolo ‘BIND’ do DNS foi originalmente desenvolvida em Berkeley para o sistema operacional UNIX BSD 4.3. O nome ‘BIND’ representa Berkeley Internet Name Domain. As principais especificações do DNS estão definidas nas solicitações de comentários (RFCs, Requests for Comments) 974, 1034 e 1035.

 

Visão geralUm Sistema de nomes de domínio é composto de um banco de dados de nomes distribuído. Os nomes do banco de dados de DNS estabelecem uma estrutura de árvore lógica denominada espaço de nome de domínio. Cada nó ou domínio no espaço de nome de domínio recebe um nome e pode conter subdomínios. Os domínios e os subdomínios são agrupados em zonas a fim de permitir administração distribuída do espaço de nome (as zonas serão discutidas posteriormente nesta seção). Ao separar cada galho da árvore com um ponto ‘.’, o nome do domínio identifica a posição do domínio na hierarquia lógica do DNS em relação ao seu domínio pai. A figura abaixo mostra alguns domínios de nível superior, nos quais se ajusta o domínio Microsoft e um host denominado ‘rhino’ se encontra dentro do domínio ‘microsoft.com’. Se alguém quisesse contatar esse host, utilizaria o rhino.microsoft.com do nome de domínio totalmente qualificado (FQDN, Fully Qualified Domain Name).

 

Entendendo a tecnologia

Servidores DNS e a InternetA raiz do banco de dados de DNS na Internet é gerenciada pelo Internet Network Information Center (http://www.internic.com). Os domínios de nível superior foram atribuídos de forma organizacional e por país. Esses nomes de domínio obedecem o Padrão internacional 3166. Abreviações com duas e três letras são utilizadas para países e outras abreviações são reservadas para serem utilizadas por organizações, como nos exemplos abaixo.

Nome de domínio DNS Tipo de organização

 

com Comercial (por exemplo, microsoft.com para Microsoft Corporation)

edu Educacional (por exemplo, mit.edu para Massachusetts Institute of Technology)

gov Governo (por exemplo, whitehouse.gov para Whitehouse em Washington D.C.)

int Organizações internacionais (por exemplo, nato.int para NATO)

mil Operações militares (por exemplo, army.mil para o Exército Americano)

net Organizações de rede (por exemplo, nsf.net para NSFNET)

org Organizações não comerciais (por exemplo, fidonet.org para FidoNet)

DomíniosCada domínio na árvore de um banco de dados de DNS, junto com todos os dados abaixo dele, é denominado um Domínio. Os domínios podem conter hosts (computadores) e outros domínios (subdomínios). Por exemplo,. o domínio Microsoft microsoft.com poderia conter computadores como ftp.microsoft.com e subdomínios como dev.microsoft.com, que poderiam conter hosts como ntserver.dev.microsoft.com.

 Em geral, os nomes de Domínio e os nomes de Host possuem restrições quanto a sua denominação, que permite apenas o uso dos caracteres ‘a-z’, ‘A-Z’, ‘0-9’ e ‘-‘ (traço ou sinal de menos). O uso de caracteres como ‘/’, ‘.’ e ‘_’ (barra, ponto e sublinhado) não é permitido.

 

ZonasZona é qualquer parte do espaço de nome do DNS que contém registros do banco de dados, os quais são gerenciados em um determinado arquivo de zona. Um único servidor DNS poderá ser configurado para gerenciar um ou vários arquivos de zona. Cada zona é ancorada em um nó de domínio específico ¾ designado como ‘domínio raiz’ da zona. Os arquivos de zona não contêm necessariamente a árvore completa (isto é, todos os subdomínios) sob o domínio raiz da zona. Para obter uma comparação de domínios e zonas, veja a figura a seguir. Nesse exemplo, microsoft.com é um domínio, mas o domínio inteiro não é controlado por um arquivo de zona. Parte do domínio na realidade é subdividido em um arquivo de zona separado para dev.microsoft.com. A subdivisão de domínios em múltiplos arquivos de zona poderá ser necessária para a distribuição de gerenciamento do domínio para grupos diferentes ou possivelmente para eficiência na duplicação de dados (ou seja, transferências de zona que serão discutidas posteriormente).

 

É muito importante que você entenda a diferença entre uma Zona e um Domínio. Uma zona é um arquivo físico composto de registros de recursos que define um grupo de domínios. Um domínio é um nó no espaço de nome do DNS e todos os subdomínios abaixo dele.

 

Servidores de nomeOs servidores DNS armazenam informações sobre o espaço de nome de domínio e são designados como Servidores de nome. Os servidores de nome geralmente possuem uma ou mais zonas pelas quais são responsáveis. Diz-se então que o Servidor de nomes têm Autorização a essas zonas.

 

Ao configurar os Servidores de nome DNS (como veremos em breve com o registro ‘NS’), você o informará sobre todos os outros Servidores de nome DNS que estejam no mesmo domínio.

 

Servidores de nome primário, secundário e principal

O Servidor de nomes primário é um servidor de nomes que obtém os dados para sua zona a partir de arquivos locais. As alterações a uma zona, como adicionar domínios ou hosts, são realizadas no Servidor de nomes primário. O Servidor de nomes secundário obtém os dados para suas zonas a partir do servidor de nomes através da rede que seja de autorização para aquela zona. A transferência de zona refere-se a processos de obtenção de informações dessa zona (ou seja, arquivo de banco de dados) através da rede.

Há três motivos para que se tenha servidores secundários dentro de uma empresa. Esses motivos são:

         Redundância

Será necessário pelo menos dois servidores de nomes DNS atendendo cada zona, um primário e um secundário para redundância. De maneira semelhante a qualquer sistema tolerante a falhas, as máquinas devem ser o mais independente possível (isto é, redes diferentes etc.).

         Locais remotos

Também será necessário ter servidores secundários (ou outros servidores para subdomínios) em locais remotos que tenham um grande número de clientes. Você não iria gostar que esses clientes se comunicassem através de vínculos lentos para resolução do nome.

         Reduzir a carga no primário

Também será necessário ter servidores secundários para reduzir a carga do servidor primário. Como as informações para cada zona são armazenadas em arquivos separados, esta designação de primário ou secundário é definida em um nível de zona. Em outras palavras, um determinado servidor de nomes poderá ser um servidor de nomes principal para certas zonas e um servidor de nomes secundário para outras zonas. Ao definir uma zona em um servidor de nomes como secundária, você precisa designar um servidor de nomes a partir do qual informações sobre zona são obtidas. A fonte de informações de zona de um servidor de nomes secundário em uma hierarquia DNS é designada como Servidor de nomes principal. O servidor de nomes principal poderá ser um servidor de nomes primário ou secundário para a zona solicitada. Ao iniciar, o servidor de nomes secundário contata seu servidor de nomes principal e inicia uma transferência de zona com esse servidor.

 Utilize servidores secundários como servidores principais em caso de sobrecarga do principal ou quando existir um caminho de rede mais eficiente entre ‘secundário para secundário’ versus ‘secundário para primário’.

Encaminhadores e escravos

Ao receber uma solicitação do DNS, o servidor de nomes DNS tenta localizar as informações solicitadas dentro de seus próprios arquivos de zona. Se essa tentativa falhar em virtude de o servidor não ser de autorização para o domínio solicitado, ele deverá comunicar-se com outros servidores de nomes DNS para resolver a solicitação. Considerando que, em uma rede conectada globalmente, a solicitação de resolução de DNS fora de uma zona local requer normalmente a interação com servidores de nomes DNS fora da empresa na Internet pública, convém ativar seletivamente servidores de nomes DNS específicos em sua empresa para fazer essa comunicação em áreas remotas.

 

Para tratar dessa questão, o DNS permite o conceito de encaminhadores. Os servidores de nomes DNS específicos são selecionados como encaminhadores, sendo que somente os encaminhadores podem executar as comunicações de área ampla através da Internet. Todos os outros servidores de nome DNS no âmbito de empresa são configurados para utilizar os encaminhadores e são configurados com os endereços IP dos servidores de nomes de domínio DNS designados como encaminhadores. Essa configuração é feita por servidor individual e não por zona!

Quando um servidor configurado para utilizar encaminhadores recebe uma solicitação de DNS que não seja capaz de resolver (através de seus próprios arquivos de zona), ele passa a solicitação para um dos encaminhadores designados. O encaminhador, então, executa as comunicações necessárias para resolver a solicitação e retorna os resultados ao servidor que fez a solicitação, o qual, por sua vez, retorna os resultados ao solicitante original. Se o encaminhador não conseguir resolver a consulta, o servidor DNS tentará resolvê-la ele mesmo da maneira normal.

 

Escravos são servidores DNS que foram configurados para utilizar encaminhadores e que também foram configurados para retornar uma mensagem de falha caso não seja possível ao encaminhador resolver a solicitação. Nenhuma tentativa será feita pelos escravos para contatar outros servidores de nome se o encaminhador não conseguir atender a solicitação.

Servidores somente de cache

Apesar de todos os servidores de nomes DNS armazenarem em cache as consultas por eles resolvidas, os Servidores somente de cache são servidores de nomes DNS cuja única função é executar consultas, armazenar as respostas em cache e retornar os resultados. Em outras palavras, eles não são de autorização para qualquer domínio e contêm somente informações que armazenaram em cache durante a resolução de consultas.

 

Ao tentar determinar quando utilizar esse tipo de servidor, lembre-se de que, ao ser iniciado pela primeira vez, o servidor não possui informações armazenadas em cache e deve construir essas informações com o tempo à medida em que atender solicitações. No entanto, se você estiver lidando com um vínculo lento entre locais, menos tráfego será enviado através do vínculo lento porque o servidor não está fazendo uma transferência de zona.

Resolução do nomeHá 3 tipos de consultas que um cliente pode fazer a um servidor DNS, Recursiva, Iterativa e Inversa. Quando estiver discutindo sobre resolução do nome, lembre-se de que um servidor DNS pode ser um cliente de outro servidor DNS.

Consultas recursivas

Em uma consulte recursiva, o servidor de nomes consultado é solicitado a responder com os dados solicitados ou com um erro declarando que os dados do tipo solicitado não existem ou que o nome do domínio especificado não existe. O servidor de nomes não pode simplesmente transferir o solicitante da consulta para um servidor de nomes diferente.

 

Este tipo de consulta é feita geralmente por um cliente DNS (um Resolvedor) a um servidor DNS. Da mesma forma, se um servidor DNS for configurado para utilizar um encaminhador, a solicitação desse servidor DNS ao seu enviador será uma consulta recursiva.

Consultas iterativas

Em uma consulta Iterativa, o servidor de nomes consultado retorna a melhor resposta que possui no momento ao solicitante da consulta. Esse tipo de consulta é feito normalmente por um servidor DNS a outros servidores DNS após receber uma consulta recursiva de um resolvedor.

 

A figura abaixo mostra um exemplo dos dois tipos de consultas. A consulta 1/8 é uma consulta recursiva de um resolvedor cliente ao seu servidor DNS enquanto que as consultas 2/3, 4/5 e 6/7 são consultas iterativas do servidor DNS para outros servidores DNS.

Obtendo o nome do Host dado o endereço IP

O que acontecerá se um resolvedor possuir o endereço IP e quiser saber o nome do Host de uma determinada máquina. Em vez de fornecer um nome e perguntar por um endereço IP, o cliente precisará fornecer o endereço IP e perguntar pelo Nome. Como não há uma correlação direta no espaço de nome do DNS entre os nomes de domínio e os endereço IP associados que eles contêm, somente uma pesquisa completa de todos os domínios poderia garantir uma resposta correta.

Para minimizar esse problema, um domínio especial “in-addr.arpa.” foi criado no espaço de nome do DNS. Os nós no domínio in-addr.arpa são denominados após os números na representação do octeto pontilhado do endereço IP. Porém, como os endereços IP ficam mais específicos da esquerda para a direita e os nomes de domínio ficam menos específicos da esquerda para a direita, a ordem dos octetos do endereço IP deve ser invertida ao construir a árvore in-addr.arpa. Com esse arranjo, a administração dos galhos inferiores da árvore

in-addr.arpa do DNS pode ser fornecida às empresas quando estas receberem seus endereços de sub-rede classe A, B ou C.

 

Assim que a árvore de domínio for construída no banco de dados de DNS, um registro de ponteiro especial será adicionado aos endereços IP associados aos nomes dos hosts correspondentes. Em outras palavras, para encontrar um nome do host para o endereço IP 157.55.200.2, o resolvedor consultaria o servidor DNS quanto a um registro de ponteiro 2.200.55.157.in-addr.arpa. Se este endereço IP estivesse fora do domínio local, o servidor DNS começaria na raiz e subseqüentemente resolveria os nós do domínio até chegar a 200.55.157.in-addr.arpa, que deve conter o registro PTR do recurso para 2 (ou seja, 157.55.200.2).

Cache e tempo de vidaQuando um servidor de nomes está processando uma consulta recursiva, poderá ser necessário que ele envie várias consultas a fim de localizar a resposta definitiva. O servidor de nomes armazena em cache todas as informações recebidas durante esse processo pelo tempo especificado nos dados retornados. Esse tempo é designado como o tempo de vida (TTL, Time To Live). O administrador do servidor de nomes da zona que contém os dados decide quanto ao TTL para os dados. Os valores menores de TTL ajudarão a garantir que os dados sobre o seu domínio sejam mais consistentes através da rede, caso esses dados sofram alterações freqüentes. No entanto, isso também aumentará a carga sobre seu servidor de nomes.

Assim que os dados forem armazenados em cache por um servidor DNS, ele deverá começar a reduzir o TTL (isto é, diminuir) de seu valor original para que ele saiba quando liberar os dados de sua cache. Caso chegue uma consulta que possa ser atendida por esses dados armazenados em cache, o TTL retornado junto com os dados será a duração do tempo restante antes que os dados sejam liberados da cache do servidor DNS. Os resolvedores clientes também possuem caches de dados e obedecem o valor do TTL para que possam saber quando expirar os dados.

Visão geralA maioria dos sistemas DNS deve ser configurada editando-se arquivos de texto. Com o DNS da Microsoft, assim como com todos os produtos baseados em Microsoft Windows, há uma interface amigável ao usuário. A nova interface de administração torna mais fácil a configuração dos servidores DNS Microsoft local e remoto. A ferramenta administrativa do DNS configura para você os arquivos de texto compatíveis com RFC.

Os arquivos do DNS

Embora a interface gráfica de usuário lhe dê capacidade para modificar os arquivos do DNS sem um editor, será necessário que você conheça a composição dos arquivos de configuração do sistema. Nos sistemas DNS compatíveis com RFC, há vários arquivos que definem a configuração do sistema e o banco de dados de DNS. Esses arquivos incluem banco de dados, cache, procura inversa e arquivos de procura inversa 127. Esses arquivos também existem no DNS do Windows NT 4.0 e também são compatíveis com RFC. Esses arquivos são explicados detalhadamente nesta seção.

O arquivo de banco de dadosO arquivo de banco de dados ou ‘arquivo de zona’ é o arquivo que contém os registros de recursos da parte do domínio pela qual a zona é responsável. Alguns dos registros de recursos comuns são fornecidos abaixo. Para obter uma lista completa, procure no Apêndice deste documento ou consulte as RFCs apropriadas. O Windows NT 4.0 fornece um arquivo como modelo com o qual trabalhar, denominado "place.dns". Esse arquivo deve ser editado e renomeado antes que seja utilizado em um servidor de produção DNS. Geralmente, será conveniente nomear esse arquivo da mesma maneira que a zona que ele representa. Esse é o arquivo que será duplicado entre principais e secundários.

O início de autoridade

O primeiro registro em qualquer arquivo de banco de dados é o registro início de autoridade (SOA, Start Of Authority).

 

IN SOA <host de origem> <correio eletrônico de contato> <no. série> <tempo de atualização><tempo de retentativa> <tempo de expiração> <TTL>

 

         host de origem - O host no qual este arquivo é mantido.

         correio eletrônico de contato - O endereço do correio eletrônico da Internet do responsável pelo arquivo de banco de dados desse domínio.

 

Em vez de escrever o símbolo ‘@’ no endereço do correio eletrônico como normalmente seria feito, o ‘@’ deve ser substituído por um ‘.’ quando colocado nos arquivos de zona. Em outras palavras, o endereço do correio eletrônico glennwo@microsoft.com seria representado como glennwo.microsoft.com no arquivo de zona.

 

         número de série - O "número da versão" deste arquivo de banco de dados. Esse número deve ser aumentado sempre que o arquivo de banco de dados for alterado.

         tempo de atualização - O tempo decorrido (em segundos) que um servidor secundário deve esperar entre verificações em seu servidor mestre para ver se o arquivo de banco de dados foi alterado e uma transferência de zona deve ser solicitada.

         tempo de retentativa - O tempo decorrido (em segundos) que um servidor secundário deve esperar antes de tentar novamente uma transferência de zona que falhou.

         tempo de expiração - O tempo decorrido (em segundos) que um servidor secundário continuará tentando descarregar uma zona. Após a expiração desse tempo limite, as informações da zona antiga serão descartadas.

         tempo de vida - O tempo decorrido (em segundos) que um servidor DNS pode armazenar em cache qualquer registro de recursos desse arquivo de banco de dados. Esse é o valor enviado com todas as respostas de consultas desse arquivo de Zona quando o registro individual não contém um valor de sobreposição.

 

Para que um registro de recurso possa abranger uma linha em um arquivo de banco de dados, as quebras de linhas devem estar entre parênteses.

 

Em um arquivo de zona, o símbolo ‘@’ representa o domínio raiz da zona (microsoft.com nos exemplos abaixo). O ‘IN’ nos registros a seguir é a classe de dados. Ele representa Internet. Existem outras classes, mas nenhuma delas está sendo amplamente utilizada atualmente.

 

Qualquer nome de domínio no arquivo de banco de dados que não seja terminado com um ponto ‘.’ terá o domínio raiz anexado ao final.

 

Exemplo:

 

@ IN SOA servidordenome1.microsoft.com. glennwo.microsoft.com. (

1 ; número de série

10800 ; atualização [3 horas]

3600 ; retentativa [1 hora]

604800 ; expiração [7 dias]

86400 ) ; tempo de vida [1 dia]

 

A definição do Intervalo de atualização dos servidores é o equilíbrio entre a consistência dos dados (exatidão dos seus dados) e a carga da sua rede.

O registro de servidores de nome

Lista os servidores de nome deste domínio permitindo que os outros servidores de nome procurem por nomes em seu domínio.

 

<domínio> IN NS <servidordenome host>

 

Exemplo:

@ IN NS servidordenome2.microsoft.com.

@ IN NS servidordenome3.microsoft.com.

O registro do sistema de mensagens

Este registro nos informa o que os processos host enviam para esse domínio. Caso existam vários registros do sistema de mensagens, o resolvedor tentará contatar os servidores de mensagens em ordem de preferência, do valor mais baixo (maior prioridade) ao valor mais alto (menor prioridade). Utilizando os registros de exemplo a seguir, a mensagem endereçada para scottsu@microsoft.com será entregue para scottsu@servidordecorreio0.microsoft.com primeiro, se possível e, em seguida, para scottsu@servidordecorreio1.microsoft.com se o servidordecorreio0 não estiver disponível.

 

<domínio> IN MX <preferência> <servidordecorreio host>

 

Exemplo:

@ IN MX 1 servidordecorreio0

@ IN MX 2 servidordecorreio1

O registro do host

O registro do host é utilizado para associar estaticamente nomes de hosts a endereços IP dentro de uma zona. Ele deve conter entradas para todos os hosts que necessitam de mapeamentos estáticos, inclusive estações de trabalho, servidores de nomes, servidor de mensagens etc. Estes são os registros que compõem a maior parte dos arquivos de banco de dados quando são utilizados registros estáticos.

 

<nome do host> IN A <endereço ip do host>

 

Exemplo:

rhino IN A 157.55.200.143

servidordenome2 IN A 157.55.200.2

servidordecorreio1 IN A 157.55.200.51

O registro do host local

O registro do host local permite que as procuras por “localhost.microsoft.com.” retornem 127.0.0.1.

 

localhost IN A 127.0.0.1

O registro CNAME

Estes registros são chamados algumas vezes de “aliases”, mas são tecnicamente designados como entradas de “Nome Canônico” (CNAME). Esses registros permitem que mais de um nome seja utilizado para apontar um único host.

 

O uso de nomes canônicos facilita a realização de tarefas como receber um servidor FTP e um servidor WEB na mesma máquina.

 

<nome alias do host> IN CNAME <nome do host>

 

Exemplo:Suponha que www.microsoft.com e ftp.microsoft.com estejam na mesma máquina. Sendo assim, possivelmente você terá as seguintes entradas em seu arquivo de zona:

 FileServer1 IN A 157.55.200.41

 ftp CNAME FileServer1www CNAME FileServer1

 Se você pretende mover o serviço do servidor FTP afastando-o do serviço de WEB, você simplesmente terá que alterar o CNAME no servidor DNS para ftp e adicionar um registro de endereço para o novo servidor. Por exemplo:

ftp CNAME FileServer2FileServer2 IN A 157.55.200.42

O arquivo de cacheO arquivo de cache contém informações sobre o host necessárias para a resolução de nomes fora dos domínios de autorização. Ele contém nomes e endereços de servidores de nome raiz. Para usuários na Internet, o arquivo padrão fornecido com o serviço DNS Microsoft deve ser suficiente. Para instalações NÃO conectadas à Internet, o arquivo deve ser substituído a fim de conter os servidores de nomes de autorização para a raiz da rede particular.

 

Para um arquivo de cache da Internet atual, consulte ftp://rs.internic.net/domain/named.cache

 

Exemplo:; DNS CACHE FILE;; Initial cache data for root domain servers.;; YOU SHOULD CHANGE:; - Nothing if connected to the Internet. Edit this file only when; update root name server list is released.; OR; - If NOT connected to the Internet, remove these records and replace; with NS and A records for the DNS server authoritative for the; root domain at your site.; Internet root name server records:; last update: Sep 1, 1995; related version of root zone: 1995090100;; formerly NS.INTERNIC.NET. 3600000 IN NS A.ROOT-SERVERS.NET.A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4; formerly NS1.ISI.EDU. 3600000 NS B.ROOT-SERVERS.NET.B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107; formerly C.PSI.NET. 3600000 NS C.ROOT-SERVERS.NET.C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12; formerly TERP.UMD.EDU. 3600000 NS D.ROOT-SERVERS.NET.D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90; formerly NS.NASA.GOV. 3600000 NS E.ROOT-SERVERS.NET.E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10; formerly NS.ISC.ORG. 3600000 NS F.ROOT-SERVERS.NET.F.ROOT-SERVERS.NET. 3600000 A 39.13.229.241; formerly NS.NIC.DDN.MIL. 3600000 NS G.ROOT-SERVERS.NET.G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4; formerly AOS.ARL.ARMY.MIL. 3600000 NS H.ROOT-SERVERS.NET.; End of File

  

O arquivo de procura invertidaEste é um arquivo de banco de dados utilizado para procuras invertidas em determinadas zonas de nomes de host IP do DNS quando fornecidas com os números IP. Isso permite ao resolvedor fornecer um endereço IP e solicitar um nome do host correspondente. Esse arquivo contém os registros do Servidor de nomes e SOA semelhantes aos outros arquivos de banco de dados de zona do DNS. Também contém registros apontadores.

 

O recurso de procura invertida do DNS é importante porque alguns aplicativos fornecem os recursos para a implementação de segurança tendo por base os nomes de host de conexão. Por exemplo, se um cliente tenta

estabelecer um vínculo entre um volume do sistema de arquivos de rede (NFS, Network File System) e esse arranjo de segurança, o servidor NFS entrará em contato com o servidor DNS e fará uma procura inversa do nome no endereço IP de clientes. Se o nome do host retornado pelo servidor DNS não estiver na lista de acesso para o volume NFS ou se o nome do host não tiver sido encontrado pelo DNS, a solicitação de montagem do NFS será negada. Este recurso de procura inversa é geralmente utilizado também para solução de problemas, o que será discutido posteriormente neste documento.

 

Abaixo estão dois exemplos de zonas para redes com classes IP diferentes.

Exemplo de zona classe C:

100.200.192.in-addr.arpa Exemplo de zona classe B:

55.157.in-addr.arpa

O registro de ponteiro

Os registros de ponteiro fornecem um mapeamento estático dos endereços IP para nomes do host dentro de uma zona de procura inversa. Os números IP são escritos em ordem inversa e “in-addr.arpa.” é anexado ao final para criar o registro de ponteiro. Como um exemplo, a procura por “157.55.200.51” requer uma consulta PTR para o nome “51.200.55.157.in-addr.arpa.”.

 <nome de domínio ip inverso> IN PTR <nome do host> Exemplo:

51.200.55.157.in-addr.arpa. IN PTR servidordecorreio1.microsoft.com.

O arquivo Arpa-127.revEste é um arquivo de banco de dados do domínio 127.in-addr.arpa. Esse domínio é utilizado para procuras inversas de números IP na rede 127, como “localhost”. As únicas coisas que mudam nesse arquivo são os registros SOA e NS.

O arquivo de inicialização BINDApesar do arquivo de inicialização, na realidade, não estar definido nas RFCs e não ser necessário que haja conformidade com RFC, ele é descrito aqui para integridade. Este arquivo, na realidade, faz parte da implementação específica de BIND do DNS. O DNS da Microsoft poderá ser configurado para utilizar um arquivo de inicialização caso você pretenda administrá-lo através de alterações dos arquivos de texto, em vez de utilizar a UI de Administrador de DNS.

 

Este arquivo controla o comportamento da inicialização do servidor DNS. Os comandos devem iniciar no começo de uma linha sem qualquer espaço antes deles. Os comandos reconhecidos são: “pasta, cache, primário e secundário”. A sintaxe para esse arquivo é:

Comando directory

Especifica uma pasta onde os outros arquivos, que o arquivo de inicialização faz referência, podem ser encontrados.

 

directory <pasta>

Exemplo:

directory c:\winnts\system32\dns

Comando cache

Especifica o arquivo utilizado para ajudar o serviço DNS a contatar servidores de nomes do domínio raiz. O comando e o arquivo ao qual ele faz referência DEVE estar presente. Um arquivo de cache adequado para uso na Internet é fornecido com o Windows NT 4.0.

 

cache . <nome do arquivo>

 

Exemplo:

cache . cache

Comando primary

Especifica um domínio para o qual esse servidor de nomes é de autorização e um arquivo de banco de dados que contém os registros de recurso para esse domínio (ou seja, arquivo de zona). Vários registros de comando primary podem existir no arquivo de inicialização.

 

primary <domínio> <nome do arquivo>

 

Exemplo:

primary microsoft.com microsoft.dnsprimary dev.microsoft.com dev.dns

Comando secondary

Especifica um domínio para o qual esse servidor de nomes é de autorização, e uma lista de endereços IP do servidor mestre a partir da qual tenta-se carregar as informações sobre a zona em vez de visualizá-las em um arquivo. Ele define também o nome do arquivo local para cache dessa zona. Vários registros de comando secondary devem existir no arquivo de inicialização.

 

secondary <domínio> <lista de host> <nome do arquivo local>

 

Exemplo:

secondary test.microsoft.com 157.55.200.100 test.dns 

Implementando o DNS utilizando o Microsoft Windows NT 4.0

Você poderá utilizar o DNS da Microsoft se quiser substituir os servidores DNS UNIX por sistemas baseados em Windows NT ou se precisar integrar clientes Microsoft WINS ativos em um ambiente baseado em UNIX.Algumas pessoas poderiam perguntar o que é o Microsoft DNS e por que deveriam utilizá-lo? Começaremos dizendo a você o que ele não é. Primeiro, o servidor Microsoft DNS não é um transporte do código BIND de Berkley (que se encontra atualmente na revisão 10.4 a partir da elaboração deste documento). Tomamos uma decisão consciente de não transportar o código BIND, mas sim escrever nosso próprio código, que atende totalmente a RFC e é compatível com BIND. Tomamos essa decisão porque queríamos adicionar com facilidade as melhorias de desempenho ao produto. O servidor DNS da Microsoft também não é o código que acompanhou o Windows NT Resource Kit. Se você utilizou esse utilitário, provavelmente observou que ele tinha problemas com transferências de zonas. O serviço do servidor DNS do Windows NT 4.0 é uma reedição completa e não simplesmente uma versão destinada a corrigir erros. Tenha certeza de que no DNS do Windows NT 4.0, a conformidade com RFC foi completamente testada e tudo funciona da forma como definido, inclusive as transferências de zonas.

 

Vamos falar agora sobre o servidor DNS da Microsoft. Em primeiro lugar e principalmente, o servidor DNS no Windows NT 4.0 é uma implementação do DNS que está em conformidade com a RFC. Isto significa que o servidor DNS da Microsoft atende todas as especificações documentadas nos padrões industriais para DNS a partir da data de liberação do Windows NT 4.0. Se existir um recurso necessário na RFC que não seja encontrado no produto Microsoft DNS, isto será considerado um erro.

 

Em virtude do Microsoft DNS ser um servidor DNS compatível com RFC, ele cria e utiliza arquivos de zona DNS padrão e suporta todos os tipos de registros de recurso padronizados. Ele é capaz de interfuncionamento com outros servidores DNS e inclui o padrão de fato de utilitário de diagnóstico do DNS - NSLOOKUP. O DNS da Microsoft possui também muitos recursos acima e além daqueles especificados nas RFCs, como a atualização dinâmica através da perfeita integração com WINS e fácil administração através do utilitário gráfico de administração denominado Gerenciador DNS.

 

O Microsoft DNS suporta as RFCs 1033, 1034, 1035, 1101, 1123, 1183 e 1536

 

Com a implementação do DNS da Microsoft, os administradores de rede poderão afastar os sistemas DNS antigos em favor de uma implementação Microsoft Windows NT. Eles são capazes de remover qualquer entrada estática de clientes Microsoft nos arquivos de zona do servidor de DNS antigo em favor da integração

Introdução ao Microsoft DNS

dinâmica WINS/DNS. Por exemplo, ser um cliente não-Microsoft desejar obter uma página de WEB em um servidor HTTP ativado para DHCP/WINS, o cliente poderá consultar o servidor DNS, o servidor DNS poderá consultar o WINS e o nome poderá ser resolvido e retornado ao cliente. Antes da integração do WINS, não havia uma maneira confiável para a resolução do nome devido ao endereçamento IP dinâmico.

 

 

 

A figura a seguir mostra como um cliente não-Microsoft poderia localizar um computador ‘scottsu1.microsoft.com’ executando o servidor de informações da Internet (IIS, Internet Information Server) da Microsoft que possui um endereço alocado de forma dinâmica do DHCP registrado no WINS.

 

Igualmente, como mencionado anteriormente, o servidor DNS da Microsoft possui uma interface gráfica de Gerenciador DNS que permite fácil administração de qualquer outro servidor DNs da Microsoft na rede através de RPC (semelhante à maneira como funcionam outros utilitários de administração do Windows NT, como o Gerenciador de servidores e o Visualizar eventos). A UI de administração também contém um assistente de zona que torna possível a qualquer pessoa que não esteja familiarizada com o DNS ser bem-sucedida ao criar zonas e arquivos de bancos de dados. Lembre-se de que você não pode administrar servidores DNS não-Microsoft com esta Ferramenta administrativa.

É importante observar que o servidor DNS da Microsoft é capaz de utilizar facilmente os arquivos de banco de dados, inicialização, cache, rev e outros, de qualquer outra implementação de servidor DNS (isto é, UNIX ou outra implementação DNS do Windows NT) desde que esse servidor DNS seja compatível com RFC. Tudo o que precisa ser feito para transportar os arquivos para o DNS da Microsoft é mudar os nomes dos arquivos e os locais no Arquivo de inicialização.

 

Apesar do Microsoft DNS oferecer suporte a um arquivo de inicialização na instalação inicial, o arquivo de inicialização é uma implementação específica de BIND e não uma exigência das RFCs. Este recurso é fornecido para fácil migração de Servidores DNS baseados em BIND. Se a ferramenta UI do Gerenciador DNS Microsoft for utilizada para criar e administrar arquivos de zona, esta opção “Inicializar do arquivo de inicialização” será definida para “Inicializar do registro” e o Microsoft DNS armazenará e utilizará os

dados do registro NT para localizar e carregar os bancos de dados do arquivo de zona. Uma mensagem será gravada no arquivo de INICIALIZAÇÃO declarando que a informa-ção encontra-se agora no registro. Para voltar e inicializar a partir do arquivo de inicialização, o valor da chave ‘EnableRegistryBoot’ no registro do Windows NT precisará ser modificado manualmente.

O servidor Microsoft DNS também poderá ser primário ou secundário para qualquer sistema operacional (ou implementação Windows NT de outros fornecedores). Isto facilita começar a migração de uma solução DNS UNIX para uma solução Microsoft.

 

A próxima seção guiará você através da configuração de um servidor Microsoft DNS e explicará os parâmetros necessários para que um cliente Resolvedor possa trabalhar.

Instalando o serviço DNS

Verificar as informações sobre o Windows NT DNS

Antes de instalar o serviço Microsoft DNS, é importante que a pilha TCP/IP do Windows NT 4.0 Server seja corretamente configurada. Especialmente, será necessário verificar a seção DNS, uma vez que o serviço DNS obtém muitas de suas definições padrão desta seção durante a instalação.

 

Para verificar estas informações, execute o Painel de controle e vá para Rede. Clique na guia Protocolos. Escolha a caixa de diálogo de propriedades do Protocolo TCP/IP e clique na guia DNS. Certifique-se de que o Nome do Host e do Domínio estejam corretamente preenchidos nesta tela.

 

O servidor

 Se o nome do domínio e o nome do host forem fornecidos na configuração do Painel de controle da rede ao criar uma zona, o DNS adicionará um registro SOA, A e NS ao banco de dados. Se as informações não estiverem configuradas, somente o registro SOA será criado.

 

Instalando o serviço Microsoft DNS

Para instalar o Serviço Microsoft DNS no Windows NT 4.0, execute o Painel de controle e vá para Rede. Clique na guia Serviços e depois no botão Adicionar. Selecione Microsoft DNS Server e clique em OK.

 

 

Neste ponto, uma instalação padrão do serviço Microsoft DNS Server será instalada no NT Server. Esta instalação irá instalar arquivos na pasta \<Raizdosistema>\system32\Dns, como mostrado. Neste ponto você será solicitado a reinicializar o servidor.

 

 

Configurando domínios e zonas do DNSPara configurar o servidor DNS, execute o Gerenciador DNS nas Ferramentas administrativas. Inicialmente, o Gerenciador DNS não terá qualquer servidor em sua lista. Para adicionar o servidor local, abra o menu suspenso DNS e clique em Novo servidor. Preencha o nome do servidor local e clique em OK.

O servidor aparecerá então na Lista de servidores. Clique duas vezes sobre o servidor para ver as Estatísticas do servidor e as Zonas que foram definidas.

 

 

Como inicialmente o servidor DNS não possui informações sobre sua rede específica, o serviço DNS Server é instalado como um servidor de nomes somente de cache para a Internet. Isto significa que o DNS somente contém informações sobre os servidores raiz da Internet. Para a maioria das configurações DNS, informações adicionais devem ser fornecidas para obter a operação desejada.

 

O primeiro passo na configuração do servidor DNS é determinar a hierarquia dos domínios e zonas do DNS. Considerações sobre a criação da hierarquia de um DNS são fornecidas na próxima seção deste documento. Uma vez determinadas as informações de domínio e zona, estas informações devem ser introduzidas na configuração do DNS utilizando o Gerenciador DNS.

 

Como as informações do DNS são agrupadas e controladas por zonas, será necessário primeiro criar uma zona. Para tanto, clique sobre o nome do servidor com o botão alternado do mouse e, em seguida, clique sobre Nova Zona.

 

Se você clicar duas vezes na zona CACHE, será possível visualizar a totalidade dos hosts definidos estatisticamente pelo servidor DNS e armazenados dinamicamente em cache devido a uma consulta anterior. A CACHE também mostrará a totalidade das entradas WINS que foram resolvidas e não gastaram seu Valor de Tempo Limite de Cache específico do WINS.

  

Neste ponto, é apresentado um diálogo que pergunta se a Zona que você está criando é uma zona primária (informações armazenadas localmente) ou uma zona secundária (informações obtidas de um servidor mestre através de uma transferência de zona). Se for uma zona primária, nenhuma informação adicional será necessária nesta etapa. Se for uma zona secundária, será necessário informar também os nomes da zona e do servidor mestre nesta tela.

 

 

O próximo passo é preencher as informações de Nome da zona e Arquivo de zona para o servidor local. Isto determinará a maneira como a zona será apresentada no Gerenciador DNS e o nome do arquivo sob o qual ela está armazenada. Em se tratando de uma zona secundária, o nome desta zona deve corresponder ao nome da zona do servidor mestre. Se este arquivo de zona já existir na pasta DNS, os registros serão importados automaticamente pelo DNS quando a zona for criada.

 

 

Em se tratando de uma zona secundária, você será solicitado a digitar o endereço IP dos servidores de nome principais (os servidores de nome com os quais você fará transferências de zona para esta zona).

 

 

Quando todas as informações tiverem sido fornecidas, a zona será adicionada à hierarquia do DNS. Se você precisar adicionar mais zonas, siga o mesmo procedimento para cada uma delas. Depois que todas as zonas tiverem sido adicionadas ao servidor, você deverá, em seguida, adicionar todos os subdomínios do DNS das

zonas que sua hierarquia possa conter. Para tanto, clique sobre a zona adequada com o botão alternado do mouse e clique em Novo domínio.

 

Digite, na caixa de diálogo, o nome do novo subdomínio e clique em OK. Se forem necessários vários níveis de subdomínios, crie cada subdomínio sucessivo clicando sobre o pai imediato com o botão alternado do mouse, clicando em Novo domínio e digitando o nome do novo subdomínio.

 

Este processo pode também ser utilizado para adicionar registros de recurso ou novo host em qualquer local de domínio no âmbito da hierarquia do DNS.

 

Integração com Procura WINS

O registro WINS

Embora o DNS possa parecer semelhante ao WINS (Windows Internet Naming Service), existem algumas diferenças importantes. O DNS é um banco de dados estático de endereços IP para mapeamento de nome para endereço, que deve ser atualizado manualmente por um administrador. Igualmente, o DNS possui um conceito hierárquico, permitindo que a administração e duplicação do banco de dados sejam subdivididas em “zonas”. O WINS, por outro lado, permite que as máquinas registrem de forma dinâmica seus mapeamentos de nome para endereço, exigindo, portanto, muito menos administração. O WINS também é um espaço de nome plano sem o conceito de hierarquia, exigindo que cada servidor WINS mantenha um banco de dados completo de entradas através de duplicação.

O servidor Microsoft DNS trabalha em perfeita integração com o servidor Microsoft WINS e fornece muita interfuncionalidade. Para fornecer essa interfuncionalidade, um novo registro foi definido como parte do arquivo de banco de dados de zona. O registro WINS é específico do Windows NT e pode ser anexado somente ao domínio da zona raiz. A presença de um registro WINS instrui o servidor de nomes a utilizar o WINS para procurar solicitações de hosts na zona raiz que não possuam endereços estáticos no banco de

dados IP. Esta funcionalidade é especialmente útil para clientes UNIX que precisem contatar clientes com DHCP/WINS ativado através de IP.

 

<domínio> IN WINS <endereço IP do servidor WINS>

 

Exemplo:

@ IN WINS 157.55.200.81

Ativando a Procura WINS

A Procura WINS pode ser ativada para uma zona através do Gerenciador DNS em vez de exigir entrada manual do registro WINS. Isto é feito clicando sobre a zona com o botão alternado do mouse e clicando em propriedades. Em seguida, clique na guia Procura WINS. Marque a caixa de verificação Utilizar resolução WINS e preencha o endereço IP do servidor WINS que você deseja utilizar e clique em Adicionar. É possível digitar vários endereços de servidores WINS.

 

Você provavelmente precisará utilizar a procura WINS somente se tiver clientes TCPIP ‘não-MS’ que precisem resolver Nome do Host para endereços IP? Por exemplo, se houver necessidade em sua empresa de utilizar FTP ou HTTP nos servidores Windows NT de clientes não-MS (ou seja, UNIX).

 

Se você tiver uma zona configurada para executar procura WINS, então será necessário que todos os servidores DNS que tenham autorização para aquela zona sejam capazes de executar procura WINS ou você terá um comportamento intermitente.

 

Para adicionar com facilidade a procura Microsoft WINS / DNS a uma arquitetura DNS antiga, simplesmente crie um novo subdomínio DNS em sua empresa e faça com que os servidores Windows NT primário e secundário sejam ativados para executar procura WINS nesse domínio. Por exemplo, na figura abaixo há um domínio acme.com e um domínio Msdomain.acme.com. A totalidade dos clientes Microsoft registram-se no servidor WINS no domínio Msdomain.acme.com.

 

 A procura WINS é realizada por zona DNS. Desta forma, uma consulta a um servidor DNS para scottsu1.microsoft.com iria para o servidor WINS se o DNS que possui o registro de procura WINS fosse de autorização para a zona microsoft.com, porém uma consulta para scottsu1.dallas.microsoft.com iria para aquele mesmo servidor WINS. Isto é mostrado na figura a seguir.

 

 

Se você estiver utilizando um registro WINS, o tempo de vida no registro SOA também não será o padrão para WINS; o WINS TTL é configurado através da caixa de diálogo Propriedades avançadas da zona (na guia Procura WINS) durante a configuração da zona. Quando a resolução de um endereço IP / Nome do host é obtida através de WINS, o endereço é armazenado em cache pelo Valor do Tempo Limite de Cache WINS. Se esse endereço for encaminhado para outro DNS, será enviado o Valor de Tempo limite de Cache WINS.

 

 

Se os seus dados não sofrerem alterações freqüentes, você poderá definir um TTL alto. Lembre-se de que você pode também definir o TTL em registros individuais.

 Se o TTL de um endereço RR individual for menor ou maior do que o TTL do registro SOA, o TTL terá preferência.

WINS e Procura inversa

O registro de Procura inversa WINS

Apesar do WINS não ter sido construído para fornecer recursos de procura inversa, esta funcionalidade poderá ser obtida para clientes com DHCP/WINS ativado ao utilizar o servidor DNS do DNS. A presença de um registro WINS-R na zona raiz instrui o servidor de nomes para utilizar procura de estado de adaptador de nó NetBIOS para qualquer solicitação de procura inversa de endereços IP na raiz da zona que não sejam estaticamente definidos com registros.

 

<domínio> IN WINS-R <domínio a ser anexado aos nomes NetBIOS retornados>

 

Exemplo:

@ IN WINS-R microsoft.com.

Ativando a Procura inversa WINS

A Procura inversa WINS pode ser ativada para uma zona através do Gerenciador DNS, em vez de exigir a entrada manual do registro WINS-R. Isto é feito clicando na zona in-addr.arpa adequada com o botão alternado do mouse e clicando em Propriedades. Em seguida, clique na guia Procura inversa WINS.

Marque a caixa de verificação Procura inversa WINS e preencha o Domínio de host DNS a ser anexado ao nome NetBIOS antes de retornar a resposta ao resolvedor.

 

 O servidor Microsoft DNS pode ser configurado para NÃO enviar registros WINS para servidores secundários. Isto será necessário se você tiver uma combinação de servidores DNS Microsoft e UNIX, uma vez que os servidores DNS UNIX não possuem recursos para realizar procura WINS.

O que você deve saber

O servidor Microsoft DNS suporta ‘Notificação’

A transação DNS NOTIFY permite que os servidores principais informem aos servidores quando a zona for alterada (Notificar é definido no servidor mestre, por zona) – uma interrupção, ao contrário do modelo de pesquisa. Esta ação deve reduzir o tempo de propagação sem aumentar indevidamente a carga do servidor mestre.

 

O uso deste recurso depende da freqüência em que os dados do servidor mestre serão alterados e da velocidade do vínculo entre o secundário e o primário. Se os dados do servidor mestre forem alterados com muita freqüência, será importante que os dados nos secundários sejam muito precisos e que o vínculo entre o local que aloja o primário e o secundário não seja negativamente influenciado pela transferência de zona, então será conveniente utilizar este recurso.

 

Também será conveniente utilizar este recurso se os dados do servidor mestre não forem alterados com muita freqüência. Neste caso, você poderá definir um tempo de atualização mais longo e uma notificação será enviada para os secundários quando eles precisarem atualizar os bancos de dados de sua zona.

O Microsoft DNS suporta ‘Rodízio’

Rodízio é uma técnica utilizada como uma forma de equilíbrio de carga entre servidores. Você poderá ler mais a respeito de equilíbrio de carga na RFC 1794. Abaixo encontra-se um exemplo que mostra como isto funciona:

 

No servidor DNS, você poderia ter 2 entradas de endereço para o mesmo host, como as seguintes:

 

copperhead.glennwo.scottsu.com A 157.55.106.193

copperhead.glennwo.scottsu.com A 157.55.107.88

 

Se você fizer uma consulta através de algum mecanismo como “PING copperhead.glennwo.scottsu.com”, o servidor DNS retornará os dois endereços IP, mas tipicamente o cliente sempre utilizará o primeiro endereço. A próxima vez que o servidor DNS receber uma consulta para esse host, a ordem da lista será alterada em rodízio (o endereço que era o primeiro na lista anterior passará a ser o último na lista nova), portando quando o resolvedor cliente escolher o primeiro endereço IP da lista, ele estará escolhendo um servidor diferente. Isto é tipicamente utilizado para equilíbrio da carga.

 

Abaixo encontra-se um rastreamento que mostra como o recurso trabalha. No quadro 1, uma consulta é enviada para obter o endereço IP do host ‘copperhead.glennwo.scottsu.com’. Como havia duas entradas no banco de dados, ambas foram retornadas. O resolvedor cliente, na maioria das implementações (inclusive o resolvedor MS) utiliza a primeira entrada e ignora a outra. 1 SCOTTSU-7 Xircom40417A DNS 0x1:Std Qry for copperhead.glennwo.scottsu.com  DNS: 0x1:Std Qry for copperhead.glennwo.scottsu.com of type Host Addr on class INET addr. 2 Xircom40417A SCOTTSU-7 DNS 0x1:Std Qry Resp. for copperhead.glennwo.scottsu.com  DNS: 0x1:Std Qry Resp. for copperhead.glennwo.scottsu.com of type Host Addr on class INET addr.....DNS: Answer section: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr.(2 records present) DNS: Resource Record: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Resource Name: copperhead.glennwo.scottsu.com DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 157.55.107.88 DNS: Resource Record: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Resource Name: copperhead.glennwo.scottsu.com DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 3600 (0xE10) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 157.55.106.193  

A próxima vez que alguém fizer uma consulta sobre o host copperhead.glennwo.scottsu.com o primeiro endereço IP da lista será diferente. DNS: Answer section: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr.(2 records present) DNS: Resource Record: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Resource Name: copperhead.glennwo.scottsu.com DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 3600 (0xE10)

DNS: Resource Data Length = 4 (0x4) DNS: IP address = 157.55.106.193 DNS: Resource Record: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Resource Name: copperhead.glennwo.scottsu.com DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 157.55.107.88 

Escopo NetBIOS

A principal coisa que você deve se lembrar sobre o suporte DNS para o escopo NetBIOS é NÃO UTILIZÁ-LO... a menos que sua rede já utilize o escopo NetBIOS. Em uma configuração de escopo, todos os hosts recebem uma identificação de escopo e registram essa identificação junto com seu nome NetBIOS no WINS. Se o DNS for configurado para utilizar o escopo, ao fazer uma consulta ao WINS, além de passar o nome do host DNS como o nome simples do NetBIOS, ele passa também o domínio DNS como a identificação do escopo NetBIOS.

Um ponto muito importante para se lembrar sobre o escopo é que quando ele é utilizado, os aplicativos NetBIOS não podem ver os hosts que estão em outro escopo! Um aplicativo NetBIOS dessa natureza é o serviço NetLogon do NT responsável pelos relacionamentos confiáveis entre os domínios NT. Isto significa, por exemplo, que se o escopo for utilizado, um usuário não poderá efetuar logon em um domínio cujos controladores tenham um escopo diferente do escopo da estação do usuário. Significa também que um usuário não poderá acessar recursos de um servidor de rede em um domínio cujo escopo seja diferente do escopo da estação do usuário.

Quando o Microsoft DNS lê e grava nos arquivos de zona?

Na inicialização do serviço DNS, os arquivos de zona são lidos a partir do disco. À medida em que as alterações vão sendo feitas no Gerenciador DNS, o serviço periodicamente libera essas alterações para o disco. Em geral, você deve sempre utilizar o utilitário Gerenciador DNS para adicionar, excluir ou modificar registros de recursos do banco de dados; no entanto, se você achar necessário modificar os arquivos com um editor, as alterações nesses arquivos devem ser feitas somente se o serviço DNS for interrompido. Como padrão, os arquivos estão localizados em \%Raizdosistema%\system32\Dns.

 

Se você utilizar o utilitário de administração do DNS e escolher o item de menu DNS | Atualizar arquivos de dados do servidor, os arquivos também serão liberados da memória para disco.

O log de eventos

O servidor DNS relatará os eventos no log de eventos. Isto permitirá ao administrador determinar quando a transferência de zona foi completada ou quando o serviço DNS foi iniciado, interrompido, ou se ocorreu um erro.

 

 

ConfiguraçãoO procedimento exato necessário para configurar máquinas clientes individuais irá variar dependendo do

sistema operacional e do software TCP/IP que estiver sendo utilizado. Os procedimentos específicos para clientes não serão abordados neste documento; porém, serão discutidos os parâmetros gerais de configuração necessários e seus respectivos usos.

O nome do host O nome do host para o cliente pode ser qualquer combinação das letras de A até Z, dos números de 0 até 9 e do hífen (-). Como padrão, nos ambientes de rede Microsoft, esse valor é o nome do computador NetBIOS; porém é possível atribuir um nome do host diferente sem influenciar a operação do computador NetBIOS, se desejável. Se Procura WINS for utilizada com Microsoft DNS, esse valor deve corresponder ao nome do computador NetBIOS, para consistência.

Alguns caracteres que podem ser utilizados em nomes NetBIOS, especialmente o ponto e o sublinhado, não podem ser utilizados em nomes de host DNS.

O nome do domínioO nome do domínio é utilizado juntamente com o nome do host para criar um nome de domínio totalmente qualificado (FQDN, Fully Qualified Domain Name) para o computador. O FQDN é o nome do host seguido por um ponto (.), seguido pelo nome do domínio. Por exemplo, poderia ser wkstn1.microsoft.com, onde wkstn1 é o nome do host e microsoft.com é o nome do domínio. Durante consultas DNS, é utilizado o nome de domínio totalmente qualificado.

Os servidores DNSMuitos sistemas operacionais permitem que você especifique vários servidores DNS em suas configurações. Quando este recurso é fornecido, uma ordem de prioridade também é fornecida para que um servidor preferencial possa ser identificado. Para uma determinada consulta DNS, o sistema tenta obter informações de DNS do primeiro endereço IP da lista. Se nenhuma resposta for recebida, ele passa para o próximo servidor da lista e assim sucessivamente.

Na maioria dos sistemas, se você tiver dois servidores DNS listados, o sistema verificará o segundo servidor somente se nenhuma resposta for recebida do primeira servidor. Se o sistema tentar verificar o nome do host no primeiro servidor e receber uma mensagem de que o nome do host não foi reconhecido, o sistema não tentará o segundo servidor DNS.

A ordem de pesquisa do Sufixo de domínio Em alguns sistema, é fornecido um recurso de ordem de pesquisa do Sufixo de domínio. A ordem de pesquisa do sufixo de domínio especifica os sufixos de domínio DNS que devem ser anexados aos nomes de host durante a resolução do nome. Ao tentar resolver um nome de domínio totalmente qualificado (FQDN) a partir de um nome de host somente, o sistema primeiro anexará o nome do domínio local. Se não for bem-sucedido,

O resolvedor (cliente)

o sistema utilizará a lista Sufixo de domínio para criar FQDNs adicionais na ordem listada e consultará os servidores DNS para cada um deles.

 

Um exemplo de configuração cliente de uma máquina com Windows NT 4.0 é ilustrado abaixo.

Resolução de nomesOs sistemas Windows NT TCP/IP 3.5x podem utilizar vários métodos para localização de recursos NetBIOS:

         Cache de nomes NetBIOS          Servidor de nomes NetBIOS          Transmissões de sub-rede IP          Arquivos LMHOSTS estáticos          Arquivos HOSTS estáticos          Servidores DNS

 As implementações anteriores utilizavam somente cache, transmissões e arquivos LMHOSTS; no entanto, na versão 3.5, um servidor de nomes (WINS) NetBIOS foi adicionado e modificações foram feitas a fim de permitir a consulta do espaço de nome pelos aplicativos NetBIOS, anexando sufixos de domínio configuráveis a um nome NetBIOS. Contudo, a resolução de nome DNS era sempre feita por último, após a tentativa de cache NetBIOS, do arquivo LMHOSTS (se ativado), WINS (se ativado) e de difusão. Com o Windows NT 4.0, a resolução de nome DNS será tentada primeiro se o nome tiver mais de 15 caracteres (comprimento

máximo de um nome de computador NetBIOS no Windows NT). O nome do host agora pode ser utilizado em qualquer um dos utilitários do Windows NT (como o Explorer mostrado abaixo) que anteriormente suportavam nomes de computador NetBIOS. Esta funcionalidade também será futuramente disponibilizada no Windows 95.

 

Lembre-se de que o arquivo \%Raizdosistema%\system32\drivers\etc\HOSTS ainda poderá ser utilizado para resolução de nome do Host. No entanto, o DNS será consultado antes do arquivo HOSTS ser analisado.

Se o nome do Host DNS (com mais de 16 caracteres de comprimento) for passado para um utilitário e existirem dois transportes carregados em uma estação de trabalho (TCP e NetBEUI), somente o transporte TCP tentará estabelecer a sessão. Se o nome do Host não for utilizado, sendo utilizado o nome NetBIOS, uma tentativa será feita para todos os transportes.

 

Neste exemplo, eu também poderia ter utilizado:

\\157.55.100.204\public em vez de \\scottsu-7.scottsu.com\public.Para obter mais informações sobre resolução de nome NetBIOS, consulte o documento técnico denominado, “Microsoft® Windows NT™ Server 3.5 - Protocolo de configuração dinâmica de hosts e serviço de nomes Internet do Windows”, número 098-56544.

 Em um computador com Windows NT Workstation, se um nome do host não for encontrado através da resolução DNS, o nome será passado para NetBT (NetBIOS em TCPIP) para resolução através de WINS, arquivo LMHOSTS ou difusão. Isto poderá ser visto como um recurso para intranet que possuam muitos servidores WEB ou FTP e queiram obter a resolução através de WINS para consultas ao host.

Prakash Narasimhamurthy da Microsoft Consulting Services forneceu o fluxograma apresentado na figura abaixo, a fim de ilustrar a resolução de nome para os vários tipos de nós.

 

 

New Windows NT 4.0 functionality 

NslookupNslookup provavelmente será uma de suas principais ferramentas de diagnóstico ao depurar a arquitetura de um sistema de nomes de domínio (DNS). Esta ferramenta poderá ser utilizada para exibir qualquer registro de recurso em qualquer servidor DNS, inclusive em implementações DNS UNIX. NSLookup da maioria das outras implementações DNS também deverá funcionar no servidor MS DNS. Este é um utilitário de linha de comando e possui a seguinte sintaxe:

O personagem principal

 

nslookup [[-opção ...] [computador a ser localizado]] | - [servidor]

Modos

Nslookup possui dois modos: interativo e não-interativo.

 

Se você precisar procurar apenas um dado, use o modo não-interativo. Como primeiro argumento, digite o nome ou o endereço IP do computador a ser procurado. Como segundo argumento, digite o nome ou o endereço IP de um servidor de nomes DNS. Se você omitir o segundo argumento, será utilizado o servidor de nomes DNS padrão.

 

Se você precisar procurar mais do que um dado, poderá utilizar o modo interativo. Digite um hífen como o primeiro argumento e o nome ou endereço IP de um servidor de nomes DNS como o segundo argumento, ou omita os dois argumentos e o servidor de nomes DNS padrão será utilizado.

Parâmetros-opção ...É possível especificar um ou mais comandos nslookup como opção de linha de comando. Para obter uma lista de comandos, consulte ‘Comandos Nslookup’ no arquivo WINNT.HLP fornecido no Windows NT 4.0. Cada opção consiste de um hífen (-) seguido diretamente pelo nome do comando e, em alguns casos, de um sinal de igual (=) e, em seguida, um valor. Por exemplo, para mudar o tipo de consulta padrão para informação do host (computador) e o tempo limite inicial para 10 segundos, digite:

 

nslookup -querytype=hinfo -timeout=10

 

O comprimento da linha de comando deve ser inferior a 256 caracteres.

 

computador a ser localizadoEsta informação instrui o Nslookup a Procurar informações sobre o computador a ser localizado, utilizando o servidor padrão atual ou utilizando o servidor, se especificado. Se o computador a ser localizado for um endereço IP e o tipo da consulta for A ou PTR, o nome do computador será retornado. Se o computador a ser localizado for um nome e não tiver um ponto final, o nome do domínio DNS padrão será anexado ao nome. (Este comportamento depende do estado das opções definidas: domínios, srchlist, defname e pesquisa.). Para procurar um computador que não esteja no domínio DNS atual, anexe um ponto ao nome.

 

Se você digitar um hífen (-) em vez do computador a ser localizado, o aviso de comando mudará para o modo interativo nslookup.

 

servidorUse este servidor como o servidor de nomes DNS. Se você omitir o servidor, o servidor de nomes DNS padrão será utilizado.

 

Para obter mais informações sobre Nslookup do NT, verifique o arquivo WINNT.HLP fornecido com o Microsoft Windows NT 4.0.

Pontos fracos da implementação atual

Procura inversa ineficiente (NbtStat)

A integração DNS e WINS não possibilita uma ‘procura inversa’ de DNS eficiente. Tanto o servidor DNS quanto o host que está sendo localizado são envolvidos quando é feita uma solicitação de procura inversa para um cliente WINS, uma vez que o servidor DNS realiza a procura do estado do adaptador de nó NetBIOS a fim de resolver o endereço IP para um nome. Se a atualização dinâmica de DNS fosse uma RFC liberada e se ela fosse utilizada em vez da integração WINS, a procura inversa seria mais eficiente e envolveria apenas os servidores DNS.

Hosts não-Microsoft não se registram no WINS

Os hosts não-Microsoft não se registram no WINS e, portanto, não podem ser ‘dinamicamente registrados’ no DNS. Se a atualização dinâmica real do DNS fosse suportada pelo servidor DNS da Microsoft, os hosts não-Microsoft, que suportassem DNS dinâmico, seriam capazes de se registrar no Microsoft DNS e os hosts Microsoft poderiam ser dinamicamente registrados em DNS não-Microsoft que suportasse o padrão de atualização dinâmica do DNS.

Registro não seguro no WINS

O registro no WINS não é seguro e seria difícil torná-lo seguro. A IETF está trabalhando na conclusão de um padrão para dar mais segurança à atualização dinâmica do DNS. O padrão de segurança do DNS não está programado para entrar na rotina de padrões IETF até o quarto trimestre de 1996.

Integração DNS e WINS não é uma RFC

Embora a atualização dinâmica do DNS ainda não seja um padrão IETF, já existem algumas implementações. A Microsoft optou por esperar até sua padronização a fim de minimizar o impacto sobre nossos clientes se fossem feitas alterações antes do padrão ser liberado.

Enquanto o WINS baseia-se atualmente nos padrões IETF (RFC 1001, 1002), suas ‘raízes’ NetBIOS resultaram em aceitação muito limitada pela IETF e pela comunidade UNIX. A integração DNS e WINS não se baseia em padrões e portanto não é aceita.

APIs de resolvedores não são expostas

Atualmente não há uma maneira para consultar, por meio de programa, o banco de dados de DNS que não seja gethostbyname( ). Também, atualmente não é possível fazer coisas como consultar, por meio de programa, o DNS para um registro MX.

Criando soluções

 

DNS será uma parte importante da arquitetura avançada de Serviços de pasta na próxima revisão completa do Windows NT Server, portanto, é importante criar uma arquitetura DNS que permita uma transição/migração tranqüila.

Considerações sobre segurançaMuitas empresas hoje em dia desejam conectar suas redes internas à Internet a fim de permitir que seus funcionários possam acessar os recursos externos que precisam para complementar suas tarefas. Apesar de ser este um recurso importante, precisa ser muito bem planejado para evitar possíveis riscos de segurança dos dados, devido a exposição da rede interna a usuários fora da empresa. Uma maneira comum para fornecer essa proteção é o uso de um firewall. Na linguagem da Internet, um firewall é um sistema ou dispositivo que fornece segurança para a rede, permitindo que somente determinadas atividades autorizadas sejam realizadas entre redes internas e a Internet.

 

Um sistema de firewall pode ser muito simples ou extremamente complexo, dependendo das necessidades específicas de cada empresa. O intuito deste documento não é fornecer uma descrição completa da estrutura de um firewall; no entanto, falaremos um pouco sobre como o servidor DNS da Microsoft poderá ser utilizado em um ambiente com firewall.

 

A seguir encontra-se uma configuração típica de conectividade Internet para uma empresa utilizando firewall duplo (ou seja, proxy).

Utilizando o servidor de DNS da Microsoft para conexão com a Internet

 

O firewall fornece proteção contra o acesso externo, enquanto permite o acesso de clientes da rede interna aos recursos da Internet. Este projeto também permite servidores FTP e WWW externos. Os servidores externos devem ser rigorosamente monitorados e providos da máxima segurança possível, uma vez que eles estão diretamente na rede Internet sem qualquer tipo de controle de acesso do tipo “firewall”. O roteador poderá fornecer alguma segurança mediante a filtragem de pacotes, se desejável, para limitar o tipo de tráfego permitido. O acesso à rede interna é controlado pelo firewall.

 

O servidor WEB interno poderá ser configurado exatamente igual ao servidor externo, exceto que os itens de segurança estarão limitados aos controles de acesso necessários para os funcionários da empresa. Normalmente, apenas os responsáveis pelo desenvolvimento da WEB irão realmente efetuar logon nos servidores internos para alterar arquivos localizados nos servidores, embora qualquer pessoa possa ser autorizada a visualizar páginas da Web utilizando um navegador.

 

O Sistema de nomes de domínio para as redes interna e externa geralmente são completamente isolados um do outro. Isto impede que clientes externos obtenham os nomes e endereços de recursos internos localizados dentro do firewall. A única coisa que será vista por um usuário externo será o endereço IP dos servidores que estão fornecendo serviços externos (ou seja, ftp, www, correio etc.).

Projeto típico de conectividade InternetCom esses itens de segurança já estabelecidos, vejamos então um projeto típico de conectividade Internet e principalmente a maneira como os servidores DNS devem ser configurados. Encontra-se abaixo um diagrama de uma empresa de grande porte que possui vários recursos internos e externos que exigem serviços DNS.

 

Há vários itens que devem ser observados sobre esse exemplo de rede antes de começarmos nossa discussão sobre as configurações do DNS. São eles:

         A Acme possui um servidor DNS primário e secundário para os serviços externos que ela mantém (isto é, dns-server1.acme.com e dns-server2.acme.com). Há também um servidor DNS secundário para sua zona acme.com que é mantido pelo Provedor de serviços da Internet para redundância (isto é, dns13.my-isp.net). Esses servidores de nomes são de autorização sobre os domínios acme.com e 100.250.192.in-addr.arpa.

         Alguns serviços externos estão sendo mantidos em vários servidores espelhados.          Vários servidores de mensagens são utilizados para fornecer conectividade de mensagens

SMTP para acme.com.          Este projeto de rede utiliza filtragem de pacotes no roteador, bem como servidores proxy

com vários adaptadores de rede para implementar segurança.          A rede interna está utilizando WINS para registro/procura de clientes e servidores

Microsoft.          Alguns serviços Intranet (por exemplo, Serviços Web) estão sendo fornecidos em Windows

NT Servers internos.          Os serviços DNS da rede interna são isolados dos serviços DNS da Internet.          A rede interna é apresentada como um ambiente simples não-roteado para se obter uma

melhor clareza. 

Tendo em mente esses detalhes, vejamos como eles poderiam influenciar a arquitetura de DNS. Passaremos pelo processo de configuração de um servidor DNS externo primeiro e, em seguida, discutiremos o servidor DNS externo.

Configuração de servidor DNS interno

Após a instalação do serviço DNS nas máquinas com Windows NT Server (ou seja, dns-server1 e dns-server2), devemos utilizar a ferramenta Gerenciador DNS para criar uma zona primária para o domínio acme.com e uma zona primária de procura inversa para 100.250.192.in-addr.arpa no dns-server1. Isto criará um registro SOA, que contém o servidor de nomes primário ‘dns-server1.acme.com.’ e o endereço do sistema de mensagens do administrador do servidor DNS ‘web-master@acme.com’, assim como um registro NS separado para dns-server1. Como os parâmetros padrão restantes para essa zona são suficientes, não iremos modificá-los e os valores padrão serão colocados no registro SOA.

 

Os registros adicionais a seguir devem ser criados no domínio acme.com e isto deve ser feito com Criar de registro PTR associado ativado, quando aplicável.

 

Os registros do servidor de nomes (NS) devem ser criados para dns-server2 e dns13.my-isp.com. Os registros do sistema de mensagens (MX) devem ser criados para mail-server1 e mail-server2. Definiremos a preferência para esses dois como 10 para se obter equilíbrio da carga em igual proporção. Os registros de endereço (A) devem ser criados para cada um dos computadores conectados diretamente à Rede Internet exposta.

 

O nome real do servidor gopher em nosso exemplo é ‘gopher-server1.acme.com’. O padrão “de fato” para fornecimento de serviços na Internet é fornecê-los nos computadores com nomes de host que correspondam ao serviço que esteja sendo fornecido. Para que os usuários possam localizar facilmente nosso serviço gopher conectando ao padrão ‘gopher.acme.com’, utilizaremos um nome canônico (ou seja, alias) para esse servidor. Para tanto, criamos um registro de nomes canônicos (CNAME) para ‘gopher’ e o associamos ao ‘gopher-server1’.

 

Considerando que há vários servidores Web espelhados e servidores ftp fornecendo serviços para usuários externos, deve existir uma maneira de agrupá-los para que possa ocorrer a distribuição equilibrada da carga através dos servidores. Há várias maneiras para fazer isto com técnicas de ‘rodízio’. O método que será utilizado aqui é associar cada um dos servidores espelhados com o mesmo nome do alias. Utilizaremos os nomes populares dos serviços como o alias (ou seja, www, ftp etc.), o que facilitará a localização dos serviços pelos usuários. Para tanto, criamos um registro de nomes canônicos (CNAME) para cada um dos servidores espelhados com o nome do serviço como o alias e o nome do servidor como o host. Com esse arranjo, cada consulta a um determinado servidor DNS para um determinado nome de servidor utilizando seu alias (ou seja, www.acme.com), retornará uma lista de servidores em estilo de ‘rodízio’, sendo que em cada uma das vezes um servidor diferente será listado como o primeiro da lista. Como a maioria dos resolvedores tentam a primeira entrada retornada primeiro, como descrito anteriormente neste documento, isso proporcionará o equilíbrio do carregamento entre os servidores.

 

Depois que essa zona tiver sido configurada no servidor DNS primário, as zonas acme.com e 100.250.192.in-addr.arpa devem ser criadas nos servidores DNS secundários. Essas zonas secundárias devem voltar em direção ao servidor DNS primário como o mestre para as transferências de zona.

 

Encontra-se abaixo o arquivo de zona resultante dos servidores DNS externos:

 ;-----------------------------------------------------------------------------------;; Database file acme.dns for acme.com. zone. (External DNS Server); Zone version: 10; @ IN SOA dns-server1.acme.com. web-master.acme.com. ( 10 ; serial number 3600 ; refresh 600 ; retry 86400 ; expire 3600 ) ; minimum TTL ;; Zone NS records; @ IN NS dns-server1@ IN NS dns-server2@ IN NS dns13.my-isp.com. ;; Zone records; @ IN MX 10 mail-server1@ IN MX 10 mail-server2dns-server1 IN A 192.250.100.11dns-server2 IN A 192.250.100.12ftp-server1 IN A 192.250.100.41ftp-server2 IN A 192.250.100.42gopher-server1 IN A 192.250.100.31mail-server1 IN A 192.250.200.81mail-server2 IN A 192.250.200.82proxy-server1 IN A 192.250.100.101proxy-server2 IN A 192.250.100.102proxy-server3 IN A 192.250.100.103;www-server1 IN A 192.250.100.21www-server2 IN A 192.250.100.22www-server3 IN A 192.250.100.23www-server4 IN A 192.250.100.24;ftp IN CNAME ftp-server1ftp IN CNAME ftp-server2;gopher IN CNAME gopher-server1;www IN CNAME www-server1www IN CNAME www-server2www IN CNAME www-server3www IN CNAME www-server4;;-----------------------------------------------------------------------------------

 

Configuração de servidor DNS interno

Após a instalação do serviço DNS nas máquinas do Windows NT Server (ou seja, dns-internal1 e dns-internal2), utilizaremos a ferramenta Gerenciador DNS para criar uma zona primária para o domínio interno acme.com e uma zona primária de pesquisa inversa para 200.55.157.in-addr.arpa no dns-internal1. Isto criará um registro SOA que contém o servidor de nomes primário ‘dns-internal1.acme.com.’ e o endereço do sistema de mensagens para o administrador do servidor DNS ‘web-master@acme.com’, assim como um registro NS separado para dns-internal1. Como os parâmetros padrão restantes dessa zona são suficientes, não os modificaremos e os valores padrão serão colocados no registro SOA.

 

Depois de criar essas zonas, ativaremos a Procura WINS na zona acme.com e digitaremos os endereços IP dos dois servidores WINS internos. Isto criará um registro WINS (WINS) nesse arquivo de zona. Ativaremos também a Procura inversa WINS na zona 200.55.157.in-addr.arpa e digitaremos o Domínio de Host DNS como ‘acme.com.’. Dessa forma, criará um registro de procura inversa WINS (WINS-R) nesse arquivo de zona.

 

Os registros adicionais a seguir devem ser criados no domínio acme.com interno, e isso deve ser feito com o Criar registro PTR associado ativado, quando aplicável.

 

Um registro de servidor de nomes (NS) deve ser criado para dns-internal2. Os registros de endereços (A) devem ser criados para cada um dos computadores conectados diretamente à Rede corporativa isolada que não sejam clientes WINS. Pode ser que todos os servidores no âmbito da rede corporativa sejam capazes de reconhecer WINS e, portanto, nenhuma entrada estática será necessária; mas apenas para mostrar como é possível combinar entradas estáticas com WINS, definiremos estaticamente os servidores proxy e os servidores DNS no arquivo de zona do DNS. Criaremos também um registro de endereços ‘hostlocal’ para o endereço local 127.0.0.1.

 

Como há vários servidores de Web fornecendo serviços aos usuários internos, utilizaremos a técnica de ‘rodízio’ com nomes canônicos, como fizemos na rede externa, e associaremos esses servidores espelhados ao ‘corpweb.acme.com’. A diferença aqui é que não há registros de endereços associados (A) para os servidores de Web internos (ou seja, www-internal1, www-internal2, www-internal3), uma vez que eles são clientes WINS e o servidor DNS consultará o servidor WINS por esses endereços, quando necessário.

 

Depois que essas zonas tiverem sido configuradas no servidor DNS primário, as zonas acme.com e 200.55.157.in-addr.arpa devem ser criadas no servidor DNS secundário. Estas zonas secundárias devem voltar em direção ao servidor DNS primário como o principal para transferências de zona.

Encontra-se abaixo o arquivo de zona resultante para servidores DNS internos:

 

;-----------------------------------------------------------------------------------;; Database file acme.dns for acme.com. zone. (Internal DNS Server); Zone version: 12; @ IN SOA dns-internal1.acme.com. web-master.acme.com.( 12 ; serial number 3600 ; refresh 600 ; retry 86400 ; expire 3600 ) ; minimum TTL ;; Zone NS records; @ IN NS dns-internal1@ IN NS dns-internal2 ;; WINS lookup record; @ IN WINS 157.55.200.91 157.55.200.92 ;; Zone records; dns-server1 IN A 157.55.200.11dns-server2 IN A 157.55.200.12proxy-server1 IN A 192.250.100.101proxy-server2 IN A 192.250.100.102proxy-server3 IN A 192.250.100.103localhost IN A 127.0.0.1;corpweb IN CNAME www-internal1corpweb IN CNAME www-internal2corpweb IN CNAME www-internal3;;-----------------------------------------------------------------------------------

  

EstatísticasO DNS da Microsoft mantém um registro de várias estatísticas de consultas. Essas estatísticas podem ser visualizadas por meio do Gerenciador DNS. Elas são acumuladas desde a última vez que o serviço DNS foi iniciado. Elas são úteis ao comparar cargas relativas entre dois servidores DNS para determinar quantas solicitações cada um está atendendo. Se um servidor estiver mais ocupado que o outro, talvez seja conveniente considerar a alteração da arquitetura atual de DNS ou a reconfiguração de alguns dos resolvedores. A figura abaixo mostra as estatísticas do servidor \\B20TCP:

 

Planejamento de capacidade e desempenho

 Para os propósitos de Planejamento de capacidade, em um servidor DNS dedicado, é importante registrar as estatísticas e observar a expansão das consultas versus memória, disco, rede e desempenho da CPU do servidor. Como as estatísticas são mantidas desde o momento em que o serviço DNS foi reinicializado, você provavelmente desejará observar a data e a hora em que o serviço DNS foi iniciado (essa informação pode ser obtida no Eventlog).

 

Agora que você sabe quantas consultas por segundo o servidor DNS está atendendo, quantas são demais? A resposta depende de:

         Em qual hardware o servidor está sendo executado?

         A máquina é dedicada para DNS ou está sendo utilizada para outros propósitos?

         Qual é a largura de banda atual da rede?

Se você achar que seu servidor DNS não está respondendo tão rápido quanto deveria, você deverá primeiro examinar os seguintes contadores do Monitor de desempenho no servidor em questão. Se qualquer um desses limiares estiver sendo alcançado, então o sistema estará com problemas de desempenho e será necessário que você investigue um pouco mais:

Objeto Contador Limiar Observações

processador % de tempo do processador

> 80%  

memória bytes livres < 1MByte  

disco físico % de tempo de disco

> 67% disponível somente se você iniciar os contadores na linha de comando com diskperf -y e reinicializar

segmento de rede % de utilização da > 40% disponível somente se o

rede Agente monitor de rede estiver instalado

 

Se a memória for a questão, será necessário então verificar o objeto ‘processo’, a instância ‘DNS’ e o contador ‘Bytes reservados’. Se este contador estiver muito alto, então o serviço DNS é a causa do contador de bytes livres de memória estar baixo. Se esse for o caso, será então necessário adicionar mais memória ou possivelmente investigar quais registros estão atualmente ativos na cache de DNS e descobrir o TTL relacionado a cada um deles.

 

Se o processador for a questão, será necessário então verificar o objeto ‘processo’, a instância ‘DNS’, o contador ‘%tempo do processador’. Se for > 80 %, talvez seja conveniente considerar a execução do servidor DNS em um servidor mais potente. Se não for alta e a porcentagem do tempo do processador ainda for alta, verifique todos os outros processos e determine qual processo está exigindo muito tempo da CPU.

 

Em um servidor DNS, a porcentagem de tempo de disco, do disco físico, não deve ser um problema a menos que o sistema tenha começado a paginação por falta de memória. Se esse for o caso, será necessário tratá-lo como uma questão de memória.

 

Se a utilização da rede for um problema, será necessário descobrir se é o servidor que está causando todo o tráfego ou outro servidor no mesmo segmento. Para tanto, utilize o utilitário Monitor de rede com recursos totais que acompanha o SMS (que lhe permitirá capturar todo o tráfego destinado e originado de qualquer endereço específico de hardware) ou o utilitário com conjunto de recursos reduzido que acompanha o Microsoft Windows NT 4.0 (que lhe permitirá rastrear somente o tráfego destinado e originado do servidor local).

DNS de equilíbrio de cargaSe você tiver vários servidores DNS como, por exemplo, um primário e 2 secundários, será conveniente configurar alguns dos clientes para apontar para um DNS secundário e outros clientes para apontar para o outro DNS secundário.

A transferência de zonaA transferência de zona nada mais é do que uma cópia de arquivo. O conteúdo inteiro do banco de dados é copiado do primário (ou mestre) para o secundário sempre que o secundário for ‘notificado’ pelo primário (ou mestre) que houve uma alteração.

 

Quando um serviço DNS do secundário é iniciado ou o ‘intervalo de atualização’ do secundário em seu registro SOA tiver expirado (como padrão, o intervalo é definido para 3 horas), ele consultará seu primário para determinar o número de série do registro SOA. Se for diferente daquele que está em seu banco de dados local, ele solicitará uma transferência de zona.

 

O primeiro quadro é uma solicitação do registro SOA do Primário. 

secondary primary DNS 0x4000:Std Qry for scottsu.com of type SOA on class INET  + FRAME: Base frame properties+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol+ IP: ID = 0x7701; Proto = UDP; Len: 57+ UDP: Src Port: DNS, (53); Dst Port: DNS (53); Length = 37 (0x25) DNS: 0x4000:Std Qry for scottsu.com of type SOA on class INET addr. DNS: Query Identifier = 16384 (0x4000) + DNS: DNS Flags = Query, OpCode - Std Qry, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: scottsu.com of type SOA on class INET addr. DNS: Question Name: scottsu.com DNS: Question Type = Start of zone of authority DNS: Question Class = Internet address class 

 

O próximo quadro é o registro SOA que está sendo retornado. primary secondary DNS 0x4000:Std Qry Resp. for scottsu.com of type SOA on class INET  + FRAME: Base frame properties+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol+ IP: ID = 0x3617; Proto = UDP; Len: 149+ UDP: Src Port: DNS, (53); Dst Port: DNS (53); Length = 129 (0x81) DNS: 0x4000:Std Qry Resp. for scottsu.com of type SOA on class INET addr. DNS: Query Identifier = 16384 (0x4000) + DNS: DNS Flags = Response, OpCode - Std Qry, AA RA Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: scottsu.com of type SOA on class INET addr. DNS: Question Name: scottsu.com DNS: Question Type = Start of zone of authority DNS: Question Class = Internet address class DNS: Answer section: scottsu.com of type SOA on class INET addr. DNS: Resource Name: scottsu.com DNS: Resource Type = Start of zone of authority DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 80 (0x50) DNS: Primary Name Server: scottsu-7.scottsu.com DNS: Responsible Authorative Mailbox: Administrator.scottsu-7.scottsu.com DNS: Version number = 19 (0x13) DNS: Refresh Interval = 3600 (0xE10) DNS: Retry interval = 600 (0x258) DNS: Expiration Limit = 86400 (0x15180) DNS: Minimum TTL = 3600 (0xE10)

 

O próximo quadro é a solicitação da transferência de zona. secondary primary DNS 0x0:Std Qry for scottsu.com of type Req. for zn Xfer  + FRAME: Base frame properties+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol+ IP: ID = 0x7A01; Proto = TCP; Len: 71+ TCP: .AP..., len: 31, seq: 365696, ack: 35871892, win: 8760, src: 1072 dst: 53 DNS: 0x0:Std Qry for scottsu.com of type Req. for zn Xfer on class INET addr. DNS: TCP Length = 29 (0x1D) DNS: Query Identifier = 0 (0x0) + DNS: DNS Flags = Query, OpCode - Std Qry, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: scottsu.com of type Req. for zn Xfer on class INET addr. DNS: Question Name: scottsu.com DNS: Question Type = Request for zone transfer DNS: Question Class = Internet address class

 

O próximo quadro contém o banco de dados que está sendo retornado pelo mestre. primary secondary DNS 0x0:Std Qry Resp. for scottsu.com of type SOA  + FRAME: Base frame properties+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol+ IP: ID = 0x3817; Proto = TCP; Len: 163+ TCP: .AP..., len: 123, seq: 35871892, ack: 365727, win: 8729, src: 53 dst: 1072 DNS: 0x0:Std Qry Resp. for scottsu.com of type SOA on class INET addr. DNS: TCP Length = 121 (0x79) DNS: Query Identifier = 0 (0x0) + DNS: DNS Flags = Response, OpCode - Std Qry, RA Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: scottsu.com of type Req. for zn Xfer on class INET addr. DNS: Question Name: scottsu.com DNS: Question Type = Request for zone transfer DNS: Question Class = Internet address class DNS: Answer section: of type SOA on class INET addr. DNS: Resource Name: scottsu.com DNS: Resource Type = Start of zone of authority DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 80 (0x50) DNS: Primary Name Server: scottsu-7.scottsu.com DNS: Responsible Authorative Mailbox: Administrator.scottsu-7.scottsu.com DNS: Version number = 19 (0x13) DNS: Refresh Interval = 3600 (0xE10) DNS: Retry interval = 600 (0x258) DNS: Expiration Limit = 86400 (0x15180) DNS: Minimum TTL = 3600 (0xE10) 00000000 00 A0 24 63 AB 22 00 80 C7 A9 EC 0F 08 00 45 00 ..$c."........E.00000010 02 AB 39 17 40 00 80 06 B9 C6 9D 37 66 34 9D 37 ..9.@......7f4.700000020 64 CC 00 35 04 30 02 23 5D 0F 00 05 94 9F 50 18 d..5.0.#].....P.00000030 22 19 58 A8 00 00 00 3D 00 00 80 80 00 01 00 01 ".X....=........00000040 00 00 00 00 07 73 63 6F 74 74 73 75 03 63 6F 6D .....scottsu.com00000050 00 00 FC 00 01 C0 0C FF 01 00 01 00 00 0E 10 00 ................00000060 14 00 00 00 00 05 00 00 00 58 02 00 00 01 00 00 .........X......00000070 00 9D 37 66 34 00 40 00 00 80 80 00 01 00 01 00 ..7f4.@.........00000080 00 00 00 07 73 63 6F 74 74 73 75 03 63 6F 6D 00 ....scottsu.com.00000090 00 FC 00 01 C0 0C 00 02 00 01 00 00 0E 10 00 17 ................000000A0 09 73 63 6F 74 74 73 75 2D 37 07 73 63 6F 74 74 .scottsu-7.scott000000B0 73 75 03 63 6F 6D 00 00 43 00 00 80 80 00 01 00 su.com..C.......000000C0 01 00 00 00 00 07 73 63 6F 74 74 73 75 03 63 6F ......scottsu.co000000D0 6D 00 00 FC 00 01 C0 0C 00 02 00 01 00 00 0E 10 m...............000000E0 00 1A 0C 73 63 6F 74 74 73 75 5F 6E 74 34 30 07 ...scottsu_nt40.000000F0 73 63 6F 74 74 73 75 03 63 6F 6D 00 00 51 00 00 scottsu.com..Q..00000100 80 80 00 01 00 01 00 00 00 00 07 73 63 6F 74 74 ...........scott00000110 73 75 03 63 6F 6D 00 00 FC 00 01 07 67 6C 65 6E su.com......glen00000120 6E 77 6F C0 0C 00 02 00 01 00 00 0E 10 00 20 0A nwo.............00000130 63 6F 70 70 65 72 68 65 61 64 07 67 6C 65 6E 6E copperhead.glenn00000140 77 6F 07 73 63 6F 74 74 73 75 03 63 6F 6D 00 00 wo.scottsu.com..00000150 40 00 00 80 80 00 01 00 01 00 00 00 00 07 73 63 @.............sc00000160 6F 74 74 73 75 03 63 6F 6D 00 00 FC 00 01 0A 63 ottsu.com......c00000170 6F 70 70 65 72 68 65 61 64 07 67 6C 65 6E 6E 77 opperhead.glennw00000180 6F C0 0C 00 01 00 01 00 00 0E 10 00 04 9D 37 6A o.............7j00000190 C1 00 36 00 00 80 80 00 01 00 01 00 00 00 00 07 ..6.............000001A0 73 63 6F 74 74 73 75 03 63 6F 6D 00 00 FC 00 01 scottsu.com.....000001B0 08 67 6F 6F 6F 6F 6F 6F 64 C0 0C 00 01 00 01 00 .gooooood.......000001C0 00 00 00 00 04 9D 37 64 64 00 37 00 00 80 80 00 ......7dd.7.....000001D0 01 00 01 00 00 00 00 07 73 63 6F 74 74 73 75 03 ........scottsu.000001E0 63 6F 6D 00 00 FC 00 01 09 73 63 6F 74 74 73 75 com......scottsu000001F0 2D 37 C0 0C 00 01 00 01 00 00 0E 10 00 04 9D 37 -7.............700000200 66 34 00 3A 00 00 80 80 00 01 00 01 00 00 00 00 f4.:............00000210 07 73 63 6F 74 74 73 75 03 63 6F 6D 00 00 FC 00 .scottsu.com....

00000220 01 0C 73 63 6F 74 74 73 75 5F 6E 74 34 30 C0 0C ..scottsu_nt40..00000230 00 01 00 01 00 00 0E 10 00 04 9D 37 64 CC 00 79 ...........7d..y00000240 00 00 80 80 00 01 00 01 00 00 00 00 07 73 63 6F .............sco00000250 74 74 73 75 03 63 6F 6D 00 00 FC 00 01 C0 0C 00 ttsu.com........00000260 06 00 01 00 00 00 00 00 50 09 73 63 6F 74 74 73 ........P.scotts

00000270 75 2D 37 07 73 63 6F 74 74 73 75 03 63 6F 6D 00 u-7.scottsu.com.00000280 0D 41 64 6D 69 6E 69 73 74 72 61 74 6F 72 09 73 .Administrator.s00000290 63 6F 74 74 73 75 2D 37 07 73 63 6F 74 74 73 75 cottsu-7.scottsu000002A0 03 63 6F 6D 00 00 00 00 13 00 00 0E 10 00 00 02 .com............000002B0 58 00 01 51 80 00 00 0E 10 X..Q.....

 

Memória consumida por registros DNSOs registros RR do DNS são muito pequenos, tendo aproximadamente 16 bytes. Os registros de domínio também são muito pequenos, tendo cerca de 56 bytes. Se você carregar muitos registros no servidor, pode não perceber o aumento do contador do processo Bytes reservados do DNS, pois o servidor DNS aloca a memória em blocos.

 

A maneira como o DNS utiliza a cache é outra coisa. A memória virtual (paginável) é alocada para entradas armazenadas em cache, conforme necessário (lembre-se de que quando o servidor DNS faz uma resolução, ele armazena em cache uma cópia dos dados pelo TTL desses dados). Se o servidor estiver ávido de memória e precisar de mais, então essa memória virá do arquivo de paginação (que geralmente é muito lento).

 

 

 Ao criar uma arquitetura DNS, é importante fazer algumas perguntas sobre as infra-estruturas atual e futura. As questões abaixo o ajudarão a desenvolver uma boa rede de suporte DNS para sua empresa.

Quantos domínios eu preciso?Este é a pergunta mais importante que você terá que responder! Há dois caminhos a seguir ao criar uma arquitetura DNS para a rede de uma empresa. A primeira opção é a mais fácil — Criar um domínio DNS para a empresa toda (por exemplo Acme.com). Isto significa que você teria um servidor DNS primário e um ou mais servidores DNS secundários. Há alguns aspectos negativos ao escolher essa opção. O primeiro é que o DNS primário poderá encontrar problemas para acompanhar todos os controles dos secundários. Há soluções para esses problemas como aumentar o intervalo de atualização do secundário, fazer com que alguns dos secundários sejam carregados a partir de outros secundários (isto é, vários DNS principais) e/ou criar alguns servidores para cache (o que permite evitar o overhead de uma transferência de zona. — Advertência: eles são úteis somente depois que tiverem construído suas caches.). Se você optar por essa abordagem e decidir no futuro que ela deverá ser recriada, ela sempre poderá ser subdividida.

 

A segunda opção destina-se mais a instalações de rede de maior porte que abrangem múltiplos locais (esta é a opção que iremos explorar mais detalhadamente no restante desse documento). Nessa configuração, você teria mais que um domínio DNS. A arquitetura consistiria de um domínio raiz (com um servidor DNS primário e um ou mais servidores DNS secundários) e com um ou mais subdomínios (cada um com um servidor DNS primário e um ou mais servidores DNS secundários). Um exemplo dos subdomínios poderia ser

Decisões DNS

Dallas.Acme.Com e Reno.Acme.Com. O motivo para tal configuração é bastante óbvio. Uma arquitetura de rede geralmente subdivide um domínio DNS corporativo em vários domínios DNS para distribuir o gerenciamento de partes do domínio a várias entidades no âmbito da organização ou para ativar muitos arquivos de zona, uma vez que os arquivos de zona somente podem ser criados em nível de domínio. Um outro motivo menos óbvio pode ser simplesmente permitir a associação organizacional de seus sistemas. Se você optar por esse caminho, então a estrutura do seu domínio deverá espelhar a estrutura de sua organização, especialmente a estrutura de suporte de sua empresa. De qualquer forma, será necessário determinar a quantidade de domínios que sua empresa precisará.

Encontra-se abaixo um exemplo de uma configuração dessa natureza, mostrando os servidores DNS e os arquivos de banco de dados de zona em cada um deles:

 

 Do ponto de vista de uma futura migração, não é recomendável que você crie um domínio DNS para cada domínio do Windows NT que você possua atualmente em sua empresa.

 

Talvez não seja tão aparente hoje, mas para uma migração sem dificuldades para a próxima revisão importante do Windows NT isto será importante. A próxima revisão importante do Windows NT está estreitamente vinculada à backbone do DNS. Consulte a seção ‘O futuro’ neste documento, para obter mais informações.

A figura a seguir tenta mostrar como um nome poderia ser no futuro; lembre-se de que você ainda poderá utilizar nomes amigáveis como Scottsu@microsoft.com.

Para uma visão geral sobre como um domínio do Windows NT poderá mapear para um nome de domínio DNS, veja a figura abaixo. Ela possui um domínio Múltiplo mestre com 2 mestres, Reno e Dallas e 6 Recursos, L100 a L202.

Na configuração do domínio anterior você poderá ter 9 domínios DNS, Acme.com, Reno.Acme.com, Dallas.Acme.com, L100.Reno.com, L101.Reno.com, L102.Reno.com, L201.Dallas.com, L202.Dallas.com e L201.Dallas.com.

 

 

A maioria das configurações de domínio empresarial se enquadra em um dos seguintes modelos, o modelo

domínio Simples, o modelo domínio mestre, o modelo domínio Múltiplo mestre ou o modelo domínio Confiança Total. Para obter maiores informações sobre cada um destes modelos, consulte o guia de administração do Windows NT.

 

Nesta seção, discutiremos dois destes modelos, o modelo Confiança total e o modelo Múltiplo mestre. Vamos examinar os modelos anteriores ao DNS e os modelos posteriores ao DNS. Felizmente, isto possibilitará que você entenda como implementar o DNS dentro de seu próprio ambiente.

Exemplos de Confiança Total

Anterior ao DNS

Vamos começar com a seguinte configuração de domínio (sem DNS) e determinar a melhor abordagem para uma arquitetura estilo DNS. A seguir encontra-se um exemplo de um modelo de domínio Confiança total. Há 2 domínios ‘Reno’ e ‘Dallas’. Vamos supor o seguinte:

         Há uma central de dados em Dallas e Reno, com um vínculo de alta velocidade entre as duas centrais de dados

         Cada central de dados possui um grande número de locais remotos (500 cada, com 20 usuários) por ela suportados através de vínculos de 38KB diretamente conectados à central de dados adequada (em nosso diagrama, mostramos apenas 2).

         Cada central de dados possui o controlador de domínio primário (PDC, Primary Domain Controller) e servidor WINS que suportam os locais remotos.

         Cada local remoto possui 1 ou mais controladores de domínio de backup (BDC, Backup Domain Controller) Windows NT que obtêm seu banco de dados de gerenciamento de contas de segurança (SAM, Security Account Management) de seu respectivo PDC da central de dados. Isto significa que a duplicação da conta do usuário ocorrerá sobre o vínculo lento (38K), portanto há poucas contas de usuários no banco de dados e a expiração da senha está desativada. Um modelo de Confiança total foi utilizado nesta configuração porque há somente 1 servidor por local remoto e havia 20 usuários por local. Se existisse uma configuração de domínio múltiplo principal ou principal haveria necessidade de 2 servidores. Se um domínio fosse utilizado, então o banco de dados de contas de usuário seria muito grande. Um domínio em cada local não foi considerado porque a rede corporativa inteira desta empresa consiste de 1000 locais remotos.

         Os BDCs remotos contêm uma entrada #PRE (pre carrega entradas permanentes na cache NetBIOS—para visualizar o tipo de cache ‘nbtstat -c’) para todos os controladores de domínio primário em seu arquivo LMHOSTS (ex.: 128.247.145.200 DALLAS_PDC #PRE #DOM:DALLAS). Isto é importante porque cada BDC remoto precisa de uma configuração de sessão segura entre seu respectivo PDC e um PDC ou BDC em todos os domínios de confiança. Em virtude do vínculo lento a cada local remoto e do vínculo rápido entre as centrais de dados, faz mais sentido que a configuração de sessão segura seja feita entre os BDCs locais e o PDC e dos outros domínios de confiança.

         Cada local remoto possui várias estações de trabalho de clientes TCPIP (em nosso diagrama mostramos apenas 2) de Mnode (difunde primeiro e, em seguida, verifica o servidor WINS) na mesma

Exemplo de configurações

rede local que o(s) servidor(es) Windows NT de Hnode (verifica o servidor WINS para resolução de nome antes da difusão).

 

 

Ao criar uma solução, é importante considerar o fluxo de tráfego da ‘configuração da sessão’ e ‘validação de logon’. Você nunca desejaria criar uma solução que impedisse um cliente de contatar seu servidor local se o vínculo entre o local remoto e sua central de dados fosse perdido.

 

Em nosso exemplo, a validação de logon ocorrerá localmente entre os clientes e os servidores locais. A configuração da sessão e a resolução do nome para os servidores ‘locais’ também ocorrerão localmente, porque os clientes são configurados como clientes TCPIP Mnode. A configuração da sessão e a resolução do nome entre um cliente e um local e um servidor em outro local remoto tomará um caminho muito diferente e incluirá o servidor WINS na central de dados e o PDC do domínio do cliente. Em nosso exemplo (observe que em nosso exemplo alguns dos dispositivos foram removidos para maior facilidade de visualização do diagrama), a estação de trabalho NT na localização 200 do domínio Dallas está conectando ao servidor \\BDC100 na localização 100 do domínio Reno. O cliente primeiro contata o servidor WINS em sua central de dados para obter o endereço IP do servidor \\BDC100 (1 e 2). Em seguida, tenta estabelecer uma sessão com o servidor \\BDC100 (3). O servidor \\BDC100, por sua vez, utiliza sua sessão segura com o PCD do cliente para propósitos de ‘passar a autenticação’ (4 e 5). Se a segurança for verificada, o cliente terá permissão para estabelecer a sessão e continuar (6). Neste exemplo, existem 3 pontos físicos de falha, o vínculo entre a Localização 200 e a central de dados de Dallas, o vínculo entre a central de dados de Dallas e a central de dados de Reno, e o vínculo entre a Localização 100 e a central de dados de Reno.

Posterior ao DNS

Agora que você entende a arquitetura atual, como você criaria uma implementação DNS Windows NT 4.0?

 

Esta é uma solução possível. Há quatro zonas, 4 domínios (com, acme.com, reno.acme.com e dallas.acme.com) e um servidor DNS em cada localização remota no modelo abaixo.

 

Os itens seguintes são fatos sobre o modelo:

         O servidor DNS que contém os arquivos de zona reno.acme.com e dallas.acme.com estão localizados em suas respectivas centrais de dados e o servidor DNS que contém o arquivo de zona acme.com está localizado em uma ou na outra central de dados, dependendo da central de dados que possui o maior tráfego de configuração de sessão da localização remota do lado do cliente. Cada zona DNS deve ter um registro WINS que aponte para seu respectivo servidor WINS. Há também um servidor DNS somente de cache em cada uma das localizações remotas da mesma zona.

         Como havia um servidor localizado na localização remota, um servidor DNS também foi colocado lá. Como o vínculo é muito lento, faz mais sentido fazer com que esse servidor seja somente de cache. Se não existissem servidores na localização remota, então provavelmente um DNS não seria realmente necessário; no entanto, cada caso é diferente e a resolução rápida do nome para endereço IP é uma decisão comercial que envolve o custo da adição de outro servidor vs. o custo da resolução lenta do nome.

         Em nosso caso reno.acme.com e dallas.acme.com serão domínios no servidor raiz das centrais de dados. Um dos servidores raiz, provavelmente o servidor de Dallas, também alojará os domínios com e acme. Cada um dos servidores de cache das localizações remotas terão estes servidores listados em seus arquivos de cache.

         A procura WINS de DNS deve ser configurada nos servidores DNS em cada central de dados.

         É conveniente considerarmos um secundário para cada primário localizado na central de dados para propósitos de tolerância a falhas.

         Como não há servidores secundários nos locais remotos, não haverá qualquer motivo para adicioná-los à lista de notificação. No entanto, os servidores secundários nas centrais de dados devem estar na lista de notificação.

Com este modelo criado, um cliente de uma localização remota pode agora estabelecer uma sessão através do nome HOST ao invés do nome NetBIOS. Por exemplo, em vez de digitar

 

Net use * \\BDC100\public

ele poderá digitar

Net use * \\BDC100.reno.acme.com\public

 

Vamos seguir o caminho do tráfego se o cliente optar por conectar através do mecanismo de nome HOST.

O cliente contata seu servidor DNS local com uma consulta recursiva (1). O servidor DNS somente de cache dallas.acme.com verifica sua memória cache local; se o endereço IP para BDC100.reno.acme.com não estiver armazenado na cache, o servidor DNS dallas.acme.com verifica seu arquivo CACHE e envia uma consulta iterativa para seu servidor de domínio RAIZ (ou seja, Acme.com) (2). O servidor acme.com retornará uma resposta (3) dizendo ao dallas.acme.com para contatar reno.acme.com (4). Quando dallas.acme.com fizer contato com reno.acme.com, o servidor DNS reno.acme.com verificará o servidor WINS (5) definido em seu registro WINS (6) e reno.acme.com responderá com o endereço IP (7) e a consulta de nome direcionada e configuração da sessão podem continuar (8,9,10,11 e 12). Se os endereços IP não fossem armazenados em cache, seriam necessários 8 quadros para resolução do endereço IP para nome (em comparação com 2 quadros do modelo WINS).

 

Se o servidor DNS dallas.acme.com fosse configurado com um ‘Encaminhador’ a consulta ao acme.com ainda assim teria sido iterativa. No entanto, se o servidor DNS dallas.acme.com fosse configurado como um servidor ‘Escravo’ a solicitação ao

acme.com teria sido recursiva.

 

Uma vez que os Serviços avançados de pastas e DNS Dinâmico se tornarem uma realidade, os servidores WINS nesta empresa poderão ser removidos e NetBIOS poderá ser desativado. Deste ponto em diante o DNS será utilizado como índice para a pasta para localizar objetos máquina, como computadores e controladores de domínio.

Exemplo de múltiplo principalNa seção seguinte, vamos examinar um modelo de domínio Múltiplo Principal Windows NT 4.0, simples e ‘bem estruturado’, e mostrar como implementar o DNS dentro desse ambiente para uma migração segura para versões futuras do Windows NT.

Anterior ao DNS

Abaixo encontra-se o layout típico Múltiplo Principal com e domínios principais e 6 domínios de recurso:

Vamos utilizar a estrutura de domínio ‘Reno’ e ‘Dallas’ e supor o seguinte:          Existe uma central de dados em Dallas e Reno com um vínculo de alta velocidade entre as duas

centrais de dados (algo como um T1).

         Cada central de dados possui uma quantidade de locais remotos que são suportados através de vínculos de 512KB (em nosso diagrama mostramos apenas 2, um para a localização 100 e outro para a localização 200)

         Cada central de dados possui o controlador de domínio primário (PDC) para o domínio mestre das centrais de dados, um servidor WINS e um controlador de domínio de backup (BDC) para o outro domínio mestre.

         Cada local remoto possui 1 controlador de domínio de backup Windows NT (BDC) para cada domínio mestre (domínio de contas) e um PDC (e uma quantidade indeterminada de BDCs) para o domínio de recursos (sem contas de usuário definidas).

         Há um servidor WINS, que é um parceiro push-pull para o servidor WINS na respectiva central de dados, em cada localização remota. Os servidores WINS nas centrais de dados são também parceiros push-pull entre si.

         Todos os clientes e servidores são nós H devido ao servidor WINS local.

         Todas as estações de trabalho Windows NT nos domínios Recurso têm suas contas de máquina em seus respectivos domínios de recurso, porém os usuários efetuam o logon nos domínios principais.

         Um roteador separa todos os clientes dos servidores nas localizações remotas.

A figura abaixo mostra o layout atual:

Vejamos o fluxo de tráfego para validação de logon e resolução de nome para configuração da sessão. Na maioria dos cenários de domínio mestre Múltiplo, as contas de máquinas cliente Windows NT estão presentes no domínio de recurso e o usuário efetua o logon no domínio mestre. Toda a validação de logon será realizada localmente dentro do local. Um cliente Windows NT Workstation na inicialização consulta o servidor WINS por uma lista de BDCs (através de consulta de nome para DOMAIN <1C>). O servidor WINS responderá com uma lista de até 25 BDCs (a lista contém o PDC e todos os BDCs do domínio mestre nele registrados, assim como outros que foram nele duplicados). O cliente envia então uma solicitação para cada servidor contido na lista e utiliza o primeiro servidor para responder (que normalmente será o BDC local do domínio mestre) como seu servidor com o qual configura um canal seguro e utiliza para validação de logon.

A configuração de sessão remota de um cliente Windows NT de um domínio de recurso a um servidor em outro domínio de recurso ocorre como mostra o diagrama a seguir.

 

 

A estação de trabalho NT consultará o servidor WINS sobre o endereço do servidor no domínio que deseja contatar (1). O servidor WINS responderá com o endereço (2) porque ele foi duplicado para o mesmo anteriormente. A estação de trabalho Windows NT irá então contatar o servidor diretamente (3). Esse servidor verá que a solicitação de configuração da sessão é proveniente de um usuário em um domínio mestre de confiança e utilizará seu canal seguro para um BDC ou PDC do domínio de confiança para verificar as credenciais (5) e, em seguida, o servidor permitirá que o cliente faça a conexão ou rejeitará a solicitação (6).

Posterior ao DNS

Agora que você entende a arquitetura atual, como você criaria uma implementação Windows NT 4.0 DNS? A primeira coisa que devemos determinar é como estruturar os domínios DNS. Sabemos que para propósitos de migração futura os domínios DNS devem ser iguais aos domínios Windows NT 4.0. A primeira e mais importante questão é agora respondida — que é, ‘Quantos domínios eu preciso?’. A resposta é, um para cada domínio do Windows NT --dez.

 

A segunda questão é, ‘como os nomes de domínio devem ser mapeados?’. Por exemplo, devemos ter L100.reno.acme.com ou L100.acme.com? Em qualquer modelo, é importante mantê-lo simples! Isto significa, em nosso caso, manter o nome o mais curto possível. Há uma outra parte desta segunda pergunta, que é, ‘de qual domínio DNS os clientes e servidores devem fazer parte?’. No cenário Múltiplo Principal, a solução lógica é colocar todas as estações de trabalho dentro de um domínio DNS denominado L100.Acme.Com e L200.Acme.Com etc. e, em seguida, colocar todos os servidores dentro de um domínio denominado Reno.Acme.Com e Dallas.Acme.Com (Isto poderá exigir modificações na configuração TCPIP de cada cliente). Isto permitirá fácil migração para Serviços avançados de pastas e DNS Dinâmico.

 

A terceira questão é, ‘quantos servidores precisaremos para suportar esta configuração?’. Haverá 10 domínios DNS (os 8 estimados + acme.com e com) e 8 servidores DNS, da mesma forma como existem 8 domínios e controladores de domínio do Windows NT (PDCs e BDCs). Isto exigirá que o serviço DNS Server seja executado em cada uma das localizações. O serviço pode ser executado no PDC ou BDC existente no âmbito da localização remota, supondo-se que exista capacidade adequada. Os servidores DNS nas localizações que alojam domínios de recurso serão os primários para seus nomes de domínio de recurso Windows NT, como L100. Acme.Com e secundários para seus respectivos domínios Principais Windows NT, como Reno.Acme.Com.

 

Após toda esta explicação, a hierarquia de domínio DNS poderá ser semelhante à seguinte:

 

 

  

Com este modelo estabelecido, um cliente de uma localização remota pode agora estabelecer uma sessão através do nome HOST ao invés do nome NetBIOS. Por exemplo, em vez de digitar

Net use * \\WKS100\public

ele pode digitar

Net use * \\WKS100.L100.acme.com\public

Se o cliente optar por conectar através do mecanismo de nome HOST, vamos acompanhar o caminho do tráfego e compará-lo com o caminho através de WINS (observe que em nosso exemplo alguns dos dispositivos foram removidos para maior facilidade de visualização do diagrama).

 

 

O cliente contata seu servidor DNS local com uma consulta recursiva (1) para o domínio ‘NT workstation.domain’. O servidor DNS local verifica sua memória cache local e, se o endereço IP para WKS100.L100.acme.com não estiver armazenado na cache, o servidor DNS verifica seu arquivo CACHE e envia uma consulta iterativa para seu servidor de domínio RAIZ (ou seja, acme.com) (2). O servidor acme.com responderá (3) dizendo ao servidor DNS local para contatar L100.acme.com (4). L100.acme.com verificará o servidor WINS (5 e 6) (o servidor DNS faz a si mesmo a pergunta, ‘Eu deveria ter o endereço IP do host WKS100.L100.acme.com porque sou de autorização para o domínio L100.acme.com, mas não tenho, então verifique o WINS’) definida no registro WINS e responde com o endereço IP (8) e a consulta de nome direcionada e configuração da sessão podem continuar (9,10,11,12). Se os endereços IP não fossem armazenados em cache, seriam necessários 8 quadros para a resolução do nome para endereço IP (em comparação com 2 quadros no modelo WINS).

 

As duas zonas no servidor DNS dentro da localização remota devem apontar para o mesmo servidor WINS local.

 

O servidor DNS local de autorização para reno.acme.com não contatou seu servidor WINS local porque o nome DNS que estava sendo solicitado não era um filho direto de seu domínio DNS reno.acme.com. Era um filho direto somente de um servidor DNS de autorização para L100.acme.com.

 

Um cliente de uma localização remota também pode estabelecer uma sessão com um servidor remoto através do nome HOST ao invés do nome NetBIOS. Por exemplo, em vez de digitar

Net use * \\PDC100\public

ele pode digitar

Net use * \\PDC100.reno.acme.com\public

Se o cliente optar por conectar através do mecanismo de nome HOST, vamos seguir o caminho do tráfego e compará-lo com o caminha através de WINS (observe que em nosso exemplo alguns dispositivos foram removidos para facilidade de visualização do diagrama).

 

O cliente contata seu servidor DNS local com uma consulta recursiva (1) para o domínio ‘NT workstation.domain’. O servidor DNs local verifica sua memória cache local e, se o endereço IP para PDC100.reno.acme.com não estiver armazenado na cache, o servidor DNS local verifica seu arquivo CACHE e envia uma consulta iterativa ao servidor RAIZ de seu domínio (ou seja, acme.com) (2). O servidor acme.com responderá (3) e dirá ao servidor DNS local para contatar reno.acme.com (4). Quando o servidor DNS local entra em contato com reno.acme.com, o DNS reno.acme.com verificará o servidor WINS (5 e 6) (o servidor DNS faz a si mesmo a pergunta, ‘Eu deveria ter o endereço IP do host PDC100.reno.acme.com porque sou de autorização para o domínio Reno.acme.com, mas não tenho, então verifique o WINS’) definida em seu registro WINS e responde com o endereço IP (7). O DNS local retorna então esse endereço ao cliente (8) e a consulta de nome direcionada e configuração da sessão pode continuar (9,10,11,12). Se os endereços IP não fossem armazenados em cache, seriam necessários 8 quadros para resolução de nome para endereço IP (em comparação com 2 quadros no modelo WINS).

 O servidor DNS local não contatou seu servidor WINS local porque o nome DNS que estava sendo solicitado não era um filho direto de um domínio DNS L200.acme.com ou dallas.acme.com ele era apenas um filho direto de um servidor DNS de autorização para reno.acme.com.

 Uma vez que os Serviços avançados de pastas e DNS Dinâmico se tornarem uma realidade, os servidores WINS nesta empresa poderão ser removidos e NetBIOS poderá ser desativado. Deste ponto em diante, o DNS será utilizado como um índice para a pasta a fim de localizar objetos máquina, como computadores e controladores de domínio.

 

Pode parecer que haja mais pontos de falha para resolução do nome (8 quadros através de DNS versus 2 quadros através de WINS), porém com esta arquitetura haverá menos duplicação de DNS Dinâmico do que a duplicação WINS que existe atualmente e o espaço plano de 16 caracteres de nome NetBIOS não significará mais nada!

O futuro

DNS Dinâmico, IPv6, Transferência Incremental, DNS Seguro, uso Limitado de (ou nenhum uso, a seu critério) de NetBIOS...  

A próxima geração do Windows NT conterá uma implementação Serviços avançados de pasta. Haverá uma nova maneira de pensar sobre domínios, usuários, grupos e confianças. Os domínios DS avançados mapearão diretamente aos domínios DNS e a administração de usuários e grupos poderá ser delegada a Unidades Organizacionais (OU) na pasta. Os novos domínios DS avançados serão muito mais funcionais do que os domínios atuais do Windows NT Server.

O ponto chave a ser entendido da perspectiva de implementação do DNS, é que o DNS será o serviço locador primário na rede de Serviços avançados de pasta. Os clientes DS Avançados utilização DNS, semelhante à maneira em que os clientes Windows NT 4.0 atualmente utilizam WINS, para localizar outros servidores que estejam executando o serviço DS e outros host na rede.

 Esta sessão examina alguns dos conceitos de Serviços de pasta avançados, assim como alguns novos padrões que influenciarão o DNS no futuro. Em seguida, veremos como um bom modelo DNS / DS será no futuro e forneceremos uma indicação sobre como você poderá criar sua rede hoje a fim de preparar-se para essa futura migração.

 

DNS dinâmicoO Windows NT 4.0 inclui dois serviços de mapeamento de nome para endereço IP - WINS e DNS. Uma diferença chave entre os dois é que, enquanto o WINS acomoda registro dinâmico de nomes NetBIOS (e endereços IP associados), os nomes DNS (e endereços IP associados) devem ser estaticamente digitados no banco de dados de serviço DNS.

 

O registro estático de informações de nome para endereço IP não é desejável no ambiente Windows NT / Win95. Isto deve-se ao fato de que em todas as instalações de redes Microsoft muito pequenas, os computadores não têm atribuições de endereço IP estático. Os computadores utilizam o Protocolo de configuração dinâmica de host (DHCP, Dynamic Host Configuration Protocol) para obter uma atribuição de endereço IP em todas as inicializações.

 

Uma proposta para registro dinâmico de informações DNS está sendo considerada pela equipe de engenharia da Internet (IETF, Internet Engineering Task Force). Você pode agora transferir a especificação a partir de “http://ds.internic.net/internet-drafts/draft-ietf-dnsind-dynDNS-09.txt”. Com a ‘atualização dinâmica’ do

IntroduçãoPadrões em desenvolvimento

DNS, um computador cliente que tiver obtido seu endereço IP atribuído a partir de um DHCP, poderá utilizar o protocolo padrão para registrar dinamicamente o nome do DNS e o endereço IP no banco de dados de DNS. Na época de estruturação do Windows NT 4.0, foi determinado que a ‘atualização dinâmica’ não seria implementada devido ao conceito ainda instável da especificação e por questões de escalabilidade. A proposta atual de DNS dinâmico baseia-se num modelo de duplicação ‘retirar do mestre simples’ e, conseqüentemente, se o mestre estiver inativo ou não puder ser conectado, as atualizações dinâmicas não ocorrerão. A Microsoft favorece um arranjo com mestre múltiplo, semelhante ao WINS, que permite que os registros continuem sem falha.

 

A longo prazo, o uso de atualizações dinâmicas de DNS é mais desejável do que a integração Windows NT 4.0 DNS-WINS, pelos seguintes motivos:

         A integração DNS-WINS não possibilita ‘procura inversa’ eficiente de DNS (resolução de endereço IP para nome DNS). A procura inversa é utilizada por segurança pelos serviços WWW (World Wide Web) Internet e Firewall. Devido à recente proliferação destes serviços, a necessidade de procura inversa DNS eficiente está aumentando significativamente. Se a atualização dinâmica de DNS fosse utilizada em vez da integração WINS, este problema deixaria de existir.

         A integração DNS-WINS não possibilita um relacionamento ‘primário-backup’ adequado entre servidores de nome DNS não MS. Isto deve-se ao fato dos servidores de nomes DNS não-MS não serem capazes de pesquisa WINS. Para propósitos de migração, os clientes desejam instalar servidores DNS MS como backups de servidores primários DNS não MS. Se a atualização dinâmica DNS fosse utilizada em vez da integração WINS, este problema deixaria de existir.

         Os hosts não-MS não registram no WINS e, portanto, não podem ser ‘dinamicamente registrados’ no DNS. A atualização dinâmica do DNS é um padrão da IETF. Se implementado (pela MS), os hosts não-MS [que suportem o padrão de atualização dinâmica de DNS] poderiam ser registrados dinamicamente no DNS MS e os hosts MS poderiam ser registrados dinamicamente em um DNS não-MS [que suporte o padrão de atualização dinâmica de DNS].

         O registro no WINS não é seguro e não possui qualquer meio racional para que se torne se-guro. A IETF está trabalhando na realização de um padrão para dar mais segurança à atualização dinâmica de DNS. O padrão de segurança de DNS não está programado para entrar na programação de padrões da IETF até o quarto trimestre de 1996. Algumas empresas já decidiram adiantar-se quanto a um padrão e ‘desenvolveram sua própria’ implementação de segurança.

Os clientes Microsoft não podem se registrar com qualquer das versões atuais de DNS dinâ-mico e os servidores DNS dinâmicos não podem duplicar seus dados dinâmicos para outros servidores DNS NÃO dinâmicos.

Nas implementações atuais de DNS Dinâmico, o primário é um único ponto de falha. Todos os clientes devem registrar seus nomes e endereços IP junto a esta máquina. Se esta máquina estiver inativa, então nenhuma atualização do banco de dados de DNS poderá ocorrer.

IPv6 (IPng)IPv6 está definido na RFC 1883 (http://ds2.internic.net/rfc/rfc1883.txt). Algumas vezes este protocolo é designado como ‘IP ou IPng de Nova geração’. IP versão 6 (IPv6) é uma nova versão do Protocolo Internet designado como sucessor do IP versão 4 (IPv4) [RFC-791]. As alterações do IPv4 para IPv6 enquadram-se nas seguintes categorias:

         Recursos de endereçamento expandido

         Simplificação do formato do cabeçalho

         Melhoria do suporte para extensões e opções

         Recurso de rotulagem de fluxo

         Recursos de autenticação e privacidade

Com o início deste novo padrão, será necessário fazer alterações no protocolo DNS. A RFC 1886 (http://ds2.internic.net/rfc/rfc1886.txt) define estas alterações. As alterações incluem um novo tipo de registro de recurso para armazenar um endereço IPv6, um novo domínio para suportar procuras com base em um endereço IPv6 e definições atualizadas dos tipos de consultas existentes que retornam endereços Internet como parte do processamento de seção adicional. As extensões foram projetadas para compatibilidade com os aplicativos existentes, principalmente, as próprias implementações DNS.

 O suporte atual para armazenamento de endereços Internet no sistema de nomes de domínio (DNS) não pode ser facilmente estendido para suportar endereços IPv6, uma vez que os aplicativos assumem que as consultas de endereço retornam endereços Ipv4 de 32 bits.

Transferências incrementais – Duplicação múltipla mestreA transferência incremental destina-se à rápida propagação de alterações a um banco de dados de DNS. O Windows NT 4.0 não suporta o Protocolo de transferência incremental, porém este protocolo será suportado no futuro. O Protocolo de transferência incremental foi projetado para reduzir a latência e diminuir a quantidade de dados enviada durante uma transferência de zona. Isto é feito através de dois mecanismos.

A Notificação é utilizada para notificar ativamente os servidores sobre uma alteração em um arquivo de zona. A notificação é obtida pela extensão NOTIFY do DNS (O MS DNS suporta Notify no Windows NT 4.0). Para obter mais informações sobre a especificação de notificação, consulte o esquema na Internet em http://ds.internic.net/internet-drafts/draft-ietf-dnsind-notify-07.txt.

 

A propagação de zona é melhorada ao enviar apenas as informações que foram alteradas. Este é um método muito melhor do que o mecanismo de transferência de zona atual, pois o método atual sempre transfere o arquivo de zona inteiro. Para obter mais informações sobre o Protocolo de transferência incremental, consulte o esquema na Internet em http://ds.internic.net/internet-drafts/draft-ietf-dnsind-ixfr-06.txt.

 

A duplicação dos dados dinâmicos funcionará de modo bastante semelhante à maneira como o WINS funciona atualmente, porém os dados permanecem dentro da zona em vez de duplicar dados desnecessários para cada um dos servidores (como WINS). A figura abaixo mostra o registro de resolução e como a duplicação irá funcionar:

O banco de dados dinâmico de L200.acme.com é duplicado somente entre o servidor DNS 2 e o servidor DNS 3. O banco de dados dinâmico de Dallas.acme.com é duplicado somente entre o servidor DNS 1 e o servidor DNS 2.

DNS seguroÀ medida em que o DNS se torna uma parte operacional essencial da infra-estrutura Internet, precisará existir um método definido de segurança para garantir a integridade e autenticação dos dados. As extensões do DNS estão descritas no documento da IETF, “Extensões do protocolo de segurança DNS - 30 de janeiro de 1996”, que fornece esses serviços para resolvedores ou aplicativos preocupados com a segurança, através do uso de assinaturas digitais criptografadas. Estas assinaturas digitais estão em zonas protegidas como registros de recurso. A segurança ainda pode ser fornecida mesmo através de servidores DNS não voltados para a segurança em muitos casos.

As extensões possibilitam também o armazenamento de chaves públicas autenticadas no DNS. Este armazenamento de chaves é capaz de suportar serviço geral de distribuição de chave pública, assim como segurança de DNS. As chaves armazenadas possibilitam que os resolvedores cientes de segurança conheçam a chave de autenticação das zonas, além daquelas para as quais foram inicialmente configurados. As chaves associadas aos nomes DNS podem ser recuperadas para suporte de outros protocolos. Provisionamentos são feitos para vários tipos de chaves e algoritmos. Além disso, as extensões de segurança possibilitam a autenticação opcional de transações de protocolo DNS. Para obter mais informações, consulte “http://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-09.txt”.

Nas implementações atuais de DNS Dinâmico, os fornecedores tinham que ‘avançar seus próprios’ protocolos de segurança devido à falta de um padrão definido. Tenha cuidado ao implementar um desses produtos, pois poderá se tornar incompatível com os futuros produtos, quando uma especificação for definida.

 

Por onde começar?Vamos dar uma olhada no processo de migração para Serviços de pasta avançados. Os novos domínios DS

Avançados serão totalmente interfuncionais com os domínios do Windows NT Server. (ou seja, os domínios Windows NT Server existentes serão capazes de confiar nos domínios DS Avançados, assim como confiam hoje em outros domínios do Windows NT Server.) Os servidores DS avançados também serão capazes de funcionar como controladores de domínio backup para domínios do Windows NT Server. Esta interfuncionalidade permitirá que a migração para Servidor DS Avançado ocorra de maneira ordenada, permitindo ao mesmo tempo que os Windows NT Servers existentes funcionem sem modificação.

 

Os administradores não serão obrigados a utilizar o modelo de administração DS Avançado até que estejam preparados para tanto. Mesmo quando os servidores DS estiverem na rede, por exemplo, os administradores serão capazes de manter todas as informações sobre contas no domínio do Windows NT Server, utilizando as Ferramentas administrativas atuais do Windows NT Server. Desta forma, os administradores serão capazes de desenvolver servidores DS Avançados sem interromper a administração da rede.

 

Com o desenvolvimento dos servidores DS Avançados, os administradores poderão começar a armazenar as informações sobre contas de usuários nos servidores DS Avançados, continuando ao mesmo tempo a armazenar e administrar estas contas a partir do domínio do Windows NT Server. Isto permitirá às organizações migrar informações sobre contas para um servidor DS Avançado de maneira incremental, à medida em que obtêm maior confiança na estabilidade e capacidade do DS Avançado. Assim que os servidores DS Avançados estiverem bem estabelecidos, os administradores serão capazes de manter todas as informações sobre contas nos servidores DS Avançados, utilizando as ferramentas do DS Avançado. Além disso, para clientes não-DS Avançado, no entanto, os servidores DS Avançados continuarão sendo semelhantes e atuando como os servidores Windows NT Server 4.x.

 

Uma vez completadas todas as transições cliente e servidor, o ambiente DS Avançado será o ambiente rotineiro diário dos usuários e administradores de sistema. E, a transição que foi possível pela interfuncionalidade entre a integração do Windows NT Server e DS Avançado permitirá que as organizações façam uma transição fácil para o espaço de nome global unificado fornecido pelo DS Avançado, sem interromper as operações da rotina do dia-a-dia da rede.

Como o DNS tem por base o TCPIP e a próxima geração do Windows NT depende do DNS como seu suporte principal, o que acontecerá com IPX e NetBEUI?

Continuará existindo suporte para NetBEUI e IPX, porém é importante entender que a Microsoft declaradamente está concentrada em TCP/IP, como ocorre também com a maioria dos demais fornecedores de sistemas de rede.

 

Se você optar por utilizar IPX e NetBEUI na próxima revisão do Windows NT, será necessário que você utilize NetBIOS. No entanto, se você optar por TCPIP como sua opção de protocolo, NetBIOS não será necessário como parte da arquitetura.

Migração

E os aplicativos antigos que dependem de nomes NetBIOS como SMS.

Será necessário que você utilize resolução de nome NetBIOS em sua rede, desde que você tenha aplicativos

que exijam nomes NetBIOS. Quando você optar por começar a migração para DS Avançado, será necessário descobrir todos os aplicativos (serviços etc.) que exijam NetBIOS e tenham um plano de migração do nome do host para cada um deles.

Localizando CDs em um ambiente de Serviços de pasta avançados

No caminho de um verdadeiro ambiente de Serviços de pastas avançados Windows NT (sem NetBIOS) haverá a exigência de um caminho de migração que inclua o uso de todos os três padrões para suporte à compatibilidade de retorno com os sistemas NetBIOS antigos.

 

Com a inicialização dos computadores de Serviços de pastas avançados Windows NT, elas não utilizarão o protocolo WINS existente para o registro de nomes NetBIOS no servidor configurado para WINS, e registrarão seus registros ‘A’ no servidor DNS. Assim sendo, os mapeamentos de nome DNS para endereço IP e NetBIOS Windows NT serão disponibilizados para todas as máquinas DS Avançado Windows NT e máquinas em nível descendente (Windows 95, Windows for Workgroups etc.).

 

Com a inicialização dos Servidores SP avançados do Windows NT, que contenham banco de dados de serviços de pasta, eles não somente registrarão um nome NetBIOS no servidor WINS, e um registro ‘A’ no servidor DNS, como também registrarão outro registro no servidor DNS, que define a localização, o protocolo de acesso ao SP suportado, os protocolos de transporte etc. Podem existir múltiplos registros ‘A’ registrados para uma máquina. Por exemplo, um CD de Serviços avançados de pasta poderá registrar:

 phoenix.nt.microsoft.com A 123.123.123.123 domain-controllers.nt.microsoft.com A 123.123.123.123

 Isto permitirá que as estações de trabalho de Serviços de pasta avançados localizem os CDs para validar suas credenciais de segurança.

Com o que você pode contar para o futuro

         A Microsoft adotará uma solução DNS dinâmica ‘segura’ e nossos clientes serão automaticamente registrados no DNS. Haverá também um processo para uso do DNS para localizar o DC de Serviços de pasta mais próximo.

         A próxima revisão de Serviços de pasta assumirá que os domínios DNS mapeiam para domínios DS.

Regras para projetar uma boa solução DNS para o futuro

         Se existirem servidores dentro de um Local, então será necessário que exista um servidor DNS dentro desse local.

         Criar um domínio DNS para cada domínio WINDOWS NT 4.0.

          O servidor DNS de cada local deve ser um servidor primário para o domínio DNS específico do local e um servidor secundário para o domínio DNS pai.

Conclusão

          Os clientes Windows devem ser registrados em um domínio DNS de local específico.

          Os Windows NT Servers devem ser registrados no domínio DNS principal.

 

Apêndices

 

Apêndice A: A ligação 

Rastreando consultas DNS

Perguntando ao DNS por um endereço IP de um HOST

O exemplo consiste da seguinte configuração com 4 hosts, 2 dos quais são servidores DNS primários.

 

 

O cliente Windows NT 40. Emite o seguinte PING. As setas representam um pacote e os números associados ao número do quadro com o rastreamento abaixo.

O rastreamento é da seguinte consulta: 

Ping rattlesnake.glennwo.scottsu.com 

ou seja, o Host é rattlesnake e o domínio é glennwo.scottsu.com    

O cliente primeiro precisa consultar seu servidor DNS quanto aos nomes.  Observe que a consulta é recursiva. 1 SCOTTSU-7 SCOTTSU_NT40 DNS 0x1:Std Qry for rattlesnake.glennwo.scottsu.com  IP: ID = 0x9608; Proto = UDP; Len: 77 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0)IP: Total Length = 77 (0x4D) IP: Identification = 38408 (0x9608) IP: Flags Summary = 0 (0x0)IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 128 (0x80) IP: Protocol = UDP - User Datagram IP: CheckSum = 0x9F28 IP: Source Address = 157.55.102.52 IP: Destination Address = 157.55.100.204 IP: Data: Number of data bytes remaining = 57 (0x0039) UDP: Src Port: Unknown, (1066); Dst Port: DNS (53); Length = 57 (0x39) UDP: Source Port = 0x042A UDP: Destination Port = DNS UDP: Total length = 57 (0x39) bytes UDP: CheckSum = 0xB2D7 UDP: Data: Number of data bytes remaining = 49 (0x0031) DNS: 0x1:Std Qry for rattlesnake.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Query Identifier = 1 (0x1) DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: 0............... = Query DNS: .0000........... = Standard Query DNS: .....0.......... = Server not authority for domain DNS: ......0......... = Message complete DNS: .......1........ = Recursive query desired DNS: ........0....... = Recursive queries supported by server DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: rattlesnake.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Question Name: rattlesnake.glennwo.scottsu.com DNS: Question Type = Host Address DNS: Question Class = Internet address class 

O scottsu_40NT.scottsu.com não é de autorização para o domínio glennwo.scottsu.com, portanto o host scottsu_40NT.scottsu.com host envia a solicitação para o servidor DNS de subdomínio copperhead.glennwo.scottsu.com. Observe que a consulta é iterativa. 2 SCOTTSU_NT40 COPPERHEAD DNS 0x5:Std Qry for rattlesnake.glennwo.scottsu.com  IP: ID = 0x9C1C; Proto = UDP; Len: 77 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0)IP: Total Length = 77 (0x4D) IP: Identification = 39964 (0x9C1C) IP: Flags Summary = 0 (0x0)IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 128 (0x80) IP: Protocol = UDP - User Datagram IP: CheckSum = 0x9487 IP: Source Address = 157.55.100.204 IP: Destination Address = 157.55.106.193 IP: Data: Number of data bytes remaining = 57 (0x0039) UDP: Src Port: DNS, (53); Dst Port: DNS (53); Length = 57 (0x39) UDP: Source Port = DNS UDP: Destination Port = DNS UDP: Total length = 57 (0x39) bytes UDP: CheckSum = 0xB33B UDP: Data: Number of data bytes remaining = 49 (0x0031) DNS: 0x5:Std Qry for rattlesnake.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Query Identifier = 5 (0x5) DNS: DNS Flags = Query, OpCode - Std Qry, RCode - No error DNS: 0............... = Query DNS: .0000........... = Standard Query DNS: .....0.......... = Server not authority for domain DNS: ......0......... = Message complete DNS: .......0........ = Iterative query desired DNS: ........0....... = Recursive queries supported by server

DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: rattlesnake.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Question Name: rattlesnake.glennwo.scottsu.com DNS: Question Type = Host Address DNS: Question Class = Internet address class 

O host Copperhead.glennwo.scottsu.com responde ao servidor DNS Scottsu_40NT DNS enviando os dados. 3 COPPERHEAD SCOTTSU_NT40 DNS 0x5:Std Qry Resp. for rattlesnake.glennwo.scottsu.com  IP: ID = 0x5F04; Proto = UDP; Len: 93 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0)IP: Total Length = 93 (0x5D) IP: Identification = 24324 (0x5F04) IP: Flags Summary = 0 (0x0)IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 128 (0x80) IP: Protocol = UDP - User Datagram IP: CheckSum = 0xD18F IP: Source Address = 157.55.106.193 IP: Destination Address = 157.55.100.204 IP: Data: Number of data bytes remaining = 73 (0x0049) UDP: Src Port: DNS, (53); Dst Port: DNS (53); Length = 73 (0x49) UDP: Source Port = DNS UDP: Destination Port = DNS UDP: Total length = 73 (0x49) bytes UDP: CheckSum = 0x8BD1 UDP: Data: Number of data bytes remaining = 65 (0x0041) DNS: 0x5:Std Qry Resp. for rattlesnake.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Query Identifier = 5 (0x5) DNS: DNS Flags = Response, OpCode - Std Qry, AA RA Bits Set, RCode - No error DNS: 1............... = Response DNS: .0000........... = Standard Query DNS: .....1.......... = Server authority for domain DNS: ......0......... = Message complete DNS: .......0........ = Iterative query desired DNS: ........1....... = No recursive queries DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: rattlesnake.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Question Name: rattlesnake.glennwo.scottsu.com DNS: Question Type = Host Address DNS: Question Class = Internet address class DNS: Answer section: rattlesnake.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Resource Name: rattlesnake.glennwo.scottsu.com DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 157.55.107.88 

Os dados são retornados ao cliente. 4 SCOTTSU_NT40 SCOTTSU-7 DNS 0x1:Std Qry Resp. for rattlesnake.glennwo.scottsu.com  IP: ID = 0x9D1C; Proto = UDP; Len: 93 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0)IP: Total Length = 93 (0x5D) IP: Identification = 40220 (0x9D1C) IP: Flags Summary = 0 (0x0)IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 128 (0x80) IP: Protocol = UDP - User Datagram IP: CheckSum = 0x9804 IP: Source Address = 157.55.100.204 IP: Destination Address = 157.55.102.52 IP: Data: Number of data bytes remaining = 73 (0x0049) UDP: Src Port: DNS, (53); Dst Port: Unknown (1066); Length = 73 (0x49) UDP: Source Port = DNS UDP: Destination Port = 0x042A UDP: Total length = 73 (0x49) bytes UDP: CheckSum = 0x8F6D UDP: Data: Number of data bytes remaining = 65 (0x0041) DNS: 0x1:Std Qry Resp. for rattlesnake.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Query Identifier = 1 (0x1) DNS: DNS Flags = Response, OpCode - Std Qry, RD RA Bits Set, RCode - No error DNS: 1............... = Response DNS: .0000........... = Standard Query

DNS: .....0.......... = Server not authority for domain DNS: ......0......... = Message complete DNS: .......1........ = Recursive query desired DNS: ........1....... = No recursive queries DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: rattlesnake.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Question Name: rattlesnake.glennwo.scottsu.com DNS: Question Type = Host Address DNS: Question Class = Internet address class DNS: Answer section: rattlesnake.glennwo.scottsu.com of type Host Addr on class INET addr. DNS: Resource Name: rattlesnake.glennwo.scottsu.com DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 157.55.107.88 

O cliente poderá então emitir um PING ao servidor. 5 SCOTTSU-7 RATTLESNAKE ICMP Echo, From 157.55.102.52 To 157.55.107.88  6 RATTLESNAKE SCOTTSU-7 ICMP Echo Reply, To 157.55.102.52 From 157.55.107.88

 

O Net Use

O exposto a seguir é um rastreamento do novo comportamento do Windows NT 4.0 que permite ao cliente conectar até um servidor Windows NT através do nome HOST em vez do nome do computador NetBIOS. Este é um rastreamento do seguinte comando:

 Net Use * \\scottsuPDC.scottsu.com\c$

 

Consulta o DNS pelo nome do HOST scottsuPDC.scotts.com 1 4.248 SCOTTSU-7 SCOTTSU_NT40 DNS 0x6:Std Qry for SCOTTSUPDC.SCOTTSU.COM   IP: Source Address = 157.55.102.52 IP: Destination Address = 157.55.100.204UDP: Src Port: Unknown, (1057); Dst Port: DNS (53); Length = 48 (0x30) UDP: Source Port = 0x0421 UDP: Destination Port = DNS UDP: Total length = 48 (0x30) bytes UDP: CheckSum = 0x8FEA UDP: Data: Number of data bytes remaining = 40 (0x0028) DNS: 0x6:Std Qry for SCOTTSUPDC.SCOTTSU.COM of type Host Addr on class INET addr. DNS: Query Identifier = 6 (0x6) DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: 0............... = Query DNS: .0000........... = Standard Query DNS: .....0.......... = Server not authority for domain DNS: ......0......... = Message complete DNS: .......1........ = Recursive query desired DNS: ........0....... = Recursive queries supported by server DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: SCOTTSUPDC.SCOTTSU.COM of type Host Addr on class INET addr. DNS: Question Name: SCOTTSUPDC.SCOTTSU.COM DNS: Question Type = Host Address DNS: Question Class = Internet address class 

Esta é a resposta do servidor DNS. O endereço IP de scottsuPDC.scottsu.com está no final do quadro 2 4.255 SCOTTSU_NT40 SCOTTSU-7 DNS 0x6:Std Qry Resp. for SCOTTSUPDC.SCOTTSU.COM   IP: Source Address = 157.55.100.204 IP: Destination Address = 157.55.102.52UDP: Src Port: DNS, (53); Dst Port: Unknown (1057); Length = 64 (0x40) UDP: Source Port = DNS UDP: Destination Port = 0x0421 UDP: Total length = 64 (0x40) bytes UDP: CheckSum = 0x4932 UDP: Data: Number of data bytes remaining = 56 (0x0038) DNS: 0x6:Std Qry Resp. for SCOTTSUPDC.SCOTTSU.COM of type Host Addr on class INET addr. DNS: Query Identifier = 6 (0x6) DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - No error DNS: 1............... = Response

DNS: .0000........... = Standard Query DNS: .....1.......... = Server authority for domain DNS: ......0......... = Message complete DNS: .......1........ = Recursive query desired DNS: ........1....... = No recursive queries DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: SCOTTSUPDC.SCOTTSU.COM of type Host Addr on class INET addr. DNS: Question Name: SCOTTSUPDC.SCOTTSU.COM DNS: Question Type = Host Address DNS: Question Class = Internet address class DNS: Answer section: SCOTTSUPDC.SCOTTSU.COM of type Host Addr on class INET addr. DNS: Resource Name: SCOTTSUPDC.SCOTTSU.COM DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = 157.55.100.204 

Em seguida, o cliente realiza um status adaptador do endereço IP para localizar os nomes que a máquina registrou 3 4.254 SCOTTSU-7 SCOTTSU_NT40 NBT NS: Query req. for *<00...(15)>   IP: Source Address = 157.55.102.52 IP: Destination Address = 157.55.100.204UDP: Src Port: NetBIOS Name Service, (137); Dst Port: NetBIOS Name Service (137); Length = 58 (0x3A) UDP: Source Port = NetBIOS Name Service UDP: Destination Port = NetBIOS Name Service UDP: Total length = 58 (0x3A) bytes UDP: CheckSum = 0x3A63 UDP: Data: Number of data bytes remaining = 50 (0x0032) NBT: NS: Query req. for *<00...(15)> NBT: Transaction ID = 32860 (0x805C) NBT: Flags Summary = 0x0000 - Req.; Query; Success NBT: 0............... = Request NBT: .0000........... = Query NBT: .....0.......... = Non-authoritative Answer NBT: ......0......... = Datagram not truncated NBT: .......0........ = Recursion not desired NBT: ........0....... = Recursion not available NBT: .........0...... = Reserved NBT: ..........0..... = Reserved NBT: ...........0.... = Not a broadcast packet NBT: ............0000 = Success NBT: Question Count = 1 (0x1) NBT: Answer Count = 0 (0x0) NBT: Name Service Count = 0 (0x0) NBT: Additional Record Count = 0 (0x0) NBT: Question Name = *<00...(15)> NBT: Question Type = Node Status Request NBT: Question Class = Internet Class 

Esta é a resposta ao status adaptador. A máquina tem vários nomes NetBIOS registrados. 4 4.255 SCOTTSU_NT40 SCOTTSU-7 NBT NS: Query (Node Status) resp. for *<00...(15)>, Success   IP: Source Address = 157.55.100.204 IP: Destination Address = 157.55.102.52UDP: Src Port: NetBIOS Name Service, (137); Dst Port: NetBIOS Name Service (137); Length = 345 (0x159) UDP: Source Port = NetBIOS Name Service UDP: Destination Port = NetBIOS Name Service UDP: Total length = 345 (0x159) bytes UDP: CheckSum = 0xC551 UDP: Data: Number of data bytes remaining = 337 (0x0151) NBT: NS: Query (Node Status) resp. for *<00...(15)>, Success NBT: Transaction ID = 32860 (0x805C) NBT: Flags Summary = 0x8400 - Resp.; Query; Success NBT: 1............... = Response NBT: .0000........... = Query NBT: .....1.......... = Authoritative Answer NBT: ......0......... = Datagram not truncated NBT: .......0........ = Recursion not desired NBT: ........0....... = Recursion not available NBT: .........0...... = Reserved NBT: ..........0..... = Reserved NBT: ...........0.... = Not a broadcast packet NBT: ............0000 = Success NBT: Question Count = 0 (0x0) NBT: Answer Count = 1 (0x1) NBT: Name Service Count = 0 (0x0) NBT: Additional Record Count = 0 (0x0) NBT: Resource Record Name = *<00...(15)> NBT: Resource Record Type = Node Status Request NBT: Resource Record Class = Internet Class NBT: Time To Live = 0 (0x0) NBT: RDATA Length = 263 (0x107) NBT: Number of Names = 12 (0xC)

NBT: ASCII Name = SCOTTSU_NT40 NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40 00 NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40D 00 NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40D <1C> NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40D <1B> NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40D <1E> NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40 <03> NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40D <1D> NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = <01><02>__MSBROWSE__<02><01> NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name NBT: ASCII Name = INet~Services <1C> NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name NBT: ASCII Name = IS~SCOTTSU_NT4000 NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40¿¿¿¿ NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering

NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name NBT: Adapter Address = 00A02463AB22 NBT: Version Major = 0 (0x0) NBT: Version Minor = 0 (0x0) NBT: Duration = 0 (0x0) NBT: FRMRs Received = 0 (0x0) NBT: FRMRs Transmitted = 0 (0x0) NBT: IFrame Receive Errors = 0 (0x0) NBT: Transmit Aborts = 0 (0x0) NBT: Tranmitted = 0 (0x0) NBT: Received = 0 (0x0) NBT: IFrame Transmit Errors = 0 (0x0) NBT: No Receive Buffers = 0 (0x0) NBT: T1 Timeouts = 0 (0x0) NBT: Ti Timeouts = 0 (0x0) NBT: Free NCBS = 0 (0x0) NBT: NCBS = 0 (0x0) NBT: Max NCBS = 0 (0x0) NBT: No Transmit Buffers = 255 (0xFF) NBT: Max Datagram = 799 (0x31F) NBT: Pending Sessions = 32 (0x20) NBT: Max Sessions = 33008 (0x80F0) NBT: Packet Size = 20976 (0x51F0) 

Agora o cliente irá realizar a troca de sinais de estabelecimento de conexão TCP tridirecional... 5 4.257 SCOTTSU-7 SCOTTSU_NT40 TCP ....S., len: 4, seq: 2817881, ack: 0, win: 8192   IP: Source Address = 157.55.102.52 IP: Destination Address = 157.55.100.204TCP: ....S., len: 4, seq: 2817881, ack: 0, win: 8192, src: 1056 dst: 139 (NBT Session)   6 4.257 SCOTTSU_NT40 SCOTTSU-7 TCP .A..S., len: 4, seq: 5416017, ack: 2817882, win: 8760, src SCOTTSU_NT40 SCOTTSU-7 IP  IP: Source Address = 157.55.100.204 IP: Destination Address = 157.55.102.52TCP: .A..S., len: 4, seq: 5416017, ack: 2817882, win: 8760, src: 139 (NBT Session) dst: 1056   7 4.258 SCOTTSU-7 SCOTTSU_NT40 TCP .A...., len: 0, seq: 2817882, ack: 5416018, win: 8760   IP: Source Address = 157.55.102.52 IP: Destination Address = 157.55.100.204TCP: .A...., len: 0, seq: 2817882, ack: 5416018, win: 8760, src: 1056 dst: 139 (NBT Session)  

Agora o cliente enviará uma solicitação de sessão NetBT ao servidor para o nome do servidor NetBIOS (e não o nome HOST). 8 4.259 SCOTTSU-7 SCOTTSU_NT40 NBT SS: Session Request, Dest: SCOTTSU_NT40   IP: Source Address = 157.55.102.52 IP: Destination Address = 157.55.100.204TCP: .AP..., len: 72, seq: 2817882, ack: 5416018, win: 8760, src: 1056 dst: 139 (NBT Session) TCP: Source Port = 0x0420 TCP: Destination Port = NetBIOS Session Service TCP: Sequence Number = 2817882 (0x2AFF5A) TCP: Acknowledgement Number = 5416018 (0x52A452) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x18 : .AP... TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....1... = Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 8760 (0x2238) TCP: CheckSum = 0x722C TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 72 (0x0048) NBT: SS: Session Request, Dest: SCOTTSU_NT40 , Source: SCOTTSU-7 <00>, Len: 68 NBT: Packet Type = Session Request NBT: Packet Flags = 0 (0x0) NBT: .......0 = Add 0 to Length NBT: Packet Length = 68 (0x44) NBT: Called Name = SCOTTSU_NT40 NBT: Calling Name = SCOTTSU-7 <00> 

Esta é uma resposta positiva da sessão do servidor. 9 4.259 SCOTTSU_NT40 SCOTTSU-7 NBT SS: Positive Session Response, Len: 0   IP: Source Address = 157.55.100.204 IP: Destination Address = 157.55.102.52TCP: .AP..., len: 4, seq: 5416018, ack: 2817954, win: 8688, src: 139 (NBT Session) dst: 1056 TCP: Source Port = NetBIOS Session Service TCP: Destination Port = 0x0420 TCP: Sequence Number = 5416018 (0x52A452) TCP: Acknowledgement Number = 2817954 (0x2AFFA2)

TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x18 : .AP... TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....1... = Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 8688 (0x21F0) TCP: CheckSum = 0x5D4C TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 4 (0x0004) NBT: SS: Positive Session Response, Len: 0 NBT: Packet Type = Positive Session Response NBT: Packet Flags = 0 (0x0) NBT: .......0 = Add 0 to Length NBT: Packet Length = 0 (0x0) 

Agora vamos começar a configurar uma sessão entre o redirecionador e o servidor (camada de aplicação). Esta configuração começa com um quadro de Negociação. 10 4.262 SCOTTSU-7 SCOTTSU_NT40 SMB C negotiate, Dialect = NT LM 0.12   11 4.276 SCOTTSU_NT40 SCOTTSU-7 SMB R negotiate, Dialect # = 7   

Agora vamos configurar a sessão entre o redirecionador e o servidor. Este quadro também possui uma Conexão de Árvore a ele anexado. Observe que o nome do servidor na Conexão de Árvore é o nome HOST. O redirecionador na realidade não utiliza esse nome. Ele apenas tem conhecimento sobre o nome do computador NetBIOS. 12 4.275 SCOTTSU-7 SCOTTSU_NT40 SMB C session setup & X, and C tree connect  IP: Source Address = 157.55.102.52 IP: Destination Address = 157.55.100.204TCP: .AP..., len: 314, seq: 2818128, ack: 5416131, win: 8647, src: 1056 dst: 139 (NBT Session) TCP: Source Port = 0x0420 TCP: Destination Port = NetBIOS Session Service TCP: Sequence Number = 2818128 (0x2B0050) TCP: Acknowledgement Number = 5416131 (0x52A4C3) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x18 : .AP... TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....1... = Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 8647 (0x21C7) TCP: CheckSum = 0x5638 TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 314 (0x013A) NBT: SS: Session Message, Len: 310 NBT: Packet Type = Session Message NBT: Packet Flags = 0 (0x0) NBT: .......0 = Add 0 to Length NBT: Packet Length = 310 (0x136) NBT: SS Data: Number of data bytes remaining = 310 (0x0136) SMB: C session setup & X, Username = Administrator, and C tree connect & X, Share = \\SCOTTSUPDC.SCOTTSU.COM\IPC$ SMB: SMB Status = Error Success SMB: Error class = No Error SMB: Error code = No Error SMB: Header: PID = 0xCAFE TID = 0x0000 MID = 0x0000 UID = 0x0000 SMB: Tree ID (TID) = 0 (0x0) SMB: Process ID (PID) = 51966 (0xCAFE) SMB: User ID (UID) = 0 (0x0) SMB: Multiplex ID (MID) = 0 (0x0) SMB: Flags Summary = 24 (0x18) SMB: .......0 = Lock & Read and Write & Unlock not supported SMB: ......0. = Send No Ack not supported SMB: ....1... = Using caseless pathnames SMB: ...1.... = Canonicalized pathnames SMB: ..0..... = No Opportunistic lock SMB: .0...... = No Change Notify SMB: 0....... = Client command SMB: flags2 Summary = 32771 (0x8003) SMB: ...............1 = Understands long filenames SMB: ..............1. = Understands extended attributes SMB: ..0............. = No paging of IO SMB: .0.............. = Using SMB status codes SMB: 1............... = Using UNICODE strings SMB: Command = C session setup & X SMB: Word count = 13 SMB: Word parameters SMB: Next offset = 0x00E8 SMB: Max Buffer Size = 4356 SMB: Max MPX requests = 50

SMB: VC number = 0 SMB: Session Key = 0 SMB: Password length = 24 (0x18) SMB: Unicode Password length = 24 (0x18) SMB: Capabilities = 212 (0xD4) SMB: ...............................0 = No Raw Reads and Writes. SMB: ..............................0. = No support for multiplexed commands. SMB: .............................1.. = Supports UNICODE strings. SMB: ............................0... = Does not support large files. SMB: ...........................1.... = Supports the NT SMB extensions. SMB: ..........................0..... = RPC remote API's not supported. SMB: .........................1...... = Recognizes NT Status codes. SMB: ........................1....... = Supports level II oplocks. SMB: .......................0........ = Does not support Lock and Read. SMB: Byte count = 171 SMB: Byte parameters SMB: Account name = Administrator SMB: Domain name = SCOTTSU_NT40D SMB: Native OS = Windows NT 1307 SMB: Native Lanman = Windows NT 4.0 SMB: Command = C tree connect & X SMB: Word count = 4 SMB: Word parameters SMB: Next offset = 0x0000 SMB: Disconnect flag = 0x0000 SMB: Password length = 1 (0x1) SMB: Byte count = 67 SMB: Byte parameters SMB: Password = SMB: Path name = \\SCOTTSUPDC.SCOTTSU.COM\IPC$ 13 4.289 SCOTTSU_NT40 SCOTTSU-7 TCP ...R.., len: 0, seq: 4933305, ack: 2818128, win: 0  14 4.289 SCOTTSU_NT40 SCOTTSU-7 TCP ...R.., len: 0, seq: 3578897, ack: 2818128, win: 0  15 4.297 SCOTTSU_NT40 SCOTTSU-7 SMB R session setup & X, and R tree connect & X, Type = IPC  16 4.479 SCOTTSU-7 SCOTTSU_NT40 TCP .A...., len: 0, seq: 2818442, ack: 5416289, win: 8489  17 4.637 SCOTTSU-7 SCOTTSU_NT40 SMB C tree connect & X, Share = \\SCOTTSUPDC.SCOTTSU.COM\C$   IP: Source Address = 157.55.102.52 IP: Destination Address = 157.55.100.204TCP: .AP..., len: 107, seq: 2818442, ack: 5416289, win: 8489, src: 1056 dst: 139 (NBT Session) TCP: Source Port = 0x0420 TCP: Destination Port = NetBIOS Session Service TCP: Sequence Number = 2818442 (0x2B018A) TCP: Acknowledgement Number = 5416289 (0x52A561) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x18 : .AP... TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....1... = Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 8489 (0x2129) TCP: CheckSum = 0x99CE TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 107 (0x006B) NBT: SS: Session Message, Len: 103 NBT: Packet Type = Session Message NBT: Packet Flags = 0 (0x0) NBT: .......0 = Add 0 to Length NBT: Packet Length = 103 (0x67) NBT: SS Data: Number of data bytes remaining = 103 (0x0067) SMB: C tree connect & X, Share = \\SCOTTSUPDC.SCOTTSU.COM\C$ SMB: SMB Status = Error Success SMB: Error class = No Error SMB: Error code = No Error SMB: Header: PID = 0xCAFE TID = 0x0000 MID = 0x0040 UID = 0x0801 SMB: Tree ID (TID) = 0 (0x0) SMB: Process ID (PID) = 51966 (0xCAFE) SMB: User ID (UID) = 2049 (0x801) SMB: Multiplex ID (MID) = 64 (0x40) SMB: Flags Summary = 24 (0x18) SMB: .......0 = Lock & Read and Write & Unlock not supported SMB: ......0. = Send No Ack not supported SMB: ....1... = Using caseless pathnames SMB: ...1.... = Canonicalized pathnames SMB: ..0..... = No Opportunistic lock SMB: .0...... = No Change Notify SMB: 0....... = Client command SMB: flags2 Summary = 32771 (0x8003) SMB: ...............1 = Understands long filenames SMB: ..............1. = Understands extended attributes SMB: ..0............. = No paging of IO SMB: .0.............. = Using SMB status codes SMB: 1............... = Using UNICODE strings SMB: Command = C tree connect & X SMB: Word count = 4 SMB: Word parameters SMB: Next offset = 0x0000

SMB: Disconnect flag = 0x0000 SMB: Password length = 1 (0x1) SMB: Byte count = 60 SMB: Byte parameters SMB: Password = SMB: Path name = \\SCOTTSUPDC.SCOTTSU.COM\C$ 18 4.654 SCOTTSU_NT40 SCOTTSU-7 SMB R tree connect & X, Type = A:  

Procura inversa de nome

Abaixo encontra-se um rastreamento da Procura inversa de nome utilizando o comando “PING -um endereço IP”. Este comando envia o endereço IP ao servidor DNS e pergunta pelo nome HOST associado ao nome NetBIOS. Lembre-se de que se o servidor DNS não tinha esse nome em sua tabela, o servidor DNS realizará realmente um status adaptador no endereço IP em vez de ir para WINS. No entanto, isto acontecerá somente se a caixa de verificação abaixo estiver marcada nas propriedades de *in-addr.arpa zone:

 

 

Ping -a 128.247.145.207 DNS: 0x1:Std Qry for 207.145.247.128.in-addr.arpa of type Dom. name ptr on class INET addr. DNS: Query Identifier = 1 (0x1) DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: 207.145.247.128.in-addr.arpa of type Dom. name ptr on class INET addr. DNS: Question Name: 207.145.247.128.in-addr.arpa DNS: Question Type = Domain name pointer DNS: Question Class = Internet address class

 Observe que o nome da Questão é o endereço IP invertido 207.145.247.128.in-addr.arpa of type PTR. ***************************************************************************************************************************** DNS: 0x1:Std Qry Resp. for 207.145.247.128.in-addr.arpa of type Dom. name ptr on class INET addr. DNS: Query Identifier = 1 (0x1) DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - No error  DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0)

DNS: Question Section: 207.145.247.128.in-addr.arpa of type Dom. name ptr on class INET addr. DNS: Question Name: 207.145.247.128.in-addr.arpa DNS: Question Type = Domain name pointer DNS: Question Class = Internet address class DNS: Answer section: 207.145.247.128.in-addr.arpa of type Dom. name ptr on class INET addr.

DNS: Resource Name: 207.145.247.128.in-addr.arpa DNS: Resource Type = Domain name pointer DNS: Resource Class = Internet address class DNS: Time To Live = 86400 (0x15180) DNS: Resource Data Length = 23 (0x17) DNS: Pointer: scottsu-7.scottsu.com

 

 

Internet          Todos os esquemas da IETF: http://ds.internic.net/Internet-drafts/

         Todas as RFCs: http://ds2.internic.net/rfc

         UseNet: comp.protocols.tcp-ip.domains

         Bons locais DNS na rede: http://www.is.co.za/dnsrd/

         Listas de correio:

namedroppers

é o fórum de discussão do grupo de trabalho DNS da equipe de engenharia da Internet (IETF) e também é utilizado pelo grupo de trabalho dnsind. A missão do dnsind é trabalhar na extensão do protocolo relacionado ao DNS para incorporar transferências de zona incrementais, notificação de alteração e atualizações dinâmicas. Solicitações de inscrição devem ser enviadas para majordomo@internic.net. As questões gerais sobre DNS não são apropriadas para este fórum. Arquivos atualizados estão disponíveis.

dns-security

é o fórum do grupo de trabalho dnssec da IETF. Solicitações de inscrição devem ser enviadas para dns-security-request@tis.com.

Livros          DNS and BIND

Tutorial completo de referência DNS para aqueles que utilizam BIND. Excelente começo para administradores com alguns conhecimentos de DNS; não aborda tópicos avançados. Publicação: Outubro 1992, reimpressão Março 1993 com algumas alterações. Autores: Paul Albitz e Cricket Liu Editora: O'Reilly & Associates ISBN: 1-56592-010-4

           TCP/IP Network Administration

Apêndice B:Mais informações

Contém uma visão geral auto-explicativa do DNS como um dos serviços de rede padrão em um ambiente TCP/IP. Publicação: Agosto 1992, reimpressão Janeiro 1994 com algumas alterações. Autor: Craig Hunt Editora: O'Reilly & Associates ISBN: 0-937175-82-X

            UNIX System Administration Handbook, Second Edition

Uma atualização do clássico de Nemeth e Snyder, que agora contém o capítulo 16 dedicado ao DNS. Indicado principalmente para comparação futura com os produtos existentes atualmente no mercado.Publicação: 1995 Autores: Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein Editora: Prentice Hall ISBN: 0-13-151051-7

           TCP/IP Illustrated, Volume 1

Para assuntos sobre protocolos e rede, consulte o capítulo 14. Publicação: 1994 Autor: W. Richard Stevens Editora: Addison-Wesley Publishing Company ISBN: 0-201-63346-9

           Firewalls and Internet Security: Repelling the Wily Hacker

Inclui alguns conselhos sobre DNS em um ambiente de firewall. Publicação: 1994 Autores: William R. Cheswick e Steven M. Bellovin Editora: Addison-Wesley Publishing Company ISBN: 0-201-63357-4

           Building Internet Firewalls

Bom livro sobre segurança geral com uma abordagem prática. O capítulo 8 inclui uma seção detalhada sobre DNS em um ambiente de firewall. Publicação: Setembro 1995 Autores: D. Brent Chapman e Elizabeth D. Zwicky Editora: O'Reilly & Associates ISBN: 1-56592-124-0

Documentos técnicosMicrosoft® Windows NT™ 3.5/3.51: Detalhes da implementação TCP/IP (Peça No. 098-62170)DHCPWINS.DOC (Peça No. 098-56544) 

CursosO Sistema de nomes de domínio (DNS) e Serviços de pastas e Nomenclatura de Internet - por Dr. Paul Mockapetris

MiscDNSAdmin.HLP  

Apêndice C:Registrando-se no NIC Domain-request@uunet.uu.net (703) 876-5050CIC@sh.cs.net (617) 873-2777domains%bitnic.bitnet@cunyvm.cuny.edu Envie mensagem para listserv%bitnic.bitnet@cunyvm.cuny.educom o texto “SEND DOMAIN GUIDE”Este arquivo contém exemplos e um modelo junto com explicações. Formulário de registro de domínio ftp://rs.internic.net/templates/domain-template.txt Taxa $100 (cobre a taxa de manutenção de $50 por dois anos). Após os 2 anos você receberá uma fatura anual. 

Apêndice D:Registros DNS           A - O registro de recurso A (endereço) mapeia um nome host (computador ou outro dispositivo de

rede) em um endereço IP em uma zona DNS. Seu par, o registro PTR, é utilizado para mapear um endereço IP em um nome host (computador ou outro dispositivo de rede) em uma zona de reserva DNS (aquelas no domínio DNS In-addr.arpa).

         AFSDB - O registro de recurso AFSDB dá a localização de um servidor de banco de dados de célula AFS (Andrew File System) ou um servidor de nomes autenticado da célula DCE (Distributed Computing Environment). AFS de Transarc é um sistema de arquivos, semelhante ao NFS, mas destinado mais para redes de longa distância (WANs, Wide Area Networks). O sistema AFS utiliza DNS para mapear DNS um nome de domínio DNS para um nome de um servidor de banco de dados de célula AFS. O serviço de nomes DCE da Open Software Foundation utiliza DNS para uma função semelhante: mapear o nome de domínio DNS de uma célula DCE para servidores de nomes autenticados para essa célula.

         CNAME - O registro de recurso CNAME (nome canônico) cria um alias (nome sinônimo) para o nome do host especificado (computador ou outro dispositivo de rede). Você poderá utilizar registros CNAME para ocultar detalhes da implementação de sua rede para clientes que conectam-se à mesma. Por exemplo, Ftp.microsoft.com é um alias (CNAME) para o verdadeiro nome do computador que executa o FTP Server da Microsoft. Os clientes conectam-se a Ftp.microsoft.com sem consideração do verdadeiro nome do computador. Isto permite que o FTP Server seja transferido para um computador diferente; somente o registro CNAME precisa ser alterado.

         HINFO - O registro de recurso HINFO (informação do host) identifica o tipo de hardware do host (computador ou outro dispositivo de rede) e o sistema operacional. Os identificadores do tipo de CPU e do Sistema operacional devem vir dos NOMES DE MÁQUINAS e NOMES DE SISTEMAS listados na RFC 1700 (Números atribuídos).

         ISDN - O registro de recurso de rede digital de serviços integrados (ISDN, Integrated Services Digital Network) é uma variaçãodo registro de recurso A (endereço). Ao invés de mapear um nome host (computador ou outro dispositivo de rede) para um endereço IP, o registro ISDN mapeia o nome para um endereço ISDN. Um endereço ISDN é um número de telefone que consiste de um código de país, um código de área ou código de país, um número de telefone local e, opcionalmente, um subendereço. O registro de recurso ISDN foi projetado para uso com o registro de recurso RT (rotear através).

         MB - O registro de recurso MB (caixa postal) é um registro experimental que especifica um host DNS (computador ou outro dispositivo de rede) com a caixa postal especificada. Outros registros experimentais relacionados são o registro de recurso MG (grupo de mensagens), o registro de recurso MR (renomeação de caixa postal) e o registro de recurso MINFO (informações de caixa postal).

         MG - O registro de recurso MG (grupo de mensagens) é um registro experimental que especifica uma caixa postal, membro do grupo de mensagens (lista de correio) especificado pelo nome do domínio DNS. Outros registros experimentais relacionados são o registro de recurso MB (caixa postal), o registro de recurso MR (renomeação de caixa postal) e o registro de recurso MINFO (informações de caixa postal).

         MINFO - O registro de recurso MINFO (informações de caixa postal) é um registro experimental que especifica uma caixa postal, responsável pela lista de correio ou caixa postal especificada. Outros registros experimentais relacionados são o registro de recurso MB (caixa postal), o registro de recurso MG (grupo de mensagens) e o registro de recurso MR (renomeação de caixa postal).

         MR - O registro de recurso MR (renomeação de caixa postal) é um registro experimental que especifica uma caixa postal que é a renomeação adequada da outra caixa postal especificada. Outros registros experimentais relacionados são o registro de recurso MB (caixa postal), o registro de recurso MG (grupo de mensagens) e o registro de recurso MINFO (informações de caixa postal).

         MX - O registro de recurso MX (trocador de mensagens) especifica um servidor de troca de mensagens para um nome de domínio DNS. Um servidor troca de mensagens é um host (computador ou outro dispositivo de rede) que irá processar ou enviar mensagem para o nome de domínio DNS. Processar a mensagem significa entregá-la no endereço ou passá-la para um tipo de transporte de mensagem diferente. Enviar a mensagem significa enviá-la ao seu servidor de destino final, enviando-a utilizando Protocolo de transferência de mensagem simples (SMTP, Simple Message Transfer Protocol) para outro servidor de troca de mensagens que esteja mais próximo do destino final, ou enfileirando-a durante um tempo específico.

         NS - O registro de recurso NS (servidor de nomes) identifica o servidor(es) de nomes DNS do domínio DNS. O registro de recurso NS aparece em todas as zonas e zonas inversas DNS (aquelas no domínio DNS In-addr.arpa).

         PTR - O registro de recurso PTR (ponteiro) mapeia um endereço IP para um nome host (computador ou outro dispositivo de rede) em uma zona inversa DNS (aquelas no domínio DNS In-addr.arpa). Seu par, o registro de recurso A (endereço) é utilizado para mapear um nome de host (computador ou outro dispositivo de rede) para um endereço IP em uma zona DNS.

         RP - O registro de recurso RP (pessoa responsável) indica quem é o responsável pelo domínio DNS ou host especificado (computador ou outro dispositivo de rede). Você poderá especificar vários registros RP para um determinado domínio DNS ou host. O registro possui duas partes: em endereço de correio eletrônico (no mesmo formato DNS que aquele no registro de recurso SOA) e um nome de domínio DNS que aponta para informações adicionais sobre o contato.

         RT - O registro de recurso RT (rotear através) especifica um host intermediário (computador ou outro dispositivo de rede) que roteia pacotes para um destino host. O registro RT é utilizado em conjunto com os registros de recurso ISDN e X25. Sua sintática e semântica é semelhante ao registro tipo MX e é utilizado quase que da mesma maneira.

         SOA - O registro de recurso SOA (início de autorização) indica que este servidor de nomes DNS é a melhor fonte de informações para os dados dentro deste domínio DNS. É o primeiro registro em cada um dos arquivos de banco de dados de DNS. O registro de recurso SOA é criado automaticamente pelo Gerenciador DNS quando você cria uma nova zona DNS.

         TXT - O registro de recurso TXT (texto) associa informações textuais gerais com um item do banco de dados de DNS. Um uso típico é para identificação da localização de um host (computador ou outro dispositivo de rede) (por exemplo, Localização: Prédio 26S, Sala 2499). A seqüência de texto deve ser menor do que 256 caracteres, porém múltiplos registros de recurso TXT são permitidos.

         WKS - O registro de recurso WKS (serviço bem conhecido) descreve os serviços fornecidos por um determinado protocolo em uma determinada interface. O protocolo geralmente é UDP ou TCP, mas pode ser qualquer uma das entradas listadas no arquivo PROTOCOLS (\%Raizdosistema%\system32\drivers\etc\protocol). Os serviços são os serviços abaixo do número da porta 256 do arquivo SERVICES (\%Raizdosistema%\system32\drivers\etc\services).

         X25 - O registro de recurso X25 (X.25) é uma variação do registro de recurso A (endereço). Ao invés de mapear um nome de host (computador ou outro dispositivo de rede) para um endereço IP, o registro X25 mapeia o nome para um endereço X.121. X.121 é o padrão da ISO (International Standards

Organization) que especifica o formato dos endereços utilizados em redes X.25. O registro de recurso X25 foi projetado para ser utilizado em conjunto com o registro de recurso RT (rotear através).

         Registro Genérico - O registro de recurso Genérico é utilizado para adicionar um registro de recurso não padronizado ao banco de dados de DNS. O registro de recurso Genérico é um recurso do Gerenciador DNS Microsoft.

 

Nossos especiais agradecimentos às pessoas abaixo por sua ajuda neste projeto:Azfar Moazzam; James Gilroy; Dan Perry; Jim Harrison; Dave Macdonald; Steven Judd; Prakash Narasimhamurthy; Margaret Johnson; Rodger Seabourne