Apostila Servidor DNS - Primário

4452
Linux Security Servers in Cloud
www.4linux.com.br
Projetos na sua empresa

com a qualidade dos treinamentos
ence
Business Intelig lx8
F
u/
.m
va
http://
BPM
http://va.mu/EuiT
Servidor Java EE
http://va.mu/FlyB
PostgreSQL
http://va.mu/EuhV
Monitoramento
http://va.mu/EukN
Virtualizao
http://va.mu/Flxl
Groupware Yj
u/FN
http://va.m
Backup
http://va.mu/Flxr
Auditoria e Anlise
http://va.mu/Flxu
Segurana
http://va.mu/Flxy
Ensino Distncia
http://va.mu/Flxc
Integrao Continua
http://va.mu/FlyD
GED - ECM
http://va.mu/Flx3
Alta Disponibilidade
http://va.mu/FNbL
Infraestrutura Web
http://va.mu/Flxi
Implantao garantida
http://va.mu/GcFv
Contedo
3 Servidor DNS - Primrio
3.1
3.2
3.3
Introduo terica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1
Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2
Resoluo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3
Resoluo Recursiva . . . . . . . . . . . . . . . . . . . . . .
3.1.4
Resoluo Iterativa
3.1.5
O arquivo hosts
3.1.6
Ferramentas de consulta . . . . . . . . . . . . . . . . . . . . 13
. . . . . . . . . . . . . . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . . . . . . . 11
Introduo ao BIND + Implementao prtica
. . . . . . . . . . . . . . 18
3.2.1
BIND como servidor cache . . . . . . . . . . . . . . . . . . . 20
3.2.2
Tipos de zonas e Registros . . . . . . . . . . . . . . . . . . . 22
3.2.3
DNS VIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4
Configuraes iniciais do VIEW . . . . . . . . . . . . . . . . 26
3.2.5
Configurao do DNS primrio . . . . . . . . . . . . . . . . . 26
FIREWALL
3.3.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Configurando o RNDC . . . . . . . . . . . . . . . . . . . . . . 34
Captulo 3
Servidor DNS - Primrio
3.1 Introduo terica
Durante os anos 70, Arpanet era uma pequena comunidade de algumas centenas
de hosts. Um nico arquivo, HOSTS.TXT, continha toda a informao necessria
sobre os hosts. Este arquivo continha nome para enderear cada host conectado a
ARPANET.
O arquivo era mantido pela Network Information Center (NIC) e distribudo por um
nico host, Stanford Research Institutes Network Information Center (SRI-NIC). Os
administradores da ARPANET enviavam ao NIC, por e-mail, quaisquer mudanas
que tivessem sido efeituadas e periodicamente SRI-NIC era atualizado, assim como
o arquivo HOSTS.TXT. As mudanas eram compiladas em um novo HOSTS.TXT
uma ou duas vezes por semana. Com o crescimento da ARPANET, entretanto, este
esquema tornou-se invivel. O tamanho do arquivo HOST.TXT crescia na proporo
em que crescia o nmero de hosts. Alm disso, o trfego gerado com o processo
de atualizao crescia em propores ainda maiores uma vez que cada host que era
includo no s significava uma linha a mais no arquivo HOST.TXT, mas um outro
host atualizando a partir do SRI-NIC.
E quando a ARPANET passou a usar protocolos TCP/IP, a populao da rede "explodiu". E passaram a existir alguns problemas com o HOST.TXT:
4Linux www.4linux.com.br
3.1 Introduo terica
Nomes que coincidiam : dois hosts do arquivo HOSTS.TXT no podiam ter o

mesmo nome. Porm, apesar do NIC poder designar endereos nicos para
cada host, ele no tinha nenhuma autoridade sobre os nomes dados aos mesmos. No havia nada que pudesse evitar que algum adicionasse um host com
um nome conflitante, interrompendo o sistema de algum outro host j existente.
Consistncia : manter a consistncia do arquivo com a rede se expandindo

quelas propores se tornou cada vez mais difcil. Quando o arquivo conseguia conter todos os hosts, algum host trocava de endereo ou um novo host
adicionado tinha quebrado a conexo do host que se desejava acessar. Ironicamente, o sucesso da ARPANET tornou o arquivo HOSTS.TXT falho e obsoleto.
Os administradores da ARPANET tentaram outras configuraes que resolvessem o

problema do HOST.TXT. O objetivo era criar um sistema que resolvesse os problemas
em uma tabela nica de hosts. O novo sistema deveria: Permitir que o administrador
local tornasse os dados mundialmente disponveis; Descentralizar a administrao
a fim de resolver o problema do gargalo gerado por um nico host, diminuindo o
problema do trfego. Alm disso, o fato da administrao ser local iria fazer com
que a atualizao dos dados se tornasse uma tarefa bem mais simples; O esquema
deveria usar nomes em hierarquia para garantir a exclusividade dos nomes.
Paul Mockapetris, do USCs Information Science Institute, foi o responsvel pela

arquitetura do sistema. Em 1984 ele lanou o RFCs 882 e 883, que descreve o
"Domain Name System", ou DNS. Estes RFCs foram sucedidos pelos RFCs 1034 e
1035, que possuem as especificaes atuais do DNS.
http://www.gta.ufrj.br/grad/anteriores98/dns-ticiana/historia.htm
Pgina 7
3.1 Introduo terica
3.1.1 Caractersticas
Banco de dados hierrquico e distribudo representado no formato de uma rvore invertida e 127 nveis;
"Namespace"de at 63 caracteres;
Capacidade de associar outras informaes a um "host"e no s seus endereos IPs;
Arquitetura cliente/servidor;
Os clientes so chamados "resolvers"e costumam ser bibliotecas do sistema
operacional ("libresolv"no Gnu/Linux) compartilhadas entre os mais diversos
programas, como "ping"ou o navegador web;
Do outro lado esto os servidores de nome "DNS", os "DNS nameserver";
A raiz da rvore tem nome nulo ou , por isso a representamos simplesmente
como ponto (.);
Os ns abaixo do domnio raiz so chamados domnios de nvel mais elevado TLD (top level domains);
Sua quantidade e nomes so impostos pela ICANN - Internet Corporation for
Assigned Names and Numbers;
Eles so divididos em "gTLD"(domnios genricos "com", "edu", "gov", "mil",
etc) e "ccTLD"(cdigos de pases ou "country-code", sempre com duas letras);
A ICANN delega, de acordo com tratados internacionais, a responsabilidade
pela administrao de um "ccTLD";
Pgina 8
3.1 Introduo terica
No caso do Brasil, essa responsabilidade pertence atualmente ao "CGI.br",

