Licenciatura de Engenharia Informtica

Segurana Informtica
3.Ano, 2.Semestre
2014/2015
Relatrio do Trabalho

Tecnologia DNSSEC

Elementos do Grupo:
Eduardo Barata

n 62009028

Joo Barata

n 20130554

Docente:
Osvaldo Santos

Contedo
ndice de Ilustraes ........................................................................................................................... 3
Introduo .............................................................................................................................................. 4
DNS ( Domain name System) .......................................................................................................... 5
Exemplo de um pedido dns ......................................................................................................... 8
Vulnerabilidade DNS Spoofing........................................................................................................ 9
Breve Histria do DNSSEC..............................................................................................................10
O que o DNSSEC?.............................................................................................................................11
O Funcionamento do DNSSEC .......................................................................................................12
A arquitetura DNSSEC ......................................................................................................................15
Formato DNSKEY ..........................................................................................................................15
Exemplo de DNSKEY ...............................................................................................................16
Formato RRSIG ...............................................................................................................................17
Exemplo RRSIG ..........................................................................................................................18
Formato NSEC3 ..............................................................................................................................18
Formato DS ......................................................................................................................................19
Exemplo DS .................................................................................................................................19
Concluso ..............................................................................................................................................20
Bibliografia ...........................................................................................................................................21

ndice de Ilustraes
Ilustrao 1- Hieraquia DNS [2] ..................................................................................................... 5
Ilustrao 2- Localizao dos Root Name Servers [3] ........................................................... 7
Ilustrao 3- Nome e Responsveis e IP dos Root Name Servers [4] .............................. 7
Ilustrao 4 - Pedido DNS [5] .......................................................................................................... 8
Ilustrao 5 DNS Spoofing [7] ......................................................................................................... 9
Ilustrao 6 Cadeia de autenticao [13] .................................................................................13

Introduo
Este trabalho pretende fazer uma breve introduo ao DNS e aos seus problemas,
tentando evidenciar a necessidade de uma nova alternativa.
Essa alternativa o DNSSEC o qual vamos explorar melhor o seu modo de
funcionamento a sua histria e a sua arquitetura.

DNS ( Domain name System)

Consiste numa base de dados distribuda utilizada para mapeamento entre nomes
de mquinas (hostnames) e endereos IP.
Os nomes so traduzidos em endereos IP atravs da consulta a servidores de
nomes, responsveis por domnios bem definidos.
O espao de nomes do DNS organizado de forma hierrquica numa estrutura em
rvore. Existe um domnio de raiz, ao qual se sucedem domnios de topo, que por
sua vez, contm subdomnios e assim sucessivamente. A responsabilidade de cada
domnio/subdomnio pode ser delegada a outra organizao. [1]

Ilustrao 1- Hieraquia DNS [2]

O servidor de nomes de um dado domnio conhece o mapeamento entre nomes e

endereos IP de todas as mquinas existentes nesse domnio e dos servidores de
nomes dos seus subdomnios imediatos.
Existem trs tipos diferentes de domnios de topo:

Domnios Genricos ou Organizacionais, identificados por trs caracteres

Domnios Geogrficos ou de Pases, identificados por dois caracteres
Domnios ARPA, domnio especial para mapeamento inverso

Cada domnio repartido em zonas, sendo que cada zona uma parte de um
domnio que est registada num ficheiro da base de dados DNS (zone file). Esta
diviso permite dividir a informao em diversos ficheiros e por diversos
computadores, evitando a sobrecarga de uma mquina.
Um servidor pode administrar uma ou mais zonas sendo que deve existir um
servidor de nomes primrio e um secundrio para cada zona. [1]
Servidores Primrios:
-So aqueles onde os domnios e registos so configurados.
- Conhecem os servidores secundrios e enviam-lhes as atualizaes das
suas tabelas periodicamente.
Servidores Secundrios:
-Funcionam como backup e distribuidores de carga de um servidor
primrio.
Root Name Server:
-Servidor do mais alto nvel hierrquico da rvore de DNS
-Contm o mapeamento para os servidores dns primrios dos domnios de
topo.
-Existem apenas 13 Root Name Servers [1]

Ilustrao 2- Localizao dos Root Name Servers [3]

Hostname
a.root-servers.net
b.root-servers.net
c.root-servers.net
d.root-servers.net
e.root-servers.net
f.root-servers.net
g.root-servers.net
h.root-servers.net
i.root-servers.net
j.root-servers.net
k.root-servers.net
l.root-servers.net
m.root-servers.net

