• Domain Name Service (DNS)
• Estrutura de DNS
• O servidor de nome
• Registros de recurso
• IN-ADDR-ARPA
• Mensagens
• A repessoa resolvida de nome
• Configurar um UNIX DNS servidor
• Entrada nos registros de recurso
• Concluir os arquivos DNS
• Começar os demônios DNS
• Configuração de um cliente
• Protocolo de BOOTP
• Mensagens de BOOTP
• Network Time Protocol (NTP)
• Sumário
• Perguntas e Respostas
• Concurso

— 11 —
Serviço de nome de domínio

TCP/IP usa um endereço de 32 bits à via um datagrama a um destino. É útil esquecer estes endereços de 32 bits e usar nomes comuns em vez disso, porque os nomes são muito mais fáceis lembrar-se. Há vários métodos usados para isto. O mais comum examina-se no Dia 7, "a Configuração TCP/IP e a administração Fundamentos", empregando um arquivo ASCII na máquina de envio que tinha nomes e endereços correspondentes (/etc/hosts em um dispositivo UNIX). Uma limitação principal a este sistema é que a máquina pode a via só a outras máquinas que têm uma entrada neste arquivo, que pode ser impossível de manter quando há muitas máquinas de objetivo ou quer acessar todos os dispositivos na sua rede.

Outra aproximação é desfazer-se da resolução de endereço de outro processo que atua como um serviço diretivo. Há dois tais esquemas no uso comum hoje: Domain Name Service (DNS) e Network Information Service (NIS), que é agora parte do NFS. Hoje olho para DNS mais detalhadamente. No Dia 12, "o NFS e NIS", examino o NFS a fundo.

Também hoje olho para o protocolo BOOTP, um sistema que fica largamente adotado como diskless estações de trabalho e os sistemas de cliente/servidor ficam mais comuns. BOOTP confia em TCP/IP. Cada um que trabalha com TCP/IP pode esperar consequentemente encontrar por acaso o protocolo BOOTP, portanto uma explicação dele é útil nesta etapa.

Finalmente, o dia acede a uma olhada rápida para Network Time Protocol (NTP), que se usa para assegurar a sincronização de timestamps entre máquinas.

Domain Name Service (DNS)

Um nome simbólico é uma cadeia de caráter que se usa para identificar uma máquina. Um nome simbólico pode ser franco (bills_machine ou tpci_server1) ou mais complexo, como muitas vezes é o caso em grandes organizações onde o nome identifica o tipo da máquina e a sua posição (como hpws510, onde hpws identifica uma estação de trabalho de CV no quinto andar, o quarto 10).

Enviando a informação a máquinas remotas, os endereços IP ou os endereços de Internet devem usar-se. Em vez de necessitar que o usuário memorize os números da máquina remota, é comum usar um nome simbólico. No fim de tudo, um nome simples é muito mais fácil lembrar-se do que um endereço de Internet de 32 bits.

Como viu antes neste livro, a conversão de um nome simbólico para um endereço IP real executa-se normalmente dentro da máquina de envio, usando um arquivo como o arquivo/etc/hosts de UNIX. Este tipo da aproximação trabalha bem dentro de uma pequena rede, onde um número limitado de máquinas de destino se implica. Tratando com a Internet inteira, contudo, é desarrazoado esperar que um arquivo ASCII contenha todos os nomes simbólicos possíveis e os seus endereços.

O tamanho absoluto de um arquivo necessitado manter todos os nomes de domínio simbólicos possíveis e os seus endereços de rede únicos correspondentes não é o único problema. As grandes redes tendem a modificar-se constantemente, especialmente em umas interredes o tamanho da Internet. Centenas de adições e modificações a entradas existentes devem executar-se diariamente. O tempo necessitado atualizar cada máquina (ou até portões selecionados a redes autônomas) nas interredes seria enorme.

A solução para o problema é oferecer um método de afastar a gestão das mesas de busca de Network Information Center (NIC), que administra a Internet, e em direção aos participantes e as suas redes autônomas em tal maneira que a carga da rede é pequena mas a flexibilidade não se compromete. Isto é o que Domain Name Service (DNS) faz. DNS também se chama às vezes o serviço diretivo de Internet, embora o nome seja um tanto de um erro de nome.

UNIX implementa DNS por um demônio chamado denominado, que corre em um servidor de nome, máquina que trata a resolução de nomes simbólicos usando métodos de DNS. A parte do sistema é uma biblioteca de funções que podem usar-se em aplicações para executar perguntas no servidor de nome. Esta rotina de pergunta chama-se a repessoa resolvida ou repessoa resolvida de nome e pode residir em outra máquina. O servidor de nome e a repessoa resolvida examinam-se mais detalhadamente logo.

Estrutura de DNS

O Serviço de Nome de domínio, como o seu nome contém, trabalha dividindo as interredes no grupo de domínios ou redes, que podem dividir-se além disso em subdomínios. Esta estrutura parece-se com uma árvore, como mostrado na Figura 11.1, usando alguns nomes de domínio arbitralmente escolhidos. O primeiro jogo de domínios chama-se os domínios superiores. Há seis domínios superiores no uso regular:

• ARPA: Para organizações específicas para a Internet
  


• COM: Para empresas comerciais
  


• EDU: Para organizações educacionais
  


• GOVERNADOR: Para órgãos governamentais
  


• MIL: Para organizações militares
  


• ORG: Para organizações não-comerciais
  

A figura 11.1. A estrutura do domínio de Internet.

Além destes domínios superiores, lá dedicam-se domínios superiores de cada país que se une. Estes identificam-se normalmente por uma forma curta do nome do país, como .ca do Canadá e .uk do Reino Unido. Estes país os domínios superiores deixam-se normalmente de diagramas da estrutura de Internet da conveniência (de outra maneira haveria centenas de domínios superiores). O esgotamento de domínio repete-se às vezes abaixo do domínio de país, então pode haver uma extensão .com ligada com .ca para mostrar um domínio comercial canadense ou .edu com .uk de uma universidade britânica.

Abaixo dos domínios superiores é outro nível das organizações individuais dentro de cada domínio superior. Os nomes de domínio registram-se todos com Network Information Center (NIC) e são únicos para a rede. Normalmente os nomes são representativos da companhia ou organização, mas alguns nomes "atraentes" realmente trabalham o seu caminho em (normalmente por causa de razões históricas).

