O protocolo DNS

Entendendo como funciona a resolução de nomes de domínio

O protocolo DNS é há muito tempo utilizado tanto na internet quanto em redes privadas. O objetivo deste artigo é dar uma pequena introdução sobre esse protocolo que utilizamos diariamente.

Renato Botelho do Couto, Staff Software Engineer, IBM

Renato Botelho do CoutoRenato Botelho é Engenheiro de Software do Linux Technology Center Brazil, onde atua na equipe de Infraestrutura. Membro do projeto FreeBSD desde 2005. Tem mais de 12 anos de experiência em sistemas UNIX-Like e redes.



04/Jun/2012

O protocolo DNS

Introdução

O DNS (Domain Name System) é um serviço que utilizamos sempre que fazemos um acesso à internet, mesmo que não saibamos disso. Quando digitamos um endereço em um Browser, ele irá fazer uso do DNS para transformar o nome do host em um endereço IP.

Essa não é a única função desse protocolo, mas é um exemplo bem simples e que comprova como a nossa vida seria difícil sem ele, imagina decorarmos os endereços IP de todos os sites que acessamos todos os dias? Seria uma missão impossível.

Um pouco de história

Na década de 70, a ARPANet (Advanced Research Projects Agency Network) era uma rede pequena, então todos os nomes das máquinas ficavam em um único arquivo, um arquivo texto, chamado HOSTS.TXT (veja RFC 952).

Nesse ambiente, se o endereço IP de um servidor mudasse, não havia uma maneira simples de garantir que o arquivo HOSTS.TXT de todos os outros servidores seriam também alterados, para refletir a alteração.

Além disso, a rede foi crescendo, o que tornou ainda mais inviável o uso do arquivo estático em cada ponto da rede.

Na década de 80 foi desenvolvido o protocolo e a primeira implementação do DNS, primeiro nas RFCs 882 e 883, e depois substituídas pelas RFCs 1034 e 1035. A primeira implementação de um servidor DNS para Unix aconteceu em 1984, quando 4 estudantes de Berkeley escreveram o Berkeley Internet NameDomain (BIND), que é amplamente utilizado até os dias de hoje.

Como funciona a resolução de nomes

Quando uma estação de trabalho é configurada para acessar uma rede TCP/IP, ou de forma manual ou usando DHCP, é configurado um ou mais servidores de DNS, que trabalham de forma recursiva.

Quando algum software da sua estação de trabalho precisar resolver algum nome, ele irá antes de mais nada consultar o arquivo hosts, que em sistemas GNU/Linux, se encontra em /etc/hosts. Esse arquivo pode conter endereços estáticos que serão usados antes de fazermos uma consulta à um servidor DNS.

Se o nome de domínio não for encontrado no arquivo hosts, a estação de trabalho irá fazer uma requisição para esse servidor DNS recursivo, esse por sua vez vai primeiro consultar se o nome de domínio requisitado pertence a ele mesmo, pois muitas vezes um servidor DNS trabalha como autoritativo e recursivo, e vai também consultar o seu cache, se encontrar já responde para sua estação de trabalho.

Caso esse nome de domínio não esteja presente nas zonas autoritativas e nem no cache, ele então fará o papel de servidor recursivo e irá resolver o nome.

A primeira consulta é feita a um dos RootServers, que é o ponto de partida na resolução de nomes. Normalmente o RootServer não vai saber resolver aquele nome, mas vai indicar um caminho a seguir, respondendo quem é responsável por parte do domínio, então o seu DNS recursivo vai consultar um desses servidores retornados pelo RootServer, até resolver completamente o domínio.

Nos sistemas GNU/Linux, a ordem de pesquisa (/etc/hosts seguido de DNS recursivo) pode ser alterada através do arquivo de configuração /etc/host.conf.

Vamos fazer uma demonstração, para resolver o hostwww.receita.fazenda.gov.br, começando de um RootServer:

# dig @198.41.0.4 www.receita.fazenda.gov.br

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc16 <<>> @198.41.0.4 www.receita.fazenda.gov.br
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12668
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 8
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.receita.fazenda.gov.br.	IN	A

;; AUTHORITY SECTION:
br.			172800	IN	NS	a.dns.br.
br.			172800	IN	NS	d.dns.br.
br.			172800	IN	NS	f.dns.br.
br.			172800	IN	NS	c.dns.br.
br.			172800	IN	NS	e.dns.br.
br.			172800	IN	NS	b.dns.br.

