Capitulo 4: DNS (BIND)

Transcrição

1 Por Eduardo Scarpellini Capitulo 4: DS (BID) 4.1 do HOSTS.TXT ao DS a década de 70, a ARPAnet era uma pequena rede de algumas centenas de computadores. Um único arquivo, chamado HOSTS.TXT, continha todas as informações necessárias sobre estes hosts. Deste arquivo derivou-se o conhecido /etc/hosts. A manutenção do HOSTS.TXT era feita pelo etwork Information Center (IC), que compilava um novo arquivo uma ou duas vezes por semana e distribuída para todas as maquinas conectadas a rede. Com o crescimento da ARPAnet esse esquema se tornou impraticável. A tabela de hosts cresceu muito e isso acarretou problemas como trafego, carga do servidor, colisões de nomes e consistência da base de dados. Os administradores da ARPAnet, então, começaram a buscar de um sucessor para o HOSTS.TXT. O novo sistema poderia permitir um administrador de dados local e, ainda, tornar os dados disponíveis globalmente. A descentralização da administração pretendia eliminar o gargalo em um único host e aliviar o problema de tráfego, manter os dados atualizados com muito mais facilidade e garantir a unicidade dos nomes utilizando uma tabela hierárquica. Paul Mockapetris, do USC's, foi responsável pelo desenho da arquitetura do novo sistema. Em 1984, ele escreveu as RFCs 882 e 883, nas quais descrevia o 'Domain ame System'. Estas RFCs foram substituídas pelas RFCs 1034 e 1035, que são as espeficicacões atuais. Estas também foram incrementada por outras, descrevendo potenciais problemas de DS, problemas de implementação, mecanismos para atualização dinâmica de servidores de nome e segurança de zonas e mais. 4.2 O DS O DS é uma base de dados distribuída que permite o controle local dos segmentos de todo o banco de dados. Esses dados podem ser replicados ou cacheados, gerando maior robustez e performance. Os servidores de nomes contem informações sobre alguns seguimentos da base-de-dados e colocam isso a disposição dos clientes, chamados resolvers. Resolvers são simplesmente algumas bibliotecas de rotinas que fazem perguntas e enviam pela rede para um servidor de nomes. A estrutura de uma base-de-dados de DS é muito similar a estrutura de um sistema de arquivos UIX.. Toda a base de dados pode ser retratado como uma árvore invertida. com o nodo raiz no topo. Cada nodo na arvore tem um rótulo, identificando uma relação com seus pais e é, também, raiz de todas arvores de uma sub-arvore que vem abaixo. o DS, o nome de domínio é a seqüência de rótulos de nodos partindo da raiz do domínio para a raiz da arvore, separados por pontos (.)

2 o sistema de arquivos UIX, temos o 'absolute pathname' que é a lista de nomes relativos de um diretório partindo da raiz para os galhos (inverso ao DS). o DS, cada domínio pode ser quebrado em varios subdomínios, e a responsabilidade por esses subdomínios pode ser delegada a diferentes organizações. Por exemplo, InterIC tem autoridade sobre o domínio.com (comercial), mas delega a responsabilidade sobre o domínio google.com a organização GOOGLE. Assim GOOGLE tem a autonomia administrativa sobre esse espaço. A zona google.com é agora independente de.com e contém todos nomes que terminam em google.com. A zona.com contem somente os domínios que terminam em.com, mas não faz parte das zonas delegadas como google.com Da mesma maneira a zona.br foi delegada a FAPESP e abaixo desta pode existir zonas como.com,.edu,.net, etc Um exemplo com: google.com, amazon.com, hacker.net, berkeley.edu, fatectq.com.br com + -- google + -- amazon + -- net + -- hacker + -- edu + -- berkeley + -- br + -- com + -- fatectq 4.3 BID (Berkeley Internet ame Domain) Para configurar nosso servidor de nomes, tomaremos como exemplo: Zona: howto.com.br Rede: etmask: Os arquivos de configuração do BID, por padrão ficam armazenados em /etc/namedb/. Editando o arquivo named.conf veremos uma zona. do tipo hint fazendo referencia ao arquivo named.root. Este arquivo contém informações sobre os RootServers com os quais vamos nos conectar para eventuais pesquisas sobre domínios e, conseqüentemente, caching de nomes. Para nosso servidor responder pela nova zona ( howto.com.br ) devemos adicionar as seguintes linhas ao final do arquivo named.conf:

3 %"&('!" ##$. ) * + + #, -$ $ ote que temos um type master, isso especifica que temos autoridade sobre a zona. A opção file referencia um arquivo de configuração para essa zona. Para a configuração de zona reversa, utilizamos: / 012 3(452 6( :9;(; <5=9#< >?9@ A!" ##$ B &('. ) ,CDE GF-@$ $ ote que o nome da zona é nossa rede ao inverso: > Caso você possua outra netmask e não seja proprietário da rede toda, utilize: / *C + 3 HI J :9;(; <1K9#< >:9I o exemplo acima temos a rede com netmask , portanto IPs de 1 a 63. É necessário que criemos o arquivo howto-com-br.zone que armazenará as configurações da zona howto.com.br Eis um exemplo: L A(A-M H3C(C 7 8 OGP9 G, Q#R: "S G Q T 0C C(U CH H*C(C 2 $VO # & ' H3C(C $V< %? "!( 2U U(C C $W< -: H3C(C C(C CX$WY*Z & E H3C(C C\[ $^] & & _ 7 8 8(O 2 6"0`2 3(4Ja ]b 2C &(' * a Q "012 3(4J012! c "012 3(4J010 c "012 3(4J012 ( % 7 8 9! cj S S# "012 3(4J010 " &(' "012 3(4J01?d o exemplo acima temos: $TTL: time to I SOA: inicio da configuracao da zona howto.com.br. root.howto.com.br é o proprietário da zona ;Serial: Esse é o numero serial da nossa zona. Com base nesse numero os servidores de nomes sabem se seu cachê esta atualizado ou não. A cada mudança na configuracao de zona esse serial deve ser modificado. Por padrão usamos a data da ultima modificação + numero da modificação /03/2004 nesse exemplo ; Refresh: É o tempo (em segundos) no qual os servidores secundários se baseiam para perguntar ao servidor primário se as configurações de zona sofreram modificações.