Há dois modos de denominar um objetivo. Se o objetivo estiver nas interredes, o nome absoluto usa-se. O nome absoluto é único e inequívoco, especificando o domínio da máquina de objetivo. Um nome relativo pode usar-se dentro do domínio local, onde o servidor de nome sabe que o objetivo é dentro do domínio e daqui não precisa à via do datagrama para as interredes, ou quando o nome relativo se conhece pelo servidor de nome e pode estender-se e derrotar-se corretamente.

O servidor de nome

Cada Servidor de Nome de DNS dirige uma área distinta de uma rede (ou um domínio inteiro, se a rede for pequena). O jogo de máquinas dirigidas pelo servidor de nome chama-se uma zona. Várias zonas podem dirigir-se por um servidor de nome. Quase cada zona tem um servidor de nome secundário ou de reserva indicado, com os dois (primário e secundário) servidores de nome mantendo a informação duplicada. Os servidores de nome dentro de uma zona comunicam a utilização de um protocolo de transferência da zona.

DNS funciona ao aninhamento do grupo de zonas. Cada servidor de nome comunica-se com aquele acima dele (e, se houver um, aquele em baixo dele). Cada zona tem pelo menos um servidor de nome responsável por saber a informação sobre endereço de cada máquina dentro daquela zona. Cada servidor de nome também sabe o endereço de pelo menos um outro servidor de nome. As mensagens entre servidores de nome normalmente usam User Datagram Protocol (UDP) porque o seu método connectionless provê a melhor realização. Contudo, TCP usa-se para atualizações de banco de dados por causa da sua confiança.

Quando uma aplicação de usuário tem de resolver um nome simbólico em um endereço de rede, uma pergunta envia-se pela aplicação ao processo de repessoa resolvida, que então comunica a pergunta para o servidor de nome. (Examino a repessoa resolvida mais detalhadamente na seguinte seção, "Registros de Recurso".) O servidor de nome verifica as suas próprias mesas e devolve o endereço de rede que corresponde ao nome simbólico. Se o servidor de nome não tiver a informação necessita, pode enviar um pedido a outro servidor de nome. Este processo mostra-se na Figura 11.2. Tanto os servidores de nome como as repessoas resolvidas usam tabelas de base de dados e esconderijos para manter a informação sobre as máquinas na zona local, bem como a informação recentemente solicitada do exterior da zona.

A figura 11.2. Resolução de nomes simbólicos.

Quando um servidor de nome recebe uma pergunta de uma repessoa resolvida, há vários tipos de operações que o servidor de nome pode executar. Denomine a queda de operações de repessoa resolvida em duas categorias: não-recursivo e recursivo. Uma operação recursiva é aquela na qual o servidor de nome deve acessar outro servidor de nome da informação.

As operações não-recursivas executadas pelo servidor de nome incluem uma resposta cheia ao pedido da repessoa resolvida, uma indicação a outro servidor de nome (que a repessoa resolvida deve enviar a uma pergunta para), ou uma mensagem de erro. Quando uma operação recursiva é necessária, o servidor de nome contata com outro servidor de nome com o pedido da repessoa resolvida. O servidor de nome remoto responde ao pedido com um endereço de rede ou com uma mensagem negativa, indicando o fracasso. As regras de DNS proíbem a um servidor de nome remoto enviar uma indicação a ainda outro servidor de nome.

Registros de recurso

A informação necessitada resolver nomes simbólicos mantém-se pelo servidor de nome no grupo de registros de recurso, que são entradas em um banco de dados. Os registros de recurso (muitas vezes abreviava RR) contêm a informação no formato de ASCII. Como ASCII se usa, é fácil atualizar os registros. O formato de registros de recurso mostra-se na Figura 11.3.

A figura 11.3. O formato de registro de recurso.

O campo de Nome é o nome de domínio da máquina à qual o registro se refere. Se nenhum nome se especificar, o nome anteriormente usado substitui-se.

O campo de Tipo identifica o tipo do registro de recurso. Os registros de recurso usam-se com vários objetivos, como mapeamento de nomes para endereços e definição de zonas. O Tipo do registro de recurso identifica-se por um código mnemônico ou um número. Estes códigos e as suas significações mostram-se na Tabela 11.1. Alguns tipos de registro de recurso são obsoletos agora (3 e 4), e os outros consideram-se experimentais neste tempo (13 e 17–21).

O campo de Classe no leiaute de registro de recurso contém um valor da classe do registro. Se nenhum valor se especificar, a classe última usada substitui-se. Os servidores de nome de Internet normalmente têm o código em.

O campo de Tempo para viver (TTL) especifica o período de tempo durante segundos que o registro de recurso é válido no esconderijo. Se um valor de 0 se usar, o registro não deve acrescentar-se ao esconderijo. Se o campo TTL se omitir, um valor à revelia usa-se. Normalmente este campo diz o servidor de nome quanto tempo a entrada é válida antes que tenha de pedir uma atualização.

A seção de dados do registro de recurso contém duas partes, compostas do comprimento do registro e os próprios dados. O campo de Comprimento de Dados especifica o comprimento da seção de dados. Os dados são um campo de comprimento variável (daqui a necessidade de um valor de comprimento) que descreve a entrada de qualquer maneira. O uso deste campo dissente com os tipos diferentes de registros de recurso.

Alguns tipos de registro de recurso têm uma parte única da informação na área de dados, como um endereço, ou no máximo três partes da informação. A única exceção é a Partida do registro de recurso de Autoridade. Os conteúdos das áreas de dados de registro de recurso (exceto SOAs) dão-se na Tabela 11.2.

O formato de registro de recurso de Partida de autoridade (SOA) usa-se para identificar as máquinas dentro de uma zona. Há só um registro de SOA em cada zona. O formato do campo de dados SOA mostra-se na Figura 11.4. Os campos no registro de recurso SOA usam-se pela maior parte para administração e manutenção do servidor de nome.

A figura 11.4. O recurso SOA registra o formato.

O campo MNAME é o nome de domínio da fonte de dados da zona. O RNAME (nome de pessoa responsável) campo é o nome de domínio da caixa do correio do administrador da zona. O campo Serial contém um número da versão da zona. Incrementa-se quando a zona se modifica; de outra maneira, mantém-se como o mesmo valor de todas tais mensagens.

