Aula 3 Servidor DNS BIND

1 Aula 3 Servidor DNS BIND Um servidor DNS é responsável em responder pelos domínios e direcionar tudo que é relacionado a ele, nele por exemplo pode se apontar onde fica www.dominio.com.br, vai apontar também quais são os servidores de entrada de e mail, ftp, web e etc. O DNS também possui outras utilidades, como por exemplo em uma rede interna, com ele configurado em um servidor uma rede interna, não será preciso informar o servidor DNS do seu provedor, basta somente apontá lo para ele e até fazer com que sua empresa toda responda por hosts, por exemplo: maquina 1.dominio.com.br, maquina 2.dominio.com.br, ou seja, resolver localmente os endereços de sua rede. 1. DNS e domínios Podemos definir como Domínio a denominação que é fornecida a um site para localizar e identificar conjuntos de computadores na Internet. O nome de domínio foi concebido com o objetivo de facilitar a memorização dos endereços de computadores na Internet, sem este serviço teríamos que memorizar uma seqüência grande de números os IP's. Para se alcançar uma estação na rede, precisamos sempre de seu endereço IP, logo o nome do domínio precisa ser traduzido para este endereço. Para resolver isso, foi criado o DNS, o Domain Name System, cuja principal função é traduzir este nome. Logo dado um nome de uma estação ou servidor (como por exemplo: http://www.uniderp.br), ele retorna o número IP da mesma (por exemplo: 200.241.189.172) Há três possibilidades de servidro DNS, descritos a seguir: cache : é um servidor que não é capaz de resolver nomes e sim fazer consultas de endereços que já foram solicitadas para melhorar a perfomance na rede. Nele não existe um base de dados sobre uma determinada zona como a GINUX da comp.ufla.br. mestre : Servidor que tem autoridade sobre uma determinada zona como a GINUX de comp.ufla.br. Nele existe uma base de dados com informações das máquinas de determinada zona. Também serve para comsultar e ser consultado por outros servidores raízes. escravo : Também conhecido como escravo ou secundário, serve como cópia do Master. É utilizado pelos clientes quando o servidor, por algum motivo, pára de funcionar. O SLAVE pode servir também para armazenar uma cópia dos backups da empresa. O DNS slave é uma redundancia do DNS master, ou seja, o que tem em um tem no outro, com isso quando o DNS master por algum motivo cai o Slave pode resolver os nomes. Para isso o cliente tem que ter cadastrado os dois DNS na sua máquina, um como primario e outro como segundario. Caso ele nao consiga resolver em um ele tenta com o outro. Dominio é o nome da entidade e a zona é a implementação dessa entidade. Duas coisas são importantes para esclarecer a diferença entre domínio e zona: o DNS é um sistema de resolução de nomes que está estruturado de forma hierárquica (árvore),

2 começando pela raíz ".", que pode ser seccionado em domínios; essa estrutura é organizada como uma base de dados distribuída em zonas. Então, domínio é o conjuntto de computadores (hosts) que pertencem a um ramo da árvore. Por exemplo, o domínio ".uniderp.br" abrange todos os hosts cujo FQDN terminem em.uniderp.br., já o domínio ".redes.uniderp.br" contém os hosts com essa terminação de nome. Por seu turno, o termo zona está associado a autoridade de determinado DNS sobre um domínio ou parte dele. Por exemplo, o domínio ".ufla.br" mencionado acima pode estar sendo gerenciado por um servidor. Nesse caso, a zona coincide com o domínio. Por outro lado, podem existir dois DNS, um para ".uniderp.br" e outro para ".redes.uniderp.br". Então a zona de ".uniderp.br" não inclui a parte do domínio iniciada no ramo ".redes.uniderp.br" 2. DNS BIND BIND (Berkeley Internet Name Domain ou Berkeley Internet Name Daemon) é o servidor para o protocolo DNS mais utilizado na Internet, especialmente em sistemas do tipo Unix e Linux, onde ele pode ser considerado um padrão de fato. Foi criado por quatro estudantes de graduação, membros de um grupo de pesquisas em ciência da computação da Universidade de Berkeley, e foi distribuído pela primeira vez com o sistema operacional 4.3BSD. O BIND foi escrito originalmente no início da década de 1980 em um projeto suportado pela agência DARPA. Em meados dos anos 80, funcionários da DEC assumiram o seu desenvolvimento. Um destes funcionários era Paul Vixie, que continuou o seu trabalho com o BIND após deixar a empresa. Ele ajudou na criação da organização ISC que se tornou responsável pela manutenção do programa. O desenvolvimento do BIND 9 foi realizado através de uma combinação de contratos comerciais e militares. Para a versão 9, o BIND foi praticamente reescrito. Ele passou a suportar, dentre outras funcionalidades, a extensão DNSSEC e os protocolos TSIG e IPv6. A maioria das funcionalidades do BIND 9 eram promovidas por empresas fornecedoras de sistemas Unix que queriam garantir que o BIND se manteria competitivo com as ofertas de servidores DNS da Microsoft, por exemplo, a extensão de segurança DNSSEC foi financiada pelos militares estadunidenses que perceberam a importância da segurança para o servidor DNS. O programador Paul Vixie, enquanto trabalhava para a empresa DEC, foi o primeiro mantenedor do BIND. Atualmente o BIND é suportado e mantido pelo Internet Systems Consortium. 3. instalando o DNS BIND O BIND foi uma das primeiras implementações de servidor DNS existentes e é a mais utilizada até hoje. A instalação do BIND pode ser feita tanto por pacotes fontes (como tar.gz) ou via o repositório da distribuição adotada, mais recomendado. Caso a distribuição seja baseada na família Debian (Ubuntu, Kurumin e etc.) o comando é: # apt get install bind9 dnsutils y

