DNS – Domain Name System

Todo SysAdmin precisa lidar com o DNS, um DNS bem configurado é a base de uma rede onde serviços são executados. Entender como o DNS funciona e como podemos melhorá-lo é importante para fazer o serviço funcionar corretamente e de forma segura.

Vamos falar hoje como o serviço funciona e suas principais características.

Os servidores de DNS são os principais servidores na internet, pois permitem que através de nomes possamos acessar os endereços. Já que toda a internet[bb] é baseada em IP, para acessarmos uma página precisaríamos conhecer número IP dela, mas como é mais fácil lembrar de vários nomes que vários números, o DNS permite que esses nomes sejam resolvidos para números, facilitando assim o uso da internet.

No início da internet, como foi pensada para pouco uso, havia um arquivo hosts.txt que continha todos os IP e nomes de máquinas que existiam na internet, o arquivo era mantido pela NIC (Network Information Center) e distribuído por um único host, o SRI-NIC. Os administradores da Arpanet enviavam ao NIC, por e-mail, quaisquer mudanças que tivessem sido efetuadas e periodicamente SRI-NIC era atualizado, assim como o arquivo hosts.txt. As mudanças eram aplicadas em um novo hosts.txt uma ou duas vezes por semana. Com o crescimento da Arpanet, entretanto, este esquema tornou-se inviável. O tamanho do arquivo hosts.txt crescia na proporção em que crescia o número de máquinas na internet.

Além disso, o tráfego gerado com o processo de atualização crescia em proporções ainda maiores uma vez que cada host que era incluído não só significava uma linha a mais no arquivo hosts.txt, mas um outro host atualizando a partir do SRI-NIC. Com o uso do TCP/IP pela Arpanet a rede cresceu exponencialmente o que tornou a atualização do arquivo algo quase impossível de ser mantido.

Os administradores da Arpanet tentaram outras configurações que resolvessem o problema do hosts.txt. O objetivo era criar um sistema que resolvesse os problemas em uma tabela única de hosts. O novo sistema deveria permitir que um administrador local tornasse os dados mundialmente disponíveis. A descentralização da administração resolveria o problema do gargalo gerado por um único host e diminuiria o problema do tráfego. Além disso, o fato da administração ser local faria com que atualizar os dados se
tornasse uma tarefa bem mais simples. O esquema deveria usar nomes em hierarquia para garantir a exclusividade dos nomes.

Paul Mockapetris, do USC’s Information Science Institute, foi o responsável pela arquitetura do sistema. Em 1984 ele lançou as RFCs 882 e 883, que descreve o “Domain Name System”, ou DNS. Estas RFCs foram sucedidos pelas RFCs 1034 e 1035, que possuem as especificações atuais do DNS.

O DNS é foi criado para ser hierárquico, distribuído e recursivo, além de permitir o cache de suas informações. Assim nenhuma máquina teria que saber todos os endereços de Internet, apenas os que estão abaixo dela diretamente. Os principais servidores de DNS são os Root Servers, servidores raiz de Internet (.). São servidores que sabem quais são as máquinas responsáveis pelos domínios de primeiro nível. Ao todo existem 13 Root Server. Resumindo:

– Hierárquico: Divide a resolução de nomes em Níveis;
– Distribuido: Ninguém mais sabe tudo, cada um sabe apenas uma parte do endereço;

Para melhor entendermos podemos exemplificar a busca por um domínio da seguinte forma:

Um cliente pede ao DNS de seu provedor por um IP de um domínio, faz com o o DNS siga o seguinte caminho:

Então quando você não tem um DNS de cache e precisa resolver um endereço, o resolvedor (cliente) solicita ao servidor Root Server o endereço. Como o Root Server só conhece os domínios de primeiro nível (.com .org .br .uk), ele repassa para o servidor que ele conhece que está ligado ao pedido do cliente, no caso o .br, que passa pra quem sabe a resposta o .com que passa pra quem sabe a resposta .cooperati que indica qual host tem a informação pedida.