O Tempo de Refresco é o número de segundos entre refrescos de dados da zona. O Tempo de Nova tentativa é o número de segundos para esperar entre pedidos de refresco mal sucedidos. O Tempo de Vencimento é o número de segundos depois dos quais a informação da zona não é já válida. Finalmente, o Tempo Mínimo é o número de segundos a usar-se no Tempo para Viver o campo de registros de recurso dentro da zona.

Alguns registros de recurso de mostra mostram o formato simples usado. Os registros de recurso de endereço compõem-se do nome de máquina, o tipo do indicador de registro de recurso (Um para o Endereço RRs, por exemplo), e o endereço de rede. Um registro de recurso de Endereço de mostra pareceria a isto:

TPCI_SCO_4     IN     A    143.23.25.7

O EM etiquetas o recurso registram como uma classe de Internet. Este formato faz fácil localizar um nome e conseguir o seu endereço. (O reverso, indo do endereço ao nome, não é como fácil e necessita um formato especial chamado IN-ADDR-ARPA, que se examina na seguinte seção, "IN-ADDR-ARPA".)

Para registros de recurso de Serviço Bem conhecidos (WKS ou tipo 11), o campo de dados do registro contém três campos usados para descrever os serviços apoiados no endereço ao qual o registro se refere. Um registro de recurso de WKS de mostra poderia parecer a isto:

TPCI_SCO.TPCI.COM     IN     WKS     143.23.1.34.

                                     FTP  TCP  SMTP  TELNET

O nome de domínio cheio e o endereço de Internet mostram-se, como está o EM mostrar a classe de Internet de registros de recurso. O tipo do registro indica-se com o WKS. Os protocolos apoiados pela máquina naquele endereço enumeram-se depois do endereço. Na verdade, estes são mapas de bits que correspondem a portos. Quando o porto mordeu estabelece-se em um valor de 1, o serviço apoia-se. A lista de portos e serviços define-se por uma Internet RFC.

IN-ADDR-ARPA

Os campos de endereço, tal como no tipo de registro de recurso de Endereço, usam um formato especial chamado IN-ADDR-ARPA. Isto permite o mapeamento inverso do endereço ao nome do host bem como anfitrião do endereço que faz o mapa. Para entender IN-ADDR-ARPA, é útil começar com um registro de recurso de formato padrão. Antes mencionou-se que os registros de recurso se mantêm no formato de ASCII. Um dos tipos mais simples do registro de recurso é para o endereço (o tipo A), como visto antes. Um extrato de um arquivo de endereço mostra-se aqui:

TPCI_HPWS1    IN     A     143.12.2.50

TPCI_HPWS2    IN     A     143.12.2.51

TPCI_HPWS3    IN     A     143.12.2.52

TPCI_GATEWAY  IN     A     143.12.2.100

              IN     A     144.23.56.2

MERLIN        IN     A     145.23.24.1

SMALLWOOD     IN     A     134.2.12.75

Cada linha do arquivo representa um registro de recurso. Neste caso, são todas as entradas simples que têm o nome simbólico da máquina (pseudônimo), a classe da máquina (em para a Internet), um para mostrar que é um registro de recurso de Endereço e o endereço de Internet. A entrada da máquina TPCI_GATEWAY tem dois endereços correspondentes porque é um portão entre duas redes. O portão tem um endereço diferente em cada uma das redes, portanto tem dois registros de recurso no mesmo arquivo. (Como com a maior parte de outros fragmentos de código neste livro, estes endereços de exemplo são hipotéticos.)

Este tipo do arquivo faz o nome para o endereço que faz o mapa fácil. O servidor de nome simplesmente procura uma linha com o nome simbólico solicitado pela aplicação e devolve o endereço de Internet no fim daquela linha. Os bancos de dados põem-se no índex no nome, portanto estas pesquisas prosseguem muito rapidamente.

Procurar do endereço ao nome é não exatamente como fácil. Se os arquivos de registro de recurso forem pequenos, os retardamentos de uma pesquisa manual não são apreciáveis, mas com grandes zonas podem haver milhares ou dezenas de milhares de entradas. O índice está no nome, procurar então um endereço pode ser um processo lento. Para resolver este problema que faz o mapa do reverso, IN-ADDR-ARPA desenvolveu-se. IN-ADDR-ARPA usa o endereço de anfitrião como um índice à informação sobre registro sobre recurso do anfitrião. Quando o registro de recurso próprio se localiza, o nome simbólico pode extrair-se.

IN-ADDR-ARPA usa o tipo de registro de recurso PTR (ver a Tabela 11.1) apontar do endereço ao nome. Poderia haver um destes índices de ponteiro mantidos em cada servidor de nome. Um exemplo de um arquivo de número ao nome segue:

23.1.45.143.IN-ADDR-ARPA.    PTR    TPCI_HPWS_4.TPCI.COM

1.23.64.147.IN-ADDR-ARPA.    PTR    TPCI_SERVER.MERLIN.COM

3.12.6.123.IN-ADDR-ARPA.     PTR    BEAST.BEAST.COM

23.143.IN-ADDR-ARPA          PTR    MERLINGATEWAY.MERLIN.COM

Os endereços de Internet invertem-se no arquivo IN-ADDR-ARPA da tranquilidade do uso. Como mostrado no arquivo de mostra, não é necessário especificar o endereço completo de um portão porque o nome de domínio fornece bastante informação sobre encaminhamento.

Mensagens

As mensagens de DNS transferem-se entre servidores de nome para atualizar os seus registros de recurso. Os campos destas mensagens são bastante semelhantes àqueles dos próprios registros. O formato de uma mensagem DNS mostra-se na Figura 11.5. A cabeçada tem várias subseções que contêm a informação sobre o tipo de pergunta ou resposta que se envia. O resto da mensagem compõe-se de quatro campos de comprimento variável, que se subdividem além disso:

• Pergunta: A informação necessita-se.
  


• Resposta: A resposta à pergunta (do RR).
  


• Autoridade: O nome de outros servidores de nome que poderiam mandar solicitar a informação, se não está prontamente disponível no servidor de nome visado.
  


• Informação adicional: a informação que pode fornecer-se para responder a pergunta ou endereços de servidores de nome se o campo de Autoridade se usou.
  

A figura 11.5. O formato de mensagem DNS.