3 Se a distribuição for baseada no Red Hat (Fedora, CentOS, Suse, Mandriva) o comando será: # yum install bind9 dnsutils y 4. Configurando o DNS BIND 4.1 Configurações básicas Devemos editar o arquivo /etc/bind/named.conf.options na linha onde tem a seguinte opção: directory "/var/cache/bind"; Vamos modificá la e adicionar a linha abaixo para: directory "/etc/bind"; version " "; A opção version exibe o texto entre aspas caso alguém utilize os comandos dig ou nslookup no seu servidor DNS, sendo portanto uma opção de segurança, já que não retorna informação alguma do nosso servidor DNS. A linha onde contém o comentário abaixo também deverá ser habilitada e deve se substituir o valor 0.0.0.0 pelo gateway da rede, por exemplo: forwarders { 192.168.1.80; Na linha onde encontramos: auth nxdomain no; Deve ser deixado como está, pois ela indica se o nosso DNS é um root server ou não. Na linha onde temos: listen on v6 { any; caso utilize se endereçamento ipv6, trocar o "any" pelo IP da interface que se quer que o servidor DNS fique escutando, caso não utilize, modifique para: listen on { 127.0.0.1; 192.168.1.80; Essa opção listen on é para endereçamento ipv4, onde o endereço do servidor DNS será, neste caso, o IP 192.168.1.80. Abaixo do listen on, por uma medida de segurança, pode se adicionar ainda a opção: allow query { f. 127.0.0.0/8; 192.168.1.0/24; Essa opção é utilizada para permitir quem se quer que faça a consulta no servidor DNS.

4 4.2 Inserindo zonas de DNS Agora iremos criar e inserir as nossas zonas de DNS. Vamos editar o arquivo /etc/bind/named.conf.local: # vim /etc/bind/named.conf.local zone "sl.labinfo" IN { type master; file "db.sl.labinfo"; allow transfer { none; zone "1.168.192.in addr.arpa" IN { type master; file "rev.sl.labinfo"; allow transfer { none; A opção type indica se o servidor DNS em questão é slave (secundário) ou master (primário). A opção allow transfer indica se iremos permitir algum outro servidor ser slave, ou seja, pegar os arquivos de zonas, se não colocar essa opção, por default será allow transfer { any;. Caso eu tenha algum servidor slave, poderia se colocar o IP dele no lugar do none e no servidor que será slave colocaria a opção masters { IP;, indicando quem é o master. Acima, quando alteramos a opção directory no arquivo named.conf.options, caso não fosse trocada aquela opção para /etc/bind teriamos de colocar no file "db.sl.labinfo" e no file "rev.sl.labinfo" para a opçãp file "/etc/bind/db.sl.labinfo" e para file "/etc/bind/rev.sl.labinfo", ou seja, indicar o caminho completo dos arquivos que ficariam em /var/cache/named, mas que no entanto iremos colocar em /etc/named, facilitando nosso trabalho, colocando todos os arquivos em um mesmo local. 4.3 Configuando o arquivo de zona do DNS Como inserimos a zona não existente por padrão, devemos agora criar o arquivo e inserirmos os dados a seguir: # vim /etc/bind/db.sl.labinfo $TTL 3600 @ IN SOA sl.labinfo. hostmaster.sl.labinfo. ( 2008111800 900 400 3600000 3600

