unesp UNIVERSIDADE ESTADUAL PAULISTA Prof. Dr. Adriano Mauro Cansian UNESP - IBILCE - São José do Rio Preto

Transcrição

1 unesp UNIVERSIDADE ESTADUAL PAULISTA Tópicos em Sistemas de Computação Administração de Redes TCP/IP DNS - Domain Name Service (Parte 2 - Configuração) Prof. Dr. Adriano Mauro Cansian UNESP - IBILCE - São José do Rio Preto

2 DNS - Domain Name Service 1 (Parte 2 - Configuração) Prof. Dr. Adriano Mauro Cansian UNESP - IBILCE - São José do Rio Preto 1. Introdução A configuração de um sistema DNS baseado no BIND (named) é coberta por 3 tarefas básicas: Configurar o resolver Configurar o BIND 2 name server O processo do BIND chama-se named (name daemon) Construir as bases de dados do name server, denominadas arquivos de zona Configurações exigidas Configuração dos Servidores Primários (primary servers) O servidor primário ou authoritative server carrega as informações a respeito do domínio a partir de arquivos locais (arquivos de zona e outros) mantidos pelo administrador do domínio. Configurar um servidor primário exige um conjunto completo de arquivos de configuração: 1 Créditos - este material foi produzido principalmente a partir do livro texto adotado no curso: Hunt, Craig - TCP/IP Network Administration - O Reilly & Associates, Inc. - 1.a Edição - Capítulo 3, pag. 51 e Capítulo 8, pag 167. Também foi utilizado material referente ao RFC- 1033, denominado Domain Administrators Operations Guide. 2 Para maiores informações sobre o BIND, incluindo RFCs e outros documentos importantes, consulte: Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-1

3 Arquivos de zona do domínio named.hosts ou dominio.algum.lugar.db Arquivos reversos do domínio named.rev ou número_do_ip.db Arquivo de configuração de boot do named named.boot ou named.conf (BIND V8 e V9) Arquivo de cache named.cache ou root.cache Arquivo de configuração do loopback named.local ou db Configuração dos Servidores Secundários Servidores secundários são aqueles que transferem (copiam) um conjunto completo de informações a partir do servidor primário. Servidores SECUNDÁRIOS não possuem arquivos de zona próprios. A configuração de um servidor secundário não exige os arquivos de zona (os quais são transferidos do servidor primário). Entretanto, os outros arquivos são necessários: Arquivo de configuração de boot do named named.boot Arquivo de cache named.cache ou root.cache Arquivo de configuração do loopback named.local ou db Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-2

4 As configurações e formato dos arquivos dos servidores serão discutidas mais adiante Configuração do Resolver O resolver não é um processo distinto e separado do sistema operacional. Ele é uma biblioteca de rotinas que são chamadas pelos processos de rede. Se existe um arquivo /etc/resolv.conf, ele é lido cada vez que se inicia um processo que usa o resolver. O arquivo de configuração do resolver /etc/resolv.conf Trata-se de um arquivo muito simples, com algumas poucas diretivas. Existem algumas definições que são específicas de cada sistema, mas duas delas estão presentes universalmente: nameserver address(ip) Identifica pelo IP, quem é o nameserver a ser buscado por aquela máquina. Podem ser definidos, em seqüência, 3 nameservers. domain name.do.dominio define o domínio DNS default. Durante uma operação, o resolver anexa (append) este nome de domínio a qualquer hostname que não é terminado por um ponto (. ). Exemplo de um arquivo /etc/resolv.conf para uma máquina cliente pura de DNS do domínio dcce.ibilce.unesp.br: Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-3

