O que é DNS, SMTP, SNMP...???

O que é DNS ?

O DNS (Domain Name System) e um esquema de gerenciamento de nomes, hierárquico e distribuído. O DNS define a sintaxe dos nomes usados na Internet, regras para delegação de autoridade na definição de nomes, um banco de dados distribuído que associa nomes a atributos (entre eles o endereço IP) e um algoritmo distribuído para mapear nomes em endereços.

O DNS e especificado nas RFCs 882, 883 e 973. As aplicações normalmente utilizam um endereço IP de 32 bits no sentido de abrir uma conexão ou enviar um datagrama IP. Entretanto, os usuários preferem identificar as maquinas através de nomes ao invés de números. Assim e necessário um banco de dados que permita a uma aplicação encontrar um endereço, dado que ela conhece o nome da maquina com a qual se deseja comunicar. Um conjunto de servidores de nomes mantém o banco de dados com os nomes e endereços das maquinas conectadas a Internet. Na realidade este e apenas um tipo de informação armazenada no domain system (sistema de domínios). Note que e usado um conjunto de servidores interconectados, ao invés de um único servidor centralizado. Existem atualmente tantas instituições conectadas a Internet que seria impraticável exigir que elas notificassem uma autoridade central toda vez que uma maquina fosse instalada ou trocasse de lugar. Assim, a autoridade para atribuição de nomes e delegada a instituições individuais. Os servidores de nome formam uma arvore, correspondendo a estrutura institucional. Os nomes também adotam uma estrutura similar. Um exemplo típico e o nome chupeta.jxh.xyz.br. Para encontrar seu endereço Internet, pode ser necessário o acesso a ate quatro servidores de nomes. Inicialmente deve ser consultado um servidor central, denominado servidor raiz, para descobrir onde esta o servidor br. O servidor br e o responsável pela gerencia dos nomes das instituições/empresas brasileiras ligadas a Internet. O servidor raiz informa como resultado da consulta o endereço IP de vários servidores de nome para o nível br (pode existir mais de um servidor de nomes em cada nível, para garantir a continuidade da operação quando um deles para de funcionar). Um servidor do nível br pode então ser consultado, devolvendo o endereço IP do servidor xyz. De posse do endereço de um servidor xyz e possível solicitar que ele informe o endereço de um servidorjxh, quando, finalmente, pode-se consultar o servidor jxh sobre o endereço da maquina chupeta. O resultado final da busca e o endereço Internet correspondente ao nome chupeta.jxh.xyz.br Cada um dos níveis percorridos e referenciado como

1

sendo um domínio.O nome completo chupeta.jxh.xyz.br e um nome de domínio. Na maioria dos casos, não e necessário ter acesso a todos os domínios de um nome para encontrar o endereço correspondente, pois os servidores de nome muitas vezes possuem informações sobre mais de um nível de domínio o que elimina uma ou mais consultas. Alem disso, as aplicações normalmente tem acesso ao DNS através de um processo local (servidor para as aplicações e um cliente DNS), que pode ser implementado de modo a guardar os últimos acessos feitos, e assim resolver a consulta em nível local. Essa abordagem de acesso através de um processo local, simplifica e otimiza a tarefa das aplicações no que tange ao mapeamento de nomes em endereços, uma vez que elimina a necessidade de implementar, em todas as aplicações que fazem uso do DNS, o algoritmo de caminhamento na arvore de domínios descrito anteriormente. O DNS não se limita a manter e gerenciar endereços Internet. Cada nome de domínio e um no em um banco de dados, que pode conter registros definindo varias propriedades. Por exemplo, o tipo da maquina e a lista de serviços fornecidos por ela. O DNS permite que seja definido um alias (nome alternativo) para o no. Também e possível utilizar o DNS para armazenar informações sobre usuários, listas de distribuição ou outros objetos.O DNS e particularmente importante para o sistema de correio eletrônico. No DNS são definidos registros que identificam a maquina que manipula as correspondências relativas a um dado nome, identificado assim onde um determinado usuário recebe suas correspondências. O DNS pode ser usado também para definição de listas para distribuição de correspondências 

O que é SMTP ?

O SMTP (Simple Mail Transfer Protocol) e o protocolo usado no sistema de correio eletrônico na arquitetura Internet TCP/IP. Um usuário, ao desejar enviar uma mensagem, utiliza o modulo interface com o usuário para compor a mensagem e solicita ao sistema de correio eletrônico que a entregue ao destinatário. Quando recebe a mensagem do usuário, o sistema de correio eletrônico armazena uma copia da mensagem em seu spool (área do dispositivo de armazenamento), junto com o horário do armazenamento e a identificação do remetente e do destinatário. A transferência da mensagem e executada por um processo em background, permitindo que o usuário remetente, apos entregar a mensagem ao sistema de correio eletrônico, possa executar outras aplicações. O processo de transferência de mensagens, executando em background, mapeia o nome da maquina de destino em seu endereço IP, e tenta estabelecer uma conexão TCP com o servidor de correio

2