A cabeçada de mensagem DNS tem vários campos diferentes ela mesma, como mostrado na Figura 11.6. A cabeçada está presente em todas as mensagens DNS. O campo de carteira de identidade de cabeçada é 16 bits de longitude e usa-se para combinar com perguntas e respostas um a outro. O campo QR do bit único faz-se em um valor de 0 para indicar uma pergunta ou valor de 1 para mostrar uma resposta. O campo de OpCode é 4 bits de longitude e pode ter um dos valores mostrados na Tabela 11.3.

A figura 11.6. A mensagem DNS formato de Cabeçada.

O campo AA é o bit de resposta autoritário. Um valor de 1 em uma mensagem de resposta indica que o servidor de nome é a autoridade reconhecida do nome de domínio questionado. O TC (truncamento) mordeu estabelece-se em um valor de 1 quando a mensagem é truncada por causa do comprimento excessivo. De outra maneira, o TC mordeu estabelece-se em 0. O RUTHERFORD (recorrência desejada) o bit estabelece-se em 1 quando se solicita que o servidor de nome execute uma pergunta recursiva. O RA (recorrência disponível) o bit estabelece-se em 1 em uma resposta quando o servidor de nome pode executar recorrências.

O campo Z é 3 bits de longitude e não se usa. O campo RCODE é 4 bits de longitude e pode estabelecer-se em um dos valores mostrados na Tabela 11.4.

O campo QDCOUNT é um campo de 16 bits do número de entradas na seção de Pergunta. O campo ANCOUNT é outro campo de 16 bits do número de respostas na seção de Resposta (o número de registros de recurso na resposta). O campo NSCOUNT é 16 bits e especifica o número de registros de recurso de servidor na seção de Autoridade da mensagem. O campo de 16 bits ARCOUNT especifica o número de registros de recurso na seção de registro Adicional.

A seção de Pergunta da mensagem tem três campos do seu próprio, como mostrado na Figura 11.7. O campo de Pergunta transporta a pergunta, que se identifica por estes campos. O campo QNAME é o nome de domínio solicitado. O QTYPE é o tipo da pergunta, usando um dos valores mostrados na Tabela 11.1. O QCLASS é a classe da pergunta, que pode estabelecer-se segundo exigências da aplicação.

A figura 11.7. A mensagem DNS formato de campo de Pergunta.

Três campos últimos na mensagem DNS (Resposta, Autoridade e Informação adicional) todos têm o mesmo formato, que mostrado na Figura 11.8. O campo de Nome mantém o nome de domínio do registro de recurso. O campo de Tipo tem algum dos valores de tipo de registro de recurso válidos. (Ver a Tabela 11.1.)

A figura 11.8. O formato de mensagem DNS Resposta, Autoridade e campos de Informação adicional.

A Classe é a classe de dados no campo de dados. O campo de Tempo para viver (TTL) é o número de segundos a informação é válida sem uma atualização. O campo RDLENGTH é o comprimento da informação no campo de dados. Finalmente, o campo RDATA é a informação sobre registro sobre recurso ou outros dados, dependendo da classe e o tipo da pergunta e resposta. Podem haver muitos tais registros na Resposta, Autoridade e seções de Informação adicional da mensagem DNS.

A repessoa resolvida de nome

Pelo que as aplicações de usuário estejam em questão, resolução que os nomes simbólicos em endereços de rede reais são fáceis. O processo mencionou-se antes. A aplicação envia uma pergunta para um processo chamado a repessoa resolvida de nome ou repessoa resolvida (que às vezes reside em outra máquina). A repessoa resolvida de nome poderia ser capaz de resolver o nome diretamente, em que caso envia uma mensagem de regresso à aplicação. Se a repessoa resolvida não puder determinar o endereço de rede, comunica-se com o servidor de nome (que poderia contatar com outro servidor de nome).

A repessoa resolvida destina-se para substituir sistemas de resolução de nome existentes em uma máquina, como o arquivo/etc/hosts de UNIX. A substituição destes mecanismos comuns é transparente ao usuário, embora o administrador deva saber se o sistema de resolução de nome nativo ou DNS devem usar-se em cada máquina portanto as mesas corretas podem manter-se.

Quando a repessoa resolvida adquire a informação de um servidor de nome, guarda as entradas no seu próprio esconderijo para reduzir a necessidade de mais tráfego de rede se o mesmo nome simbólico se usar novamente (que muitas vezes é o caso com aplicações que trabalham através de redes). O período de tempo a repessoa resolvida de nome guarda estes registros é dependente do Tempo para Viver o campo nos registros de recurso enviados, ou em um conjunto de valores à revelia pelo sistema.

Quando um servidor de nome não pode resolver um nome, pode retornar uma mensagem à repessoa resolvida com o endereço de outro servidor de nome no campo de Autoridade da mensagem. A repessoa resolvida então deve dirigir uma mensagem a outro servidor de nome nas esperanças de resolver o nome. A repessoa resolvida pode pedir que o servidor de nome conduza a própria pergunta estabelecendo o RUTHERFORD bit (recursivo) na mensagem. O servidor de nome pode recusar ou aceitar o pedido.

A repessoa resolvida usa tanto UDP como TCP no seu processo de pergunta, embora UDP seja mais comum, devido à sua velocidade. Contudo, as perguntas iterativas ou as transferências de grandes montantes da informação poderiam recorrer a TCP por causa da sua confiança mais alta.

Abaixo do sistema operacional UNIX, várias implementações diferentes da repessoa resolvida de nome estão no uso. A repessoa resolvida provista com as versões BSD de UNIX limitou-se em particular, não oferecendo nem um esconderijo nem capacidades de pergunta iterativas. Para resolver estas limitações, o servidor de Berkeley Internet Name Domain (BIND) acrescentou-se. ATE fornece tanto capacidades de pergunta escondem como iterativas em três modos diferentes: como um servidor primário, como um servidor secundário, ou como um servidor de só esconder (que não tem um banco de dados do seu próprio, só um esconderijo). O uso de AMARRA sistemas BSD permite a outro processo assumir a carga de trabalho da resolução de nome, um processo que poderia estar em outra máquina inteiramente.

Configurar um UNIX DNS servidor

Configurar um servidor DNS necessita que vários arquivos e bancos de dados se modifiquem ou se criem. O processo é demorado, mas afortunadamente tem de fazer-se só uma vez para cada servidor. Os arquivos implicados na maior parte de organizações DNS e os seus objetivos, são como se segue:

named.hosts: Define o domínio com mapeamentos hostname-to-IP