mais especificamente ao "REGISTRO.br";
Uma vez delegado um domnio, sua nova autoridade pode delegar subdomnios
sem necessitar notificar a entidade responsvel pelo domnio pai;
Um subdomnio est para um subdiretrio assim como um domnio est para
um diretrio, e um "host"est para um arquivo;
Finalmente, vale a pena mencionar que o arquivo "HOSTS.TXT"foi portado para
o ambiente Unix e posteriormente para o Gnu/Linux como "/etc/hosts". Este arquivo normalmente o primeiro a ser consultado pelo resolvedor, que ir buscar por
um servidor de nomes apenas em caso de o "host"no ser encontrado no arquivo
"/etc/hosts".
3.1.2 Resoluo
Resoluo "DNS" o processo pelo qual um programa consulta dados a respeito de
um "hostname". Na grande maioria das vezes, consulta-se o endereo IP deste
"host"para ento efetuar algum tipo de conexo algum servio, como "HTTP",
"SMTP, "POP", dentre outros. O processo de resoluo, a partir do primeiro "nameserver"consultado, pode ser:
recursiva
iterativa
3.1.3 Resoluo Recursiva

Tomando um navegador web como exemplo, a resoluo para acesso a um "website"tem as seguintes etapas:
Pgina 9
3.1 Introduo terica
1.Usurio solicita acesso a "www.exemplo.com.br";

2.Navegador checa se j conhece o endereo IP do "hostname"solicitado (cache do
"browser");
3.Se no conhece, o navegador passa a solicitao para a biblioteca de resoluo o "resolver";
4.O "resolver"procura o "hostname"solicitado no arquivo "/etc/hosts"local;
5.Se no encontrar, ele checa o arquivo "/etc/resolv.conf"para saber a quais "nameservers"deve solicitar a informao;
6.O "resolver"repassa a solicitao ao primeiro "nameserver"da lista, e logo aps
para o prximo at o fim da lista, aguardando por uma resposta de qualquer um
deles;
7.O servidor de nomes acionado consulta seu "cache", se houver;
8.Se no encontrar em seu "cache", o servidor em questo vai diretamente ao servidor raiz e transfere a consulta - www.exemplo.com.br?;
9.O servidor raiz no faz "cache", e tambm no autoridade sobre zonas de baixo
nvel, ento ele apenas responde uma parte da questo: "No sei quem , mas sei
quem pode responder melhor: br.";
10.O servidor de nomes reenvia a consulta para o servidor ".br- www.exemplo.com.br?;
11.".br"retorna o mesmo tipo de resposta, porm como uma dica mais prxima: "No
sei quem , mas sei quem pode responder melhor: com.br.";
12.Passos 10 e 11 so efetuados mais uma vez, e agora a resposta "No sei quem
, mas sei quem pode responder melhor: exemplo.com.br.";
13.Aps repetir o passo 10, finalmente a resposta ser da autoridade sobre o domnio
Pgina 10
3.1 Introduo terica
exemplo.com.br. Vai ser respondido o IP, juntamente ao TTL do registro, ou ser

respondido "inexistente";
14.O servidor de nomes far "cache"da resposta, ao mesmo tempo que a repassa
para o resolvedor original;
15.O resolvedor repassa a resposta para o navegador;
16.O navegador inicia uma conexo "HTTP"com o IP descoberto.
Conceitos de DNS e a sua configurao em Gnu/Linux utilizando Bind9, so

cobrados na Prova do LPI 201 peso2.
3.1.4 Resoluo Iterativa
Enquanto o servidor "cache"do exemplo acima executa um processo recursivo de

consultas sucessivas descendo a rvore at a autoridade capaz de responder definitivamente ao questionamento apresentado, os servidores ".", "br.", "com.br.", apenas informam que conhecem algum mais preciso que eles. Essa uma consulta
iterativa. Iterao, nesse caso, significa "apontar para o mais prximo conhecido".
3.1.5 O arquivo hosts
Derivado do arquivo "HOSTS.TXT"original, aquele que era atualizado e distribudo

antes do surgimento do "Domain Name System", o arquivo "/etc/hosts"continua tendo
um papel muito importante no processo de resoluo. No passo a passo descrito
anteriormente, observe que ele a primeira fonte de consulta do "resolver".
Pgina 11
3.1 Introduo terica
Este comportamento pode ser modificado atravs do arquivo "/etc/nsswitch", porm,

