Système de noms de domaine/Extensions

Système de noms de domaine

• Le modèle hiérarchique
• Mise en œuvre
• Extensions
• Exercices
• Annexes

Les problèmes de sécurité et DNSSEC

Attaques spécifiques au DNS

Les serveurs DNS sont susceptible de subir les attaques classiques à tous serveurs. Mais ce système peut subir des attaques spécifiques que nous allons détailler ici.

Attaques de type DoS sur les serveurs root

Il s'agit d'une attaque de type DoS sur l'ensemble des serveurs pour bloquer complètement le système DNS. Une attaque de ce type a eu lieu le 21/10/2002, pendant laquelle 7 serveurs sur les 13 sont tombés. Cependant cette attaque n'a pas eu d'impact réel sur les utilisateurs.

La sécurisation du DNS avec TSIG et DNSSEC

Rappel sur la cryptographie

La sécurisation du DNS va se baser sur la cryptographie.

Les services de sécurité sont :

• la confidentialité
• l'intégrité
• l'authentification
• la non répudiation

Le RFC 3833 fait une analyse des menaces concernant le DNS et explique ce DNSSEC tente d'améliorer. Dans le cadre du DNS avec des données publiques, les services utiles sont l'authentification et l'intégrité des données :

• L'authenticité : la donnée est-elle publiée par l'entité autoritaire
• L'intégrité : la donnée est-elle conforme à celle publiée

La cryptographie va permettre de signer des messages ou de les crypter. Il existe deux types d'algorithme :

• des algorithmes à clés secrètes ou symétriques
• des algorithmes à clés publiques ou asymétrique

Dans les algorithmes à clés secrètes, la clé de chiffrement ou de signature est la même que la clé de déchiffrement ou de vérification. Dans ce cas, on utilise un secret partagé. Il faut noter que la cryptographie symétrique est plus rapide que l'asymétrique.

Dans le cas des algorithmes asymétrique la clé de chiffrement est publique tandis que la clé de déchiffrement est gardée secrète, ou plutôt la clé de signature est secrète tandis que la clé de vérification est publique. Un exemple connu d'algorithme asymétrique est RSA.

Enfin, un dernier point utile pour la notion de signature est la notion de fonctions de hachage. Elles permettent l’obtention d'une empreinte numérique de taille fixe à partir d'un message de taille variable. Un fonction de hachage utilisable dans la sécurité est celle qui engendre de faibles collisions (empreinte identique pour des messages distincts) et qui est en sens unique (difficulté de retrouver le message d'origine).

TSIG et SIG(0)

TSIG = transaction Signature (RFC 2845). La liste des algorithmes utilisés par TSIG est maintenue par l'IANIA http://www.iana.org/assignments/tsig-algorithm-names

SIG(0)

NTP

TSIG et SIG0 signent avec un tampon de temps. Donc une synchronisation par NTP est nécessaire. Voir la présentation de NTP http://alexandre.alapetite.net/iup-gmi/ntp/ et http://fr.wikipedia.org/wiki/Network_Time_Protocol.

Une version simplifiée de NTP existe. Il s'agit de SNTP qui est notamment utilisé par Windows pour se synchroniser avec le "temps internet".

DNSSEC

DNSSEC est un ensemble d'extensions pour sécuriser le système DNS.

le projet initial (2004) de mise en place de l'infrastructure DNSSEC en France est ici : http://www.idsa.prd.fr

document de présentation de dnssec : http://ws.edu.isoc.org/workshops/2005/ccTLD-Dakar/jour4/dnssec-dakar-francais-updated.pdf

IDN

Noms de domaines dits internationaux. L'implémentation actuelle est IDNA (International Domain Name for Application). Le nom de domaine enregistré dans le dns reste écrit avec les caractères autorisés par le DNS (une partie de l'ASCII). Les applications interprètent ce nom de domaine pour l'afficher les bons caractères. Pour savoir que le nom est un IDN, il commence par xn--. C'est pourquoi, il est interdit dans la plupart des cas d'enregistrer des noms de domaines commençant par cette chaîne.

