Introduction à DNSSEC

De Ensiwiki
Aller à : navigation, rechercher
DNSSEC: Problèmes de performance et ponts vers d'autres protocoles
Projet Projet de spécialité 2A
Sous-projet Communication et Réseaux
Étudiants Quentin LUC, Cyril LUPO, Thê-Minh TRINH
Promo 2012
Tuteur Martin Heusse (LIG)
Accueil projet: DNSSEC: Problèmes de performances et ponts vers d’autres protocoles

Le but de cet article est de détailler le protocole DNSSEC (et ses subtilités) qu'il sera nécessaire de comprendre en vue d'une réalisation pratique. Cet article est motivé par la lourdeur que constitue la lecture des RFC détaillant le fonctionnement de DNSSEC (RFC 4033, RFC 4034, RFC 4035, RFC 5155 et RFC 5702) ainsi que le peu de documentation disponible sur Internet. Le lecteur trouvera donc ici une explication plus abordable et en français des principes de base de DNSSEC.


Le protocole DNS été conçu en 1983 et la sécurité n'était pas un élément essentiel dans sa conception. De nombreuses failles ont alors été découvertes. DNS s'est montré vulnérable à plusieurs types d'attaques, comme par DDOS ou attaques type Man in the middle. Les choses se sont accélérées en 2008, année où le chercheur en sécurité informatique Dan Kaminski révèle une faille majeure qui permet de rediriger tout client faisant une requête DNS vers un serveur différent. Pour cela, le pirate doit simplement réussir à deviner l'ID de la requête et à répondre avant le serveur d'autorité (empoisonnant ainsi le cache du résolveur). Cela a donc ouvert la porte a un tout nouveau type de phishing. Cette découverte a bousculé les choses pour DNSSEC (DNS Security Extensions) dans la mesure où l'ampleur de la vulnérabilité nécessitait une contre-mesure efficace, donnant lieu à une avancée significative dans son déploiement.


DNSSEC apporte trois fonctionnalités par rapport à DNS:

  1. Authentification des données contenues dans les réponses.
  2. Intégrité de ces données.
  3. Preuve de non existence.


Dans un premier temps, ce document s'intéresse au fonctionnement du protocole DNSSEC et aux fonctionnalités apportées par rapport à DNS, et, dans un second temps, rend compte du déploiement actuel de DNSSEC.


Fonctionnement du protocole DNSSEC

Principes généraux de DNSSEC

Authenticité et intégrité

Afin d'assurer l'authenticité et l'intégrité des réponses, DNSSEC est basé sur un modèle de cryptographie à clé publique. Un serveur d'autorité calcule un hash de la réponse puis le signe avec une clé privée (secrète) avant d'envoyer le paquet et son hash au résolveur. Celui-ci sera à même de vérifier l'authenticité et l'intégrité des données en vérifiant que le hash déchiffré à l'aide de la clé publique associée à la clé privée correspond bien au hash recalculé de la réponse.


Remarque: En général, on appelle la réponse d'une requête DNS RRset (Record Resource set). Cela correspond en fait à un ensemble d'enregistrements associés à un domaine

ex: RRset correspondant à www.dnssec-tools.org

# dig www.dnssec-tools.org A

; <<>> DiG 9.4.1-P1 <<>> www.dnssec-tools.org A
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19511
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.dnssec-tools.org.          IN      A

;; ANSWER SECTION:
www.dnssec-tools.org.   14400   IN      A       66.35.250.210

;; AUTHORITY SECTION:
dnssec-tools.org.       86400   IN      NS      ns4.dnssec-tools.org.
dnssec-tools.org.       86400   IN      NS      ns1.dnssec-tools.org.

;; ADDITIONAL SECTION:
ns1.dnssec-tools.org.   86400   IN      A       168.150.236.43
ns4.dnssec-tools.org.   86400   IN      A       76.216.12.217

;; Query time: 13 msec
;; SERVER: 168.150.236.43#53(168.150.236.43)
;; WHEN: Mon Apr  7 15:27:56 2008
;; MSG SIZE  rcvd: 122

L'adaptation de la signature électronique à DNSSEC sera détaillée plus en profondeur dans la section 1.3. La compréhension de cette partie nécessitera la connaissance des différents enregistrements détaillés en partie 1.2.

Preuve de non-existence

