DDDS, NAPTR, et Encrypted NAPTR : Interrogations

Bonjour,
Je suis en train de lire les RFC 340{1,2,3,4} à propos DDDS et je suis tombé sur deux ou trois points qui me font m'interroger.

Tout d'abord, dans la RFC 3402, Section 3.3, on lit le descriptif de l'algorithme DDDS, et je suis assez circonspect lors des deux points 3 et 4.
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.
Il se peut également que j'ai mal compris qqch.

J'ai ensuite regardé du coté de certains qui utilisent déjà des NAPTR RRs : telnic.
Lorsque je fais un dig telnic.tel NAPTR ou même presque n'importe qui d'autre chez le TLD .tel, je passe automatiquement en rejeu en TCP, certainement à cause de la taille de la réponse. 
Même si leur utilisation des NAPTR RRs me semble un peu abusive, est ce qu'il est possible de conclure qu'utiliser ce genre de RRs mène quasi obligatoire à toujours faire ses requêtes en TCP ? Si oui, est ce la raison qui fait (ou me semble faire) que DDDS ait un succès relativement faible (les résolveurs, comme ceux de Free, refusant les connexions en TCP, et empêchant donc de faire ce genre de requêtes) ? 
Comment faire pour fournir plein de règles pour divers services dans un même "Well Known FQDN", sans dépasser les tailles limites ; existe-il des astuces comme pour les SRV RR avec des "well known service name" (_smtp._tcp.example.tld.) ? Si oui, n'est ce pas contre le principe même de DDDS (ce qui a d'ailleurs causé l'apparition de S-NAPTR (RFC 3958) pour justement effacer ces well known service name) ?

Par ailleurs, j'ai lu également le draft à propos des NAPTR avec contenu chiffré (X-Crypto : http://tools.ietf.org/id/draft-timms-encrypt-naptr-01.txt ). 
Je suis circonspect par le stockage du code dénotant comment est chiffrée la donnée (type et taille de clé, de padding, de hash) dans le champ service : comment faire quand on a des règles non terminales de type X-Crypto : est ce que X-Crypto doit nécessairement être utilisé avec des règles terminales (le draft ne semble pas en parler) ? 
Doit on prévoir une règle par type de chiffrement qu'on peut être amené à rediriger vers ? 
Les applications sont elles officiellement autorisées à faire des comparaisons de noms de services par sous-chaines ("le type et le sous-type du service, mais pas le code spécifiant le chiffrement ?") ?

Merci à ceux qui auront lu un si long mail d'une part, et à ceux qui prendront le temps d'y répondre d'autre part ;)
Cordialement,
Florian Maury