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.
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).
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.
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.
Nota: na coleção dos pacotes geralmente tem uma versão mais recente do BIND que a instalada no sistema. O uso desta versão usualmente não é necessária, a menos que existam exigências específicas.
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.
Nota: note-se que para o DNS a ordem hierárquica dos nomes procede da direita para a esquerda, ou seja, em www.netbsd.org, org é o nível mais alto (o TLD, aquele imediatamente abaixo dos root servers); netbsd pertence ao domínio org e www pertence ao domínio netbsd.org.
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.
Nota: o conteúdo e o número dos arquivos de configuração pode variar de acordo com a versão do NetBSD.
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
Nota: aqui o name server foi inicializado manualmente. Uma vez verificado o correto funcionamento é possível reinicializá-lo automaticamente no boot, agindo sobre a opção especificada do arquivo /etc/rc.conf.
Executamos o nslookup para examinar a situação e verificar o bom funcionamento do servidor.
# nslookup Default server: localhost Address: 127.0.0.1 >
Agora efetuemos uma inquirição a (a título de exemplo) www.mclink.it.
> www.mclink.it Server: localhost Address: 127.0.0.1 Name: www.mclink.it Address: 195.110.128.8
Repetindo a interrogação uma segunda vez, obtém-se um resultado ligeiramente diferente:
> www.mclink.it Server: localhost Address: 127.0.0.1 Non-authoritative answer: Name: www.mclink.it Address: 195.110.128.8
Como se vê, os dados são os mesmos mas agora apareceu a expressão "Non-authoritative answer", que indica que o servidor não saiu pela rede para descobrir o endereço, mas utilizou os dados que tinha guardado no cache (depósito) depois da primeira interrogação. A resposta não se origina, portanto, do servidor mestre do domínio mclink.it, como no caso precedente, mas do cache do nosso servidor.
Estes primeiros resultados nos confortam pelo bom funcionamento do servidor.
Pode ser uma boa ocasião para experimentar também o comando host.
# host www.mclink.it www.mclink.it has address 195.110.128.8
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.
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.
Nota: é possível que no arquivo named.conf fornecido com o NetBSD estejam presentes também outras seções, por exemplo IPv6.
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.
Nota: os números de linha e o caracter "|" no início de cada linha não fazem perte do arquivo e estão presentes apenas como referência.
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).
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++.
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.
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).
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.
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.
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.
Server master e server slave: No exemplo precedente o nosso servidor era do tipo master para todas as zonas. Isto é, era o servidor que possuia a cópia master dos arquivos de zona. Um servidor de tipo slave, ao contrário, possui uma cópia (réplica) dos arquivos de zona do master correspondente (que não é escrita a mão pelo administrador do sistema, como a cópia master). Entre o server master e o slave existem métodos de sincronização automática cuja descrição excede os objetivos dessa breve introdução.
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).
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.
Esta linha é um comentário.
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).
Nota: note-se que ambos os endereços precedentes terminam em um ponto. Todos os nomes não terminados em um ponto são considerados relativos ao domínio corrente e o servidor o completa acrescentando o domínio (@) no fim. Portanto, nos arquivos de zona é necessário prestar atenção em como se escrevem os nomes. Se, por exemplo, escrevemos "ape.insetti.net" (no lugar de "ape.insetti.net.") o servidor modifica internamente o nome para "ape.insetti.net.insetti.net", que certamente não é aquele que se quer obter.
O registro SOA continua, delimitado por parênteses, até a linha 8. A linha 4 define o número de série do arquivo. O número pode ser escolhido à vontade, com a condição de que seja atualizado cada vez que se modifica o arquivo de zona. Nesse caso foi escolhida uma codificação que se baseia na data da última modificação do arquivo, expressa no formato ano-mês-dia seguido de um número de série. Por exemplo, se o arquivo for novamente modificado em 03/12/2000 o número ficará 2000120302. Se houver modificação dois dias depois, o número ficará 2000120501. É muito importante lembrar-se de atualizar esse número de série quando se modifica o arquivo.
As linhas de 5 a 8 contêm os tempos em segundos que se referem à interação entre o master os seus slaves. Para os fins desta introdução não nos interessa examiná-la em detalhe e tomaremos por bons os valores definidos por default no exemplo.
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.
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.
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.
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.
In-addr.arpa: O domínio pré-definido (trata-se de um TLD) in-addr.arpa serve para transformar os endereços IP em nomes de host. No interior deste domínio os endereços IP devem ser escritos com as mesmas convenções dos nomes dos hosts, isto é, com a parte mais significativa à direita. Por esse motivo 192.168.1.2 torna-se 2.1.168.192.IN-ADDR.ARPA. Desse modo o BIND pode analisar esse nome exatamente como faz com os nomes dos hosts, procedendo da direita para a esquerda.
Nos exemplos precedentes foram inseridos nos arquivos de zona os registros estritamente necessários para o funcionamento da configuração que nos tínhamos proposto. Na realidade, existem muitos outros tipos de registro que permitem especificar em maior detalhe e com maior flexibilidade a estrutura da nossa rede. Na seqüência desta seção, vejamos alguns dos outros tipos de registro. Para uma descrição mais completa e aprofundada, entretanto, remete-se à literatura especializada.
Os registros CNAME servem para criar codinomes (alias) de nomes existentes, ou seja, atribuir nomes adicionais a um host. Por exemplo:
www IN CNAME ape ftp IN CNAME ape
Desse modo indicamos ao BIND que os nomes www e ftp fazem, ambos, referência ao host ape.
Os registros TXT servem para acrescentar texto descritivo aos registros de DNS. Por exemplo:
IN TXT "A minha rede local"
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