Capítulo 11. O Domain Name System

Índice
11.1. O que é o DNS?
11.2. Produzindo um caching server
11.3. Um name server para o domínio local
11.4. Os arquivos de configuração do named
11.5. Inicializar o name server

Neste capítulo nos ocuparemos do DNS (Domain Name System). Utilizando como exemplo a rede descrita no Capítulo 10, será configurado um name server local.

No Capítulo 10 vimos como elaborar os arquivos de configuração de uma rede local simples. Um dos problemas a enfrentar era a tradução dos nomes dos hosts da rede para endereços IP e vice-versa. No contexto daquele capítulo o problema foi resolvido utilizando-se o arquivo /etc/hosts, em que eram indicadas as correspondências entre hosts e endereços IP, e que deveria estar presente (e atualizado) em cada um dos hosts da própria rede. Por exemplo:

192.168.1.1	ape.insetti.net ape
192.168.1.2	vespa.insetti.net vespa  

Um outro arquivo, /etc/nsswitch.conf, indicava ao sistema a ordem em que consultar os recursos para resolver os nomes dos hosts.

HOSTS:    files dns  

Com este sistema o arquivo /etc/hosts era consultado primeiro e só em caso de malogro lançava-se mão do DNS. Uma vez que a rede não tinha seu próprio name server, eram utilizados os fornecidos pelo provedor, especificando-os no arquivo /etc/resolv.conf com a diretriz "nameserver". Na prática o arquivo /etc/hosts era usado para a resolução dos nomes na rede local (não visível ao exterior) e os servidores DNS do provedor permitiam resolver os nomes pertencentes à Internet.

Nota: com o termo resolver indica-se a conversão do nome em endereço IP e vice-versa.

A situação é ilustrada na Figura 11-1: ape é o gateway da rede e a diretriz nameserver dos arquivos /etc/resolv.conf de ambos os hosts apontam para o name server do provedor. Todas as interrogações DNS são endereçadas a este último. Os nomes dos hosts locais são resolvidos com o exame do arquivo /etc/hosts.

Figura 11-1. Uso do DNS do provedor

Neste capítulo veremos como preparar um servidor DNS local, sem necessidade de recorrermos aos servidores do provedor, que permita resolver todo tipo de nome, seja interno seja externo, e evitar o recurso ao arquivo hosts. Serão descritos dois tipos de abordagem, cujo significado será esclarecido no decorrer: um caching server e um servidor propriamente dito. O ambiente em que será configurado o name server será o mesmo daquele descrito no Capítulo 10.

A situação que se quer obter é ilustrada pela Figura 11-2. O name server encontra-se no host ape e é utilizado para resolver tanto os nomes internos quanto os externos. O arquivo /etc/resolv.conf do ape aponta para si mesmo, enquanto o do vespa aponta para o ape. O name server do provedor não será utilizado (exceto quando não usamos a diretriz forwarders ilustrada a seguir).

Figura 11-2. Uso do DNS interno

Nota: podemo-nos perguntar quando é oportuno seguir a abordagem descrita no Capítulo 10 e quando convém utilizar um servidor DNS próprio. Como em muitos outros casos, não existe uma resposta unívoca. Em geral, para computadores isolados ou para casos de redes locais muito simples, como aquela descrita anteriormente, que se apoiam no servidor DNS de um provedor, convém seguir a abordagem já descrita, reservando o uso de um servidor DNS próprio para situações mais complexas. Ao término da leitura do capítulo deveria estar suficientemente claro quando é que o uso de um servidor local pode ser mais cômodo.

11.1. O que é o DNS?

Quando se faz referência a um host é decididamente mais confortável utilizar um nome do tipo www.netbsd.org que um endereço IP numérico como 110.111.112.113. Em um nível de comunicação mais baixo, entretanto, não são usados os nomes mas os endereços em forma numérica. Parece, pois, evidente, a exigência de um serviço de tradução dos nomes em endereços numéricos e vice-versa. O DNS (Domain Name Server) é precisamente isto (e ainda algumas coisas mais). Trata-se de um banco de dados hierárquico e distribuído. Hierárquico significa que o espaço dos nomes dos hosts não é "chato", mas apresenta uma hierarquia dos nomes. Isso torna possível a existência de dois hosts com o mesmo nome, desde que pertençam a domínios diferentes. Se assim não fosse, poderia haver um só host de nome www conectado à Internet. Com uma estrutura hierárquica, www.netbsd.org e www.mydomain.org são dois hosts diferentes. Distribuído significa que o banco de dados não está inteiramente concentrado em um ponto (ou seja, não existe um host que conhece os nomes e os endereços de todos os outros hosts) mas "estilhaçado": cada servidor possui informações relativas ao próprio domínio. Portanto, para poder desenvolver a sua tarefa é necessário que os servidores possam por-se em contato entre si para trocar informações.

