Resumen

  • Un registro SRV puede enumerar varios destinos, pero la pertenencia a esa respuesta no concede por sí sola autoridad sobre el servicio del dominio. RFC 5178 exige que el nombre autenticado conserve servicio, dominio y host.
  • La credencial del triplete funciona como delegación a un miembro concreto. El alta y la baja del clúster deben reconciliarse con la emisión y revocación de credenciales, sin confundir descubrimiento con autorización.

La elasticidad de un clúster suele representarse como un conjunto de cajas equivalentes. Se añade una máquina, se publica en DNS, recibe tráfico y desaparece de nuevo cuando baja la demanda. Esa imagen es útil para capacidad. Para autoridad, resulta incompleta.

Un cliente no busca una caja cualquiera. Busca, por ejemplo, el servicio de directorio de una organización o la raíz NFS de un dominio. Si una respuesta de descubrimiento no protegida incluye un host ajeno, ese host puede tener una credencial válida para su propia identidad. La autenticación servicio [AT] host —donde [AT] representa el signo arroba ASCII literal de la sintaxis del RFC— confirmará que el cliente llegó al host anunciado. No confirmará que la organización le delegó ese servicio.

RFC 5178 conserva el mandato dentro del nombre: servicio [AT] dominio [AT] host.

La tercera pieza no es redundante

El nombre basado en dominio contiene tres elementos obligatorios. El servicio identifica la función. El dominio identifica la comunidad o recurso que la función debe servir. El hostname identifica al aceptador concreto. Aunque dominio y hostname suelen usar nombres DNS, no desempeñan el mismo papel.

Esta diferencia permite tolerar un mecanismo de descubrimiento inseguro sin convertirlo en autoridad final. DNS puede proponer ds2.example.net. El cliente todavía exige que el servidor autentique una credencial para ldap [AT] example.net [AT] ds2.example.net. Un servidor desviado que solo posee su identidad ordinaria no cumple la segunda proposición.

La credencial es, por tanto, una decisión ejecutable. El administrador que la crea incorpora al host al conjunto de servidores autorizados para el servicio de ese dominio. La existencia de la cadena en un archivo de configuración no produce esa autoridad; tampoco la produce aparecer en SRV. La produce la emisión de una credencial que el mecanismo puede comprobar.

El punto de control cambia. Al investigar una selección incorrecta ya no basta con preguntar quién modificó DNS. Hay que revisar quién aprobó el triplete, dónde se copió, cuándo expiraba y si se revocó al retirar el miembro.

Dos inventarios que nunca deben fundirse

El clúster mantiene al menos dos conjuntos. Uno contiene los hosts publicitados para descubrimiento. Otro contiene los hosts con credenciales activas para representar el servicio del dominio. Normalmente se parecen; nunca son la misma evidencia.

Un despliegue puede publicar primero un destino y emitir su credencial después. Durante ese intervalo el host se descubre pero no puede demostrar el mandato. Una retirada puede hacer lo contrario: quitar el registro antes de revocar la credencial. El host deja de recibir clientes ordinarios, pero todavía puede autenticarse si alguien llega a él por una caché, una configuración fija o una respuesta manipulada.

La reconciliación útil es la diferencia entre conjuntos. Un host solo en DNS es un destino aún no preparado o una publicación obsoleta. Un host solo en la credencial es una autorización residual. La coincidencia demuestra coherencia administrativa, no salud del servicio. Todavía faltan contexto GSS, autorización de aplicación y resultado observado.

Convertir ambos inventarios en un campo «miembro activo» elimina precisamente las transiciones que una auditoría necesita ver.

La compatibilidad puede reducir el alcance

RFC 5178 advierte que no todos los mecanismos y aceptadores manejan el nuevo tipo. En LDAP, los clientes existentes pueden usar nombres ligados al host, y desplegar nombres de dominio antes que las credenciales correspondientes rompe la interoperabilidad.

