==== Instalação e configuração do Bind no Debian 8 ==== === Introdução ao BIND === O BIND (Berkeley Internet Name Domain) é o servidor de nomes utilizado na grande maioria dos servidores da Internet, provendo uma estável e robusta arquitetura sobre a qual as organizações podem construir sua estrutura de nomes. # install bind9 dnsutils O arquivo principal chama-se /etc/bind/named.conf mas contém apenas configurações estáticas. Ele utiliza a cláusula include para anexar os arquivos /etc/bind/named.conf.options e /etc/bind/named.conf.local. Sendo que desses dois, o primeiro serve para personalizar todas opções referentes ao funcionamento do próprio BIND, enquanto que o segundo serve para declarar todas as zonas pelas quais este servidor deve responder. # ls -lh /etc/bind total 52K -rw-r--r-- 1 root root 2,4K Fev 19 01:59 bind.keys -rw-r--r-- 1 root root 237 Fev 19 01:59 db.0 -rw-r--r-- 1 root root 271 Fev 19 01:59 db.127 -rw-r--r-- 1 root root 237 Fev 19 01:59 db.255 -rw-r--r-- 1 root root 353 Fev 19 01:59 db.empty -rw-r--r-- 1 root root 270 Fev 19 01:59 db.local -rw-r--r-- 1 root root 3,0K Fev 19 01:59 db.root -rw-r--r-- 1 root bind 463 Fev 19 01:59 named.conf -rw-r--r-- 1 root bind 490 Fev 19 01:59 named.conf.default-zones -rw-r--r-- 1 root bind 165 Fev 19 01:59 named.conf.local -rw-r--r-- 1 root bind 890 Jun 4 11:34 named.conf.options -rw-r----- 1 bind bind 77 Jun 4 11:34 rndc.key -rw-r--r-- 1 root root 1,3K Fev 19 01:59 zones.rfc1918 Além dos arquivos citados acima, temos o arquivo db.root que relaciona os endereços dos 13 servidores raiz e é lido como zona hint. O BIND vai utilizar a porta 53/UDP para receber consultas, a porta 53/TCP para transferir zonas para servidores escravos, a porta 953/TCP para receber comandos via rndc(que dependem de chaves criptografadas), e portas udp altas podem ser dinamicamente atribuídas para efetuar consultas em outros servidores. Vamos observar a recursividade e as portas envolvidas utilizando o tcpdump, mas antes vamos verificar as portas: # ss -nat | grep 53 LISTEN 0 10 192.168.200.100:53 *:* LISTEN 0 10 127.0.0.1:53 *:* LISTEN 0 128 127.0.0.1:953 *:* LISTEN 0 10 :::53 :::* LISTEN 0 128 ::1:953 :::* Instale o sniffer tcpdump: # apt-get install tcpdump Execute o tcpdump para verificar os pacotes saindo de uma porta alta até a porta 53/udp de seu servidor: # tcpdump -i eth0 -n port 53 Em outro terminal execute: # dig @localhost -t any wikipedia.com Saída da consulta: # dig @localhost -t any wikipedia.com ; <<>> DiG 9.9.5-9-Debian <<>> @localhost -t any wikipedia.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57682 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 3, ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;wikipedia.com. IN ANY ;; ANSWER SECTION: wikipedia.com. 600 IN TXT "google-site-verification=AMHkgs-4ViEvIJf5znZle-BSE2EPNFqM1nDJGRyn2qk" wikipedia.com. 3600 IN MX 10 polonium.wikimedia.org. wikipedia.com. 3600 IN MX 50 lead.wikimedia.org. wikipedia.com. 86400 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2015052817 43200 7200 1209600 3600 wikipedia.com. 600 IN AAAA 2620:0:861:ed1a::1 wikipedia.com. 600 IN A 208.80.154.224 wikipedia.com. 86400 IN NS ns0.wikimedia.org. wikipedia.com. 86400 IN NS ns1.wikimedia.org. wikipedia.com. 86400 IN NS ns2.wikimedia.org. ;; AUTHORITY SECTION: wikipedia.com. 86400 IN NS ns2.wikimedia.org. wikipedia.com. 86400 IN NS ns1.wikimedia.org. wikipedia.com. 86400 IN NS ns0.wikimedia.org. ;; ADDITIONAL SECTION: ns0.wikimedia.org. 86398 IN A 208.80.154.238 ns1.wikimedia.org. 86398 IN A 208.80.153.231 ns2.wikimedia.org. 86398 IN A 91.198.174.239 ;; Query time: 2081 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Jun 04 18:57:55 BRT 2015 ;; MSG SIZE rcvd: 417 Captura com o tcpdump: # tcpdump -i eth0 -n port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 18:57:53.432907 IP 192.168.200.100.5513 > 192.33.14.30.53: 40180% [1au] ANY? wikipedia.com. (42) 18:57:53.664192 IP 192.33.14.30.53 > 192.168.200.100.5513: 40180- 0/7/1 (594) 18:57:53.664869 IP 192.168.200.100.61999 > 199.19.57.1.53: 23654% [1au] A? ns0.wikimedia.org. (46) 18:57:53.665031 IP 192.168.200.100.30221 > 199.19.57.1.53: 36251% [1au] AAAA? ns0.wikimedia.org. (46) 18:57:53.665150 IP 192.168.200.100.53091 > 199.19.57.1.53: 27810% [1au] A? ns1.wikimedia.org. (46) 18:57:53.665261 IP 192.168.200.100.7319 > 199.19.57.1.53: 6732% [1au] AAAA? ns1.wikimedia.org. (46) 18:57:53.665374 IP 192.168.200.100.49066 > 199.19.57.1.53: 61180% [1au] A? ns2.wikimedia.org. (46) 18:57:53.665471 IP 192.168.200.100.31189 > 199.19.57.1.53: 43021% [1au] AAAA? ns2.wikimedia.org. (46) 18:57:53.894522 IP 199.19.57.1.53 > 192.168.200.100.61999: 23654- 0/7/4 (637) 18:57:53.894865 IP 192.168.200.100.21300 > 91.198.174.239.53: 12289% [1au] A? ns0.wikimedia.org. (46) 18:57:53.907795 IP 199.19.57.1.53 > 192.168.200.100.30221: 36251- 0/7/4 (637) 18:57:53.908137 IP 192.168.200.100.31076 > 91.198.174.239.53: 53799% [1au] AAAA? ns0.wikimedia.org. (46) 18:57:53.917811 IP 199.19.57.1.53 > 192.168.200.100.49066: 61180- 0/7/4 (637) 18:57:53.918137 IP 192.168.200.100.10913 > 91.198.174.239.53: 31592% [1au] A? ns2.wikimedia.org. (46) 18:57:53.921041 IP 199.19.57.1.53 > 192.168.200.100.7319: 6732- 0/7/4 (637) 18:57:53.921192 IP 199.19.57.1.53 > 192.168.200.100.53091: 27810- 0/7/4 (637) 18:57:53.921384 IP 192.168.200.100.29745 > 91.198.174.239.53: 41837% [1au] AAAA? ns1.wikimedia.org. (46) 18:57:53.921604 IP 192.168.200.100.57528 > 91.198.174.239.53: 63523% [1au] A? ns1.wikimedia.org. (46) 18:57:53.922265 IP 199.19.57.1.53 > 192.168.200.100.31189: 43021- 0/7/4 (637) 18:57:53.922469 IP 192.168.200.100.37465 > 91.198.174.239.53: 5737% [1au] AAAA? ns2.wikimedia.org. (46) 18:57:54.147218 IP 91.198.174.239.53 > 192.168.200.100.21300: 12289*- 1/0/1 A 208.80.154.238 (62) 18:57:54.147532 IP 192.168.200.100.20861 > 208.80.153.231.53: 32464% [1au] ANY? wikipedia.com. (42) 18:57:54.163634 IP 91.198.174.239.53 > 192.168.200.100.31076: 53799*- 0/1/2 (109) 18:57:54.167263 IP 91.198.174.239.53 > 192.168.200.100.10913: 31592*- 1/0/1 A 91.198.174.239 (62) 18:57:54.174376 IP 91.198.174.239.53 > 192.168.200.100.29745: 41837*- 0/1/2 (113) 18:57:54.181264 IP 91.198.174.239.53 > 192.168.200.100.57528: 63523*- 1/0/1 A 208.80.153.231 (62) 18:57:54.186531 IP 91.198.174.239.53 > 192.168.200.100.37465: 5737*- 0/1/2 (113) 18:57:54.421467 IP 208.80.153.231.53 > 192.168.200.100.20861: 32464*- 9/0/1 A 208.80.154.224, AAAA 2620:0:861:ed1a::1, SOA, NS ns2.wikimedia.org., NS ns0.wikimedia.org., NS ns1.wikimedia.org., MX polonium.wikimedia.org. 10, MX lead.wikimedia.org. 50, TXT "google-site-verification=AMHkgs-4ViEvIJf5znZle-BSE2EPNFqM1nDJGRyn2qk" (327) 18:57:54.421982 IP 192.168.200.100.30469 > 192.112.36.4.53: 16762% [1au] DS? com. (32) 18:57:54.422075 IP 192.168.200.100.45579 > 192.112.36.4.53: 22093% [1au] NS? . (28) 18:57:54.646574 IP 192.112.36.4.53 > 192.168.200.100.45579: 22093*- 14/0/25 NS g.root-servers.net., NS j.root-servers.net., NS m.root-servers.net., NS d.root-servers.net., NS a.root-servers.net., NS l.root-servers.net., NS f.root-servers.net., NS k.root-servers.net., NS c.root-servers.net., NS e.root-servers.net., NS i.root-servers.net., NS b.root-servers.net., NS h.root-servers.net., RRSIG (913) 18:57:54.653260 IP 192.112.36.4.53 > 192.168.200.100.30469: 16762*- 2/0/1 DS, RRSIG (239) 18:57:54.653838 IP 192.168.200.100.63771 > 192.36.148.17.53: 55236% [1au] DS? wikipedia.com. (42) 18:57:54.892686 IP 192.36.148.17.53 > 192.168.200.100.63771: 55236- 0/15/16 (737) 18:57:54.893120 IP 192.168.200.100.49116 > 192.12.94.30.53: 17433% [1au] DS? wikipedia.com. (42) 18:57:55.207575 IP 192.12.94.30.53 > 192.168.200.100.49116: 17433*- 0/6/1 (766) 18:57:55.208000 IP 192.168.200.100.51033 > 192.42.93.30.53: 50748% [1au] DNSKEY? com. (32) 18:57:55.511119 IP 192.42.93.30.53 > 192.168.200.100.51033: 50748*- 3/0/1 DNSKEY, DNSKEY, RRSIG (743) [...] ==== BIND como servidor cache ==== As bibliotecas do resolvedor da maioria dos sistemas operacionais não são capazes de executar o processo de resolução completo, chamado recursivo. Ao invés disso elas dependem de um servidor intermediário com essa capacidade. Quando nos conectamos de casa diretamente à Internet, o serviço DHCP do provedor se encarrega de nos atribuir o endereço de seus servidores cache. Caso contrário, nosso resolver não teria a quem consultar e não conseguiríamos navegar. No entanto, muitos administradores de rede utilizam os IPs desses provedores para configurar várias estações de trabalho de uma rede. O efeito disto é que cada estação vai fazer suas próprias consultas individuais, multiplicando o volume de dados trafegados através do link de Internet, desperdiçando tempo e ocupando largura de banda. Quanto maior a rede, maior o impacto. A alternativa para evitar estes problemas é manter um servidor DNS caching only. Servidores cache reservam o resultado de suas buscas na memória pelo tempo limite estabelecido pela autoridade sobre o domínio consultado. Dessa forma, independente da quantidade de máquinas da rede, as consultas serão feitas na Internet apenas uma vez a cada intervalo de atualização. Nosso servidor recém instalado já está operando como servidor cache. Faça uma consulta e verifique o Query time. Repita o procedimento: # dig @localhost -t soa kernel.org | tail -n6 ;; Query time: 851 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Jun 04 19:35:32 BRT 2015 ;; MSG SIZE rcvd: 216 # dig @localhost -t soa kernel.org | tail -n6 ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Jun 04 19:35:53 BRT 2015 ;; MSG SIZE rcvd: 216 Para que a partir de agora todas as nossas aplicações utilizem o potencial de nosso servidor cache, edite o arquivo /etc/resolv.conf e mantenha apenas as linhas a seguir: # vim /etc/resolv.conf nameserver 127.0.0.1 * DICA: Não é necessária a configuração deste arquivo, pois mesmo sem ele o servidor continua efetuando as consultas e resolvendo os nomes, além de fazer cache! A fim de termos uma maior segurança em relação às mudanças do arquivo /etc/resolv.conf, podemos adicionar um atributo de proteção a ele, não permitindo qualquer tipo de alteração: # chattr +i /etc/resolv.conf ==== Tipos de zonas e Registros ==== Em relação às zonas, o BIND pode operar de acordo com 6 tipos: master, slave, stub, hint, forward e delegation-only. * master - O BIND vai responder como autoridade sobre aquele domínio. Os dados da zona serão criados, publicados e administrados a partir dele. * slave - O BIND também vai responder por esse domínio, mas nenhuma criação ou alteração respectiva a essa zona será feita localmente neste servidor. Os dados serão sempre transferidos de um servidor master. * stub - Este tipo de zona não é previsto em nenhuma RFC e foi implementado apenas no BIND. Assemelha-se a uma zona slave mas replica do master apenas os registros do tipo NS. Em desuso. * hint - Específica para o BIND onde ele deve começar uma busca recursiva quando estiver operando como cache. Por padrão, há uma zona hint criada com os endereços dos 13 root servers. * forward - Serve para orientar o BIND a encaminhar a consulta sobre uma determinada zona para outro servidor em especial. O encaminhamento de consultas também pode ser especificado de maneira global no arquivo named.conf.options. * delegation-only - Para evitar abusos de algumas autoridades sobre domínios de primeiro nível como COM, NET, ORG, etc., o BIND mantém o tipo de zona delegação apenas. Qualquer resposta que não tenha uma delegação explícita ou implícita na seção autoridade será transformada em uma resposta NXDOMAIN. Vamos configurar nossa zona DNS: martins.net Pode ser que na Internet já exista um domínio com este nome, mas isso não importa porque nossas consultas ficarão limitadas a nossa rede interna. As zonas devem ser declaradas no arquivo /etc/bind/named.conf.local. Uma zona mestre precisa, no mínimo, do nome do domínio, tipo de zona e o caminho para o banco de dados de registros. Quando apenas o nome do arquivo é citado, o servidor BIND vai procurá-lo no diretório definido na opção directory, do arquivo /etc/bind/named.conf.options. Isso significa que, por padrão, o caminho completo corresponderia a /var/cache/bind/db.martins.net. O conteúdo do banco de dados da zona que foi declarado será principalmente uma série de registros de recursos (resources records), ou simplesmente, registros. No entanto, três diretivas são suportadas: * $TTL * $ORIGIN * $INCLUDE Um registro tem o seguinte formato: dono [TTL] [classe] tipo dados. * dono - É o nome do registro. Quando substituído pelo símbolo @, o dono é o próprio domínio. Caso o dono fique em branco, o BIND assume o nome do registro imediatamente superior; * TTL - Um valor, em segundos, para a permanência dos dados deste registro no cache de um servidor. Raramente utilizado. * classe - Podem ser CH, HS ou IN. O padrão é IN, de Internet, e não precisa ser declarada. CH = CHAOS e HS = Hesiod. * tipo - No momento existem mais de 30 tipos de registro, dentre os quais veremos SOA, NS, MX, A, CNAME, TXT e PTR. * dados - Diferentes tipos de dados são definidos para diferentes tipos de registros. Para um registro tipo A temos um endereço IP por exemplo. Registros do tipo TXT tem sido usados para aumentar o controle contra spams. São criados de acordo com o formato definido pelo projeto SPF - Sender Policy Framework, ou simplesmente SPF. O SPF diz quais servidores podem enviar e-mails em nome do seu domínio. O objetivo é evitar que seu domínio seja usado para forjar remetentes falsos. Grandes provedores já adotaram o SPF e cada vez mais outros domínios vem seguindo a mesma prática. Tende a tornar-se uma imposição. Muito mais antigo que o SPF, e por consequência, uma imposição natural do ecossistema de e-mails, é garantir que o IP do registro MX tenha endereço reverso. Esta é uma forma de checar se o e-mail partiu de um usuário doméstico cujo computador está sendo usado como zumbi, por exemplo. Normalmente, configurar o endereçamento reverso não depende do administrador do domínio, mas sim do provedor do link. Porém, é possível requisitar autoridade sobre o bloco de IPs destinado àquele link. Vai depender do provedor. Mas como em nosso caso estamos utilizando apenas endereços privados, vamos assumir a autoridade sobre todo o bloco 192.168.200.0/24. ==== Configuração do DNS primário ==== Antes de checar como está o nosso ambiente... Configuração de rede: # cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.200.100 netmask 255.255.255.0 gateway 192.168.200.1 Hostname e arquivo hosts # cat /etc/hostname ns1.martins.net # cat /etc/hosts 127.0.0.1 localhost 192.168.200.100 ns1.martins.net ns1 # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters Agora vamos criar nossa zona # cat /etc/bind/named.conf.local // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; zone "martins.net" { type master; file "db.martins.net"; }; zone "200.168.192.in-addr.arpa" { type master; file "rev.martins.net"; }; Vamos checar os arquivos de configuração para ver se não tem erros: # named-checkconf * Se não houver mensagem na saída do comando está tudo ok Agora criaremos o banco de dados de registros de DNS direta e reversa # cat /var/cache/bind/db.martins.net $TTL 86400 @ IN SOA ns1.martins.net. root.martins.net. ( 2015060401 ;Serial 3600 ;Refresh 1800 ;Retry 604800 ;Expire 86400 ;Minimum TTL ) ; @ IN A 192.168.200.220 ;sitio: www.martins.net ; @ IN NS ns1.martins.net. @ IN MX 10 mail.martins.net. ; ns1.martins.net. IN A 192.168.200.100 ; mail.martins.net. IN A 192.168.200.240 smtp.martins.net. IN CNAME mail.martins.net. pop.martins.net. IN CNAME mail.martins.net. imap.martins.net. IN CNAME mail.martins.net. ; www.martins.net. IN CNAME @ ftp.martins.net. IN CNAME @ # cat /var/cache/bind/rev.martins.net $TTL 86400 @ IN SOA ns1.martins.net. root.martins.net. ( 2015060401 ;Serial 3600 ;Refresh 1800 ;Retry 604800 ;Expire 86400 ;Minimum TTL ) ; @ IN NS ns1.martins.net. ; 240 IN PTR mail.martins.net. Sobre o registro SOA, vão algumas explicações: * serial - É a referência para os slaves saberem se a zona sofreu alterações; * refresh - Tempo que o servidor secundário vai aguardar até checar se há atualizações no servidor primário; * retry - Em caso de falha do refresh, o tempo até a próxima verificação; * expire - O tempo que o secundário aguardará o primário voltar, se esgotar, o secundário pára de responder por essa zona; * negative caching TTL - Se a zona expirar, esse será o tempo pelo qual um servidor cache armazenará a informação NXDOMAIN antes de iniciar uma nova busca recursiva. O máximo são 3 horas. Agora vamos checar a configuração da zona que temos autoridade: # named-checkzone martins.net. /var/cache/bind/db.martins.net zone martins.net/IN: loaded serial 2015060401 OK # named-checkzone 200.168.192.in-addr.arpa. /var/cache/bind/rev.martins.net zone 200.168.192.in-addr.arpa/IN: loaded serial 2015060401 OK Reinicie o serviço do Bind9: # systemctl restart bind9.service Verificando o status do bind # systemctl status bind9.service ● bind9.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/bind9.service; enabled) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf-$named.conf Active: active (running) since Qui 2015-06-04 20:56:27 BRT; 23s ago Docs: man:named(8) Process: 904 ExecStop=/usr/sbin/rndc stop (code=exited, status=0/SUCCESS) Main PID: 909 (named) CGroup: /system.slice/bind9.service └─909 /usr/sbin/named -f -u bind Jun 04 20:56:27 ns1.martins.net named[909]: command channel listening on ::1#953 Jun 04 20:56:27 ns1.martins.net named[909]: managed-keys-zone: loaded serial 2 Jun 04 20:56:27 ns1.martins.net named[909]: zone 0.in-addr.arpa/IN: loaded serial 1 Jun 04 20:56:27 ns1.martins.net named[909]: zone 127.in-addr.arpa/IN: loaded serial 1 Jun 04 20:56:27 ns1.martins.net named[909]: zone 255.in-addr.arpa/IN: loaded serial 1 Jun 04 20:56:27 ns1.martins.net named[909]: zone 200.168.192.in-addr.arpa/IN: loaded serial 2015060401 Jun 04 20:56:27 ns1.martins.net named[909]: zone localhost/IN: loaded serial 2 Jun 04 20:56:27 ns1.martins.net named[909]: zone martins.net/IN: loaded serial 2015060401 Jun 04 20:56:27 ns1.martins.net named[909]: all zones loaded Jun 04 20:56:27 ns1.martins.net named[909]: running Vamos fazer alguns testes envolvendo nossos domínios e o comando dig: Antes de testarmos o comando dig, devemos saber o significado de algumas siglas, facilitando assim o entendimento e melhor aproveitamento deles. * SOA - Start Of Authotity(Autoridade inicial): Indica onde começa a autoridade da zona; * NS - Name Server(Servidor de nomes): Indica um servidor de nomes para a zona; * A - Address(Endereço IP): Mapeamento de nome a endereço (IPv4); * AAAA - Address(Endereço IP): Mapeamento de nome a endereço (IPv6); * MX - Mail eXchanger(Smtp): Indica um mail exchenger para um nome(servidor de email); * CNAME - Cononial Name(Alias): Mapeia um nome alternativo(apelido); * PTR - Poiter Record(IP reverso); * TXT - Texto: descritivo referente a um registro. # dig -t SOA martins.net ; <<>> DiG 9.9.5-9-Debian <<>> -t SOA martins.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45435 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;martins.net. IN SOA ;; ANSWER SECTION: martins.net. 86400 IN SOA ns1.martins.net. root.martins.net. 2015060401 3600 1800 604800 86400 ;; AUTHORITY SECTION: martins.net. 86400 IN NS ns1.martins.net. ;; ADDITIONAL SECTION: ns1.martins.net. 86400 IN A 192.168.200.100 ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 04 21:00:02 BRT 2015 ;; MSG SIZE rcvd: 115 Vamos testar as configurações referente ao e-mail: # dig -t MX martins.net ; <<>> DiG 9.9.5-9-Debian <<>> -t MX martins.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7788 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;martins.net. IN MX ;; ANSWER SECTION: martins.net. 86400 IN MX 10 mail.martins.net. ;; AUTHORITY SECTION: martins.net. 86400 IN NS ns1.martins.net. ;; ADDITIONAL SECTION: mail.martins.net. 86400 IN A 192.168.200.240 ns1.martins.net. 86400 IN A 192.168.200.100 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 04 21:01:04 BRT 2015 ;; MSG SIZE rcvd: 111 Testando a resposta reversa # dig -x 192.168.200.240 ; <<>> DiG 9.9.5-9-Debian <<>> -x 192.168.200.240 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46976 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;240.200.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 240.200.168.192.in-addr.arpa. 86400 IN PTR mail.martins.net. ;; AUTHORITY SECTION: 200.168.192.in-addr.arpa. 86400 IN NS ns1.martins.net. ;; ADDITIONAL SECTION: ns1.martins.net. 86400 IN A 192.168.200.100 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 04 21:04:00 BRT 2015 ;; MSG SIZE rcvd: 121 ==== Servidor Secundário ==== Para registrarmos um domínio público, precisamos de pelo menos dois servidores DNS respondendo pelo seu domínio. Isso significa um servidor master (mestre) e pelo menos um servidor slave (escravo). A exigência é uma forma de garantir que seu domínio estará sempre disponível. Se um servidor parar, o outro continua respondendo. Se os servidores estiverem geograficamente separados, isto garante ainda mais disponibilidade, pois mesmo que um link caia, o outro certamente ainda estará disponível. Na verdade, um mesmo servidor rodando BIND pode ser ao mesmo tempo mestre para alguns domínios, escravo para outros, e cache para todo o resto. Sendo assim, vamos efetuar a instalação do Bind9 numa outra máquina para servir de escravo (secundário). Antes de configuramos a máquina slave, vamos deixar nosso bind autorizado a transferir as zonas para esta máquina(192.168.200.101 dns slave). Acrescente no arquivo named.conf.local (192.168.200.100 - dns master): # cat /etc/bind/named.conf.local [...] zone "martins.net" { type master; file "db.martins.net"; allow-transfer { 192.168.200.101; }; notify yes; also-notify { 192.168.200.101; }; }; zone "200.168.192.in-addr.arpa" { type master; file "rev.martins.net"; allow-transfer { 192.168.200.101; }; notify yes; also-notify { 192.168.200.101; }; }; Explicando as inclusões: * allow-transfer - para transferir a zona para o secundário. * notify yes - o servidor mestre envia uma mensagem DNS NOTIFY para os servidores escravos para fazê-los conferir o arquivo de zona imediatamente. Isso é feito para manter o banco de dados mestre e escravo firmemente sincronizados. * also-notify - diz para o servidor também notificar o endereço fornecido entre chaves. Devemos configurar também o arquivo de registro da zona DNS dos domínios que temos autoridade. # cat /var/cache/bind/db.martins.net $TTL 86400 @ IN SOA ns1.martins.net. root.martins.net. ( 2015060401 ;Serial 3600 ;Refresh 1800 ;Retry 604800 ;Expire 86400 ;Minimum TTL ) ; @ IN A 192.168.200.220 ;sitio: www.martins.net ; @ IN NS ns1.martins.net. @ IN NS ns2.marrtins.net. @ IN MX 10 mail.martins.net. ; ns1.martins.net. IN A 192.168.200.100 ns2.martins.net. IN A 192.168.200.101 ; mail.martins.net. IN A 192.168.200.240 smtp.martins.net. IN CNAME mail.martins.net. pop.martins.net. IN CNAME mail.martins.net. imap.martins.net. IN CNAME mail.martins.net. ; www.martins.net. IN CNAME @ ftp.martins.net. IN CNAME @ # cat /var/cache/bind/rev.martins.net $TTL 86400 @ IN SOA ns1.martins.net. root.martins.net. ( 2015060401 ;Serial 3600 ;Refresh 1800 ;Retry 604800 ;Expire 86400 ;Minimum TTL ) ; @ IN NS ns1.martins.net. @ IN NS ns2.martins.net. ; 240 IN PTR mail.martins.net. Reinicie o Bind: # systemctl restart bind9.service Vamos agora efetuar a instalação e configuração do Bind9 no Slave Antes vamos checar nosso ambiente Configuração de rede # cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.200.101 netmask 255.255.255.0 gateway 192.168.200.1 dns-nameservers 8.8.8.8 Hostname e arquivo hosts # hostnamectl status Static hostname: ns2.martins.net Icon name: computer-vm Chassis: vm Machine ID: 9150d0eb9e7946b78c3b621bd3143aae Boot ID: 05871afea3f542359054a2d92f519692 Virtualization: oracle Operating System: Debian GNU/Linux 8 (jessie) Kernel: Linux 3.16.0-4-586 Architecture: x86 # cat /etc/hosts 127.0.0.1 localhost 192.168.200.101 ns2.martins.net ns2 # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters Instalando o bind9 # apt-get install bind9 dnsutils * Depois da instalação podemos remover a entrada de dns das configurações de rede e alterar o resolv.conf já que apartir de agora as consulta seram realizadas através do nosso dns. # cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.200.101 netmask 255.255.255.0 gateway 192.168.200.1 # vim /etc/resolv.conf nameserver 127.0.0.1 # chattr +i /etc/resolv.conf Agora abra o arquivo de declaração de zonas e insira o seguinte: # vim /etc/bind/named.conf.local // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; zone "martins.net" { type slave; file "db.martins.net"; masters { 192.168.200.100; }; }; zone "200.168.192.in-addr.arpa" { type slave; file "rev.martins.net"; masters { 192.168.200.100; }; }; * É importante ressaltar que não é necessário criar os arquivos especificados pelas opções file pois eles serão transferidos automaticamente do servidor master para o servidor slave. Reinicie o Bind9: # systemctl restart bind9.service Verificando o status # systemctl status bind9.service ● bind9.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/bind9.service; enabled) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf-$named.conf Active: active (running) since Qui 2015-06-04 21:45:02 BRT; 28s ago Docs: man:named(8) Process: 2039 ExecStop=/usr/sbin/rndc stop (code=exited, status=0/SUCCESS) Main PID: 2044 (named) CGroup: /system.slice/bind9.service └─2044 /usr/sbin/named -f -u bind Jun 04 21:45:02 ns2.martins.net named[2044]: transfer of 'martins.net/IN' from 192.168.200.100#53: connected using 192.168.200.101#48304 Jun 04 21:45:02 ns2.martins.net named[2044]: zone martins.net/IN: transferred serial 2015060401 Jun 04 21:45:02 ns2.martins.net named[2044]: transfer of 'martins.net/IN' from 192.168.200.100#53: Transfer completed: 1 messages, 14 reco...tes/sec) Jun 04 21:45:02 ns2.martins.net named[2044]: zone martins.net/IN: sending notifies (serial 2015060401) Jun 04 21:45:03 ns2.martins.net named[2044]: zone 200.168.192.in-addr.arpa/IN: Transfer started. Jun 04 21:45:03 ns2.martins.net named[2044]: transfer of '200.168.192.in-addr.arpa/IN' from 192.168.200.100#53: connected using 192.168.200.101#42721 Jun 04 21:45:03 ns2.martins.net named[2044]: zone 200.168.192.in-addr.arpa/IN: transferred serial 2015060401 Jun 04 21:45:03 ns2.martins.net named[2044]: transfer of '200.168.192.in-addr.arpa/IN' from 192.168.200.100#53: Transfer completed: 1 mess...tes/sec) Jun 04 21:45:03 ns2.martins.net named[2044]: zone 200.168.192.in-addr.arpa/IN: sending notifies (serial 2015060401) Jun 04 21:45:03 ns2.martins.net named[2044]: error (network unreachable) resolving 'ns2.marrtins.net/AAAA/IN': 2001:503:a83e::2:30#53 Hint: Some lines were ellipsized, use -l to show in full. * Observe que já houve a transferência da zona, que podemos podemos confirmar acompanhando os logs... # tail -f /var/log/daemon.log Jun 4 21:45:02 ns2 named[2044]: transfer of 'martins.net/IN' from 192.168.200.100#53: connected using 192.168.200.101#48304 Jun 4 21:45:02 ns2 named[2044]: zone martins.net/IN: transferred serial 2015060401 Jun 4 21:45:02 ns2 named[2044]: transfer of 'martins.net/IN' from 192.168.200.100#53: Transfer completed: 1 messages, 14 records, 332 bytes, 0.001 secs (332000 bytes/sec) Jun 4 21:45:02 ns2 named[2044]: zone martins.net/IN: sending notifies (serial 2015060401) Jun 4 21:45:03 ns2 named[2044]: zone 200.168.192.in-addr.arpa/IN: Transfer started. Jun 4 21:45:03 ns2 named[2044]: transfer of '200.168.192.in-addr.arpa/IN' from 192.168.200.100#53: connected using 192.168.200.101#42721 Jun 4 21:45:03 ns2 named[2044]: zone 200.168.192.in-addr.arpa/IN: transferred serial 2015060401 Jun 4 21:45:03 ns2 named[2044]: transfer of '200.168.192.in-addr.arpa/IN' from 192.168.200.100#53: Transfer completed: 1 messages, 5 records, 189 bytes, 0.001 secs (189000 bytes/sec) Jun 4 21:45:03 ns2 named[2044]: zone 200.168.192.in-addr.arpa/IN: sending notifies (serial 2015060401) Jun 4 21:45:03 ns2 named[2044]: error (network unreachable) resolving 'ns2.marrtins.net/AAAA/IN': 2001:503:a83e::2:30#53 Podemos confirmar também listando os arquivos existentes no diretório onde o bind armazena as bases das zonas. # ls -lha /var/cache/bind/ total 20K drwxrwxr-x 2 root bind 4,0K Jun 4 21:45 . drwxr-xr-x 9 root root 4,0K Jun 4 21:34 .. -rw-r--r-- 1 bind bind 687 Jun 4 21:45 db.martins.net -rw-r--r-- 1 bind bind 720 Jun 4 21:35 managed-keys.bind -rw-r--r-- 1 bind bind 281 Jun 4 21:45 rev.martins.net