O DNS trabalha com as portas 53 (UDP e TCP) e 953 (TCP) para seu funcionamento e controle, respectivamente. A porta 53 UDP é usada para consultas entre Servidor e Cliente, e a porta 53 TCP geralmente é usada para sincronia (troca de arquivos de database de zonas) entre Master (Primário) e Slave(Secundário), a porta 953 é usada para programas externos se comunicarem com o BIND, por exemplo um DHCP que queira adicionar o nome dos hosts que receberam IP dentro da zona do DNS, lógico que isso só deve ser feito se estabelecermos uma relação de confiança entre eles, a fim de evitar que o DNS tenha dados sobrescritos por qualquer software.

O BIND foi criado por quatro estudantes de graduação, membros de um grupo de pesquisas em ciência da computação da Universidade de Berkeley e foi distribuído pela primeira vez com 4.3BSD. O programador Paul Vixie(criador da vixie-cron), enquanto trabalhava para a empresa DEC, foi o primeiro mantenedor do BIND. Atualmente o BIND é suportado e mantido pelo Internet Systems Consortium (ISC).

O desenvolvimento do BIND 9 foi realizado através de uma combinação de contratos comerciais e militares. A maioria das funcionalidades do BIND 9 eram promovidas por empresas fornecedoras de sistemas Unix que queriam garantir que o BIND se manteria competitivo com as ofertas de servidores DNS da Microsoft. Por exemplo, a extensão de segurança DNSSEC foi financiada pelos militares dos EUA que perceberam a importância da segurança para o servidor DNS.

Entendendo o BIND

A configuração do BIND é feita em duas etapas:
– Primeiro criamos os domínios (zonas) dentro do arquivo named.conf, isso faz com o o BIND saiba que existe um ou mais domínios por quem ele deve responder, cria-se nesse arquivo as zonas diretas e reversa. As seções criadas no arquivo named.conf especificam que tipo de DNS estamos configurando (Master ou Slave), qual arquivo de database contém as máquinas que pertencem a cada domínio e alguns parâmetros de acesso ou segurança.

– Em segundo lugar devemos criar o arquivo da zona, o arquivo de database que contém os dados de autoridade sobre o domínio e que contém os nomes e IP de cada máquina que pertence a esse domínio, tanto da zona direta quanto da reversa, que é importante principalmente quando se trata de servidores de E-mail que verificam a existência de mapeamento inverso de IP (IP para nome) confirmando assim a identidade de um emissor de email.

Nos arquivos de configuração de zonas utilizamos o RR (Resource Record), ou seja registro de recursos, que são os registros de dados do DNS. São usados para descrever os hosts e recursos utilizados pelo DNS para uma determinada zona. Esses recursos são utilizados tanto para consulta de IP quanto para consulta de chaves, informações sobre o servidor, informações sobre o email, informações sobre dados adicionais, etc.

Segundo as especificações das RFC: 1035, 1876, 2535, 2672, 2782, 2930, 2931, 3445, 3596, 3658. Os principais RR são:
SOA – Geralmente o primeiro registro de uma zona, contém dados do domínio, email do responsável pelo domínio e os intervalos de tempo para manutenção da zona;
@ IN SOA 82c.bd8.myftpupload.com. adm.82c.bd8.myftpupload.com. ( 2011102001; 3600; 7200; 86400; 3600; )

NS – Mapeia os servidores de nome com autoridade desta zona, têm sempre um registro A associado a ele, muito importante para o funcionamento da zona;
@ IN NS ns1.82c.bd8.myftpupload.com.

MX – Especifica o servidor de E-mail associado ao domínio e qual a prioridade dele, quanto menor o número associado mais importante é o servidor, têm sempre um registro A associado a ele;

@ IN MX 10 mail.82c.bd8.myftpupload.com.

A – Especifica um endereço associado a um nome, em IPv4;
ftp IN A 172.16.1.254

AAAA – Especifica um endereço associado a um nome, em IPv6;
ftp IN AAAA 2002:0a14:01dc::1

CNAME – Especifica um apelido para um host da rede;
pop3 IN CNAME mail

DNAME – Mapeia um apelido para um domínio inteiro, permite que ao apontar para um determinado host seja redirecionado para toda uma subárvore de domínio;
cooperati.net.br. IN DNAME 82c.bd8.myftpupload.com.

