Mon blog

Lorsqu'on a une machine avec une adresse IP variable, et qu'on veut la joindre depuis l'extérieur (pour se connecter à sa webcam, ou bien à un serveur HTTP qu'elle héberge ou bien pour tout autre raison), il est courant d'utiliser une mise à jour dynamique du DNS. Après tout, c'est bien le but principal du DNS, fournir un identificateur stable, le nom de domaine. Ce RFC explique les pièges et les problèmes lorsqu'on est connecté via un système à fort partage d'adresses IP (comme DS-Lite), et comment on peut utiliser PCP dans ce contexte.

Il existe plusieurs fournisseurs qui hébergent votre nom de domaine et acceptent des requêtes de mise à jour dynamiques, via un formulaire Web ou bien via une API. On peut avoir une idée du nombre de tels fournisseurs en regardant la liste de DNSlookup. Il n'y a pas à proprement parler de norme pour cette demande de mise à jour, à part le RFC 2136 qui ne semble guère utilisé par ces fournisseurs (comme le note à juste titre le Wikipédia anglophone, « DNS dynamique » désigne en fait deux choses différentes, la mise à jour par le RFC 2136 et le fait de mettre à jour la base sans édition manuelle). Le fournisseur doit avoir une interface qui assure en outre un minimum de sécurité (cf. la section 4 de notre RFC) par exemple en utilisant HTTPS + une authentification du client. Une utilisation courante est que le routeur ou l'ordinateur de l'utilisateur détecte une nouvelle adresse IP, et il notifie l'hébergeur de cette nouvelle adresse. Ce dernier met alors à jour le DNS (via le RFC 2136 ou via toute autre méthode).

Mais, aujourd'hui, de plus en plus d'utilisateurs sont coincés derrière un système à partage d'adresses massif (cf. RFC 6888), où on n'a plus une seule adresse IP publique à la maison. Pour être joint de l'extérieur, il faut communiquer non seulement son adresse IP mais également un port. Plus question de faire tourner son serveur Web sur le port 80, celui-ci ne peut pas être partagé. En outre, il faudra évidemment indiquer au réseau que le port en question devra être connecté au port sur lequel écoute le serveur de l'utilisateur (ce qui se fait en UPnP ou, plus récemment, en PCP, ce dernier étant normalisé dans le RFC 6887).

Les nombreux problèmes posés par le partage d'adresses sont bien connus (RFC 6269). Parmi eux :

• On ne peut plus compter sur les ports « bien connus » (comme 80 pour HTTP), il faut pouvoir indiquer aux clients un port explicite,
• Il faut un mécanisme pour configurer les connexions entrantes (justement ce que fait PCP),
• Il faut pouvoir détecter des changements d'adresses IP qui se passent très loin de l'utilisateur, dans l'AFTR de DS-Lite (RFC 6333) ou dans le routeur CGN pour NAT444.

À noter que, pour prévenir le monde extérieur du couple {adresse, port} à contacter (problème connu sous le nom de « problème du rendez-vous »), on utilise souvent aujourd'hui des techniques non-standard, spécifiques à une application particulière (cela se fait souvent dans le monde du jeu en ligne) ou spécifiques à un protocole donné (SIP va utiliser un SIP proxy, section 16 du RFC 3261).

Voyons donc les trois problèmes à résoudre et les solutions possibles (section 2 du RFC) :

• Pour indiquer le port, deux méthodes, utiliser des URI qui permettent d'inclure le port, comme le permet HTTP (http://www.example.net:5318/foo/bar), ou utiliser des enregistrement DNS SRV (RFC 2782). La seconde méthode est plus propre, car invisible à l'utilisateur (et elle offre d'autres possibilités), et elle n'oblige pas les applications à utiliser des URI. Malheureusement, elle est anormalement peu déployée dans les applications (par exemple les navigateurs Web).
• Pour configurer les connexions entrantes, on se sert de PCP (RFC 6887), dont c'est justement le but principal.
• Pour détecter les changements d'adresses, on va encore se servir de PCP. Une des solutions est de faire des requêtes PCP de type MAP régulièrement, demandant une correspondance {adresse externe -> adresse interne} de courte durée et de voir quelle est l'adresse IP retournée. Une autre solution, moins bavarde, est de juste vérifier la table locale du client PCP, notant les changements d'adresses, et de ne faire une requête MAP que s'il n'y a pas de correspondance dans la table locale. Dans les deux cas, lorsqu'on détecte un changement d'adresse, on met à jour le DNS par les moyens classiques (le client PCP, routeur ou ordinateur, est également client du service de DNS dynamique).

La section 3 couvre quelques détails pratiques de déploiement. Par exemple, le RFC couvre le cas où le service de « DNS dynamique » ne fait pas de DNS du tout mais publie sa propre adresse dans le DNS, redirigeant ensuite les clients vers le bon serveur (via une réponse 301 en HTTP, ce qui se nomme parfois URL forwarding). Ces serveurs devront modifier leur API pour que le client puisse indiquer le port en plus de l'adresse IP (aujourd'hui, ils ont souvent 80 câblé en dur). Dans un contexte différent (protocole ne permettant pas les redirections), on peut envisager d'utiliser la technique de découverte du RFC 6763.

Pour résumer par des remarques personnelles, tout cela est plutôt embrouillé, et on n'est pas tiré d'affaire, d'autant plus que PCP n'est pas tellement déployé aujourd'hui.