isso s seria feito em um cenrio muito particular. Podemos considerar que quase a
totalidade dos sistemas "*nix"vo seguir a ordem de resoluo padro.
Sendo assim, bom conhecer a sintaxe desse arquivo:
Endereco_IP
Hostname_canonico
192.168.200.254
gateway . com . br
Aliases
gateway
Devemos colocar um endereo IP por linha, seguido de um endereo cannico e opcionalmente "aliases"(apelidos). O nome de "host"cannico pode ser qualquer nome
no formato "DNS", porm, em alguns casos, como o de servidores de e-mails, adequado que os IPs presentes nesta mquina tenham um "FQDN"pertinente. FQDN
(Fully Qualified Domain Name) um "hostname"que identifica, sem ambiguidade,
a posio daquele n dentro da rvore DNS.
Por esta razo, um "FQDN"deve terminar com um ".", que representa a raiz da rvore. Os "aliases"podem ser outros "hostnames"cannicos, ou simples sufixos, para
simplificar a escrita de determinados endereos. Aps a instalao do sistema, o arquivo "hosts"costuma conter uma entrada referente ao IP da interface "loopback", e
uma entrada para cada outra interface presente na mquina para qual um endereo
foi atribudo.
[http://gnulinuxbr.com/2010/05/04/domain-name-system-servidor-dns-nodebian-parte-1/ ]
Por exemplo:
127.0.0.1 localhost
192.168.1.50
Pgina 12
micro50 . dexter . com . br .
micro50
3.1 Introduo terica
Pode ser acrescentadas quantas entradas forem necessrias, inclusive para IPs externos. Atualmente, os sistemas baseados em Debian j contm entradas para endereamento "IPv6", que seguem a mesma lgica. Poder ver isto executando:
root@dmz :~ # cat / etc / hosts
...
# The following lines are desirable for IPv6 capable hosts
::1
fe00 ::0 ip6 - localnet
ff00 ::0 ip6 - mcastprefix
ff02 ::1 ip6 - allnodes
ff02 ::2 ip6 - allrouters
ip6 - localhost ip6 - loopback
3.1.6 Ferramentas de consulta

Caso ainda no estejam presentes, vamos instalar as ferramentas de pesquisa de
"DNS".
root@dmz :~ # aptitude install dnsutils
nslookup
A "ISC" (Internet Systems Consortium - www.isc.org) diz, literalmente, no manual
de utilizao do BIND: "Devido a sua interface misteriosa e frequente comportamento inconsistente, ns no recomendamos o uso do "nslookup". Usem o
"dig"no lugar dele".
Porm, o pacote mantido pela prpria ISC em nome da legio de administradores
que se habituaram a utilizar o "nslookup"como ferramenta de resoluo de problemas.
Pgina 13
3.1 Introduo terica
Dentre suas vantagens est o fato de ter uma biblioteca de resoluo independente
do sistema, e consultar um servidor por vez, dentre os listados no "/etc/resolv.conf".
Apesar da consulta ser mais lenta, torna a triagem mais controlvel. Dentre os problemas mais crnicos do "nslookup"esto: respostas confusas e erros indefinidos.
host
O comando "host" concebido para dar respostas objetivas, limitando-se na maioria

dos casos a uma s linha. Porm, repostas mais detalhadas podem ser obtidas com
a utilizao de parmetros. Ao contrrio do "dig", o "host"consulta a "search list"do
arquivo "/etc/resolv.conf".
dig
O comando "dig" o acrnimo para "Domain Information Groper", que significa algo
como "aquele que busca por informaes de domnio no escuro", e ao mesmo
tempo, a palavra "dig"em ingls significa literalmente "escavar". Acho que mencionar
estas curiosidades demonstra o esforo de imaginao dos criadores do "dig"e, no
toa, ele o comando de pesquisa mais poderoso no pacote de utilitrios "BIND".
No "dig"h dezenas de opes e incontveis combinaes entre elas, por isso consultar o "man"e, sobretudo, ter um forte domnio do funcionamento do sistema de
nomes de domnio, necessrio para dom-lo.
O "dig"no utiliza a opo "search"do "/etc/resolv.conf", por isso necessrio utilizar

"FQDN"em todas as buscas.
Antes de testarmos o comando dig, devemos saber o significado de algumas siglas,

facilitando assim o entendimento e melhor aproveitamento deles.
Pgina 14
3.1 Introduo terica
Vamos testar o "verborrgico"comando "dig":
root@dmz :~ # dig www .4 linux . com . br .
;; ->> HEADER < < - opcode : QUERY , status : NOERROR , id : 5930
;; flags : qr rd ra ; QUERY : 1 , ANSWER : 1 , AUTHORITY : 0 , ADDITIONAL : 0
;; QUESTION SECTION :
; www .4 linux . com . br .
;; ANSWER SECTION :
www .4 linux . com . br .
;; Query time : 392 msec
;; SERVER : 4.2.2.2 # 53(4.2.2.2)
10
IN
300 IN
A 66.118.142.41
...
root@dmz :~ # dig @8 .8.4.4 www .4 linux . com . br .
; www .4 linux . com . br .
;; ANSWER SECTION :
IN
300 IN
A
A 66.118.142.41
8
9
10

;; SERVER : 8.8.8.8 # 53(8.8.4.4)
Pgina 15
3.1 Introduo terica
11
...
root@dmz :~ # dig -t mx gmail . com .
; gmail . com .
;; ANSWER SECTION :
gmail . com .
1425
IN
MX
40 alt4 . gmail - smtp - in . l . google . com .
gmail . com .
1425
IN
MX
5 gmail - smtp - in . l . google . com .
gmail . com .
1425
IN
MX
10
gmail . com .
1425
IN
MX
11
gmail . com .
1425
IN
MX
12
IN
MX
13
;; SERVER : 8.8.8.8 # 53(4.2.2.2)
14
...
root@dmz :~ # dig -x 200.212.122.137
;137.122.212.200. in - addr . arpa .
;; ANSWER SECTION :
137.122.212.200. in - addr . arpa . 43200 IN
8
9
IN
PTR
CNAME 137.128 -
191.122.212.200. in - addr . arpa .

137.128 -191.122.212.200. in - addr . arpa . 3600 IN PTR boca .4 linux . com . br
.
10
11
;; SERVER : 8.8.8.8 # 53(4.2.2.2)
12
...
root@dmz :~ # dig + trace www .4 linux . com . br .
; <<>> DiG 9.7.3 <<>> + trace www .4 linux . com . br .
Pgina 16
3.1 Introduo terica
;; global options : + cmd
30820 IN
NS
h . root - servers . net .
30820 IN
NS
l . root - servers . net .
30820 IN
NS
m . root - servers . net .
30820 IN
NS
i . root - servers . net .
30820 IN
NS
j . root - servers . net .
30820 IN
NS
d . root - servers . net .
10
30820 IN
NS
f . root - servers . net .
11
30820 IN
NS
e . root - servers . net .
12
30820 IN
NS
c . root - servers . net .
13
30820 IN
NS
a . root - servers . net .
14
30820 IN
NS
b . root - servers . net .
15
30820 IN
NS
k . root - servers . net .
16
30820 IN
NS
g . root - servers . net .
17
;; Received 228 bytes from 4.2.2.2 # 53(4.2.2.2) in 132 ms
18
br .
172800
IN
NS
c . dns . br .
19
br .
172800
IN
NS
f . dns . br .
20
br .
172800
IN
NS
a . dns . br .
21
br .
172800
IN
NS
d . dns . br .
22
br .
172800
IN
NS
b . dns . br .
23
br .
172800
IN
NS
e . dns . br .
24
;; Received 287 bytes from 192.5.5.241 # 53( f . root - servers . net ) in 216
ms
25
4 linux . com . br .
86400 IN
NS
ns1 .4 linux . com . br .
26
86400 IN
NS
27
;; Received 103 bytes from 200.189.40.10 # 53( b . dns . br ) in 32 ms
28
29
60
IN
NS
ns1 . testdrive .4 linux . com . br .
30
60
IN
NS
31
60
IN
NS
32
;; Received 147 bytes from 200.212.122.137 # 53( ns1 .4 linux . com . br ) in
300 IN
A 66.118.142.41
44 ms
Pgina 17
3.2 Introduo ao BIND + Implementao prtica

O BIND (Berkeley Internet Name Domain) o servidor de nomes utilizado na
grande maioria dos servidores da Internet, provendo uma estvel e robusta arquitetura sobre a qual as organizaes podem construir sua estrutura de nomes. Ser
este servidor que iremos abordar no curso. Sua instalao bem simples:
root@dmz :~ # aptitude install bind9
O arquivo principal chama-se "/etc/bind/named.conf" mas contm apenas configuraes estticas. Ele utiliza a clusula 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 opes referentes ao funcionamento do
prprio "BIND", enquanto que o segundo serve para declarar todas as zonas pelas
quais este servidor deve responder.
root@dmz :~ # ls - lh / etc / bind
Alm dos arquivos citados acima, temos o arquivo "db.root"(no RedHat fica em "/var/named/named.ca") que relaciona os endereos dos 13 servidores raiz e lido como
"zona hint", que ser explicada adiante.
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 atribudas para efetuar consultas em outros servidores.
Vamos observar a recursividade e as portas envolvidas utilizando o "tcpdump", mas

antes vamos verificar as portas:
Pgina 18
root@dmz :~ # netstat - nltup
tcp
0
OU A
tcp
tcp
tcp
tcp6
tcp6
udp
0 127.0.0.1:53
0.0.0.0:*
0 127.0.0.1:953
0.0.0.0:*
0 :::53000
:::*
1033/ sshd
0
OU A
8
0.0.0.0:*
862/ named
OU A
7
0 192.168.200.3:53
862/ named
OU A
6
0.0.0.0:*
862/ named
OU A
5
0 0.0.0.0:53000
1033/ sshd
OU A
4
0 :::53
:::*
862/ named
0
0 192.168.200.3:53
0.0.0.0:*
862/ named
9
udp
0 127.0.0.1:53
0.0.0.0:*
862/ named
10
udp6
0 :::53
:::*
862/ named
Instale o sniffer tcpdump:
root@dmz :~ # aptitude install tcpdump
Execute o tcpdump para verificar os pacotes saindo de uma porta alta at a porta
53/udp de seu servidor:
root@dmz :~ # 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 65535

bytes
Pgina 19
Em outro terminal execute:
root@dmz :~ # dig @localhost -t any wikipedia . com
Verifique a sada do tcpdump:
19:11:52.396000 IP 192.168.200.3.33625 > 198.41.0.4.53: 12121 [1 au ]

ANY ? wikipedia . com . (42)
19:11:52.396000 IP 192.168.200.3.29726 > 192.33.4.12.53: 39309 [1 au ]

NS ? . (28)
19:11:52.544000 IP 192.33.4.12.53 > 192.168.200.3.29726: 39309* 14/0/23 NS m . root - servers . net . , NS d . root - servers . net . , NS h . root
- servers . net . , NS k . root - servers . net . , NS g . root - servers . net . , NS
i. root - servers . net . , NS b . root - servers . net . , NS j . root - servers .
net ., NS a . root - servers . net . , NS f . root - servers . net . , NS c . root servers . net . , NS l . root - servers . net . , NS e . root - servers . net . ,
RRSIG (857)
19:11:52.552000 IP 198.41.0.4.53 > 192.168.200.3.33625: 12121 0/15/16 (737)
Os logs de seu servidor DNS esto em "/var/log/daemon.log". Verifique-os:
root@dmz :~ # tail / var / log / daemon . log
3.2.1 BIND como servidor cache

As bibliotecas do resolvedor da maioria dos sistemas operacionais no so capazes
de executar o processo de resoluo completo, chamado recursivo, como vimos
acima. Ao invs disso elas dependem de um servidor intermedirio com essa capacidade. Quando nos conectamos de casa diretamente Internet, o servio "DHCP"do
Pgina 20
provedor se encarrega de nos atribuir o endereo de seus servidores cache. Caso

contrrio, nosso "resolver"no teria a quem consultar e no conseguiramos navegar.
No entanto, muitos administradores de rede utilizam os IPs desses provedores para
configurar vrias estaes de trabalho de uma rede. O efeito disto que cada estao vai fazer suas prprias consultas individuais, multiplicando o volume de dados
trafegados atravs do link de Internet, desperdiando 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 memria pelo tempo limite estabelecido pela autoridade sobre o domnio consultado. Dessa forma, independente da quantidade de mquinas
da rede, as consultas sero feitas na Internet apenas uma vez a cada intervalo de
atualizao.
Nosso servidor recm instalado j est operando como servidor "cache". Faa uma
consulta e verifique o Query time. Repita o procedimento:
root@dmz :~ # dig @localhost -t soa kernel . org | tail - n6
2
3
;; SERVER : 127.0.0.1 # 53(127.0.0.1)
;; WHEN : Mon Aug
;; MSG SIZE
6 11:47:36 2012
rcvd : 129
7
8
root@dmz :~ # dig @localhost -t soa kernel . org | tail - n6
9
10
11
;; SERVER : 127.0.0.1 # 53(127.0.0.1)
12
;; WHEN : Mon Aug
13
;; MSG SIZE
6 11:47:53 2012
rcvd : 129
Para que a partir de agora todas as nossas aplicaes utilizem o potencial de nosso
servidor "cache", edite o arquivo "/etc/resolv.conf" e mantenha apenas as linhas a
seguir:
Pgina 21
root@dmz :~ # vim / etc / resolv . conf
nameserver 192.168.200.3
DICA: No necessria a configurao deste arquivo, pois mesmo sem ele

o servidor continua efetuando as consultas e resolvendo os nomes, alm de fazer
cache!
A fim de termos uma maior segurana em relao s mudanas do arquivo /etc/resolv.conf, podemos adicionar um atributo de proteo a ele, no permitindo qualquer
tipo de alterao:
root@dmz :~ # chattr + i / etc / resolv . conf
3.2.2 Tipos de zonas e Registros

Em relao 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 domnio. Os dados
da "zona"sero criados, publicados e administrados a partir dele.
slave - O "BIND"tambm vai responder por esse domnio, mas nenhuma criao ou
alterao respectiva a essa "zona"ser feita localmente neste servidor. Os dados
sero sempre transferidos de um servidor "master".
stub - Este tipo de "zona"no 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.
Pgina 22
hint - Especfica para o "BIND"onde ele deve comear uma busca recursiva quando
estiver operando como "cache". Por padro, h uma "zona hint"criada com os endereos 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 tambm pode ser especificado de maneira global no arquivo "named.conf.options".
delegation-only - Para evitar abusos de algumas autoridades sobre domnios de
primeiro nvel como "COM", "NET", "ORG", etc., o "BIND"mantm o tipo de zona
"delegao apenas". Qualquer resposta que no tenha uma delegao explcita ou
implcita na seo autoridade ser transformada em uma resposta "NXDOMAIN".
Vamos configurar nossa zona DNS: dexter.com.br Pode ser que na Internet j exista
um domnio com este nome, mas isso no importa porque nossas consultas ficaro
limitadas a nossa rede interna.
As "zonas"devem ser declaradas no arquivo "/etc/bind/named.conf.local". Uma
"zona"mestre precisa, no mnimo, do nome do domnio, 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 diretrio definido na opo "directory", do arquivo
"/etc/bind/named.conf.options". Isso significa que, por padro, o caminho completo
corresponderia a "/var/cache/bind/db.dexter".
O contedo do banco de dados da "zona"que foi declarado ser principalmente uma
srie de registros de recursos ("resources records"), ou simplesmente, registros. No
entanto, trs diretivas so suportadas:
"$TTL"
"$ORIGIN"
"$INCLUDE"
Com exceo do "$TTL", as demais so raramente utilizadas.
Pgina 23
Um registro tem o seguinte formato: dono [TTL] [classe] tipo dados.
dono - o nome do registro. Quando substitudo pelo smbolo "@", o dono o

prprio domnio. Caso o dono fique em branco, o "BIND"assume o nome do registro
imediatamente superior;
TTL - Um valor, em segundos, para a permanncia dos dados deste registro no
"cache"de um servidor. Raramente utilizado.
classe - Podem ser "CH", "HS"ou "IN". O padro "IN", de Internet, e no 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 so definidos para diferentes tipos de registros.
Para um registro tipo "A"temos um endereo IP por exemplo.
Recentemente, registros do tipo "TXT"tem sido usados para aumentar o controle
contra "spams". So 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 domnio. O
objetivo evitar que seu domnio seja usado para forjar remetentes falsos. Grandes
provedores j adotaram o "SPF"e cada vez mais outros domnios vem seguindo a
mesma prtica. Tende a tornar-se uma imposio. Muito mais antigo que o "SPF",
e por consequncia, uma imposio natural do ecossistema de e-mails, garantir
que o IP do registro "MX" tenha endereo reverso. Esta uma forma de checar se
o e-mail partiu de um usurio domstico cujo computador est sendo usado como
"zumbi", por exemplo.
Normalmente, configurar o endereamento reverso no depende do administrador
Pgina 24
do domnio, mas sim do provedor do link. Porm, possvel requisitar autoridade

sobre o bloco de IPs destinado quele link. Vai depender do provedor. Mas como
em nosso caso estamos utilizando apenas endereos privados, vamos assumir a
autoridade sobre todo o bloco 192.168.200.0/24.
http://gnulinuxbr.com/2010/05/17/domain-name-system-%E2%80%93-
servidor-dns-no-debian-%E2%80%93-parte-3/ ]
3.2.3 DNS VIEW

