Resumen

  • RFC 5346 documenta una prueba precomercial de Infrastructure ENUM realizada en Corea en 2006. Una URI descubierta en NAPTR todavía debía convertirse en una pasarela. El operador podía usar resolución recursiva o una tabla fija privada, y el fallo de cualquiera de esos caminos podía devolver el número al PSTN.
  • La tabla fija reducía fallos cuando había pocos registros ENUM y pocos puntos de interconexión IP. También creaba un segundo plano de autoridad junto al DNS. Su contenido reflejaba rutas y acuerdos bilaterales que una resolución pública no autorizaba por sí sola.
  • Una llamada completada no demuestra qué plano la encaminó. La evidencia debe conservar la consulta ENUM, la selección NAPTR, el dominio, la fuente del mapa, la pasarela, el motivo del fallback, el régimen contractual y el resultado final.

La URI no era la pasarela

ENUM transformaba un número E.164 en un nombre y devolvía reglas NAPTR. Una regla terminal podía producir una URI SIP o H.323. Ese resultado resolvía una pregunta: qué identificador de servicio debía examinar el softswitch. No resolvía automáticamente dónde estaba una interconexión válida ni quién podía usarla.

RFC 5346 describe dos caminos posteriores. El primero consultaba un servidor recursivo y aplicaba las reglas de localización SIP. El segundo buscaba el dominio de la URI en una tabla fija dentro del softswitch. La tabla asociaba el dominio con el nombre y la dirección de una pasarela concreta.

Si el dominio no aparecía en la tabla, la llamada se enviaba al PSTN. Si la resolución recursiva no producía registros utilizables, también. La misma URI ENUM podía, por tanto, terminar en IP o abandonar ENUM según un dato que no estaba en el NAPTR.

Ese salto es el centro de la autoridad de ruta. Descubrir un nombre no concede permiso para usar cualquier extremo que responda.

El acuerdo bilateral vivía fuera del DNS

Los operadores querían cobrar por la interconexión y tendían a trabajar con transportistas de confianza mediante acuerdos bilaterales. Podían pactar una pasarela específica y mantener esa información en privado.

Una dirección públicamente resoluble no demostraba que el operador llamante tuviera derecho a entregar tráfico allí. La tabla fija condensaba datos técnicos y comerciales: el dominio reconocido, la pasarela acordada y el camino permitido. Era una proyección incompleta del contrato, pero más cercana a la decisión real que la simple existencia de una dirección.

La tabla tampoco era prueba eterna. Podía quedar obsoleta después de cambiar el acuerdo, la pasarela o la propiedad del número. DNS y tabla podían ser válidos en sus propios dominios administrativos y aun así discrepar sobre la ruta correcta.

Por eso el registro de auditoría debe indicar cuál fuente ganó. “URI resuelta” no basta. “Entrada presente en tabla” tampoco. Hace falta la versión de la tabla, el acuerdo aplicable, la pasarela ejecutada y el resultado.

La duplicación compró estabilidad

Mantener ENUM y una tabla local era ineficiente. Había dos puntos de gestión para el mismo recorrido. Sin embargo, la prueba comenzó cuando pocas compañías publicaban información ENUM. Un sistema que dependiera exclusivamente del nuevo directorio habría fallado para la mayoría de los números.

La tabla permitió introducir consultas ENUM sin perturbar el servicio comercial existente. Los softswitches podían cambiar rápidamente entre el método fijo y el método basado en DNS porque los operadores todavía desconfiaban del rendimiento y la fiabilidad del nuevo procesamiento.

RFC 5346 califica esa convivencia como una solución temporal, no como una arquitectura razonable a largo plazo. La observación es importante: algo puede ser correcto para reducir el riesgo de migración y peligroso si se convierte en estado permanente.

Mientras el fallback funcione, un registro faltante no siempre produce un incidente visible. La red antigua absorbe el error. El nuevo directorio parece compatible, aunque nunca haya asumido la decisión.

Los códigos DNS no tenían un significado aislado

La prueba asignó semántica operativa a varias respuestas. RCODE=0 con una URI utilizable llevaba al procesamiento del dominio. RCODE=0 sin URI utilizable provocaba fallo inmediato para un número de una gama “ENUM only”. NXDOMAIN, fallo de servidor, rechazo, error de formato, no implementado o timeout activaban el método específico del proveedor y el PSTN.

La aparente paradoja era deliberada. Un número ENUM-only fuera de servicio conservaba un dominio existente pero no un NAPTR utilizable. No debía caer al PSTN porque carecía de punto de interconexión allí. En cambio, muchos números con acceso PSTN no necesitaban ningún dato ENUM durante el despliegue inicial.

DNS transportaba esa diferencia porque el aprovisionamiento la había codificado. El protocolo no inventaba la política. Copiar la tabla de respuestas sin copiar el contrato de numeración cambiaría su significado.