;; ADDITIONAL SECTION:
a.dns.br.		172800	IN	A	200.160.0.10
a.dns.br.		172800	IN	AAAA	2001:12ff::10
b.dns.br.		172800	IN	A	200.189.40.10
c.dns.br.		172800	IN	A	200.192.232.10
d.dns.br.		172800	IN	A	200.219.154.10
e.dns.br.		172800	IN	A	200.229.248.10
e.dns.br.		172800	IN	AAAA	2001:12f8:1::10
f.dns.br.		172800	IN	A	200.219.159.10

;; Query time: 259 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Apr  9 15:10:16 2012
;; MSG SIZE  rcvd: 296

Quando questionamos o RootServer sobre o host em questão, ele não o conhece, porém, conhece o final dele, o .br, e sabe quem é responsável pelo .br. Dessa maneira ele nos indica os hosts e IPs de todos os servidores autoritativos do Registro.br, que é a entidade responsável pelos domínios .br.

# dig @200.160.0.10 www.receita.fazenda.gov.br

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc16 <<>> 
 @200.160.0.10 www.receita.fazenda.gov.br
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18651 
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.receita.fazenda.gov.br.	IN	A

;; AUTHORITY SECTION: 
fazenda.gov.br.		86400	IN	NS	antares.serpro.gov.br.
fazenda.gov.br.		86400	IN	NS	trifid.serpro.gov.br.
fazenda.gov.br.		86400	IN	NS	andromeda.serpro.gov.br.
fazenda.gov.br.		86400	IN	NS	centauro.serpro.gov.br.
fazenda.gov.br.		86400	IN	NS	canisvenatici.serpro.gov.br.

;; ADDITIONAL SECTION:
antares.serpro.gov.br.	86400	IN	A	161.148.1.8
trifid.serpro.gov.br.	86400	IN	A	161.148.25.38
andromeda.serpro.gov.br. 86400	IN	A	200.198.205.242
centauro.serpro.gov.br.	86400	IN	A	161.148.1.17
canisvenatici.serpro.gov.br. 86400 IN	A	200.198.224.33
antares.serpro.gov.br.	86400	IN	AAAA	2804:150:0:200::11
trifid.serpro.gov.br.	86400	IN	AAAA	2804:150:0:1::17
centauro.serpro.gov.br.	86400	IN	AAAA	2804:150:0:200::12
canisvenatici.serpro.gov.br. 86400 IN	AAAA	2804:151:0:200::11

;; Query time: 142 msec
;; SERVER: 200.160.0.10#53(200.160.0.10)
;; WHEN: Mon Apr  9 15:15:17 2012
;; MSG SIZE  rcvd: 375

Quando fazemos a mesma requisição para um dos servidores de DNS autoritativos do registro.br, ele vai nos indicar quem são os servidores autoritativos do domínio fazenda.gov.br.

# dig @161.148.1.8 www.receita.fazenda.gov.br 

; <<> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc16 <<> @161.148.1.8 www.receita.fazenda.gov.br
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4811
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.receita.fazenda.gov.br.	IN	A

;; ANSWER SECTION:
www.receita.fazenda.gov.br. 21600 IN	A	161.148.231.100

;; AUTHORITY SECTION:
receita.fazenda.gov.br.	21600	IN	NS	centauro.serpro.gov.br.
receita.fazenda.gov.br.	21600	IN	NS	trifid.serpro.gov.br.
receita.fazenda.gov.br.	21600	IN	NS	andromeda.serpro.gov.br.
receita.fazenda.gov.br.	21600	IN	NS	canisvenatici.serpro.gov.br.
receita.fazenda.gov.br.	21600	IN	NS	antares.serpro.gov.br.

;; ADDITIONAL SECTION:
trifid.serpro.gov.br.	21600	IN	A	161.148.25.38
trifid.serpro.gov.br.	21600	IN	AAAA	2804:150:0:1::17
antares.serpro.gov.br.	21600	IN	A	161.148.1.8
antares.serpro.gov.br.	21600	IN	AAAA	2804:150:0:200::11
centauro.serpro.gov.br.	21600	IN	A	161.148.1.17
centauro.serpro.gov.br.	21600	IN	AAAA	2804:150:0:200::12
andromeda.serpro.gov.br. 21600	IN	A	200.198.205.242
canisvenatici.serpro.gov.br. 21600 IN	A	200.198.224.33
canisvenatici.serpro.gov.br. 21600 IN	AAAA	2804:151:0:200::11

