Résumé

  • ENUM transforme un numéro E.164 en clé DNS, puis applique des règles NAPTR jusqu’à produire un URI : il découvre un contact de service possible, il ne constate pas une communication aboutie.
  • Un dossier d’appel fiable conserve séparément le contrôle du numéro, la validation DNSSEC, le NAPTR choisi, l’URI obtenu, l’identité du pair, la signalisation et l’observation du média bidirectionnel.

Un tableau de bord reçoit un numéro E.164 et affiche « succès ». La ponctuation a été retirée, les chiffres ont été inversés pour former un nom sous e164.arpa, le jeu de NAPTR est arrivé avec une validation DNSSEC correcte et le client a construit un URI SIP. Après cela, le service a pu refuser l’invitation, viser une ancienne adresse, ne jamais faire sonner le terminal ou établir une signalisation sans audio dans les deux sens.

La réponse ENUM n’était pas nécessairement erronée. C’est le libellé du tableau de bord qui l’était : une découverte d’adresse avait été promue en communication réussie.

Patrik Fältström et Michael Mealling ont cosigné la RFC 3761, publiée sur la voie des normes en 2004. La RFC 6116, de Scott Bradner, Lawrence Conroy et Kazunori Fujiwara, l’a remplacée en 2011. Elle se présente comme une mise à jour du texte édité par Fältström et Mealling. Cette généalogie interdit une attribution solitaire : ENUM est une construction collective, corrigée par l’expérience d’interopérabilité.

Son apport est précis. Une application peut partir d’un numéro téléphonique et découvrir un URI grâce au DNS. Le DNS ne devient pour autant ni commutateur téléphonique, ni autorité d’attribution des numéros, ni témoin d’une conversation humaine.

Du numéro à la clé, pas du numéro à la personne

La RFC 6116 commence par l’Application Unique String. Un numéro E.164 international perd ses séparateurs visuels, mais conserve son signe plus. La première règle connue retire ensuite ce signe, inverse les chiffres, insère des points et ajoute .e164.arpa.. Ce calcul donne une clé DNS sans ambiguïté pour l’application ENUM.

Il ne démontre pas que l’émetteur de la requête est autorisé, ni que le titulaire actuel contrôle toujours le numéro. Un portage a pu intervenir. Une revalidation peut être en retard. Une application peut recevoir un numéro copié depuis une source qui n’a aucune autorité. La justesse de la transformation ne répare aucune de ces lacunes.

La requête demande des enregistrements NAPTR. Une règle terminale produit le résultat attendu ; une règle non terminale désigne un nouveau nom et provoque une autre interrogation. À la fin de la boucle DDDS, le résultat attendu est un URI absolu. ENUM s’arrête donc sur une expression d’adresse, avant l’événement « appel ».

La RFC 3403 décrit la mécanique. ORDER ordonne les groupes de règles. PREFERENCE départage les candidats d’un même ordre. FLAGS, SERVICES, REGEXP et REPLACEMENT déterminent l’interprétation et la réécriture. Ne garder que l’URI final revient à effacer la raison de sa sélection.

Une règle unique ne supprime pas les choix

La formule « l’algorithme ENUM renvoie toujours une seule règle » peut tromper une interface. Elle décrit la sortie de l’algorithme, pas le succès d’une opération téléphonique. Une application peut connaître certains Enumservices et pas d’autres, écarter un enregistrement privé ou mal formé, présenter plusieurs URL à une personne, puis laisser celle-ci choisir.

Les clients doivent trier un RRSet par ORDER, puis par PREFERENCE. En cas d’égalité, l’ordre d’arrivée dans le paquet DNS ne forme pas une préférence durable. Deux résolveurs peuvent restituer les mêmes données dans un ordre différent sans que l’un d’eux falsifie la zone.

La préférence du titulaire n’est pas non plus un ordre exécutoire. La RFC 6116 recommande de ne publier que des contacts que le registrant est prêt à prendre en charge, car même le contact le moins favorisé peut être choisi. Cela ne garantit ni sa disponibilité au moment de la requête, ni la prise en charge du schéma par le client, ni l’admission de l’appel par le fournisseur suivant.

Une trace utile garde donc le RRSet complet, les TTL, chaque ordre et préférence, le service déclaré, les drapeaux, la règle de réécriture et les capacités du client. Elle indique pourquoi chaque candidat a été retenu, ignoré ou rejeté. Sans ce dénominateur, l’URI final ne permet pas de contrôler la décision.

Le droit sur le numéro se vérifie en amont

Un nom ENUM n’est pas attribué comme un domaine ordinaire. Il dépend d’une attribution E.164. La RFC 4725 sépare précisément l’entité qui attribue le numéro, son assignee, le registrant ENUM, l’entité de validation, le registre, le registrar, le prestataire DNS et le fournisseur d’application.