named.rev: Usos IN-ADDR-ARPA de mapeamentos IP-to-hostname

named.local: Usado para resolver o driver de laço de retorno

named.ca: as Listas arraigam servidores de domínio

named.boot: Usado para estabelecer arquivo e posições de banco de dados

Estes nomes de arquivo usam-se pela convenção, mas podem modificar-se para ajustar as suas próprias necessidades pessoais. O arquivo primário na lista é named.boot, que se lê quando as botas de sistema e definem outros arquivos no jogo. Por isso, qualquer modificação de nome de arquivo reflete-se em named.boot. Para a simplicidade, uso os nomes de arquivo convencionais neste capítulo. Cada um dos arquivos enumerados aqui é um banco de dados com entradas na forma de um registro de recurso.

Entrada nos registros de recurso

Para a configuração de servidor de mostra, assumo um sistema operacional UNIX usando nomes regularmente padrão e leiaute de rede. DNS deixa-o tornar-se muito complexo, mas é mais fácil ver o que os arquivos e os registros de recurso fazem com um leiaute simples.

Um registro de recurso SOA coloca-se no arquivo named.hosts. Os pontos-e-vírgulas no registro usam-se para comentários. Este registro de recurso formatou-se como um campo por linha para esclarecer as suas entradas, embora isto não seja necessário. Este registro de recurso define um limite superior do domínio de tpci.com, com server.tpci.com o servidor de nome primário do domínio, root.merlin.tpci.com o endereço de e-mail da pessoa responsável pelo domínio e o resto das entradas identificadas por comentários:

tpci.com.   IN   SOA     server.tpci.com

    root.merlin.tpci.com (

    2  ; Serial number

    7200 ; Refresh (2 hrs)

    3600 ; Retry (1 hr)

    151200 ; Expire (1 week)

    86400 ); min TTL

Observe que a informação do número de série ao campo vencer se cerca em parênteses. Isto é parte da sintaxe de ordem e deve incluir-se para indicar a ordem de parâmetro.

Além do SOA RR, o arquivo named.hosts contém registros de Endereço. Estes registros usam-se para o mapeamento real de um nome do host ao seu endereço IP. Alguns registros de recurso de Endereço mostram o formato destas entradas (refira-se a seções mais adiantadas deste capítulo das significações de cada campo se não estiver seguro):

artemis     IN     A    143.23.25.7

merlin      IN     A    143.23.25.9

pepper      IN     A    143.23.25.72

Os hostnames não se dão como nomes de domínio totalmente qualificados porque o servidor pode deduzir o nome completo. Se quiser usar o nome de domínio cheio, deve seguir o nome com um período. As máquinas mostradas no exemplo precedente iriam se dar como esta utilização de nomes de domínio totalmente qualificados:

artemis.tpci.com.     IN     A    143.23.25.7

merlin.tpci.com.      IN     A    143.23.25.9

pepper.tpci.com.      IN     A    143.23.25.72

O Ponteiro (PTR) registro de recurso usa-se para fazer o mapa de um endereço IP a um nome usando IN-ADDR-ARPA. Um PTR único RR ajuda a esclarecer isto. O registro

7.0.120.147.in-addr.arpa IN PTR merlin

indica que merlin denominado da máquina tem o endereço IP 147.120.0.7.

Os registros de recurso de Servidor de Nome apontam para o servidor de nome que tem a autoridade de uma determinada zona. Os registros de Name Server (NS) usam-se quando uma grande rede tem várias subredes, cada um com o seu próprio servidor de nome. Uma entrada parece a isto:

tpci.com   IN   NS  merlin.tpci.com

Este registro indica que o servidor DNS do domínio de tpci.com se chama merlin.tpci.com. Se houvesse várias subredes usadas em tpci.com, haveria um NS RR para cada subrede.

Concluir os arquivos DNS

Como viu antes, DNS usa vários arquivos para considerar que o recurso registra a descrição das zonas usadas por DNS. O primeiro arquivo do interesse é named.hosts, que contém o SOA, NS, e Um recurso registra. Todas as entradas no arquivo named.hosts devem começar na primeira posição de caráter de cada linha. Aqui está uma amostra named.hosts arquivo com comentários acrescentados para mostrar os registros:

; named.hosts files

; Start Of Authority RR

tpci.com.    IN    SOA     merlin.tpci.com

            root.merlin.tpci.com (

            2  ; Serial number

            7200 ; Refresh (2 hrs)

            3600 ; Retry (1 hr)

            151200 ; Expire (1 week)

            86400 ); min TTL

;

; Name Service RRs

tpci.com   IN   NS  merlin.tpci.com

subnet1.tpci.com IN NS goofy.subnet1.tpci.com

;

; Address RRs

artemis     IN     A    143.23.25.7

merlin      IN     A    143.23.25.9

windsor     IN     A    143.23.25.12

reverie     IN     A    143.23.25.23

bigcat      IN     A    143.23.25.43

pepper      IN     A    143.23.25.72

A primeira seção estabelece o recorde SOA, que define os parâmetros de TTL, vencimento, refresco, e assim por diante. Estabelece o servidor de nome do domínio de tpci.com a merlin.tpci.com. A segunda seção usa os registros de recurso NS para definir o servidor de nome do domínio de tpci.com como merlin.tpci.com (o mesmo como o SOA) e uma subrede de tpci chamou subnet1, para o qual o servidor de nome é goofy.subnet1.tpci.com. A terceira seção tem uma lista do nome de registro de endereço para o mapeamento de ENDEREÇO IP. Há uma entrada nesta seção de cada máquina na rede.

O arquivo named.rev fornece o mapeamento inverso do endereço IP para trabalhar a máquina o nome e compõe-se de registros de recurso de Ponteiro. O mesmo formato que o arquivo named.hosts segue-se, exceto a troca de nome e endereço IP e a conversão do endereço IP ao estilo de IN-ADDR-ARPA. O arquivo named.rev equivalente do arquivo named.hosts mostrado antes parece a isto:

; named.rev files

; Start Of Authority RR

23.143.in-addr.arpa    IN    SOA     merlin.tpci.com

            root.merlin.tpci.com (

            2  ; Serial number

            7200 ; Refresh (2 hrs)

            3600 ; Retry (1 hr)

            151200 ; Expire (1 week)

            86400 ); min TTL

;

; Name Service RRs

23.143.in-addr.arpa   IN   NS  merlin.tpci.com

