Resumen

  • ENUM convierte un número E.164 en una clave DNS y procesa reglas NAPTR hasta producir un URI; descubre un posible contacto de servicio, no una comunicación concluida.
  • Un registro defendible une la validación del control del número, el estado DNSSEC, el NAPTR elegido, el URI resultante, el par autenticado, la señalización y los medios bidireccionales observados.

Una consola recibe un número E.164 y marca éxito. Eliminó signos, invirtió los dígitos para formar un nombre bajo e164.arpa, obtuvo un RRSet NAPTR con DNSSEC válido y construyó un URI SIP. Después, otro nombre pudo apuntar a un servidor antiguo. El proveedor pudo rechazar la invitación. El terminal pudo no responder. Incluso una señalización aceptada pudo acabar con audio en un solo sentido.

Nada obliga a declarar falsa la respuesta ENUM. El fallo está en haber llamado «conectado» a un resultado que solo decía «resuelto».

Patrik Fältström y Michael Mealling firmaron la RFC 3761, publicada en 2004 como estándar. En 2011 fue sustituida por la RFC 6116, de Scott Bradner, Lawrence Conroy y Kazunori Fujiwara. El texto vigente se describe como actualización del documento editado por Fältström y Mealling. ENUM es, por tanto, trabajo colectivo y revisado, no una decisión operativa atribuible a una sola persona.

Su promesa es limitada y valiosa: partir de un número telefónico y descubrir un URI mediante DNS. No convierte DNS en central telefónica, autoridad de numeración ni testigo de una conversación.

Una clave exacta no acredita al titular

La RFC 6116 define primero la cadena única de aplicación. El número E.164 internacional pierde guiones, espacios y otros adornos, pero mantiene el signo más inicial. La primera regla conocida quita ese signo, invierte los dígitos, los separa con puntos y añade .e164.arpa.. El resultado es una clave inequívoca dentro de la aplicación ENUM.

La operación no prueba quién conserva el derecho sobre el número. Tampoco autentica a quien inició la consulta ni confirma que una portabilidad reciente haya llegado al sistema de validación. La exactitud sintáctica contesta cómo preguntar; no decide quién puede publicar ni a quién conviene llamar.

La clave solicita registros NAPTR. Uno terminal puede producir el resultado final; uno no terminal genera otro nombre de dominio para una consulta posterior. La última vuelta de DDDS entrega un URI absoluto. Ese es el límite del algoritmo: una dirección expresada, no un estado de llamada.

La RFC 3403 separa las piezas de la regla. ORDER organiza el orden principal, PREFERENCE ordena candidatos elegibles dentro del mismo nivel, y FLAGS, SERVICES, REGEXP y REPLACEMENT gobiernan la interpretación y la reescritura. Guardar solo el URI elimina la explicación de por qué fue elegido.

Una regla resultante todavía deja decisiones

La frase «el algoritmo ENUM siempre devuelve una sola regla» no describe el resultado de una llamada. Una aplicación puede admitir solo algunos Enumservices, descartar datos privados o mal formados, mostrar varios URL a la persona usuaria o aplicar conocimiento específico antes de actuar.

El cliente ordena el RRSet por ORDER y PREFERENCE. Cuando hay igualdad, el orden de llegada dentro de la respuesta DNS no representa una preferencia estable. Dos clientes pueden observar el mismo conjunto y recorrerlo de manera distinta si tienen capacidades o políticas diferentes.

La preferencia del registrante tampoco obliga al cliente. La RFC aconseja publicar únicamente contactos que se esté dispuesto a sostener, porque hasta el peor clasificado puede terminar seleccionado. Eso no asegura que esté disponible ahora, que la aplicación entienda su esquema o que el siguiente proveedor admita la solicitud.

La traza debe conservar el conjunto entero, los TTL, los campos de orden y servicio, las reglas de reescritura y las capacidades locales. También debe explicar por qué cada candidato se aceptó o descartó. Sin ese denominador, un URI aislado no permite auditar la selección.

El derecho de uso se valida antes del DNS