L’assignee détient le droit d’utiliser le numéro. L’entité de validation vérifie que le registrant est cet assignee ou agit avec son autorisation. Le contrôle initial ne suffit pas pour toute la durée de vie : le document prévoit une validation récurrente et la révocation de la délégation lorsque l’attribution ou le droit change.

Cette provenance n’est pas incluse magiquement dans chaque réponse NAPTR. Un résolveur peut vérifier la signature de données publiées sans connaître la transaction de portage, la méthode de validation ou la décision locale qui les a précédées. « Le nom existe » et « cette personne ou organisation contrôle encore le numéro maintenant » ne sont pas la même affirmation.

La nuance évite aussi des accusations hâtives. Un contact dépassé peut provenir d’un cache dont le TTL n’est pas écoulé, de mises à jour non synchronisées ou d’une révocation tardive. Le dossier doit joindre la version de l’attribution, l’instant et la méthode de validation, son expiration, la modification de délégation et les octets effectivement vus par le client.

DNSSEC s’arrête avant l’identité du service

La RFC 6116 accorde à DNSSEC une fonction importante : authentifier les données DNS et réduire plusieurs attaques contre ENUM. Elle refuse cependant le raccourci suivant. Une adresse obtenue par une recherche ENUM validée par DNSSEC ne prouve pas que l’entité contactée est le pair attendu.

Le service doit authentifier cette entité pendant sa propre phase d’établissement. Les données d’adresse ou d’identité découvertes hors du service ne remplacent pas ce contrôle. Une signature valide répond à la question « ces données appartiennent-elles à la chaîne DNS signée ? », pas à « le logiciel qui répond à cette adresse est-il celui auquel l’appelant voulait parler ? ».

Le cache ajoute une dimension temporelle. Dans l’exemple SIP de la RFC, l’URI issu d’ENUM déclenche d’autres NAPTR, puis des SRV et enfin une résolution d’adresse, avant même que le client SIP tente une session. Chaque zone peut changer selon un autre calendrier et un autre TTL. Des réponses authentiques peuvent composer un itinéraire momentanément incohérent.

Il faut conserver le résultat DNSSEC, ses périodes de validité, le résolveur, l’âge du cache, les réponses négatives et toute la chaîne de noms. L’identité du pair réellement joint vient ensuite, au moyen du protocole du service.

L’URI vocal ne fait que commencer l’appel

La RFC 4415 enregistre l’Enumservice voice:tel. Elle dit qu’un URI tel: peut servir à initier une communication vocale interactive. Un composeur utilise le numéro, directement vers le PSTN ou le PLMN, ou par l’intermédiaire d’un fournisseur IP et d’une passerelle.

Le verbe « initier » fixe la limite. Le client doit comprendre le type et le sous-type. Un fournisseur peut authentifier l’appelant, appliquer une politique, accepter ou rejeter la demande. Le routage peut échouer. Le terminal distant peut sonner, rediriger, expirer ou répondre. Le flux audio doit encore être négocié et transporté.

Un URI SIP illustre la remise de témoin. La RFC 3261 définit un autre protocole, chargé de localiser des participants potentiels et de créer, modifier ou terminer des sessions. Il possède ses transactions, ses authentifications, ses invitations, ses réponses et ses acquittements. ENUM fournit une entrée ; il ne pré-exécute aucun de ces états.

Même une signalisation acceptée ne prouve pas une conversation. Elle ne montre pas, à elle seule, un son bidirectionnel, une présence humaine, une durée utile ou une facturation correcte. Les preuves de média et d’application doivent rester séparées, avec une rétention proportionnée à la vie privée.

Reconstruire la chaîne dans le bon ordre

Le reçu commence avec le numéro d’origine, sa normalisation et la clé DNS. Viennent ensuite le résolveur, l’heure, DNSSEC, le RRSet complet, les TTL et les réécritures non terminales. Le client consigne ses Enumservices compatibles, les candidats, sa raison de sélection et l’URI final.

La seconde moitié relève d’autres responsables : résolution aval, pair authentifié, autorisation du fournisseur, demande de signalisation, identifiant de transaction, réponses, acquittement et cause de terminaison. Ce n’est qu’après ces étapes que l’on peut décrire les points média attendus, les paquets dans les deux sens et la période pendant laquelle la session a été utilisable.

Chaque étape peut réussir avant que la suivante échoue. Cette séparation permet de distinguer une délégation expirée d’un cache ancien, un service non pris en charge d’un hôte inaccessible, un mauvais pair d’un appelant refusé, et une signalisation établie d’un audio à sens unique.

Sources