4 14400 ; Retry: Tempo de espera para uma nova tentativa de sincronização de configuracao de zonas ; Expire: É o tempo para a configuração da zona expirar e uma nova sincronização dos dados ser forçada ) ; Minimum: É o valor mínimo padrão para o $TTL, ou seja, é o tempo mínimo de vida de uma conexão. Esse valor é utilizado caso você não coloque um valor para I S : A entrada S em I referencia um servidor de nomes para essa zona, é a maquina que estará rodando o I MX 10 mail.howto.com.br. : A entrada MX (mail exchanger) em I referencia um servidor de . Essa entrada exige um numero que indica sua prioridade, em caso de mais de um servidor em nossas zonas. Quanto menor o numero, maior a prioridade (10 no nosso caso). ote que a entrada MX aponta para mail.howto.com.br seguida de um ponto (.). Esse ponto deve existir sempre que especificarmos um nome ao invés de um IP. Um entrada I A deverá existir para o subdomínio I A : Entradas I A definem subdomínios/host. este caso temos o IP respondendo por howto.com.br (sem subdomínio) já que o primeiro campo (@) não foi preenchido. bsd I A : esta linha estamos apontando o subdominio bsd (bsd.howto.com.br) para o IP named I A : Subdomínio named apontando para , que é nosso servidor de nomes. www I A bsd.howto.com.br. : Aqui temos um subdominio www como um alias para bsd.howto.com.br (note o ponto no final), portanto que respondera pelo será o IP ftp I A : Subdomínio ftp apontando para Poderíamos ter usado I A bsd.howto.com.br, como em www mail I A : Uma entrada declarando o subdominio mail que esta sendo apontado para o IP Esta entrada vai ser usada pela I MX. ossa zona howto.com.br está configurada, agora podemos configurar a zona reversa para Para isso criamos o arquivo rev.

5 Eis um exemplo: L A(A-M H3C(C 7 8 OGP9 G, Q#R: "S G Q T 0C C(U CH H*C(C 2 $VO # & ' H3C(C $V< %? "!( 2U U(C C $W< -: H3C(C C(C CX$WY*Z & E H3C(C C\[ $^] & & _ 7 8 8(O 2 6"0`2 3(4Ja > A < cj G Q > A <! cj S S# d 7 8 > A < " & ' Q# A entrada I SOA é idêntica ao arquivo de configuração de zona. Aqui a grande diferença é que não usamos entrada A, e sim PTR, além de mudança da ordem dos campos. Agora temos: numero-ip I PTR nome.zona Primeiro elegemos um servidor de nomes, que no caso é nossa própria I S I PTR named.howto.com.br.: esse caso estamos relacionando o IP 1 ( ) ao subdominio named.howto.com.br. As outras entradas são praticamente idênticas a do IP 1, mudando apenas o IP e seu nome. Assim nosso servidor de nomes será capaz de identificar o nome de cada endereço da rede, fazendo o reverso da resolução de nomes. ote que nesse arquivo é comum adicionarmos apenas entradas para os nomes reais de cada máquina, então nosso IP 2 ( ) fica apenas com o nome bsd, descartando, assim, www e ftp que referenciam este mesmo endereço. ossa configuração parece estar ok. Para iniciarmos o BID utilizamos o comando named que pode ser utilizado a seguinte forma: e cf g\ & cf _h & c Deste modo o processo terá como owner o usuário bind (grupo bind ), tornando sua execução mais segura. Para verificar a execução do BID verifique se sua maquina esta atendendo a porta 53 (netstat na) Configure seu /etc/resolv.conf para usar o IP do seu servidor de nomes : (! #if R2 6"012 3(4Ja052 Para testar sua configuração utilize o comando nslookup, que deverá retornar algo parecido com: ;( % _ ' O jf #kl cj G Q 9c(c-E!(!5km2 6"052 3(4J052 Para testar a resolução de nomes, digitamos um host (completo) no prompt:

6 n ((o O #jf #kp cj S Q 9c(c-E!(!5km2 6"052 3(4J052 8 & (( & F h!e ##k 8 Jk! cs G S 9c(c-E!(!5km2 6"052 3(4J050 9 '(&! "!5kq((r a Q ote que o nslookup mostra como um alias para bsd.howto.com.br Para fazer o reverso de nomes digitamos um IP no prompt: n 2 6"0`2 3(4Ja05?d O #jf #kp cj S Q 9c(c-E!(!5km2 6"052 3(4J052 8 Jk ( &(' a Q 9c(c-E!(!5km2 6"052 3(4J05:d Se você obteve respostas parecidas ao utilizar o nslookup, suas configurações de zona estão OK. Senão analise seus logs e verifique as zonas que apresentam problemas (com base no Serial)