HINFO – Um registro HINFO fornece informações sobre tipo de CPU e sistema operacional para um host do domínio. Nomes de CPU e SO podem ser obtidos em http://www.iana.org/protocols:
molde_mestre.82c.bd8.myftpupload.com. HINFO INTEL[bb]-386 Linux

KEY – recurso de chave pública pública associada a uma zona. Utilizada pelo DNSSEC para autenticar os registros de recursos SIG recebidos de zonas assinadas, as informações são exibidas na ordem: protocolo, assinatura da chave, chave publica;
82c.bd8.myftpupload.com. IN DNSKEY 256 3 3 BOMbSz…

LOC – Esse registro fornece a possibilidade de especificar as informações sobre localização de computadores, sub-redes e redes no mundo. As opções são: latitude, longitude, altura, tamanho, precisão horizontal, precisão vertical;
82c.bd8.myftpupload.com IN LOC 43 01 04.012 S 19 32 01.210 W 832.40m 1.10m 11003.00m 11.00m

MINFO – Esse registro fornece uma lista de servidores para uma caixa de correio ou lista de correio, o primeiro ponto faz o papel de @ (arroba);
admin.82c.bd8.myftpupload.com. IN MINFO suporte.82c.bd8.myftpupload.com.

PTR – Esse registro provê mapeamento indireto para registros do DNS, mapeia IP para nome;
254.1.16.172 IN PTR ftp.82c.bd8.myftpupload.com.

RP – Esse registro têm o e-mail da pessoa responsável pela zona ou host;
82c.bd8.myftpupload.com. IN RP dnsmaster.82c.bd8.myftpupload.com.

SRV – Esse registro permite a seleção de um servidor, muito usado pela Microsoft[bb] para informar os servidores do AD para os clientes. A RFC 1700 define alguns dos dados utilizados neste registro, ele informa: serviço, protocolo, nome, prioridade, importância, porta, destino;
_ldap._tcp._msdcs SRV 0 0 389 ldap.82c.bd8.myftpupload.com.

TXT – Esse registro contém uma informação qualquer que queira ser passada para aqueles que consultarem a zona;
82c.bd8.myftpupload.com. IN TXT “Site muito bom, só com Feras e tem um tal de Vagner também…”

SPF – Esse registro define o servidor de email autorizado a enviar mensagens pelo domínio. É consultado por servidores de email para confirmar autoridade sobre um domínio.
82c.bd8.myftpupload.com. IN TXT “v=spf1 include:cooperati.net.br -all”

RRSIG – Registro de recurso assinado, utilizado em DNS com DNSSEC.
82c.bd8.myftpupload.com. 6 IN RRSIG A 5 3 60 20100723102502…

Os arquivos também podem incluir as diretivas de zona:
$ORIGIN – Guarda o nome da zona.
$INCLUDE – Inclui um arquivo dentro da zona.
$TTL – Tempo de vida das consultas de DNS.
Para maiores informações sobre outros recursos consulte as RFC mencionadas acima. Para informações sobre recursos mais utilizados em português consulte a rnp.br.

Espero que esse artigo inicial tenha ajudado a entender um pouco da estrutura do DNS, no próximo artigo falarei sobre como configurar um domínio usando o Bind e posteriormente em como melhorar a segurança do mesmo.

