Global SRV Record Checker
Mientras que los registros A y AAAA estándar se limitan a traducir un nombre de dominio en una dirección IP, el registro SRV (Service) es mucho más complejo. Definido en RFC 2782, el registro SRV establece una forma estandarizada de definir el nombre de host exacto, el protocolo y el número de puerto preciso para aplicaciones de red específicas. Son la columna vertebral del descubrimiento de servicios empresariales, muy utilizados para Microsoft Active Directory, enrutamiento SIP/VoIP, mensajería instantánea XMPP y arquitecturas de servidores multijugador masivos (como resolver _minecraft._tcp.example.com).
Sintaxis y Vinculación de Puertos
Un registro SRV es instantáneamente reconocible por su rígida estructura de formato. El nombre del registro debe comenzar con un guion bajo denotando el servicio, seguido de un guion bajo denotando el protocolo de transporte, añadido al dominio base (por ejemplo, _sip._tls.example.com). El payload resultante entrega cuatro puntos de datos específicos al cliente que se conecta: la Prioridad, el Peso (Weight), el Puerto objetivo y el Nombre de host objetivo canónico. Esto permite a los administradores ejecutar múltiples servicios distintos en una sola dirección IP usando puertos no estándar, sin requerir que los usuarios finales memoricen y escriban números de puerto en sus clientes.
Failover Nativo y Balanceo de Carga Ponderado
La característica más poderosa del registro SRV es su lógica de enrutamiento nativa y de múltiples niveles. El entero de Prioridad actúa exactamente como un registro MX; los clientes que se conectan siempre intentarán negociar un handshake con el servidor de prioridad más baja primero. Esto establece una redundancia de failover inmediata. Si múltiples registros comparten exactamente la misma Prioridad, se activa el entero de Peso (Weight). Esto actúa como un balanceador de carga proporcional. Si el Servidor A tiene un peso de 75 y el Servidor B tiene un peso de 25, la aplicación cliente enrutará el 75% de las nuevas conexiones al Servidor A. Esto permite a los ingenieros enrutar el tráfico de manera inteligente a través de clusters con capacidades de hardware variables.
Por Qué HTTP Ignora los Registros SRV
Una pregunta común de los desarrolladores junior es por qué el tráfico web (HTTP/HTTPS) no utiliza registros SRV para lograr un balanceo de carga nativo. La respuesta es puramente histórica. Para cuando se estandarizaron los registros SRV, las convenciones arquitectónicas de HTTP operando estrictamente en el puerto 80 y HTTPS en el puerto 443 ya estaban universalmente incrustadas en el código de cada navegador web. Cambiar la web a búsquedas SRV habría añadido una penalización de resolución masiva (requiriendo round-trips adicionales) por un beneficio marginal. En cambio, HTTP depende de balanceadores de carga a nivel de aplicación y enrutamiento IP Anycast.