Em alguns casos precisamos fazer regras de consultas diferentes de dns para um
mesmo host. Muitas vezes problemas com consultas de DNS em DMZ gera transtorno
aos administradores de rede principalmente ao iniciantes. Um dos maiores problemas acontece quando usamos DMZ com ips invlidos com apontamento DNAT de
up ip vlido, causando problemas de consulta na rede interna com a tradicional mensagem "Connect Refuse!"
Como resolver isso?
A resposta est em um recurso pouco conhecido chamado de DNS split com o View
ou simplesmente conhecido com DNS View.
O que o Split Horizon DNS?
"Split Horizon"DNS se refere prtica de separar o DNS em uma viso externa
e interna. Isso proporciona uma separao lgica entre as informaes de DNS
disponvel para clientes da rede interna e que disponibilizada ao pblico Internet
em geral. Ser capaz de enumerar esta informao um recurso inestimvel para
os possveis atacantes. Ao separar as informaes publicamente disponveis do que
exigido pelos clientes internos, acrescenta uma camada muito importante de proteo. Split Horizon DNS pode ser realizado em vrios mtodos, mas a separao
Pgina 25
em dispositivos fsicos ainda o preferido.

O que a View?
View um recurso de regras especfica para as query feita em uma zona, reagindo
de forma distinta para origens diferente de consulta. Ento podemos dizer que o view
faz com que o servidor responda de forma diferenciada para cada segmento da rede
tornado-se "inteligente".
3.2.4 Configuraes iniciais do VIEW