IP Addresses
198.41.0.4, 2001:503:ba3e::2:30
192.228.79.201, 2001:500:84::b
192.33.4.12, 2001:500:2::c
199.7.91.13, 2001:500:2d::d
192.203.230.10
192.5.5.241, 2001:500:2f::f
192.112.36.4
128.63.2.53, 2001:500:1::803f:235
192.36.148.17, 2001:7fe::53
192.58.128.30, 2001:503:c27::2:30
193.0.14.129, 2001:7fd::1
199.7.83.42, 2001:500:3::42
202.12.27.33, 2001:dc3::35

Ilustrao 3- Nome e Responsveis e IP dos Root Name Servers [4]

Manager
VeriSign, Inc.
University of Southern California (ISI)
Cogent Communications
University of Maryland
NASA (Ames Research Center)
Internet Systems Consortium, Inc.
US Department of Defence (NIC)
US Army (Research Lab)
Netnod
VeriSign, Inc.
RIPE NCC
ICANN
WIDE Project

Exemplo de um pedido dns

Ilustrao 4 - Pedido DNS [5]

Quando um utilizador do pc 1 faz uma pesquiza por www.google.com feito um

pedido ao servidor local de dns (servidor 2), se este no sabe qual o endereo ip
da maquina do nome fornecido vai encarregar-se de consultar outros servidores
dns seguindo a hierarquia dns. O servidor local (servidor 2) comea por contactar
o root name server (servidor 3) e recebe como resposta o endereo ip do servidor
dns seguinte (servidor 4), o servidor local vai ento contactar o servidor 4 e recebe
como resposta o endereo ip do servidor dns seguinte (servidor 5), e assim
sucessivamente at receber uma resposta com o endereo ip do nome pretendido,
s ento manda a resposta para o utilizador do pc 1 com o endereo ip do website
pretendido.

Vulnerabilidade DNS Spoofing

Normalmente usa um servidor dns fornecido por um ISP ou servidor dns da
organizao. Os servidores dns so usados na rede de uma organizao para
melhorar a performance das resposta pondo em cache o resultado obtido de
querrys anteriores. Ataques de envenenamento de cache num nico servidor dns
podem afetar os utilizadores diretamente servidos pelo servidor comprometido ou
utilizadores servidos por servidores num nvel hierrquico do servidor afetado (se
for aplicvel).
Para realizar um ataque de envenenamento da cache o atacante explora falhas no
software do DNS. O servidor deve validar corretamente as respostas para
assegurar que so de uma fonte autorizada (usando DNSSEC, por exempro), se isso
no acontecer o servidor pode acabar por colocar em cache entradas incorretas e
servi-las a utilizadores que faam o mesmo pedido.
Este ataque pode ser usado para redirecionar os utilizadores de um site para um
site escolhido pelo atacante. Por exemplo, um atacante spoofa (altera) o endereo
ip na tabela dns de um website num determinado servidor dns e redireciona o
utilizador para um website idntico ao site pretendido pelo utilizador. Quando o
utilizador chega a este website alterado pode ter o seu username e password
roubadas quando tenta fazer login no site ou pode ser induzido a fazer download
de ficheiros maliciosos. [6]

Ilustrao 5 DNS Spoofing [7]

Breve Histria do DNSSEC

1983 Paul Mockapetris inventa o DNS e implementa o primeiro servidor, o
Jeeves.
1986 O DNS torna-se um IETF Internet Standard. Dois RFC descrevem o DNS:
RFC1034 e o RFC1035.
1988 O DNS comea a disseminar-se pela Internet.
1990 Steven Bellovin descobre uma falha grave no DNS 2. Como o DNS j se
encontrava muito disseminado pela internet, este relatrio foi mantido em segredo
at 1995. Durante esses anos comea a pesquisa para um substituto mais seguro
ao DNS.
1995 O artigo de Bellovin publicado e o DNSSEC (como passou a ser conhecido)
torna-se um grande tpico de discusso na IETF.
1999 O RFC2535 publicado pelo IETF. O protocolo DNSSEC parece finalmente
finalizado. BIND9 desenvolvido para ser a primeira implementao capaz de
suportar DNSSEC.
1999-2001 Ainda que finalizado o DNSSEC no obtm grande expresso.
2001 Experiencias demostram que o manuseamento de chaves no RFC2535
esnto a causar problemas operacionais em alguns casos impossveis de
solucionar.
Aps algumas ideias e drafts, um novo tipo de registos foi proposto o DS
(Delegation Signer). decidido reescrever o RFC2535 em trs novos drafs.
2005 Os trs drafts so passados ao editor de RFC. O novo standard quase
oficial.
2005/ Maro Os RFCs so publicados:
RFC 4033 - DNS Security Introduction and Requirements
RFC 4034 - Resource Records for the DNS Security Extensions
RFC 4035 - Protocol Modifications for the DNS Security Extensions [7]

