Mentre i record A e AAAA standard sono limitati a tradurre un nome di dominio in un indirizzo IP, il record SRV (Service) è di gran lunga più complesso. Definito nella RFC 2782, il record SRV stabilisce un modo standardizzato per definire hostname esatti, protocollo e numero di porta preciso per specifiche applicazioni di rete. È la spina dorsale della discovery dei servizi enterprise, usato intensivamente per Microsoft Active Directory, routing SIP/VoIP, messaggistica istantanea XMPP e architetture di server multiplayer massive (come la risoluzione di _minecraft._tcp.example.com).

Sintassi e binding delle porte

Un record SRV è immediatamente riconoscibile dalla sua struttura di formattazione rigida. Il nome del record deve iniziare con un underscore che indica il servizio, seguito da un underscore che indica il protocollo di trasporto, aggiunti al dominio di base (es. _sip._tls.example.com). Il payload risultante fornisce al client che si connette quattro punti dati specifici: la Priority, la Weight, la porta target e l'hostname target canonico. Questo consente agli amministratori di far girare più servizi distinti su un singolo indirizzo IP usando porte non standard, senza richiedere agli utenti finali di memorizzare e digitare numeri di porta nei propri client.

Failover nativo e load balancing pesato

La funzionalità più potente del record SRV è la sua logica di routing nativa a più livelli. L'intero Priority agisce esattamente come un record MX: i client in connessione cercheranno sempre prima di negoziare l'handshake con il server di priorità più bassa. Questo stabilisce una ridondanza di failover immediata. Se più record condividono la stessa Priority, scatta l'intero Weight, che funge da load balancer proporzionale. Se il Server A ha peso 75 e il Server B ha peso 25, l'applicazione client instraderà il 75% delle nuove connessioni al Server A. Questo consente agli ingegneri di distribuire il traffico in modo intelligente tra cluster con capacità hardware diverse.

Perché HTTP ignora i record SRV

Una domanda comune dei sviluppatori junior è perché il traffico web (HTTP/HTTPS) non utilizzi i record SRV per ottenere un load balancing nativo. La risposta è puramente storica: al momento della standardizzazione dei record SRV, le convenzioni architetturali di HTTP che opera esclusivamente sulla porta 80 e HTTPS sulla porta 443 erano già universalmente hardcodate in ogni browser web. Spostare il web sulle ricerche SRV avrebbe aggiunto una penalità enorme alla risoluzione (con round-trips aggiuntivi) per un beneficio marginale. Invece, HTTP si affida ai load balancer a livello applicativo e al routing IP Anycast.