Resumen

  • La revisión 06 de DUJ define instrucciones manuales DUJS legibles o DUJ64 codificadas en Base64; ambas contienen una lista ordenada de altas y bajas que debe evaluarse como una unidad atómica.
  • Ver una instrucción bien formada no autentica al servicio que la creó ni autoriza al usuario sobre la zona. El operador conserva la decisión local y el resultado público requiere observación posterior.

Una acción visible y un contenido opaco

La pantalla dice add. A continuación aparece una cadena Base64. La usuaria reconoce que algo será añadido, pero no puede leer con naturalidad el nombre, el tipo y el Rdata que producirán el efecto. Copia la cadena porque el servicio se la ha presentado como el siguiente paso necesario.

No hay engaño en el diseño. draft-hoffman-duj-06 explica que DUJ64 es deliberadamente ilegible para el usuario, aunque deja visible si la acción añade o elimina. Su objetivo es transportar el formato de registro que habría aparecido en DUJS sin que la escritura manual, las comillas “inteligentes” o los escapes dañen el contenido.

El error comenzaría si una interfaz convirtiera esa opacidad en confianza. Base64 no cifra, no firma y no identifica al autor. Un paquete que llega intacto puede ser malicioso, obsoleto, preparado para otra cuenta o incompatible con la política de la zona. La exactitud de los bytes no decide quién puede cambiar el DNS.

El problema que sí resuelve

Las instrucciones DNS en lenguaje natural obligan a traducir entre modelos. Un servicio habla de “host”, “valor” y “verificación”; el panel del operador habla de propietario, tipo, TTL y datos. Una persona decide si debe sustituir un RRset, agregar otra cadena o escribir un punto final. La explicación puede mezclarse con urgencia comercial.

DUJ convierte la parte operativa en una estructura estrecha. El valor exterior tiene dos elementos. El primero identifica DUJS o DUJ64; el segundo es un arreglo no vacío de plantillas. Cada plantilla contiene exactamente add o delete y un registro en formato de archivo de zona de RFC 1035. Los comodines están prohibidos. Los tipos aún no registrados pueden representarse con la forma genérica de RFC 3597, aunque el operador puede rechazarlos.

Los arreglos, en lugar de objetos ampliables, también eliminan comentarios persuasivos. La fuente no puede adjuntar un campo como “actualización urgente de seguridad” para obtener una aprobación que los datos desnudos no merecen. Si el formato evoluciona, debe cambiar el identificador de versión, no incorporar silenciosamente claves nuevas.

Es una especificación mínima útil: reduce ambigüedad sin reclamar la decisión completa.

La persona no une las dos conexiones

El paquete recorre dos tramos. Primero, del servicio a la persona. Después, de la persona al operador DNS. La sección de seguridad limita la autenticidad e integridad de cada tramo a la fuerza de la conexión correspondiente.

Autenticarse en el panel DNS solo prueba quién mantiene la segunda sesión. No prueba qué servicio originó los bytes ni qué pantalla los mostró. Del mismo modo, una sesión auténtica con el servicio no prueba que la cuenta DNS tenga competencia sobre todos los nombres del paquete. Una delegación hija puede interrumpir la autoridad aparente de la zona; un nombre parecido puede pertenecer a otra superficie administrativa.

La automatización debe conservar, por tanto, la procedencia de la presentación y la autorización de la mutación como registros diferentes. También necesita una decisión humana comprensible cuando el contenido llega como DUJ64: decodificar para previsualizar es razonable; llamar “seguro” al resultado por ser decodificable no lo es.

Todo o nada no significa correcto o incorrecto

El operador debe confirmar que el arreglo completo puede aplicarse de forma atómica antes de ejecutar una acción. Si una operación impide el commit del conjunto, ninguna debe procesarse. Así se evita que una migración elimine el valor anterior y falle antes de instalar el nuevo.

Pero la atomicidad protege la unidad de la transacción, no su intención. Un atacante también puede preparar un conjunto coherente. Una orden caducada también puede ejecutarse sin fisuras. El borrado y alta de registros equivocados pueden quedar perfectamente sincronizados.

Por eso el texto conserva autoridad local. El operador debe verificar que el usuario puede cambiar la zona nombrada por cada FQDN. Puede aplicar reglas propias a tipos desconocidos. Puede rechazar cualquier DUJ, por ejemplo uno que añade y luego elimina el mismo registro, y debería explicar el rechazo. La sintaxis termina antes de esa decisión.

Los reintentos necesitan una respuesta honesta

El estado previo importa. Un add puede omitirse porque el registro exacto ya existe. Un delete puede no tener efecto porque el registro ya no está. La sección de procesamiento también exige comprobar presencia o ausencia exacta y recomienda informar al usuario de cada cambio realizado.

“Aceptado” es demasiado pobre. Una recepción útil debería incluir la huella del paquete, la cuenta autenticada, la zona, la base de autorización, las decisiones locales, el RRset anterior y posterior, las acciones omitidas y la identidad del commit atómico. Esta propuesta de recepción es análisis operativo de Daniel Kade; no debe atribuirse al borrador.

Después viene otro límite. El backend puede haber confirmado la transacción sin que todos los servidores autoritativos la hayan cargado. Los secundarios pueden retrasarse. Los resolvers pueden conservar la versión anterior por TTL. El servicio que pidió la prueba puede consultar desde otra vista. El éxito debe dividirse entre autorización, commit, publicación observada y aceptación del servicio final.

Un borrador individual, no un despliegue

La revisión 06 fue cargada el 26 de septiembre de 2026 y expira el 30 de marzo de 2027. Datatracker la muestra como Internet-Draft individual activo, sin stream RFC y sin posición formal en el proceso de estándares. Su texto declara intención Standards Track; eso no equivale a adopción, consenso, aprobación o RFC.

El cambio congelado desde la revisión 05 actualiza número y fechas, no el mecanismo. Tampoco hay en las fuentes prueba de implementación, interoperabilidad, adopción, incidente, rendimiento o resultado comercial. El análisis se limita al contrato descrito.

Fuentes