Resumen

  • El registro de parámetros DNS de la IANA asigna a «DNS Stateful Operations» el OpCode 6 y mantiene una tabla DSO Type Codes con KeepAlive, RetryDelay y EncryptionPadding. Un asiento registral es el único elemento del expediente que persiste sin la cooperación activa de nadie.
  • Los dos textos de Bellis son objetos de naturaleza distinta: RFC 5625 es una práctica recomendada de un solo autor cuyas obligaciones más duras prohíben estropear tráfico ajeno; RFC 8490 es una Proposed Standard de seis firmas cuyas prohibiciones constituyen un estado compartido. Ninguno obliga a quien decide no implementarlo, y nada en este expediente demuestra un efecto sobre una red en producción.

Qué es exactamente un asiento de registro

La tabla de OpCodes de los parámetros DNS de la IANA otorga el valor 6 a «DNS Stateful Operations (DSO)» con referencia a RFC 8490, y la tabla contigua fija 0x0001 KeepAlive, 0x0002 RetryDelay y 0x0003 EncryptionPadding.

Conviene decir con precisión qué es un asiento así y qué no es. Es un acto público: registra que un identificador existe, cómo se llama y dónde se definió. No depende de la participación continuada del autor, no expira con su contrato laboral y no requiere el consentimiento de nadie para permanecer en el catálogo. Y no significa lo que suele suponerse: la fila no dice qué programa envía ese código.

Esa distancia entre el catálogo y la máquina es el argumento entero de este texto, y el expediente Bellis la muestra con inusual claridad porque el mismo ingeniero aparece en dos documentos que fallan de maneras opuestas.

Un autor, un documento de consejo

RFC 5625, DNS Proxy Implementation Guidelines, se publicó en agosto de 2009 como BCP 152 (página informativa de RFC 5625). La página de la subserie BCP 152 indica que contiene exactamente un RFC. El bloque de autoría acredita a una sola persona, R. Bellis, de Nominet UK (texto de RFC 5625).

Su nota de situación es franca respecto del tipo de afirmación que hace: el documento «specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements». Ahí está todo el mecanismo de cumplimiento. Una práctica recomendada no lleva aparejado ningún programa de conformidad, ningún organismo certificador, ninguna batería de pruebas cuya falla invalide un producto. Es una opinión madurada, ofrecida a quienes pueden discrepar.

Prohibiciones antes que funciones

Al leer las oraciones obligatorias aparece un patrón inmediato. RFC 5625 emplea su lenguaje más fuerte para proteger aquello que el proxy no comprende:

  • Sección 4.1: los proxies MUST ignorar cualquier indicador DNS desconocido y reenviar esos paquetes tal cual.
  • Sección 4.4: si un proxy debe truncar una respuesta por decisión propia, MUST activar el bit TC.
  • Sección 4.5: los proxies DNS MUST ser capaces de reenviar paquetes que contengan registros TKEY.

Las tres obligaciones son prohibiciones de interferir. El documento nunca ordena a una pasarela implementar una novedad; le impide destruir un significado que no le pertenece. La ambición positiva se formula más suave: la sección 3 solo recomienda que los proxies sean lo más transparentes posible, la sección 4.4.1 prefiere que una consulta recibida por TCP se reenvíe por TCP sin intento previo por UDP, y la sección 5.2 prefiere un valor por defecto vacío.

No es timidez. Una pasarela doméstica sobrevive a su propio firmware mucho antes de que el DNS deje de cambiar. El autor no puede saber qué exigirá de ese aparato una extensión futura, y la única regla defendible pasa a ser la que escribió: transporta lo que no entiendes y declara con honestidad cuándo truncas.

Seis firmas y obligaciones que construyen algo

RFC 8490, DNS Stateful Operations, es una Proposed Standard de marzo de 2019 que actualiza RFC 1035 y RFC 7766 (página informativa de RFC 8490). Lleva seis firmas: R. Bellis (ISC), S. Cheshire (Apple), J. Dickinson y S. Dickinson (Sinodun), T. Lemon (Nibbhaya Consulting) y T. Pusateri, sin afiliación (texto de RFC 8490).

