Zum Inhalt springen
IPeek

SRV-Abfrage

Dienst-Standort-Einträge

Wird geprüft…

Was ist ein SRV-Record?

Ein SRV-Record (Service) gibt den Hostnamen und Port für einen bestimmten Dienst bekannt – etwa SIP, XMPP, LDAP oder Microsoft Autodiscover – zusammen mit Priorität und Gewicht zur Lastverteilung. Anders als ein A-Record teilt er Clients nicht nur mit, wo ein Dienst liegt, sondern auch auf welchem Port, sodass Anwendungen Dienste ohne fest codierte Konfiguration finden können. Fragen Sie sie über die Form _service._proto.domain ab.

So funktioniert das SRV-Record-Format

Ein SRV-Record wird nach einem unverwechselbaren Muster benannt: _service._proto.domain, zum Beispiel _sip._tcp.example.com. Die Unterstriche verhindern Kollisionen mit gewöhnlichen Hostnamen. Die Daten des Records enthalten vier Werte: Priorität, Gewicht, Port und Ziel. Priorität funktioniert wie bei MX – niedrigere Zahlen werden zuerst versucht. Gewicht verteilt die Last unter Zielen derselben Priorität, wobei höhere Gewichte proportional mehr Verkehr erhalten. Port ist der TCP- oder UDP-Port, auf dem der Dienst lauscht, und Ziel ist der Hostname, der ihn bereitstellt und der einen eigenen A- oder AAAA-Record haben muss.

So lesen Sie Ihre SRV-Lookup-Ergebnisse

IPeek gibt für den abgefragten Dienstnamen Priorität, Gewicht, Port und Ziel-Host jedes SRV-Records zurück. Lesen Sie zuerst die Priorität: Clients nutzen die Ziele mit der niedrigsten Priorität, bevor sie auf höhere zurückgreifen. Unter gleichen Prioritäten entscheidet das Gewicht über den Anteil des Verkehrs, den jedes Ziel erhält. Bestätigen Sie, dass der Port zum erwarteten Dienst passt – 5060 für SIP, 389 für LDAP, 443 für viele Autodiscover-Setups. Prüfen Sie, dass jedes Ziel zu einem gültigen Host auflöst. Ein leeres Ergebnis bedeutet, dass der Dienst unter diesem Namen auf der Domain nicht bekannt gegeben wird.

Wann Sie SRV-Records benötigen

SRV-Records sind immer dann wichtig, wenn Clients einen Dienst automatisch entdecken müssen, statt sich auf feste Einstellungen zu verlassen. Microsoft Teams, Skype for Business und SIP-Anbieter nutzen sie, um Sprach- und Präsenzserver zu finden. XMPP-Chat, LDAP-Verzeichnisabfragen, Minecraft-Server und Kerberos hängen alle von der SRV-Erkennung ab. Der große Vorteil ist Flexibilität: Verschieben Sie einen Dienst auf einen neuen Host oder Port oder verteilen Sie ihn über mehrere Server, und Clients folgen den SRV-Records ohne Neukonfiguration. Wenn ein Dienst einen bestimmten _service._proto-Namen erfordert, veröffentlichen Sie einen passenden SRV-Record, sonst finden Clients ihn nicht.

Häufig gestellte Fragen

Was bedeutet das Namensformat _service._proto.domain?

Dieses Muster benennt einen SRV-Record nach dem Dienst und Protokoll, das er beschreibt. _service ist die Dienstbezeichnung (wie _sip oder _ldap), _proto ist der Transport (_tcp oder _udp) und domain ist Ihre Domain. Zum Beispiel gibt _sip._tcp.example.com SIP über TCP bekannt. Die führenden Unterstriche bewahren diese Bezeichnungen davor, mit normalen Hostnamen zu kollidieren.

Wie funktionieren Priorität und Gewicht in einem SRV-Record?

Priorität und Gewicht steuern, welches Ziel ein Client wählt. Priorität funktioniert wie bei MX-Records: Clients versuchen zuerst die Ziele mit der niedrigsten Priorität und greifen auf höhere Zahlen zurück. Unter Zielen, die sich eine Priorität teilen, legt das Gewicht den Anteil des Verkehrs fest, den jedes erhält, sodass ein höheres Gewicht mehr Verbindungen anzieht. Zusammen ermöglichen sie sowohl Failover als auch Lastverteilung.

Was ist der Unterschied zwischen einem SRV-Record und einem A-Record?

Ein A-Record bildet einen Hostnamen auf eine IP-Adresse ab, während ein SRV-Record zusätzlich den Port angibt und Priorität und Gewicht für einen benannten Dienst hinzufügt. SRV lässt Clients sowohl wo als auch auf welchem Port ein Dienst läuft entdecken, plus wie die Last zu verteilen ist – was ein einfacher A-Record nicht ausdrücken kann. SRV-Ziele verlassen sich zur Auflösung weiterhin auf A-Records.

Welche Dienste nutzen häufig SRV-Records?

SIP- und VoIP-Systeme, XMPP-Chat, LDAP und Active Directory, Kerberos, Microsoft Teams und Skype for Business und sogar Minecraft-Server nutzen häufig SRV-Records. Jedes Protokoll, das von automatischer Diensterkennung ohne fest codierte Host- und Port-Einstellungen profitiert, ist ein Kandidat. Der Client muss so geschrieben sein, dass er den jeweiligen _service._proto-Namen abfragt.

Warum liefert meine SRV-Abfrage keine Ergebnisse?

Ein leeres SRV-Ergebnis bedeutet meist, dass unter genau diesem _service._proto.domain-Namen kein Record veröffentlicht ist. Prüfen Sie, dass Dienstbezeichnung, Protokoll und Domain korrekt geschrieben sind, einschließlich der Unterstriche. Der Dienst nutzt möglicherweise einen anderen Namen als erwartet, oder der Record existiert schlicht nicht. Bestätigen Sie den genauen Namen, den die Client-Anwendung benötigt.