Para implementar o VIEW em um servidor de DNS necessrio que todas as zonas
pr existente
root@dmz :~ # sed 2 i " view \" all \" {" / etc / bind / named . conf . default zones -i
root@dmz :~ # sed 3 i " match - clients { none ;
};" / etc / bind / named . conf .
default - zones -i
root@dmz :~ # sed 32 i "};" / etc / bind / named . conf . default - zones -i
3.2.5 Configurao do DNS primrio

Agora iremos configurar o "Bind9", lembrando que estamos fazendo um teste interno,
restringindo as consultas apenas para a rede local, certifique-se de que os arquivos
"/etc/resolv.conf" e "/etc/hosts" estejam corretos. Vamos configurar as duas zonas
de nossos domnios no arquivo "/etc/bind/named.conf.local":
Pgina 26
root@dmz :~ # vim / etc / bind / named . conf . local
2
3
....
4
5
acl " lan_nets " {
192.168.200.0/24;
10.0.0.0/24;
};
9
10
view " externa " {
11
match - clients { ! lan_nets ; any ;
12
recursion yes ;
13
zone " dexter . com . br " {
14
type master ;
15
file " db . dexter . externa " ;
16
};
};
17
18
};
19
20
21
view " interna " {
22
match - clients { lan_nets ; 127 any ; };
23
recursion yes ;
24
zone " dexter . com . br " {
25
type master ;
26
file " db . dexter . interna " ;
27
};
28
29
};
Vamos checar os arquivos de configurao para ver se no tem erros:
root@dmz :~ # named - checkconf
Pgina 27
Agora criaremos o banco de dados de registros de "DNS", onde teremos servidores

