Apostila Servidor DNS - Primário

8/9/2019 Apostila Servidor DNS - Primário

1/36

4452

Linux Security Servers in Cloud

www.4linux.com.br


2/36


3/36


4/36


5/36


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


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/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


9/36


• 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:



10/36


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



11/36


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".



12/36


13/36


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.



14/36


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.



15/36


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



5 ; www .4 linu x. com .br . IN A



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 )



16/36


11 ...

1 r o ot @ dm z : ~ # d ig - t m x g m ai l . c om .




5 ; gmai l . com . IN MX


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 .




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




5 ;1 37 . 12 2. 21 2 .2 . in - a dd r . ar pa . I N P TR


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 .



17/36


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


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



18/36


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



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



21/36


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:



22/36


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.



23/36


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.



24/36


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



25/36


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



26/36


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":



27/36


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



28/36


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



29/36


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;



30/36


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


6 ; de xt er .com .br . IN SOA

7




31/36


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


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


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


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


6 ; de xt er .com . br . IN MX

7


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


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


19 ; ; S E R VE R : 1 2 7 . . . 1 # 5 3 ( 1 2 7 . . . 1 )



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


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:



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 :


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


9 ; de xt er .com . br . IN A



34/36


10


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


18 ns 1 . de xt er . c om . br . 8 64 I N A 2 . 1 . 5 .9 9

19


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 ...



35/36


36/36


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


Apostila Servidor DNS - Primário

Documents

Transcript of Apostila Servidor DNS - Primário