Le mécanisme succinctement expliqué ci-dessus ne fonctionne que dans le cas où il existe une réponse concernant la requête DNS. Dans le cas où aucun RRset ne correspond à la requête, il faut pouvoir prouver qu'il n'existe bien aucun enregistrement. Pour cela, DNSSEC utilise un nouveau type d'enregistrement qui permet d'envoyer le nom du premier domaine existant par ordre alphabétique. Cette preuve de non-existence est détaillée dans la section 1.5.




Apports de DNSSEC par rapport à DNS

Les enregistrements en pratique

DNS est constitué d'un ensemble d'enregsitrement (RRSet) qui sont en fait les informations relatives au domaine. Chaque enregistrement est composé d'un type qui permet d'identifier les informations (A pour l'IPv4, AAAA pour l'IPv6, SOA pour le serveur autoritaire, ...). Sur le serveur DNS, l'ensemble de ces informations sont simplement stockées dans un fichier qui est consulté dès qu'une demande est faite. Voici un exemple de fichier de zone :

$TTL	2h
@	IN	SOA	server.projet. postmaster.projet. (
				2009101201
				8H
				2H
				1W
				1D
	)

@		IN	NS	server.projet.

server		A	192.168.0.3
cyril		A	192.168.0.41
quentin		NS	server.quentin
theminh		A	192.168.0.121
papa		A	192.168.0.132

server.quentin	A	192.168.10.4


Les enregistrements de DNSSEC

DNSSEC est un protocole construit de telle sorte qu'un serveur adapté à DNSSEC puisse traiter des requêtes DNS classiques. On retrouve donc entre autres tous les enregistrements (Resource Records: RR) de DNS dans un paquet DNSSEC. La RFC 4034 précise l'ajout de quatre enregistrements:

  1. DNSKEY
  2. RRSIG
  3. NSEC
  4. DS

La RFC 5155, parue ultérieurement, précise l'ajout de deux nouveaux enregistrements:

  1. NSEC3
  2. NSEC3PARAM

Nous détaillerons l'utilité de ces nouveaux enregistrements dans les sous-parties qui suivent.

Enregistrement DNSKEY