de e-mail, web e ftp. Primeiro o domnio dexter.com.br.
root@dmz :~ # vim / var / cache / bind / db . dexter . externa
$TTL 86400 ; default para todos os registros sem TTL
3
4
IN
SOA
ns1 . dexter . com . br . root . dexter . com . br . (
YYYYMMDDNN ; serial
8 h ; refresh
1 h ; retry
3 d ; expire
3 h ) ; negative caching ttl
10
11
IN
NS
ns1 . dexter . com . br .
12
IN
MX
10 mail . dexter . com . br .
13
IN
200.100.50.99
14
ns1
IN
200.100.50.99
15
www
IN
200.100.50.99
16
ftp
IN
CNAME
www
17
mail
IN
200.100.50.99
18
smtp
IN
CNAME
mail
19
webmail
IN
CNAME
mail
20
pop
IN
CNAME
mail
21
imap
IN
CNAME
mail
Agora a View interna:
root@dmz :~ # vim / var / cache / bind / db . dexter . interna
$TTL 86400 ; default para todos os registros sem TTL
3
4
IN
SOA
ns1 . dexter . com . br . root . dexter . com . br . (
YYYYMMDDNN ; serial
8 h ; refresh
1 h ; retry
3 d ; expire
Pgina 28
3 h ) ; negative caching ttl
9
10
11
IN
NS
12
IN
MX
13
IN
192.168.200.3
14
ns1
IN
192.168.200.3
15
www
IN
192.168.200.3
16
ftp
IN
CNAME
www
17
mail
IN
192.168.200.3
18
smtp
IN
CNAME
mail
19
webmail
IN
CNAME
mail
20
pop
IN
CNAME
mail
21
imap
IN
CNAME
mail
22
ldap
IN
192.168.200.2
23
intranet
IN
CNAME
www
25
firewall
IN
192.168.200.1
26
datacenter
IN
192.168.200.2
27
dmz
IN
192.168.200.3
28
storage
IN
192.168.200.4
29
audit
30
fileserver
24
IN
A
IN
192.168.200.5
A
192.168.200.6
Sobre o registro "SOA", vo algumas explicaes:
serial - a referncia para os "slaves"saberem se a "zona"sofreu alteraes;
refresh - Tempo que o servidor secundrio vai aguardar at checar se h atualizaes

no servidor primrio;
retry - Em caso de falha do "refresh", o tempo at a prxima verificao;
expire - O tempo que o secundrio aguardar o primrio voltar, se esgotar, o secundrio pra de responder por essa zona;
Pgina 29
negative caching TTL - Se a zona expirar, esse ser o tempo pelo qual um servidor "cache"armazenar a informao "NXDOMAIN"antes de iniciar uma nova busca
recursiva. O mximo so 3 horas.
Se o comando retornar ao prompt significa que est correto! Agora vamos checar
a configurao da zona que temos autoridade:
root@dmz :~ # named - checkzone dexter . com . br . / var / cache / bind / db . dexter

