Introdução às Redes e
Protocolos TCP/IP
Sessão nº7
Jorge Gomes
[email protected]
DNS
(Domain Name System)
Resolução de Nomes
• Os humanos são melhores com nomes do que
com números
– Memorizar e usar nomes de maquinas em vez de
endereços IP é mais fácil
– www.lip.pt  193.136.91.234
• Resolução de nomes:
– Através de ficheiros locais /etc/hosts
– Através de bases de dados locais (NIS / YP, NIS+)
– Através do DNS
/etc/hosts
• Simples de usar:
– Cada linha corresponde a um host
– Formato:
# Endereço-IP
nome-canonico
aliases
193.136.91.234
127.0.0.1
www.lip.pt
localhost.localdomain
www
localhost
• Não possui escalabilidade:
– Não podemos introduzir todos os sistemas da Internet
manualmente
– Não é eficiente copiar manualmente o ficheiro para todos os
sistemas após cada actualização
NIS
• O NIS é uma forma de distribuir informação de
configuração como o /etc/hosts
– É usado em redes locais
• Permite o acesso a um ficheiro de hosts centralizado
– Mas não podemos introduzir todos os sistemas da Internet
manualmente
– O NIS é relativamente complexo por servir diversos tipos de
informação e objectivos
Escolha
• Existindo diversas fontes para a informação:
– NIS, NIS+, /etc/hosts, DNS
• Como é que um host (cliente) escolhe a origem da
informação ?
–
–
–
–
–
Depende do sistema operativo e sua configuração
Por exemplo nem todos os sistemas suportam NIS
Alguns procuram sempre primeiro no hosts e depois no DNS
Outros só usam DNS
Em Linux existe o /etc/nsswitch.conf
/etc/nsswitch.conf
passwd:
shadow:
group:
files nisplus nis
files
files nisplus nis
#hosts:
hosts:
db files nisplus nis dns
files dns
#services:
nisplus [NOTFOUND=return] files
#networks:
nisplus [NOTFOUND=return] files
#protocols:
nisplus [NOTFOUND=return] files
#rpc:
nisplus [NOTFOUND=return] files
#ethers:
nisplus [NOTFOUND=return] files
#netmasks:
nisplus [NOTFOUND=return] files
# rpcbootparamd or local file
bootparams:
nisplus [NOTFOUND=return] files
ethers:
netmasks:
networks:
protocols:
rpc:
services:
netgroup:
publickey:
automount:
aliases:
files
files
files
files
files
files
nisplus
nisplus
files nisplus
files nisplus
DNS
• O DNS é uma base de dados distribuída que é usada
pelas aplicações TCP/IP para efectuar:
– O mapeamento de nomes em endereços IP.
– O mapeamento inverso de endereços IP em nomes.
– Encaminhamento de Email, etc
• O DNS é distribuído porque não existe nenhum sistema
na Internet que possua toda a informação.
– Os servidores de DNS são responsáveis por fornecer a
informação.
• Os servidores de DNS são mantidos por:
– organizações que possuam um domínio na Internet
– fornecedores de serviço IP
• Os servidores e clientes DNS não são implementados
no kernel dos sistema operativo.
– De facto a pilha de protocolo TCP/IP não sabe da existência do
DNS.
DNS
• Os servidores de DNS são implementados como
processos (bind / named).
• Os clientes de DNS são implementados como funções
de biblioteca (resolver):
– Com as quais a aplicação é compilada
• As duas funções do DNS mais usadas são:
– gethostbyname() : obtém o endereço IP a partir do nome.
– gethostbyaddr() : obtém o nome a partir de um endereço.
• Os dois RFCs relevantes para o DNS são:
– RFC 1034 define o conceito e funcionalidade.
– RFC 1035 especifica os detalhes de implementação.
• O esquema de nomes do DNS é hierárquico
– Similar à arvore de directórios de um sistema de ficheiros.
DNS
root
arpa
com
in-addr sun
193
www
edu
gov
mil
int
ripe
www
www www
Domínios genéricos
7
org
fnal
139
44
net
linux
pt
uk
...
tw
uc
co
com
dei
ibm
asus
ftp
www
www
Domínios nacionais
Country codes ISO 3166
Domínios
De topo
Domínios
de segundo
nível
DNS
• Cada nó da arvore possui uma etiqueta com até 63 caracteres.
– O nó de topo não possui nome.
– Não existe distinção entre nomes em maiúsculas e minúsculas.
• Cada nome completo lê-se de baixo para cima separando cada
nível por um ponto e terminando em ponto.
– Os nomes que não terminam em ponto têem de ser completados, o modo como
são completados dependo do software usado.
– Um nome que termina em ponto designa-se por “Fully Qualified Domain Name
(FQDN)”
• Os domínios de topo mil e gov são para uso dos militares e
governo dos Estados Unidos.
• A informação de topo da arvore de DNS é mantida num conjunto
de servidores conhecido por root name servers.
– Estes servidores mantêm informação sobre as delegações dos domínios de
topo
• A responsabilidade por outras zonas da arvore é delegada.
– Uma zona é uma sub-arvore da arvore de DNS que é administrada
separadamente.
DNS
• O DNS de topo é gerido pelo ICANN:
– Existem 13 servidores da root zone do DNS de A a M
– Mantém uma copia de http://www.internic.net/zones/root.zone
IPv4 address
IPv6 address
Location
Soft
A
198.41.0.4
B
192.228.79.201
C
192.33.4.12
2001:503:BA3E::2:30
VeriSign
2001:478:65::53 (not in
USC-ISI
root zone yet)
Cogent Communications
distributed using anycast
BIND
Marina Del Rey, California, U.S.
BIND
distributed using anycast
BIND
D
128.8.10.90
University of Maryland
College Park, Maryland, U.S.
BIND
E
192.203.230.10
NASA
Mountain View, California, U.S.
BIND
F
192.5.5.241
distributed using anycast
BIND
G
192.112.36.4
distributed using anycast
BIND
H
128.63.2.53
U.S. Army Research Lab
Aberdeen Proving Ground,
Maryland, U.S.
NSD
I
192.36.148.17
J
K
192.58.128.30
193.0.14.129
2001:7fe::53 (testing,
not in root zone yet)
2001:503:C27::2:30
2001:7fd::1
Autonomica
distributed using anycast
BIND
VeriSign
RIPE NCC
distributed using anycast
distributed using anycast
BIND
NSD
L
199.7.83.4
2001:500:3::42
ICANN
distributed using anycast
NSD
M
202.12.27.33
2001:dc3::35
WIDE Project
distributed using anycast
BIND
2001:500:2f::f
2001:500:1::803f:235
Operator
Internet Systems
Consortium
Defense Information
Systems Agency
DNS
• Os servidores de topo:
– Existe mais de um servidor por detrás de cada endereço IP
associado às letras A a M
– Algumas letras usam anycast
• Anycast e DNS:
– Permite replicação geográfica dos servidores
– Funciona anunciando o mesmo endereço IP via BGP a partir
de múltiplas localizações
– Na prática permite que em cada local seja escolhido o servidor
mais próximo
– Permite redundância
– Quando um servidor falha a sua rota é automaticamente
removida
– Outra rota mais distante passa a ser escolhida
DNS
• O ICANN controla também diversos domínios TLD
genéricos:
– O registo nestes domínios é delegado em registrars
• O registo em “.com” e “.net”:
– É operado pela Verisign sobre contrato com o ICANN
• O registo em “.edu”:
– É operado pelo net.educase.edu
– Organização sem fins lucrativos criada pela Internet Society
• Domínios nacionais são controlados por entidades
nacionais:
– O domínio (.pt) é controlado pela FCCN (www.dns.pt)
• Podem efectuar-se registos através:
– Agentes de registo (Registrars)
(http://www.internic.net/alpha.html)
– Companhias de web hosting
– Pagam-se fees anuais
DNS
• Muitos domínios de segundo nível subdividem o seu domínio em
mais sub-domínios de acordo:
– com a sua estrutura administrativa
– ou distribuição geográfica.
• Uma vez que a delegação de uma zona (domínio) tenha sido
efectuada é da responsabilidade da organização à qual a
delegação foi efectuada:
– Disponibilizar a informação sobre essa zona através da implementação de
servidores de DNS.
– Cada vez que um novo sistema é adicionado a uma zona o administrador da
rede deve introduzir no servidor DNS correspondente o nome e endereço IP
do novo sistema.
• Cada zona tem de possuir um servidor de DNS primário e um ou
mais servidores de DNS secundários:
– Servidor de DNS primário: obtém a sua informação a partir de ficheiros em
disco.
– Servidor de DNS secundário: obtém a sua informação a partir de informação
copiada do servidor de DNS primário.
DNS
• Os servidores secundários existem para garantir a
disponibilidade da informação sobre uma zona em
caso de falha do servidor primário.
– A transferência de informação sobre uma zona entre um
servidor primário e um servidor secundário chama-se
transferência de zona.
• As transferências de zona são sempre efectuadas
pelos servidores secundários e ocorrem quando:
– Um servidor de DNS primário lê os ficheiros de configuração
em disco e detecta com base no numero de série da zona que
ocorreu uma actualização. Neste caso o primário envia uma
notificação aos servidores secundários.
– Quando os servidores secundários determinam que houve
uma actualização do primário através de uma verificação
periódica do numero de série da zona.
– A informação mantida nos servidores secundários é valida
durante um período limitado de tempo, após o qual uma nova
transferência de zona tem de ser obrigatoriamente efectuada.
DNS
• Quando um servidor que suporta recursão recebe um pedido de
informação para uma zona sobre a qual não possui informação
– É desencadeado um processo iterativo de tradução.
• Cada servidor conhece os endereços IP de um ou vários
servidores de DNS responsáveis pela root:
– Informação sobre os root servers não muda frequentemente
– Desta forma é possível obter informação sobre os endereços IP dos
servidores responsáveis pelos domínios de topo.
– Contactando o servidor de topo pode-se obter informação sobre os
servidores responsáveis pelos domínios de segundo nível
– O processo continua iterativamente até encontrar o servidor
responsável pela zona que contém a informação que se pretende
obter, que é então questionado directamente.
• Para melhorar o desempenho do DNS cada servidor mantém uma
cache com a informação que obteve durante o seu
funcionamento.
– Cada informação em cache possui um tempo de vida ao fim do qual
expira
Formato de Mensagem DNS
Identificação
(16)
Flags
(16)
Número de questões
(16)
Número de RRs de resposta
(16)
Número de RRs autoritários
(16)
Número de RRs adicionais
(16)
Questões
RRs com respostas
(Número variável de RRs)
RRs autoritários
(Número variável)
RRs com informação adicional
(Número variável)
O Campo Flags
• O campo de flags divide-se em:
QR
(1)
–
–
–
–
opcode
(4)
AA
(1)
TC
(1)
RD
(1)
RA
(1)
zero
(3)
rcode
(4)
QR: 0 a mensagem é uma questão, 1 a mensagem é uma resposta.
AA: 1 o servidor que está a responder é autoritária para a zona.
TC: 1 mensagem truncada a 512 bytes (só usado com UDP).
RD: 1 quando usado numa query indica que se pretende que o
servidor use recursividade para responder à query. 0 numa query
indica que se o servidor não for autoritário para a zona deve apenas
retornar uma lista de servidores que o sejam.
• Um servidor root nunca aceita queries recursivas
• Cada vez mais servidores também possuem esta politica.
• Devem ser os servidores locais a efectuar a recursividade
– RA: É usado nas respostas para indicar que o servidor suporta
recursividade.
– RCODE: 0 OK, 3 erro.
O Campo Questões
• O campo de questões divide-se em:
Nome a traduzir
Tipo de questão
(16)
Classe da questão ( 1 = IP)
(16)
– Nome a traduzir: sequência de etiquetas que são precedidas por um
byte com o numero de caracteres de cada etiqueta e terminando com
um byte com valor zero.
ns.dns.pt.
2
n
s
3
d
n
s
2
p
t
– Tipo de questão: o tipo de questão indica o tipo informação (RR) que
se pretende obter:
Nome
A
NS
CNAME
PTR
HINFO
MX
AXFR
ANY
Valor
1
2
5
12
13
15
252
255
Descrição da informação a obter
Endereço IP
Name server responsável por um domínio
Nome canónico, um nome virtual que aponta para o nome real
Nome a partir de endereço (Pointer)
Informação sobre o host, duas strings com CPU e sist. operativo
Nome e prioridade do servidor de email para um host / domínio
Pedido de transferência de zona
Obtenção de todos os registos
0
Formato das respostas DNS
Nome do domínio
Tipo de RR
(16)
Classe
(16)
Tempo de vida
(32)
Tamanho dos dados
(16)
Dados
– Nome do domínio: nome ao qual os dados (RR) corresponde.
– Tipo: especifica um dos tipos de RR tal como nas questões.
– Tempo de vida: número de segundos que um cliente DNS pode
manter esta informação em cache (2 dias é um valor usual).
– Tamanho dos dados: Número de bytes do campo de dados.
– Dados: resposta depende do tipo de RR. Para um endereço IP
são quatro bytes. Para nomes é usado o formato mencionado
anteriormente.
Exemplo com um Cliente
• Pretende-se fazer ssh para uma maquina usando o seu nome:
– É usada a função gethostbyname para obter o endereço IP do
sistema.
– O cliente de DNS determina o endereço IP do servidor de DNS a usar
com base em informação de configuração existente em
armazenamento local.
• Podem existir vários servidores configurados para redundância.
– Envia uma query para o servidor de DNS usando UDP.
– A query usa:
•
•
•
•
O bit RD a 1 (deseja-se recursividade)
O bit QR a 0 (é uma questão)
Classe 1 (questão sobre IP)
Tipo 1 (pretende-se obter um RR do tipo A endereço IP)
– O servidor verifica se possui informação sobre a zona
correspondente ao nome que se pretende traduzir:
•
•
•
•
Pode existir em cache ou numa zona localmente suportada
Caso afirmativo responde imediatamente ao cliente usando UDP.
Se for primário para a zona a resposta terá o bit de autoritário a 1.
Caso contrario contactará outros servidores para obter a informação.
Mapeamento Reverso
• É possível obter o nome correspondente a um endereço IP
através da função gethostbyaddr()
• Para este efeito existe o domínio in-addr.arpa.
• As varias “classes” de endereços IP atribuídas podem ser
registadas como sub-domínios debaixo deste domínio.
• Para efectuar o mapeamento inverso da rede 193.139.77.0 / 24 é
necessária a delegação do domínio 77.139.193.in-addr.arpa a um
servidor de DNS.
• O servidor deve usar registos PTR para efectuar o mapeamento
entre os endereços IP e o nome correspondente.
• O mapeamento reverso é frequentemente usado pelos servidores
(por ex. o SSH) para verificar que os clientes têm origem em
domínios de confiança
• Um cliente que não tenha um mapeamento reverso é
frequentemente considerado suspeito
Exemplo com um Servidor
• Um servidor de DNS local recebe uma questão:
– pedido com recursividade
– obtenção de um endereço IP referente a uma zona que não é
local(www.cern.ch).
• Resolução:
– O servidor local usa a sua lista de root name servers para seleccionar
um servidor que será interrogado para determinar os endereços IP
dos servidores de DNS responsáveis por “ch”.
– O servidor root responde com registos autoritários para os nomes
dos servidores de DNS de “ch” e informação adicional com os
endereços IP destes servidores.
– O servidor local questiona um dos servidores de DNS de “ch” para
obter os endereços IP dos servidores responsáveis pelo domínio
“cern.ch”.
– O servidor “ch” responde com registos autoritários para os nomes
dos servidores de DNS de “cern.ch” e informação adicional com os
seus endereços IP.
– Finalmente um servidor de DNS de “cern.ch” é interrogado para obter
o endereço IP de “www.cern.ch”.
– O servidor de “cern.ch” responde com o endereço IP ou com a
indicação de que o RR não existe.
DNS
• Em sistemas “*NIX” a configuração do cliente de DNS é efectuada
no ficheiro /etc/resolv.conf
search lip.pt
nameserver 10.226.1.1
nameserver 10.226.1.2
• Atenção alguns utilitários de configuração podem reescrever o
/etc/resolv.conf
• Em RH se o NetworkManager estiver activo a configuração do
DNS poderá ser reescrita
• A configuração faz-se também através dos scripts
/etc/sysconfig/network-scripts/ifcfg-ethX
DOMAIN=lip.pt
DNS1=10.226.1.1
DNS2=10.226.1.2
DNS
• Em sistemas “*NIX” o ficheiro de configuração do
servidor de DNS chama-se /etc/named.conf
• Um servidor de DNS responde a queries na porta 53
• Um servidor de DNS efectua queries:
– Inicialmente a porta 53 era usada
– A partir de uma qualquer porta pré-definida pelo sysadm
– Usando portas alocadas dinamicamente (mais difícil de passar nas
firewalls)
acl ns { 192.178.4.3; };
acl my-net { 192.137.86.0/24; };
options {
directory “/etc/namedb”;
query-source address * port 5678;
recursion yes;
allow-transfer { ns; my-net; };
allow-recursion { my-net; };
};
zone “.” {
type hint;
file “named.root”;
};
zone “blabla.net” {
type master;
file “master/blabla.net”;
};
zone “86.137.192.in-addr.arpa” {
type master;
file “master/192.137.86”;
};
;
; Ficheiro de configuração para a zona blabla.net
;
$TTL 86400
@
IN
SOA
2010030901
28800
7200
604800
86400 )
dns1.blabla.net. sysadm.blabla.net. (
; Serial number yymmddss, xx zone change
; Refresh 4 hours
; Retry 2 hours
; Expire 7 days
; minimum time-to-live 1 day
IN
IN
NS
NS
dns1.blabla.net.
dns2.blabla.net.
IN
IN
MX
MX
10
20
frog
frog
dns1.frog
dns2.frog
IN
IN
IN
IN
NS
NS
A
A
dns1.frog.blabla.net.
dns2.frog.blabla.net.
192.178.231.2
192.178.234.7
alfa
beta
delta
mail1
mail2
dns1
dns2
IN
IN
IN
IN
IN
IN
IN
A
A
A
A
CNAME
A
A
192.137.86.56
192.137.86.92
193.116.2.82
192.137.86.12
alfa.blabla.net.
192.137.86.14
123.81.11.5
mail1.blabla.net.
mail2.blabla.net.
;
; Ficheiro de configuração para a zona 86.137.192.in-addr.arpa
;
$TTL 86400
@
IN
SOA
2010030901
28800
7200
604800
86400 )
dns1.blabla.net. sysadm.blabla.net. (
; Serial number yymmddss, xx zone change
; Refresh 4 hours
; Retry 2 hours
; Expire 7 days
; minimum time-to-live 1 day
IN
IN
NS
NS
dns1.blabla.net.
dns2.blabla.net.
12
14
IN
IN
PTR
PTR
mail1.blabla.net.
dns1.blabla.net.
56
92
IN
IN
PTR
PTR
alfa.blabla.net.
beta.blabla.net.
UDP e TCP
• O DNS suporta UDP e TCP:
– Ambos os protocolos usam o mesmo numero de porta (53).
• Por norma é usado UDP:
– Quando uma resposta é recebida com o bit TC a 1 indicando
que a mensagem foi truncada a 512 bytes, então o TCP é
usado para efectuar a transferência.
• As transferências de zona entre servidores primários e
secundários são sempre efectuadas usando TCP:
– Para garantir maior fiabilidade.
– Por existir probabilidade elevada da transferência precisar
mais de 512 bytes.
Exemplos
• Traduzir via DNS o nome de um host
$ host lnlip01.lip.pt
lnlip01.lip.pt has address 10.1.1.101
$ host www.cern.ch
www.cern.ch is an alias for webr4.cern.ch.
webr4.cern.ch has address 137.138.137.177
• Traduzir via DNS o endereço de um host
$ host 10.1.1.101
101.1.1.10.in-addr.arpa domain name pointer lnlip01.lip.pt.
$ host 137.138.137.177
177.137.138.137.in-addr.arpa domain name pointer webr4.cern.ch.
Exemplos
• Obter via DNS o nome dos servidores de mail para um domínio:
$ host -t MX cern.ch
cern.ch mail is handled by 10 cernmxgwlb.cern.ch.
$ host -t MX fct.mctes.pt
fct.mctes.pt mail is handled by 5 anubis.fct.mctes.pt.
$ host -t MX lip.pt
lip.pt mail is handled by 10 smtp.lip.pt.
• Obter os servidores de DNS para um domínio:
$ host -t NS lip.pt
lip.pt name server ns02.lip.pt.
lip.pt name server ns01.lip.pt.
Exemplos
$ host –vT www.cern.ch
Trying "www.cern.ch"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5145
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6
;; QUESTION SECTION:
;www.cern.ch.
IN
A
;; ANSWER SECTION:
www.cern.ch.
9235 IN
webr4.cern.ch.
9235 IN
;; AUTHORITY SECTION:
cern.ch.
555 IN
cern.ch.
555 IN
cern.ch.
555 IN
NS
NS
NS
CNAME webr4.cern.ch.
A
137.138.137.177
scsnms.switch.ch.
ext-dns-1.cern.ch.
ext-dns-2.cern.ch.
;; ADDITIONAL SECTION:
scsnms.switch.ch.
53873 IN A
130.59.1.30
scsnms.switch.ch.
53873 IN A
130.59.10.30
scsnms.switch.ch.
53873 IN AAAA 2001:620::1
ext-dns-1.cern.ch.
3146 IN
A
192.65.187.5
ext-dns-2.cern.ch.
10101 IN
A
192.91.245.85
ext-dns-2.cern.ch.
10101 IN
AAAA 2001:1458:e008:1::2
Received 261 bytes from 10.226.1.1#53 in 0 ms
Exemplos
$ dig +trace +tcp www.lip.pt
; <<>> DiG 9.2.4 <<>> +trace +tcp www.lip.pt
;; global options: printcmd
.
234746 IN
NS C.ROOT-SERVERS.NET.
.
234746 IN
NS D.ROOT-SERVERS.NET.
.
234746 IN
NS E.ROOT-SERVERS.NET.
.
234746 IN
NS F.ROOT-SERVERS.NET.
.
234746 IN
NS G.ROOT-SERVERS.NET.
.
234746 IN
NS H.ROOT-SERVERS.NET.
.
234746 IN
NS I.ROOT-SERVERS.NET.
.
234746 IN
NS J.ROOT-SERVERS.NET.
.
234746 IN
NS K.ROOT-SERVERS.NET.
.
234746 IN
NS L.ROOT-SERVERS.NET.
.
234746 IN
NS M.ROOT-SERVERS.NET.
.
234746 IN
NS A.ROOT-SERVERS.NET.
.
234746 IN
NS B.ROOT-SERVERS.NET.
;; Received 508 bytes from 10.226.1.1#53(10.226.1.1) in 1 ms
pt.
172800 IN NS NS.DNS.BR.
pt.
172800 IN NS
NS.DNS.pt.
pt.
172800 IN NS AUTH200.NS.UU.NET.
pt.
172800 IN NS NS2.NIC.FR.
pt.
172800 IN NS NS-EXT.ISC.ORG.
pt.
172800 IN NS AUTH210.NS.UU.NET.
pt.
172800 IN NS NS2.DNS.pt.
;; Received 363 bytes from 192.33.4.12#53(C.ROOTSERVERS.NET) in 24 ms
lip.pt.
28800 IN
NS ns02.fccn.pt.
lip.pt.
28800 IN
NS lnnet02.lip.pt.
lip.pt.
28800 IN
NS afnet01.lip.pt.
;; Received 215 bytes from 200.160.0.5#53(NS.DNS.BR) in
235 ms
www.lip.pt.
86400 IN CNAME lnnet08.lip.pt.
lnnet08.lip.pt.
86400 IN
A
193.136.91.234
lip.pt.
86400 IN
NS afnet01.lip.pt.
lip.pt.
86400 IN
NS ns02.fccn.pt.
lip.pt.
86400 IN
NS lnnet02.lip.pt.
;; Received 210 bytes from
193.136.2.228#53(ns02.fccn.pt) in 5 ms