;; Query time: 82 msec
;; SERVER: 161.148.1.8#53(161.148.1.8)
;; WHEN: Mon Apr  9 15:16:24 2012
;; MSG SIZE  rcvd: 377

Nessa terceira consulta, conseguimos finalmente descobrir o IP do host que estamos buscando, na linha:

;; ANSWER SECTION:
www.receita.fazenda.gov.br. 21600 IN	A	161.148.231.100

Assim o software que requisitou a resolução desse nome pode agora se conectar ao endereço IP correspondente a ele.

O arquivo resolv.conf
Nos sistemas GNU/Linux /etc/resolv.conf é o arquivo onde definimos regras importantes sobre as consultas de DNS, os seguintes parâmetros podem ser definidos:

nameserver <IP>
Endereço IP do servidor de DNS recursivo que o sistema deverá consultar para efetuar resolução de nomes. São permitidas múltiplas entradas desse parâmetro no arquivo de configuração. Quando isso ocorrer, o sistema irá consultá-los na ordem em que estão listados. Se essa entrada não estiver presente, o sistema tentará usar o próprio host como servidor recursivo.

domain <domínio local>
Quando uma parte do domínio local é definida aqui, as consultas podem ser feitas usando nomes relativos a esse domínio, por exemplo, se definirmos o seu valor como "ibm.com" e fizermos uma consulta ao host "mail", o sistema tentará resolver "mail.ibm.com". Caso esse parâmetro não esteja presente, o sistema detectará o domínio do host configurado no equipamento.

search <lista de domínios>
Por padrão, essa lista contém apenas o domínio local, mas ela pode conter uma lista de domínios que devem ser utilizados em busca de domínios que contiverem um número de pontos menor que o parâmetro ndots (valor padrão 1).

sortlist <lista de IPs e máscaras>
Define regras para a ordenação dos IPs retornados na resolução de um nome. Devem ser definidos classes de IP/máscara e assim, quando uma consulta retornar vários endereços, eles serão ordenados de acordo com a escolha.

options opção ...
Várias opções podem ser definidas aqui, como pode ser visto à seguir:

ndots:n
Define um limite para o número de pontos (.) que devem existir em um nome para que ele seja resolvido de maneira absoluta, sem adição dos itens contidos nos parâmetros domain e search. O valor padrão é 1, o que significa que se houver 1 ou mais pontos no nome, ele será tratado como um nome absoluto antes de quaisquer elementos da lista de busca (domain e search) serem anexados a ele.

timeout:n
Define por quanto tempo, em segundos, o sistema irá aguardar a resposta do servidor recursivo.

attempts:n
Define quantas tentativas serão feitas de resolver um nome antes de o sistema desistir e retornar uma mensagem de erro para a aplicação que solicitou a resolução de nome.

rotate
Habilita a opção de fazer um load balance entre os servidores definidos através do parâmetro nameserver. O protocolo round robin é usado nesse caso.

no-check-names
Desabilita a checagem dos caracteres não permitidos nos nomes de domínio, como o underscore (_), caracteres não ASCII ou caracteres de controle.

inet6
Faz com que o sistema busque primeiro um registro IPv6 (AAAA) e depois o registro IPv4 (A).

ip6-bytestring
Faz com que consultas de DNS reverso IPv6 usem o formato bit-label, definido na RFC 2673 ao invés de usar o formato nibble.

ip6-dotint/no-ip6-dotint
Quando a opção ip6-dotint está definida, o sistema irá resolver zonas reversas de IPv6 usando a zona ip6.int (Obsoleto). Quando no-ip6-dotint está definida (comportamento padrão), ele irá utilizar a zona ip6.arpa.

edns0
Habilita o suporte às extensões DNS definidas na RFC 2671.

Os Root Servers

Baseado no que foi dito no tópico anterior, a resolução de nomes precisa ter um ponto de partida, e é aí que entram os RootServers. Eles são os servidores que guardam as informações sobre os TLD (Top LevelDomains), e a partir deles a resolução de nomes é possível.

Existem 13 RootServers atualmente, que são mantidos por diversas entidades, como está descrito em http://www.root-servers.org/. Todo servidor DNS deve possuir em suas configurações os endereços IP de todos os RootServers.