eletrônico da maquina de destino. Note que o processo de transferência atua como cliente do servidor do correio eletrônico. Se a conexão for estabelecida, o cliente envia uma copia da mensagem para o servidor, que a armazena em seu spool. Caso a mensagem seja transferida com sucesso, o servidor avisa ao cliente que recebeu e armazenou uma copia da mensagem. Quando recebe a confirmação do recebimento e armazenamento, o cliente retira a copia da mensagem que mantinha em seu spool local. Se a mensagem, por algum motivo, não for transmitida com sucesso, o cliente anota o horário da tentativa e suspende sua execução. Periodicamente o cliente acorda e verifica se existem mensagens a serem enviadas na área de spool e tenta transmiti-las.Se uma mensagem não for enviada por um período, por exemplo de dois dias,o serviço de correio eletrônico devolve a mensagem ao remetente, informando que não conseguiu transmiti-la. Em geral, quando um usuário se conecta ao sistema, o sistema de correio eletrônico e ativado para verificar se existem mensagens na caixa postal do usuário. Se existirem, o sistema de correio eletrônico emite um aviso para o usuário que, quando achar conveniente, ativa o modulo de interface com o usuário para receber as correspondências. Uma mensagem SMTP divide-se em duas partes: cabeçalho e corpo, separados por uma linha em branco. No cabeçalho são especificadas as informações necessárias para a transferência da mensagem. O cabeçalho e composto por linhas, que contem uma palavra-chave seguida de um valor. Por exemplo, identificação do remetente (palavra-chave "to:" seguida do seu endereço), identificação do destinatário, assunto da mensagem, etc... No corpo são transportadas as informações da mensagem propriamente dita. O formato do texto e livre e as mensagens são transferidas no formato texto. Os usuários do sistema de correio eletrônico são localizados através de um par de identificadores. Um deles especifica o nome da maquina de destino e o outro identifica caixa postal do usuário. Um remetente pode enviar simultaneamente varias copias de uma mensagem, para diferentes destinatários utilizando o conceito de lista de distribuição (um nome que identifica um grupo de usuários). O formato dos endereços SMTP e o seguinte: nome_local@nome_do_dominio onde o nome_do_dominio identifica o domínio ao qual a maquina de destino pertence (esse endereço deve identificar um grupo de maquinas gerenciado por um servidor de correio eletrônico). O nome local identifica a caixa postal do destinatário. O SMTP especifica como o sistema de correio eletrônico transfere mensagens de uma maquina para outra. O modulo interface com usuário e a forma como as mensagens são armazenadas não são definidos pelo SMTP. O sistema de correio eletrônico pode também ser utilizado por

3

processos de aplicação para transmitir mensagens contendo textos. O que é SNMP ?

O sistema de gerenciamento de rede da arquitetura Internet TCP/IP opera na camada de aplicação e baseia-se no protocolo SNMP (Simple Network Management Protocol). Os padrões que definem a estrutura de gerenciamento de redes Internet são descritos nos documentos RFC-1155 (Structure Of Management Information), RFC-1156 (Management Information Base) e RFC-1157 (Simples Network Management Protocol). Como no esquema de gerenciamento OSI, os processos que implementam as funções de gerenciamento Internet atuam como agentes ou gerentes. Os agentes coletam junto aos objetos gerenciados as informações recolhidas pelos clientes, com o objetivo de detectar a presença de falhas no funcionamento dos componentes da rede (hosts, gateways, processos executando os protocolos de comunicação, etc...), para que possam ser tomadas providencias no sentido de contornar os problemas que ocorrem como conseqüência das falhas. Um objeto gerenciado representa um recurso que pode ser um sistema hospedeiro (estação de trabalho, servidor de terminais, etc...), um gateway ou um equipamento de transmissão (modem, pontes, concentradores, etc...). Cada objeto gerenciado e visto como uma coleção de variáveis cujo valor pode ser lido ou alterado. O gerente envia comandos aos agentes, solicitando uma leitura no valor das variáveis dos objetos gerenciados (get e response), ou modificando seu valor (put). A modificação do valor de uma variável pode ser usada para disparar indiretamente a execução de operações nos recursos associados aos objetos gerenciados (por exemplo, uma reiniciarão). Na troca de informações entre o gerente e o agente, são aplicados mecanismos de autenticação para evitar que usuários não autorizados interfiram no funcionamento da rede. A troca de mensagens entre o gerente e o agente e definida pelo protocolo SNMP. O SNMP define o formato e a ordem que deve ser seguida no intercambio de informações de gerenciamento. As informações sobre os objetos gerenciados são armazenados na MIB (Management Information Base), que contem informações sobre o funcionamento dos hosts, dos gateways, e dos processos que executam os protocolos de comunicação (IP, TCP, ARP, ...). A MIB e especificada em ASN.1. O funcionamento do SNMP baseia-se na troca de operações que permitem que o gerente solicite que o agente lhe informe, ou modifique, o valor de uma variável de um objeto na MIB. O SNMP define também uma operação (trap), que permite que um agente informe ao gerente a ocorrência de um evento especifico. Com o objetivo de permitir o uso do esquema de gerenciamento OSI em redes que adotam a

4

arquitetura Internet TC/IP, foi definido o protocolo de gerenciamento CMOT (CMIP Over TCP/IP). O CMOT utiliza o servico CMIS (Common Management Information Service) e o protocolo CMIP (Common Management Information Protocol) funcionando sobre uma conexão TCP/IP. O CMTU e descrito na RFC-1095. Alexandre Lopes -------------------- Mensagem editada por Tira Acentos 1.00 - Diabolik Dreamz Soft, 1995 MLº Alguem teria algum artigo em portugues sobre o que é ºDNS em um servidor, ou ate mesmo uma explicação de forma simples para ºque serve o DNS, sei somente que ele faz troca de nome por numero. É exatamente isso. Você da um nome pra ele e ele fala o endereço IP (números) correspondente aquele nome. Pra que serve isso? Pacotes IP tem de ser endereçados por números, mas é extremamente incomodo pra seres humanos decorar números. A solução foi usar um serviço que fizesse a tradução de um para outro. Quando vc faz uma conexão comwww.shareware.com o seu browser faz uma conexão com um servidor DNS pedindo o endereço IP correspondente a string "www.shareware.com". O DNS tenta resolver isso localmente, mas se não conseguir propaga a consulta pra outros servidores DNS ate conseguir (ou nao) a resposta, e então retorna o endereço pro browser que continua a conexão. Os nomes no estilo aaa.bbbbbb.cc.dddd.e são conseqüência da estrutura hierárquica usada na distribuição dos nomes, e essa estrutura é usada pra melhorar a eficiência na busca. 

