全球 SRV 紀錄檢查器
雖然標準的 A 和 AAAA 紀錄僅限於將網域名稱轉換為 IP 位址，但 SRV (Service) 紀錄的複雜度遠高於此。定義於 RFC 2782 中的 SRV 紀錄建立了一種標準化方法，可為特定的網路應用程式定義確切的主機名稱、協定，以及精確的連接埠號碼。它們是企業服務探索 (service discovery) 的骨幹，被大量用於 Microsoft Active Directory、SIP/VoIP 路由、XMPP 即時通訊，以及大型多人伺服器架構（例如解析 _minecraft._tcp.example.com）。
語法與 Port Binding
SRV 紀錄可透過其嚴格的格式結構立即識別。紀錄名稱必須以表示服務的底線 (underscore) 開頭，接著是表示傳輸協定的底線，附加到基礎網域（例如 _sip._tls.example.com）。產生的 Payload 會向連線的用戶端傳遞四個特定的資料點：優先權 (Priority)、權重 (Weight)、目標連接埠 (Port) 和標準的目標主機名稱 (Hostname)。這允許管理員在單一 IP 位址上使用非標準連接埠執行多個不同的服務，而不需要終端使用者記住並在他們的用戶端中輸入連接埠號碼。
原生 Failover 與加權負載平衡
SRV 紀錄最強大的功能是其原生的、多層次的路由邏輯。Priority 整數的運作方式與 MX 紀錄完全相同；連線的用戶端將始終嘗試先與具有最低優先權的伺服器協商 handshake。這建立了立即的 Failover 備援。如果多筆紀錄共享完全相同的優先權，則會觸發 Weight 整數。它充當比例式的負載平衡器。如果伺服器 A 的權重為 75，而伺服器 B 的權重為 25，則用戶端應用程式會將 75% 的新連線路由到伺服器 A。這使得工程師能夠在具有不同硬體容量的叢集 (cluster) 中智慧地路由流量。
為何 HTTP 忽略 SRV 紀錄
初階開發人員常見的問題是，為什麼網頁流量 (HTTP/HTTPS) 不利用 SRV 紀錄來實現原生負載平衡。答案純粹是歷史原因。在 SRV 紀錄標準化時，HTTP 嚴格在連接埠 80 上運作以及 HTTPS 在連接埠 443 上運作的架構慣例已經普遍地被寫死 (hardcoded) 到每一個網頁瀏覽器中。將 Web 轉移到 SRV 查詢會增加巨大的解析懲罰（需要額外的往返 round-trips），但帶來的邊際效益卻很小。相反地，HTTP 依賴於應用程式層 (application-layer) 的 Load Balancers 和 Anycast IP 路由。