La salida prevista no es aceptar sin más. Si el iniciador recurre al nombre del host, debe verificar por otra vía que ese host está autorizado para servir al dominio deseado. Lo mismo se aplica a clientes que nunca implementaron el tipo.

Esta condición convierte el fallback en política. Un reintento exitoso solo prueba que una ruta compatible funcionó. El expediente debe identificar la lista alternativa de hosts autorizados, su propietario y su vigencia. Si esa lista procede de la misma respuesta insegura que originó el problema, el control es circular.

La dirección debe decidir de antemano si una pérdida de alcance bloquea la sesión, activa una autorización local equivalente o permite una excepción registrada. Dejar que una biblioteca pruebe automáticamente otro nombre entrega esa decisión a la secuencia de errores.

Autenticar el nombre no termina la historia

Un contexto GSS satisfactorio para el triplete esperado demuestra que el aceptador controló una credencial compatible bajo el mecanismo elegido. No demuestra que el DNS fuera auténtico, que la credencial siguiera aprobada, que el usuario estuviera autorizado a leer el directorio o que el servidor devolviera el contenido correcto.

La secuencia completa incluye la intención del cliente, la consulta de descubrimiento, los candidatos, la selección, la construcción del nombre tipado, la conversión al nombre del mecanismo, la credencial, el establecimiento de contexto, la política de la aplicación y una observación de resultado.

Cada paso responde a una pregunta distinta. «GSS OK» no puede informar si el servidor era el miembro que el dominio quería, del mismo modo que «SRV encontrado» no informa si el servidor poseía la credencial correcta.

RFC 6641 ilustra la composición para NFSv4. El cliente usa SRV para encontrar raíces del espacio de archivos de una organización. DNSSEC debe utilizarse cuando esté disponible. El nombre basado en dominio añade una comprobación: el host seleccionado debe autenticar el servicio NFS para el dominio de la organización. Después NFS negocia seguridad y monta — o no — el espacio esperado.

ACE y UTF-8 son vistas, no mandatos

RFC 5178 también define cómo importar y mostrar dominios internacionalizados. La interfaz clásica acepta ACE. La variante UTF-8 recomendada acepta UTF-8 o ACE. La visualización clásica entrega ASCII o ACE; la variante UTF-8 entrega UTF-8 y no ACE.

No se desprende de ello que dos cadenas visualmente parecidas sean el mismo nombre GSS. RFC 2743 separa nombres internos, nombres de mecanismo, formas mostradas y exportadas. Incluso importar y volver a mostrar no garantiza recuperar la cadena original ni el mismo identificador de tipo. La comparación autorizativa pertenece a las funciones GSS y a la canonización del mecanismo.

Además, RFC 5178 se apoyó en RFC 3490, posteriormente sustituido por la familia IDNA2008. Una implementación moderna necesita registrar el perfil aplicado, la A-label o U-label relevante y el principal final. Actualizar el tratamiento de dominios sin registrar el cambio puede alterar qué credencial se busca aunque la pantalla parezca igual.

El operador necesita dos pruebas: qué aprobó una persona y qué autenticó el mecanismo.

Kerberos mapea, no aplana

RFC 5179 lleva la estructura a Kerberos V. El servicio se convierte en el primer componente del principal, el host en el segundo y el dominio en el tercero. Se recomienda NT-SRV-HST-DOMAIN con valor 12. El realm no es una copia libre del campo dominio: por seguridad debe derivarse a partir del hostname conforme a la lógica Kerberos.

La separación impide que una entrada afirme a la vez su ámbito de servicio y la autoridad de autenticación que la validará. Para operar, hay que conservar el principal canónico, el realm consultado, el KDC efectivo y la credencial que respondió.

Un clúster es una técnica de disponibilidad. Solo se convierte en un servicio autorizado cuando cada miembro recibe una delegación delimitada y el cliente exige esa delimitación. El número de servidores nunca reemplaza el expediente de autoridad.

Sources