O aplicativo de referência no que diz respeito ao gerenciamento do DNS é o BIND (Berkeley Internet Name Domain System), um software distribuído livremente pelo ISC (Internet Software Consortium) que implementa o protocolo DNS. O BIND faz parte da distribuição básica do NetBSD e, portanto, não é necessário instalar nenhum software adicional. A distribuição do BIND compreende vários componentes, entre os quais o servidor DNS, representado pelo dæmon named e alguns programas utilitários como host, dig, nslookup e dnsquery. Ademais, fazem parte da distribuição do BIND também as funções de biblioteca para a resolução das queries do DNS.

11.1.1. Como funciona uma interrogação do DNS?

Para efetuar uma interrogação do DNS, um aplicativo contata um servidor DNS que provê, por sua vez, à contatação dos servidores responsáveis pelo domínio ao qual se refere o nome a ser resolvido. Na realidade, a interrogação segue um percurso de tipo hierárquico, partindo dos servidores de nível mais alto, os assim chamados root servers, até chegar ao nível de detalhamento desejado. Por exemplo, suponhamos querer encontrar o endereço IP de www.netbsd.org. Primeiro o nosso name server contata um root server que fornece os endereços dos servidores para o domínio "org" (org é um dos TLD, ou seja, Top Level Domain, que são os domínios de nível mais alto como "edu", "org", "com", etc.) Assim o nosso servidor contata um dos servidores para o domínio org, que por seu turno lhe fornece os endereços dos servidores para o domínio netbsd.org. Enfim o nosso servidor contata um dos servidores do netbsd.org para saber o endereço de www. Aqui conclui-se o ciclo de inquirições e respostas.

Este exemplo deveria ter esclarecido o que se entende por "hierárquico e distribuído". O nome do host foi analisado de acordo com uma hierarquia precisa e as interrogações foram realizadas dirigindo-se em cada momento aos servidores que tinham conhecimento de cada uma das suas várias partes.

11.2. Produzindo um caching server

Com o termo caching server entende-se um servidor que não gerencia em si mesmo a conversão dos nomes de host em endereços IP, mas sempre faz referência a outros servidores. A particularidade desse tipo de servidor é que memoriza as respostas que lhe chegam e se torna capaz, desse modo, de efetuar as interrogações posteriores mais velozmente. Já que um servidor desse tipo não gerencia os nomes internos da nossa rede, para obter os endereços daqueles nomes será ainda necessário fazer referência ao habitual arquivo /etc/hosts.

Como o NetBSD já fornece uma série de arquivos de configuração pré-definidos, a constituição de um servidor desse tipo é, para dizer pouco, elementar, como veremos em breve.

O servidor propriamente dito é constituído pelo dæmon named, que faz referência a um arquivo de configuração que por default é /etc/named.conf. Exemplo desse arquivo de configuração no NetBSD pode ser encontrado no diretório /etc/namedb e, como primeiro passo, criemos um link ao arquivo:

# ln -s /etc/namedb/named.conf /etc/named.conf    

O nosso name server está pronto para o uso. O passo seguinte será efetuar os testes para verificar-lhe o correto funcionamento mas, antes, devemos indicar ao sistema para usar o nosso servidor, inserindo no arquivo /etc/resolv.conf uma linha do tipo:

nameserver 127.0.0.1    

Nesse momento tudo está pronto para inicializar o named.

# named    

11.3. Um name server para o domínio local

No Secção 11.2 viu-se como estruturar um caching server, o que foi bastante simples. Experimentemos agora solicitar ao servidor algumas informações sobre um host da nossa rede local.

# nslookup
Default server: localhost
Address: 127.0.0.1

> ape.insetti.net
Server:  localhost
Address:  127.0.0.1

*** localhost can't find ape.insetti.net: Non-existent host/domain    

O servidor não sabe nada do nosso host local. De fato, os dados correspondentes ainda estão confinados no arquivo /etc/hosts, que não é consultado pelo servidor. Portanto o servidor de nomes efetua o habitual giro de interrogações partindo dos root servers, mas naturalmente não conclui nada. Isso não significa que a instalação do servidor esteja errada. Indica apenas que a resolução dos nomes locais poderá ser efetuada apenas por meio do arquivo /etc/hosts.

Na seqüência do capítulo será visto como fazer para o servidor de nomes gerenciar o nosso domínio local. Para fazer isso será necessário tanto modificar o named.conf como adicionar os arquivos de zona. Isto é, os arquivos que contêm os registros do DNS que descrevem os hosts (e outras características) da rede local. Na realidade, já estão presentes na configuração atual os arquivos de zona, que podem ser encontrados no diretório /etc/named.db. Sobre isto voltaremos em um segundo momento.

11.4. Os arquivos de configuração do named