O que o DNSSEC?
O Domain Name System Security Extensions (DNSSEC) um conjunto de
especificaes da Internet Engineering Task Force (IETF) com vista a fornecer
segurana informao fornecida pelo Domain Name System (DNS). Esta extenso
ao DNS permite aos clientes de DNS (resolvers) a autenticao da origem dos
dados DNS, a autenticao da negao de existncia e a integridade dos dados mas
no assegura a sua disponibilidade nem confidencialidade. [8]

Estes mecanismos requerem que sejam introduzidas alteraes ao protocolo DNS.

O DNSSEC adiciona quatro novos tipos de registos de recursos:

Resourse Record Signature (RRSIG)

DNS Public Key (DNSKEY)
Delegation Signer (DS)
Next Secure (NSEC)

Para alm disso tambm adicionam dois novos message bits ao header DNS:

Checking Disabled (CD)

Authenticated Data (AD)

Para suportar o aumento do tamanho das mensagens DNS resultantes da adio

dos resourse records (RRs), o DNSSEC necessita tambm do suporte EDNS0
especificado no RFC2671. Para alm deste suporte necessrio tambm o suporte
para o DNSSEC OK (DO) EDNS header bit especificado no RFC3225 para que um
security-aware resolver (resolver de DNS que suporta DDNSSEC) possa indicar que
pretende receber DNSSEC RRs nas suas queries. [9]

O Funcionamento do DNSSEC
O DNSSEC oferece autenticao associando assinaturas criptogrficas geradas
digitalmente aos DNS RRs. Estas assinaturas so guardadas num novo RR, o RRSIG.
Normalmente existe apenas uma chave privada que assina todos os registos de
uma zona ainda que seja possvel o uso de vrias chaves. Por exemplo podem
existir diferentes chaves para cada um dos diferentes tipos de algoritmos de
assinatura digital. [9]
Uma vez que um security-aware resolver obtm de forma segura a chave pblica
da zona, este pode autenticar os dados assinados dessa zona. Um conceito
importante desta aproximao que uma chave assina a zona e no o servidor que
responsvel pela zona. [9]
Um security-aware resolver obtm a chave pblica da zona de duas maneiras
distintas. Uma tendo a chave pblica j guardada no sistema e configurada no
sistema a segunda atravs de uma resoluo de DNS normal. Para permitir a
obteno da chave pblica da segunda maneira, as chaves pblicas so guardadas
num novo tipo de RR, o DNSKEY. Por forma a garantir a segurana, as chaves
privadas devem ser guardadas offline sempre que possvel. Para garantir a
autenticidade da chave pblica obtida atravs da resoluo de DNS essa chave
pblica tem de ser assinada por outra chave previamente autenticada. [9]
Os security-aware resolvers autenticam a informao de zona formando uma
cadeia de confiana desde a chave pblica descoberta at a uma chave publica
autenticada previamente conhecida, chave esta que foi autenticada previamente ou
ento foi configurada no sistema de resolver. Assim sendo o resolver tem de estar
configurada com pelo menos uma chave pblica confivel previamente
configurada. [9]
Este tipo de cadeia de confiana muito semelhante cadeia de confiana dos
certificados digitais onde as autoridades certificadoras tm de vir j configuradas
no sistema do utilizador (normalmente no sistema operativo).
Se a ncora de confiana for uma chave pblica de zona, esta vai autenticar a zona
associada, se no entanto for uma chave pblica que assina uma chave de zona, esta