5 # /etc/resolv.conf # comentarios aparecem com sinal de # # dominio dcce.ibilce.unesp.br # configuracao do resolver domain dcce.ibilce.unesp.br # o primeiro nameserver a ser buscado é a primária do domínio nameserver # o segundo nameserver é a máquina principal do campus nameserver Configuração do sistema rodando named - servidor primário Arquivos exigidos para configurar o named: Nome usual do arquivo: named.boot (ou named.conf dependendo da versão do BIND. Vide observações no tópico 2.1 abaixo) Descrição: Ajusta os parâmetros gerais do named, e aponta para as bases de dados usadas pelo servidor. Estes dados podem ser arquivos locais, ou servidores remotos. named.cache ou root.cache Define os root servers named.local ou db Resolução de loopback named.hosts ou dominio.db Arquivo de zona que mapeia host names para endereços IP e demais configurações. named.rev ou IP-completo.db Arquivo de zona reverso, que mapea endereço IP em host names Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-4

6 2.1. Iniciando o BIND named.boot O arquivo /etc/named.boot é usado até a versão 4.x.x do BIND, que é conhecida como família BIND-4. Em maio de 1997, a partir dos desenvolvimentos da Internet Software Consortium ( surgiu a família BIND-8.x As famílias BIND-4 e BIND-8 possuem sérios problemas de segurança e seu uso deve ser fortemente desencorajado. Em setembro de 2000, surgiu a versão BIND-9.x, a qual possui melhorias significativas com relação a segurança e outros aspectos de performance, principalmente suporte a DNSSEC e aos protocolos TSIG (Secret Key Transaction Authentication for DNS) e IPv6. Para uma revisão histórica do BIND, consulte: A versão atual, (verificada em agosto de 2009) é a As versões mais recentes do BIND não usam o arquivo de configuração named.boot mas sim /etc/named.conf, o qual possui uma sintaxe de diretivas diferente. Este é o único arquivo que difere entre a família 4 e as famílias 8 e 9. Neste curso, por questões didáticas, iniciaremos nosso estudo pelo named.boot. A configuração do /etc/named.conf (família 8 e 9) é mais elaborada, devido a mudança da sintaxe da configuração e maior disponibilidade de recursos. Os alunos deverão observar os detalhes de configuração do named.conf, consultando a documentação disponível em: Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-5

7 O arquivo /etc/named.boot Este arquivo aponta para a fonte de informação do DNS. Ele é consultado durante a inicialização do processo named. Possui algumas diretivas básicas apresentadas a seguir. Diretiva: Função: directory Define um diretório para todas as referências de arquivo subsequentes da configuração. Deve ser a primeira diretiva do arquivo named.boot primary # master * Declara este servidor como sendo primário para a zona específica secondary # Declara este servidor como sendo slave * secundário para a zona específica cache Aponta para o arquivo de cache. Note mo exemplo que o apontador do arquivo de cache é um. (ponto). forwarders Lista servidores para os quais os queries são redirecionados. Diretiva pouco usada em configurações usuais. Note que a maneira como se configura o named.boot (ou o named.conf) controla se o servidor vai atuar como servidor primário, secundário ou caching-only. Um mesmo servidor pode ser primário para um domínio e secundário para outro, entretanto não pode ser primário e secundário ao mesmo tempo tecnicamente isso é possível, mas não é uma prática aceitável, uma vez que viola o RFC Orientação para estudo: Existem diferentes maneiras de se configurar servidores primários e secundários. Neste material serão apresentados exemplos de configurações mais usadas. Estes exemplos serão completamente discutidos a analisados em sala, mas não serão descritos totalmente neste material de aula, pois isto está feito no livro texto do curso. Para uma discussão detalhada das configurações, consulte Hunt, Craig - TCP/IP Network Administration - O Reilly & Associates, Inc, capítulo 8 e Apêndice D. # Usado com BIND-4 e named.boot * Usado com BIND-8 e BIND-9 no /etc/named.conf Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-6

8 Exemplo 1: named.boot para um servidor apenas primário máquina master.dcce.ibilce.unesp.br: master.dcce.ibilce.unesp.br comentários iniciam com Type Domain Source file or host diretiva Dominio / definicao Arquivo fonte ou host diretório onde se encontram os arquivos directory /var/named tipo : domínio: arquivo: primary dcce.ibilce.unesp.br dcce.zone primary IN-ADDR.ARPA db primary IN-ADDR.ARPA db cache. root.cache --- end --- Anotações: Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-7

9 Exemplo 2: named.boot para um servidor primário e secundário, máquina master.ibilce.unesp.br: master.ibilce.unesp.br Type Domain Source file or host directory /var/named Dominios primarios arquivos de zones tipo: domínio: arquivo: primary ibilce.unesp.br ibilce.zone primary polo.ibilce.unesp.br polo.zone primary ensino.ibilce.unesp.br ensino.zone primary acme.org.br acme.zone Dominios primarios - arquivos de reversos Tipo: Domínio reverso: arquivo: primary IN-ADDR.ARPA db primary IN-ADDR.ARPA db primary IN-ADDR.ARPA db primary IN-ADDR.ARPA db Dominios para os quais sou secundario: Tipo: Domíno: Onde buscar: Salvar em: secondary unesp.br unesp-zone.bak secondary dcce.ibilce.unesp.br dcce- zone.bak secondary df.ibilce.unesp.br df-zone.bak secondary feb.br feb.zone.bak secondary pref.sjr.sp.gov.br pref-zone.bak Dominios para os quais sou secundario de reverso Tipo: Domíno: Onde buscar: Salvar em: secondary IN-ADDR.ARPA db.bak secondary IN-ADDR.ARPA db.bak secondary secondary IN-ADDR.ARPA db.bak IN-ADDR.ARPA db.bak cache. root.cache fim Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-8

10 Exemplo 3: named.conf para bind 9.x /* * named.conf para bind 9 para o domínio ibilce.unesp.br *! Este arquivo é apenas para exemplo * NÃO está completo devido a restrição de espaço */ options { directory "/var/named" diretório onde ficam os arquivos check-names master warn /* default. */ datasize 20M allow-transfer { } /* Máquinas para as quais permito transferir meus registros de DNS */ /* Estas máquinas são normalmente as secundárias (slaves) que copiam meus mapas */ } logging { category cname { null } category lame-servers { null } } /* Domínios para os quais sou servidor direto (mapas master) */ zone "ibilce.unesp.br" IN { type master file " master/ibilce.unesp.br.zone " arquivo onde está o mapa master } /* Domínios para os quais sou servidor secundário (mapas slave) */ /* Não estão apresentados todos os diretos, devido a restrição de espaço */ zone " dcce.ibilce.unesp.br " IN { type slave file " slave/dcce.ibilce.unesp.br.zone.bak " arquivo onde armazena o mapa secundário masters { } local onde vai buscar o mapa master } /* Mapas diretos reversos */ zone " in-addr.arpa" IN { type master file " db" arquivo onde está o mapa master Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-9

11 } /* continuação */ /* Mapas secundários (slaves) reversos */ zone " in-addr.arpa" IN { type slave file " db.bak" arquivo onde armazena o mapa secundário masters { } local onde vai buscar o mapa master allow-transfer { none } } zone " in-addr.arpa" IN { type slave file " db.bak" arquivo onde armazena o mapa secundário masters { } local onde vai buscar o mapa master allow-transfer { none } } /* Mapas Slaves da Reitoria */ zone "unesp.br" { type slave file "sec/unesp.zone.bak" arquivo onde armazena o mapa secundário masters { local onde vai buscar o mapa master } } zone " in-addr.arpa" { type slave file "sec/unesp.1.rev.bak" masters { } } /* Resolver local */ zone "localhost" IN { type master file "localhost.zone" check-names fail allow-update { none } allow-transfer { any } } zone "." IN { type hint file "root.cache" } /* Este arquivo é apenas para exemplo e NÃO está completo devido a restrição de espaço */ Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-10

12 2.2. Standard Resource Records - Arquivos de zona Os demais arquivos named.hosts (ou o nome equivalente do arquivo de mapa direto), named.rev, named.cache (ou o nome equivalente do arquivo de mapa reverso) e named.local (ou nomes similares), são usados para configuração dos arquivos de zona. Como dito anteriormente, estes são os arquivos que contém as informações das bases de dados de cada domínio, e o mapeamento de nomes para números IP (diretos) e vice-versa (reverso). Todos estes arquivos possuem o mesmo formato básico, e usam os mesmos tipos de registros para definir as informações. Os registros usados nos arquivos são chamados de registrospadrão de recursos (standard resource records) ou simplesmente resource records (RRs). A seguir são apresentados resumidamente os tipos de registros disponíveis no BIND. Para uma discussão detalhada dos formatos dos registros consulte o Apêndice D da 1 ª Edição de TCP/IP Network Administration por Craig Hunt, ou então consulte Name Server Operations Guide for BIND, disponível em Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-11

13 Nome do RR Start of Authority DNS Resource Records principais Indicador do tipo do registro SOA Descrição: Marca o início de dados de uma zona e define parâmetros que afetam a zona inteira. Name server NS Identifica (aponta) um name server para um domínio Address A Converte (aponta) um host name para um endereço IP. Pointer PTR Converte um endereço IP para um host name (mais usado em reversos). Mail Exchange MX Identifica (aponta) onde entregar mensagens para um dado domínio ou host name. Canonical name Host Information Wel known Services CNAME HINFO WKS Define um alias (sinônimo ou nome canônico) para um host name. Descreve o hardware e SO de um host. Pouco usada atualmente por motivos de segurança. Anuncia os serviços de rede disponíveis naquele host. Não é exigida, e é pouco usada atualmente por motivos de segurança. Os RRs são definidos no RFC-1033 Domain Administrators Operations Guide. Um pequeno entendimento destes registros é necessário para a compreensão dos arquivos de configuração. Alguns registros são mais complexos e necessitam de uma análise mais detalhada, principalmente os registros SOA e MX. Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-12

14 O formato básico de um registro do DNS é o seguinte: [name] [ttl] IN type Data name ttl IN type Data Este é o nome do objeto de domínio que o RR referencia. Pode ser um nome de host individual ou um domínio inteiro. Se for inserido um string qualquer, como por exemplo um hostname, ele é relativo ao domínio corrente, a menos que ele termine com um ponto. Se o campo name é deixado em branco o registro se aplica ao objeto de domínio que foi nomeado por último (mais acima na configuração). Time to live define o tempo, em segundos, que a informação deste registro deve ser mantida em cache em outros hosts. Usualmente este campo é deixado em branco, e é usado o ttl default, ajustado para toda a zona no início do arquivo, ou seja, na definição do SOA. Define um registro como sendo um RR Internet. Existem outras classes, mas não são usadas. Identifica de que tipo se trata este RR, descritos na tabela anterior (SOA, MX, A, etc..) Deve sempre ser especificado um valor neste campo. Trata-se da informação específica deste tipo de registro, por exemplo, se é um registro tipo A, este campo deverá conter o endereço IP verdadeiro. Observação: na verdade, a complexidade dos registros é maior do que esta apresentada na tabela. Existem muitos detalhes que não estão sendo discutidos aqui. Para uma descrição detalhada do formato e sintaxe dos registros, consulte o apêndice disponível no livro texto TCP/IP Network Administration, ou então outros documentos disponiveis em Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-13

15 2.2.1.O arquivo de inicialização de cache Diretiva cache no /etc/named.boot aponta para um arquivo de configuração de cache, usualmente chamado named.cache ou root.cache Este arquivo é usado para estabelecer um cache inicial dos nomes de domínio quando o nameserver inicializa. O root domain é indicado na declaração de cache por um único ponto (. ) Um arquivo de cache possui, pelo menos, os nomes e endereços dos root servers. Um named.cache contém registros NS que identificam os nomes dos root servers e registros A que fornecem os endereços destes root servers. Exemplo: Um arquivo básico de cache (/var/named/root.cache), usado no domínio ibilce.unesp.br This file holds the information on root name servers needed to initialize cache of Internet domain name servers (e.g. reference this file in the "cache. <file>" configuration file of BIND domain name servers). This file is made available by InterNIC registration services under anonymous FTP as file /domain/named.root on server ftp://ftp.rs.internic.net/domain/. 6D IN NS G.ROOT-SERVERS.NET.. 6D IN NS J.ROOT-SERVERS.NET.. 6D IN NS K.ROOT-SERVERS.NET.. 6D IN NS L.ROOT-SERVERS.NET.. 6D IN NS M.ROOT-SERVERS.NET.. 6D IN NS A.ROOT-SERVERS.NET.. 6D IN NS H.ROOT-SERVERS.NET.. 6D IN NS B.ROOT-SERVERS.NET.. 6D IN NS C.ROOT-SERVERS.NET. Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-14

16 . 6D IN NS D.ROOT-SERVERS.NET.. 6D IN NS E.ROOT-SERVERS.NET.. 6D IN NS I.ROOT-SERVERS.NET.. 6D IN NS F.ROOT-SERVERS.NET. ADDITIONAL SECTION: G.ROOT-SERVERS.NET. 5w6d16h IN A J.ROOT-SERVERS.NET. 5w6d16h IN A K.ROOT-SERVERS.NET. 5w6d16h IN A L.ROOT-SERVERS.NET. 5w6d16h IN A M.ROOT-SERVERS.NET. 5w6d16h IN A A.ROOT-SERVERS.NET. 5w6d16h IN A H.ROOT-SERVERS.NET. 5w6d16h IN A B.ROOT-SERVERS.NET. 5w6d16h IN A C.ROOT-SERVERS.NET. 5w6d16h IN A D.ROOT-SERVERS.NET. 5w6d16h IN A E.ROOT-SERVERS.NET. 5w6d16h IN A I.ROOT-SERVERS.NET. 5w6d16h IN A F.ROOT-SERVERS.NET. 5w6d16h IN A Total query time: 215 msec FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET WHEN: Sun Feb 15 01:22: MSG SIZE sent: 17 rcvd: 436 fim Este arquivo descreve o nome dos servidores raiz no mundo. Este conteúdo pode mudar com o passar do tempo, mas raramente muda. Se houver mudança, tem que ser atualizado. A última mudança ocorreu em 28/01/2004 (estamos em 26/08/2009). Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-15

17 2.2.2.O arquivo named.local Os arquivo named.local ou db é usado apenas para converter o endereço que é o endereço de loopback para o nome localhost. Exemplo: Arquivo local da máquina master.dcce.ibilce.unesp.br master.dcce.ibilce.unesp.br File: /var/named/ db BIND data file for local loopback interface. Origin of zone: IN SOA master.dcce.ibilce.unesp.br. adriano.nimitz.ibilce.unesp.br. ( Serial (o serial sempre deve aumentar) Refresh (3 horas em segundos ) 3600 Retry (1 hora em segundos) Expire (5 dias em segundos) Minimum TTL (24 hrs em segundos) ) IN NS master.dcce.ibilce.unesp.br. IN NS dixit.ansp.br. 1 IN PTR localhost. localhost. IN A fim Outra maneira de definir os tempos, ao invés de usar segundos: master.dcce.ibilce.unesp.br File: /var/named/ db BIND data file for local loopback interface. Origin of zone: IN SOA master.dcce.ibilce.unesp.br. adriano.nimitz.ibilce.unesp.br. ( Serial (o serial sempre deve aumentar) 8H Atualização, H = horas 2H Tentativa, H = horas 1W Expiração, W = semanas 1D ) TTL, D = Dias IN NS master.dcce.ibilce.unesp.br. IN NS dixit.ansp.br. 1 IN PTR localhost. localhost. IN A fim Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-16

18 2.2.3.O arquivo de zona direto Trata-se do arquivo principal de definição do domínio. Este arquivo só deve ser criado no servidor primário. Entre outras operações, converte hostnames em endereços IP registro tipo A são predominantes. Entretanto, outros registros aparecem CNAME, MX, dentre outros Todos os outros servidores buscam estas informações no servidor primário. Muito importante assim como os demais arquivos de configuração, o arquivo de zona direto é muito sensível a falhas de digitação. Como este arquivo contém mais informações, ele está mais sujeito a erros. Um único caractere errado pode ter conseqüências desastrosas, e fazer com que o named saia do ar, interrompendo todas as operações do domínio. Tenha muito cuidado ao editar ou modificar estes arquivos! Exemplo: Arquivo direto do servidor primário do domínio dcce.ibilce.unesp.br. Máquina master.dcce.ibilce.unesp.br /var/named/dcce.ibilce.unesp.br.db Resource Record information for dcce.ibilce.unesp.br domain For mapping of names to addresses (direct mapping) File: /var/named/dcce.ibilce.unesp.br.db = origin of the zone (dcce.ibilce.unesp.br) {name} {ttl} {class} {type} {data} Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-17

19 @ IN SOA master.dcce.ibilce.unesp.br. hostmaster.dcce.ibilce.unesp.br. ( serial 22/09/1998 V refresh (3hs) 3600 retry (1h) expire (5 dias) minimum ttl (24 hs) ) IN NS master.dcce.ibilce.unesp.br. observe o. (ponto) no final dos nomes NS wolverine.dcce.ibilce.unesp.br. NS master.ibilce.unesp.br. MX 0 master.dcce.ibilce.unesp.br. servidor de para o domínio MX 10 wolverine.dcce.ibilce.unesp.br. servidor de para o domínio continua Name servers master.ibilce.unesp.br. IN A ibilce.unesp.br. IN NS master.ibilce.unesp.br. localhost IN A master IN A IBM Server NIS & DNS shadowcat IN A IBM Secondary NIS & DNS wolverine IN A Sparc LX dazzlen IN A IBM havok IN A Axil 240 casper IN A Sparc 5 router IN A Router Cisco 7010 chivas IN A Server Novell 4.11 MX 10 master.dcce.ibilce.unesp.br. nimitz IN A Server Novell 3.11 MX 10 master.dcce.ibilce.unesp.br. MX 20 wolverine.dcce.ibilce.unesp.br. Alias especias para o dominio dcce.ibilce.unesp.br mail IN CNAME master.dcce.ibilce.unesp.br. www IN CNAME shadowcat.dcce.ibilce.unesp.br. ftp IN CNAME shadowcat.dcce.ibilce.unesp.br. hosts do laboratorio de pesquisa intruder IN A spiderman IN A Prof. Jose Marcio batman IN A Prof. Ranga Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-18

20 robin IN A Prof. Adriano poirot IN A Proj. Socorro hosts dos gabinetes dos docentes fantasma IN A Prof. Adriano scully IN A Sala de Est. Pos(ariel) maggie IN A Prof. Aleardo t darkman IN A Prof. Ranga scar IN A Prof. Ralha [nota do material de aula: alguns hosts foram removidos aqui, para ] [economia de espaço da apostila - Adriano. ] OS dois abaixo sao testes do Printserver lexmark - Adriano 19/fev lexmark1 IN A lexmark2 IN A laser4tn IN A LaserJet 4TN andar superior fim Dois aspectos devem ser observados sobre o registro SOA. master.dcce.ibilce.unesp.br deve ser uma máquina real com um registro A. Não é permitido ter um registro CNAME para a máquina mencionada no registro SOA. O nome não precisa ser 'master', pode ser qualquer nome de máquina válido. Em seguida, a entrada hostmaster.dcce.ibilce.unesp.br deve ser lida como hostmaster@dcce.ibilce.unesp.br, o qual deve ser um nome alternativo de correio, ou caixa postal, acessado pela(s) pessoa(s) que mantém o DNS e leiam a correspondência freqüentemente. Qualquer correspondência relativa ao domínio será enviada para o endereço relacionado aqui. O nome não precisa ser 'hostmaster', pode ser qualquer endereço válido, como por exemplo chefe_do_dns mas espera-se que o endereço 'chefe_do_dns' funcione corretamente e seja lido. Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-19

21 Há um novo tipo RR neste arquivo, o MX, ou registro de recurso de servidor de correio. Este arquivo diz aos sistemas de correspondência para onde estes devem enviar a correspondência endereçada para alguém@dcce.ibilce.unesp.br, ou seja no nosso caso master.dcce.ibilce.unesp.br ou wolverine.dcce.ibilce.unesp.br. O número antes de cada nome de máquina define a prioridade. O RR com o número mais baixo tem prioridade. Caso ele não esteja ativo ou apresentar algum erro, a mensagem pode ser enviada a um outro servidor de mensagens com um número mais alto, um operador de correspondência secundário, ou seja, no nosso caso, wolverine.dcce.ibilce.unesp.br que tem prioridade O arquivo reverso do domínio - named.rev O arquivo reverso é semelhante ao arquivo de zona direto, e também ao arquivo db (reverso do localhost). Uma coisa importante aqui, é notar que IPs são escritos ao contrário no campo in-addr.arpa. Por exemplo, caso o endereço da máquina seja , o named encontrará servidores arpa., in-addr.arpa., 192.in-addr.arpa., in-addr.arpa., in-addr.arpa. Este arquivo também só deve ser criado pelo administrador no servidor primário. A seguir veremos um exemplo de um arquivo reverso para a rede Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-20

22 Exemplo: resource Record information for IN-ADDR.ARPA domain For mapping of addresses to names (reverse mapping) File: /var/named/ db = origin of the zone (dcce.ibilce.unesp.br) {name} {ttl} {class} {type} {data} Note outra maneira de iniciar um SOA IN-ADDR.ARPA. IN SOA master.dcce.ibilce.unesp.br. adriano.nimitz.ibilce.unesp.br. ( serial 1800 refresh (30 min) 3600 retry (1h) expire (5 dias) minimum ttl (24 hs) ) IN NS master.dcce.ibilce.unesp.br. NS wolverine.dcce.ibilce.unesp.br. NS master.ibilce.unesp.br. NS nusselt.eta.ibilce.unesp.br. 1 IN PTR master.dcce.ibilce.unesp.br. IBM Master NIS & DNS 2 IN PTR shadowcat.dcce.ibilce.unesp.br. Note o. no final dos nomes 3 IN PTR wolverine.dcce.ibilce.unesp.br. 4 IN PTR dazzlen.dcce.ibilce.unesp.br. IBM T Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-21

23 5 IN PTR havok.dcce.ibilce.unesp.br. Axil IN PTR casper.dcce.ibilce.unesp.br. Sparc-5 "Norian" 10 IN PTR router.dcce.ibilce.unesp.br. Router (Polo Novo) 20 IN PTR chivas.dcce.ibilce.unesp.br. Server Novell IN PTR nimitz.dcce.ibilce.unesp.br. Server Novell continuação... hosts do laboratorio de pesquisa 36 IN PTR poirot.dcce.ibilce.unesp.br. hosts do gabinetes dos docentes [nota da apostila: alguns hosts foram removidos para economia de espaço ] [ entretanto, todos os hosts que aparecem na zona direta devem estar ] [cadastrados no reverso. -Adriano. ] 102 IN PTR laser4tn.dcce.ibilce.unesp.br. LaserJet andar sup. Hosts do Laboratorio da Pos- Graduacao 109 IN PTR lisa.dcce.ibilce.unesp.br. Pentium-200-linux 109 IN PTR foxbat.dcce.ibilce.unesp.br. Micro da POS-GRAD Hosts da Secretaria do Departamento... em IN PTR zandor.dcce.ibilce.unesp.br. PC da Olga 111 IN PTR batgirl.dcce.ibilce.unesp.br. PC da Sandy Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-22

24 115 IN PTR notebook.dcce.ibilce.unesp.br. notebook Adriano hosts do departamento de Engenharia de alimentos ( ) hosts engenharia nova ( ) 121 IN PTR etan01.eta.ibilce.unesp.br. secretaria IN PTR etan26.eta.ibilce.unesp.br. biblioteca 147 IN PTR etan27.eta.ibilce.unesp.br. jose antonio 153 IN PTR etan33.eta.ibilce.unesp.br. joao claudio 160 IN PTR etan40.eta.ibilce.unesp.br. salao frente 161 IN PTR etan41.eta.ibilce.unesp.br. salao fundos hosts da engenharia velha ( ) 181 IN PTR etav01.eta.ibilce.unesp.br. lab. didatico comp. 182 IN PTR nusselt.eta.ibilce.unesp.br. ibm power pc - nis - nusselt 183 IN PTR biot.eta.ibilce.unesp.br. ibm dns - biot 184 IN PTR etav04.eta.ibilce.unesp.br. lab. didatico comp. 185 IN PTR etav05.eta.ibilce.unesp.br. lab. didatico comp. 186 IN PTR etav06.eta.ibilce.unesp.br. lab. didatico comp Configuração de um servidor recursivo Para configurar um servidor apenas recursivo, é necessário utilizar a diretiva allowrecursion. A diretiva informa para o BIND quais redes ou hosts são habilitados a usar esse servidor como recursivo. Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-23

25 É importante utilizar a restrição de serviço pois isso acarreta em problemas de segurança, sem contar o fato de prover serviço para hosts que não pertencem ao ambiente administrado. A configuração nas versões 9 do BIND deve ser feita na seção options do arquivo named.conf. Para facilitar a configuração, é possível também criar listas de controle de acesso (ACL Access Control List). A ACL é um recurso que permite especificar com facilidade quais hosts, redes ou sub-redes terão acesso a determinado serviço controlado pela ACL. As ACLs devem ser feitas no arquivo named.conf. No exemplo abaixo temos uma configuração de uma ACL e do parâmetro allowrecursion. Exemplo: // Exemplo de criação de ACL // acl minharede { /24 }... options { //linhas suprimidas... allow-recursion { minharede /8 } //linhas suprimidas... } Anotações: Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-24

26 Exercícios: 1.) Explique como funciona o utilitário de administração denominado nslookup. Apresente exemplos de utilização. 2.) Explique como funciona e como se implementa um serviço de resolução de endereços denominado DHCP. Dê exemplos sobre como ele é configurado. 3.) Explique como funciona e como se implementa um serviço de resolução de endereços denominado bootp. Apresente as exigências sobre onde ele pode ser utilizado (domínio, mesmo segmento de rede, etc...). Mostre como é um arquivo de configuração. 4.) Crie um domínio fictício, denominado acme.org.br e crie os arquivos de configuração de DNS primário e secundário, além do resolver, para um conjunto de 10 máquinas que formam o site. Considere que a máquina principal chama-se master.acme.org.br e ela deve ser responsável por receber os s para o domínio acme.org.br. Considere também que a máquina secundária chama-se coiote.acme.org.br e ela deve também responder como Dê os nomes que você desejar para as outras máquinas. Use uma rede classe C fictícia. Explique como o que é o sistema de base de dados whois e como ela funciona. Apresente alguns exemplos de funcionamento. Faça testes para entender sua operação. Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-25

27 Anotações: Referências: Prof. Adriano Mauro Cansian Administração de Redes TCP/IP DNS, Parte 2-26