Administração de Redes GNU/Linux/DNS: Serviço de Nomes de Domínio
Este capítulo trata de um dos serviços mais fundamen1ais para o funcionamento da Internet, o serviço de nomes de domínio- DNS, que traduz nomes de hosts em números IP e vice-versa.
Obs.: este conteúdo está sendo migrado de: http://wiki.marceloakira.com/bin/view/GrupoLinux/ArtigoServidorDeNomes
Serviços de Nomes - DNS editar
O DNS - Domain Name Server - se enquadra nos principais serviços de redes TCP/IP. Como já mencionado antes, a finalidade do DNS é converter nomes como www.conectiva.com.br em endereços IP como 200.242.140.10. É importante salientar que o DNS faz também a resolução reversa, ou seja, converte endereços IP para nomes. Neste capítulo veremos como configurar um cliente DNS, e como transformar o Linux em um Servidor de Nomes.
Nos sistemas Linux existem duas técnicas para fazer resoluções, a primeira forma é através de uma tabela de hosts, a outra é feita através da consulta a um servidor de nomes (DNS). A tabela de hosts se refere ao arquivo de mapeamento /etc/hosts (para maiores informações, veja o primeiro capítulo). Por outro lado, o DNS é um banco de dados com servidores distribuídos e organizados de forma hierárquica, espalhados por toda Internet; de forma que todo servidor de nomes é também cliente de outro, pois caso um não consiga resolver um nome (traduzir para um número IP), este consultará outro e assim por diante.
O servidor de nomes padrão na maioria das distribuições de Linux é o software named que está incluso no pacote BIND - Berkeley Internet Name Domain. O pacote BIND, além do servidor DNS, oferece também: biblioteca em linguagem C para ser utilizada em clientes DNS chamada de biblioteca resolver; o utilitário para administração rndc - remote name daemon control program; e os utilitário host para consulta em servidores DNS.
Instalação do BIND editar
Há basicamente duas formas que podem ser utilizadas para instalar um sistema no Linux.
- 1.Instalação por pacotes. Um pacote de instalação é um conjunto de arquivos binários provenientes do código-fonte compilado para uma plataforma específica. Portanto, você deve utilizar o pacote específico para cada determinado sistema operacional, ou seja, para Linux existem os seus arquivos binários específicos e para outro sistema operacional existirão os seus pertinentes. A principal vantagem de se utilizar instalação por pacotes é a facilidade de instalação, pois não é necessário compilar e algumas vezes os arquivos já vem mais pré-configurados.
- 2.Compilar e instalar. Neste caso você deverá baixar o código fonte do programa, compilar e instalar. Geralmente estes programas vêm compactados e serão compilados através do comando make. Para cada programa você deve seguir as instruções dos arquivos README e INSTALL, estes arquivos geralmente vem junto ao código fonte. A principal vantagem da utilização de compilação de código-fonte para instalação são: maior flexibilidade de configuração e geralmente a versão do programa é superior à última versão existente disponível em por pacotes.
Instalação por pacotes editar
Em nossa instalação vamos utilizar a ferramenta APT (Advanced Packaging Tool). Através da ferramenta APT, podemos verificar que na distribuição Debian 4.0 (etch) existem os pacotes de interesse: bind, bind-dev, bind-doc, bind9, bind9-doc, bind9-host, libbind-dev, libbind9-0. Vejamos:
# aptitude search bind ... p bind - Internet Domain Name Server p bind-dev - libraries used by BIND p bind-doc - documentation for BIND p bind9 - Internet Domain Name Server p bind9-doc - Documentation for BIND p bind9-host - Version of 'host' bundled with BIND 9.X ...
Segue uma descrição de cada pacote:
- bind: servidor de nomes BIND, versão 8
- bind-dev: bibliotecas utilizadas pelo servidor de nomes BIND versão 8
- bind-doc: documentação para o servidor BIND versão 8
- bind9: servidor de nomes BIND, versão 9
- bind9-doc: documentação para o servidor BIND versão 9
- bind9-host: versão do utilitário 'host' para BIND versão 9
Note que você pode instalar a versão 8 ou versão 9 do BIND, adotaremos esta última.
→ Vejamos a seguir a instalação do pacote bind9:
# aptitude install bind9
O pacote bind9 traz os arquivos de configuração prontos para que o named possa ser rodado como um servidor de cache. Isto facilita a configuração do BIND, pois já é um bom começo para os outros tipos de configuração (servidor primário ou servidor secundário). Veremos mais adiante sobre os conceitos de servidor cache, primário e secundário mais adiante.
Uma vez feito isto, seu sistema está pronto para ser configurado.
Compilando e Instalando o BIND editar
→ Neste caso você deve ter o código fonte do software para compilar e instalar. A última versão do código fonte pode ser encontrada no site http://www.isc.org. Para instalar o BIND:
#cp bind-9.2.0.tar.gz /usr/local/src #cd /usr/local/src #tar xvfz bind-9.2.0.tar.gz #cd bind-9.2.0 #./configure --prefix=/usr/local/bind-9.2.0 #make #make install #ln -s /usr/local/bind-9.2.0 /usr/local/bind
Observe que neste exemplo foi utilizado o BIND 9.2. Estes conjuntos de comandos considera que o BIND será todo instalado no diretório /usr/local/bind-9.2.0; isto é realizado através da opção --prefix=/usr/local/bind-9.2.0 do comando ./configure. Esta pode ser uma boa estratégia, uma vez que isto ajuda na administração de seu servidor, pois facilita a identificação dos arquivos do BIND; se esta opção não fosse utilizada, seria executado o padrão, de instalar os arquivos espalhados e misturados com outros em /usr/local/bin, /usr/local/sbin, /usr/local/var, etc. Desta forma, os diretórios bin (executáveis), sbin (executáveis para uso do super-usuário), var (arquivos de banco de dados) e etc (arquivos de configuração) ficam todos abaixo de /usr/local/bind-9.2.0.
O comando make compila o código-fonte e o comando make install instala os binários compilados no diretório indicados.
O comando ln -s /usr/local/bind-9.2.0 /usr/local/bind cria um link simbólico chamado /usr/local/bind; este procedimento pode tornar a sua instalação mais versátil, pois caso seja necessário atualizar o BIND, você pode simplesmente atualizar o link para a versão mais nova. Assim os seus scripts de inicialização de serviços, por exemplo, podem fazer referência ao link (/usr/local/bind) em vez de um caminho da versão específica (/usr/local/bind-9.2.0), causando menos impacto ao atualizar uma versão.
→ Sempre que encontrar algum problema com a compilação e instalação, veja o arquivos README e INSTALL que acompanham o pacote.
Hierarquia editar
O DNS se baseia em um banco de dados distribuído, onde as informações são distribuídas em uma topologia em árvore, tudo começando de um ponto de partida. O processo da distribuição de informação é descrita assim, de forma simplificada: para que o DNS possa resolver nomes há um ponto de partida de pesquisa, a partir deste ponto, caso este não resolva o nome solicitado, a consulta é repassada para um dos servidores delegados por este servidor; caso o servidor delegado não resolva, ele irá repassar a consulta novamente para um outro servidor delegado por ele e assim por diante, até que seja encontrado definitivamente o servidor autorizado [authoritative server].
O ponto de partida para toda consulta de nomes é denominado domínio raiz, suportado por vários servidores raízes. Na verdade nenhum servidor raiz não responde diretamente à solicitação de resolução de um endereço. Em vez disso, ele delega a responsabilidade de resolver nomes para um outro servidor, delegando parte do domínio (um sub-domínio).
Os servidores raízes são denominados com um ponto ".", e estão no topo de todas as consultas, ou seja, são os primeiros servidores de DNS a serem consultados. Abaixo do "." há diversos Domínios de Alto Nível (TLDs - Top Level Domains). Sendo os mais conhecidos: o org, net, com e edu, de origem americana; alguns dos domínios fora dos Estados Unidos são também TLDs, e que denominam países e possuem somente duas letras, como br (Brasil), ar (Argentina), de (Alemanha); entre outros. Segue abaixo um diagrama desta hierarquia:
→ Os sub-domínios do domínio raiz, referentes à países são padronizados por órgão internacionais e podem ser consultados em: http://www.userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html.
Este diagrama nos mostra os servidores raízes no topo e os "sub-domínios" logo abaixo. Esta configuração nos lembra a árvore de diretório Linux, pois a partir do diretório / (raiz), podemos ir identificando os sub-diretórios até chegarmos no alvo desejado. O princípio da hierarquia DNS segue a mesma analogia.
Exemplo prático - Hierarquia DNS editar
Inúmeros aplicativos são clientes DNS (navegadores, clientes FTP, ping, etc). Por exemplo, Ao executar o comando:
ftp www.sistemasabertos.com.br
O DNS, que pode ser ou não a máquina local, consulta os servidores raízes sobre o sub-domínio br., que seria, comparado com a hierarquia de diretórios Linux, o sub-diretório do diretório raiz Linux; e caso este servidor conheça, o próximo passo é encontrar o com.br., assim acontece até atingir o servidor que realmente tem a autoridade do sub-domínio para resolver seus endereços IP.
Vamos exemplificar o conceito anteriormente explicado, simulando todos os passos que um DNS local faria para resolver um nome. Vejamos como isto ocorre, usando como exemplo o nome do host : www.sistemasabertos.com.br
Conforme explicado, nosso objetivo é encontrar qual é o servidor que definitivamente responde pelo endereço IP de www.sistemasabertos.com.br. Antes de realizar isto, verifique se sua máquina já está devidamente configurada como cliente DNS. Caso não esteja, veja o Capítulo 1 - Configuração Geral TCP/IP - ou veja o tópico configurando o Resolver (cliente DNS) neste capítulo.
Veja os primeiros passos iniciais:
- 1) o servidor local consulta o servidor raiz;
- 2) o servidor raiz fornece o(s) servidor(es) responsável(is) pelo domínio .br;
→ Para simular a consulta que o DNS local faz com o servidor raiz, utilizamos o comando dig, disponível no pacote dnsutils:
# aptitude install dnsutils
# dig -h
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]
Where: domain is in the Domain Name System
q-class is one of (in,hs,ch,...) [default: in]
q-type is one of (a,any,mx,ns,soa,hinfo,axfr,txt,...) [default:a]
(Use ixfr=version for type ixfr)
q-opt is one of:
-x dot-notation (shortcut for in-addr lookups)
-i (IP6.INT reverse IPv6 lookups)
-f filename (batch mode)
-b address[#port] (bind to source address/port)
-p port (specify port number)
-t type (specify query type)
-c class (specify query class)
-k keyfile (specify tsig key file)
-y name:key (specify named base64 tsig key)
-4 (use IPv4 query transport only)
-6 (use IPv6 query transport only)
d-opt is of the form +keyword[=value], where keyword is:
+[no]vc (TCP mode)
+[no]tcp (TCP mode, alternate syntax)
+time=### (Set query timeout) [5]
+tries=### (Set number of UDP attempts) [3]
+retry=### (Set number of UDP retries) [2]
...
global d-opts and servers (before host name) affect all queries.
local d-opts and servers (after host name) affect only that lookup.
-h (print help and exit)
-v (print version and exit)
Por padrão o host utiliza como DNS padrão de consulta (Default Server) o DNS indicado no arquivo /etc/resolv.conf, neste nosso altere para o próprio host (127.0.0.1):
# cat /etc/resolv.conf nameserver 127.0.0.1
→ Agora devemos consultar um servidor raiz sobre o domínio br, e para isto, eu preciso do endereço IP de um servidor raiz. Como eu poderia obter esta informação? Os criadores do DNS resolveram isto utilizando um arquivo estático, que pode ser atualizado manualmente (raramente é necessário), através de um arquivo que vem com o pacote BIND, denominado db.root, que também é conhecido como arquivo Hints. Este arquivo lista os nomes dos servidores raízes, e os seus respectivos números IP's, semelhante ao arquivo /etc/hosts. Uma vez consultado este arquivo, eu posso escolher um servidor entre os vários disponíveis para que eu possa realizar a consulta.
Antes de realizar consultas ao seu próprio DNS, vamos avaliar alguns arquivos que o pacote bind9 instalou em seu sistema:
# dpkg -L bind9 /etc/bind/db.root --> lista de DNS raízes /etc/bind/named.conf --> arquivo principal de configuração do BIND /etc/init.d/bind9 --> script de inicialização do BIND ... --> utilitários e documentação
Vamos agora analisar o conteúdo do arquivo /etc/bind/db.root:
# cat /etc/bind/db.root cat /etc/bind/db.root . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. ... . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 ... J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 L.ROOT-SERVERS.NET. 3600000 IN A 198.32.64.12 M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33
Isto pode ser comprovado pela consulta através do utilitário dig:
# dig . ns <--- preste atenção no ponto (.) ... ;; ANSWER SECTION: . 513025 IN NS f.root-servers.net. . 513025 IN NS g.root-servers.net. . 513025 IN NS h.root-servers.net. . 513025 IN NS i.root-servers.net. . 513025 IN NS j.root-servers.net. . 513025 IN NS k.root-servers.net. . 513025 IN NS l.root-servers.net. . 513025 IN NS m.root-servers.net. . 513025 IN NS a.root-servers.net. . 513025 IN NS b.root-servers.net. . 513025 IN NS c.root-servers.net. . 513025 IN NS d.root-servers.net. . 513025 IN NS e.root-servers.net. ;; ADDITIONAL SECTION: j.root-servers.net. 513025 IN A 192.58.128.30 j.root-servers.net. 513025 IN AAAA 2001:503:c27::2:30 l.root-servers.net. 513025 IN A 199.7.83.42 m.root-servers.net. 513025 IN A 202.12.27.33 m.root-servers.net. 513025 IN AAAA 2001:dc3::35 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) <--- o servidor consultado foi local ...
Note que o comando acima está realizando a seguinte consulta: "quais são os servidores de nomes para o domínio raiz (.)?".
A sintaxe do comando dig é assim:
dig [@servidor] name [tipo]
Onde:
- @servidor é um parâmetro opcional e indica o servidor no qual a consulta deve ser realizada. Por padrão o valor é o ip do servidor indicado em /etc/resolv.conf. O sinal arroba (@) precede o número ip do servidor, por exemplo: @127.0.0.1, @200.163.79.1, etc.
- name é o nome ou número IP a ser consultado.
- tipo é o tipo de consulta (NS=servidor de nome, MX=servidor de e-mail, A=endereço, etc). Por padrão o valor é "A". Você pode especificar este valor tanto em maiúscula (MX, por exemplo) ou mínuscula (mx, por exemplo).
→ A seguir devemos definir o tipo de pesquisa que desejamos fazer. Neste caso queremos fazer uma pesquisa em relação aos registros NS (registros de servidores de nomes), pois queremos achar o servidor de nomes autorizado que gerencia o ".br". Arbitrariamente podemos escolhemos o servidor a.root-servers.net como fonte de pesquisa, assim:
# dig @198.41.0.4 br. ns ... ;; QUESTION SECTION: ;br. IN NS ;; ANSWER SECTION: br. 86057 IN NS c.dns.br. br. 86057 IN NS d.dns.br. br. 86057 IN NS e.dns.br. br. 86057 IN NS a.dns.br. br. 86057 IN NS b.dns.br. ...
Note no comando acima, que o dig realiza uma pergunta: "quem é o servidor de nomes do domínio br.?" para o servidor raiz "a" de número IP 198.41.0.4
→ Assim como foi feito para o domínio br., faremos a consulta para o domínio com.br. Vamos primeiramente escolher um dos DNS para consulta. Vejamos:
# dig @198.41.0.4 c.dns.br <-- qual é o número IP do servidor c.dns.br? ;; ADDITIONAL SECTION: c.dns.br. 172800 IN A 200.192.232.10 # dig @200.192.232.10 com.br. ns ;; ANSWER SECTION: com.br. 86400 IN NS b.dns.br. com.br. 86400 IN NS c.dns.br. com.br. 86400 IN NS d.dns.br. com.br. 86400 IN NS e.dns.br. com.br. 86400 IN NS a.dns.br.
→ Observe que a própria máquina c.dns.br, além de responder pelo domínio br. também responde pelo domínio .com.br. Logo, podemos prosseguir a consulta usando o mesmo servidor definido anteriormente, agora para o domínio sistemasabertos.com.br.:
# dig @200.192.232.10 sistemasabertos.com.br. ns ... ;; AUTHORITY SECTION: sistemasabertos.com.br. 86400 IN NS intranet.sistemasabertos.com.br. sistemasabertos.com.br. 86400 IN NS ns1.xname.org. ...
Neste caso já descobrimos que o hospedeiro intranet.sistemasabertos.com.br é o servidor de nomes primário (é o primeiro da lista) pelo domínio sistemasabertos.com.br e seu endereço IP é 200.163.79.1. Observe que também existe outro hospedeiro responsável pelo domínio sistemasabertos.com.br, que é o hospedeiro ns1.xname.org,também denominada como o servidor secundário do domínio sistemasabertos.com.br.
→ Agora devemos prosseguir definindo o hospedeiro intranet.sistemasabertos.com.br como nosso servidor de consulta:
# dig @200.163.79.1 www.sistemasabertos.com.br ;; ANSWER SECTION: www.sistemasabertos.com.br. 79154 IN CNAME intranet.sistemasabertos.com.br. intranet.sistemasabertos.com.br. 79152 IN A 200.163.79.1
Logo, observamos que o nome www.sistemasabertos.com.br é apenas um apelido (alias) para a o nome canônico (real) do hospedeiro intranet.sistemasabertos.com.br, ou seja, ambas são a mesma máquina. Caso contrário, o comando retornaria simplesmente o endereço IP de www.sistemasabertos.com.br.
Concluindo, a partir de um servidor de nomes raiz conseguimos chegar ao endereço desejado e consequentemente conseguimos descobrir o endereço IP de www.sistemasabertos.com.br que é 200.163.79.1, além do DNS responsável por este nome, de mesmo número IP, mas de nome canônico (verdadeiro) intranet.sistemasabertos.com.br.
Cache de consultas editar
Um conceito também importante a ser compreendido, é que o servidor de nomes armazena todas as consultas realizadas em cache de memória por um período estipulado pelo fornecedor da consulta. Este período é denominado TTL (Time-To-Live, o qual será visto mais adiante), de forma que quando este tempo expira, a informação da consulta é retirada do próprio cache. Assim, quando o cliente necessita de uma informação, se o servidor de nomes já possui a consulta em cache, este não irá consultar seus superiores na hierarquia. Assim evita-se consultar um servidor raiz ou outro servidor acima na hierarquia em toda consulta, por exemplo.
O arquivo /etc/bind/db.root editar
→ Este arquivo contém uma lista de nomes de servidores raízes, espalhados em todo o mundo e é usado pelo seu servidor DNS como ponto de partida de consulta, como mostrado anteriormente. Você nunca deve editar ou modificar este arquivo, a não ser para atualizar suas informações que são raramente alteradas. Segue abaixo um exemplo deste arquivo:
... ;; ANSWER SECTION: . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 L.ROOT-SERVERS.NET. 3600000 IN A 198.32.64.12 M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33 ...
Este arquivo contém apenas registros de servidor de nome (NS) e de endereço (A). Cada um destes registros NS identifica um Servidor de Nome - Name Server - para o domínio raiz que é dominado com um (.) (isso mesmo, um ponto) . O registro A define o endereço IP dos Servidores de Nomes Raízes. Na instalação do Linux já é fornecido este arquivo. Para adquirir este arquivo basta fazer o download do arquivo /domain/named.root de ftp.rs.internic.net via ftp anônimo.
Configurando o Resolver (cliente DNS) editar
Conforme foi dito, o pacote BIND fornece uma biblioteca chamada resolver, que na verdade é também considerada o cliente DNS, pois é através dela é que vários programas que dependem da resolução de nomes faz suas operações para resolver nomes para número IP e vice-versa. Na prática, a configuração do cliente se resume em definir o servidor de DNS que será usado para fazer a resolução de nomes e definir a ordem de consulta aos métodos de resolução de nomes.
Definir o servidor de DNS editar
→ Para definir o servidor a ser consultado, deve-se editar o arquivo /etc/resolv.conf. Vejamos um exemplo do arquivo /etc/resolv.conf:
#cat /etc/resolv.conf search sistemasabertos.com.br nameserver 10.1.0.101 nameserver 10.1.0.102
Este arquivo contém entradas dos endereços IP de um ou mais servidores de nomes. Assim como entradas para busca de domínios de nomes.
→ A opção search é seu domínio de pesquisa padrão, ou seja, ao entrar com o host lab10 com o telnet:
#telnet lab10
será a mesma coisa que utilizar o seu nome completo de domínio, ou falando com mais rigor técnico, utilizar o nome de domínio totalmente qualificado (FQDN- Full Qualified Domain Name) do host:
#telnet lab10.sistemasabertos.com.br
Em outras palavras, ele tem este host como pertencente ao domínio padrão sistemasabertos.com.br.
O parâmetro "nameserver" define o endereço IP do servidor de nomes que a máquina irá utilizar para fazer consultas. Você pode ter várias entradas deste parâmetro, sendo que, somente quando o primeiro servidor de nomes definido no arquivo venha a falhar o outro será usado.
→ Se você estiver executando um servidor DNS na sua máquina e gostaria de usá-lo para consultas, entre com o endereço IP da máquina local ou o ip de loopback no arquivo /etc/resolv.conf:
nameserver 127.0.0.1
→ Para obter o IP do servidor de nomes de um determinado domínio, digite:
#dig dominio.com.br
→ Para maiores informações sobre o utilitário dig, execute man dig.
Definir a ordem de consulta editar
Percebemos pelo exemplo acima, que existem dois métodos de resoluções de nomes: o arquivo /etc/hosts e o DNS. Entretanto, qual será utilizado para resolver nomes primeiramente?
→ A resposta para esta pergunta está no arquivo /etc/host.conf. Vejamos um exemplo deste arquivo:
#cat /etc/host.conf order hosts,bind multi on
A diretiva order define a ordem de consulta , neste exemplo primeiramente será feito a consulta no arquivo(hosts) para somente depois consultar o DNS (bind) caso o arquivo não consiga resolver o nome. A opção multi on é exclusiva do arquivo /etc/hosts,esta permite que uma mesma máquina tenha múltiplos endereços Ips - o DNS por padrão já suporta esta opção.
Entendendo Zona e Domínio editar
No estudo de servidores de domínio surge o termo zona [zone] que é comumente confundida com o termo domínio. Antes de utilizarmos o termo zona, é importante definir e diferenciar cada um destes termos:
- Domínio: Define um espaço de nomes aonde encontra-se várias zonas.
- Zona: Uma zona é definida como uma região de um domínio, pode ser entendida como um sub-domínio. Por exemplo o domínio .br tem uma possível zona chamada com.br, enquanto esta zona pode ser um domínio para outras possíveis zonas como: sistemasabertos.com.br ou teste.com.br
→ Domínio e sub-domínio (zona) faz analogia com diretório e sub-diretório quando refere-se a sistemas de arquivo.
Servidores DNS editar
Existem basicamente três tipos de servidores DNS, o servidor caching [caching-server], o servidor primário [master server] e o servidor secundário [slave server].
- Servidor caching [caching-server]: Definido com um servidor que guarda em cache consultas que já foram anteriormente solicitadas, de forma a melhorar a performance da resolução de nomes. Este tipo de servidor também é definido como um servidor que é capaz apenas de fazer consultas para resolver endereços , ou seja, ele é um servidor destinado a fazer e guardar consultas, não sendo responsável por nenhuma zona.
- Servidor Primário [master server]: Definido como um servidor autorizado (servidor que tem autoridade sobre uma zona), ou seja, que mantém a base de dados de um determinada zona. Este servidor além de fazer consulta a servidores raízes também é consultado por outros servidores DNS como responsável (autorizado) pela zona em que foi delegada.
- Servidor Secundário [slave server]: Este servidor é definido como uma cópia do servidor primário [master]. É utilizado pelos clientes quando o servidor master, por algum motivo, pára de funcionar.
Para configurar um servidor é necessário certificar-se que o pacote BIND - Berkeley Internet Name Domain esteja instalado. O DNS BIND é um sistema cliente/servidor. O cliente utiliza uma biblioteca padrão para consultas DNS chamado de resolver que formula as solicitações para o servidor de nomes. O servidor de nomes é um processo daemon chamado named.
Cinco tipos de arquivos diferentes são necessários para a configuração do named. Todas as configurações requerem estes dois arquivos básicos:
- Arquivo de configuração principal (por padrão named.conf): Define parâmetros básicos e aponta para as fontes de informação do banco de dados do domínio, estes podem ser arquivos locais ou servidores remotos. Os próprios dois arquivos citados abaixo (hints e localhost reverso) são exemplos de arquivos de banco de dados; e para cada nova zona, dois arquivos são criados: arquivo de zona e zona reversa, o que veremos mais detalhadamente abaixo.
- Arquivo Hints (por padrão /etc/bind/db.root): fornece, como já visto, os nomes e endereços dos servidores de nomes raízes (root-server).
Existem mais outros arquivos que são utilizados para configurar o master server. Estes arquivos definem o banco de dados do domínio:
- Arquivo zone [arquivo de zona]: É usado para mapear nomes de hospedeiros para endereços IP, para identificar servidores de mensagem e para fornecer uma variedade de outras informações de domínio. É neste arquivo que é referenciado um host a um endereço IP. Este arquivo é similar a uma lista telefônica, pois para cada pessoa é atribuído um número de telefone. Como estamos tratando de máquinas e endereços IP, para cada máquina será atribuído um endereço IP.
- Arquivo reverse zone [arquivo de zona reversa]: Este arquivo é utilizado para mapear endereços IPs para nomes de hosts . Este arquivo faz o serviço contrário do arquivo zone, pois a partir deste arquivo é possível descobrir o nome do hospedeiro [hostname] através de seu endereço IP.
Configurando um servidor de cache editar
Este servidor necessita de três arquivos de configuração: configuração principal (named.conf), arquivo hints (db.root) e localhost reverso (db.127). Na verdade, todos estes arquivos já vem pré-configurados, quando se instala o pacote bind9.
Vejamos a configuração padrão de instalação destes arquivos:
O arquivo named.conf editar
O arquivo named.conf, tem uma sintaxe baseada em sentenças [statements], com opções para cada sentença em um bloco delimitado por chaves ({}). Cada opção também tem uma sintaxe específica para determinar seus argumentos. Os arquivos de configuração do BIND, suporta comentários em bloco, no estilo C++ (/* comentário */); comentários de linha, no estilo C++ (// comentário); comentários no estilo perl ou bash (# comentário); e finalmente, comentários de linha utilizando-se ponto-e-vírgula no início do comentário (; comentário). Veja como é a estrutura deste arquivo:
/* Este é um bloco de comentário,
estilo C++ */
<sentença1> <argumentos_sentença1> {
// Isto também é um comentário, mas de somente uma linha. Estilo C++
<opção1> <argumentos1>;
<opção2> <argumentos2>;
};
<sentença2> <argumentos_sentença2> { ; isto também é um comentário
# esta também é outra opção de comentário. Estilo bash ou perl.
<opção1> <argumentos1>;
<opção2> <argumentos2>;
}
...
Veja também um exemplo concreto, do arquivo padrão, para a versão BIND versão 9:
#cat /etc/named.conf
include "/etc/bind/named.conf.options";
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
// zone "com" { type delegation-only; };
// zone "net" { type delegation-only; };
// From the release notes:
// Because many of our users are uncomfortable receiving undelegated answers
// from root or top level domains, other than a few for whom that behaviour
// has been trusted and expected for quite some length of time, we have now
// introduced the "root-delegations-only" feature which applies delegation-only
// logic to all top level domains, and to the root domain. An exception list
// should be specified, including "MUSEUM" and "DE", and any other top level
// domains from whom undelegated responses are expected and trusted.
// root-delegation-only exclude { "DE"; "MUSEUM"; };
include "/etc/bind/named.conf.local";
Note neste arquivo a existência das sentenças [statements] options, zone (usada várias vezes), key e controls. Vejamos analisar cada um separadamente.
Sentença include/options editar
A sentença include permite incluir arquivos externos no arquivo principal como se o conteúdo do arquivo estivesse presente no próprio arquivo. Vejamos o conteúdo do arquivo /etc/bind/named.conf.options:
# cat /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.
// query-source address * port 53;
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
Note que o arquivo basicamente define um bloco 'options', que tem opções válidas para todo o servidor de nomes, servindo para definir parâmetros gerais. Veja a função de cada uma das opções:
- directory: Define qual é o diretório padrão onde os arquivos de banco de dados são armazenados. Note no exemplo, que temos como argumento desta opção o diretório /var/cache/bind, isto significa que quando especificamos uma opção da sentença zone assim: file "db.exemplo" estamos referenciando na verdade, o arquivo /var/cache/bind/db.exemplo.
- dump-file: Define qual é o arquivo para o qual será realizado um dump das consultas em cache. Como foi dito anteriormente, as consultas de um servidor de nomes permanecem em cache de memória. Se você desejar realizar uma cópia do conteúdo do cache em arquivo, você deverá fazer uma operação de "dump", através do comando rndc dumpdb.
- statistics-file: Define qual é o arquivo que irá conter informações de estatísticas de uso do servidor de nomes. Este arquivo é criado quando se solicita a geração de estatísticas, através do comando rndc stats.
- memstatistics-file: Define qual é o arquivo que irá conter informações de uso de memória do servidor de nomes. Esta opção, apesar de aparecer por padrão, ainda não está implementada.
- listen-on: A partir da versão 9.0 do BIND o arquivo named.conf vem pré-configurado com a diretiva listen-on. Esta diretiva define quais clientes pode consultar o servidor DNS. Por padrão vem configurado para aceitar consultas apenas locais (127.0.0.1/32). Para permitir que todos tenham acesso ao servidor DNS, comente esta opção. Para permitir que apenas máquinas de sua rede consulte o servidor DNS, adicione o endereço de rede a esta diretiva. Por exemplo: considerando que você esteja em uma rede 10.1.0.0/16, a diretiva ficará da seguinte forma: listen-on { 127.0.0.1/32; 10.1.0.0/16;};
Sentença zone editar
A sentença zone define uma zona que o servidor de nomes responde. Os principais tipos de zona são:
- master: zona a partir do qual o servidor mantém os dados originais e portanto, pode oferecer respostas autorizadas sobre estas informações. As informações são obtidas a partir de um arquivo de zona.
- slave: zona da qual o servidor mantém uma cópia dos dados originais de um servidor. As informações da zona são obtidas a partir de outro servidor.
- hint: zona que serve para informar quais são os servidores raízes. Esta informação é obtida de um arquivo Hints (por padrão, o arquivo é /etc/bind/db.root).
A zona denominada com um "." é obrigatória, e indica a zona de tipo hint, e o arquivo que contém os dados dos servidores de nomes raízes é indicado pela opção file "db.root"; enquanto que a zona denominada "0;0.0.127.in-addr.arpa" indica uma zona definida como master e serve para indicar o arquivo de localhost reverso.
Sentença key editar
Define uma chave criptográfica [secret] que pode ser utilizada em comum entre dois servidores, para se estabelecer uma comunicação segura.
A partir da versão 9.0, surgiu um novo suporte ao BIND para transações entre servidores, de forma mais segura. Este suporte veio através da sentença key, que define através de opções, uma chave secreta [secret] criptografado, juntamente com o tipo de algoritmo de criptografia. Assim, toda comunicação entre dois servidores pode ser utilizada esta chave [key] criptográfica, compartilhada entre os dois servidores, que é utilizada para assinar digitalmente uma mensagem de um servidor de nomes para outro. Isto pode ser muito útil para assegurar a comunicação entre o servidor primário e o secundário, em uma operação de transferência de zona, por exemplo.
Para saber mais como utilizar estes recursos de segurança, veja o "Manual do Administrador do BIND - versão 9" e veja seção 4.4 - TSIG - Transaction SIGnatures, pois por enquanto, ainda não mostraremos como utilizar este recurso de comunicação segura.
→ O valor "hmac-md5" para a opção algorithm é a único algoritmo criptográfico suportado no momento.
Sentença controls editar
A sentença controls define canais onde se pode utilizar o utilitário rndc. O utilitário rndc é um acrônimo para Remote Name Daemon Control, que permite controlar um DNS remotamente. Uma sintaxe simplificada desta sentença é:
controls {
inet <endereco_ip> <porta> allow { <lista_clientes> } keys { <lista_chaves> }
};
Onde:
- endereco_ip: é o endereço ip do servidor DNS onde os clientes poderão conectar (é possível que o seu servidor tenha mais de uma interface de rede, portanto, ter mais de um endereço ip). Um asterisco (*) denominaria todas as interfaces.
- porta: define uma porta (o padrão é a porta 953) onde será permitido que clientes remotos conectem.
- lista_clientes: define uma lista separada por ponto-e-vírgula de clientes (pode ser o FQDN do cliente ou o número IP) que podem utilizar o comando rndc.
- lista_chaves: define a lista de chaves que os clientes poderão utilizar para estabelecerem a comunicação segura.
No nosso exemplo, o valor de endereco_ip é 127.0.0.1; o valor de porta é padrão; o valor de lista_clientes é localhost; e o valor de lista_chaves é a chave key_rndc, definida anteriormente. Isto significa que o DNS irá permitir conexões de clientes pelo IP 127.0.0.1, na porta 953, permitindo somente o cliente localhost (ele próprio), utilizando a chave key_rndc. Em outras palavras, o DNS permite utilizar o comando rndc localmente.
→ o utilitário rndc é um utilitário para administração do BIND, que surgiu a partir do BIND versão 9, antes desta versão o utilitário era denominado ndc, e podia administrar somente localmente o servidor de nomes.
É importante saber que existem outras possíveis opções para cada sentença, também inclusive com outras sentenças não constantes neste arquivo padrão. Se você desejar saber mais, indicamos o "Manual de referência do Administrador do BIND 9", com endereço disponível na seção de links indicados deste capítulo.
O arquivo db.root editar
Como foi dito, o arquivo db.root é o arquivo hints, que possui o endereço dos servidores raízes, com seus respectivos endereços IP. Um exemplo deste arquivo já foi mostrado anteriormente .
O arquivo db.127 editar
→ Como foi dito, o arquivo db.127 é o arquivo localhost reverso, que permite que clientes resolvam o número IP 127.0.0.1 como o nome localhost. Mais a frente iremos explicar detalhadamente a sintaxe deste arquivo. Por enquanto, só o apresentaremos como é o padrão:
# cat /etc/bind/db.127 @ IN SOA localhost. root.localhost. ( 1997022700 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum @ IN NS localhost. 1 IN PTR localhost.
→ Resumindo, a única configuração a ser feita é a alteração da diretiva listen-on do arquivo named.conf, caso queira permitir que clientes consultem seu servidor. Agora você deve inicializar o daemon do DNS, portanto, execute:
#/etc/rc.d/init.d/bind restart
→ A este ponto seu servidor estará respondendo a solicitações de cliente, basta configurar um cliente e testar. Você até pode definir seu próprio servidor como cliente de si mesmo . Para isto edite o arquivo /etc/resolv.conf e deixe da seguinte forma:
# cat /etc/resolv.conf search sistemasabertos.com.br nameserver 127.0.0.1
Observe que foi utilizado o endereço de loopback para indicar a própria máquina. Para testar a configuração, basta utilizar o dig para fazer consultas ao servidor.
→ Não é uma obrigação fazer está última configuração, mas caso queira utilizar o DNS, você deverá fazer esta configuração tanto nos clientes como no Servidor.
→ Para testar o servidor de cache, execute:
# dig www.ufg.br ... ;; QUESTION SECTION: ;www.ufg.br. IN A ;; ANSWER SECTION: www.ufg.br. 3600 IN A 200.137.221.69 ;; AUTHORITY SECTION: ufg.br. 3600 IN NS ns.ufg.br. ufg.br. 3600 IN NS ns2.ufg.br. ...
Observe que o servidor de cache retornou o endereço que solicitamos: www.ufg.br tem endereço 200.137.192.69. Para qualquer nome que existe na Internet o servidor de cache irá conseguir fornecer, pois este consulta os servidores raízes que por sua vez delega suas consultas para o servidores responsáveis por determinado domínio. Estes servidores responsáveis irão retornar o endereço IP que se deseja. Porém você não conseguirá resolver nomes de máquinas de sua rede. Para resolver nomes de seus hosts você precisará criar o seu próprio servidor primário.
→ O cache dos servidores DNS armazenam as resoluções de nome em memória e tem um prazo de expiração definido em cada registro de recurso - RR- (Será explicado no próximo tópico) , assim se uma nova máquina fazer uma outra pesquisa sobre o endereço www.ufg.br, o servidor de cache responderá sem fazer nova pesquisa aos servidores raízes.
Configuração do servidor Primário editar
Toda configuração apresentada a seguir é característica do BIND 9.0. Estaremos usando como exemplo a máquina lab1.sistemasabertos.com.br para fazer a configuração do servidor primário. O arquivo /etc/bind/named.conf desta máquina deve estar da seguinte forma:
include "/etc/bind/named.conf.options";
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
// zone "com" { type delegation-only; };
// zone "net" { type delegation-only; };
// From the release notes:
// Because many of our users are uncomfortable receiving undelegated answers
// from root or top level domains, other than a few for whom that behaviour
// has been trusted and expected for quite some length of time, we have now
// introduced the "root-delegations-only" feature which applies delegation-only
// logic to all top level domains, and to the root domain. An exception list
// should be specified, including "MUSEUM" and "DE", and any other top level
// domains from whom undelegated responses are expected and trusted.
// root-delegation-only exclude { "DE"; "MUSEUM"; };
include "/etc/bind/named.conf.local";
Veja que no final do arquivo existe um arquivo que é incluído através da diretiva include. O ideal é inserir nossas configurações locais neste arquivo, pois mantemos as configurações essenciais do sistema no arquivo /etc/bind/named.conf e inserimos nossas configurações em /etc/bind/named.conf.local:
# vi /etc/bind/named.conf.local
zone "sistemasabertos.com.br" {
type master;
file "db.sa";
};
zone "1.10.in-addr.arpa" {
type master;
file "db.10.1";
};
→ estamos considerando que você tenha um domínio na Internet e quer registrá-lo. Para maiores informações de como registrar um domínio veja o endereço http://www.registro.br. Este endereço pertence a FAPESP - orgão que responsável pela domínio .br. Para outros domínios existem outros órgãos.
Nesta nova configuração do arquivo surgem novas zonas definidas, as zonas sistemasabertos.com.br e a 1.10.in-addr.arpa. Podemos observar também a ocorrência da instrução file que define o arquivo da base de dados de domínio. Nesta base de dados se encontra os RRs - Registro de Recurso - do DNS. Estes RRs definem servidores de nomes, endereço IP de hosts, etc, para isto existem vários tipos de registros que veremos ao criar os arquivos de banco de dados primário.
Logo, devemos criar os arquivos da base de dados db.sa e db.10.1, para isso você deverá entender a sintaxe e o propósito dos registros do banco de dados.
→ Observe que a zona reversa 1.10.in-addr.arpa identifica o endereço de rede de trás para frente. Lembrando que estamos considerando que o servidor está na rede 10.1.0.0/16. Caso o endereço de rede fosse 200.137.4.0/24, a zona reversa para esta rede será 4.137.200.in-addr.arpa.
Registros de Recursos DNS editar
Os Registros de Recursos - RR - DNS tem o seguintes formato:
[name] [ttl] IN type data
Onde:
- name: Identifica o objeto de domínio afetado por este registro. Pode ser um host individual ou domínio inteiro.
- ttl: Este campo é chamado de time-to-live, que define a duração em segundos que este registro de recurso deve ser mantido em memória (cache) por outros servidores DNS externos que fizerem consulta a este servidor DNS. Um valor TTL baixo é adequado para RR's com maior freqüência de mudança. A contrapartida para um TTL muito baixo é um aumento de tráfego de rede para este servidor. Por exemplo, alguns servidores definem alguns valores TTL como zero, fazendo com que servidores DNS externos não armazenem a consulta em cache; em outros casos, um valor de 43200 (12 horas) é razoável, fazendo com que um servidor externo mantenha uma contagem regressiva da consulta realizada em cache, por 43200 segundos, até expirar e ser retirada do cache.
- class: Existem três valores possíveis para este campo: IN, HS, CH. Atualmente é utilizado apenas o IN que é característico de redes TCP/IP e servidores Internet. Os outros dois possíveis valores , respectivamente classes HESIOD e CHAOS são padrões antigos de redes desenvolvido pelo MIT (Massachussets Institute of Technology) e que não são utilizados na Internet .
- type: Este campo define o tipo do registro fonte. Veja abaixo os mais comuns.
| Nome do Registro | Tipo de Registro | Função |
|---|---|---|
| Início de Autoridade [Start Of Authority] | SOA | Marca o começo dos dados de zona e define parâmetros globais |
| Servidor de Nomes e Domínio [Name Server] | NS | Identifica um servidor de nomes autorizado. |
| Endereço [Address] | A | Converte nome de hospedeiro - host - para endereço IP |
| Ponteiro [Pointer] | PTR | Converte endereço IP para um nome de hospedeiro-host. |
| Mail Exchanger [Repassador de email] | MX | Identifica o servidor de email para este domínio |
- data: Este último campo no registro de recurso é o campo de dados, o mesmo comporta os dados que são específicos para cada tipo de registro de recurso, ou seja, cada formato e dado deste campo é diferente para cada tipo de registro, exemplo: em um tipo de registro A o campo data deve conter o endereço IP.
O arquivo de Registro de Recurso de domínio editar
Sua finalidade primordial é converter nomes de hosts em endereços IP.
Continuando com o nosso exemplo, na máquina lab1 que será o servidor execute os seguintes passos:
→ 1.Crie o arquivo com nome referente a instrução file que está na zona sistemasabertos.com.br. Logo o arquivo deve ser criado no diretório /var/cache/bind e deve conter o nome db.sa.
$TTL 43200 @ IN SOA lab1.sistemasabertos.com.br. root.sistemasabertos.com.br. ( 2001032802 ; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN MX 5 lab1.sistemasabertos.com.br. @ IN NS lab1.sistemasabertos.com.br. @ IN NS lab2.sistemasabertos.com.br. lab1 IN A 10.1.0.101 lab2 IN A 10.1.0.102 lab3 IN A 10.1.0.103 lab4 IN A 10.1.0.104 lab5 IN A 10.1.0.105 lab6 IN A 10.1.0.106 lab7 IN A 10.1.0.107 www IN CNAME lab1
Nas versões mais recentes do BIND, foi acrescentado a possibilidade de se declarar diretivas. As diretivas são de sintaxe $DIRETIVA <valor> e são declaradas na primeira linha do arquivo de zona. Na primeira linha temos como primeiro caso o parâmetro $TTL 43200. Esta entrada define o tempo de vida padrão para os registro de recursos que vierem definidos no arquivo. Em seguida teremos os registro de recursos, na sintaxe definida anteriormente.
→ Configurando o arquivo da zona direta sistemasabertos.com.br
Aproveitando a sintaxe do arquivo da zona localhost db.local:
# cp db.local db.sa
editando:
# vi db.sa ; ; BIND data file for local loopback interface ; $TTL 604800 @ IN SOA localhost. root.localhost. ( ########## ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS localhost. @ IN A 127.0.0.1 lab5 IN A 10.1.0.105 lab6 IN A 10.1.0.106
Registro SOA - Definindo informações sobre a autoridade editar
O parâmetro @ faz referência ao domínio da zona definido no arquivo /etc/named.conf, ou seja, ele se refere ao domínio sistemasabertos.com.br. Outro parâmetro desta linha define o inicio de autoridade - SOA -, o nome de máquina lab1.sistemasabertos.com.br define o servidor que tem "Autoridade sobre a zona". Já root.sistemasabertos.com.br define o endereço de e-mail da pessoa responsável por este domínio, neste arquivo o @ do email é substituído um (.), pois como visto, o @ tem outra finalidade.
Em seguida temos:
- 2001032802: Este é o número serial que diz ao servidor slave se este arquivo de registro de recurso foi atualizado. Toda vez que você atualizar o DNS, você deve alterar este número para um número maior, pois assim o DNS secundário fará a sua atualização dinamicamente (vide servidor sencundário) . O slave [servidor secundário] checa periodicamente o inicio de autoridade SOA e compara o seu número serial com o servidor, se o seu número serial for menor, ele será atualizado. Por isso ao alterar o banco de dados devemos incrementar o número serial. Este número segue uma lógica: os primeiros 4 (quatro) números define o ano da última alteração que neste caso é 2001, o próximo dois números define o mês que neste caso é o mês de março - 03 -, os dois que se seguem é o dia do mês, os últimos dois números são utilizados para saber a quantidade de atualizações já feitas, ou seja, para cada alteração deste arquivo, este número constituído por dois algarismos deve ser incrementado. Observe que seguindo esta lógica, nenhuma data futura representada desta forma produzirá um número serial menor do que para uma data anterior , assim você tem controle da data de última atualização e também da quantidade de atualizações. Está é apenas uma forma inteligente de se ter controle sobre as atualizações, podendo ser utilizado outras maneiras.
- 3600: Este é o período em segundos que o slave [servidor secundário] utiliza para verificar periodicamente o número serial e consequentemente fazer a atualização, esta atualização só é feita caso o número serial do slave seja menor que número serial do servidor.
- 900: Este é o ciclo de tentativas. O ciclo de tentativas determina o tempo que o servidor slave deve esperar por uma nova solicitação quando o servidor master falhar na resposta de um registro SOA. Exemplo: o servidor secundário [slave] tenta verificar o número serial do servidor primário [master] e este não responde, então o servidor escravo irá esperar por 900 segundos para uma nova solicitação.
- 1209600: Este é o tempo limite, o período em segundos que o servidor secundário deve continuar respondendo mesmo que não consiga atualizar o arquivo zone, ou seja, mesmo que o servidor mestre não esteja respondendo.
- 43200: Define o tempo de vida (time-to-live) em segundos que outro servidor de nomes irá armazenar em cache a informação de uma consulta de domínio não existente (no such domain - NXDOMAIN). Neste exemplo, quando um outro DNS realiza uma consulta que resultou um host não existente, por exemplo tentou achar o host naoexiste.sistemasabertos.com.br, esta consulta fica armazenada em cache.
Registro NS - definindo servidores de nome editar
O RR NS define os servidores de nome oficiais para o domínio. Neste exemplo encontramos dois servidores de nome. O primeiro nome, lab1 é o servidor de nomes primário, neste exemplo estamos adotando como servidor secundário o host lab2.sistemasabertos.com.br.Você ainda pode definir um servidor que seja externo à sua rede para que seja servidor slave.
Registro MX - definindo Servidores de Mensagens editar
O RR MX define os servidores de mensagens para este domínio. Neste caso usamos também a máquina lab1 como servidor de mensagens, lembrando que para configurar um servidor de mensagens é necessário todo um processo de configuração, o que estamos fazendo é apenas um pré-requisito. Os registros MX redirecionam mensagens endereçadas para o domínio sistemasabertos.com.br.
Todo e-mail enviado para jpaulo@sistemasabertos.com.br será recebido pela máquina lab1 e pode ser repassado de acordo com a configuração do servidor de mensagens para outros hosts. Mensagens podem ainda ser endereçadas diretamente para um host em específico, como exemplo temos: jpaulo@lab9.sistemasabertos.com.br.
Logo depois da entrada MX existe um número, este define a prioridade do servidor de email. Você pode ter várias entradas MX com diferentes servidores de email. Cada servidor de email deve ter prioridade diferente, sendo que quanto menor for o número, maior será a prioridade. Assim quando o servidor de maior prioridade falhar o segundo servidor de menor número irá fazer o papel de servidor de email deste domínio.
Registro A - Definindo os hosts e seus IPs editar
→ Acima de todas as funções o objetivo final deste arquivo é mapear nomes para endereços IP. Eis aqui um exemplo das próximas linhas do arquivo:
lab1 IN A 10.1.0.101
Podemos traduzir esta linha para:
Máquina lab1 em rede TCP/IP possui endereço IP 10.1.0.101
Assim deve ser feito para todas as máquinas da rede, toda máquina da rede deve ter uma linha com seu endereço IP neste arquivo. Quando você solicitar uma máquina através de um nome, a máquina que solicitou pergunta ao servidor DNS e ele te responde conforme a linha traduzida acima, e assim você obtém o requisitado endereço IP.
Neste caso colocando apenas o primeiro nome, o sistema entende como pertencente ao domínio sistemasabertos.com.br. Ao colocar o FQDN , deve-se lembrar de colocar no final do nome um (.). Este ponto é um padrão de sintaxe que especifica que um nome absoluto, que inicia-se a partir do domínio root (raiz) especificada como ponto (.).
Registro CNAME editar
Este registro é utilizado para atribuir apelidos para um host. CNAME indica qual é o nome canônico para um alias . Nome canônico é o nome real da máquina. Deve-se notar que um nome canônico sempre tem um registro A associado para definir o seu endereço IP, portanto um registro CNAME sempre é acompanhado de um host que teve seu número IP referenciado por um registro A, nunca outro alias. Assim ao colocar um alias www para um host, este provavelmente é o servidor Web deste domínio. Assim, seguindo nosso exemplo, quando uma pessoa digitar em um browser www.sistemasabertos.com.br, na verdade, ela estará acessando a máquina lab1.sistemasabertos.com.br (Veja a última linha do arquivo /etc/named/sistemasabertos.hosts). Isto é interessante na medida que não é necessário decorarmos nomes de máquinas. Assim digitando www.nomedominio teremos a certeza que estaremos acessando o servidor web deste domínio.
Arquivo da Zona Reversa editar
Assim como o DNS é capaz de converter nomes para endereço IP, o DNS também é capaz de converter números IP para nomes. Alguns serviços, como por exemplo o ftp, utilizada a resolução reversa para registrar o nome do host cliente ftp em vez de seu número ip em seu histórico [log] .
Para que o DNS forneça este serviço precisamos criar o arquivo da base de dados da zona reversa. Antes disto, devemos criar uma zona reversa no arquivo /etc/bind/named.conf e posteriormente criar o arquivo de banco de dados.
→ Está zona já foi criada anteriormente com nome de "1.10.in-addr.arpa." Lembre -se também que o arquivo da base de dados definido para esta zona deve ter o nome db.10.1
Através do arquivo named.conf e da zona definida no exemplo, devemos criar este arquivo dentro do diretório /var/cache/bind, o arquivo deverá ter o nome db.10.1. Segue abaixo a configuração deste arquivo:
$TTL 43200 @ IN SOA lab1.sistemasabertos.com.br. root.sistemasabertos.com.br. ( 20010328002 ; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN NS lab1.sistemasabertos.com.br. 101.0 IN PTR lab1.sistemasabertos.com.br. 102.0 IN PTR lab2.sistemasabertos.com.br. 103.0 IN PTR lab3.sistemasabertos.com.br. 104.0 IN PTR lab4.sistemasabertos.com.br. 105.0 IN PTR lab5.sistemasabertos.com.br. 106.0 IN PTR lab6.sistemasabertos.com.br. 107.0 IN PTR lab7.sistemasabertos.com.br.
O arquivo da base de dados da zona reversa também possui um RR SOA e um RR NS, geralmente os mesmos parâmetros utilizados no arquivo de banco de dados de zona. A finalidade da resolução reversa é se obter o nome canônico de um host, baseado em seu ip. Para isto utiliza-se o registro de recurso PTR, que associa um endereço IP a um nome de host. O endereçamento reverso utiliza um domínio fictício convencionado como in-addr.arpa e que um número ip é de forma reversa.
Observe que a zona foi definida com o endereço de rede de trás para frente sendo 1.10.in-addr.arpa. No arquivo da zona reversa deve ser definido os outros octetos do endereço IP pertinente ao endereço de host, e deve ser também de trás para frente. Vejamos a máquina lab1.sistemasabertos.com.br que neste exemplo está definido com endereço de host 101.0. Agora associe este endereço ao endereço de rede de trás para frente. Resultado: 101.0.1.10, o endereço IP exatamente ao contrário. Logo o endereço IP desta máquina interpretado pelo named será 10.1.0.101.
→ Configurando o arquivo reverso
Aproveitando o db.127
# cp db.127 db.10.1
Editando:
# vi db.10.1 ; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA localhost. root.localhost. ( ########## ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS localhost. 1.0.0 IN PTR localhost. 105.0 IN PTR lab5 106.0 IN PTR lab6
Depois de feito isto, os próximos passos são:
→ 1.Reinicializar o bind
#/etc/rc.d/init.d/bind restart
→ Depois de inicializado o named, para diagnosticar possíveis erros utilize o comando:
# tail -n20 /var/log/syslog Aug 30 16:02:10 lab1 named[848]: master zone "sistemasabertos.com.br" (IN) loaded (serial 2001082905) Aug 30 16:02:10 lab1 named[848]: Zone "0.1.10.in-addr.arpa" (file db.10.1): No default TTL set using SOA minimum instead Aug 30 16:02:10 lab1 named[848]: master zone "0.1.10.in-addr.arpa" (IN) loaded (serial 2001082901) Aug 30 16:02:10 lab1 named[848]: listening on [127.0.0.1].53 (lo) Aug 30 16:02:10 lab1 named[848]: listening on [10.1.0.101].53 (eth0) Aug 30 16:02:10 lab1 named[848]: Forwarding source address is [0.0.0.0].1024 Aug 30 16:02:10 lab1 named[849]: group = bind Aug 30 16:02:10 lab1 named[849]: user = bind Aug 30 16:02:10 lab1 named[849]: Ready to answer queries. ago 30 16:02:10 lab1 named: named startup succeeded
Caso a saída do comando não registre nenhum erro, sua configuração está correta
→ 2.O arquivo /etc/resolv.conf do servidor deve ficar com a seguinte configuração:
search sistemasabertos.com.br nameserver 127.0.0.1
→ Os clientes deverão definir através da entrada nameserver exatamente o endereço IP do servidor.
search sistemasabertos.com.br
→ Este parâmetro é utilizado quando você digitar apenas o nome da máquina sem seu respectivo domínio, então, automaticamente o domínio sistemasabertos.com.br será acrescentado.
nameserver 127.0.0.1a
Neste caso estamos utilizando o endereço 127.0.0.1 para o servidor utilizar de seu próprio DNS. Nas máquinas clientes obviamente elas devem colocar o endereço IP do servidor.
dig editar
→ Para verificar realmente se seu DNS realmente está funcionando, use a ferramenta dig. Eis aqui um exemplo:
#dig lab1.sistemasabertos.com.br ... ... 10.1.0.101 ...
Depois de digitar dig, basta digitar o nome da máquina que o DNS fornecerá o endereço IP. A recíproca é verdadeira, se você informar o endereço IP, o DNS fornecerá o nome da máquina mais o endereço IP. O detalhe é que para funcionar a segunda tentativa a resolução reversa deverá estar adequada.
Configuração de servidor de nomes Secundário editar
Este tipo de servidor é considerado também um servidor autorizado, pois tem um completo banco de dados de domínio que ele transfere do servidor primário.
Mas qual seria a principal diferença entre o servidor primário e o secundário?. O servidor primário extrai seus dados diretamente de seus arquivos de registro de banco de dados (arquivos locais), enquanto o servidor secundário carrega os dados por meio de outro servidor DNS, através de um processo chamado de transferência de zona.
A grande vantagem de utilizar o servidor secundário é a manutenção do servidor. Com o servidor secundário você precisa manter a informação atualizada apenas no servidor primário, pois o servidor secundário faz uma transferência de zona do servidor primário. Alterando o servidor primário esta configuração será refletida consequentemente no servidor secundário, assim a manutenção é totalmente centralizada no servidor primário.
→ Para configurar o named.conf do servidor escravo, você pode partir do servidor de cache e adicionar mais duas zonas. Veja o exemplo do arquivo /etc/bind/named.conf.local:
//
// CONFIGURAÇÃO DO SERVIDOR SECUNDÁRIO
//
zone "sistemasabertos.com.br" {
type slave;
file "db.sa";
masters { 10.1.0.101; };
};
zone "1.10.in-addr.arpa" {
type slave;
file "db.10.1";
masters { 10.1.0.101; };
};
Neste exemplo estamos usando a máquina 10.1.0.101 (lab1) como servidor primário para o domínio sistemasabertos.com.br, logo qualquer outra máquina pode usar esta configuração para ser o servidor secundário. Estas novas instruções zone declaram zonas para os domínios sistemasabertos.com.br e 0.1.10.in-addr.arpa. A última zona definida é a zona reversa.
Antes de iniciar o daemon named, você deve verificar o dono e o grupo do diretório do /var/cache/bind. O serviço named do servidor secundário tenta gravar os arquivos do servidor primário (master) neste diretório, o serviço named utiliza do usuário também chamado bind para escrever estes arquivos neste diretório, porém o usuário bind não tem permissão para escrever este diretório. Logo, você deve alterar esta configuração:
→ No servidor secundário execute:
#chown bind.bind /var/cache/bind
→ Depois de feito as configurações acima, é hora iniciar o serviço named. Isto considerando que já esteja configurado o servidor primário.
#/etc/rc.d/init.d/bind restart
Verifique os possíveis erros através dos arquivos do syslog do Servidor Master. Veja o exemplo:
#tail -n20 /var/log/syslog Aug 30 16:20:45 lab8 named[959]: starting. named 8.2.2-P7 Fri Nov 10 20:54:32 EST 2000 Aug 30 16:20:45 lab8 named[959]: hint zone "" (IN) loaded (serial 0) Aug 30 16:20:45 lab8 named[959]: Zone "0.0.127.in-addr.arpa" (file db.root): No default TTL set using SOA minimum instead Aug 30 16:20:45 lab8 named[959]: master zone "0.0.127.in-addr.arpa" (IN) loaded (serial 1997022700) Aug 30 16:20:45 lab8 named[959]: slave zone "sistemasabertos.com.br" (IN) loaded (serial 2001082905) Aug 30 16:20:45 lab8 named[959]: slave zone "0.1.10.in-addr.arpa" (IN) loaded (serial 2001082901) Aug 30 16:20:45 lab8 named[959]: listening on [127.0.0.1].53 (lo) Aug 30 16:20:45 lab8 named[959]: listening on [10.1.0.108].53 (eth0) Aug 30 16:20:45 lab8 named[959]: listening on [10.1.3.108].53 (eth1) Aug 30 16:20:45 lab8 named[959]: Forwarding source address is [0.0.0.0].1024 Aug 30 16:20:45 lab8 named[960]: group = bind Aug 30 16:20:45 lab8 named[960]: user = bind Aug 30 16:20:45 lab8 named[960]: Ready to answer queries. ago 30 16:20:45 lab8 named: named startup succeeded
Através deste arquivo você pode detectar vários erros, tanto no servidor primário, quanto no servidor secundário. A máquina utilizada para ser servidor secundário neste exemplo foi a lab8.Observe na saída do comando tail que todas as zonas foram carregadas com sucesso. Observe também que o usuário e grupo responsável pela transferência de arquivos é o usuário bind e o grupo bind. Por este motivo tivemos que mudar as permissões do diretório /var/cache/bind como mostrado anteriormente.
A cláusula file do arquivo named.conf tem um sentido diferente dos modelos apresentados anteriormente. No Servidor secundário [slave], o arquivo definido pela instrução file é o arquivo que será copiado do servidor primário. Portanto, este arquivo, a princípio, não existe no servidor secundário até que o serviço named seja inicializado. Em outras palavras o servidor secundário [slave] fará uma cópia da base de dados do DNS do servidor primário. Outra importância de termos o servidor secundário está no fato de que: caso o servidor primário não responda, o secundário estará disponível para atendê-lo.
Delegando sub-domínios (zonas) editar
Sabemos que o DNS é um banco de dados hierárquico na Internet que funciona através de delegação de domínios através de servidores autorizados. Nosso objetivo é criar uma zona dentro domínio sistemasabertos.com.br chamada pr.sistemasabertos.com.br.
Para fazermos esta configuração vamos partir da configuração do servidor primário feito anteriormente. Esta configuração é baseada apenas no arquivo db.sa - arquivo da base de dados da zona sistemasabertos.com.br. Vejamos quais linhas devem ser adicionadas a este arquivo:
$TTL 43200 @ IN SOA lab1.sistemasabertos.com.br. root.sistemasabertos.com.br. ( 2001032802 ; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN MX 5 lab1.sistemasabertos.com.br. @ IN NS lab1.sistemasabertos.com.br. @ IN NS lab2.sistemasabertos.com.br. lab1 IN A 10.1.0.101 lab2 IN A 10.1.0.102 lab3 IN A 10.1.0.103 lab4 IN A 10.1.0.104 lab5 IN A 10.1.0.105 lab6 IN A 10.1.0.106 lab7 IN A 10.1.0.107 www IN CNAME lab1 ; ;------Inicio da seção de delegação de sub-domínio---- ; pr.sistemasabertos.com.br. IN NS valete.pr.sistemasabertos.com.br. valete.pr.sistemasabertos.com.br. IN A 10.1.0.200 ; bc.sistemasabertos.com.br IN NS dama.pr.sistemasabertos.com.br. dama.pr.sistemasabertos.com.br. IN A 10.1.0.201
Neste exemplo foram definidos duas novas zonas(dois novos sub-domínios) dentro do domínio sistemasabertos.com.br . A zona pr.sistemasabertos.com.br cujo servidor autorizado é a máquina valete.pr.sistemasabertos.com.br, endereço IP 10.1.0.200 e a zona bc.sistemasabertos.com.br cujo servidor é a máquina dama.pr.sistemasabertos.com.br, endereço IP 10.1.0.201.
Você deverá também editar o arquivo de zona reversa(10.1.0.reverse), vejamos:
$TTL 43200 @ IN SOA lab1.sistemasabertos.com.br. root.sistemasabertos.com.br. ( 20010328002 ; serial 3600 ; refresh 900 ; retry 1209600 ; expire 43200 ; default_ttl ) @ IN NS lab1.sistemasabertos.com.br. 101.0 IN PTR lab1.sistemasabertos.com.br. 102.0 IN PTR lab2.sistemasabertos.com.br. 103.0 IN PTR lab3.sistemasabertos.com.br. 104.0 IN PTR lab4.sistemasabertos.com.br. 105.0 IN PTR lab5.sistemasabertos.com.br. 106.0 IN PTR lab6.sistemasabertos.com.br. 107.0 IN PTR lab7.sistemasabertos.com.br. 200.0 IN PTR valete.pr.sistemasabertos.com.br. 201.0 IN PTR dama.bc.sistemasabertos.com.br.
As linhas adicionadas a este arquivo estão em negrito. Neste arquivo a única finalidade destas entradas e resolver o IP destas máquinas para seus respectivos nomes.
Depois de feito isto, basta configurar os novos servidores primários para os novos domínios: pr.sistemasabertos.com.br e bc.sistemasabertos.com.br. A configuração destes novos servidores é a configuração padrão de servidores primários.
→ Sempre que alterar os arquivos pertinente ao serviço named, este deve ser reiniciado.
Terminologia utilizada neste capítulo editar
biblioteca resolver: biblioteca que pode ser utilizado por aplicações para obter o endereço IP a partir de um nome e vice-versa. A utilização da biblioteca resolver está ligado à configuração do cliente DNS. BIND: Berkeley Internet Name Domain, nome do pacote de software do DNS que pode ser encontrado no endereço http://www.isc.org Canonical name: Nome original da máquina, é definido como o nome de hospedeiro para o qual está atribuído um endereço IP no arquivo da base de dados do DNS. Domínio: Define um espaço de nomes onde encontra-se várias zonas. FQDN: Acrônimo de Nome Totalmente Qualificado {Full Qualified Domain Name], especifica o nome da máquina com seu respectivo domínio. Por exemplo: intranet.sistemasabertos.com.br. MIT: Massachussets Institute of Technology MX: Registro de Recurso que define o servidor de email de um domínio. MX significa Mail Exchanger[Repassador de Email] resolução de nomes: Mesmo que encontrar o endereço IP através de um nome de hospedeiro resolução reversa: Processo de obter o nome da máquina através de seu endereço IP. RR: Registro de Recurso. São utilizados para compor a base de dados do DNS , todas as informações de zona são feitas através do registro de recurso. Existem vários tipos de RRs, cada registro tem uma função específica: identificar um servidor de email de um domínio, determinar o início de autoridade de um domínio, atribuir a um nome um endereço IP, entre outros. Autoridade sobre a zona - Servidor primário que é responsável por um domínio, um servidor tem autoridade sobre um domínio quando este pode delegar consultas para outros servidores de DNS que compõe seu domínio. Servidor caching [caching-server]: Definido com um servidor que guarda em cache consultas que já foram anteriormente solicitadas, de forma a melhorar a performance da resolução de nomes. Este tipo de servidor também é definido como um servidor que é capaz apenas fazer consultas para resolver endereços , ou seja, ele um servidor destinado a fazer e guardar consultas, não sendo responsável por nenhuma zona. Servidor DNS primário: Definido como um servidor autorizado (Servidor que tem autoridade sobre uma zona) que mantém a base de dados de um determinada zona, este servidor além de fazer consulta a servidores raízes também é consultado por outros servidores DNS como responsável (autorizado) pela zona em que foi delegada. Servidor DNS secundário: Também chamado de Servidor slave, é considerado uma cópia do primário. Este servidor tem a função de assegurar o serviço do servidor primário caso este venha a falhar. SOA: Início de Autoridade [Start Of Authority]. Marca o começo dos dados de zona e define parâmetros globais. TLD: Domínios de Alto Nível , são considerados domínios de alto nível: .br, .net, .com, etc, pois os servidores autorizados deste domínio são os primeiros servidores a serem consultados na árvore hierárquica do DNS. TTL: Time-to-Live - Define o tempo de vida de um registro de recurso. Este tempo de vida está ligado ao tempo que o registro de recurso ficará guardado em cache. Zona: Uma zona é definida como uma região de um domínio, pode ser entendida como um sub-domínio. Por exemplo o domínio .br tem uma possível zona chamada com.br, enquanto está zona pode ser um domínio para outras possíveis zonas como: sistemasabertos.com.br ou teste.com.br
Links Indicados editar
- 1. http://www.isc.org/products/BIND/
- É o site oficial do BIND, podendo se encontrar a documentação oficial “Bind 9 Administrator Guide”, o software oficial, etc. É mantida pelo ISC - Internet Software Consortium - um consórcio de entidades públicas e privadas, dentre elas HP, Sun e IBM; e que promovem a criação e manutenção de vários softwares, dentre eles um pacote de software de DHCP e outro de news (INN). Site em inglês.
- 2. http://www.crynwr.com/crynwr/rfc1035
- a conversão modificada da RFC1035 (Domain Names - Concepts and Facilities”) em html por Russell Nelson, é a RFC mais importante sobre DNS, e descreve os detalhes do sistema de domínios e protocolo. Em inglês.
- 3. http://www. ietf.org/rfc/rfc1034.txt
- a localização oficial da RFC1034. Possui uma definição bem interessante sobre nomes canônicos ou primários e seu uso no RR CNAME. Em inglês.
- 4. http://eeunix.ee.usm.maine.edu/guides/dns/dns.html
- É um guia bem direto e enxuto sobre DNS, escrito por Glenn Stevens. Possui ilustrações bastante interessantes, que elucidam bem o funcionamento do protocolo. Em inglês.
- 5. http://www.internic.net
- Este site pertence a um dos grande órgãos internacionais que cuidam da internet como um todo no aspecto de resolução de nomes.
- 6. http://www.nominum.com/resources/documentation/Bv9ARM.pdf
- Manual de referência do Administrador do BIND 9 - Um manual oficial, indispensável para administradores de Servidores de Nomes. Contém informações detalhadas de todas sentenças e opções disponíveis para o BIND 9.
Exercícios de Revisão editar
1. Qual é a definição de DNS? Qual é sua principal finalidade? Quais os tipos de servidores de DNS existem e quais suas principais características?
2. Qual a diferença entre zona e domínio?
3. Defina Servidor Autorizado.
4. Quantas zonas são definidas no arquivo named.conf quando se trata de um servidor de cache. Quais as funções destas zonas?
5. Na configuração do DNS primário são utilizados 3 arquivos de configuração, qual a função de cada um?
6. Sabemos que na configuração do servidor secundário é utilizado apenas o arquivo named.conf. Faça um exemplo de uma configuração de servidor secundário, explicando todas as opções utilizada no arquivo e suas funções?
7. Suponha que você está no servidor de um domínio mk.br e quer criar um sub-domínio bom.mk.br- uma nova zona deste domínio - qual o procedimento?
8. Qual a diferença entre um servidor de nomes: caching, primário [master] e secundário [slave]?
9. Suponha que necessitamos de configurar um domínio chamado teste.com.br, para um servidor de nomes primário de nome ns.teste.com.br e endereço IP 200.1.2.3. O endereço IP deste servidor é 200.1.2.3 e o IP do servidor web deste domínio é o mesmo do servidor secundário de nome ns2.teste.com.br, com número IP 200.1.2.4. E o servidor SMTP (mail) é o mesmo do DNS primário. Apresente a configuração para esta situação, indicando quais são e um possível conteúdo destes arquivos.
10. O que são RR - Registros de Recursos? Qual é a sintaxe? Para que servem? Cite e explique alguns tipos de RRs.
11. Qual é a função dos servidores de nome raízes [root-servers]? Por que eu preciso de manter um arquivo dos endereços IP's dos servidores de nome raízes? Como eu posso atualizar este arquivo?
12. Qual é a função da diretiva $TTL? Qual é a vantagem e a desvantagem de se ter um valor de TTL - Time To Live - alto ou baixo?
13. Suponha que o servidor de email responsável por um domínio (registro MX) mantido por um DNS foi modificado. Imediatamente você pediu que alguns colegas que utilizam outros servidores de nomes fizessem testes para saber se a sua configuração foi efetivada com sucesso. Porém, alguns disseram que o teste foi bem sucedidos, outros não. Levante hipóteses para explicar o porquê de alguns testes não terem dado certo. Isto é normal? O que você poderia fazer para que isto não acontecesse? Como eu faria para não perder os e-mails?