Ajout de "T" enregistrements aux noms de domaine (Idée qui m'est venue dans un rêve)

Au niveau du domaine, c'est déjà parfaitement possible - il suffit de mettre des enregistrements NAPTR de style ENUM (ou alternativement SRV) dans votre fichier de zone.

La raison d'utiliser NAPTR plutôt que SRV est que SRV n'est défini que pour un ensemble limité de services de communication. Les enregistrements NAPTR, en revanche, peuvent être utilisés pour réécrire n'importe quel nom de domaine en URI. Si l'URI résultante est au format sip:, alors vous utilisez les enregistrements SRV (pour _sip._udp.example.com) pour trouver la passerelle SIP de example.com.

Ce qui n'a pas encore été défini à l'IETF (bien que cela ait été discuté), c'est comment étendre ceci pour avoir des enregistrements NAPTR différents pour chaque utilisateur individuel au sein du domaine spécifié (c'est-à-dire localpart@example.com).

Vous pourriez simplement avoir localpart.example.com dans le DNS, mais il y a des préoccupations quant à la manière dont cela pourrait être géré, ainsi que des conflits potentiels avec de vrais sous-domaines que vous pourriez vouloir avoir. Par exemple, que faites-vous si la convention du site est que localpart sont vos initiales mais que vos initiales sont 'www'?

Cela pourrait être résolu assez facilement en utilisant localpart._name.example.com mais je sais, d'après les discussions que j'ai eues avec l'un des responsables du groupe DNSOP de l'IETF, qu'il y a une certaine résistance aux tendances d'utilisation de DNS comme une base de données distribuée générique et à l'utilisation croissante d'étiquettes à préfixe de soulignement.

Cela est déjà fait pour la VoIP, voir par exemple http://www.nominet.org.uk/enum/

L'opposé de votre idée existe déjà :

• Mapping de numéro de téléphone
• RFC3761

La réponse à la question n°1 est "écrire un RFC, le soumettre à l'IETF". C'est un processus long, mais si vous réussissez à intéresser quelques personnes, ce serait une excellente expérience, même si elle n'est pas acceptée :)