O dæmon named lê dois tipos de arquivo de configuração. O primeiro, já citado, é o named.conf, que contém as opções de configuração do programa. O segundo tipo de arquivo é constituído pelos assim chamados arquivos de zona, que contêm os registros do DNS para os hosts da rede local. Os registros do DNS permitem transformar os nomes dos hosts em endereços IP e vice-versa, definir os servidores de correio e especificar muitas outras informações. Neste capítulo não serão descritos em detalhe nem o arquivo de configuração, nem os arquivos de zona. Vamo-nos limitar a apresentar e comentar exemplos que deveriam ser fáceis de modificar e adaptar.

11.4.1. Named.conf

O exemplo seguinte mostra uma configuração mínima para o arquivo named.conf. Grande parte do conteúdo já estava presente no arquivo por default do NetBSD. Apenas as linhas de 17 a 25 foram acrescentadas para gerenciar o domínio local.

Em uma primeira olhada já se nota que o arquivo está dividido em seções (ou mais precisamente statements) distintas, com os corpos das várias seções postos entre haspas. Vejamos agora em detalhe o significado das várias partes do arquivo (para uma descrição completa remete-se à página de manual named.conf(5).

Linha 1

As linhas que se iniciam com o caracter "#" são consideradas comentários e são ignoradas, assim como as linhas vazias. São reconhecidos também os comentários em estilo C e C++.

Linhas 3-5

A seção options controla as opções de configuração global do servidor e os defaults que serão usados nas outras seções do arquivo. A diretriz directory define o diretório de trabalho do servidor. Todos os percursos não absolutos presentes nas outras seções do arquivo de configuração serão interpretados como relativos a este diretório. Por exemplo, o arquivo root.cache (linha 7) será procurado em /etc/namedb/root.cache.

Linhas 7-10

Esta seção define uma zona. Trata-se de uma zona especial, pré-definida, contendo os já citados root servers dos quais partem as buscas. A diretriz hint indica que esta zona é precisamente a dos root servers e a linha 7 especifica o nome do arquivo em que se encontram os dados da zona (o arquivo foi cortesmente fornecido pelo NetBSD).

Linhas 12-15

Esta seção define a zona inversa local para o endereço de loopback (127.0.0.1). Ver a explicação das linhas 22-25.

Linhas 17-20

Definição da zona relativa ao domínio local. A opção "type master" indica que o servidor é o master server para esta zona, ou seja, é aquele que tem a cópia master do arquivo de zona (no arquivo indicado na linha 19). O arquivo de zona contém o registro do DNS para efetuar a conversão do nome do host para o endereço IP, assim como outras informações que serão examinadas em seguida.

Note-se que o nome da zona deve corresponder ao nome do domínio, enquanto o nome do arquivo que contém o registro do DNS é livre, mesmo se normalmente convém ater-se a alguma convenção.

Linhas 22-25

Estas linhas definem a zona inversa para o domínio local. Isto é, o arquivo que contém o registro do DNS para efetuar a conversão de endereço IP para nome do host. Mesmo nesse caso o servidor é do tipo master. A linha 24 indica o nome do arquivo que contém o registro do DNS.

O nome da zona merece uma explicação. A primeira parte é o endereço IP da rede escrito ao contrário (192.168.1 torna-se 1.168.192), enquanto que a segunda refere-se ao domínio pré-definido "in-addr.arpa" que serve para a resolução inversa, isto é, a transformação dos endereços IP em nomes.

A configuração do named.db terminou. Nas seções seguintes examinaremos o conteúdo dos arquivos de zona, descrevendo os registro do DNS. Os arquivos para as zonas "." e ".127" são pré-definidos e não exigem modificações. Portanto, não serão examinados. A sua estrutura é, mesmo assim, a mesma dos arquivos para o domínio local.

Antes de passar ao exame dos arquivos de zona, vejamos uma outra diretiva que pode ser inserida na seção options, ou seja: forwarders. Por exemplo:

options {
        directory "/etc/namedb";
        forwarders {
	        1.2.3.4;
		1.2.3.5;
        };
};      

No exemplo precedente suponha-se que 1.2.3.4 e 1.2.3.5 sejam o name server do provedor. O efeito desta configuração é que o nosso servidor efetuará as interrogações servindo-se dos name servers do provedor. Desse modo serão eles a se encarregar do caching das informações, ao invés do servidor local. No caso em que os forwarders não consigam responder a uma interrogação, então o servidor procurará encontrar a resposta por conta própria. Esta articulação reduz a carga de trabalho do servidor local, que se limita a gerenciar sozinho as zonas de que é master (em definitivo, o domínio local).

11.4.2. O arquivo para a zona insetti.net

Pelo modo como foi definido em named.conf, o arquivo para a zona insetti.net recebe o nome de /etc/namedb/insetti.net. O seu conteúdo é o seguinte:

1| ; Local hosts
 2|
 3| @	IN	SOA	ape.insetti.net. hostmaster.ape.insetti.net. (
 4| 				2000120301	; Serial
 5| 				3600		; Refresh
 6| 				300		; Retry
 7| 				3600000		; Expire
 8| 				3600 )		; Minimum
 9|		IN	NS	ape.insetti.net.
10|		IN	MX	10 ape
11| ape		IN	A	192.168.1.1
12| vespa	IN	A	192.168.1.2      

O arquivo é o verdadeiro banco de dados do DNS, contendo os registros de DNS. Na seqüência desta seção examinemos os registros presentes no arquivo.

Linha 1

Esta linha é um comentário.

Linhas 3-8

Este grupo de linhas define o registro SOA (Start Of Authority) que delimita o início de uma zona de autoridade. Cada zona tem um só registro SOA.

O caracter @ no início da linha é um sinônimo para o nome do domínio especificado na diretriz "zone" do arquivo named.conf e, assim, neste caso equivale a "insetti.net".

O subseqüente "IN" indica estar na Internet e define o tipo de rede.

Depois da SOA vêm, na ordem, o name server e o endereço de e-mail do responsável pela zona (no endereço de e-mail o caracter @, que para o DNS tem um significado particular, deve ser substituído por um ponto).

Linha 9

A linha 9 é um registro do tipo NS que indica qual é o name server autorizado para a zona. Pode haver mais de uma linha do tipo NS. Note-se que o nome termina com um ponto.

Linha 10

Esta linha contém um registro do tipo MX, que contribui para acelerar a transferência da correspondência indicando qual é (ou quais são) os servidores de correio da zona. O número "10" que aparece depois de NS exprime uma preferência: quanto menor for o número, maior será a preferência dada ao servidor. No caso da presença de vários registros MX, é utilizado em primeiro lugar o que tem o número mais baixo. Não importa o valor do número. Conta apenas a relação maior-menor com os números dos outros registros MX. No exemplo seguinte o mail hub ape será provado antes de vespa.

IN	MX  10 ape
	IN	MX  20 vespa	    

Note-se que como depois do nome do host não aparece o ponto, ao próprio nome será articulado o domínio.

Linhas 11-12

Finalmente chegamos aos registros que são usados para transformar os nomes dos hosts em endereços IP (mas não vice-versa: essa é a tarefa do arquivo para a zona 1.168.192). Os dois registros de tipo A associam os endereços aos nomes dos dois hosts da nossa rede. Se estivessem presentes outros hosts seriam adicionados outros registros A. Note-se que os nomes dos hosts não são seguidos de ponto.

11.4.3. O arquivo para a zona 1.168.192.in-addr.arpa

Segundo o que foi definido no named.conf, o arquivo para a zona 1.168.192.in-addr.arpa chama-se /etc/namedb/1.168.192. O seu conteúdo é o seguinte:

1| @	IN	SOA	ape.insetti.net. hostmaster.ape.insetti.net. (
 2|				2000120301	; Serial
 3| 				3600		; Refresh
 4| 				300		; Retry
 5| 				3600000		; Expire
 6| 				3600 )		; Minimum
 7| 	IN	NS	ape.insetti.net.
 8| 1	IN	PTR	ape.insetti.net.
 9| 2	IN	PTR	vespa.insetti.net.      

A primeira parte deste arquivo é de todo equivalente àquela do arquivo para a zona insetti.net e, portanto, não a examinaremos de novo. As únicas novidades são as linhas 8 e 9, que têm a função inversa ao registro A. Trata-se dos registros PTR, que permitem transformar os endereços IP em nomes de host. À luz de tudo o que foi dito até aqui, o seu significado deveria estar claro o suficiente. Note-se que os nomes dos hosts terminam em ponto.

No início da linha 8 aparece o número "1". Já que não está seguido de um ponto, o DNS o concatena ao nome da zona (1.168.192.IN-ADDR.ARPA), obtendo 1.1.168.192.IN-ADDR.ARPA, que é o endereço completo a ser resolvido. O mesmo discurso vale para a linha 9, onde se obtém 2.1.168.192.IN-ADDR.ARPA.

11.5. Inicializar o name server

O servidor se inicializa, como já foi explicado, pelo caching server. Se o servidor já estiver ativo, agora que os dados de configuração foram modificados é necessário reinicializá-lo, coisa que se efetua com o comando ndc (name dæmon control program).

# ndc reload    

Agora que o name server está ativo, não é mais necessário inserir os nomes dos hosts no arquivo /etc/hosts porque pensamos que o named vai resolver os nomes. Naturalmente todos os hosts da rede devem apontar para o name server usando o arquivo /etc/resolv.conf. Particularmente em ape teremos:

nameserver 127.0.0.1    

enquanto em vespa teremos:

nameserver 192.168.1.1