Autres Fonctionnalités
Résolution Inverse : Adresse -> Nom
(cf. exemple dig n.8).
La résolution inverse consiste à retrouver un nom de machine à partir
d'une adresse IP (v4 ou v6).
Un premier schéma possible est l'utilisation de la requête DNS inverse IQUERY.
Il s'agit d'une requête contenant 0 Question et 1 Réponse
de la forme {any_name, IN, A, any_ttl, 157.159.100.1}.
Si le serveur interrogé connaît des RRs qui possèdent les mêmes RDATAs du même RR-type,
il fera alors une réponse contenant les Questions que
l'on aurait du poser dans une requête directe et les Réponses
correspondantes. Ce schéma ne permet toutefois pas un réel processus de
résolution, car il nécessite de deviner le serveur qui possède
l'information directe (ex : quel est le lien entre int-evry.fr. et
157.159. ?). De plus le IQUERY est optionnel dans le standard
RFC1035, et est devenu obsolète en 2002 avec la RFC3425.
L'autre schéma développé dans le DNS consiste à réaliser la résolution inverse
des adresses par une résolution directe appliquée à un nommage particulier
dans l'arbre DNS. On définit ainsi une règle de construction
qui associe un Nom de domaine conventionnel à chaque adresse IP. Les
Resource Records contiendront alors les noms de machines associés. La
difficulté principale réside dans le fait que la délégation DNS dans
la branche des adresses IP est fortement contrainte par le processus
d'allocation des adresses IP (...) et totalement indépendante du processus
de délédation des zones directes.
Dans le cas des adresses IPv4, le nom consiste à prendre en ordre
inverse la notation décimale pointée et à la rattacher au domaine
prédéfini .in-addr.arpa.. Cette structuration ne marche pas trop
mal pour les principes de délégation de domaine tant que l'on est sur
des réseaux IP avec les classes A, B ou C. Dans les autres cas, il existe
différentes adaptations possibles qui ont chacunes quelques défauts (cf. RFC2317).
Exemple : l'adresse "157.159.100.74" correspondra au nom de domaine
74.100.159.157.in-addr.arpa.
Ce nom aura un RR de type PTR dont la valeur renvoie vers un nom de machine
dans l'arbre DNS direct. On notera que cette opération n'est nullement bijective et
qu'il est courant d'avoir plusieurs noms pour une même adresse (mais 1 seul PTR) ou
plusieurs adresses pour un même nom.
74.100.159.157.in-addr.arpa. 172800 IN PTR ipv6-1.int-evry.fr.
zeratul.ipv6.int-evry.fr. 86400 IN A 157.159.100.74
ipv6-1.int-evry.fr. 172800 IN A 157.159.100.74
En terme de délégation DNS, le domaine 159.157.in-addr.arpa.
va naturellement à l'administrateur du réseau 157.159.0.0/16.
Ainsi l'INT gère les informations directes et inverses dans 2 domaines
DNS différents avec 2 délégations indépendantes : AFNIC pour fr.,
ARIN (puis RIPE à partir de 2004) pour 157.in-addr.arpa..
Le serveur maître des 2 zones est en pratique le même, ce qui facilite
le maintien de la cohérence entre la base directe et la base reverse (!).
Pour IPv6, on a le même type de mécanisme avec actuellement
plusieurs variantes de rattachement et de nommage. La branche de
rattachement standard pour les adresses IPv6 est .ip6.arpa.,
mais les premiers déploiements d'IPv6 utilisent aussi le rattachement
.ip6.int.. Le schéma basique de nommage consiste à prendre
en ordre inverse et en hexadécimal les 32 demi-octets de l'adresse IPv6.
Pour L'INT, la zone reverse IPv6 sera alors déléguée pas RENATER.
Exemple :
3.8.c.2.a.3.e.f.f.f.0.d.0.b.2.0.0.0.0.1.3.0.2.3.0.6.6.0.1.0.0.2.ip6.arpa. (
86400 IN PTR zeratul.ipv6.int-evry.fr. )
zeratul.ipv6.int-evry.fr. 86400 IN AAAA 2001:660:3203:1000:2b0:d0ff:fe3a:2c83
Un deuxième schéma, plus évolué a été proposé. Il introduit un nouveau
RR, le DNAME, qui généralise le CNAME; et utilise la notion de label binaire.
Ce mécanisme permet d'avoir une délégation des adresses à toute
position bit, il offre aussi la possibilité de mettre les informations
reverses dans la même zone que les informations directes et ceci sous
une forme plus compacte que le schéma basique.
Le gros défaut est que les extensions proposées sont pour le moment jugées trop
dangereuses par l'IAB pour le bon fonctionnement opérationnel du DNS. Pour l'usage du DNAME, cf. zone demo en annexe.
Wildcard
Le standard RFC1034 définit une forme très particulières de Resource
Records qui sont appelés wildcards. La sémantique de ces
wildcards est toutefois assez "étrange" et pour le moins
éloignée de l'intuition commune.
Il s'agit de RRs qui appartiennent à la base de données d'une zone DNS et
dont le premier label du Nom est uniquement le caractère * . Par exemple :
{*.int-evry.fr., 600, IN, TXT, "un wildcard"}
Le caractère * sert alors à synthétiser n'importe quel Nom de la zone
(à quelques "détails" près).
Pour une requête sur un Nom donné et si le wildcard s'applique,
la réponse est obtenue en remplaçant le * du Record par le Nom utilisé
dans la requête.
Quelques "Détails" :
- un wildcard ne s'applique pas, si la requête concerne
un Nom existant dans la zone et ceci de manière complètement
indépendante du type de RR. Sur l'exemple précédent, le wildcard ne
s'applique pas à www.int-evry.fr. car il existe un CNAME pour
ce nom. ducon.int-evry.fr. qui n'existe pas aurait une
information TXT mais pas www.int-evry.fr.
- le wildcard peut s'appliquer sur plusieurs niveaux de
labels et sous-labels. Ex: ducon.lajoie.int-evry.fr. aurait une
information TXT.
- le wildcard ne s'applique plus en dehors de la zone. Une
délégation de zone supprime l'effet du wildcard. Ex :
ducon.ipv6.int-evry.fr. n'aurait plus d'informations TXT puisque
ipv6 est une sous-zone.
- le wildcard n'apparaît jamais dans un cache
- ... cf. fin de zone demo en annexe ...
En pratique, on rencontre beaucoup d'implémentations de serveur DNS
non conformes et l'usage incorrect du wildcard est assez fréquent.
Le mieux est donc de ne pas utiliser de wildcard dans une zone,
sauf si l'on désire explicitement les effets de bord évoqués
précédemment.
Extensions de Sécurité, DNSSEC
La première spécification de DNSSEC dans le RFC2535, introduit
différentes extensions de sécurité nécessaires pour le système DNS. Ces
extensions visent soit à sécuriser le fonctionnement du DNS existant, soit
à offrir des services de sécurité à travers l'utilisation du DNS.
Dans la nouvelle spécification de DNSSEC (RFC4033, RFC4034, RFC4035),
appelé parfois DNSSEC-bis, une seule de ces extensions garde le label "DNSSEC", les
autres extensions continuant à exister de manière autonome.
Dans tous les cas, il s'agit d'extensions compatibles avec la spécification
actuelle du DNS, et dont le deploiement est possible sans perturbation du service DNS
existant.
1) Publication de clés publiques
Cette extension consiste à utiliser le DNS existant pour
enregistrer des clés cryptographiques publiques utilisables
dans un cadre de PKI. Techniquement simple, cela remplace avantageusement
le "allez voir ma clé publique sur ma page web"
mais cela reste toutefois assez léger en tant que PKI. La mise
en oeuvre de cette fonctionnalité nécessite uniquement de definir
de nouveaux types de RR pour contenir les clés publics.
Les RRs KEY ou DNSKEY sont aujourd'hui strictement
réservés à l'enregistrement de clés publiques à l'usage exclusif de DNSSEC.
Par contre, d'autres RR sont définis indépendement de DNSSEC et eventuellement
en fonction des applications utilisatrices de cryptographie à clés publiques. On
trouvera ainsi le RR CERT pour l'enregistrement de certificat X509,
le RR SSHFP pour l'enregistrement des empreintes des clés publiques du protocole SSH,
ou le RR IPSECKEY pour l'enregistrement du materiel cryptographique utilisé
par le protocole IPSEC.
2) Authentification des Transactions DNS
L'objectif est de signer les transactions entre (ou avec) des serveurs DNS
afin de sécuriser différentes opérations de contrôle du système DNS existant.
En premier lieu, cela concerne des opérations à fort risque d'intrusion comme
le dynamic update, ou le transfert de zones entre serveurs Authoritative.
On pourra aussi authentifier des transactions entre un client et son
serveur de résolution, mais cela n'offrira pas à lui seule une authentification
des données du DNS.
Deux mecanismes sont définis pour l'authentification des transactions. Le premier,
TSIG (RFC2845), utilise un secret partagé. Il est complété par un mecanisme
d'échange de clés appelé TKEY (RFC2930).
Le second mécanisme, appelé SIG(0) (RFC2931), utilise de la
cryptographie à clé publique. Dans les deux cas, la signature assure l'intégrité
du message DNS et l'authentification de l'auteur du message.
NB : Une autre solution est possible, IPSEC.
3) Authentification et Intégrité des Données du DNS
Cette fonctionnalité est le coeur de DNSSEC proprement dit.
Il va s'agir d'abord de signer toutes les données contenues dans les zones DNS afin d'en
authentifier l'origine (l'administrateur de la zone source) et d'en garantir
l'intégrité malgré la complexité et le nombre d'intervenants du processus de résolution DNS.
Pour completer cette premiere étape, DNSSEC doit aussi s'occuper de "l'intégrité des
données inexistantes", c'est à dire de permettre d'authentifier les réponses DNS négatives
(NXDOMAIN ou NODATA) au même titre que les réponses positives.
Avec ces deux premières étapes, toutes les réponses du DNS sont certifiées par
l'administrateur de la source des données. Il reste à savoir comment faire confiance
à cet administrateur pour chaque zone et comment certifier sa clé publique. DNSSEC
introduit pour cela, un dernier mécanisme qui va permettre d'utiliser la structure
d'arbre du DNS comme squelette d'une PKI (Public Key Infrastructure).
Ainsi chaque administrateur d'une zone DNS peut être certifié par l'administrateur
de sa zone parent dont il reçoit délégation d'un point de vue DNS comme PKI. A terme,
la racine du DNS devient l'autorité racine de certification de la PKI.
La mise en oeuvre de DNSSEC repose essentiellement sur quatre nouveaux RR :
DNSKEY, RRSIG, NSEC, DS.
- DNSKEY sert à enregistrer les clés publiques qui seront utilisées
par DNSSEC pour signer les informations. Différents algorithmes cryptographiques
sont autorisés avec des tailles variables de clés. Dans l'utilisation standard,
on aura deux RRs DNSKEY associés au nom d'une zone. Le premier, appelé ZSK
Zone Signing Key, sert à signer chaque RR de la zone. Il est géré
de manière autonome par l'administrateur de la zone et peut donc changer souvent.
Le second, appelé KSK Key Signing Key, ne sert qu'a signer
les DNSKEY de la zone et donc la ZSK. La clé KSK
sera par contre certifiée par l'administrateur de la zone parent. Ce processus
de signature et de certification à deux étages permet de réaliser un bon compromis
entre le besoin d'autonomie et de réactivité au niveau de la gestion d'une zone et
la difficulté de maintenir la coherence de la délégation DNS entre des administrateurs
de zones différentes.
- RRSIG réalise la signature cryptographique d'un RRset. Il contiendra
la réference au RRset signé et à la clé DNSKEY utilisée pour signer. Il
contient aussi une durée de validité de la signature. Dans une zone, on trouvera
normalement un RRSIG utilisant la ZSK pour chaque RRset de la zone.
On aura de plus un RRSIG utilisant la KSK mais uniquement pour le
RRset de type DNSKEY (?kékidi?: cf. exemple en annexe).
- NSEC Next Sec va permettre d'authentifier les données inexistantes.
DNSSEC définit un ordre lexicographique sur les noms de domaine. Pour chaque nom
de domaine dans un zone DNS, on rajoute un RR NSEC qui contiendra
d'une part la liste des TYPEs de RR existants pour ce nom, et d'autre part le prochain
nom de domain existant dans la zone. Par complementarité l'ensemble des NSEC,
identifie les types de RR inexistants ou les noms inexistants. L'authentification
des réponses négatives sera alors réalisés par la présence d'un RRSIG pour
signer chaque NSEC
- DS Delegation Signer sert à certifier la délégation de zone.
Pour un nom de zone donnée, ce record n'existe que dans la zone parent, et
contiendra une empreinte (digest) de la KSK de la zone enfant. Il sera
evidement signé dans la zone parent par un RRSIG au même titre que les autres RRs.
Pour un RR donnant l'adresse IPv4 de diamant.int-evry.fr., la chaine de certification
DNSSEC se décompose donc en :
- diamant.int-evry.fr. IN A ? : la données proprement dites
- diamant.int-evry.fr. IN RRSIG ? : les signatures par la ZSK des différents RR "diamant",
on choisit celle signant le type A
- int-evry.fr. IN DNSKEY ? : la ZSK et la KSK, ici on prend la ZSK
- int-evry.fr. IN RRSIG ? : on choisit la signature de la ZSK par la KSK
- int-evry.fr. IN DNSKEY ? : deja fait, mais ici on prend la KSK
- int-evry.fr. IN DS ? !ATTENTION! requête dans la zone fr. : l'empreinte de
la KSK dans la zone parent
- int-evry.fr. IN RRSIG ? !toujours dans fr. : la signature du DS.
- fr. IN DNSKEY ? : la ZSK signant le DS
- .. on itére jusqu'a obtenir une clé de confiance dans un DNSKEY (qui sera autosigné si besoin). on verifie alors la validité cryptographique de chaque étape.
Conclusion : Assez lourd techniquement, et gourmand en terme de performance.
(cf. zone signée en annexe)
4) Quoi d'autres encore ?
On pourra se reporter au RFC3833 pour l'analyse des risques de sécurité dans le DNS.
Il y a essentiellement deux problèmes de sécurité qui ne sont pas couvert par
les extensions précédentes. Le premier touche aux dénis de service pour lesquel DNSSEC
va plutot aggraver la situation du fait de la charge induite par le traitement cryptographique.
Le deuxième problème concerne la confidentialité des données. Sur le principe, cela
ne concerne pas le DNS, qui revendique le caractère public des données. Par contre,
la définition du NSEC par DNSSEC ajoute une nouvelle source de "non confidentialité"
par rapport au fonctionnement de base du DNS. Il s'agit de la possibilité de "compilation"
des données d'une zone, c'est-à-dire par exemple d'obtenir l'ensemble des noms
de machines d'une zone. Cette compilation était difficile à la base, car une requête DNS
nécessite de connaitre un nom pour avoir une information. Avec DNSSEC, cette compilation
devient triviale puisqu'il suffit de chercher itérativement les records NSEC
qui chainent l'ensemble des noms de la zone. Actuellement differentes propositions
sont faîtes pour un nouveau NSEC ("NSEC3") ou d'autres mécanismes d'authentification
des réponses négatives qui ne contiennent pas d'information sur les noms existants.
Autres Extensions du DNS par rapport au Standard (RFC1034, RFC1035)
Load Balancing(RFC1794)
Le Load Balancing va consister dans les cas où il existe
plusieurs RRs avec le même nom et le même type (RRset) a
répartir de façon équilibrée l'usage des différents RRs. Il s'agit d'une
clarification de la spécification initiale qui est largement implantée.
Pour forcer la répartition (vis à vis de clients fumistes), la RFC1794
préconise d'utiliser au niveau des serveurs un mécanisme de tourniquet
(round-robin) qui consiste à faire une rotation du RRset à
chaque utilisation. (cf. exemple dig n.9).
Transfert Incremental (RFC1995)
Optimisation du transfert de ZONE (AXFR) qui consiste à ne transférer
que les données modifiées d'une zone par rapport à un numéro de série
donné. On définit pour cela, un pseudo-type IXFR.
Cette extension existe largement dans les implémentations mais
est très peu utilisée d'un point de vue opérationnel car elle
nécessite une journalisation lourde de la part du serveur maître. Sans
doute plus utilisée en conjonction avec la mise à jour dynamique.
Notification (RFC1996)
Amélioration du maintien de cohérence d'une base de zone. En cas
de modification de la base, un serveur authoritative envoie aux serveurs de
la zone qu'il connaît (RR NS de la zone), un message DNS de
type NOTIFY. Celui-ci contient le SOA de la zone. Un serveur secondaire
qui reçoit ce message doit a priori se dire que le numéro de série a
changé et déclenchera "spontanément" un refresh de la zone (comme à
l'expiration du temporisateur refresh). Les secondaires doivent aussi
générer le NOTIFY à chaque transfert de la zone.
Cette extension est largement opérationnelle.
Negative Cache(RFC2308)
Ceci consiste a rajouter dans les Caches, les réponses négatives
du type "il n'y a pas de réponses" (NXDOMAIN ou NODATA). Le dernier TTL
(appelé "minimum" dans la RFC1035) dans un SOA est associé à ce
mécanisme et s'appelle le Negative Cache TTL. Cette extension
est assez largement prise en compte par les serveurs mais beaucoup
moins par les administrateurs lors de la définition de leur zone.
DNS Dynamic Update (RFC2136,RFC3007)
Le DNS prévoit à l'origine, uniquement une maintenance "manuelle" des
bases de Zone. Le Dynamic Update consiste à rajouter dans le
protocole DNS la possibilité d'avoir des requêtes d'écriture sur la base
DNS. La motivation est très liée à l'utilisation de DHCP, à la
mobilité ou à la renumérotation dans le cadre IPv6. Facile à intégrer
sur le plan syntaxique, cette extension pose énormément de problèmes
pratiques d'un point de vue sécurité (gestion de droit d'accès et authentification)
et aussi des problèmes classiques de maintien de cohérence de la base (dynamicité trop importante). Il nécessite de plus une journalisation lourde de la part du serveur.
Mécanisme d'extensibilité du DNS (EDNS0) (RFC2671)
Adaptation du format de message DNS pour pouvoir plus facilement
intégrer des extensions au protocole DNS en s'affranchissant en
particulier des contraintes de taille de message, ou format des
labels. Un pseudo-type OPT est défini à cet effet, le codage
des labels est de plus étendu...
Internationalisation (IDN) (RFC3490,3491,3492..)
Du plaisir de mettre des caractères japonais dans les labels!!!
Enormément de propositions à l'IETF et de pressions politiques
du monde extérieur, mais des réserves importantes de l'IAB sur
le déploiement opérationnel.
Intégration d'IPv6 (RFC3596)
L'enregistrement des adresses IPv6 dans le DNS est réalisé par un RR AAAA.
Ce Record est similaire au RR A pour IPv4 et s'utilise
dans les mêmes conditions, par exemple dans le cas de la GLUE.
Le reverse addressing IPv6 est réalisé par une branche conventionnelle
.ip6.arpa. de manière similaire au cas IPv4.
Un autre schéma plus évolué, reposant sur un RR A6 et sur le RR DNAME,
a été proposé. Il est aujourd'hui placé à l'état experimental compte tenu des problèmes
possibles engendrés par l'usage du DNAME. (RFC2874,RFC3363,RFC3364)
Authentification des transactions DNS (RFC2845,2930,2931)
Initialement incluse dans DNSSEC, cette fonctionnalité est maintenant spécifiée
de manière indépendante de DNSSEC-bis. Le contenu a été décrit précedement.
DNSSEC (RFC4033,4034,4035)
Appelé aussi "DNSSEC bis" par rapport à la premiere définition de DNSSEC dans
le RFC2535. Le contenu a été décrit précedement.
Nouveaux Types de RR
Quelques RRs récents ou à venir : IPSECKEY, SSHFP, DHCID (infos DHCP),...
cf. section Types de RR
Encore d'autres propositions (cf. en annexe index des RFCs)
Extensions hors standardisation
...en construction (future)
- Acces list , sort list, point de vue ...
- Split DNS et Firewall ...
- server-ID (dig ANY CH version.bind.) ...
La plupart des extensions spécifiques proposées par des logiciels serveurs
portent sur des fonctions de confidentialité ou sur le fait d'offrir des réponses
différentes du serveur DNS en fonction de l'origine de la question. Ces extensions
peuvent être utiles pour des problèmes particuliers, mais sont du point de vue de la
standardisation contraires au principe fondamental de publicité des informations du DNS.
...
Conclusions ?
Globalement beaucoup trop d'extensions pour un système qui pose
aujourd'hui de plus en plus de problème de fonctionnement opérationnel
sur l'Internet. La position actuelle de l'IESG et de l'IAB est de ne
surtout pas se presser de "surcharger le baudet", tout en intégrant
bien sur les priorités incontournables liées à la sécurité, à la
mobilité, au déploiement d'IPv6...
"The DNS Today Are we Overloading the Saddlebags on an Old Horse?", Randy
Bush, IETF45, San-diego 2000.