100.23.143.in-addr.arpa   IN NS goofy.subnet1.tpci.com

;

; Address RRs

9.25.23.143.in-addr.arpa   IN   PTR merlin

12.25.23.143.in-addr.arpa  IN   PTR windsor

23.25.23.143.in-addr.arpa  IN   PTR reverie 

43.25.23.143.in-addr.arpa  IN   PTR bigcat

72.25.23.143.in-addr.arpa  IN   PTR pepper

Deve haver um arquivo named.rev separado de cada zona ou subdomínio na rede. Estes arquivos podem ter nomes diferentes ou colocar-se em diretórios diferentes. Se tiver só uma zona única, um arquivo named.rev é tudo que isto é necessário.

O arquivo named.local contém uma entrada do motorista de laço de retorno (que sempre tem o endereço IP 127.0.0.1). Este arquivo deve conter a informação sobre o mapeamento de IN-ADDR-ARPA do motorista de laço de retorno, bem como um domínio novamente (porque o arquivo named.rev não cobre a 127 subrede). Um arquivo named.local parece a isto:

; named.local files

; Start Of Authority RR

0.0.127.in-addr.arpa    IN    SOA     merlin.tpci.com

            root.merlin.tpci.com (

            2  ; Serial number

            7200 ; Refresh (2 hrs)

            3600 ; Retry (1 hr)

            151200 ; Expire (1 week)

            86400 ); min TTL

;

; Name Service RR

0.0.127.in-addr.arpa   IN   NS  merlin.tpci.com

;

; Address RR

1.0.0.127.in-addr.arpa   IN   PTR localhost

Este arquivo então provê o mapeamento da máquina denominou localhost ao endereço IP 127.0.0.1.

O arquivo named.ca usa-se para especificar servidores de nome a que o sistema pode recorrer. As máquinas especificadas no arquivo named.ca devem ser estáveis e não sujeitas à modificação rápida. Uma amostra named.ca arquivo parece a isto:

; named.ca

; servers for the root domain

;

.  99999999  IN   NS  ns.nic.ddn.mil.

   99999999  IN   NS  ns.nasa.gov.

   99999999  IN   NS  ns.internic.net

; servers by address

;

ns.nic.ddn.mil   99999999   IN  A  192.112.36.4

ns.nasa.gov      99999999   IN  A  192.52.195.10

ns.internic.net  99999999   IN  A  198.41.0.4

Neste arquivo só três servidores DNS especificaram-se. Um arquivo named.ca normal pode ter aproximadamente uma dúzia de servidores de nome, dependendo da sua proximidade do seu sistema. Pode adquirir uma lista cheia de servidores de nome de domínio de raiz válidos pelo FTP anônimo a nic.ddn.mil, no arquivo /netinfo/root-servers.txt. Este arquivo pode colar-se em named.ca. Os servidores especificados no arquivo named.ca identificam-se cada um por duas entradas. Cada um dá o domínio de raiz (o período) seguido do nome do servidor de nome; o outro tem o endereço IP de servidor de nome. O Tempo para Viver o campo estabelece-se muito grande porque se espera que estes servidores sempre estejam disponíveis.

O arquivo named.boot usa-se para provocar o carregamento dos demônios DNS e especificar os servidores de nome primários e secundários na rede. Uma amostra named.boot arquivo parece a isto:

; named.boot

directory    /usr/lib/named

primary    tpci.com    named.hosts

primary    25.143.in-addr.arpa    named.rev

primary    0.0.127.in-addr.arpa    named.local

cache    .    named.ca

A primeira linha do arquivo named.boot manda seguir o diretório de palavra-chave do diretório dos arquivos de configuração DNS. Cada depois da linha com a palavra-chave primária diz a DNS os arquivos que deve usar para encontrar a informação sobre configuração. A primeira linha, por exemplo, estabelece named.hosts como o arquivo para localizar o servidor primário de tpci.com. A informação IN-ADDR-ARPA guarda-se no arquivo named.rev para a 143,25 subrede. A informação localhost está em named.local, e finalmente o servidor e a informação sobre esconderijo sobre nome estão em named.ca.

Um servidor de nome secundário configura-se só ligeiramente diferentemente do que um servidor primário. A diferença está no arquivo named.boot, que aponta atrás para o servidor primário.

Começar os demônios DNS

O passo final na configuração DNS deve assegurar que o demônio DNS chamado denominado se carrega quando as botas de sistema UNIX. Isto faz-se normalmente pelas escritas de lançamento rc. A maior parte de versões de UNIX têm as rotinas do lançamento DNS já introduzido na escrita de lançamento, normalmente na forma de um cheque do arquivo named.boot. Se named.boot existe, o demônio DNS denominado partidas. O código normalmente parece a isto:

# Run DNS server if named.boot exists

if [ -f /etc/inet/named.boot -a -x /usr/sbin/in.named ]

then

   /usr/sbin/in.named

fi

Os caminhos diretivos exatos e as opções poderiam ser diferentes na sua escrita rc, mas a ordem deve verificar o arquivo named.boot e partida denominada se existir.

Configuração de um cliente

Configurar uma máquina UNIX para usar um servidor DNS primário para a resolução é um processo rápido. Em primeiro lugar, o arquivo/etc/resolv.conf modifica-se para incluir o endereço do servidor primário. Por exemplo, um arquivo resolv.conf poderia parecer a isto:

domain tpci.com

nameserver   143.25.0.1

nameserver   143.25.0.2

A primeira linha estabelece o nome de domínio, que se segue dos endereços IP de servidores de nome disponíveis. Este arquivo aponta para dois servidores de nome na 143,25 subrede.

Protocolo de BOOTP

TCP/IP tem de saber um endereço de Internet antes que possa comunicar-se com outras máquinas. Isto pode causar um problema quando uma máquina se carrega inicialmente ou não tem passeio de disco dedicado do seu próprio. No Dia 2, "TCP/IP e a Internet", viu como Reverse Address Resolution Protocol (RARP) pode usar-se para determinar um endereço IP, mas uma alternativa é de uso comum: o protocolo de alça ou BOOTP. BOOTP usa UDP para permitir a uma máquina diskless determinar o seu endereço IP sem usar RARP.

