Resumen

  • DNS SRV permitió que un dominio publicara, para un servicio y transporte concretos, varios destinos, sus puertos, niveles primarios y de reserva y una inclinación estadística entre servidores del mismo nivel.
  • Priority y Weight expresan decisiones distintas. El cliente intenta primero el nivel alcanzable con el número más bajo; solo dentro de ese nivel construye un orden aleatorio ponderado.
  • El registro no demuestra salud, autorización ni identidad. El cliente aún resuelve el destino canónico, abre el transporte y el puerto publicados y valida la aplicación que responde.

Cuando el servicio dependía de una convención local

El DNS original asociaba nombres de host con direcciones. El programa solía aportar lo demás: un puerto conocido, una entrada de /etc/services o el nombre exacto de una máquina entregado por el operador. Nombre público, servidor, puerto y plan de respaldo quedaban unidos en una sola suposición.

RFC 2052 propuso en octubre de 1996 un registro experimental para preguntar otra cosa: dónde se encuentra un servicio dentro de un dominio. La respuesta podía nombrar varios destinos y acompañarlos con prioridad, peso y puerto.

En febrero de 2000, RFC 2782 sustituyó aquella especificación como Proposed Standard. Quería que un administrador pudiera mover el servicio entre hosts con poca fricción, usar varios servidores y distinguir principales de reservas. La IANA conserva el tipo 33 con la descripción Server Selection.

Servicio, transporte y dominio dejaron de ser una sola etiqueta

Un cliente LDAP que busca TCP bajo example.com consulta _ldap._tcp.example.com. Los dos rótulos de la izquierda declaran servicio y transporte; el resto identifica el ámbito administrativo. RFC 2782 añadió los guiones bajos al reemplazar RFC 2052 para reducir colisiones con nombres DNS ordinarios y aclaró el algoritmo de pesos.

La coordinación evolucionó después. RFC 6335 reunió los procedimientos de nombres de servicio y números de puerto. Un nombre puede servir al descubrimiento SRV aunque no tenga puerto asignado. Su registro evita duplicidad; no avala el producto ni convierte el tráfico en legítimo.

RFC 8552 creó en 2019 el registro de nombres DNS globales con guion bajo. RFC 8553 adaptó las especificaciones que usaban SRV a ese registro sin romper las instalaciones existentes. Lo que empezó como defensa contra colisiones obtuvo una asignación auditable.

Cuatro campos no forman una sola política

Los datos SRV contienen Priority, Weight, Port y Target.

Priority crea niveles de conmutación. El cliente debe intentar un destino alcanzable del menor número. Un nivel superior no es un igual que recibe menos carga: es reserva hasta que el inferior deja de servir.

Weight solo ordena registros que comparten prioridad. El cliente suma los pesos, extrae un número uniforme, elige mediante una suma acumulada, retira el registro y repite. La zona publica una proporción; el cliente produce una secuencia. Un peso cero tampoco equivale a prohibición absoluta cuando existen pesos positivos: el algoritmo le deja una probabilidad muy pequeña.

El ejemplo de RFC 2782 ofrece dos hosts de prioridad cero con pesos uno y tres. En muchas primeras elecciones independientes, el segundo tenderá a recibir tres cuartas partes. Dos hosts de prioridad uno solo aparecen si falla la pareja preferida. Ningún usuario aislado recibe una garantía de proporción exacta.

Weight no mide carga instantánea. Las colas, CPU y latencia cambian demasiado rápido para una respuesta DNS cacheada. Perseguirlas con TTL mínimos elevaría la carga de DNS y debilitaría la fiabilidad. El peso representa diferencias estáticas, como capacidad relativa o una conexión más amplia.

Port libera otra dependencia del cliente. Puede coincidir con el número registrado, pero no está obligado. El operador puede trasladar un servicio sin actualizar el fichero local de cada equipo ni conservar un puerto privilegiado de Unix.

Target debe resolver directamente a direcciones y no puede ser un alias. El cliente usa A/AAAA entregados como datos adicionales o los consulta. SRV termina en un host canónico; no autoriza una cadena oculta de CNAME o DNAME.

Ausencia y negativa explícita

Un único destino . declara que ese servicio no está disponible en el dominio. No niega la existencia del dominio ni de otros servicios. Es información positiva y acotada.

La ausencia de un SRV utilizable tenía otra ruta: consultar la dirección del dominio y probar la convención anterior. RFC 2782 consideraba inútil esperar que todos los clientes se actualizaran de una vez. Recomendaba mantener direcciones razonables para programas antiguos, pero no mostrar allí un servidor exclusivamente de reserva si esos programas lo tratarían como principal.

La compatibilidad era una decisión real, no un detalle. Mantenerla preservaba acceso y a la vez podía saltarse prioridad y puerto. Retirarla hacía coherente la nueva política y podía dejar atrás software heredado.

El DNS publicaba candidatos, no un servicio probado

El cliente lee todo el conjunto, agrupa por prioridad, ordena con pesos, resuelve direcciones y prueba transporte, dirección y puerto. Una respuesta auténtica demuestra lo publicado por la autoridad DNS. No demuestra que el proceso esté sano, que la aplicación tenga la identidad correcta, que el host consienta la referencia o que los destinos pertenezcan a la misma organización.

La seguridad se vuelve más visible porque el registro expresa más. Un falsificador puede suministrar un puerto falso además de nombre y dirección. Un dominio puede apuntar hacia un tercero y dirigirle tráfico indeseado. Puertos finos complican filtros y exigen cooperación entre operadores de DNS y red.

El contrato tampoco nace por capricho de una zona. La especificación de la aplicación debe autorizar SRV, definir el nombre simbólico y tratar la seguridad. El protocolo determina si la consulta significa algo; el dominio rellena el conjunto; el cliente ejecuta; el destino sigue teniendo que probar el servicio.

Fuentes y límite probatorio

La reconstrucción usa solo RFC 2052, RFC 2782, RFC 6335, RFC 8552, RFC 8553 y los parámetros DNS de IANA. Prueban semántica y evolución, no adopción presente, ahorro de latencia, conformidad de productos ni disponibilidad viva.

La aportación de SRV fue precisa: un servicio pudo conservar su nombre mientras cambiaban host y puerto. La respuesta DNS orientaba el intento, pero nunca heredaba la autoridad de la aplicación que aún debía responder.