Autoritativo x Recursivo

Um servidor DNS pode operar de duas maneiras distintas, em modo Autoritativo ou em modo Recursivo. Um mesmo servidor pode ser configurado para atuar como Autoritativo e recursivo ao mesmo tempo.

Um servidor DNS Autoritativo é aquele que responde por um determinado domínio, ou seja, ele sabe todos os dados sobre um ou mais domínios, e outros servidores usam-no para consultar esses dados quando necessário.

Um servidor DNS Recursivo é usado para consultar dados sobre outros domínios. É esse tipo de servidor que configuramos em nossas estações de trabalho para conseguirmos resolver os nomes dos hosts que usamos no dia a dia.

Master x Slave

Para evitar a duplicação de informações, um servidor DNS pode ser configurado para trabalhar em modo Slave. Nesse caso, o administrador não irá configurar os dados de uma zona direto no servidor DNS, ele apenas configura o cabeçalho dela e diz quem é o servidor Master. Então os dados da zona são transferidos e mantidos atualizados entre eles.

DNS Reverso

Além de converter nomes em endereços IP, muitas vezes precisamos fazer o contrário, descobrir qual é o nome de um determinado IP. Para isso utilizamos o DNS Reverso.
Como os endereços IP são delegados em blocos para empresas, o que muda são os últimos octetos do endereço, portanto, na hora de resolver o reverso, o IP é escrito de trás para frente.
Existe uma zona chamada in-addr.arpa que é o começo da resolução de um reverso, resolvido pelos RootServers.
Portanto, quando resolvemos o reverso do IP 161.148.231.100, o servidor DNS irá resolver um registro do tipo PTR para o endereço 100.231.148.161.in-addr.arpa.

Principais tipos de registros

O servidor DNS Autoritativo guarda os dados referentes aos domínios separados em diversos tipos de registros, cada qual para um uso específico. Iremos detalhar aqui os principais tipos de registro utilizados na atualidade:

SOA
É o registro que guarda o cabeçalho daquela Zona, disponibilizando dados importantes, seu formato é:

  • Name: O nome da zona (ex. ibm.com)
  • TTL: Time-To-Live
  • Class: Classe do registro, IN = Internet. Existem outras classes históricas HS (Hesiod) e CH (Chaos), que hoje em dia não são mais usadas
  • Name server: Indica o servidor DNS autoritativo daquela zona
  • Email: Indica o email do responsável por aquela zona. O símbolo de '@' é trocado por ponto '.'
  • SN (Serial Number): Número serial, usado por outros servidores DNS (secundários ou recursivos) para saberem que aquela zona foi alterada
  • Refresh: Indica de quanto em quanto tempo um servidor DNS Slave deverá atualizar os dados referentes àquela zona
  • Retry: Indica ao servidor DNS Slave de quanto em quanto tempo ele deverá tentar obter os dados daquela zona quando o Refresh falhar
  • Expiry: Indica quando o servidor DNS Slave não será mais considerado autoritativo daquela zona quando não for possível fazer o Refresh
  • Minimum / TTL: Define quanto tempo o registro dessa zona deverá permanecer no cache de um servidor DNS antes que seja feito um Refresh

A
Associa um hostname à um endereço IPv4.

AAAA
Associa um hostname à um endereço IPv6.

PTR
Associa um endereço IP a um hostname para a resolução de DNS reverso.

NS
Informa os IPs dos servidores DNS autoritativos de um domínio.

MX
Informa os IPs dos servidores SMTP de um domínio. Esse tipo de registro tem como particularidade um campo a mais, que informa a prioridade do servidor SMTP. Quanto mais baixo o valor, maior a prioridade.

CNAME
Usado para criarmos um alias de um host para outro, facilitando no caso de uma mudança de IP.

TXT
Pode armazenar qualquer informação em formato texto. Inicialmente criado para armazenar comentários ou informações sobre o domínio, hoje é muito usado por ferramentas anti-spam como o SPF (Sender Policy Framework) e o DomainKeys/DKIM.

Principais Softwares

Esses são alguns dos principais softwares (opensource ou comerciais) utilizados para se instalar e configurar um Servidor DNS:

  • BIND
  • NSD
  • djbdns
  • Unbound
  • Microsoft DNS
  • Dnsmasq
  • MaraDNS

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre
ArticleID=819128
ArticleTitle=O protocolo DNS
publish-date=06042012