. interna
zone dexter . com . br / IN : loaded serial 2012080701
OK
root@dmz :~ # named - checkzone dexter . com . br . / var / cache / bind / db . dexter

. externa
zone dexter . com . br / IN : loaded serial 2012080701
OK
Reinicie o servio do Bind9:
root@dmz :~ # service bind9 restart
Stopping domain name service ...: bind9 waiting for pid 1125 to die .
Starting domain name service ...: bind9 .
Vamos fazer alguns testes envolvendo nossos domnios e o comando dig:
root@dmz :~ # dig -t soa dexter . com . br
;; flags : qr aa rd ra ; QUERY : 1 , ANSWER : 1 , AUTHORITY : 1 , ADDITIONAL

: 1
4
5
; dexter . com . br .
IN
SOA
7
8
;; ANSWER SECTION :
Pgina 30
dexter . com . br .
86400 IN
SOA ns1 . dexter . com . br . root . dexter . com .
br . 2012080701 28800 3600 259200 10800

10
11
;; AUTHORITY SECTION :
12
dexter . com . br .
86400 IN
NS
13
14
;; ADDITIONAL SECTION :
15
86400 IN
A 192.168.200.3
16
17
18
;; SERVER : 127.0.0.1 # 53(127.0.0.1)
19
;; WHEN : Mon Aug
20
;; MSG SIZE
7 11:53:49 2012
rcvd : 106
Vamos testar as configuraes referente ao e-mail:
root@dmz :~ # dig -t mx dexter . com . br
;; flags : qr aa rd ra ; QUERY : 1 , ANSWER : 1 , AUTHORITY : 1 , ADDITIONAL

: 2
4
5
IN
MX
7
8
;; ANSWER SECTION :
dexter . com . br .
86400 IN
MX
NS
10
11
12
dexter . com . br .
86400 IN
13
14
15
mail . dexter . com . br . 86400 IN
A 192.168.200.3
16
A 192.168.200.3
86400 IN
17
18
19
;; SERVER : 127.0.0.1 # 53(127.0.0.1)
Pgina 31
3.3 FIREWALL
20
;; WHEN : Mon Aug
21
;; MSG SIZE
7 11:54:28 2012
rcvd : 102
Vamos efetuar um ping no domnio dexter.com.br:
root@dmz :~ # ping - c2 www . dexter . com . br
PING www . dexter . com . br (192.168.200.3) 56(84) bytes of data .
64 bytes from dmz . dexter . com . br (192.168.200.3) : icmp_req =1 ttl =64

time =0.025 ms
64 bytes from dmz . dexter . com . br (192.168.200.3) : icmp_req =2 ttl =64

time =0.031 ms
Reinicie o Bind9 novamente e verifique o log:
root@dmz :~ # tail -f / var / log / daemon . log
Aug
1 13:23:35 dmz named [1370]: zone localhost / IN : loaded serial 2
Aug
1 13:23:35 dmz named [1370]: managed - keys - zone ./ IN : loading

from master file managed - keys . bind failed : file not found
Aug
1 13:23:35 dmz named [1370]: managed - keys - zone ./ IN : loaded

serial
Aug
1 13:23:35 dmz named [1370]: running
Aug
1 13:23:35 dmz named [1370]: zone dexter . com . br / IN : sending

notifies ( serial 2012080701)
3.3 FIREWALL
Para que outros servidores utilizem nosso DNS habilite a passagem de pacotes no
firewall e tambm adicione um redirecionamento de porta, especificamente a porta
53 UDP, S para lembrar adicione no fim do escopo do start:
Pgina 32
3.3 FIREWALL
root@firewall :~ # vim / etc / init . d / firewall
...
# Para que o firewall use a DMZ para resolver nomes
iptables -A INPUT -p udp -- sport 53 -s $DMZ -d $FW -- dport $PA -j

ACCEPT
iptables -A OUTPUT -p udp -- sport $PA -s $FW -d $DMZ -- dport 53 -j

ACCEPT
6
7
# Passagem de pacotes do dns interno para o mundo
iptables -A FORWARD -p udp

j
-- sport 53 -s $DMZ
-d 0/0 -- dport $PA -
ACCEPT
iptables -A FORWARD -p udp -- sport $PA -s 0/0 -d $DMZ
-- dport 53 -j
ACCEPT
10
11
# Redirecionamento da porta 53 na maquina Firewall para DMZ
12
iptables -t nat -A PREROUTING -p udp -- sport $PA -s 0/0 -d $WAN1 -dport 53 -j DNAT --to - destination $DMZ :53
Teste o script
root@firewall :~ # service firewall restart
Para testar o DNS de um IP externo ao da nossa rede, na maquina externa execute:
root@maq - externa :~ # dig dexter . com . br @200 .100.50.99
; <<>> DiG 9.7.3 <<>> dexter . com . br @200 .100.50.99
;; global options : + cmd
;; Got answer :
;; flags : qr aa rd ; QUERY : 1 , ANSWER : 1 , AUTHORITY : 1 , ADDITIONAL : 1
7
8
IN
Pgina 33
3.3 FIREWALL
10
11
;; ANSWER SECTION :
12
dexter . com . br .
86400 IN
A 200.100.50.99
13
14
15
dexter . com . br .
86400 IN
NS
16
17
18
86400 IN
A 200.100.50.99
19
20
21
;; SERVER : 200.100.50.99 # 53(200.100.50.99)
22
;; WHEN : Tue Aug
23
;; MSG SIZE
7 19:32:04 2012
rcvd : 81
3.3.1 Configurando o RNDC

