>_Dns 1.3

Servidor de zonas

Cada domínio na Internet tem sua autoridade, que nada mais édo que um servidor onde as informações daquele domínio são criadas, mantidas ou alteradas. Mas como um domínio pode se sub-dividir em inúmeros outros domínios, surge um outro conceito: Zonas.

Uma zona é o conjunto dos hosts de um domínio sobre o qual se mantém autoridade. Uma vez delegado um subdomínio a outra autoridade, os hosts desse domínio pertecem a zona daquela autoridade, e não mais a zona original onde inicia-se o subdomínio.

Principais tipos de registros

Existem diversos tipos diferentes de registros DNS disponíveis. A lista a seguir não pretende, de maneira alguma, ser extensa ou exaustiva, mas antes mostrar os mais comuns que vai encontrar por ai.

* A – Address; especifica um endereço IP direto
* AAAA – Address IPv6; especifica um endereço IPv6
* NS – NameServer; especifica servidores DNS para o domínio ou subdomínio
* CNAME – Canonical NAME; um apelido para outro hostname
* MX – Mail eXchanger; o servidor de email
* PTR – PoinTeR; aponta o hostname/domínio reverso a partir de um endereço IP
* SOA – Start Of Authority; indica o responsável por respostas autoritativas por um domínio
* TXT – TeXT; permite incluir um texto curto em um hostname; usado para implementar o SPF
* SRV – SeRVice; permite definir serviços disponíveis em um domínio

Estes são os principais, e que você provavelmente vai achar por aí. Vamos agora considerar alguns deles que requerem carinho especial dos administradores.

SOA: aonde tudo começa

O SOA ou Start Of Authority indica o servidor e administrador responsável por um domínio, além de indicar outras informações úteis, como número serial da zona DNS, tempo de vida do registro SOA, intervalo de replicação de zonas, etc. Veja um exemplo:

dig -t soa uol.com.br
(…)
;; ANSWER SECTION:
uol.com.br.             3575    IN      SOA     eliot.uol.com.br. root.uol.com.br. 2005081804 7200 3600 432000 3600
(1)                     (2)             (3)     (4)               (5)              (6)        (7)  (8)  (9)    (10)
(…)

* 1 – nome da zona consultada
* 2 – TTL do registro na memória do seu DNS
* 3 – tipo de registro
* 4 – DNS responsável pela zona
* 5 – email do responsável pelo DNS acima
* 6 – número serial da zona; recomenda-se o formato YYYYMMDDxx (ano com 4 dígitos, mês, dia e quantidade de alterações durante o dia)
* 7 – refresh ou tempo em que um servidor com a zona replicada tenta replica-la de novo
* 8 – intervalo entre tentativas de replicação
* 9 – TTL do SOA
* 10 – tempo mínino que a zona deve ser retida em memória

Registros temperamentais: MX e PTR

Os registros MX e PTR merecem carinho especial dos seus administradores. O formato do registro MX é (imaginando o domínio dominio.com.br):

.   IN MX 10 mail.dominio.com.br
.   IN MX 50 mail2.dominio.com.br

O “.” se refere ao domínio imediatamente superior, ou seja, a zona atual (não se trata de um subdomínio). O número define a preferência do MX. Quanto menor o número, maior sua preferência ou prioridade de receber emails.

Note que os hostnames mail.dominio.com.br e mail2.dominio.com.br DEVEM ser registros “A”, jamais “CNAMEs” nem endereços IP. Embora esses tipos de registros possam funcionar, não estão de acordo com as definições de melhores práticas de DNS publicadas em RFCs, e irão causar dores de cabeça ao administrador responsável, uma vez que haverá atrasos e falhas de entrega de email para seu domínio.

Já os registros PTR devem estar colocados debaixo de uma zona específica chamada “in-addr.arpa”.

O registro PTR deve ser colocado com os octetos do endereço IP invertidos, e o hostname indicado PRECISA existir e apontar para o mesmo endereço IP. Por exemplo, se tivermos o endereço 189.185.67.13, seu registro PTR seria: — 189.185.67.13 IN PTR meureverso.gnulinuxbr.com.br

E, obrigatoriamente, para que seu registro PTR seja válido e funcional, o host meureverso.sardine.com.br PRECISA apontar de volta para 189.185.67.13.

Para consultarmos se nosso reverso está ok, basta rodarmos o seguinte comando:

dig -t ptr 189.185.67.13.in-addr.arpa

Ferramenta útil

