Resumen

  • La declaración local de subdominios y el registro público que permite verificarla son objetos distintos. El segundo puede confirmar la autorización sin enumerar todos los nombres privados.
  • La identidad DNS del resolutor sí queda visible en el nombre del registro público. Ocultar el inventario no protege un secreto que se haya incorporado a esa identidad.
  • Autorizar una zona hija estable simplifica las altas de servicios, pero también concede margen para decisiones futuras dentro de ese espacio.

Pedir una explicación no debería obligar siempre a publicar un inventario. Una organización puede necesitar demostrar quién permitió que ciertos nombres se resuelvan de forma distinta dentro de su red, sin querer dar a cualquier observador una lista de sus servicios internos. La dificultad consiste en ofrecer una prueba útil sin añadir una divulgación innecesaria.

El DNS con vistas diferentes plantea precisamente ese problema. Un nombre puede recibir una respuesta interna que no coincide con la visible desde fuera. Para un cliente que ya utiliza un servicio de resolución cifrada externo, aceptar esa excepción exige decidir cuándo salir de su recorrido habitual. La existencia de una necesidad local no explica por sí sola por qué todas las demás consultas deberían seguir el mismo camino.

También sería insuficiente rechazar cualquier información local. Los servicios internos pueden depender de esa vista particular para ser encontrados por su nombre. Hay una opción entre confiar toda la resolución al entorno recién encontrado y negarse a usar sus particularidades: verificar una autorización acotada.

RFC 9704, publicado en enero de 2025 dentro de la vía de estandarización, proporciona un mecanismo para hacerlo. Su diseño permite que la aprobación sea comprobable en el DNS público sin colocar allí la lista completa de subdominios privados. Esa separación es el centro de esta discusión, no una promesa de que la infraestructura se vuelva invisible.

El permiso tiene dos representaciones

La red entrega al cliente una declaración con el nombre de autenticación del resolutor, la zona padre y el conjunto de subdominios para los que solicita autoridad, además del algoritmo y una sal aleatoria. El operador de la zona padre aprueba el contenido y publica un valor de verificación calculado sobre la representación canónica del conjunto y la sal.

El cliente dispone de la declaración local y puede calcular el valor que espera encontrar. El registro TXT público confirma esa combinación sin tener que presentar el inventario a quienes solo consultan la zona pública. El nombre del registro incorpora la identidad del resolutor, el marcador de verificación y el padre correspondiente.

No conviene describir ese valor como una base de datos cifrada. Un resumen criptográfico no es una lista que después se descifra, y la sal no se oculta a los clientes que reciben la declaración. El objetivo es limitar lo que debe publicarse, no impedir que los participantes conozcan la información necesaria para usar el mecanismo.

Esto permite formular una exigencia de rendición de cuentas más precisa. Quien revisa la autorización puede pedir que exista una correspondencia verificable entre el permiso del padre y el ámbito local, sin exigir que el detalle tenga la misma audiencia que la prueba pública.

Dentro de la organización, en cambio, conviene conservar la explicación del permiso. Si solo queda el valor de verificación, el personal que asuma la operación después no sabrá por qué se aprobó aquel ámbito ni qué servicio lo justificaba. La privacidad frente al exterior no debería convertirse en falta de memoria para el propio responsable.

El registro de dominios de aprovisionamiento de IANA recoge splitDnsClaims y sus cinco campos. Su función es coordinar la forma de expresar la declaración. No acredita que un equipo concreto la procese, ni que un cliente haya validado un permiso, ni que un proveedor haya implantado el diseño. Esas afirmaciones requerirían otras pruebas.

La información que sigue saliendo

La parte visible merece una revisión propia. RFC 9704 advierte de que el nombre de autenticación del resolutor aparece en el nombre del registro público y puede contener información sensible. Es posible proteger cuidadosamente la lista y revelar, por otra vía, lo que esa lista pretendía no anunciar.

Un ejemplo hipotético ayuda a situar el riesgo: un servicio aún confidencial usa nombres privados, pero su resolutor lleva el nombre del proyecto. No haría falta romper el algoritmo para obtener una pista. La divulgación estaría en una elección de nomenclatura que quizá se consideró un detalle de instalación.

Por ello, la identidad pública debería ser deliberadamente poco reveladora. Esto no exige eliminar toda relación reconocible con el operador; exige decidir qué relación es necesaria y qué información comercial o interna no aporta nada a la verificación.

La decisión llega antes de publicar. Borrar más tarde un nombre puede cambiar lo que se obtiene en una consulta nueva, pero no retira las copias que otros ya hayan observado. No debe confundirse la facilidad de editar un registro con la capacidad de deshacer su exposición.