L'enregistrement DNSKEY est utilisé pour transmettre une clé publique entre le résolveur et le serveur de nom. Cette clé publique est celle qui est associée à la clé privée avec laquelle le serveur d'autorité va signer les hashs des enregistrements RRSET . Le résolveur utilisera donc la clé publique écrite dans l'enregistrement DNSKEY pour vérifier la signature du serveur d'autorité, s'assurant ainsi de l'intégrité et de l'authenticité du message. Il est à noter qu'une clé publique est associée à une zone et non à un serveur (voir la section 1.3.1 pour plus d'information).

Un enregistrement DNSKEY a la structure suivante:


                        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                         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Flags: Les bits 0-6 et 8-14 sont réservés et doivent valoir 0. Si le bit 7 est à 1, c'est que la clé publique de l'enregistrement correspond à la clé publique d'une zone, et le nom associé à cette clé publique doit être le nom d'une zone. S'il est à 0, c'est que l'information contenue ne correspond pas au type de clé publique normalement utilisée et que l'information du champ Public Key ne doit pas être utilisée pour vérifier une signature.

Champ Protocol: Doit valoir 3 pour que l'enregistrement DNSKEY soit valide. Il sera ignoré sinon.

Champ Algorithm: Indique l'algorithme de cryptographie à clé publique utilisé pour générer la clé. Dans la plupart des cas, on utilisera RSA associé à la fonction de hachage cryptographique SHA-2 (La RFC 5702 préconise le basculement de SHA-1 à SHA-2). Dans ce cas, le champ Algorithm vaudra alors 8 (au lieu de 5 pour SHA-1).

Champ Public Key: Contient la clé publique de la zone.


En pratique, ce se traduit dans le fichier de zone signé par :

projet.			7200	DNSKEY	256 3 5 (
					AwEAAeINDB+FifDLUQTdYHlGs3zOPpBDYzEY
					1YXHYQXhJLlXUJVB6OyuKngwFTeSqCWpbeA3
					y2s79gXApUvXKFACXVDDi2KpEwBSlx4sDx2o
					C3StA35xRaidFIWRhOghkXWwgN+wn9HXRIfC
					IjR0Ywdme25qyuTBRiqxA+0/KU6In+t/
					) 

Ainsi, lorsqu'une demande DNSKEY est faite, le serveur transmet exactement ce qui est affiché ci-dessus. On retrouve bien les champs décrits ci-dessus, notamment le champ protocole qui vaut bien 3 et le 5 qui indique que l'on chiffre le message grâce à SHA-1.

Enregistrement RRSIG

L'enregistrement RRSIG contient la signature de l'enregistrement envoyé par le serveur d'autorité. Il s'agit de la signature obtenue en signant le hash du RRset avec la clé privée du serveur d'autorité, c'est-à-dire à celle contenue dans l'enregistrement DNSKEY. C'est cette signature que le résolveur vérifiera par la suite. Ainsi, il existera un enregistrement RRSIG pour chaque enregistrement de la zone dans le fichier de zone signé.

Un enregistrement RRSIG a la structure suivante:

                        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                          /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Type Covered: Indique le type d'enregistrement qui a été signé (à quel enregistrement correspond la signature).

Champ Algorithm: idem DNSKEY

Champ Labels: Indique le nombre de domaines contenus dans le RRset signé (par exemple, pour www.quentinluc.com, le champ vaudra 3). Si un des domaines est *, le résolveur devra trouver le domaine associée. En effet, pour vérifier la signature, il faut le nom du signataire car sig=K_{ZSK}(Hash( nom | RRset ) )

Champ Original TTL: Vaut le TTL (Time To Live) du RRset signé.

Champ Key Tag: Étiquette permettant d'identifier de façon efficace un enregistrement DNSKEY ayant de fortes chances de correspondre à cet enregistrement RRSIG, si l'on connaît le nom du détenteur de la clé et l'algorithme utilisé. Il est à noter que cette étiquette n'est pas unique donc ne permet pas d'identifier formellement la bonne clé, mais un ensemble de clés ayant une forte probabilité d'être la bonne.

Champ Signer's Name: Indique le nom de la zone détentrice de la clé utilisée pour la signature. Ce nom est utile pour la vérification de la signature.

Champ Signature: Contient la signature.

Voici un extrait de notre fichier de zone signé :

cyril.projet.		7200	IN A	192.168.0.41
			7200	RRSIG	A 5 2 7200 20110708131554 (
					20110608131554 10548 projet.
					23s788snO7HZqJ6d13M+ppFaHmUJ8M6DbNDf
					75+ScvTmjN7kjjUonEOdscNaVUoi+8j9oWeB
					u33eYUAhntf5A8Cmat2ya2/DF9/67CaJoH2a
					hkjGOKNhdQ1IYreGtB03PHPzqAAEHOAtfDBH
					tgoZapD0ZLMA2N6eeUfUyqz2MS0= )
			86400	NSEC	quentin.projet. A RRSIG NSEC
			86400	RRSIG	NSEC 5 2 86400 20110708131554 (
					20110608131554 10548 projet.
					RkCEJDGrIrfSDhYcr1Xl7HbKM/wBpyKmJRIu
					sL2G1t/EItLmu4ic15GZjWvqXKTL1jNYPzB7
					YzpvHF+GerzY1hiXPs7HYq0Z1aSQ2k7ng9Dl
					H/fPoxc0JC7a+h0i+ztGkGXQ+taI2wAhuM+M
					ti/8tFuCVXKyz+2iNTkipmnbdDg= )
server.projet.		7200	IN A	192.168.0.3
			7200	RRSIG	A 5 2 7200 20110708131554 (
					20110608131554 10548 projet.
					4d6nydSGDGoW7qXFGDJDHKCgzcti1jS8JW0k
					TDCNxuXBKEdvpU1vdMCZMMUzMnb4XIe+S10t
					guwTNFkkBkS4CNWmtxaeN9DrcqPY+HeyT3UJ
					nxuhbJidDbK5Q9TToSVFY9piEP/wd5Y/H0ro
					0+g9liinUKEIIfBbEnL9+IlsIXM= )
			86400	NSEC	theminh.projet. A RRSIG NSEC
			86400	RRSIG	NSEC 5 2 86400 20110708131554 (
					20110608131554 10548 projet.
					OB2sespNLPdzmwAt1GEJpvlB0WvKuDXcRBR2
					QNhwG4cZ0QDS2tubY/Pm9Q80BWOISOoK+1J3
					BmhqfRqQ2fA5mLyCfRl5gzwcZEaPKnRSXZC8
					tKC+ojeWDLQGmj6EyljQCRH8LcjQp0m4SFnF
					DZe3cwa55wYbuwkTY5tM6m9WwQQ= )
theminh.projet.		7200	IN A	192.168.0.121
			7200	RRSIG	A 5 2 7200 20110708131554 (
					20110608131554 10548 projet.
					2m4eH7nB+hJ1u9AllBxwcnA8ZPP6I+yXwtci
					iCBulsvP+Mko0O4KxdCx+3ThViVkKmpuPwnL
					gTBs+ksCqI7gKOYc3NRxvbGHl916eirX6V3F
					brAhvBSSu5BBjVT7sJi+JKD8XKZZY4VCi05E
					bC6W1+45c0VZprjkAP5IkNiKa84= )
			86400	NSEC	projet. A RRSIG NSEC
			86400	RRSIG	NSEC 5 2 86400 20110708131554 (
					20110608131554 10548 projet.
					BAN23n0xv4I1vd4lWBa1vBnVUfW1OgpzADbL
					v17PKt0moVReyZMm2L4evzCNX2TJj73ihqaS
					ipvTFxzdbLa7gIY+aKBMH7J0AndJC5zO4pq6
					8IVaNAimHtFk2OVruHdkKFu5o6TOjVN5N7nw
					keBKA4WekHVfdMWmCKAT7lEbv+Q= )

On constate bien la présence d'enregistrement RRSIG pour chaque type d'enregistrement. Ces enregistrements sont distingués grâce au deuxième champ qui indique l'enregistrement signé.


Enregistrement NSEC

L'enregistrement NSEC est utilisé dans le cadre d'une preuve de non existence. Il contient tout d'abord le nom du prochain domaine d'autorité ou du point de délégation pour la requête concernée ainsi que les enregistrements qui existent pour le-dit nom.

Un enregistrement NSEC a la structure suivante:

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                      Next Domain Name                         /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Type Bit Maps                           /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Next Domain Name: Contient le nom de la prochaine zone d'autorité concernant la requête suivant la relation d'ordre sur les RRsets. Pour le nom suivant le dernier RRset, on renvoie le nom de la zone mère.

Champ Type Bit Maps: Identifie les types d'enregistrements correspondant au nom associé à la requête.


Voici un extrait de notre fichier de zone signé :

cyril.projet.		7200	IN A	192.168.0.41
[...]
			86400	NSEC	quentin.projet. A RRSIG NSEC
[...]

On retrouve bien l'enregistrement NSEC pour chacun des noms enregistrés qui contient le nom qui se situe juste après lui dans l'ordre alphabétique. On remarque également qu'il indique quels sont les enregistrements disponibles pour le nom précédemment cité (ici A, RRSIG et NSEC).

Lors de la demande d'une correspondance par un serveur d'un nom inconnu, le serveur de nom va rechercher l'encadrement dans lequel il se situe et renvoyer l'enregistrement.

Enregistrement DS

Un enregistrement DS d'une zone mère est directement lié à l'enregistrement DNSKEY d'une des zones filles. Son but est de pouvoir identifier rapidement la clé publique de la zone fille (allégeant ainsi le coût de l'authentification). Il contient un Hash du nom du détenteur de la clé publique (zone fille) concaténé aux données de l'enregistrement DNSKEY (de la zone fille). Il permet entre autre d'établir la chaine de confiance (voir section 1.4 sans avoir besoin de l'intervention de l'administrateur du réseau. En effet, cet enregistrement est demandé par le résolveur au serveur autoritaire dès qu'il a besoin de vérifier une signature reçue par la zone fille. Ainsi, la zone mère lui indique qu'il peut faire confiance à ce serveur en lui renvoyant un hash de la clé signé par elle-même. Le résolveur sait ainsi qu'il peut lui faire confiance.

Un enregistrement DS a la structure suivante:

                        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                             /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Key Tag, Algorithm: Idem RRSIG

Champ Digest Type: Fonction de hachage cryptographique utilisée pour construire le hash situé dans le champ Digest. On utilisera en général SHA-1.

Champ Digest: Digest = Hash( nomfille | DNSKEY )


L'enregistrement DS est le seul enregistrement de DNSSEC qui va être présent dans le fichier de zone non-signé (contenant les informations du simple DNS). En effet, cet enregistrement DS lui a été fournit par la zone fille et doit être signé par la zone mère pour pouvoir prouver son authenticité. Le fichier de zone signé étant généré automatiquement, il faut que l'enregistrement DS soit présent dans le fichier de zone non-signé pour être signé.

Voici l'enregistrement DS de notre fichier de zone non-signé :

quentin.projet.		IN DS 51781 5 1 3BFA45EC2BF40CC96308A3C3C4D2F55812E17015
quentin.projet.		IN DS 51781 5 2 754505D33985643182D3EF9AA0E47B4D3324A4818EA682BDA79E89DF 76377A74

Et voici l'enregistrement DS dans notre fichier de zone signé :

quentin.projet.		7200	IN NS	server.quentin.projet.
			7200	DS	51781 5 1 (
					3BFA45EC2BF40CC96308A3C3C4D2F55812E1
					7015 )
			7200	DS	51781 5 2 (
					754505D33985643182D3EF9AA0E47B4D3324
					A4818EA682BDA79E89DF76377A74 )
			7200	RRSIG	DS 5 2 7200 20110708131554 (
					20110608131554 10548 projet.
					nQ81bTai5N6NXCPwNZriav46iV5R8WSZjOop
					3b09wchJXd3YVfrgBIRyEeJI2brJgvHfMGko
					2XmyyLbJi3cZo7rcI5EWXZR0egOkjNYH/r6b
					MUunaVwISeqb0sAJ45gdCnIIdV9sU3Yg3F6R
					aBE81u/hpcupQUtqVcUOCzQJ+GM= )

On observe bien le RRSIG correspondant à DS.

Enregistrement NSEC3

L'enregistrement NSEC3 est apparu ultérieurement à NSEC (RFC 5155). Il a le même objectif tout en luttant contre des attaques de type "énumération de zone" (voir section 1.5). En effet, pour éviter qu'une personne mal intentionnée soit en mesure de reconstruire toutes les correspondances nom-adresse en envoyant volontairement des requêtes échelonnées, l'enregistrement NSEC3 utilise une fonction de hachage appliquée aux noms renvoyés. Ainsi, sera envoyé le hash du prochain nom de la zone, ne permettant alors pas de reconstruire la zone entière (la fonction de hachage doit-être résistante aux collisions).

Un enregistrement NSEC3 a la structure suivante:

                     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                         /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Hash Alg.: Indique la fonction de hachage cryptographique utilisée.

Champ Flags: Aucun flag n'est défini sauf le 8ème qui est un flag opt-out. Si le 8ème bit est à 1, l'enregistrement NSEC3 contient des délégations non signées.

Champ Iterations: Nombre d'appels de la fonction de hachage pour calculer le hash

Champ Salt Length: Taille en octet du champ Salt

Champ Salt: Un paramètre en entrée de la fonction de hachage pour éviter les attaques par dictionnaire.

Champ Hash Length: Taille du champ Next Hashed Owner Name

Champ Next Hashed Owner Name: Contient le hash suivant le hash de la requête selon la relation d'ordre sur les hashs. Le Next Hashed Owner name du dernier hash de la zone correspond au premier hash de la zone

Champ Type Bit Maps: idem NSEC


L'enregistrement NSEC3 est l'un des enregistrement DNSSEC le plus difficile à mettre en place. En effet, il faut pour cela générer une nouvelle paire de clé pour le hashage des noms et ensuite calculé le hash de l'ensemble des noms de la zone. Le coût est encore plus élevé que pour simplement DNSSEC (le résolveur doit calculer le hash des noms reçus à chaques requêtes de ce type qu'il reçoit). De plus, l'implémentation de cette fonctionnalité n'est pas compatible avec NSEC. En effet, une fois que NSEC3 a été implémenté sur le serveur, tous les autres serveurs qui n'ont pas la fonction implémentée vont considérer que la réponse n'est pas sécurisée (même si DNSSEC est implémenté).


