Faculdade de Tecnologia SENAC Pelotas/RS
Curso Superior de Tecnologia em Redes de Computadores
Redes de Computadores III
DNS (Domain Naming System)
Professor Eduardo Maroñas Monks
SUMÁRIO
•
•
•
•
•
•
•
•
Histórico
Objetivos
Componentes
Funcionalidades
Protocolo
Aplicações
Segurança
Referências Bibliográficas
Prof. Eduardo M. Monks - Redes de Computadores III
2
Histórico
• No início da ARPANET, começou a ser necessária uma
forma mais fácil de encontrar os hosts do que endereços
numéricos
• Foi criado um arquivo com o nome de HOSTS.TXT que
continha o mapeamento entre endereços e nomes
• Este arquivo era mantido pelo SRI’s NIC (StanfordResearch-Institute: Network-Information-Center)
• Os administradores enviavam as mudanças de
endereços e nomes para o SRI NIC
• O SRI NIC atualiza periodicamente o arquivo
HOSTS.TXT
• Os administradores de rede faziam o download por
FTP do arquivo HOSTS.TXT
Prof. Eduardo M. Monks - Redes de Computadores III
3
Histórico
• Com o aumento no número de hosts, o arquivos
HOSTS.TXT começou a apresentas problemas:
• Escalabilidade (tráfego e carga no repositório)
• Colisões de nomes
• Inconsistência do arquivo
• Em 1984, Paul Mockapetris disponibilizou as primeiras
RFCs (882 e 883) do DNS
• As RFCs 1034 e 1035 foram as sucessoras e as
melhorias continuam…
• A motivação inicial foi a organização do serviço de email
• Dificuldade para encontrar a caixa postal a qual
entregar o e-mail
• O primeiro domínio no DNS foi isi.edu (Information
Sciences Institute)
Entrevista com Paul Mockapetris http://www.youtube.com/watch?v=VLahF1zwAog
Prof. Eduardo M. Monks - Redes de Computadores III
4
Objetivos
• DNS (Domain Name System)
• Sistema de gerenciamento de nomes hierárquico e
distribuído
• Protocolo de camada de aplicação
• Baseado em cliente/servidor
• Cliente solicita ao servidor de nomes a resolução
de nome para endereço
• Complexidade na “borda” da rede
• Funcionalidades
• Nomes canônicos e alias (apelidos)
• Definição de servidor de e-mail por domínio
• Distribuição de carga (WWW, DNS)
Prof. Eduardo M. Monks - Redes de Computadores III
5
Componentes
• Servidores Raiz
• São contatados pelos servidores de nomes locais que
não podem resolver um nome
• Servidores de nomes raiz:
• Buscam servidores de nomes autorizados se o
mapeamento do nome não for conhecido
• Conseguem o mapeamento
• Retornam o mapeamento para o servidor de nomes
local
Haviam 13
servidores de
nomes raiz no
mundo, mas
devido a ataques
de DDOS…
Prof. Eduardo M. Monks - Redes de Computadores III
6
Componentes
• Servidores top-level domain (TLD):
• Responsáveis pelos domínios com, org, net, edu etc. e
todos os domínios top-level nacionais (ccTLD –
Country Code TLD): br, ar, uk, fr, ca, jp...
• Network Solutions mantém servidores para o TLD
“com” TLD
• Educause para o TLD “edu”
• No Brasil, é Comitê Gestor da Internet no Brasil, a
parte operacional é no Registro.br
Lista de(http://registro.br)
TLDs no Brasil • http://registro.br/dominio/dpn.html
Servidores DNS autorizados
• Servidores
DNS de organizações, provêem
ccTLD
(IANA) - http://www.iana.org/domains/root/db/
mapeamento de nomes para endereços de forma
autorizada no domínio da organização (ex.: Web e
mail).
• Podem ser mantidos por uma organização ou
provedor de serviços
Prof. Eduardo M. Monks - Redes de Computadores III
7
Componentes
• Servidor de nomes local
• Não pertence estritamente a uma hierarquia
• Cada ISP (ISP residencial, companhia, universidade)
possui um
• Também chamado de “servidor de nomes default”
• Quando um host faz uma pergunta a um DNS, a
pergunta é enviada para seu servidor DNS local
• Funciona como um proxy, encaminhando as perguntas
para dentro da hierarquia de servidores
Prof. Eduardo M. Monks - Redes de Computadores III
8
Funcionalidades
• Cliente quer o IP do domínio www.amazon.com:
• Cliente consulta o servidor local de DNS; Se estiver no
cache responde localmente;
• Caso contrário, o Cliente ou o Servidor local,
consulta os servidores raiz para encontrar o
servidor DNS responsável pelos domínios .com
• Cliente ou Servidor Local consulta o servidor DNS
.com para obter o servidor de DNS autoritário para
amazon.com
• Cliente ou Servidor Local consulta o servidor de DNS
amazon.com para obter o endereço IP de
www.amazon.com
• Cliente e Servidor Local armazenam em cache o
resultado da consulta
Prof. Eduardo M. Monks - Redes de Computadores III
9
Funcionalidades
• O hospedeiro em
cis.poly.edu quer o
endereço IP para
gaia.cs.umass.edu
Prof. Eduardo M. Monks - Redes de Computadores III
10
Funcionalidades
• Consulta recursiva:
• Transfere a tarefa
de resolução do
nome para o
servidor de nomes
consultado
• Carga pesada?
• Consulta encadeada:
• Servidor contatado
responde com o
nome de outro
servidor de nomes
para contato
• “Eu não sei isto,
mas pergunte a
este servidor”
Prof. Eduardo M. Monks - Redes de Computadores III
11
Funcionalidades
• Cache
• Uma vez que um servidor de nomes apreende um
mapeamento, ele armazena o mapeamento num
registro do tipo cache
• Registros do cache tornam-se obsoletos
(desaparecem) depois de um certo tempo
• Servidores TLD são tipicamente armazenados em
cache nos servidores de nome locais
• Mecanismos de atualização e notificação estão
sendo projetados pelo IETF
• RFC 2136
• http://www.ietf.org/html.charters/dnsindcharter.html
Prof. Eduardo M. Monks - Redes de Computadores III
12
Funcionalidades
• Tipos de registros
• base de dados distribuída que armazena registros de
recursos (RR)
• formato dos RR: (name, value, type, ttl)
 Type = A
 name é o nome do
computador
 value é o endereço IP
 Type = NS
 name é um domínio (ex.:
foo.com)
 value é o endereço IP
do servidor de nomes
autorizados para este
domínio
Prof. Eduardo M. Monks - Redes de Computadores III
 Type = CNAME
 name é um “apelido” para
algum nome “canônico” (o
nome real)
www.ibm.com é realmente
servereast.backup2.ibm.com
 value é o nome canônico
 Type = MX
 value é o nome do
servidor de correio
associado com name
13
Protocolo
• Protocolo DNS: mensagem de consulta e resposta,
ambas com o mesmo formato de mensagem
• Cabeçalho da mensagem
• Identificação: número de 16 bits para consulta,
resposta usa o mesmo número
• Flags:
• Consulta ou resposta
• Recursão desejada
• Recursão disponível
• Resposta é autorizada
Prof. Eduardo M. Monks - Redes de Computadores III
14
Protocolo
• Exemplo: empresa recém-criada “Network Utopia”
• Registrar o nome networkutopia.com num “registrar”
(ex.: Network Solutions)
• É necessário fornecer ao registrar os nomes e
endereços IP do seu servidor nomes autorizados
(primário e secundário)
• Registrar insere dois RRs no servidor TLD do domínio
com:
• (networkutopia.com, dns1.networkutopia.com, NS)
• (dns1.networkutopia.com, 212.212.212.1, A)
• No servidor autorizado, inserir um registro Tipo A para
www.networkutopia.com e um registro Tipo MX para
networkutopia.com
Prof. Eduardo M. Monks - Redes de Computadores III
15
Protocolo
• Programa do usuário solicita endereço IP para um nome
de domínio;
• Módulo tradutor (resolver) no host ou ISP local formula
consulta para servidor de nomes local (mesmo domínio
do tradutor);
• Servidor de nomes local verifica banco de dados/cache
local;
• se encontrado, retorna endereço IP ao solicitante;
• se não encontrado, consulta outros servidores de
nomes disponíveis, começando pela raiz da árvore do
DNS ou o mais alto possível na árvore;
• Quando a resposta é recebida, o servidor de nomes local
armazena o mapeamento nome/endereço no cache local;
• Programa do usuário recebe endereço IP ou mensagem
de erro.
Prof. Eduardo M. Monks - Redes de Computadores III
16
Protocolo
• Consulta começa com tradutor de nomes localizado no
sistema host do usuário
• Se o nome solicitado não estiver no cache, é enviada
uma consulta ao servidor de DNS local
• retorna um endereço imediatamente, ou
• retorna endereço após consultar outros servidores
• Dois tipos de consultas possíveis
• Recursiva
• Iterativa
Prof. Eduardo M. Monks - Redes de Computadores III
17
Protocolo
• Busca recursiva para obter a resolução do nome
gaia.cs.umass.edu
Servidor de Nome Raiz
3
2
5
4
Servidor de nomes
autoritário (Authoritative)
dns.umass.edu
Servidor de
nomes local
dns.eurocom.fr
1
6
gaia.cs.umass.edu
Host requisitante
surf.eurecom.fr
Prof. Eduardo M. Monks - Redes de Computadores III
18
Protocolo
• Busca recursiva com um servidor intermediário entre o
servidor raiz e o servidor autoritário
Servidor de Nome Raiz
3
2
7
Servidor de nomes
intermediário
dns.umass.edu
6
5
Servidor de
nomes local
dns.eurocom.fr
1
4
Servidor de nomes
autoritário (Authoritative)
dns.umass.edu
8
Gaia.cs.umass.edu
Host requisitante
surf.eurecom.fr
Prof. Eduardo M. Monks - Redes de Computadores III
19
Protocolo
• Busca recursiva com um servidor intermediário entre o
servidor raiz e o servidor autoritário
Servidor de Nome Raiz
3
2
7
Servidor de nomes
intermediário
dns.umass.edu
6
5
Servidor de
nomes local
dns.eurocom.fr
1
4
Servidor de nomes
autoritário (Authoritative)
dns.umass.edu
8
Gaia.cs.umass.edu
Host requisitante
surf.eurecom.fr
Prof. Eduardo M. Monks - Redes de Computadores III
20
Aplicações
•
•
•
•
•
Clientes e servidores de DNS existem para a maioria dos
sistemas operacionais.
Nos sistemas operacionais, existe, pelo menos, um cliente
(resolver) nativo
No Linux, a implementação mais comum é o ISC BIND
para servidor
No Windows, o MS DNS Server é o mais utilizado
Atualmente, todos os modens/roteadores ADSL possuem
uma implementação de servidor DNS para cache (DNS
Relay)
Exemplo de configuração
do ISC BIND
Prof. Eduardo M. Monks - Redes de Computadores III
21
Aplicações
• Cliente DNS (resolver)
• Responsável por solicitar as consultas ao
servidor
• No Microsoft Windows e no Linux, o utilitário
nslookup possui funcionalidades para
diagnóstico do serviço de DNS
• No Linux, o utilitário dig substituiu o
nslookup na distribuições mais recentes
Prof. Eduardo M. Monks - Redes de Computadores III
22
Segurança
• Problemas de segurança mais comuns ao serviço de
DNS :
• Ataques de negação de serviço (DOS – Denial of
Service)
• Clientes ficam impossibilitados de resolver
nomes
• Se o usuário souber o IP do host destino, poderá
acessar sem problemas. Você sabe o IP do Terra
de cabeça?
• Envenenamento de DNS
•
Enganar o cache do DNS e forçar a resolução de
nomes para um IP malicioso
• Os usuários poderiam ser direcionados para qualquer
endereço que o atacante desejasse, mesmo buscando
de forma correta o domínio
• Conhecida como Kaminsky Vulnerabilty
(http://unixwiz.net/techtips/iguide-kaminsky-dnsvuln.html)
Prof. Eduardo M. Monks - Redes de Computadores III
23
Referências Bibliográficas
•
•
•
•
•
•
•
•
•
•
RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES
RFC 1035 – DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION
Serviço WHOIS da ARIN - http://whois.arin.net/ui/
Serviço WHOIS da RIPE - http://www.ripe.net/db/whois.html
Serviço WHOIS da APNIC - http://www.apnic.net/apnicinfo/whois_search2
Arquivos HOSTS.TXT antigos - http://pdp-10.trailing-edge.com/bbev83b-bm/01/new-system/hosts.txt.html
Servidores Raiz (IANA) http://www.iana.org/domains/root/db/index.html
Informações e localização dos servidores raiz - http://www.rootservers.org/
Os cinco piores incidentes de segurança no serviço DNS http://www.securityweek.com/top-five-worst-dns-securityincidents
ALBITZ, Paul; LIU, Cricket. DNS and BIND. 4th edition, O’Reilly,
2001.
Prof. Eduardo M. Monks - Redes de Computadores III
24