As máquinas de Diskless normalmente contêm a informação de lançamento nos seus BAILES PARA OS ESTUDANTES. Como estes devem guardar-se pequenos e consistentes entre muitos modelos de estações de trabalho diskless para reduzir preços, é impossível empacotar um protocolo completo como TCP/IP em um pedaço. Também é impossível embutir um endereço IP, porque o pedaço pode usar-se em muitas máquinas diferentes na mesma rede. Isto força uma estação de trabalho diskless recentemente calçada a determinar o seu próprio endereço IP de outras máquinas na rede. (Na prática, a máquina diskless também deve determinar o endereço IP do servidor de rede que usará, bem como o endereço do portão IP mais próximo.)

BOOTP supera alguns de problemas de RARP. RARP necessita o acesso direto ao hardware de rede, que pode causar problemas tratando com servidores. Também, RARP fornece a só um endereço IP. Quando os grandes pacotes devem enviar-se, isto desperdiça muito espaço que pode usar-se para a informação útil. BOOTP desenvolveu-se para usar UDP e pode implementar-se dentro de um programa aplicado. BOOTP também necessita que só um pacote único da informação forneça toda a informação que uma nova estação de trabalho diskless necessita para começar a operação. Por isso, BOOTP é mais eficiente e mais fácil desenvolver aplicações para, fazendo-o popular.

Para determinar o endereço IP de uma estação de trabalho diskless, BOOTP usa as capacidades de transmissão de IP. (Poderia lembrar que IP permite vários endereços de rede especiais que se transmitem a todas as máquinas na rede.) Isto deixa a estação de trabalho enviar uma mensagem mesmo quando não sabe o endereço de máquina de destino ou até o seu próprio.

---

IP transmitem endereços tal como 255.255.255.255 permitem a uma mensagem enviar-se a todas as máquinas em uma rede apesar de ter nenhuma fonte ou endereço de rede de destino.

---

BOOTP põe todas as tarefas de comunicações na estação de trabalho diskless. Especifica que todas as mensagens UDP enviaram sobre as somas de controle de uso de rede e que Não Fragmento mordeu estabelecer-se. Isto tende a reduzir o número de datagramas perdidos, interpretados mal, ou duplicados.

Para tratar a perda de uma mensagem, BOOTP usa um jogo simples de cronômetros. Quando uma mensagem se enviou, um cronômetro começa. Se nenhuma resposta se tenha recebido quando o cronômetro se esgota, a mensagem é ressentem-se. O protocolo estipula que o cronômetro se estabelece em um valor casual, que aumenta cada vez quando o cronômetro vence até que consiga um valor máximo, depois do qual se torna aleatório novamente. Isto previne o tráfego maciço depois que várias máquinas falham ao mesmo tempo e tentam transmitir mensagens BOOTP ao mesmo tempo.

BOOTP usa os termos cliente e servidor para referir-se a máquinas. O cliente é a máquina que inicia uma pergunta, e o servidor é a máquina que responde àquela pergunta. Destas definições, é fácil ver que o cliente e o servidor não têm relação física a nenhuma estação de trabalho, porque o papel de cada estação de trabalho pode modificar-se com o tráfego de mensagem. Como a maior parte de sistemas podem tratar múltiplos fios de tráfego de uma vez, é possível para uma máquina ser tanto cliente como um servidor simultaneamente.

---

Considerando papéis de cliente/servidor em BOOTP, lembre-se de que a máquina que envia a primeira mensagem é o cliente e a máquina que respostas é o servidor. Não há relação a termos de arquitetura de cliente/servidor.

---

Mensagens de BOOTP

As mensagens de BOOTP guardam-se em formatos fixos da simplicidade e permitir ao software BOOTP ajustar-se em um pequeno espaço dentro de um BAILE PARA OS ESTUDANTES. O formato de mensagens BOOTP mostra-se na Figura 11.9. O campo de OpCode usa-se para transmitir qualquer um pedido (jogo a um valor de 1) ou uma resposta (jogo a um valor de 2). O campo HTYPE indica o tipo de hardware de rede. O campo HLEN indica o comprimento de um endereço de hardware. (Estes dois campos últimos são thsame como em ARP.)

A figura 11.9. O formato de mensagem BOOTP.

O campo de PULOS guarda a pista do número de vezes que a mensagem se expede. Quando o cliente envia a mensagem de pedido, um valor de 0 põe-se no campo de PULOS. Se o servidor decidir expedir a mensagem a outra máquina, incrementa a conta de PULOS. (A expedição é necessária aperfeiçoando uma máquina através de mais de um portão.)

O Campo numérico Transacional é um número inteiro destinado pelo cliente à mensagem e é inalterado do pedido de responder. Isto permite combinar com as respostas ao pedido correto. O campo de Segundos é o número de segundos o cliente inicializou-se, destinou-se pelo cliente quando a mensagem se envia.

O campo de Endereço IP de Cliente preenche-se tanto quanto possível pelo cliente. Isto poderia resultar em um endereço de rede parcial ou nenhuma informação em absoluto, dependendo do conhecimento do cliente da rede na qual está. Qualquer informação que é desconhecida estabelece-se em 0 (portanto o campo poderia ser 0.0.0.0 se nada se conhece sobre o endereço de rede). Se o cliente quiser a informação de um determinado servidor, pode pôr o endereço do servidor no campo de Endereço IP de Servidor. Semelhantemente se o cliente sabe o nome do servidor, põe-no no campo de Nome do host de Servidor. O mesmo solicita outros campos de endereço. Se os campos se estabelecerem em 0, qualquer servidor pode responder. Se um servidor específico ou o portão se derem, só aquela máquina responde à mensagem.

O campo específico para o Vendedor usa-se, como o nome sugere, para a informação sobre implementação que é específica para cada vendedor. Este campo é opcional. Primeiros 32 bits definem o formato da informação restante. Estes primeiros bits conhecem-se como o biscoito mágico e têm um valor padrão de 99.120.83.99. Depois do biscoito mágico são os jogos da informação em um formato de três campos: um tipo, um comprimento e um valor. Há vários tipos identificados pela Internet RFC, como mostrado na Tabela 11.5. O campo de Comprimento não se usa para os tipos 0 e 255, mas deve estar presente para os tipos 1 e 2. O comprimento pode variar dependendo do número de entradas em outros tipos de mensagens.

Poderia lembrar-se de que uma máquina pode obter a máscara de subrede de uma mensagem ICMP, mas BOOTP é o método recomendado de obter este valor.