5 ) @ IN NS sl.labinfo. @ IN A 192.168.1.80 @ IN MX 10 mail.sl.labinfo. # caso tenha um servidor de e mail mail IN A 192.168.1.80 www IN CNAME vivaolinux.com.br. # caso tenha um servidor web Onde: A chave de registro SOA indica o início de uma zona de autoridade. 2008111800 é o número serial, ou seja, o slave verá que o servidor master foi modificado através desse número, caso se modifique algo no servidor DNS, TEM QUE MODIFICAR O SERIAL TAMBÉM, colocando 2008111801 e assim por diante. 900 será o update, ou seja, de quanto em quanto tempo o slave verificará se houve alguma modificação em algum arquivo de zona. 400 será o retry, ou seja, caso o servidor master pare de funcionar por algum motivo, de quanto em quanto tempo o slave verificará se o master voltou a funcionar. 3600000 será o expire, ou seja, se o servidor master cair, após quanto tempo o servidor slave irá parar de resolver nomes também. 3600 será o negative cache. A chave de registro NS (nameserver) indica o nome da autoridade do domínio. A chave A indica o endereço de host. A chave MX 10 indica o servidor de email para o domínio, o número 10 é a prioridade desse servidor. A chave CNAME é o nome canônico. 4.4 Configuando o arquivo de zona do DNS reverso Criar o arquivo de zona de DNS reverso: # vim /etc/bind/rev.sl.labinfo $TTL 3600 @ IN SOA sl.labinfo. hostmaster.sl.labinfo. ( 2008111800 900 400 3600000 3600 ) @ IN NS sl.labinfo. 80 IN PTR sl.labinfo.

6 @ IN MX 10 mail.sl.labinfo. # caso haja um servidor de e mail 80 IN PTR mail. sl.labinfo (reverso). A chave de registro PTR (pointer) indica um ponteiro para outro lado do nome do domínio espacial 4.5 Registros do DNS BIND Os arquivos de configuração do DNS possuem 3 registros de resolução: SOA NS PTR O SOA (Start Of Autority Início De Autoridade) define o servidor DNS. O @ (at está em) é um anotação especial que significa a origem deste domínio, ou melhor, onde ele está localizado. Isto quer dizer o seguinte: o domínio 0.0.127.IN ADDR.ARPA está localizado em SOA linux. O NS é o servidor de nomes RR (Register Resolution Resolução de Registro) que indica ao DNS que a estação é a servidora de nomes de domínio. (localhost). O PTR diz que 1 (iguala 1.0.0.127.IN ADDR.ARPA, ou 127.0.0.1) é o nome DNS do servidor local Para entendermos melhor: o registro de SOA é o preâmbulo a toda zona de arquivo, descreve a zona de onde vem quem é o responsável por seus conteúdos. o registro NS indica que quem resolve o DNS para o domínio 0.0.127.in addr.arpa é o servidor linux. o registro de PTR nos fala que 1.0.0.127.in addr.arpa (127.0.0.1) é conhecido como localhost. Existem alguns parâmetros que são representados por número e seguidos por ponto e vírgula (que representa comentários) com sua respectiva descrição. São eles: serial: representa uma data definida pelo root para ser utilizada em operação com um servidor de domínio secundário. Um servidor secundário armazena uma cópia da base de dados do servidor primário (o tipo Master na configuração named.conf). Este tipo de servidor é bastante útil quando temos uma rede muito grande ou separada em diferentes localidades geográficas. Quando um servidor primáio de DNS pára de funcionar por algum motivo o secundário assume a resolução de nomes; refresh: representa o tempo em segundos para a atualização/verificação da base de nomes de

7 domínios de um servidor primário de DNS, para um servidor secundário de DNS; retry: caso o servidor primário de DNS pare seu funcionamento, o servidor secundário tentará a comunicação repetidamente conforme o intervalo de tempo definido aqui. Se for definido uma hora, de uma em uma hora o servidor secundário tentará a comunicação com o primário; expire: tempo útil de base de dados de nomes de domínios em um servidor secundário de DNS. Caso este tempo seja ultrapassado sem ser realizado um contato com o servidor primário de DNS, os dados ali armazenados são considerados desatualizados. Em certos casos o servidor poderá até parar de resolver estes nomes de DNS; Time To Live TTL: indica o tempo de resposta de um servidor em caso de pedido de resolução de um nome contido em sua base; 4.6 Testando o servidor DNS BIND Deve se incialmente edite o arquivo de resolução de nomes /etc/resolv.conf e editá la da seguinte forma: # vim /etc/resolv.conf search sl.labinfo nameserver 192.168.1.80 Feito isso, deve se reiniciar o servidor DNS BIND: # /etc/init.d/bind9 restart ou # invoke rc.d bind9 restart Após reinciado o servidor DNS BIND deve se testá lo utilizando o comando host. Para o servidor DNS: # host sl.labinfo E para o servidor de DNS reverso: # host 192.168.1.80 Para terminar o teste deve se utilizar os comandos dig e nslookup e observar suas saídas: # dig 192.168.1.80 ou # dig sl.labinfo e # nslookup 192.168.1.80 ou # nslookup sl.labinfo