wiki v1

User Tools

Site Tools

Trace: • tnat • google_cloud_terraform • pldap • kubectl_set • install_ipa_oracle_linux • dnsdebian8
wikiv3:dnsdebian8

Table of Contents

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
wikiv3/dnsdebian8.txt · Last modified: by 127.0.0.1