Re: DDDS, NAPTR, et Encrypted NAPTR : Interrogations

Le 21 nov. 2011 à 08:18, Stephane Bortzmeyer a écrit :

> On Fri, Nov 18, 2011 at 08:30:32AM +0100,
> Florian MAURY <[email protected]> wrote 
> a message of 20 lines which said:
> 
>> Sauriez vous m'expliquer pourquoi applique-t-on *d'abord* les
>> substitutions *puis*, si cela donne une chaine non nulle, on teste
>> que le service est celui attendu, alors que comparer les services
>> revient à faire une comparaison de chaines de caractères (peu
>> couteux) alors que la substitution est un lancement de regexp
>> (couteux). Cela me semble ruineux en terme de performances.
> 
> Un collègue anglophone suggère :
> 
> In terms of performance, it is true the regexp substitution is costly,
> but it provides added flexibility so that rules can defined at the
> database (DNS) rather than at the application.
> 

Bonjour,
Je vous remercie d'avoir fait suivre ma question à vos contacts anglophones.
Je ne suis cependant pas sur de bien comprendre sa réponse : ce qui m'intriguait n'était nullement que les regexp soient stockées dans le NAPTR RR mais plutôt de l'ordre d'application de celle-ci. Je vais reformuler mon interrogation :

Les NAPTR RR permettent de stocker dans un même enregistrement différentes informations, dont notamment un service (E2U+email:mailto, E2U+voice:tel, E2U+sms:tel par exemple) et une expression rationnelle (regexp) qui doit être appliquée à l'Application Unique String définie dans l'application. Cette dernière n'est jamais communiquée lors des requêtes DNS.
Ainsi, une fois la requête DNS effectuée, et la réponse reçue, l'application choisit les règles à appliquer en fonction des ordres et préférences, puis on arrive à l'étape 3 et 4 dont je parlais dans mon premier email.

Selon la RFC, on doit d'abord appliquer les regexp jusqu'à obtenir une règle non nulle.
On peut imaginer que la regexp qui s'appliquera pour obtenir un email sera fort différente de celles qui s'appliquera pour les 2 numéros de téléphone. 

Prenons un exemple de résolution dont le but est de récupérer le numéro de téléphone pour envoyer un SMS.

On récupère tous les NAPTR records. L'ordre et la préférence établissent que l'application traitera les enregistrements dans l'ordre email, voix, sms.

La règle des emails est donc appliquée (cout important généré) à l'AUS, et ne renvoie rien (ou peut etre que si ? c'est suivant la règle...). Admettons qu'elle ne renvoie rien. On passe à la règle suivante.

On arrive à la règle pour obtenir le numéro de téléphone voix : la regexp est appliquée (cout important généré) à l'AUS : cela renvoie une chaine non vide (par exemple). On passe donc à l'étape 4 de l'algorithme : on compare le service avec celui qui était demandé : comparaison de chaine de caractères (cout faible) entre "E2U+voice:tel" et "E2U+sms:tel". Elles sont inégales, donc on revient à l'étape 3 et on recommence les résolutions de regexp.

On applique la regexp (cout important généré) sur les SMS qui renvoie une chaine non vide (c'est le but, du moins :)) : on passe à l'étape 4 et on compare les services : "E2U+sms:tel" et "E2U+sms:tel" sont bien égaux : on peut passer à l'étape 5 (ou pas, d'ailleurs, d'après la RFC).

On a donc effectué 2 regexp complètement inutiles ; dans les deux cas, la règle aurait pu être disculpée directement en comparant d'abord les services.

Il m'aurait paru plus performant (et donc logique) de tester d'abord les services : on n'avait alors plus qu'une seule règle. On appliquait alors qu'une seule regexp.

Cordialement,
Florian Maury