Los dominios ENUM están ligados a asignaciones E.164. La RFC 4725 distingue la entidad que asigna el número, el assignee con derecho de uso, el registrante ENUM, la entidad de validación, el registro, el registrador, el proveedor DNS y el proveedor de aplicación.

La entidad de validación comprueba que el registrante es el assignee o actúa con su autorización. El control inicial no basta para toda la vida de la delegación: hacen falta revalidación y revocación cuando cambian la asignación o las condiciones.

Ese expediente no viaja dentro de cada NAPTR. Un resolver puede autenticar los datos publicados sin conocer el último portado, el método de validación ni la política local que autorizó el alta. Que el nombre exista y que su registrante mantenga hoy el control son afirmaciones distintas.

Un registro obsoleto tampoco demuestra por sí solo una acción maliciosa. Pueden intervenir un TTL vigente, actualizaciones de zonas en momentos diferentes o una revocación pendiente. Para reconstruir el caso hacen falta la versión de asignación, la hora y método de validación, su caducidad, el cambio de delegación y la respuesta vista por el cliente.

DNSSEC no autentica al servicio final

La RFC 6116 recomienda DNSSEC para autenticar datos y mitigar ataques contra ENUM, pero formula una advertencia decisiva: obtener una dirección mediante una consulta protegida no garantiza que la entidad alcanzada sea el par de servicio que se pretendía contactar.

El servicio tiene que autenticar a ese par durante su propio establecimiento. La identidad o dirección descubierta fuera del protocolo no sustituye esa comprobación. DNSSEC puede decir que el dato pertenece a una cadena firmada; no puede anticipar quién responderá al otro lado de una sesión posterior.

El tiempo complica aún más el trayecto. El ejemplo SIP de la RFC encadena el URI ENUM con otros NAPTR, SRV y registros de dirección antes de que el agente intente iniciar una sesión. Zonas y TTL diferentes pueden producir combinaciones transitorias. Todos los datos pueden ser auténticos y, a la vez, no describir un único instante coherente.

Conserve validación DNSSEC, vigencia de firmas, resolver, edad de caché, respuestas negativas y cada resolución posterior. Después vincule el intento de señalización a la identidad autenticada del par real.

El URI de voz abre otro proceso

La RFC 4415 registró el Enumservice voice:tel. Un URI tel: generado puede utilizarse para iniciar una llamada de voz interactiva. Un marcador emplea el número a través de PSTN o PLMN, de forma directa o mediante un proveedor IP y una pasarela.

«Iniciar» no es «completar». El cliente debe admitir tipo y subtipo. El proveedor puede autenticar, autorizar, redirigir o rechazar. El enrutamiento puede no hallar destino. El terminal remoto puede sonar, caducar o responder. Los medios necesitan después su propia negociación y camino.

Un URI SIP entrega el control a la RFC 3261, un protocolo separado para localizar participantes y crear, modificar o terminar sesiones. Sus transacciones contienen autenticación, autorización, invitaciones, respuestas, confirmaciones y estado de diálogo. ENUM aporta un URI de entrada; no ejecuta de antemano ese intercambio.

Ni siquiera una señalización aceptada basta para demostrar una conversación. No prueba audio en ambos sentidos, presencia humana, duración útil o facturación correcta. Esas observaciones pertenecen a otro registro y deben limitarse por privacidad.

El comprobante completo tiene dos mitades

La primera conserva el número original, su normalización, la clave DNS, el resolver, la hora, DNSSEC, el RRSet, los TTL y cualquier reescritura no terminal. Añade los servicios compatibles, los candidatos, la razón de selección y el URI producido.

La segunda empieza después de ENUM: resolución descendente, par autenticado, autorización del proveedor, solicitud de señalización, identificador de transacción, respuestas, confirmación y causa de cierre. Solo entonces se observan los extremos de medios, los paquetes en ambas direcciones y el intervalo de servicio útil.

Cada peldaño puede pasar y el siguiente fallar. Esa granularidad separa una delegación vencida de una caché antigua, un servicio incompatible de un host caído, un par equivocado de un llamante no autorizado y una invitación aceptada de un canal sin voz de retorno.

Fuentes