O comando rndc (Remote Named Daemon Control) uma ferramenta de gerenciamento do named. A vantagem dessa ferramenta que ela permite controlar o
named muito facilmente sem ter que ficar enviando sinais ao processo do mesmo.
Vamos limitar o seu uso apenas no prprio servidor, para isso vamos alterar o arquivo
/etc/bind/named.conf.local.
root@dmz :~ # vim / etc / bind / named . conf . local
include " / etc / bind / rndc . key " ;
controls {
inet 127.0.0.1 port 953 allow { localhost ; } keys { " rndc - key " ; };
4
5
};
6
7
view " externa " {
...
Pgina 34
3.3 FIREWALL
Para configurar o RNDC devemos primeiro gerar a chave criptogrfica. Sendo assim,
execute:
root@dmz :~ # cd / etc / bind
root@dmz :/ etc / bind # rndc - confgen -r / dev / urandom -a
wrote key file " / etc / bind / rndc . key "
Veja a chave gerada:
root@dmz :/ etc / bind # cat rndc . key
key " rndc - key " {
algorithm hmac - md5 ;
secret " gdt6lf3SlKt + o6e3UeqVrw == " ;
};
Por segurana, deixe leitura e escrita somente para o root e o grupo:
root@dmz :/ etc / bind # chmod 770 / etc / bind / rndc . key
Agora que ajustamos as configuraes, reinicie o servio:
Stopping domain name service ...: bind9 waiting for pid 1008 to die .
Starting domain name service ...: bind9 .
Veja o status do rndc:
root@dmz :~ # rndc status
version : 9.7.3
CPUs found : 1
Pgina 35
3.3 FIREWALL
worker threads : 1
number of zones : 54
debug level : 0
xfers running : 0
xfers deferred : 0
soa queries in progress : 0
10
query logging is OFF
11
recursive clients : 0/0/1000
12
tcp clients : 0/100
13
server is up and running
Agora podemos executar os comando re reload com o rndc:
root@dmz :~ # rndc reload
server reload successful
Para vermos o que est em cache no DNS, podemos usar os comandos abaixo:
root@dmz :~ # rndc dumpdb - cache
root@dmz :~ # cat / var / cache / bind / named_dump . db
E para limpar o cache execute:
root@dmz :~ # rndc flush
Pgina 36

Apostila Servidor DNS - Primário

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apostila Servidor DNS - Primário

Uploaded by

Copyright:

Available Formats

4452

Linux Security Servers in Cloud

Projetos na sua empresa

Introduo ao BIND + Implementao prtica

BIND como servidor cache . . . . . . . . . . . . . . . . . . . 20

Tipos de zonas e Registros . . . . . . . . . . . . . . . . . . . 22

Configuraes iniciais do VIEW . . . . . . . . . . . . . . . . 26

Configurao do DNS primrio . . . . . . . . . . . . . . . . . 26

3.1 Introduo terica

Nomes que coincidiam : dois hosts do arquivo HOSTS.TXT no podiam ter o

Consistncia : manter a consistncia do arquivo com a rede se expandindo

Os administradores da ARPANET tentaram outras configuraes que resolvessem o

Paul Mockapetris, do USCs Information Science Institute, foi o responsvel pela

Linux Security Servers in Cloud

3.1 Introduo terica

Linux Security Servers in Cloud

3.1 Introduo terica

No caso do Brasil, essa responsabilidade pertence atualmente ao "CGI.br",

3.1.3 Resoluo Recursiva

Linux Security Servers in Cloud

3.1 Introduo terica

1.Usurio solicita acesso a "www.exemplo.com.br";

Linux Security Servers in Cloud

3.1 Introduo terica

exemplo.com.br. Vai ser respondido o IP, juntamente ao TTL do registro, ou ser

Conceitos de DNS e a sua configurao em Gnu/Linux utilizando Bind9, so

3.1.4 Resoluo Iterativa

Enquanto o servidor "cache"do exemplo acima executa um processo recursivo de

3.1.5 O arquivo hosts

Derivado do arquivo "HOSTS.TXT"original, aquele que era atualizado e distribudo

Linux Security Servers in Cloud

3.1 Introduo terica

Este comportamento pode ser modificado atravs do arquivo "/etc/nsswitch", porm,

micro50 . dexter . com . br .

Linux Security Servers in Cloud

3.1 Introduo terica

root@dmz :~ # cat / etc / hosts

# The following lines are desirable for IPv6 capable hosts

fe00 ::0 ip6 - localnet

ff00 ::0 ip6 - mcastprefix

ff02 ::1 ip6 - allnodes

ff02 ::2 ip6 - allrouters

ip6 - localhost ip6 - loopback

3.1.6 Ferramentas de consulta

root@dmz :~ # aptitude install dnsutils

Linux Security Servers in Cloud

3.1 Introduo terica

O comando "host" concebido para dar respostas objetivas, limitando-se na maioria

O "dig"no utiliza a opo "search"do "/etc/resolv.conf", por isso necessrio utilizar

Antes de testarmos o comando dig, devemos saber o significado de algumas siglas,

Linux Security Servers in Cloud

3.1 Introduo terica

Vamos testar o "verborrgico"comando "dig":

root@dmz :~ # dig www .4 linux . com . br .

;; ->> HEADER < < - opcode : QUERY , status : NOERROR , id : 5930

;; flags : qr rd ra ; QUERY : 1 , ANSWER : 1 , AUTHORITY : 0 , ADDITIONAL : 0

; www .4 linux . com . br .

www .4 linux . com . br .

;; Query time : 392 msec

;; SERVER : 4.2.2.2 # 53(4.2.2.2)

root@dmz :~ # dig @8 .8.4.4 www .4 linux . com . br .

;; ->> HEADER < < - opcode : QUERY , status : NOERROR , id : 27912

;; flags : qr rd ra ; QUERY : 1 , ANSWER : 1 , AUTHORITY : 0 , ADDITIONAL : 0

; www .4 linux . com . br .