Attention les IDN concernent également les adresses mails. Les premiers tests datent de 1998. Mais en pratique les IDN avancent lentement.

L'AFNIC n'autorise pas d'enregistrement d'IDN.

Notion de "babel name"

Exemple xn--NomDuMarqueConnue.com peut faire croire que la marque détient le domaine, alors que le préfixe laisserait supposer le contraire.

Les IDN et les TLD

Deux types d'IDN :

• IDN hybride idn.ascii
• IDN complet idn.idn (en fait n'existe pas encore)

Alternative aux IDN

Certains acteurs considèrent que l'IDN n'est pas satisfaisant pour permettre à accès multilingue à l'Internet. La société Netpia, http://e.netpia.com propose par exemple un système de serveurs de mots clefs, similaires au des pages jaunes ou des moteurs de recherche. Ce système est appelé "Native Language Internet Address". Les serveurs servent une zone géographique donnée utilisant la même langue ou le même système d'écriture. L'intégration du système se fait soit au niveau du navigateur (plug-in) soit au niveau du FAI (ou par la modification du serveur DNS). Le système est parti de Corée, puis s'est entendu à d'autres pays comme le Japon, pour toucher actuellement 95 pays, selon la société qui commercialise le système.

Dans ce modèle, on ajoute au dessus du DNS un système non hiérarchique. Il existe une ébauche de RFC datant de 2001, mais apparemment pas de RFC : http://tools.ietf.org/html/draft-jhbae-nliasa-00 . Attention, cette ébauche ne peut pas servir de référence. Simplement, on monte en abstraction et on se rapproche des utilisateurs finaux en passant successivement :

• des adresses IP,
• des noms de domaine,
• des noms de domaine partiellement internationalisés,
• des noms de domaine complètement internationalisés (avec TLD internationalisés),
• Native Language Internet Address ou NLIA (mots clés internationalisés).

Il imagine un système de serveurs NLIA fonctionnant à côtés des serveurs DNS. Une requête devrait comporter trois éléments :

• Native Language Internet Address,
• Informations concernant l'application,
• Informations concernant la langue.

La réponse dépend de l'application concernée, exemple demande sur le mot Netpia (exemple pris dans l'ébauche de RFC) :

• Navigateur web, www.netpia.com
• client news, news.netpia.com
• client mail, webmaster@netpia.com
• client telnet, telnet.netpia.com
• client FTP, ftp.netpia.com
• Téléphone, 82 2 3665 0123

Le serveur DNS de Neptia a pour adresse IP 211.106.67.202. Certaines réponses DNS sur ce serveur sont assez surprenantes comme le montre cet exemple.

dig @211.106.67.202 A ibm.

; <<>> DiG 9.3.2 <<>> @211.106.67.202 A ibm.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 225
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;ibm. IN A

;; ANSWER SECTION:
ibm. 86400 IN A 211.106.67.202

;; AUTHORITY SECTION:
realname. 86400 IN NS update-kt.netpia.com.

;; ADDITIONAL SECTION:
update-kt.netpia.com. 102 IN A 211.106.67.221

;; Query time: 2265 msec
;; SERVER: 211.106.67.202#53(211.106.67.202)
;; WHEN: Sun Jun 25 15:46:25 2006
;; MSG SIZE rcvd: 95

ENUM

ENUM permet de placer les numéros de téléphone dans le DNS. Après un certaine activité au cours des années 2004 2005, les projets liés à ENUM semblent diminuer.

Le projet français Numerobis

Projet terminé ? Il a eu lieu entre 2002 et 2004.

IPv6 et le DNS

Ajout des types d'enregistrement AAAA et A6.

IPv6 commence à avancer dans de nombreux TLD. Pour le constater, on peut regarder les nombreux enregistrements de type AAAA dans le fichier root.zone disponible sur le site du ftp de l'internic ftp://rs.internic.net/domain. On trouve environ une vingtaine de TLD en IPv6 (AT BE BIZ BR CH CN DE FR IE IT JP LU KR NET ORG PL PR PT SE TH TN TW UK).