19.10.1. O Que É DHCP?

DHCP, o Protocolo de Configuração Dinâmica de Servidor (Dynamic Host Configuration Protocol, Descreve os meios pelo qual um sistema pode se conectar a uma rede e obter a informação necessária para comunicação naquela rede. O FreeBSD usa a implementação de DHCP da ISC (Internet Systems Consortium), então toda informação dependente de implementação aqui disponível é para ser utilizada com a distribuição da ISC.

19.10.2. O Que Esta Seção Cobre

Esta seção descreve os componentes cliente e servidor do sistema DHCP da ISC. O programa cliente, dhclient, já vem integrado no FreeBSD e a parte servidor está disponível do port net/isc-dhcp3. As páginas de manual dhclient(8), dhcp-options(5), e dhclient.conf(5), adicionalmente às referências disponíveis abaixo, são recursos úteis.

5

19.10.3. Como Funciona

Quando o dhclient, o cliente DHCP, é executado na máquina cliente, ele começa a transmissão por difusão de requisições de informações de configuração. Por padrão, estas solicitações estão são na porta UDP 68. O servidor responde na UDP 67, dando ao cliente um endereço IP e outras informações de rede, como a máscara de rede, roteador e servidores DNS. Toda esta informação é fornecida na forma de um ``arrendamento (lease)'' e é válido somente por um determinado período (configurado pelo mantenedor do servidor DHCP). Desta forma, endereços IP atribuídos a clientes que não estão mais conectados à rede, podem ser reaproveitados automaticamente.

Clientes DHCP podem obter uma grande quantidade de informações do servidor. Uma lista completa pode ser encontrada em dhcp-options(5).

19.10.4. Integração com o FreeBSD

O FreeBSD integra totalmente o cliente DHCP da ISC, o dhclient. O suporte ao cliente DHCP é fornecido tanto no instalador quanto no sistema base, evitando a necessidade de conhecimento detalhado das configurações em qualquer rede que tenha um servidor DHCP. O dhclient foi incluído em todas as distribuições do FreeBSD, desde a versão 3.2

O DHCP é suportado pelo sysinstall. Quando configurar uma interface de rede através do sysinstall, a primeira pergunta feita é, ``Do you want to try DHCP configuration of this interface? ("Você deseja tentar configuração DHCP nesta interface?")'' Respondendo afirmativamente, será executado o dhclient, e se funcionar, as informações da configuração de rede serão preenchidas automaticamente.

Existem duas coisas que você precisa fazer para ter seu sistema usando DHCP na inicialização:

Certifique-se de que o dispositivo bpf está compilado no seu kernel. Para fazer isso, adicione o pseudo-device bpf no seu arquivo de configuração do kernel e reconstrua o kernel. Para maiores informações sobre construção de kernels, veja Capítulo 9.

O dispositivo bpf já é parte do kernel GENERIC fornecido com o FreeBSD, desta forma, se você não tem um kernel adaptado, você não precisa criar um para ter o DHCP funcionando.

6

Nota: Para os que são particularmente preocupados com segurança, você deve estar ciente de que o bpf também é o dispositivo que permite o funcionamento correto de analizadores de pacotes (embora ainda precisem ser executados pelo usuário root). O bpf é obrigatório para usar DHCP, mas se você é muito sensível com relação a segurança, você provavelmente não deve adicionar o bpf ao seu kernel na expectativa de que em algum momento no futuro você vai utilizar DHCP.

Edite o seu /etc/rc.conf para incluir o seguinte:

ifconfig_fxp0="DHCP"

Nota: Certifique-se de substituir fxp0 pela designação da interface que você deseja configurar automaticamente, como descrito em Seção 6.8.

Se você está usando um local diferente para o dhclient, ou se você deseja passar parâmetros adicionais para o comando, inclua também o seguinte (editando, se necessário):

dhcp_program="/sbin/dhclient"

dhcp_flags=""

O servidor DHCP, dhcpd, é incluído como parte do port net/isc-dhcp3 na coleção de ports. Este port contem a distribuição completa do DHCP da ISC, contendo o cliente, servidor, agente de relay e documentação.

19.10.5. Arquivos

/etc/dhclient.conf

O dhclient requer um arquivo de configuração /etc/dhclient.conf. Tipicamente o arquivo contem somente comentários e o padrões mais razoáveis definidos. Este arquivo de configuração é descrito pela página de manual dhclient.conf(5)

/sbin/dhclient

O dhclient é compilado estaticamente e reside em /sbin. A página de manual dhclient(8) fornece mais informações sobre o dhclient.

/sbin/dhclient-script

7

O dhclient-script é o script de configuração do cliente DHCP específico do FreeBSD. É descrito em dhclient-script(8), mas você não deve precisar de qualquer modificação de usuário para seu funcionamento.

/var/db/dhclient.leases

O cliente DHCP mantém uma base de dados de arrendamentos neste arquivo, que é gravado como um registro (log). dhclient.leases(5) oferece uma descrição um pouco mais longa.

19.10.6. Leitura Complementar

O protocolo DHCP é descrito totalmente na RFC 2131. Um recurso de informações também foi montado em dhcp.org.

19.10.7. Instalando e Configurando um Servidor DHCP

19.10.7.1. O Que Esta Seção Cobre

Esta seção fornece informações sobre como configurar um sistema FreeBSD para atuar como servidor DHCP usando a implementação da ISC da suíte DHCP.

A parte servidora da suíte não é fornecida no FreeBSD, então você vai precisar instalar o port net/isc-dhcp3 para ativar este serviço. Veja Capítulo 4 para mais informações sobre uso da coleção de ports.

19.10.7.2. Instalação do Servidor DHCP

Para configurar seu sistema servidor FreeBSD como um servidor DHCP, você vai precisar garantir que o dispositivo bpf(4) está compilado no seu kernel. Para isto, adicione o pseudo-device bpf ao seu arquivo de configuração do kernel e reconstrua o kernel. Para mais informações sobre construção de kernels, veja Capítulo 9.

O dispositivo bpf já é parte do kernel GENERIC, fornecido com o FreeBSD, assim você não precisa criar um kernel adaptado para ter o DHCP funcionando.

Nota: Aqueles particularmente preocupados com segurança, devem observar que o bpf também é o dispositivo que permite aos analizadores de pacotes executarem seu trabalho (apesar de tais programas precisarem de acesso

8

privilegiado). O bpf é exigido para uso do DHCP, mas se você é muito preocupado com questões de segurança, você provavelmente não deve incluir o bpf em seu kernel simplesmente por supor que vai usar DHCP em algum momento no futuro.

A próxima coisa que você vai precisar fazer é editar o exemplo dhcpd.conf que foi incluído pelo port net/isc-dhcp3. Por padrão, este será o arquivo /usr/local/etc/dhcpd.conf.sample, e você deve copiar este arquivo para /usr/local/etc/dhcpd.conf antes de modificá-lo.

19.10.7.3. Configurando o Servidor DHCP

O arquivo dhcpd.conf é composto de declarações relativas a subredes e servidores, e é, talvez, melhor explicado usando um exemplo:

option domain-name "exemplo.com";

option domain-name-servers 192.168.4.100;

option subnet-mask 255.255.255.0;

default-lease-time 3600;

max-lease-time 86400;

ddns-update-style none;

subnet 192.168.4.0 netmask 255.255.255.0 {

range 192.168.4.129 192.168.4.254;

option routers 192.168.4.1;

host mailhost {

hardware ethernet 02:03:04:05:06:07;

fixed-address mailhost.exemplo.com;

Esta opção especifica o domínio que será fornecido aos clientes como o principal domínio de busca. Veja resolv.conf(5) para mais informações sobre o que isso significa. Esta opção especifica uma lista separada por vírgulas de servidores DNS que o cliente deve utilizar. A máscara de rede que será fornecida aos clientes.

9

Um cliente pode requerer um período de tempo específico válido para um arrendamento. Senão o servidor deverá fazer um arrendamento com este prazo de expiração (em segundos). Este é o maior período de tempo permitido que o servidor deverá permitir um arrendamento. Se um cliente solicitar um período maior, um arrendamento será efetuado, entretanto, será válido somente por max-lease-time segundos. Esta opção especifica se o servidor DHCP deverá tentar atualizar o DNS quando um arrendamento é aceito ou devolvido. Na implementação da ISC, esta opção é obrigatória. Isto estipula quais endereços IP devem ser usados no conjunto reservado para alocação aos clientes. Endereços IP dentro da faixa inclusive os discriminados são distribuídos aos clientes. Declara o gateway padrão que será fornecido aos clientes. O endereço MAC de um sistema (de forma que o servidor DHCP possa reconhecê-lo quando dele receber uma solicitação). Especifica que o sistema sempre deve receber o mesmo endereço IP. Note que um hostname funciona aqui, desde que o servidor DHCP seja capaz de resolver o nome via DNS antes de responder à solicitação com as informações do arrendamento.

Quando você terminar de escrever o seu dhcpd.conf você pode dar prosseguimento, iniciando o servidor com o seguinte comando:

# /usr/local/etc/rc.d/isc-dhcpd.sh start

Se futuramente você precisar realizar alterações na configuração de seu servidor, é importante notar que enviar um sinalSIGHUP para o dhcpd não irá recarregar as configurações, como na maioria dos daemons. Você precisa enviar um sinal SIGTERM para parar o processo, e então, reiniciá-lo com o comando acima.

19.10.7.4. Arquivos

/usr/local/sbin/dhcpd

O dhcpd é compilado estaticamente e reside em /usr/local/sbin. A página de manual dhcpd(8) instalada com o port fornece mais informações sobre o dhcpd.

/usr/local/etc/dhcpd.conf

10

O dhcpd requer um arquivo de configuração, /usr/local/etc/dhcpd.conf antes de começar a prestar serviços para os clientes. O arquivo precisa conter todas as informações que devem ser fornecidas aos clientes sendo atendidos, juntamente com informações sobre a operação do servidor. Este arquivo de configuração é descrito pela página de manual dhcpd.conf(5), instalada pelo port.

/var/db/dhcpd.leases

O servidor DHCP mantém uma base de dados de arrendamentos que distribuiu neste arquivo, o qual é escrito como um arquivo de registro (log). A página de manual dhcpd.leases(5), instalada pelo port fornece uma descrição um pouco mais longa.

/usr/local/sbin/dhcrelay

O dhcrelay é usado em ambientes avançados onde um servidor DHCP repassa uma solicitação de um cliente para outro servidor DHCP em uma rede separada. A página de manual dhcrelay(8) fornecida com o port contém mais detalhes.

Introdução O que é o DHCP?; Como Funciona?; O Passado do DHCP ; Para que Serve? Onde Encontrar? ;Problemas; Conclusões

Este artigo introduz o leitor interessado no servico provido pelo Dynamic Host Configuration Protocol (DHCP), apresentando-o, quanto ao seu funcionamento e funcionalidade, bem como discutindo seus problemas. Indica, ainda, boas referencias sobre o DHCP, e locais onde pode-se encontrar uma lista de clientes e servidores.

Introdução

Apresentam-se aqui os principais conceitos do DHCP, sem entrar em detalhes sobre nenhuma implementacao especifica. O dominio dos conceitos basicos de um servico de rede e' um forte aliado na sua administracao. Este texto presta-se como uma introducao ao servico provido pelo protocolo DHCP, voltado para administradores de redes interessado no tema.

11

O que é o DHCP?

A configuracao automatica e dinamica de computadores ligados a uma rede TCP/IP, no que tange aos inumeros parametros de rede, ja' e' possivel utilizando-se o Dynamic Host Configuration Protocol (DHCP) ([RFC2131]). O DHCP, que e' hoje um protocolo recomendado, em vias de ser padronizado pelo Internet Activities Board (IAB), facilita, e ate' mesmo viabiliza, a gerencia de grandes redes IPs, assim como a vida dos usuarios itinerantes com seus computadores portateis.

Para o perfeito funcionamento de um computador ligado a uma rede Internet, nao apenas precisa-se configurar o seu endereco IP, mas tambem uma serie de outros parametros de rede. Um cliente DHCP busca encontrar um ou mais servidores DHCP que possam fornecer os parametros desejados, para que sua maquina possa ser automaticamente configurada.

Embora nao seja o unico parametro indispensavel, o endereco IP e', sem duvida, o mais importante deles, assim como o mais peculiar, posto que um determinado endereco nao deve ser utilizado por mais de um cliente ao mesmo tempo. O DCHP possibilita a implementacao uma politica de alocacao dinamica de enderecos IPs, que possibilita a reutilizacao de enderecos disponiveis ao longo do tempo.

Como Funciona?

Um servidor DHCP, respondendo a uma solicitacao de parametros de um cliente, oferece uma opcao, dentre as que tiver disponivel, para o solicitante, informando-lhe o tempo de arrendamento (leasing) dos parametros oferecidos.

Em resposta aos oferecimentos dos diversos servidores, o cliente podera' optar por aceitar, ou nao, uma das proposta, indicando o fato ao servidor da proposta eleita, ou optando por fazer nova requisicao.

Recebendo o aceite do cliente, o servidor reserva o endereco IP (se ainda estiver disponivel) e indica o fato ao cliente, que, a partir de entao, podera' fazer a correta e almejada configuracao do seu computador.

É facultado ao cliente, solicitar um re-arrendamento dos parame- tros obtidos ao servidor. Tal solicitacao devera' ser feita quando atingido a metade do tempo de arrendamento combinado, minorando assim a

12

possibilidade de ocorrencia de problemas com eventuais descompassos entre os relogios dos dois equipamentos.

Espera-se tambem que o cliente informe ao servidor quando nao for mais utilizar os recursos alocados - por exemplo, quando estiver sendo desligado. Porem, esta atitude cordial do cliente, se nao ocorrer, nao fara' com que o endereco seja indefinidamente inutilizado, posto que, ao final do tempo de arrendamento, o servidor assumira' que tal endereco podera' ser re-alocado sem problemas.

É possivel que o servidor DHCP nao esteja no mesmo enlace do cliente e que entre eles haja algum roteador que nao faca o roteamento dos pacotes DHCP. Deve-se lembrar que o cliente DHCP, por nao saber inicialmente quem e' o servidor DHCP, utiliza o broadcast para procura-lo, e que o mesmo pode ser feito pelo servidor ate' que o cliente tenha um endereco IP fixo. No caso entao de, entre o servidor e o cliente, haver um roteador que nao encaminhe devidamente pacotes DHCP, ha' a necessidade de um elemento intermediario: o relay DHCP. O relay DHCP e' uma maquina capaz de receber pacotes dos clientes DHCP de sua rede, por exemplo, e encaminhar essas solicitacoes a um ou mais servidores em outras redes.

O Passado do DHCP

O DHCP e' uma evolucao do Bootstrap Protocol - BOOTP ([RFC951]), protocolo padronizado pelo IAB, que permite a configuracao automatica de parametros de redes de um sistema, porem sem a capacidade de alocar dinamicamente estes parametros, como faz o DHCP. Nao apenas em termos de servico, o DHCP e' um "superset" do BOOTP, mas tambem em termos de protocolo. E' possivel e desejado, embora isso nem sempre ocorra, que um servidor DHCP seja capaz de atender a um cliente BOOTP e que um cliente DHCP seja atendido por um servidor BOOTP.

Para que Serve?

Ao oferecer um endereco IP a um cliente solicitante, o servidor DHCP envia-lhe outros parametros opcionais, chamados "opcoes do DHCP". Ha' dezenas deles, como mascara de rede, endereco(s) de roteador(es), enderecos de servidores de DNS, nome do cliente, nome do dominio DNS, rotas estaticas, dentre outros. Todas as opcoes disponiveis podem ser encontradas em [RFC2132].

13

Um servidor DHCP pode implementar politicas de alocacao de enderecos e opcoes DHCP de forma manual, automatica e dinamica. Na alocacao manual, o administrador do servidor DHCP estabelece um endereco IP para cada endereco Medium Access Control (MAC). Por exemplo, dado o endereco Ethernet 00:20:35:b1:49:4f, a ele sera' associado o endereco IP 192.168.0.33. Na alocacao automatica, disponibiliza-se um conjunto de enderecos IPs, de tal forma que, quando um endereco e' solicitado, um dos elementos do conjunto disponivel e' alocado de forma permanente e automatica para o solicitante. A alocacao dinamica ocorre como a automatica, exceto que o endereco e' arrendado apenas por um periodo de tempo determinado.

Em funcao dos recurso de configuracao do servidor utilizado, e' possivel a um administrador utilizar o DHCP para gerenciar a politica de distribuicao de enderecos apropriada para a sua rede. Maquinas como roteadores ou servidores devem, preferencialmente, utilizar enderecos configurados manualmente, ja' maquinas clientes fixas podem utilizar enderecos alocados automaticamente, e maquinas moveis devem adquirir enderecos de forma dinamica, por exemplo.

Uma outra aplicacao interessante e' utilizar o DHCP, em conjunto com o PPP, nos servidores de comunicacao para alocacao de enderecos e parametros de rede para clientes temporarios que utilizam o acesso discado. O PPP tem seu proprio jeito de alocar a um cliente um endereco IP: o IP Control Protocol - IPCP ([RFC1332]), que possibilita ao servidor de comunicacao (servidor PPP) passar para o cliente um endereco IP. Onde, entao, entraria o DHCP? Alguns servidores de comunicacao ([Wobus97]) podem solicitar via DHCP um determinado IP antes de passa-lo para o cliente, via IPCP.

Onde Encontrar?

O DHCP (cliente, servidor e relay) e' hoje encontrado para uma variada gama de plataformas como o UNIX, o Windows NT, o Windows 95, etc. Alguns ja' sao distribuidos em conjunto com os sistemas operacionais, e.g. o Windows 95 suporta o DHCP, o NT-4.0 vem com um servidor. Encontramos tambem implementacoes "freeware" e comerciais. Jonh Wobus lista em [Wobus97] uma serie delas. Nao encontramos problemas para instalar o Internet Software Consortium (ISC) DHCP/BOOTP Server ([ISC]) no UNIX (FreeBSD).

14

Problemas

A alocacao dinamica de enderecos nem sempre e' conveniente para todas as maquinas de uma rede. Maquinas que sao referenciadas pelos seus enderecos IPs, e nao por seus nomes, como os roteadores, por exemplo, devem ter um endereco IP fixo. Ha' casos em que um determinado recurso e' associado a um determinado endereco IP definido pelo DNS, e.g. e' comum associar um endereco IP a um servidor Web. Dessa forma, nao e' conveniente utilizar uma busca dinamica do endereco IP deste servidor. Pode-se utilizar alocacao manual, associando no servidor DHCP o endereco de MAC do servidor Web a seu endereco IP.

A alocacao dinamica pode tambem inviabilizar os esquemas de seguranca que baseiam-se em permitir ou coibir o acesso a determinados recursos atraves da identificacao do endereco IP ou do nome da maquina do solicitante (e.g. os comandos r's do UNIX ou os esquemas de controle de acesso por nome/enderecos IP do apache). Em redes onde este tipo de controle e' feito a nivel de maquina, e' necessario restringir o uso do DHCP dinamico.

O uso do DHCP dinamico pode vir a comprometer seriamente a seguranca de uma rede cujos pontos de acesso nao sao controlados, ou sao utilizados por usuarios nao confiaveis. Um usuario mal intencionado ou desavisado pode causar grandes transtornos, configurando um servidor DHCP nao oficial, por exemplo.

O DHCP e' construido sobre o protocolo UDP, que e' um protocolo inseguro, herdando, portanto, as suas falhas de seguranca.

Conclusões

A automacao da configuracao de maquinas ligadas a uma rede IP pode ser implantada utilizando-se o DHCP. Aqui, como em qualquer outro processo de automacao, e' preciso que a configuracao desse servico seja feita de forma apropriada `a rede em questao, e que nao leve a comprometer seu funcionamento e sua seguranca. Conhecendo-se o DHCP, seus recursos e suas falhas, assim como os recursos do servidor utilizado, pode-se utiliza-lo como um aliado na administracao de uma rede.

15

DNS Reverso

O DNS reverso é um recurso que permite que outros servidores verifiquem a autenticidade do seu servidor, checando se o endereço IP atual bate com o endereço IP informado pelo servidor DNS. Isso evita que alguém utilize um domínio que não lhe pertence para enviar spam, por exemplo.

Qualquer um pode enviar e-mails colocando no campo do remetente o servidor do seu domínio, mas um servidor configurado para checar o DNS reverso vai descobrir a farsa e classificar os e-mails forjados como spam.

O problema é que os mesmos servidores vão recusar seus e-mails, ou classificá-los como spam caso você não configure seu servidor DNS corretamente para responder às checagens de DNS reverso. Chegamos a um ponto em que o problema do spam é tão severo, que quase todos os servidores importantes fazem esta checagem, fazendo com que, sem a configuração, literalmente metade dos seus e-mails não sejam entregues.

O primeiro passo é checar os arquivos /etc/hostname e /etc/hosts (no servidor), que devem conter o nome da máquina e o domínio registrado.

O arquivo /etc/hostname deve conter apenas o nome da máquina, como em: servidor

No Fedora e em algumas outras distribuições, o nome da máquina vai dentro do arquivo /etc/sysconfig/network.

No arquivo /etc/hosts deve conter duas entradas, uma para a interface de loopback, o 127.0.0.1, e outra para o IP de internet do seu servidor, que está vinculado ao domínio, como em:

127.0.0.1 localhost.localdomain localhost

64.234.23.12 servidor.kurumin.com.br servidor

A partir daí, falta adicionar a zona reversa no bind complementando a configuração do domínio, que já fizemos. Começamos adicionando a entrada no /etc/bind/named.conf ou /etc/bind/named.conf.local:

zone "23.234.64.in-addr.arpa" {

16

type master;

file "/etc/bind/db.kurumin.rev";

};

No nosso exemplo, o endereço IP do servidor é 64.234.23.12. Se retiramos o último octeto e escrevemos o restante do endereço de trás pra frente, temos justamente o 23.234.64 que usamos no registro reverso. A terceira linha indica o arquivo onde a configuração do domínio reverso será salva. Neste caso indiquei o arquivo db.kurumin.rev, mas você pode usar qualquer nome de arquivo.

Este arquivo db.kurumin.rev é bem similar ao arquivo com a configuração do domínio, que acabamos de configurar. As três linhas iniciais são idênticas (incluindo o número de sincronismo), mas ao invés de usar o A para relacionar o domínio e cada subdomínio ao IP correspondente, usamos a diretiva PTR para relacionar o endereço IP de cada servidor ao domínio (é justamente por isso que chamamos de DNS reverso ;).

No primeiro arquivo, usamos apenas os três primeiros octetos do endereço (a parte referente à rede), removendo o octeto final (o endereço do servidor dentro da rede). Agora, usamos apenas o número omitido da primeira vez.

O IP do servidor é 64.234.23.12, removendo os três primeiros octetos ficamos apenas com o 12. Temos também o endereço do DNS secundário, que é 64.234.23.13, de onde usamos apenas o 13. Relacionando os dois a seus respectivos domínios, o arquivo fica:

@IN SOAservidor.kurumin.com.br. hostmaster.kurumin.com.br. (

2006040645 3H 15M 1W 1D )

NS servidor.kurumin.com.br.

NS ns1.kurumin.com.br.

12PTRkurumin.com.br.

13PTRns1.kurumin.com.br.

17

Caso você não esteja usando um DNS secundário, é só omitir as linhas referentes a ele, como em:

@IN SOAservidor.kurumin.com.br. hostmaster.kurumin.com.br. (

2006040645 3H 15M 1W 1D )

NS servidor.kurumin.com.br.

12PTRkurumin.com.br.

Depois de terminar, reinicie o Bind e verifique usando o dig. Comece checando o domínio, como em:

# dig kurumin.com.br

Na resposta, procure pela seção ANSWER SECTION, que deverá conter o IP do servidor, como configurado no bind:

;; ANSWER SECTION:

kurumin.com.br. 86400 IN A 64.234.23.12

Faça agora uma busca reversa pelo endereço IP, adicionando o parâmetro -x, como em:

# dig -x 64.234.23.12

Na resposta você verá:

;; ANSWER SECTION:

12.23.234.64.in-addr.arpa. 86400 IN PTR kurumin.com.br.

Ou seja, com o DNS reverso funcionando, o domínio aponta para o IP do servidor e o IP aponta para o domínio, permitindo que os outros servidores verifiquem a autenticidade do seu na hora de receber e-mails provenientes do seu domínio.

18

Lembre-se que seus e-mails podem ser classificados como spam também se seu IP estiver marcado em alguma blacklist. Você pode verificar isso rapidamente no http://rbls.org/.

Você vai notar, por exemplo, que praticamente endereço IP de uma conexão via ADSL ou modem vai estar listado, muitas vezes "preventivamente", já que é muito comum que conexões domésticas sejam usadas para enviar spam. É recomendável verificar periodicamente os IP's usados pelo seu servidor, além de verificar qualquer novo IP ou link antes de contratar o serviço.

Como Funciona o DNS Reverso

O DNS Reverso resolve um endereço IP para um nome de servidor por exemplo, ele poderia resolver 200.176.3.142 para exemplo.hipotetico.com.br.

Para os seus domínios, o DNS direto (que resolve um nome de servidor para um endereço IP, como quando se resolve exemplo.hipotetico.com.br para 200.176.3.142) começa na instituição (registro.br, para domínios registrados no Brasil) onde você registrou os seus domínios. Nesse registro, você deve dizer quais são os servidores de DNS que respondem pelos nomes no seu domínio, e o registro.br enviará essa informação para os root servers. Então, qualquer um no mundo pode acessar os seus domínios, e você pode encaminhá-los para qualquer IP que você quiser. Você tem total controle sobre os seus domínios, e pode encaminhar as pessoas para qualquer IP (tendo ou não controle sobre esses IPs, embora você não deva encaminhá-los para IPs que não são seus, sem permissão).

O DNS reverso funciona de forma parecida. Para os seus IPs, o DNS reverso (que resolve 200.176.3.145 de volta para exemplo.hipotetico.com.br) começa no seu provedor de acesso ou de meio físico (ou com quem quer que lhe diga qual é o seu endereço IP). Você deve dizer-lhe quais servidores de DNS que respondem pelos apontamentos de DNS reverso para os seus IPs (ou, eles podem configurar esses apontamentos em seus próprios servidores de DNS), e o seu provedor passará esta informação adiante quando os servidores de DNS deles forem consultados sobre os seus apontamentos de DNS reverso. Então, qualquer um no mundo pode consultar os apontamentos de DNS reverso dos seus IPs, e você pode responder com qualquer nome que quiser (tendo ou não controle sobre os domínios desses

19

nomes, embora você não deva apontá-los para nomes que não são dos seus domínios, sem permissão).

Então, tanto para DNS direto quanto para DNS reverso, há dois passos: [1] Você precisa de servidores de DNS, e [2] Você precisa informar a entidade correta (o registro.br para consultas de DNS direto, ou o seu provedor para consultas de DNS reverso) quais são os seus servidores de DNS. Sem o passo 2, ninguém vai conseguir alcançar os seus servidores de DNS.

Se você pôde compreender os parágrafos acima (o que pode levar algum tempo), você entenderá o maior problema que as pessoas têm com apontamentos de DNS reverso. O maior problema que as pessoas têm é que elas possuem servidores de DNS que funcionam perfeitamente para seus domínios (DNS direto), elas então incluem apontamentos de DNS reverso nesses servidores e o DNS reverso não funciona. Se você entendeu os parágrafos acima, você já percebeu o problema: Se o seu provedor não sabe que você tem servidores de DNS para responder pelo DNS reverso dos seus IPs, ele não vai propagar essa informação para os root servers, e ninguém vai nem mesmo chegar aos seus servidores de DNS para consultar o DNS reverso.

Conceitos Básicos:

O DNS reverso resolve 200.176.3.142 para exemplo.hipotetico.com.br (um endereço IP para um nome de servidor).

O caminho de uma consulta típica de DNS reverso: Resolver de DNS root servers LACNIC (Orgão que distribui endereços IP na América Latina e Caribe) registro.br (responsável pela distribuição de IPs no Brasil) Provedor de acesso ou de meio físico Servidores de DNS do usuário do IP.

Quem quer que proveja os seus endereços IP (normalmente o seu provedor) DEVE ou [1] configurar seus apontamentos de DNS reverso nos servidores deles, ou [2] “delegar a autoridade” dos seus apontamentos de DNS reverso para os seus servidores de DNS.

Apontamentos de DNS reverso são feitos com nomes que são o endereço IP invertido com um “.in-addr.arpa” adicionado no final – por exemplo, “142.3.176.200.in-addr.arpa”.

20

Apontamentos de DNS reverso são configurados com registros PTR (enquanto que no DNS direto usa-se registros A), feitos dessa forma: “142.3.176.200.in-addr.arpa.  PTR  exemplo.hipotetico.com.br.” (enquanto que no DNS diretos, seriam assim: “exemplo.hipotetico.com.br. A 200.176.3.142").

Todos os servidores na Internet devem ter um apontamento de DNS reverso (veja RFC 1912, seção 2.1).

Servidores de correio eletrônico sem DNS reverso terão dificuldades para entregar e-mails para alguns grandes provedores.

Um Mito Muito Comum:

Mito: Se você tem um apontamento de DNS reverso registrado no seu servidor de DNS, seu DNS reverso está corretamente configurado.

Fato: Isso geralmente não é o caso. Você precisa de DUAS coisas para ter um DNS corretamente configurado:

Seus servidores de DNS (ou os do seu provedor) DEVEM ter os apontamentos de DNS reverso configurados (“142.3.176.200.in-addr.arpa.  PTR  exemplo.hipotetico.com.br.”).

E seu provedor de acesso ou de meio físico DEVEM configurar o DNS reverso no lado deles, de forma que os resolvers de DNS por todo o mundo saibam que os seus servidores de DNS são os que devem ser consultados quando quiserem resolver o DNS reverso dos seus endereços IP.

Como uma consulta de DNS reverso é efetuada:

O resolver de DNS inverte o IP e adiciona “.in-addr.arpa” no final, transformando 200.176.3.142 em 142.3.176.200.in-addr.arpa.

O resolver de DNS então consulta o registro PTR para 142.3.176.200.in-addr.arpa.

O resolver de DNS pergunta aos root servers pelo registro PTR do 142.3.176.200.in-addr.arpa.

21

Os root servers encaminham O resolver de DNS para os servidores de DNS encarregados da faixa “Classe A” (200.in-addr.arpa, que cobre todos os IPs que começam com 200).

Em quase todos os casos, os root servers irão encaminhar o resolver de DNS para um “RIR” (“Registro de Internet Regional”). Estas são as organizações que distribuem os IPs. Usualmente, LACNIC controla os IPs da América Latina e Caribe, ARIN controla os IPs da América do Norte, APNIC controla os IPs da Ásia e do Pacífico, e RIPE Controla os IPs da Europa.

O resolver de DNS irá perguntar aos servidores de DNS do “RIR” indicado pelos root servers pelo registro PTR do 142.3.176.200.in-addr.arpa.

Dependendo do “RIR”, a resposta pode ser um encaminhamento direto para a entidade que recebeu o range de IPs (como faz a ARIN), ou como no nosso caso, um encaminhamento para uma organização nacional que controla os IPs no país dentro da região de abrangência do “RIR”. Por exemplo, a LACNIC responderia que os servidores de DNS encarregados da faixa “Classe B” (176.200.in-addr.arpa) são os do registro.br, que controla a distribuição de IPs no Brasil.

Nesse segundo caso, o resolver de DNS irá perguntar agora para os servidores do registro.br pelo registro PTR do 142.3.176.200.in-addr.arpa.

Os servidores de DNS do registro.br vão encaminhar o resolver de DNS para a entidade que recebeu o range de IPs. Estes são, normalmente os servidores de DNS do seu provedor de acesso ou de meio físico.

O resolver de DNS irá perguntar aos servidores de DNS do provedor pelo registro PTR do 142.3.176.200.in-addr.arpa.

Os servidores de DNS do provedor vão encaminhar o resolver de DNS para os servidores de DNS da organização que de fato está usando o IP.

O resolver de DNS irá perguntar aos servidores de DNS da organização pelo registro PTR do 142.3.176.200.in-addr.arpa.

Finalmente, os servidores de DNS da organização irão responder com “exemplo.hipotetico.com.br”.

22