Existem diversas ferramentas que são aquela aspirina na hora da dor de cabeça com DNS. Aqui listo uma bem interessante.

  • http://www.dnsreport.com – um site que faz um check-up completo em zonas DNS, exibe problemas, avisa sobre melhores práticas e aponta especificações a seguir.


Tipos de zonas e registros

Em relação as znas, o BIND pode operar de acordo com 6 tipos: master, slave, stud, hint, forward e delegation-only.

  • master – O BIND vai responder como autoridade sobre aquele domínio. OS dados da zona serão criados, publicados e administrados a partir dele.
  • slave – O BIND também vai responder por esse domínio, mas nenhuma criação ou alteração respectiva a essa zona será feita localmente neste servidor. Os dados serão sempre tranferidos de um servidor master.
  • stub – Este tipo de zona não é previsto em nenhuma RFC e foi implementado apenas no BIND. Assemelha-se a uma zona slave mas replica do master apenas os registros do tipo NS. Em desuso.
  • hint – Específica para o BIND onde ele deve começar uma busca recursiva quando estiver operando como cache. Por padrão, há uma zona hint criada com os endereços dos root servers.
  • forward – Server para orientar o BIND a encaminhar a consulta sobre uma determinada zona para outro servidor em especial. O encaminhamento de consultas também pode ser especificado de maneira global no arquivo named.conf.options.
  • delegation-only – Para evitar abusos de algumas autoridades sobre domínios de primeiro nível (COM, NET, ORG), o BIND mantém o tipo de zna “delegação apenas”. Qualquer resposta que não tenha uma delegação explícita ou implicita na seção autoridade será transformada em uma resposts NXDOMAIN.

Vamos configurar nossa própria zona DNS que vai se chamar gnulinuxbr.com.br. Pode ser que na internet já exista um domínio com este nome, mas isso não importa porque nossas consultas ficarão limitadas ao teste nosso teste interno.

As zonas devem ser declaradas no arquivo named.conf.local. Uma zona mestre precisa, no minímo do nome do domínio, tipo de zona e o caminho para o banco de dados de registros. Quando apenas o nome do arquivo é citado, o servidor BIND vai procurá-lo no diretório definido na opção directory, do arquivo named.conf.options.

Isso significa que, por padrão, o caminho completo corresponderia a /var/cache/bind/db.gnulinuxbr

O conteúdo do banco de dados da zona que foi declarada será principalmente uma série de registro de recursos (resources records), ou simplesmente, registros. No entanto três diretivas são suportadas:

  • $TTL;
  • $ORIGIN;
  • $INCLUDE.

Mas com exceção do $TTL, são raramente utilizadas.

Um registro tem o seguinte formato:

dono[TTL] [classe] tipo de dados.

dono – É o nome do registr. Quando substituído por uma @, o dono é o próprio domínio. Caso o dono fique em branco, o BIND assume o nome do registro imediatamente superior.

TTL – Um valor em segundos para a permanência dos dados deste registro no cache de um servidor. Raramente utilizado.

classe – Podem ser CH, HS ou IN. O padrão é IN, de Internet, e não precisa ser declarada.

tipo – No momento existem mais de 30 tipos de registro, dentre os quais veremos SOA, NS, MX, A, CNAME, TXT e PTR.

dados – Diferentes tipos de dados são definidos para diferentes tipos de registros. Para um registro tipo A temos um endereço IP por exemlo.

Recentemente, registros do tipo TXT tem sido usados para aumentar o controle contra spams. São criados de acordo com o formato definido pelo projeto Sender Policy Framework, ou simplesmente SPF.

O SPF diz quais servidores odem ENVIAR e-mails em nome do seu domínio. O objetivo é evitar que seu domínio seja usado para forjar remetentes falsos. Grandes provedores já adotaram o SPF, e cada vez mais outros domínios vem seguindo a mesma prática. Tende a tornar-se uma imposição. Muito mais antigo que o SPF, e por consequência, uma imposição natural do ecossistema de e-mails, é garantir que o IP do registro MX tenha endereço reverso. Esta é uma forma de checar se o e-mail partiu de um usuário doméstico cujo computador está sendo como zumbi, por exemplo.

Normalmente, configurar o endereçamento reverso não depende do administrador do domínio, e sim do provedor do link. Porém, é possível requisitar autoridade sobre o bloco de IPs destinado àquele link. Vai depender do provedor. Mas como em nosso caso estamos utilizando apenas endereços privados, vamos assumir a autoridade sobre todo o bloco 192.168.0/27.

Continua na parte 4.

até.

>_Dns 1.3
Tagged on:

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

%d blogueiros gostam disto: