Resumen

  • draft-levine-dnsextlang-14 propone almacenar descripciones de RRTYPE en TXT para que muchos tipos nuevos se incorporen como datos de configuración. Sigue siendo un Internet-Draft individual, no un RFC ni un servicio de IANA en producción.
  • La marca X avisa de procesamiento especial y permite rechazar una zona cuando falta esa función. No instala la función ni certifica que un servidor concreto la tenga.
  • DNSSEC autentica origen e integridad bajo una política de confianza. La ejecución segura requiere además conciliar los dos nombres, identificar caché y override local, ensayar límites, convertir a bytes, cargar una zona aislada y observar una respuesta autoritativa.

El momento decisivo no ocurre cuando aparece un registro nuevo en un catálogo. Ocurre cuando el operador coloca un archivo de zona frente a un binario real. El TXT llegó con una firma válida y el formulario de alta acepta sus campos. Aun así, nadie ha demostrado que la combinación exacta de parser, almacenamiento, firmador y servidor autoritativo produzca los octetos esperados.

El borrador intenta resolver una fricción conocida. Cada RRTYPE nuevo suele obligar a añadir sintaxis al formato maestro y a las herramientas de aprovisionamiento. Una stanza declarativa permitiría indicar nombre, número, banderas y campos. El servidor convertiría texto legible a RDATA; un exportador reconstruiría texto desde AXFR; la interfaz podría crear formularios y validar entradas.

La mejora desplaza trabajo desde lanzamientos repetidos hacia datos interpretados. Precisamente por eso, el esquema deja de ser simple documentación: participa en la conducta del parser.

Dos índices no garantizan una versión

La definición se publicaría dos veces: por número bajo RRTYPE.ARPA y por nombre simbólico bajo RRNAME.ARPA. Una entrada puede ser CNAME de la otra. También existen variantes con etiqueta de idioma para las descripciones humanas y una entrada sin prefijo como valor predeterminado.

El borrador exige que ambos TXT sean idénticos, pero no establece cómo resolver una divergencia. Durante una actualización, los caches pueden observar generaciones distintas. La variante lingüística y el alias por defecto pueden avanzar en momentos separados. Un archivo local, permitido para depuración y override, añade otra autoridad.

La propia sección de directorio conserva una incongruencia: el texto sitúa la lista en _LIST.RRTYPE.ARPA mientras el ejemplo usa _LIST.RRNAME.ARPA. No debe convertirse en una elección silenciosa de cada producto. Es una cuestión abierta del documento que un cliente prudente debe registrar y, si hay conflicto, rechazar.

TTL no significa conmutación atómica. RFC 8767 incluso define condiciones limitadas para servir datos stale cuando falla la actualización autoritativa. La propuesta no obliga a hacerlo, pero una evidencia seria debe decir si la stanza procedía de una respuesta autoritativa actual, de caché vigente o de una retención vencida.

Una firma válida no revisa la semántica

La sección de seguridad teme que el spoofing modifique las definiciones importadas y cita DNSSEC como defensa. RFC 4033 describe autenticación de origen e integridad de RRsets mediante anclas de confianza y cadenas de autenticación. El resultado demuestra procedencia y ausencia de alteración indetectada, no corrección funcional.

DNSSEC no compara las copias numérica y simbólica. No prueba que el parser soporte todos los tipos de campo, que la aritmética de longitudes sea segura, que un adaptador SQL conserve el orden o que el operador autorice el cambio. Una stanza equivocada puede estar perfectamente firmada.

Publicar, autenticar y activar son actos de autoridad diferentes. El editor de la zona afirma. El validador comprueba origen. El operador decide si esos bytes pueden influir en un servicio. Una única etiqueta de “confianza” borra la responsabilidad entre los tres.

X señala una carencia; no la corrige

Un RRTYPE marcado con X necesita procesamiento adicional en el servidor. La finalidad declarada es que el servidor emita error si no lo implementa. I y A describen el alcance de clase; O y E, condición obsoleta o experimental.

Ninguna letra proporciona código. Un producto puede reconocer el formato de red y carecer del comportamiento particular. Automatizar bien significa detenerse con una causa precisa, no inferir soporte porque la gramática fue aceptada.

RFC 3597 ya obliga a tratar tipos desconocidos de forma transparente y ofrece TYPEnn \# longitud hexadecimal. Los tipos desconocidos no reciben procesamiento de sección adicional. El lenguaje de extensión mejora la experiencia humana, los formularios y la conversión guiada por tabla; no crea por primera vez la capacidad de transportar RDATA opaco. La notación genérica sigue disponible como retirada conservadora.

El recibo de ejecución

El borrador reconoce que una definición inválida, accidental o maliciosa, puede provocar fallos extraños en software que no valide antes de usarla. También admite que expresar registros arbitrarios puede sortear restricciones de aprovisionamiento. Por ello, el parser debe tratarse como límite de ejecución y de autorización.

Un recibo útil conserva: revisión y estado del documento; respuesta del directorio; hashes de nombre numérico, simbólico e idiomas; DNSSEC y política de ancla; TTL, edad de caché y stale; ruta y hash del override; versiones de servidor, parser y backend; módulo que satisface cada X; pruebas válidas, inválidas y de recursos; bytes de ida y vuelta entre texto y wire; carga canaria y consulta autoritativa; alcance, salud y reversión de la activación.

Este modelo es una propuesta editorial, no una obligación del draft. Separa pruebas que suelen aparecer fundidas. La firma no sustituye al test. El test no sustituye a la carga. La carga no sustituye a la respuesta. Una respuesta no demuestra convergencia de toda la flota.

La separación también ubica la reparación. Una divergencia de nombres pertenece a conciliación; un token desconocido, a admisión de capacidad; un cambio de bytes, al conversor; una diferencia entre canario y producción, al despliegue. Llamarlo todo «soporte RRTYPE» impide saber quién debe actuar.

Una coordinación mínima puede ser más rápida

La capa común necesita gramática portable, unión inequívoca entre nombre y número, semántica de campos, elección de idioma, proceso registral e invariantes de interoperabilidad. No necesita dictar el backend, los límites de memoria, el momento de activación ni el mecanismo de rollback de cada operador.

La doctrina de especificación inicial mínima de Heng Lu sitúa allí la frontera: centralizar lo indispensable para intercambiar y dejar las decisiones posteriores cerca de quien asume el resultado. La adopción voluntaria se acredita con código funcionando, no con la mera existencia de un registro.

Un override visible puede servir para un prototipo o una contención. RFC 3597 puede sostener la representación opaca mientras llega el parser amistoso. La pluralidad de caminos no destruye la interoperabilidad si cada salida se identifica. Lo peligroso es que generaciones diferentes aparezcan bajo el mismo estado verde.