Resumen

  • RFC 3403 guardó reglas DDDS en registros NAPTR, pero la posición física en una respuesta DNS no fijaba el orden de ejecución. El cliente ordenaba por ORDER y aplicaba PREFERENCE solo entre alternativas del mismo nivel.
  • Tras una coincidencia no podía saltar a otro ORDER porque apareciera después un servicio conocido. La sección Additional, DNSSEC y el éxito del destino eran pruebas independientes.

Una herramienta de DNS dibuja filas y hace que la respuesta parezca una lista. El primer registro ocupa el primer renglón y parece reclamar precedencia. RFC 3403 advirtió que esa impresión no era un contrato. NAPTR devolvía un conjunto de reglas candidatas cuyo orden normativo se encontraba dentro de cada registro.

Publicado en octubre de 2002 en la vía de estándares, el RFC definió DNS como base de reglas de DDDS. La clave era un nombre de dominio válido; el cliente consultaba registros NAPTR, tipo 35, y recibía una serie de reglas. El documento sustituyó a RFC 2915 y RFC 2168 como especificación oficial del formato.

ORDER reconstruía la secuencia de delegación. Los valores menores se procesaban primero. Dos registros con el mismo ORDER representaban la misma regla desde el punto de vista de autoridad, aunque ofrecieran servicios distintos. Una vez encontrada una coincidencia, el cliente no debía examinar otro ORDER, salvo la excepción explícita de selección compleja del algoritmo DDDS.

Por eso el orden del paquete tenía poco valor probatorio. Un servidor, caché o biblioteca podía entregar el RRset en otra secuencia sin cambiar su significado. Elegir el primer registro con Services conocidos sustituía la estructura publicada por un accidente de presentación.

PREFERENCE actuaba dentro del grupo. Era el equivalente de Priority y clasificaba alternativas con el mismo ORDER, de menor a mayor. Un cliente podía considerar una preferencia peor si no soportaba bien el protocolo preferido. No podía usar esa libertad para cruzar a otro nivel después de coincidir.

El campo tampoco era balanceo de carga. Comunicaba calidad o preferencia entre reglas equivalentes en autoridad. Para repartir tráfico existían SRV o múltiples registros A. Interpretarlo como peso inventaría una aleatoriedad no definida por NAPTR.

Flags y Services recibían significado de la especificación de la aplicación. La base genérica no declaraba universalmente qué indicador terminaba el proceso ni qué servicio era válido. Reconocer una cadena no demostraba que el cliente estuviera ejecutando la aplicación correcta.

REGEXP y REPLACEMENT eran formas mutuamente excluyentes de la sustitución. REGEXP se aplicaba a la cadena original; REPLACEMENT contenía un nombre plenamente cualificado para un reemplazo simple, sin compresión. Si ambos tenían valor, el registro era erróneo y debía ignorarse o generar error.

La administración añadía otra capa. En el archivo de zona la barra inversa servía para escapar caracteres y a menudo debía escribirse dos veces para llegar una vez a la respuesta. El texto administrado y la expresión recibida no eran necesariamente idénticos. Un recibo debía guardar ambos lados.

Los campos de texto usaban UTF-8. Fuera de ASCII, las expresiones debían trabajar con puntos de código, no bytes. Tampoco podían depender de una locale POSIX, pues una regla que cambiara según la configuración regional del cliente dejaría de ser universal.

Varias aplicaciones DDDS podían compartir un nombre DNS y colisionar. RFC 3403 ofrecía tres defensas: zonas separadas, expresiones ancladas en rasgos de la cadena propios de cada aplicación o Flags y Services que permitieran descartar reglas ajenas. Compartir ubicación no fusionaba contratos.

Additional era una optimización. El servidor podía adjuntar RRsets A o SRV relevantes con la misma autenticidad que la respuesta, y el cliente podía usarlos. Sin embargo, la aplicación debía funcionar con servidores que nunca rellenaran esa sección. Su ausencia pedía otra consulta, no invalidaba NAPTR.

El TTL protegía la coherencia temporal. Durante un retroceso tras un fallo, todas las reglas recordadas debían seguir vigentes. Si una sola había caducado, el algoritmo recomenzaba desde el principio. Mezclar reglas de épocas distintas podía producir una secuencia que nunca existió simultáneamente.

El RFC también recomendó informar del fracaso cuando una consulta posterior a la reescritura fallaba, en lugar de volver atrás para probar otros caminos. El retroceso oportunista convertía una delegación ordenada en búsqueda abierta y ocultaba dónde falló la autoridad seleccionada.

DNSSEC podía autenticar NAPTR como cualquier dato DNS. No demostraba que la expresión fuese segura, que el cliente hubiera ordenado bien, que Services perteneciera a la aplicación prevista ni que el servicio final respondiera. Por eso el texto advirtió contra entregar expresiones sin examen a entornos capaces de ejecutar código.

El registro DNS Parameters de IANA conserva NAPTR como tipo 35: prueba de coordinación, no de uso correcto. El RFC Editor muestra una errata editorial, la 2868, retenida para actualización documental. Elimina la repetición this this en la descripción de Services y no altera la semántica.

Una evidencia completa conserva clave, RRset, estado DNSSEC, TTL, secuencia recibida, grupos ORDER, PREFERENCE, Flags, Services, validez de REGEXP o REPLACEMENT, interpretación UTF-8, comparación entre zona y red, rechazos, registro seleccionado, Additional utilizado, siguiente consulta y resultado del consumidor.

La especificación inicial mínima de Lu Heng explica el reparto: estandarizar la representación DNS indispensable y dejar el significado a cada aplicación. La primacía del código en ejecución aporta la prueba. Si se reordena el RRset, se elimina Additional, cambia la locale o vence una dependencia, el cliente conforme sigue los campos de autoridad.

RFC 3403 convirtió un conjunto DNS en una acción ordenada sin fingir que el transporte ya había hecho el trabajo. El primer NAPTR visto no era necesariamente la primera regla. La primera regla era la que ORDER situaba allí.

Fuentes