vai autenticar a chave de zona que por sua vez pode ser usada para autenticar a
zona associada. Se a ncora de segurana for no entanto o hash da chave pblica
em vez da chave em si, o resolver tem de obter a chave atravs de uma query DNS.
[9]
Para ajudar os security-aware resolvers a estabelecer esta cadeia de confiana,
sempre que haja espao na mensagem, os name servers (Servidores DNS que
suportam DNSSEC) enviam na sua resposta as assinaturas necessrias para a
autenticao da chave publica da zona bem como a prpria chave pblica da zona.
[9]
O tipo de RR Delegation Signer (DS) simplifica algumas das tarefas administrativas
envolvidas na delegao de assinaturas ao longo dos limites organizacionais. O RR
DS encontra-se nu ponto de delegao da zona Pai e indica a chave ou chaves
pblicas correspondentes s chaves privadas que foram usadas para assinar a
chave auto assinada no RR DNSKEY que usada na zona filha delegada. Por sua vez
o administrador da zona filha vai usar a chave privada associada a esse DNSKEY
para assinar os registos da zona filha. Tipicamente a cadeia de autenticao a
seguinte:

Ilustrao 6 Cadeia de autenticao [13]

Este mecanismo apenas oferece uma maneira de assinar RR existentes numa zona.
O problema de fornecer respostas negativas com o mesmo nvel de autenticidade e
integridade requer o uso de um novo tipo de RR, o NSEC. O NSEC permite a um
security-aware resolver autenticar a resposta negativa para um nome ou tipo no
existente com os mesmos mecanismos com que se autenticam outros pedidos DNS.
O uso de RR NSEC requer uma representao cannica e a ordenao dos nomes de
domnio nas zonas. As cadeias NSEC descrevem explicitamente as falhas ou
espaos em branco numa zona e listam os tipos de RR presentes e os seus nomes.
Cada RR NSEC assinada e autenticado como qualquer outro tipo de RR
introduzidos pelo DNSSEC. [9]
Esta implementao apresenta um problema no entanto, a chamada zone
walking. Este problema consiste no facto de um atacante fazer queries sequenciais
ao servidor de DNSSEC por forma a conseguir obter um mapa da rede uma vez que
as respostas NSEC devolvem uma resposta do intervalo de nomes no existentes
podendo por isso obter os nomes de domnio existentes. Este tipo de ataque no
existia no DNS pois este limitava-se a responder com a no existncia de um
determinado nome de domnio, j o DNSSEC responde com o intervalo de nomes
no existentes divulgando logo partida dois nomes existentes.
Por forma a contrariar este problema o RFC5155 veio substituir o NSEC pelo
NSEC3. Ao contrrio do NSEC que autenticava as falhas entre nomes numa zona o
NSEC3 autentica hashes das falhas dos nomes numa zona com um algoritmo de
hash mltiplas vezes adicionado um salt a cada processo de hashing. O salt deve
ser do tamalho do maior algoritmo de hash utilizado por exemplo se se usar o
sha256 o slat deve ser de 256bits. Esta soluo no impede a zone walking mas
em vez de nomes o atacante obtm os hashs desses nomes cujo processo de hash
pode ter sido repetido varias vezes dificultando exponencialmente o processo de
descoberta do nome a cada passagem de hash tornando todo o processo menos
apetecvel para o atacante. [10]

A arquitetura DNSSEC
Formato DNSKEY

O RDATA para o DNSKEY consiste em dois octetos para as Flags, um octeto para o
Protocolo, um octeto para o Algoritmo e um campo para a Chave Pblica. [11]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Flags
|
Protocol
|
Algorithm
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/
/
/
Public Key
/
/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[11]
Campo Flags
O bit 7 representa a Zone Key Flag. Se o bit 7 tiver o valor 1, ento trata-se de uma
DNSKEY que guarda uma chave de zona DNS e o nome do dono da DNSKEY deve
ser o nome da zona. Se o valor for 0 a DNSKEY guarda outro tipo de chave pblica
de DNS e no deve ser utilizada para validar RRSIGs.
O bit 15 representa a Secure Entry Point Flag descrita no RFC3757. Se o bit estiver
a 1, a DNSKEY guarda o registo de uma chave que usada como ponto de entrada
seguro. Esta flag usada como auxiliar na assinatura de zona ou em software de
debugging.
Os bits 0-6 e 8-14 esto reservados e devem ter o valor de 0 durante a criao de
DNSKEYs e ser ignorados na leitura. [11]

Campo Protocolo
Este campo deve ter o valor 3, qualquer outro tipo de valor faz com que a DNSKEy
seja considerada invlida.

