Upload
marcelofur19727989
View
241
Download
0
Embed Size (px)
Citation preview
8/9/2019 Apostila Servidor DNS - Primário
1/36
4452
Linux Security Servers in Cloud
www.4linux.com.br
8/9/2019 Apostila Servidor DNS - Primário
2/36
8/9/2019 Apostila Servidor DNS - Primário
3/36
8/9/2019 Apostila Servidor DNS - Primário
4/36
8/9/2019 Apostila Servidor DNS - Primário
5/36
8/9/2019 Apostila Servidor DNS - Primário
6/36
Capítulo 3
Servidor DNS - Primário
3.1 Introdução teórica
Durante os anos 70, Arpanet era uma pequena comunidade de algumas centenas
de hosts. Um único arquivo, HOSTS.TXT, continha toda a informação necessária
sobre os hosts. Este arquivo continha nome para endereçar cada host conectado a
ARPANET.
O arquivo era mantido pela Network Information Center (NIC) e distribuído por um
único host, Stanford Research Institute’s Network Information Center (SRI-NIC). Os
administradores da ARPANET enviavam ao NIC, por e-mail, quaisquer mudanças
que tivessem sido efeituadas e periodicamente SRI-NIC era atualizado, assim como
o arquivo HOSTS.TXT. As mudanças eram compiladas em um novo HOSTS.TXT
uma ou duas vezes por semana. Com o crescimento da ARPANET, entretanto, este
esquema tornou-se inviável. O tamanho do arquivo HOST.TXT crescia na proporção
em que crescia o número de hosts. Além disso, o tráfego gerado com o processode atualização crescia em proporções ainda maiores uma vez que cada host que era
incluído não 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 população da rede "ex-
plodiu". E passaram a existir alguns problemas com o HOST.TXT:
6
8/9/2019 Apostila Servidor DNS - Primário
7/36
4Linux – www.4linux.com.br 3.1 Introdução teórica
• Nomes que coincidiam : dois hosts do arquivo HOSTS.TXT não podiam ter o
mesmo nome. Porém, apesar do NIC poder designar endereços únicos para
cada host, ele não tinha nenhuma autoridade sobre os nomes dados aos mes-
mos. Não havia nada que pudesse evitar que alguém adicionasse um host com
um nome conflitante, interrompendo o sistema de algum outro host já existente.
• Consistência : manter a consistência do arquivo com a rede se expandindo
àquelas proporções se tornou cada vez mais difícil. Quando o arquivo con-
seguia conter todos os hosts, algum host trocava de endereço ou um novo host
adicionado tinha quebrado a conexão do host que se desejava acessar. Ironica-
mente, o sucesso da ARPANET tornou o arquivo HOSTS.TXT falho e obsoleto.
Os administradores da ARPANET tentaram outras configurações 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 disponíveis; Descentralizar a administração
a fim de resolver o problema do gargalo gerado por um único host, diminuindo o
problema do tráfego. Além disso, o fato da administração ser local iria fazer com
que a atualização 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 USC’s Information Science Institute, foi o responsável pela
arquitetura do sistema. Em 1984 ele lançou 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 especificações atuais do DNS.
http://www.gta.ufrj.br/grad/anteriores98/dns-ticiana/historia.htm
Linux Security Servers in Cloud Página 7
8/9/2019 Apostila Servidor DNS - Primário
8/36
3.1 Introdução teórica 4Linux – www.4linux.com.br
3.1.1 Características
• Banco de dados hierárquico e distribuído representado no formato de uma ár-
vore invertida e 127 níveis;
• "Namespace"de até 63 caracteres;
• Capacidade de associar outras informações a um "host"e não só seus en-
dereços IP’s;
• Arquitetura cliente/servidor;
• Os clientes são 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 estão os servidores de nome "DNS", os "DNS nameserver";
• A raiz da árvore tem nome nulo ou , por isso a representamos simplesmente
como ponto (.);
• Os nós abaixo do domínio raiz são chamados domínios de nível mais elevado -
TLD (top level domains);
• Sua quantidade e nomes são impostos pela ICANN - Internet Corporation for
Assigned Names and Numbers;
• Eles são divididos em "gTLD"(domínios genéricos "com", "edu", "gov", "mil",
etc) e "ccTLD"(códigos de países ou "country-code", sempre com duas le-
tras);
• A ICANN delega, de acordo com tratados internacionais, a responsabilidade
pela administração de um "ccTLD";
Página 8 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
9/36
4Linux – www.4linux.com.br 3.1 Introdução teórica
• No caso do Brasil, essa responsabilidade pertence atualmente ao "CGI.br",
mais especificamente ao "REGISTRO.br";
• Uma vez delegado um domínio, sua nova autoridade pode delegar subdomínios
sem necessitar notificar a entidade responsável pelo domínio pai;
• Um subdomínio está para um subdiretório assim como um domínio está para
um diretório, 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 ar-
quivo é normalmente o primeiro a ser consultado pelo resolvedor, que irá buscar por
um servidor de nomes apenas em caso de o "host"não ser encontrado no arquivo"/etc/hosts". “
3.1.2 Resolução
Resolução "DNS"é o processo pelo qual um programa consulta dados a respeito de
um "hostname". Na grande maioria das vezes, consulta-se o endereço IP deste"host"para então efetuar algum tipo de conexão à algum serviço, como "HTTP",
"SMTP, "POP", dentre outros. O processo de resolução, a partir do primeiro "name-
server"consultado, pode ser:
• recursiva
• iterativa
3.1.3 Resolução Recursiva
Tomando um navegador web como exemplo, a resolução para acesso a um "web-
site"tem as seguintes etapas:
Linux Security Servers in Cloud Página 9
8/9/2019 Apostila Servidor DNS - Primário
10/36
3.1 Introdução teórica 4Linux – www.4linux.com.br
1.Usuário solicita acesso a "www.exemplo.com.br";
2.Navegador checa se já conhece o endereço IP do "hostname"solicitado (cache do
"browser");
3.Se não conhece, o navegador passa a solicitação para a biblioteca de resolução -
o "resolver";
4.O "resolver"procura o "hostname"solicitado no arquivo "/etc/hosts"local;
5.Se não encontrar, ele checa o arquivo "/etc/resolv.conf"para saber a quais "name-
servers"deve solicitar a informação;
6.O "resolver"repassa a solicitação ao primeiro "nameserver"da lista, e logo após
para o próximo 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 não encontrar em seu "cache", o servidor em questão vai diretamente ao servi-
dor raiz e transfere a consulta - www.exemplo.com.br?;
9.O servidor raiz não faz "cache", e também não é autoridade sobre zonas de baixo
nível, então ele apenas responde uma parte da questão: "Não 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, porém como uma dica mais próxima: "Nãosei quem é, mas sei quem pode responder melhor: com.br.";
12.Passos 10 e 11 são efetuados mais uma vez, e agora a resposta é "Não sei quem
é, mas sei quem pode responder melhor: exemplo.com.br.";
13.Após repetir o passo 10, finalmente a resposta será da autoridade sobre o domínio
Página 10 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
11/36
4Linux – www.4linux.com.br 3.1 Introdução teórica
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 conexão "HTTP"com o IP descoberto.
Conceitos de DNS e a sua configuração em Gnu/Linux utilizando Bind9, sãocobrados na Prova do LPI 201 – peso2.
3.1.4 Resolução Iterativa
Enquanto o servidor "cache"do exemplo acima executa um processo recursivo de
consultas sucessivas descendo a árvore até a autoridade capaz de responder defini-
tivamente ao questionamento apresentado, os servidores ".", "br.", "com.br.", ape-
nas informam que conhecem alguém mais preciso que eles. Essa é uma consulta
iterativa. Iteração, nesse caso, significa "apontar para o mais próximo con-
hecido".
3.1.5 O arquivo hosts
Derivado do arquivo "HOSTS.TXT"original, aquele que era atualizado e distribuído
antes do surgimento do "Domain Name System", o arquivo "/etc/hosts"continua tendo
um papel muito importante no processo de resolução. No passo a passo descrito
anteriormente, observe que ele é a primeira fonte de consulta do "resolver".
Linux Security Servers in Cloud Página 11
8/9/2019 Apostila Servidor DNS - Primário
12/36
8/9/2019 Apostila Servidor DNS - Primário
13/36
4Linux – www.4linux.com.br 3.1 Introdução teórica
Pode ser acrescentadas quantas entradas forem necessárias, inclusive para IPs ex-
ternos. Atualmente, os sistemas baseados em Debian já contém entradas para en-
dereçamento "IPv6", que seguem a mesma lógica. Poderá ver isto executando:
1 r o o t @ d m z : ~ # c a t / e t c / h o s ts
2 ...
3 # T he f ol lo wi ng l in es a re d es ir ab le f or I Pv 6 c ap ab le h os ts
4 ::1 ip6 - l oc al ho st ip6 - l oo pba ck
5 f e : : i p6 - l o c al n e t
6 f f : : i p6 - m c a s tp r e f i x
7 f f 2 : : 1 i p6 - a l l no d e s
8 f f 2 : : 2 i p6 - a l l r ou t e r s
3.1.6 Ferramentas de consulta
Caso ainda não estejam presentes, vamos instalar as ferramentas de pesquisa de
"DNS".
1 r o o t @ d m z : ~ # a p t it u d e i n s ta l l d n s ut i l s
• nslookup
A "ISC" (Internet Systems Consortium - www.isc.org) diz, literalmente, no manual
de utilização do BIND: "Devido a sua interface misteriosa e frequente compor-tamento inconsistente, nós não recomendamos o uso do "nslookup". Usem o
"dig"no lugar dele".
Porém, o pacote é mantido pela própria ISC em nome da legião de administradores
que se habituaram a utilizar o "nslookup"como ferramenta de resolução de proble-
mas.
Linux Security Servers in Cloud Página 13
8/9/2019 Apostila Servidor DNS - Primário
14/36
3.1 Introdução teórica 4Linux – www.4linux.com.br
Dentre suas vantagens está o fato de ter uma biblioteca de resolução 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 controlável. Dentre os prob-
lemas mais crônicos do "nslookup"estão: respostas confusas e erros indefinidos.
• host
O comando "host"é concebido para dar respostas objetivas, limitando-se na maioria
dos casos a uma só linha. Porém, repostas mais detalhadas podem ser obtidas com
a utilização de parâmetros. Ao contrário do "dig", o "host"consulta a "search list"do
arquivo "/etc/resolv.conf".
• dig
O comando "dig"é o acrônimo para "Domain Information Groper", que significa algo
como "aquele que busca por informações de domínio no escuro", e ao mesmo
tempo, a palavra "dig"em inglês significa literalmente "escavar". Acho que mencionar
estas curiosidades demonstra o esforço de imaginação dos criadores do "dig"e, não
à toa, ele é o comando de pesquisa mais poderoso no pacote de utilitários "BIND".
No "dig"há dezenas de opções e incontáveis combinações entre elas, por isso con-
sultar o "man"e, sobretudo, ter um forte domínio do funcionamento do sistema de
nomes de domínio, é necessário para domá-lo.
O "dig"não utiliza a opção "search"do "/etc/resolv.conf", por isso é necessário 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.
Página 14 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
15/36
4Linux – www.4linux.com.br 3.1 Introdução teórica
Vamos testar o "verborrágico"comando "dig":
1 r o o t @ d m z : ~ # d i g w w w . 4 l i nu x . c o m . b r .
2 ; ; - > > HE AD ER < < - o p co d e : Q UE RY , s t at u s : N OE RR OR , i d : 5 93
3 ; ; f la gs : q r r d r a; Q UE RY : 1 , A NS WE R : 1 , A UT HO RI TY : , A DD IT IO NA L :
4 ; ; Q U ES T IO N S E CT I ON :
5 ; www .4 linu x. com .br . IN A
6 ; ; A N SW E R S E CT I ON :
7 ww w .4 l i nu x . co m . br . 3 I N A 6 6 .1 18 .1 42 .4 1
8 ; ; Q ue ry t im e : 3 92 m se c
9 ; ; S E R VE R : 4 . 2 .2 . 2 # 5 3 ( 4 . 2 . 2. 2 )
10 ...
1 r o o t @ d m z : ~ # d i g @ 8 . 8 . 4 .4 w w w . 4 l i nu x . c o m . b r .
2 ; ; - > > HE AD ER < < - o p co d e : Q UE RY , s t at u s : N OE RR OR , i d : 2 79 1 2
3 ; ; f la gs : q r r d r a; Q UE RY : 1 , A NS WE R : 1 , A UT HO RI TY : , A DD IT IO NA L :
4 ; ; Q U ES T IO N S E CT I ON :
5 ; www .4 linu x. com .br . IN A
6 ; ; A N SW E R S E CT I ON :
7 ww w .4 l i nu x . co m . br . 3 I N A 6 6 .1 18 .1 42 .4 1
8
9 ; ; Q ue ry t im e : 3 48 m se c
10 ; ; S E R VE R : 8 . 8 .8 . 8 # 5 3 ( 8 . 8 . 4. 4 )
Linux Security Servers in Cloud Página 15
8/9/2019 Apostila Servidor DNS - Primário
16/36
3.1 Introdução teórica 4Linux – www.4linux.com.br
11 ...
1 r o ot @ dm z : ~ # d ig - t m x g m ai l . c om .
2 ; ; - > > HE AD ER < < - o p co d e : Q UE RY , s t at u s : N OE RR OR , i d : 5 92 3 8
3 ; ; f la gs : q r r d r a; Q UE RY : 1 , A NS WE R : 5 , A UT HO RI TY : , A DD IT IO NA L :
4 ; ; Q U ES T IO N S E CT I ON :
5 ; gmai l . com . IN MX
6 ; ; A N SW E R S E CT I ON :
7 gm ail . com . 1425 IN MX 4 alt4 . gmail - smtp - in .l .go og le . com .
8 gm ail . com . 1425 IN MX 5 gmail - smtp - in .l . goo gl e. com .
9 gm ail . com . 1425 IN MX 1 alt1 . gmail - smtp - in .l .go og le . com .
10 gm ail . com . 1425 IN MX 2 alt2 . gmail - smtp - in .l .go og le . com .
11 gm ail . com . 1425 IN MX 3 alt3 . gmail - smtp - in .l .go og le . com .
12 ; ; Q u er y t i me : 1 3 6 m s ec
13 ; ; S E R VE R : 8 . 8 .8 . 8 # 5 3 ( 4 . 2 . 2. 2 )
14 ...
1 r o ot @ dm z : ~ # d ig - x 2 . 2 1 2. 1 22 . 13 7
2 ; ; - > > HE AD ER < < - o p co d e : Q UE RY , s t at u s : N OE RR OR , i d : 6 42 9 3
3 ; ; f la gs : q r r d r a; Q UE RY : 1 , A NS WE R : 2 , A UT HO RI TY : , A DD IT IO NA L :
4 ; ; Q U ES T IO N S E CT I ON :
5 ;1 37 . 12 2. 21 2 .2 . in - a dd r . ar pa . I N P TR
6 ; ; A N SW E R S E CT I ON :
7 1 3 7 . 1 22 . 21 2 .2 . in - a d d r . ar pa . 4 32 I N C NA M E 1 3 7 .1 28 -
8 1 9 1 . 1 2 2 . 2 1 2 . 2 . i n - a d d r . a r p a .
9 1 3 7 . 1 28 - 1 9 1 . 12 2 . 2 1 2. 2 . in - a d dr . a r p a . 3 6 I N P T R b o c a . 4 l i n u x . c o m . b r
.
10 ; ; Q ue ry t im e : 5 24 m se c
11 ; ; S E R VE R : 8 . 8 .8 . 8 # 5 3 ( 4 . 2 . 2. 2 )
12 ...
1 r o o t @ d m z : ~ # d i g + t r a c e w w w . 4 l i n u x . c o m . b r .
2 ; < < >> D iG 9 .7 . 3 < < >> + t r ac e w ww . 4 l i nu x . c om . b r .
Página 16 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
17/36
4Linux – www.4linux.com.br 3.1 Introdução teórica
3 ; ; g l ob a l o p ti o ns : + c md
4 . 382 IN NS h . root - se rv er s .net .
5 . 382 IN NS l . root - se rv er s .net .
6 . 382 IN NS m . root - se rv er s .net .
7 . 382 IN NS i . root - se rv er s .net .8 . 382 IN NS j . root - se rv er s .net .
9 . 382 IN NS d . root - se rv er s .net .
10 . 382 IN NS f . root - se rv er s .net .
11 . 382 IN NS e . root - se rv er s .net .
12 . 382 IN NS c . root - se rv er s .net .
13 . 382 IN NS a . root - se rv er s .net .
14 . 382 IN NS b . root - se rv er s .net .
15 . 382 IN NS k . root - se rv er s .net .
16 . 382 IN NS g . root - se rv er s .net .
17 ; ; R e ce i ve d 2 28 b yt es f ro m 4 . 2. 2 .2 # 5 3 ( 4 .2 . 2. 2 ) i n 1 32 m s
18 br . 17 28 IN NS c . dns . br .
19 br . 17 28 IN NS f . dns . br .
20 br . 17 28 IN NS a . dns . br .
21 br . 17 28 IN NS d . dns . br .
22 br . 17 28 IN NS b . dns . br .
23 br . 17 28 IN NS e . dns . br .
24 ; ; R e ce i ve d 2 87 b yt es f ro m 1 9 2. 5 .5 . 24 1 # 5 3( f . r oo t - s e r ve r s . ne t ) i n 2 16
ms
25 4 linu x. com .br . 864 IN NS ns1 .4 lin ux . com . br .
26 4 linu x. com .br . 864 IN NS ns2 .4 lin ux . com . br .
27 ; ; R e ce i ve d 1 3 b yt es f ro m 2 . 1 89 . 4 . 1 # 5 3 ( b . dn s . br ) i n 3 2 m s
28 ww w .4 l i nu x . co m . br . 3 I N A 6 6 .1 18 .1 42 .4 1
29 4 linu x. com .br . 6 IN NS ns1 . tes td ri ve .4 linu x. com .br .
30 4 linu x . com .br . 6 IN NS ns1 .4 linu x . com .br .
31 4 linu x . com .br . 6 IN NS ns2 .4 linu x . com .br .
32 ; ; R e c e iv e d 1 4 7 b y t e s f r om 2 . 2 12 . 1 2 2 . 13 7 # 5 3 ( n s 1 . 4 l i n ux . c o m . b r ) i n
44 ms
Linux Security Servers in Cloud Página 17
8/9/2019 Apostila Servidor DNS - Primário
18/36
8/9/2019 Apostila Servidor DNS - Primário
19/36
4Linux – www.4linux.com.br 3.2 Introdução ao BIND + Implementação prática
1 r o o t @ d m z : ~ # n e t st a t - n l t up
2 tcp . . . : 5 3 . . . : *
OU Ç A 133/ sshd
3 tcp 1 9 2 . 1 6 8 . 2 . 3 : 5 3 . . . : *
OU Ç A 862/ nam ed
4 tcp 1 2 7 . . . 1 : 5 3 . . . : *
OU Ç A 862/ nam ed
5 tcp 1 2 7 . . . 1 : 9 5 3 . . . : *
OU Ç A 862/ nam ed
6 tcp6 : : :5 3 :::*
OU Ç A 133/ sshd
7 tcp6 ::: 53 :::*
OU Ç A 862/ nam ed
8 udp 1 9 2 . 1 6 8 . 2 . 3 : 5 3 . . . : *
8 6 2 / n a m e d
9 udp 1 2 7 . . . 1 : 5 3 . . . : *
8 6 2 / n a m e d
10 udp6 ::: 53 :::*
8 6 2 / n a m e d
Instale o sniffer tcpdump:
1 r o o t @ d m z : ~ # a p t it u d e i n s ta l l t c p du m p
Execute o tcpdump para verificar os pacotes saindo de uma porta alta até a porta
53/udp de seu servidor:
1 r oo t@ dm z :~ # t cp du mp - i e th - n p or t 5 3
2 t c pd u mp : v e rb o se o u tp ut s u pp re s se d , u se - v o r - vv f or f ul l p r ot o co l
decode
3 l i st e ni n g o n e th , l in k - t y pe E N 1 MB ( E t he r ne t ) , c a pt u re s iz e 6 55 35
bytes
Linux Security Servers in Cloud Página 19
8/9/2019 Apostila Servidor DNS - Primário
20/36
3.2 Introdução ao BIND + Implementação prática 4Linux – www.4linux.com.br
Em outro terminal execute:
1 r o ot @ dm z : ~ # d ig @ l oc a lh o st - t a ny w i ki p ed i a . c om
Verifique a saída do tcpdump:
1 1 9 :1 1 :5 2 . 39 6 I P 1 9 2 .1 6 8 .2 . 3 . 33 6 25 > 1 9 8. 4 1. . 4. 5 3: 1 2 12 1 [ 1 au ]
A N Y ? w i k i pe d i a . c o m . ( 4 2)
2 1 9 :1 1 :5 2 . 39 6 I P 1 9 2 .1 6 8 .2 . 3 . 29 7 26 > 1 9 2. 3 3 .4 . 12 . 53 : 3 93 9 [ 1 au ]
NS ? . ( 28 )
3 1 9 : 1 1 : 5 2 . 5 4 4 I P 1 9 2 . 3 3. 4 . 1 2 . 53 > 1 9 2 . 1 6 8 .2 . 3 . 29 7 2 6 : 3 9 3 9 * -1 4 / / 23 N S m . ro ot - s e rv e rs . n e t . , N S d . ro ot - s e rv e rs . n e t ., N S h . r oo t
- s e r ve r s . ne t . , N S k . ro ot - s e rv e rs . n e t ., N S g . r oo t - s e r ve r s . ne t . , N S
i . r oo t - s e r ve r s . n e t . , N S b . r o o t - s e r v e r s . n e t . , N S j . r o ot - s e r v e rs .
n et . , N S a . ro ot - s e rv e rs . n e t . , N S f . ro ot - s e rv e rs . n e t . , N S c . ro ot -
s e r v er s . n e t . , N S l . r o o t - s e r v e r s . n e t . , N S e . r oo t - s e r ve r s . n e t . ,
R R S IG ( 8 57 )
4 1 9 :1 1 :5 2 . 55 2 I P 1 9 8. 4 1. .4 . 53 > 1 9 2. 1 6 8. 2 . 3 . 33 6 25 : 1 21 21 -
/ 1 5 /1 6 ( 7 37 )
Os logs de seu servidor DNS estão em "/var/log/daemon.log". Verifique-os:
1 r o o t@ d m z : ~ # t a il / v a r / l o g / d a e mo n . l o g
3.2.1 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, como vimos
acima. Ao invés disso elas dependem de um servidor intermediário com essa capaci-
dade. Quando nos conectamos de casa diretamente à Internet, o serviço "DHCP"do
Página 20 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
21/36
4Linux – www.4linux.com.br 3.2 Introdução ao BIND + Implementação prática
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 es-
tação vai fazer suas próprias consultas individuais, multiplicando o volume de dadostrafegados 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 so-
bre 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 deatualização.
Nosso servidor recém instalado já está operando como servidor "cache". Faça uma
consulta e verifique o “Query time”. Repita o procedimento:
1 r oo t@ dm z :~ # d ig @ lo ca lh os t - t s oa k er ne l . or g | t ai l - n6
2
3 ; ; Q ue ry t im e : 4 81 m se c4 ; ; S E R VE R : 1 2 7 . . . 1 # 5 3 ( 1 2 7 . . . 1 )
5 ; ; W HE N: Mo n A ug 6 1 1: 47 :3 6 2 12
6 ; ; M SG SIZE rcvd : 1 29
7
8 r oo t@ dm z :~ # d ig @ lo ca lh os t - t s oa k er ne l . or g | t ai l - n6
9
10 ; ; Q ue ry t im e : m se c
11 ; ; S E R VE R : 1 2 7 . . . 1 # 5 3 ( 1 2 7 . . . 1 )
12 ; ; W HE N: Mo n A ug 6 1 1: 47 :5 3 2 12
13 ; ; M SG SIZE rcvd : 1 29
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:
Linux Security Servers in Cloud Página 21
8/9/2019 Apostila Servidor DNS - Primário
22/36
3.2 Introdução ao BIND + Implementação prática 4Linux – www.4linux.com.br
1 r o o t@ d m z : ~ # v i m / e t c / r e s o l v . c o nf
2 n a m e se r v e r 1 9 2 . 1 68 . 2 .3
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/re-
solv.conf, podemos adicionar um atributo de proteção a ele, não permitindo qualquertipo de alteração:
1 r o ot @ dm z : ~ # c h at t r + i / e tc / r e s ol v . c on f
3.2.2 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 oualteraçã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 ape-
nas no "BIND". Assemelha-se a uma "zona slave"mas replica do "master"apenas os
registros do tipo "NS". Em desuso.
Página 22 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
23/36
4Linux – www.4linux.com.br 3.2 Introdução ao BIND + Implementação prática
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 en-
dereços dos 13 "root servers".
forward - Serve para orientar o "BIND"a encaminhar a consulta sobre uma determi-nada "zona"para outro servidor em especial. O encaminhamento de consultas tam-
bé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: dexter.com.br 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.dexter".
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"
Com exceção do "$TTL", as demais são raramente utilizadas.
Linux Security Servers in Cloud Página 23
8/9/2019 Apostila Servidor DNS - Primário
24/36
3.2 Introdução ao BIND + Implementação prática 4Linux – www.4linux.com.br
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 precisaser 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.
Recentemente, 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
Página 24 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
25/36
4Linux – www.4linux.com.br 3.2 Introdução ao BIND + Implementação prática
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.”
[ 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 proble-
mas acontece quando usamos DMZ com ips inválidos com apontamento DNAT de
up ip válido, causando problemas de consulta na rede interna com a tradicional men-
sagem "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 à prática de separar o DNS em uma visão externae interna. Isso proporciona uma separação lógica entre as informações de DNS
disponível para clientes da rede interna e que é disponibilizada ao público à Internet
em geral. Ser capaz de enumerar esta informação é um recurso inestimável para
os possíveis atacantes. Ao separar as informações publicamente disponíveis do que
é exigido pelos clientes internos, acrescenta uma camada muito importante de pro-
teção. Split Horizon DNS pode ser realizado em vários métodos, mas a separação
Linux Security Servers in Cloud Página 25
8/9/2019 Apostila Servidor DNS - Primário
26/36
3.2 Introdução ao BIND + Implementação prática 4Linux – www.4linux.com.br
em dispositivos físicos ainda é o preferido.
O que é a View?
View é um recurso de regras específica para as query feita em uma zona, reagindode forma distinta para origens diferente de consulta. Então 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 Configurações iniciais do VIEW
Para implementar o VIEW em um servidor de DNS é necessário que todas as zonas
pré existente
1 r o o t@ d m z : ~ # s e d 2 i " v i e w \ " a l l \ " { " / e t c / b i nd / n a m e d . c o n f . d e fa u lt -
z o ne s - i
1 r o o t @d m z :~ # s ed 3 i " ma tc h - c l i e nt s { n on e ; } ;" / e tc / b i nd / n a me d . c on f .
d e f a ul t - z o n e s - i
1 r o o t@ d m z : ~ # s e d 3 2 i " } ;" / e t c / b i nd / n a m e d . c o n f . d e fa u lt - z o n e s - i
3.2.5 Configuração do DNS primário
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 domínios no arquivo "/etc/bind/named.conf.local":
Página 26 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
27/36
4Linux – www.4linux.com.br 3.2 Introdução ao BIND + Implementação prática
1 r o o t@ d m z : ~ # v i m / e t c / b i n d / n a m e d . c o nf . l o c a l
2
3 ....
4
5 a c l " l a n _n e ts " {
6 1 9 2 . 1 6 8 . 2 . / 2 4 ;
7 1 . . . / 2 4 ;
8 };
9
10 v ie w " e x te r na " {
11 m a tc h - c li en ts { ! l a n_ ne ts ; a ny ; } ;
12 r e c u r s i on y e s ;
13 z on e " d e xt e r . co m . br " {
14 t y pe m a s te r ;
15 f i le " d b . d e x t er . e x t er n a " ;
16 };
17
18 };
19
20
21 v ie w " i n te r na " {
22 m at ch - c l i en t s { l a n_ n et s ; 1 27 a n y ; } ;
23 r e c u r s i on y e s ;
24 z on e " d e xt e r . co m . br " {
25 t y pe m a s te r ;
26 f i le " d b . d e x t er . i n t er n a " ;
27 };
28
29 };
Vamos checar os arquivos de configuração para ver se não tem erros:
1 r o o t@ d m z : ~ # n a me d - c h e c kc o n f
Linux Security Servers in Cloud Página 27
8/9/2019 Apostila Servidor DNS - Primário
28/36
3.2 Introdução ao BIND + Implementação prática 4Linux – www.4linux.com.br
Agora criaremos o banco de dados de registros de "DNS", onde teremos servidores
de e-mail, web e ftp. Primeiro o domínio “dexter.com.br.”
1 r o o t@ d m z : ~ # v i m / v a r / c a ch e / b i n d / d b . d e x te r . e x t e r n a2 $ TT L 8 64 ; d ef au lt p ar a t od os o s r eg is tr os s em T TL
3
4 @ IN SOA ns1 .dex te r .com . br . root .d ex ter .com . br . (
5 Y Y Y Y MM D D N N ; s e r ia l
6 8 h ; r ef re sh
7 1 h ; r et ry
8 3 d ; e xp ir e
9 3 h ) ; n eg at iv e c ac hi ng t tl
10 ;11 @ IN NS ns1 . d ext er . com . br .
12 @ IN MX 1 mail . d ex ter . com . br .
13 @ IN A 2 . 1 . 5 . 9 9
14 ns1 IN A 2 . 1 . 5 . 9 9
15 www IN A 2 . 1 . 5 . 9 9
16 ftp IN CNAM E w ww
17 mail IN A 2 . 1 . 5 . 9 9
18 smtp IN CNAM E mail
19 w e bm ai l IN CNAM E mail
20 pop IN C NAME mail
21 imap IN CNAME mail
Agora a View interna:
1 r o o t@ d m z : ~ # v i m / v a r / c a ch e / b i n d / d b . d e x te r . i n t e r n a
2 $ TT L 8 64 ; d ef au lt p ar a t od os o s r eg is tr os s em T TL
3
4 @ IN SOA ns1 .dex te r .com . br . root .d ex ter .com . br . (
5 Y Y Y Y MM D D N N ; s e r ia l
6 8 h ; r ef re sh
7 1 h ; r et ry
8 3 d ; e xp ir e
Página 28 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
29/36
4Linux – www.4linux.com.br 3.2 Introdução ao BIND + Implementação prática
9 3 h ) ; n eg at iv e c ac hi ng t tl
10 ;
11 @ IN NS ns1 . dex te r . com . br .
12 @ IN MX 1 mail . de xt er . com . br .
13 @ IN A 1 9 2 . 1 6 8 . 2 . 314 ns1 IN A 1 9 2 . 1 6 8 . 2 . 3
15 www IN A 1 9 2 . 1 6 8 . 2 . 3
16 ftp IN C NAME www
17 mail IN A 1 9 2 . 1 6 8 . 2 . 3
18 smtp IN C NAME mail
19 w e bm ai l IN C NAME mail
20 pop IN C NAME mail
21 imap IN C NAME mail
22 ldap IN A 1 9 2 . 1 6 8 . 2 . 2
23 in t ra n et IN C NAME w ww
24
25 fi r ew a ll IN A 1 9 2 . 1 6 8 . 2 . 1
26 d at a c e n te r IN A 1 9 2 . 1 6 8 . 2 . 2
27 dmz IN A 1 9 2 . 1 6 8 . 2 . 3
28 s t or ag e IN A 1 9 2 . 1 6 8 . 2 . 4
29 au dit IN A 1 9 2 . 1 6 8 . 2 . 5
30 f il e s e r ve r IN A 1 9 2 . 1 6 8 . 2 . 6
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 se-
cundário pára de responder por essa zona;
Linux Security Servers in Cloud Página 29
8/9/2019 Apostila Servidor DNS - Primário
30/36
3.2 Introdução ao BIND + Implementação prática 4Linux – www.4linux.com.br
negative caching TTL - Se a zona expirar, esse será o tempo pelo qual um servi-
dor "cache"armazenará a informação "NXDOMAIN"antes de iniciar uma nova busca
recursiva. O máximo são 3 horas.
Se o comando retornar ao “prompt” significa que está correto! Agora vamos checara configuração da zona que temos autoridade:
1 r o o t@ d m z : ~ # n a me d - c h e c kz o n e d e x te r . c o m . b r . / v a r / c a c he / b i n d / d b . d e x t er
. i n t e r n a
2 z o n e d e x te r . c o m . b r / I N : l o a d e d s e r ia l 2 1 2 8 7 1
3 OK
4 r o o t@ d m z : ~ # n a me d - c h e c kz o n e d e x te r . c o m . b r . / v a r / c a c he / b i n d / d b . d e x t er
. e x t e r n a
5 z o n e d e x te r . c o m . b r / I N : l o a d e d s e r ia l 2 1 2 8 7 1
6 OK
Reinicie o serviço do Bind9:
1 r o o t @ d m z : ~ # s e r vi c e b i n d9 r e s ta r t
2 S to pp in g d om ai n n am e s er vi ce . . .: b in d9 w ai ti ng f or p id 1 12 5 t o d ie .
3 S t ar t in g d om a in n am e s e rv i ce . . . : b in d9 .
Vamos fazer alguns testes envolvendo nossos domínios e o comando dig:
1 r o ot @ dm z : ~ # d ig - t s oa d e xt e r . co m . br
2 ; ; - > > HE AD ER < < - o p co d e : Q UE RY , s t at u s : N OE RR OR , i d : 5 15 5
3 ; ; f la gs : q r a a r d r a; Q UE RY : 1 , A NS WE R : 1 , A UT HO RI TY : 1 , A DD IT IO NA L
: 1
4
5 ; ; Q U ES T IO N S E CT I ON :
6 ; de xt er .com .br . IN SOA
7
8 ; ; A N SW E R S E CT I ON :
Página 30 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
31/36
4Linux – www.4linux.com.br 3.2 Introdução ao BIND + Implementação prática
9 d ex te r . co m .b r. 8 64 I N S OA n s1 . d ex te r . co m . br . r oo t . de xt er . c om .
b r . 2 12 8 7 1 2 88 3 6 2 5 92 1 8
10
11 ; ; A U TH O RI T Y S E CT I ON :
12 d ex ter . com .br . 864 IN NS ns1 . dex te r. com . br .13
14 ; ; A D DI T IO N AL S E CT I ON :
15 ns 1 . de xt er . c om . br . 8 64 I N A 1 9 2. 16 8. 2 . 3
16
17 ; ; Q ue ry t im e : m se c
18 ; ; S E R VE R : 1 2 7 . . . 1 # 5 3 ( 1 2 7 . . . 1 )
19 ; ; W HE N: Mo n A ug 7 1 1: 53 :4 9 2 12
20 ; ; M SG SIZE rcvd : 1 6
Vamos testar as configurações referente ao e-mail:
1 r o ot @ dm z : ~ # d ig - t m x d e xt er . c o m . br
2 ; ; - > > HE AD ER < < - o p co d e : Q UE RY , s t at u s : N OE RR OR , i d : 6 12 4 6
3 ; ; f la gs : q r a a r d r a; Q UE RY : 1 , A NS WE R : 1 , A UT HO RI TY : 1 , A DD IT IO NA L
: 2
45 ; ; Q U ES T IO N S E CT I ON :
6 ; de xt er .com . br . IN MX
7
8 ; ; A N SW E R S E CT I ON :
9 d ex ter . com .br . 864 IN MX 1 mail . de xt er . com . br .
10
11 ; ; A U TH O RI T Y S E CT I ON :
12 d ex ter . com .br . 864 IN NS ns1 . dex te r. com . br .
13
14 ; ; A D DI T IO N AL S E CT I ON :
15 m a il . d e x te r . c om . b r . 8 64 I N A 1 9 2 . 1 68 . 2 .3
16 ns 1 . de xt er . c om . br . 8 64 I N A 1 9 2. 16 8. 2 . 3
17
18 ; ; Q ue ry t im e : m se c
19 ; ; S E R VE R : 1 2 7 . . . 1 # 5 3 ( 1 2 7 . . . 1 )
Linux Security Servers in Cloud Página 31
8/9/2019 Apostila Servidor DNS - Primário
32/36
3.3 FIREWALL 4Linux – www.4linux.com.br
20 ; ; W HE N: Mo n A ug 7 1 1: 54 :2 8 2 12
21 ; ; M SG SIZE rcvd : 1 2
Vamos efetuar um ping no domínio dexter.com.br:
1 r o ot @ dm z : ~ # p in g - c2 w ww . d e xt e r . co m . br
2 P IN G w ww . d e x te r . c om . b r ( 1 92 . 16 8 .2 . 3 ) 5 6 (8 4) b y te s o f d at a .
3 6 4 b yt e s f ro m d mz . d e xt e r . co m . br ( 1 92 . 16 8 . 2 .3 ) : i c mp _ re q = 1 t tl = 6 4
t i me = . 2 5 m s
4 6 4 b yt e s f ro m d mz . d e xt e r . co m . br ( 1 92 . 16 8 . 2 .3 ) : i c mp _ re q = 2 t tl = 6 4
t i me = . 3 1 m s
Reinicie o Bind9 novamente e verifique o log:
1 r o o t @ d m z : ~ # s e r vi c e b i n d9 r e s ta r t
2 r o ot @ dm z : ~ # t ai l - f / v ar / l og / d a e mo n . l og
3 A ug 1 1 3: 23 :3 5 d mz n am ed [ 1 37 ] : z on e l oc al ho st / I N: l oa de d s er ia l 2
4 A ug 1 1 3 :2 3 :3 5 d mz n am e d [ 13 7 ] : m an ag ed - k ey s - z o ne . / IN : l o ad i ng
f ro m m a st e r f il e m an ag ed - k ey s . b in d f a il e d : f il e n ot f ou n d
5 A ug 1 1 3 :2 3 :3 5 d mz n am e d [ 13 7 ] : m an ag ed - k ey s - z o ne . / IN : l o ad e d
serial
6 A u g 1 1 3: 23 :3 5 d mz n am ed [ 1 37 ] : r un ni ng
7 A u g 1 1 3 :2 3 :3 5 d mz n am e d [ 13 7 ] : z on e d e xt e r . co m . br / I N : s e nd i ng
n o t if i e s ( s e r i al 2 1 2 8 7 1 )
3.3 FIREWALL
Para que outros servidores utilizem nosso DNS habilite a passagem de pacotes no
firewall e também adicione um redirecionamento de porta, especificamente a porta
53 UDP, Só para lembrar adicione no fim do escopo do start:
Página 32 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
33/36
4Linux – www.4linux.com.br 3.3 FIREWALL
1 r o o t @ fi r e w a ll : ~ # v i m / e t c / i n it . d / f i r e w a l l
2 ...
3 # P ar a qu e o f ir ew al l u se a D MZ p ar a r es ol ve r n om es
4 i pt ab le s - A I NP UT - p ud p - -s po rt 53 - s $ DM Z - d $ FW - -d po rt $ PA - j
ACCEPT
5 i pt ab le s - A O UT PU T - p u dp - -s po rt $P A - s $F W - d $ DM Z - -d po rt 53 - j
ACCEPT
6
7 # P as sa ge m d e p ac ot es d o d ns i nt er no p ar a o m un do
8 i pt ab le s - A F O RW AR D - p u dp - -s po rt 53 - s $ DMZ - d / - -d po rt $P A -
j AC CE PT
9 i pt ab le s - A F OR WA RD - p u dp - -s po rt $ PA - s / - d $ D MZ - -d po rt 53 - j
ACCEPT
10
11 # R ed i re ci on am e nt o d a p or ta 5 3 n a m aq ui na F ir ew al l p ar a D MZ
12 i pt ab le s - t n at - A P RE RO UT IN G - p u dp - - sp or t $ PA - s / - d $ WA N1 - -
d p or t 5 3 - j D NA T - - to - d e s t in a ti o n $ DM Z : 53
Teste o script
1 r o o t @ f i r e w al l : ~ # s e r vi c e f i r e wa l l r e s ta r t
Para testar o DNS de um IP externo ao da nossa rede, na maquina externa execute:
1 r o ot @ ma q - e x t e r na : ~ # d i g d e x te r . c o m . b r @ 2 . 1 .5 . 9 9
2 ; < < >> D iG 9 .7 . 3 < < >> d e xt er . c o m . br @ 2 . 1 . 5 . 9 9
3 ; ; g l ob a l o p ti o ns : + c md
4 ; ; G ot a ns we r :
5 ; ; - > > HE AD ER < < - o p co d e : Q UE RY , s t at u s : N OE RR OR , i d : 1 5 3 9
6 ; ; f la gs : q r a a r d; Q UE RY : 1 , A NS WE R : 1 , A UT HO RI TY : 1 , A DD IT IO NA L : 1
7
8 ; ; Q U ES T IO N S E CT I ON :
9 ; de xt er .com . br . IN A
Linux Security Servers in Cloud Página 33
8/9/2019 Apostila Servidor DNS - Primário
34/36
3.3 FIREWALL 4Linux – www.4linux.com.br
10
11 ; ; A N SW E R S E CT I ON :
12 d ex ter . com .br . 864 IN A 2 .1 .5 . 99
13
14 ; ; A U TH O RI T Y S E CT I ON :15 d ex ter . com .br . 864 IN NS ns1 . dex te r. com . br .
16
17 ; ; A D DI T IO N AL S E CT I ON :
18 ns 1 . de xt er . c om . br . 8 64 I N A 2 . 1 . 5 .9 9
19
20 ; ; Q ue ry t im e : m se c
21 ; ; S E R VE R : 2 . 1 . 5 . 99 # 5 3 ( 2 .1 . 5 .9 9 )
22 ; ; W HE N: Tu e A ug 7 1 9: 32 : 4 2 12
23 ; ; MSG S IZE rcvd : 81
3.3.1 Configurando o RNDC
O comando rndc (Remote Named Daemon Control) é uma ferramenta de geren-
ciamento do named. A vantagem dessa ferramenta é que ela permite controlar onamed muito facilmente sem ter que ficar enviando sinais ao processo do mesmo.
Vamos limitar o seu uso apenas no próprio servidor, para isso vamos alterar o arquivo
“/etc/bind/named.conf.local.”
1 r o o t@ d m z : ~ # v i m / e t c / b i n d / n a m e d . c o nf . l o c a l
2 i n c l ud e " / e t c / b i nd / r n d c . k e y " ;
3 c o nt r ol s {
4 i ne t 1 27 . . .1 p or t 9 5 3 a ll ow { l oc al ho st ; } k ey s { " rn dc - k e y "; } ;
5 };
6
7 v ie w " e x te r na " {
8 ...
Página 34 Linux Security Servers in Cloud
8/9/2019 Apostila Servidor DNS - Primário
35/36
8/9/2019 Apostila Servidor DNS - Primário
36/36
3.3 FIREWALL 4Linux – www.4linux.com.br
4 w o rk er t h re a ds : 1
5 n um be r o f z on es : 5 4
6 d eb ug l ev el :
7 x f er s r u nn i ng :
8 x f er s d e fe r re d : 9 s oa q ue ri es i n p ro gr es s :
10 q u er y l o gg i ng i s O FF
11 r e c u r s i v e c l i e nt s : / / 1
12 t cp c l ie n ts : /1
13 s er ve r i s u p a nd r un ni ng
Agora podemos executar os comando re reload com o rndc:
1 r o o t @ d m z : ~ # r n d c r e l oa d
2 s e r v e r r e l oa d s u c c es s f u l
Para vermos o que está em cache no DNS, podemos usar os comandos abaixo:
1 r o ot @ dm z : ~ # r nd c d u mp db - c ac h e2 r o o t@ d m z : ~ # c a t / v a r / c a c h e / b i n d / n a m e d _d u m p . d b
E para limpar o cache execute:
1 r o ot @ dm z : ~ # r nd c f l us h
Página 36 Linux Security Servers in Cloud