Hay otros destinatarios de información que tampoco desaparecen. RFC 9463, dedicado al descubrimiento de resolutores designados por la red, recuerda que el cifrado del transporte no reduce los datos disponibles para el resolutor. Proteger una consulta durante el trayecto no la oculta al servicio que debe responderla.

Este límite importa al externalizar la operación. La guía de tecnologías de pasarela de ACSC, de ASD recomienda considerar la confianza y las amenazas antes de exponer vistas internas a proveedores externos. También advierte contra tratar la selección de vistas por dirección IP como un mecanismo de seguridad. Su referencia a RFC 9704 es orientación técnica, no una certificación de una implantación particular.

Ni una lista poco visible ni una autorización de resolución sustituyen los controles de la aplicación. Saber a qué dirección corresponde un servicio no equivale a tener permiso para entrar en él. Ese permiso debe seguir siendo defendible incluso cuando el nombre llegue a ser conocido.

Verificar sin aceptar la explicación del mismo interesado

La confirmación pública debe obtenerse de una forma que el operador local no pueda alterar a voluntad. RFC 9704 contempla un resolutor externo cifrado ya configurado o la validación DNSSEC completa realizada por el propio cliente sobre el registro de verificación.

La primera vía conserva las reglas normales con las que el cliente acepta respuestas del servicio externo. Si no obtiene una respuesta en un plazo razonable, la verificación falla. La urgencia de abrir una aplicación interna no cambia el significado de ese resultado.

En la segunda vía, una respuesta validada como Secure puede utilizarse. Bogus e Indeterminate se rechazan. Ante Insecure, se recomienda probar otro método; si el cliente no vuelve a intentarlo, debe considerar fallida la validación. No son cuatro maneras equivalentes de obtener un indicador favorable.

El ámbito del mecanismo también es explícito: nombres arraigados en el DNS global, cooperación del padre adecuado y resolutores con transporte cifrado autenticado. No sirve para validar de este modo la apropiación de nombres de uso especial como local., ni autoriza a la red a filtrar el dominio de un tercero.

El descubrimiento sigue resolviendo otro problema. RFC 9463 facilita nombre, direcciones y parámetros de servicio. La comprobación del certificado compara al extremo con el nombre suministrado, pero no valida por sí misma la seguridad del canal que distribuyó la configuración o la confianza del usuario en la red. RFC 9704 añade un permiso para un ámbito concreto, no una confianza general en todo lo que ese extremo diga.

El perímetro decide quién tendrá que volver a preguntar

La autorización puede abarcar varios subdominios o un espacio más amplio. El RFC recomienda agrupar los nombres internos bajo una zona hija porque así disminuye la frecuencia de cambios en el registro público. Aclara que esa agrupación no es necesaria simplemente para evitar que se publique cada nombre privado.

La ventaja administrativa es real como propiedad del diseño, aunque aquí no se haya medido su valor económico. Si una zona interna estable ya está aprobada, la incorporación de un servicio dentro de ella puede no requerir cambiar otra vez el registro del padre. La organización necesita menos coordinación pública para sus modificaciones ordinarias.

Pero ese ahorro compra discreción. Una aprobación de subárbol no se limita a los nombres que aparecen en el documento revisado hoy. También deja espacio para los que se creen mañana. Por eso conviene preguntar quién controla ese crecimiento y qué cambios de finalidad obligarían a revisar el acuerdo.

Un conjunto estrecho puede resultar adecuado para servicios sensibles y poco cambiantes. Una zona hija coherente puede encajar con un equipo que administra muchos servicios relacionados. Cubrir todo el padre concede un ámbito mayor. Ninguna opción debería ganar solo porque reduzca el número de solicitudes pendientes.

Las renovaciones añaden coordinación temporal. El nuevo registro de verificación debe publicarse antes de modificar la declaración correspondiente; el antiguo debe conservarse mientras existan las configuraciones todavía válidas previstas por el procedimiento. Las reglas de RFC 8801 gobiernan por separado la caducidad y actualización de la información del dominio de aprovisionamiento. La distribución pública y la local no avanzan necesariamente al mismo tiempo.

Esta investigación no presenta ensayos de clientes, porcentajes de adopción, incidentes descubiertos ni resultados de rendimiento. Examina un mecanismo documentado y las decisiones que implica. Para mantener una excepción precisa hay que financiar su mantenimiento; de lo contrario, la falta de tiempo puede terminar ampliando el permiso, aunque nadie lo haya defendido como una elección de diseño.

El objetivo razonable no es ocultarlo todo ni dirigirlo todo al resolutor local. Es hacer comprobable una excepción necesaria, revelar solo lo que su verificación necesita y conservar la capacidad de explicar quién puede ampliarla.