O campo de Nome de arquivo de Bota pode especificar um nome de arquivo do qual obter uma imagem de memória que permite a estação de trabalho diskless à bota propriamente. Isto poderia estabelecer-se pelos vendedores ou fornecer-se pelo servidor. Isto permite à imagem de memória obter-se de uma máquina enquanto os endereços reais se obtêm do outro. Se este campo se estabelecer em 0, o servidor seleciona a imagem de memória para enviar.

O processo da inicialização segue dois passos. O primeiro deve usar BOOTP para obter a informação sobre os endereços de rede do cliente e pelo menos uma outra máquina (um portão ou servidor). O segundo passo usa um protocolo diferente para obter uma imagem de memória do cliente.

---

Um processo de passo duplo usando dois protocolos diferentes usa-se para separar a configuração e carga de sistema operacional da máquina. O uso de dois protocolos permite a otimização de cada tarefa. Dois passos também se usam porque a máquina que responde à mensagem de cliente BOOTP não poderia ser a máquina que carrega da imagem de memória.

---

Network Time Protocol (NTP)

A regulação de tempo é muito importante para redes, não só para assegurar que os cronômetros internos se mantêm propriamente, mas também para a sincronização de relógios para enviar mensagens e timestamps dentro daquelas mensagens. Alguns sistemas confiam a tempo para o encaminhamento. A asseguração que os relógios de ponto são consistentes e exatos é uma tarefa muitas vezes contemplada do alto, mas permanece bastante importante mandar definir um procedimento formal por uma Internet RFC. O protocolo que mantém padrões de tempo chama-se o Protocolo de Tempo de Rede ou NTP. NTP pode usar TCP ou UDP; o porto 37 dedica-se a ele.

A operação de NTP confia na obtenção de um tempo exato de uma pergunta para um servidor de tempo primário, que ele mesmo adquire a sua informação sobre regulação de tempo de uma fonte de tempo padrão (como o Instituto Nacional de Padrões e Tecnologia nos Estados Unidos). O servidor de tempo questiona o relógio padrão (também chamou um mestre fonte que cronometra) e estabelece os seus próprios tempos no padrão.

Uma vez que o servidor de tempo primário tem um tempo exato, envia mensagens NTP a servidores de tempo secundários além disso fora nas interredes. Os servidores de tempo secundários podem comunicar-se com mais servidores de tempo secundários usando NTP, embora a exatidão se perca com cada comunicação devido à latência nas redes. Consequentemente, estas mensagens de tempo podem enviar-se a portões e máquinas individuais dentro de uma rede, se o administrador assim decidir. Normalmente cada rede tem pelo menos um servidor de tempo primário e um servidor secundário, embora as grandes redes pudessem ter vários de cada um.

O formato de mensagens NTP é simples, como mostrado na Figura 11.10. Vários campos de controle usam-se para procedimentos de atualização e sincronização, mas os detalhes destes campos não são importantes para esta discussão. A Distância Sincrônica ao campo Primário é uma estimativa do atraso de viagem de ida e volta incurso ao relógio primário. A carteira de identidade do servidor de tempo primário é o endereço da eleição prévia.

A figura 11.10. O formato de mensagem NTP.

Há vários timestamps na mensagem NTP. O Tempo o Relógio Local Atualizado é o tempo o relógio local do criador de mensagem atualizou-se. Originar timestamp é o tempo que a mensagem se enviou. Receber timestamp é o tempo recebeu-se. Transmitir timestamp é o tempo a mensagem transmitiu-se depois da recepção.

Todos os timestamps calculam-se de uma compensação do número de segundos desde primeiro de janeiro de 1900. Os campos timestamp são 64 bits, primeiros 32 bits de um número inteiro e os 32 últimos de uma fração. O campo de Autenticação final é opcional e pode usar-se para autenticar a mensagem.

Sumário

Viu agora como o Serviço de Nome de domínio trabalha. DNS é uma parte integrante e importante da maior parte de instalações TCP/IP, permitindo a nomes simbólicos resolver-se propriamente através de redes. O uso de servidores de nome explicou-se, bem como a maneira na qual os registros se guardam dentro dos servidores. Associado com DNS é o ARP e processo de resolução de nome de IN-ADDR-ARPA.

Hoje também olhei para o protocolo BOOTP, necessário para permitir a muitos terminais diskless e estações de trabalho unir-se à rede e carregar o seu sistema operacional. Sem BOOTP, precisaria tudo de computadores apresentados de maneira cheia ou estações de trabalho.

Perguntas e Respostas

Quais são os nomes de domínio superiores e quais são os seus objetivos?

Os domínios de alto nível são .arpa (específico para a Internet), .com (comercial), .edu (instituições de educação), .gov (governamental), .mil (forças armadas) e .org (organizações não-comerciais).

O que um DNS denomina o servidor fazem?

O servidor de nome de DNS dirige uma zona de máquinas e fornece a resolução de nome para todas as máquinas dentro daquela zona.

Se um servidor de nome não puder resolver um nome usando as suas próprias mesas, o que acontece?

As perguntas podem enviar-se da máquina que recebe a pergunta para outros servidores de nome para procurar uma resolução. Se outra máquina realmente tiver a resposta, não se devolve à máquina de investigação, de qualquer modo. Só o endereço da repessoa resolvida de nome com a resposta se devolve. A máquina de investigação então deve enviar uma pergunta específica à repessoa resolvida com a resposta.

Qual é a vantagem do formato de IN-ADDR-ARPA?

IN-ADDR-ARPA permite um mapeamento do endereço IP ao nome do host simbólico. Às vezes isto é um modo rápido de obter o nome simbólico de uma máquina de destino.

Porque faz uso de BOOTP UDP?

Simplesmente porque é mais pequeno para codificar. Embutir o código de TCP em um BAILE PARA OS ESTUDANTES tomaria muito mais quarto do que o código simples necessário para UDP.

Concurso

1. Que protocolo se usa por servidores de nome de DNS? Porque é uma boa escolha?
   


2. O que um recurso DNS é de registro?
   


3. Mostre uma entrada de mostra em um arquivo IN-ADDR-ARPA e explique o que os campos significam.
   


4. BOOTP ajuda uma bota de estação de trabalho diskless. Como adquire uma mensagem à rede procurando o seu endereço IP e a posição dos seus arquivos de bota de sistema operacional?
   


5. Qual é o Protocolo de Tempo de Rede? Porque se usa?