Campo Algoritmo
Este campo identifica o algoritmo utilizado na criao da chave publica e
determina o formato do campo chave pblica. [11]
Alguns dos algoritmos disponveis e o seu valor:
Value Algorithm [Mnemonic] Signing References
Status
----- -------------------- --------- ---------- --------0
reserved
1
RSA/MD5 [RSAMD5]
n
[RFC2537] NOT RECOMMENDED
2
Diffie-Hellman [DH]
n
[RFC2539]
3
DSA/SHA-1 [DSA]
y
[RFC2536] OPTIONAL
4
Elliptic Curve [ECC]
TBA
5
RSA/SHA-1 [RSASHA1]
y
[RFC3110] MANDATORY
252
Indirect [INDIRECT]
n
253
Private [PRIVATEDNS]
y
see below OPTIONAL
254
Private [PRIVATEOID]
y
see below OPTIONAL
255
reserved
6 - 251

Available for assignment by IETF Standards Action. [11]

Campo Chve Pblica

Este campo guarda a chave pblica. O seu formato depende do tipo de algoritmo
utilizado.

Exemplo de DNSKEY

example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3

Cbl+BBZH4b/0PY1kxkmvHjcZc8no
kfzj31GajIQKY+5CptLr3buXA10h
WqTkF7H6RfoRqXQeogmMHfpftf6z
Mv1LyBUgia7za6ZEzOJBOztyvhjL
742iU/TpPSEDhm2SNKLijfUppn1U
aNvv4w== )

O primeiro campo o nome do dono do domnio, seguido do TTL, da Classe e o tipo

de RR neste caso DNSKEY. O valor 256 indica que o Zone Bit Key tem o valor 1. O
valor 3 fixo pelo protocolo e o valor 5 indica o algoritmo utilizado neste caso o
RSA/SHA1. Segue-se a chave pblica no formato base64. [11]

Formato RRSIG

O RDATA para o RRSIG consiste em dois octetos Type Covered para o tipo de RR
que coberto por este registo RR, um octeto para o algoritmo utilizado, um octeto
para Labels, 4 octetos para o TTL original, 4 octetos para a expirao da assinatura,
4 octetos para determinar a data a partir da qual a assinatura valida, 2 octetos
para a tag da chave, o nome do assinante e a assinatura. [11]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type Covered
| Algorithm
|
Labels
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Original TTL
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Signature Expiration
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Signature Inception
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key Tag
|
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signer's Name
/
/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/
/
/
Signature
/
/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tanto os campos Signature Expiration e Inception field representam a data e o

tempo num nmero de 32 bits unsigned que representa os segundos desde 1 de
janeiro de 1970 00:00:00 UTC, ignorando os segundos de salto. Devido ao uso de
arimtica de nmeros sequenciais a maior diferena de datas que se pode obter
dos dois 68 anos. [11]
Este valor independente do TTL original do DNS e no influenciado pelo
mesmo, isto , um TTL maior no aumenta a data de expirao da assinatura assim
como uma data de expirao de uma assinatura posterior no aumenta o TTL de
um registo DNS.

Exemplo RRSIG

host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (

20030220173103 2642 example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) [11]

O primeiro campo representa o nome do dono, o segundo o TTL de seguida a

Classe, e o tipo de RR neste caso um A ( domnio ipv4).
O valor 5 representa o algoritmo ( neste caso RSA/SHA1) utilizado para criar o
algoritmo. O valor 3 o nmero de labels no nome original do dono.
O valor 86400 o TTL original seguido dos tempos de expirao e incepo da
assinatura.
O valor 2642 a tag da chave seguido do nome do assinante. O resto a codificao
da assinatura em base64. [11]

Formato NSEC3
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Hash Alg.
|
Flags
|
Iterations
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt Length |
Salt
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash Length |
Next Hashed Owner Name
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/
Type Bit Maps
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

O algoritmo de Hash um octeto simples que pode indicar a ausncia de

encriptao se se activar o bit menos significativo. [12]
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|
|O|
+-+-+-+-+-+-+-+-+

Formato DS

O RDATA para o DS consiste em dois octetos para a tag da chave, um octeto para o
algoritmo, um octeto para o tipo de Digest e o campo de Digest. [11]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key Tag
| Algorithm
| Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/
/
/
Digest
/
/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Exemplo DS
Exemplo de um DNSKEY e o seu correspondente DS.
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
fwJr1AYtsmx3TGkJaNXVbfi/
2pHm822aJ5iI9BMzNXxeYCmZ
DRD99WYwYqUSdjMmmAphXdvx
egXd/M5+X7OrzKBaMbCVdFLU
Uh6DhweJBjEVv5f2wwjM9Xzc
nOf+EPbtG9DMBmADjFDc2w/r
ljwvFw==
) ; key id = 60485
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
98631FAD1A292118 )