El erratum 1537 corrige cuatro referencias: deben apuntar a la regla 3 y no a la 2. El erratum 1538 corrige “non-complaint” por “non-compliant”. Una automatización debe usar la decisión real, no una numeración defectuosa del texto original.

Un dominio sin resolución podía empujar una llamada hacia un camino inexistente

Para las gamas ENUM-only, el dominio de una URI debía resolver para todos los posibles operadores. El servidor final podía rechazar una invitación SIP, pero su dirección de máquina tenía que existir.

Si no resolvía, la lógica podía intentar PSTN. Como la gama no tenía interconexión PSTN, el resultado sería fallo o bucle. El fallback que protegía a los números tradicionales era inseguro para esta clase.

La regla demuestra que el fallback no es una reacción neutra ante el error. Debe estar limitado por la naturaleza del número y por los caminos que realmente existen. Un control que sólo pregunta “¿falló DNS?” carece del contexto necesario.

La protección requiere declarar las gamas autorizadas, el máximo de transiciones, una marca que impida volver al mismo régimen y una razón observable. Sin esos campos, un bucle parece una secuencia de intentos independientes.

El timeout transfería el control después de consumir tiempo

La falta de respuesta acababa tratándose como error DNS. Antes de usar el camino histórico, el softswitch esperaba. RFC 5346 considera esa espera larga respecto al tiempo normal de establecimiento.

Los participantes no redujeron los timeouts de manera especial. La pila DNS servía a otras funciones y una configuración no conforme podía alterar operaciones ajenas a ENUM. La mejora local exigía estudiar sus dependencias.

Una métrica de tiempo total mezcla espera del resolver, decisión de fallback, encaminamiento PSTN y señalización SIP. Si la llamada termina, el retraso puede atribuirse al servicio en general y no al cambio de autoridad que lo causó.

El indicador correcto marca el instante en que vence la consulta, el código sintetizado, la regla aplicada y el siguiente plano. El tiempo de fallback es parte de la procedencia.

La tabla de promedios no contaba esa historia

La prueba midió el promedio desde INVITE hasta 200 OK. Los seis pares ENUM/no ENUM fueron 2,33/2,28 segundos para A→A; 2,23/2,25 para A→B; 4,11/3,79 para A→otro PSTN; 2,18/2,05 para B→B; 2,19/2,19 para B→A; y 3,95/3,41 para B→otro PSTN.

Las diferencias eran inferiores a un segundo. Eso sostiene una afirmación acotada: en esas combinaciones, el usuario difícilmente distinguía la elección por la demora de inicio.

No se publican recuentos de muestras, percentiles, colas, denominadores de fallo, estados de caché ni procedencia de ruta por llamada. 200 OK no demuestra calidad de medios, facturación, conversación completada ni titularidad del número.

Una llamada salvada por la tabla privada puede ocupar la misma celda que una llamada encaminada enteramente por ENUM. El promedio mide percepción; no identifica autoridad.

El error aparecía lejos de quien podía corregirlo

RFC 5346 advierte que un registro mal aprovisionado podía producir errores en la red del operador que originaba la llamada. Ese operador no siempre sabía qué compañía servía el número o quién podía editar el dato, especialmente con portabilidad.

La respuesta DNS podía ser auténtica y errónea desde el punto de vista operativo. El softswitch podía ejecutar fielmente una ruta equivocada. El incidente no contenía por sí mismo la identidad del reparador.

El expediente necesita enlazar registro y versión, canal EPP, actualización dinámica, estado de portabilidad, operador responsable, vista del resolver, fuente del dominio, tabla local y contacto de reparación. Compartir información sin compartir responsabilidad acelera el daño.

La visibilidad pública añadió otra superficie

La prueba expuso 2.8.e164.arpa en Internet. Los operadores dudaban de que la gestión centralizada y pública fuera realista y temían revelar números. Preferían acceso privado en algunos escenarios.

El documento también advierte que un resolver comprometido podía causar retrasos o fallos, y recomienda permitir consultas desde la red local del softswitch y restringir el exterior.

Privado no significa correcto. Público no significa autorizado. La decisión cambia observación, privacidad y ataque, pero no sustituye el control sobre el contenido ni el acuerdo de interconexión.

El alcance histórico limita la conclusión

RFC 5346 es informativo y no especifica un estándar de Internet. Describe una prueba de 2006 con dos operadores. RFC 6116 sustituyó después a RFC 3761. Las fuentes no prueban despliegue actual, prevalencia, producto, incidente ni tasa universal.

La lección reusable no es copiar su tabla. Es mantener visible el paso entre directorio nuevo, mapa privado y red antigua. La continuidad sólo puede evaluarse si no borra quién tomó la decisión.