La sécurisation de la messagerie électronique

Le courrier électronique est peu sécurisé. Les RFC 2821 et RFC 2822 qui le spécifient ne permettent pas une authentification même faible de l’émetteur. Ceci explique les nombreuses manipulations sur les en-têtes des mails.

De nombreux RFC récentes proposent des mécanismes d'authentification faible du courrier électronique. Concrètement, il indique comment définir les adresses IP ayant le droit d'émettre des mails au nom du nom de domaine. donc on authentifie uniquement le domaine et non l’émetteur complet. Il existe d'autres mécanismes de sécurisation de la messagerie électronique qui sortent du cadre du DNS (exemple S/MIME). Deux propositions concurrentes existent : Sender ID et SPF. Ils utilisent tous les deux l'enregistrement de type TXT sur le domaine.

Sender ID

RFC 4408. Le contenu de l'enregistrement TXT commence par "spf2.0/".

SPF

RFC 4406. Le contenu de l'enregistrement TXT commence par "spf1".

Sender Policy Framework est une norme très utilisée pour réduire le spam.

Exemples d'application

AOL a mis en place SPF et Sender ID.

dig TXT aol.com

; <<>> DiG 9.3.2 <<>> TXT aol.com
; (10 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 684
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 2

;; QUESTION SECTION:
;aol.com. IN TXT

;; ANSWER SECTION:
aol.com. 300 IN TXT "v=spf1 ip4:152.163.225.0/24 ip4
:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24
 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"
aol.com. 300 IN TXT "spf2.0/pra ip4:152.163.225.0/24
 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.
0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

;; AUTHORITY SECTION:
aol.com. 1071 IN NS dns-01.ns.aol.com.
aol.com. 1071 IN NS dns-02.ns.aol.com.
aol.com. 1071 IN NS dns-06.ns.aol.com.
aol.com. 1071 IN NS dns-07.ns.aol.com.

;; ADDITIONAL SECTION:
dns-01.ns.aol.com. 15742 IN A 64.12.51.132
dns-02.ns.aol.com. 15742 IN A 205.188.157.232

;; Query time: 31 msec
;; WHEN: Thu Jun 29 15:42:53 2006
;; MSG SIZE rcvd: 512

Microsoft a mis en place SPF.

dig TXT microsoft.com

; <<>> DiG 9.3.2 <<>> TXT microsoft.com
; (10 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1548
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com. IN TXT

;; ANSWER SECTION:
microsoft.com. 3600 IN TXT "v=spf1 mx include:_spf-a.micros
oft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com ~all"

;; AUTHORITY SECTION:
microsoft.com. 98386 IN NS ns1.msft.net.
microsoft.com. 98386 IN NS ns2.msft.net.
microsoft.com. 98386 IN NS ns3.msft.net.
microsoft.com. 98386 IN NS ns4.msft.net.
microsoft.com. 98386 IN NS ns5.msft.net.

;; ADDITIONAL SECTION:
ns1.msft.net. 92291 IN A 207.68.160.190
ns2.msft.net. 162045 IN A 65.54.240.126
ns3.msft.net. 92291 IN A 213.199.144.151
ns4.msft.net. 92291 IN A 207.46.66.126
ns5.msft.net. 162045 IN A 65.55.238.126

;; Query time: 46 msec
;; WHEN: Thu Jun 29 15:47:14 2006
;; MSG SIZE rcvd: 323

Et il est obligatoire d'en avoir pour pouvoir écrire à ses domaines : Hotmail, Outlook et Live. Éventuellement les emails doivent contenir une signature DKIM correspondant aux DNS.

 Si les règles IN TXT sont invisibles (ex : avec dig -t txt domaine.com) après le TTL, il suffit de retirer la règle posant problème (IN SPF).