Os primeiros quatro campos especificam o nome, TTL, Classe e tipo de RR neste

caso o DS.
O campo 60485 a tag da chave que corresponde ao dskey.example.com e o valor
5 corresponde ao algoritmo utilizado (RSA/SHA1) o valor 1 corresponde ao
algoritmo de digest e o resto o digest em formato hexadecimal. [11]

Concluso
Apesar de ser um grande passo em frente ao nvel da segurana o DNSSEC ainda
apresenta algumas falhas que tm de ser solucionadas at que tenhamos um
sistema verdadeiramente robusto e eficiente de DNS.
O NSEC3 veio mitigar algumas das falhas mais graves do DNSSEC mas o problema
subjacente do zone walking ainda existe e existem testes em que o bruteforce
com recurso a placas grficas conseguiu obter resultados ainda que tenha levado
algum tempo.
Apesar de tudo o DNSSEC apresente um nvel de segurana muito superior ao DNS
e espera-se que a sua disseminao seja cada vez maior por forma a termos uma
internet mais segura.

Bibliografia
[1]

A. Fonte, O. Santos e V. Soares, Aplicaes Internet - Servio DNS, Introduo ao DNS, Castelo Branco,
2014.

[2]

P. Remoaldo, Domain Name Services, Faculdade de Engenharia, Universidade do Porto, 05 1998.

[Online]. Available: http://paginas.fe.up.pt/~mgi97018/dns.html#1. [Acedido em 28 05 2015].

[3]

N. I. Exchange, Many rootservers connected to NL-ix, 21 10 2013. [Online]. Available: https://www.nlix.net/news/95/many_rootservers_connected_to__nlix/. [Acedido em 28 05 2015].

[4]

IANA, Root Servers, [Online]. Available: https://www.iana.org/domains/root/servers. [Acedido em 28

05 2015].

[5]

Fir3Net, DNS / nslookup - How to find the root servers ?, 31 10 2008. [Online]. Available:
https://www.fir3net.com/Networking/Protocols/dns-nslookup-how-to-find-the-root-servers.html.
[Acedido em 28 05 2015].

[6]

Wikipedia, DNS spoofing, 12 03 2015. [Online]. Available: http://en.wikipedia.org/wiki/DNS_spoofing.

[Acedido em 28 05 2015].

[7]

S. N. Labs, A Short Story of DNSSEC, Stichting NLnet Labs, 27 9 2013. [Online]. Available:
http://www.nlnetlabs.nl/projects/dnssec/history.html. [Acedido em 28 05 2015].

[8]

Wikipedia, Domain Name System Security Extensions, Wikipedia, 26 05 2015. [Online]. Available:
http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions. [Acedido em 28 05 2015].

[9]

R. Arends, R. Austein, M. Larson, D. Massey e S. Rose, RFC4033, Network Working Group - IETF, 03
2005. [Online]. Available: http://www.ietf.org/rfc/rfc4033.txt. [Acedido em 28 05 2015].

[10] R. v. Rein, Cryptographic sanity: NSEC3 parameters, Surf Net, 20 05 2010. [Online]. Available:
https://dnssec.surfnet.nl/?p=60. [Acedido em 28 05 2015].

[11] R. Arends, R. Austein, M. Larson, D. Massey e S. Rose, RFC4034, Network Working Group - IETF, 03
2005. [Online]. Available: http://www.ietf.org/rfc/rfc4034.txt. [Acedido em 28 05 2015].

[12] B. Laurie, G. Sisson, R. Arends e D. Blacka, RFC5155, Network Working Group -IETF, 03 2008. [Online].
Available: http://www.ietf.org/rfc/rfc5155.txt. [Acedido em 28 05 2015].

[13] R. v. Rijswijk, How many keys #2, Surf Net, 9 09 2010. [Online]. Available:
https://dnssec.surfnet.nl/?p=509. [Acedido em 28 05 2015].

[14] C. H. Kuroiwa, Tutorial DNSSEC, 18 07 2012. [Online]. Available:

ftp://ftp.registro.br/pub/doc/tutorial-dnssec.pdf. [Acedido em 28 05 2015].

[15] O. N. Cert, Signs of a DNS Cache Poisoning Attack, Oman Natianal Cert, [Online]. Available:
http://www.cert.gov.om/media_news_details.aspx?news=20#.VWjaqEarFXM. [Acedido em 28 05 2015].