Não esqueçam de assinar o nosso Portal e divulgar para que possamos crescer e melhorar sempre.

  • Muito bom!

    Seu eu tivesse acesso a esse tipo de post na minha época de iniciante tenho certeza que a evolução seria muito mais rápida!

    Sou meio suspeito para falar, mas acho que o conteúdo do CooperaTI é sem igual no Brasil!

  • Tá faltando um link para compartilhar com o Google+

  • Bruno Cruz – Belém Pará

    Material excelente ! vou guardar esse material que um dia vou precisar (de novo)… falo precisar de novo porque um dia precisei e foi muito difícil encontrar!!

  • wellinton

    Muito bom !!!

    Uma sujes tao, que tal uma serie de tópicos para ajudar a galera a tirar suas certificações ,
    por exemplo eu to querendo tirar a 70 640 (estou começando) apesar de já trabalhar com servidores pequenos e virtualização sinto que preciso muito da teoria e apesar de ter muita coisa na net tem muito material que não esclarece bem o que precisamos ou são equivocados em seu conteúdo então pensando nisso me veio a ideia uma vez que o COOPERATI possui conteúdo muito bom e de muita credibilidade.

    se for rolar fico no aguardo anciloso , caso não, se alguém poder compartilhar um bom material agradeço desde ja.

    • Wellington,

      Nestes artigos não estou me focando em provas específicas, mas em como funcionam os serviços ou tecnologias. Como no post sobre roteamento estático, apesar de tê-lo feito em Linux, os conceitos apresentados nele servem para qualquer sistema operacional.

  • João Fernando

    Parabens ! Muito Bomm , Obrigado

  • Junior

    Wagner, ótimo post, mas seria legal se vc fizesse um video-tutorial em que vc colocasse um modelo de bind com mais de um dominio e com alguns dos recursos mensionados aqui inclusive com o recurso de view e e-mail para ambos os domínios com reverso, já pesquisei na net mas nunca achei um material que seja completo e seguro em que possamos confiar.
    Parabéns pelos tópicos e obrigado por nos ajudar com amplo conhecimento.

    Abraço

  • jonas

    Vagner blz. Recentemente tenho sofrido varios ataques de DOS em alguns do nossos servidores de dns. U samos uma solucao djbDNS somente para cache. Gostaria de uma orientação sua, de qual poderia ser uma ferramenta para mitigar de forma mais eficaz e barrar o ip do atacante.. isto de forma mais eficaz.
    Hoje usamos o iptraf, e todos bloqueo hora e feito por iptables.
    Hora usamos peakflow par analise e dentro deele algumas regras . Gostaria que vc comentasse sobre outra ferramenta talvez de dns ou uma ferramenta para ajudar a bloquear estes ataques. Percebi tambem que volte e meia alguma rotas principalmente de banco somente neste recursivo sao injetadas. Até agora nao descobri, o que temporariamente fiz, foi criar uma regra que de tempo em tempos restart o servico desta forma, meio tosca, consegui temp. resolver o problema
    Se puder ajudar fica ae meu apelo. valeu

  • Fernando

    Olá Vagner,
    Estou com problema de acesso em um dos site da empresa. No servidor onde já tem um site rodando e funcionando adicionando mais um site.
    Criei no dns Primario e secundario as entradas ficando assim.
    site1 A 200.1.2.3
    site CNAME site1
    A pagina fica intermitente hora acessa e outra hora dar pagina nao encontrada mas o site antigo funciona normal.
    Fiz os teste de dns e responde, fiz o mesmo procedimento pra colocar outros site no ar e funcionou. Agora eu nao sei o q é.

    • Fernando,

      Tem certeza que não tem conflito de nomes para esse site?
      Utiliza um RR A para esse site em vez do CNAME para testar.

      Abraço.

      • Fernando

        Se eu entendi o q seu comentário sobre o RR A, eu acho q já fiz.
        Antes, no inicio eu fiz um entrada no bind ficando assim,
        novosite A 200.1.2.3 e tava com o mesmo problema.Foi entao q eu mudei para o CNAME.
        mas eu tenho outro site em outro servidor com o nome parecido com esse q tá com problema.o meu dns ficou assim

        intranet A 200.1.2.1
        moodle CNAME intranet
        cursos A 200.1.2.2
        novomoodle CNAME cursos

        Com nomes de site parecidos mesmo apontando pra servidores diferente dar problema?

        Obrigado pela a sua atenção Vagner.

        • Fernando,

          Não dá problemas não, pode ser diferente uma letra apenas…
          No início do seu aquivo você colocou a variável $ORIGIN ?
          Se não sempre coloque os nomes FQDN, tipo:

          intranet.dominio.com. A 200.1.2.1
          moodle.dominio.com. CNAME intranet.dominio.com.
          cursos.dominio.com. A 200.1.2.2
          novomoodle.dominio.com. CNAME cursos.dominio.com.

          Lembre do . no final que indica que o nome termina ali.

          Abraço.