Su nota de situación es la fórmula de la vía normativa: representa el consenso de la comunidad IETF, ha recibido revisión pública y fue aprobada para publicación por el grupo directivo de ingeniería de Internet. La autoridad que ejerce es prestada por un proceso con revisores dentro; no la reclaman sus autores.

Y sus imperativos hacen algo estructuralmente distinto de los de RFC 5625. No se limitan a impedir que un intermediario estorbe: fabrican un objeto compartido entre dos extremos.

  • Sección 5.1: un servidor MUST NOT iniciar mensajes de solicitud ni mensajes unidireccionales DSO antes de que una sesión DSO se haya establecido mutuamente.
  • Sección 5.1.1: un servidor que implemente DSO MUST NOT devolver DSOTYPENI ante una solicitud Keepalive, porque el TLV Keepalive es de implementación obligatoria.
  • Sección 5.4.1: si llega una respuesta DSO con MESSAGE ID cero, el error es fatal y el receptor MUST abortar la conexión de inmediato.

Leídas en orden, esas frases describen una institución de dos miembros. Una sesión existe solo por establecimiento mutuo. Un código de rechazo con nombre queda inhabilitado para una solicitud concreta porque otra pieza es obligatoria. Un identificador malformado no es una advertencia sino una ruptura. Dos máquinas sostienen un estado conjunto que ninguna puede declarar por su cuenta, y el documento es el lugar donde esa conjunción queda escrita.

Alrededor, los redactores dejaron discreción marcada como tal: un cliente sin respuesta SHOULD esperar treinta segundos; si el servidor corta la conexión, SHOULD marcar esa instancia de servicio como no compatible con DSO. Son instrucciones para leer el silencio, de otra naturaleza que las reglas de constitución.

Los tres huecos del expediente

Tres preguntas naturales siguen abiertas, y merece la pena decir por qué con exactitud.

El registro de erratas primero. El 18 de octubre de 2026 las páginas de erratas de RFC 5625 y RFC 8490 no mostraban entrada alguna, y ninguna página informativa indicaba documento sucesor u obsoleto. Una pantalla vacía es una señal débil: puede significar que el texto resistió o que nadie presentó una corrección. Son hechos distintos que se ven iguales desde fuera.

La fabricación del documento después. Las fichas del Datatracker para RFC 5625 y RFC 8490 estaban disponibles aquí como resúmenes de página, no como historiales completos de revisión: la filiación de los grupos de trabajo es visible —DNSEXT para la guía de proxies, DNSOP para las operaciones con estado— pero la historia frase por frase no lo es.

Y sobre todo: no se obtuvo prueba de implementación para ninguno de los dos documentos. Este texto no sostiene que RFC 5625 cambiara el modo en que las pasarelas reenvían consultas, ni que DSO aparezca en algún resolutor comercializado. Son cuestiones empíricas sobre software, y el software no dejó rastro en el expediente examinado.

Dónde termina de verdad la autoría

La tentación con un ingeniero como Bellis es leer el número de RFC como prueba de la red. No lo es. El número acredita que un documento se publicó, se revisó y se catalogó; no dice nada sobre qué máquinas ejecutan lo que describe. El cumplimiento aparece en el despliegue, y el despliegue es la decisión de otro.

Lo que el autor controlaba es más estrecho y más interesante. Controlaba la redacción: qué exigencia se convertía en MUST, cuál quedaba en RECOMMENDED y, sobre todo en RFC 5625, si los verbos más fuertes se gastarían en prohibir daños o en reclamar funciones. Controlaba, con cinco coautores, la decisión de hacer del establecimiento de sesión una precondición en lugar de una cortesía. Son actos reales, atribuibles a personas nombradas y visibles en el texto.

Lo que no controlaba es la parte que decide si todo eso importa. Un implementador puede leer RFC 8490, sopesar el coste del estado de sesión frente a un calendario de firmware y rechazarlo. Nada en el documento lo alcanza. El registro conserva el número de todos modos, y por eso precisamente el registro atestigua mejor la durabilidad de lo que la prosa atestigua la adopción.