Globaler SRV-Record Checker
Während Standard-A- und AAAA-Records darauf beschränkt sind, einen Domainnamen in eine IP-Adresse zu übersetzen, ist der SRV-Record (Service) weitaus komplexer. Der in RFC 2782 definierte SRV-Record etabliert einen standardisierten Weg, um den exakten Hostnamen, das Protokoll und die genaue Portnummer für spezifische Netzwerkanwendungen zu definieren. Sie sind das Rückgrat der Enterprise-Service-Discovery und werden intensiv für Microsoft Active Directory, SIP/VoIP-Routing, XMPP-Instant-Messaging und massive Multiplayer-Serverarchitekturen (wie das Auflösen von _minecraft._tcp.example.com) genutzt.
Syntax und Port Binding
Ein SRV-Record ist an seiner strengen Formatierungsstruktur sofort erkennbar. Der Record-Name muss mit einem Unterstrich beginnen, der den Dienst angibt, gefolgt von einem Unterstrich für das Transportprotokoll, angehängt an die Basisdomain (z. B. _sip._tls.example.com). Der resultierende Payload liefert dem verbindenden Client vier spezifische Datenpunkte: die Priority (Priorität), das Weight (Gewicht), den Ziel-Port und den kanonischen Ziel-Hostnamen. Dies ermöglicht es Administratoren, mehrere unterschiedliche Dienste auf einer einzigen IP-Adresse mit Nicht-Standard-Ports auszuführen, ohne dass Endbenutzer sich Portnummern merken und in ihre Clients eintippen müssen.
Natives Failover und gewichtetes Load Balancing
Die leistungsstärkste Funktion des SRV-Records ist seine native, mehrstufige Routing-Logik. Der Priority-Integer verhält sich exakt wie bei einem MX-Record; verbindende Clients werden immer versuchen, einen Handshake mit dem Server mit der niedrigsten Priorität zuerst auszuhandeln. Dies etabliert sofortige Failover-Redundanz. Teilen sich mehrere Records exakt dieselbe Priorität, wird der Weight-Integer getriggert. Dieser fungiert als proportionaler Load Balancer. Wenn Server A ein Gewicht von 75 und Server B ein Gewicht von 25 hat, routet die Client-Anwendung 75 % der neuen Verbindungen an Server A. Dies ermöglicht es Engineers, Traffic intelligent über Cluster mit unterschiedlichen Hardwarekapazitäten zu routen.
Warum HTTP SRV-Records ignoriert
Eine häufige Frage von Junior-Entwicklern ist, warum Web-Traffic (HTTP/HTTPS) keine SRV-Records nutzt, um natives Load Balancing zu erreichen. Die Antwort ist rein historischer Natur. Als SRV-Records standardisiert wurden, waren die architektonischen Konventionen, dass HTTP strikt auf Port 80 und HTTPS auf Port 443 arbeitet, bereits universell in jedem Webbrowser fest einprogrammiert. Eine Umstellung des Webs auf SRV-Lookups hätte einen massiven Auflösungs-Penalty (durch zusätzliche Round-Trips) für einen marginalen Nutzen bedeutet. Stattdessen verlässt sich HTTP auf Application-Layer-Load-Balancer und Anycast-IP-Routing.