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" :

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.

Pour un RR donnant l'adresse IPv4 de diamant.int-evry.fr., la chaine de certification DNSSEC se décompose donc en :

  1. diamant.int-evry.fr. IN A ? : la données proprement dites
  2. diamant.int-evry.fr. IN RRSIG ? : les signatures par la ZSK des différents RR "diamant", on choisit celle signant le type A
  3. int-evry.fr. IN DNSKEY ? : la ZSK et la KSK, ici on prend la ZSK
  4. int-evry.fr. IN RRSIG ? : on choisit la signature de la ZSK par la KSK
  5. int-evry.fr. IN DNSKEY ? : deja fait, mais ici on prend la KSK
  6. int-evry.fr. IN DS ? !ATTENTION! requête dans la zone fr. : l'empreinte de la KSK dans la zone parent
  7. int-evry.fr. IN RRSIG ? !toujours dans fr. : la signature du DS.
  8. fr. IN DNSKEY ? : la ZSK signant le DS
  9. .. 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) 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.