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.

19.10.3. Como Funciona

5
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