Enregistrement NSEC3PARAM

L'enregistrement NSEC3PARAM est apparu dans la RFC 5155. Il contient les paramètres de l'enregistrement NSEC3. Il ne sert qu'aux serveurs d'autorité pour calculer le hash des noms qu'il conserve.


Un enregistrement NSEC3PARAM a la structure suivante:

                        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                      /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tous les champs sont identiques aux champs correspondant de NSEC3.


Authenticité et intégrité

Gestion des clés

Pour pouvoir prouver l'authenticité et l'intégrité des réponses, DNSSEC utilise le système de cryptographie à clé publique. Ainsi, le serveur va utiliser une première paire de clés pour chiffrer les hash des réponses qu'il doit transmettre aux demandeurs. Cependant, au vu du grand nombre de données qui allaient être chiffrées avec ces clés, il s'est avéré indispensable de renouveler ces clés régulièrement afin d'éviter qu'un pirate puisse les craquer (en effet, plus la quantité de données chiffrées est importante, plus un pirate a d'information et est capable de craquer le chiffrement).

Pour éviter aux administrateurs des réseaux de devoir trop souvent indiquer de nouvelles paires de clés, une nouvelle paire de clé a été introduite. Ces clés sont plus longues et amenés a être renouvelées moins régulièrement. Elles permettent ainsi les échanges des clés de manière sécurisée permettant le renouvellement fréquent de la première paire.

Ces deux paires de clés sont décrites un peu plus en détail ci-dessous.


Zone Signing Key (ZSK)

La Zone Signing Key (ZSK) correspond à la clé privée utilisée pour signer une zone, c'est-à-dire les enregistrements demandés par les serveurs récursifs. La clé publique correspondante est connue des serveurs récursifs afin qu'ils puissent vérifier les hash des réponses. La validité d'une ZSK est indiquée par un TTL (Time to live), qui sera en général de 1 mois (elle correspond au couple de clé amené à être renouvelé régulièrement).

Key Signing Key (KSK)

La Key Signing Key est une clé privée destinée à signer une clé de zone (ZSK). Une KSK n'est utilisée que pour signer un enregistrement DNSKEY (voir section 1.2.3). La clé KSK fait office de maillon de confiance dans la chaîne de confiance décrite en section 1.4. Il est à noter que les KSK ont des TTL plus longs que les ZSK (13 mois en général), en raison de leur plus grande taille et des échanges moindres.

Remarque: les champs TTL définissent ainsi la fréquence de roulement des clés

Stockage des clés

La gestion des clés privées est un des principaux problèmes rencontrés lors du déploiement de DNSSEC. Les problèmes rencontrés sont identiques à ceux rencontrés lors du déploiement de n'importe quelle P.K.I (public key infrastructure).

La sécurité de DNSSEC reposant sur le secret contenu dans les clés privées KSK et ZSK, celles-ci doivent être stockées à des endroits non connectés au réseau. Les clés publiques sont stockées dans les enregistrements DNSKEY.

Algorithmes et fonctions de hachage utilisés

En général, RSA est utilisé avec une fonction de hachage de la famille SHA-2 (SHA-256, SHA-512). La RFC 4034 préconisait l'utilisation de SHA-1, ce qui a été corrigé en SHA-2 en octobre 2009 dans la RFC 5702

Que doit-on signer ?

Qui signe ?

Lors d'une réponse à une requête DNSSEC c'est le serveur d'autorité qui signe la réponse avec la clé privée ZSK de la zone sur laquelle il a autorité. C'est le résolveur qui réalise tous les calculs cryptographique lors d'une réponse à une requête DNS. Le serveur d'autorité, lui, ne fait que transmettre les données dont les signatures ont été pré-calculées. Seul le résolveur devra donc être une machine dotée d'une puissante force de calcul.

Que signe t -il ?

Le calcul de la signature est donné par la formule suivante :

signature = K_{ZSK}( Hash( RRSIGDATA | RR(1) | RR(2) | ...))

où RRSIGDATA est la concaténation de tous les champs de l'enregistrement RRSIG sauf le champ Signature, et

RR(i) = nomdetenteur | type | classe | TTL | Taille RDATA | RDATA ,

nomdetenteur est le nom du signataire en forme canonique, et tel que tous les RR(i) vérifient

  1. le nom du détenteur correspond au champ Signer's Name du RRSIG
  2. la classe est la même que celle du RRSIG
  3. le type fait partie des types listés dans le champ Type Covered Field
  4. le TTL est le même que clui du RRSIG

Quelles métadonnées ?

Il est important de souligner la corrélation entre l'enregistrement RRSIG envoyé par une zone fille et l'enregistrement DNSKEY de la zone mère. En effet, l'enregistrement DNSKEY de la zone mère permet d'identifier le signataire du RRSIG, grâce aux champs Algorithm, Protocol, et Public Key. On voit donc ici apparaître la notion de lien de confiance entre les zones

Chaîne d'authentification et chaîne de confiance

Une des contraintes sur lesquelles repose DNSSEC est l'échange de clés publiques. Il faut pouvoir être sûr que la clé publique située dans l'enregistrement DNSKEY du résolveur correspond bien à la bonne clé de la zone. De plus, on souhaite que les échanges de clés soient fait de manière totalement automatique. Pour cela, on construit une chaîne de confiance basée sur la hiérarchie de l'architecture DNS.

Remarque : Pour comprendre pleinement cette partie, il est nécessaire d'avoir compris la différence subtile entre un domaine et une zone en DNS.

Construction de la chaîne de confiance

Il est impossible pour un serveur DNS de contrôler et de gérer l'ensemble des domaines mondiaux. C'est pourquoi DNS est basée sur le principe des délégations. Ces délégations consistent à transmettre l'autorité sur un ou plusieurs sous-domaines à un autre organisme.

DNSSEC utilise ce principe de délégation pour établir la chaine de confiance. En effet, à partir du moment où l'on fait confiance au serveur autoritaire, et que celui-ci nous indique que l'un de ces serveurs enfant est digne de confiance, nous faisons alors confiance à celui-ci. Et ainsi de suite (évidemment, il suffit que l'on fasse confiance au serveur fils pour faire confiance au serveur autoritaire).

De manière pratique, cela se traduit par une authentification de la clé du serveur fille par le serveur autoritaire grâce aux enregistrements DS (voir section 1.2.6).

Le concept de Trust Anchor

Tout paraît simple dans l'application de cette chaine de confiance, mais c'est l'un des éléments le plus critique de DNSSEC. Pour que celle-ci puisse être appliquée, il faut introduire un nouveau concept, celui du trust anchor. En effet, pour faire confiance au fils, on doit demander au père. Mais quid du serveur racine ?

On appelle trust anchor (encre de confiance) la première clé de la chaine a qui on fait confiance. Cette clé est la clé publique associée à la KSK de la racine. Tous les serveurs sont censés connaître cette clé qui est entrée manuellement.

Cette trust anchor est un élément critique de la chaine de confiance puisqu'il suffit qu'un pirate réussisse à trouver la clé privée pour que toute la chaine de confiance soit compromise.

Exemple de mise en place d'un ilot sécurisé

DNSSEC est à ce jour (jeudi 9 juin 2011) en cours de déploiement, et encore de nombreux serveurs n'ont pas implémenté cette fonctionnalité (voir section 2). Il existe cependant des ilots sécurisés, qui ne peuvent pas faire valider leurs clés par leurs serveurs autoritaires respectifs, mais qui ont quand même souhaités développer des échanges sécurisés pour leurs sous-domaines.

Pour mettre en place cela, on doit introduire manuellement la clé publique associée à la KSK de la zone mère dans les différents autres serveurs. De plus, pour pouvoir indiquer qu'une zone fille est sécurisée, il est nécessaire d'introduire l'enregistrement DS de la fille à l'intérieur du fichier de zone autoritaire manuellement aussi.

Cet échange est représenté sur la figure ci-dessous


Envoi ds (DNSSEC).png

DNSSEC Lookaside Validation (DLV)

Une alternative à la gestion manuelle des trust anchors est d'utiliser DLV (DNSSEC Lookaside Validation), normalisé plus tard. L'idée est de dissocier la racine du DNS et la racine de signature DNSSEC (pour des problèmes politiques). Avec DLV, et contrairement au DNSSEC, plusieurs "racines" peuvent signer un même domaine (une racine DLV qui signe .org et une autre qui signe site.org). Le résolveur DLV peut utiliser l'algorithme qu'il veut. Cette alternative a eu beaucoup de détracteurs, car elle aurait retardé la signature de la racine. Maintenant que la racine est signée, la clé de la racine devrait suffire en tant que trust anchor. Cela explique aussi le fait qu'il y ait très peu de TLD qui ont leur trust anchor publiée dans le dépot DLV de l'ISC (Internet Systems Consortium).

Preuve de non-existence

La preuve de non-existence est un des moyens de DNSSEC pour s'assurer qu'un nom de domaine n'existe pas. En effet, il est facile de prouver qu'un enregistrement existe, en renvoyant la correspondance de manière chiffrée, mais dans le cas où celui-ci n'existe pas, il faut tout de même s'assurer que la demande a correctement été effectuée au serveur DNS.

Fonctionnement de la preuve de non-existence basée sur NSEC

Le serveur DNS est capable, grâce à l'enregistrement NSEC signé d'indiquer quel est le nom de domaine qui aurait suivi l'enregistrement manquant. L'ordre des noms de domaine suit simplement celui de la table ASCII. Par exemple, si je fais la demande au serveur de nexistepas.grandcercle.org, j'obtiens en retour :

lulu.grandcercle.org.    43200   IN      NSEC    panda.grandcercle.org. AAAA RRSIG NSEC

Je sais donc qu'il n'existe aucun enregistrement entre lulu.grandcercle.org et panda.grandcercle.org

Problème de l'énumération de zone

Le problème de ce protocole est que les noms de domaines sont renvoyés en clairs et il est donc possible, par l'utilisation de requêtes NSEC chainées d'obtenir l'ensemble des noms de domaine pour une zone. Cela permettrait, pour un attaquant, de connaître le nombre exact de machines dans le sous-domaine voire plus, sachant que certains administrateurs de serveur DNS y rajoutent des informations sur leur configuration et leur type.

Solution basée sur NSEC3

Pour résoudre ce problème, une extension à NSEC a été développée qui permet non pas de donner en clair les noms de la zone, mais seulement leur hash. Ainsi, le serveur va calculer le hash de chacun des noms qu'il dessert et ordonner non pas par ordre des noms, mais cette par ordre des hash. Ensuite, lorsqu'un résolveur demande un nom, le serveur va calculer son hash et vérifier son existence dans sa table de hash. Dans le cas où ce nom n'existe pas, il va alors renvoyer l'intervalle dans lequel se situe le hash du nom demandé.


Déploiement à l'heure actuelle

Les acteurs

Le déploiement d'une chaîne de confiance pour DNSSEC complète implique l'intervention de plusieurs acteurs: les autorités de régulation de l'internet, les FAI (fournisseurs d'accès à internet), les fabricants de matériel et les développeurs.


Le déploiement de DNSSEC au niveau mondial a débuté en 2010. Le 15 Juillet 2010, l'ICANN annonce que la zone racine est signée. Aujourd'hui, plus de 72 TLD dont .com et .fr sont signés (il y en a 310 au total). En France, depuis Avril 2011, les bureaux d'enregistrement peuvent demander à l'AFNIC que les noms de domaine soient sécurisés avec DNSSEC.


En tant que gestionnaires des résolveurs, les FAI jouent un rôle clé dans la mise en place d'un niveau de sécurité supplémentaire pour les internautes.


DNSSEC peut générer des problèmes de compatibilité avec les équipements réseau qui prennent en charge DNS. Les pare-feu, routeurs et autres matériels réseau doivent être compatibles avec DNSSEC. Le problème est que les paquets DNSSEC sont plus volumineux que les paquets DNS, limités à 512 octets. De plus, en raison des limites de taille de MTU, le protocole UDP ne peut pas toujours prendre en charge les paquets DNSSEC. Utiliser TCP alourdit considérablement le trafic. Certains périphériques ne prennent même pas en charge DNS sur TCP. Il y a donc une longue phase de tests au niveau matériel pour s'assurer du bon fonctionnement de DNSSEC.


Enfin Bind, le logiciel utilisé dans la majorité des serveurs DNS, peut prendre en charge DNSSEC en activant l'option dnssec-validation yes;. Les systèmes d'exploitation Microsoft Windows 7 et Windows Server 2008 R2 supportent DNSSEC.

Validation de DNSSEC

Se pose la question de l'endroit où doit se faire la validation DNSSEC, c'est-à-dire jusqu'où va la chaîne de confiance. À priori, il y a plusieurs possibilités pour le choix de l'endroit où faire la validation :

  1. Dans le résolveur DNS du FAI. Le problème est que si une attaque se produit entre le résolveur et la machine de l'utilisateur, l'apport de DNSSEC par rapport à DNS est nul. Cette menace est d'autant plus importante que la plupart des attaques ce font à ce niveau là.
  2. Sur l'ordinateur de l'utilisateur dans une application, comme son navigateur. Cela pourrait permettre d'afficher des messages d'avertissement et d'adapter son niveau de sécurité. Cependant, il n'existe pas encore d'API standard pour pouvoir adapter les applications à DNSSEC. De plus, cette solution risque d'être coûteuse en termes de trafic DNS puisqu'on n'utilise pas le cache du résolveur du FAI.


Conclusion


DNSSEC résout de nombreux problèmes de sécurité connus avec DNS, permettant ainsi de contribuer à une plus grande sécurisation d'internet. Cependant, la mise en place d'un tel protocole est lourd de changements, tant au niveau compatibilité qu'au niveau des ressources supplémentaires nécéssaires (on retrouve la même problématique que pour le déploiement d'IPv6).