SRV-Record im DNS verständlich erklärt: Service-Discovery

Der SRV-Record (kurz für Service Record) ist ein spezialisierter DNS-Eintrag, der zur Service-Discovery (Dienste-Erkennung) im Netzwerk dient. Im Gegensatz zu A-Records, die lediglich einen Namen mit einer IP-Adresse verknüpfen, definiert ein SRV-Record, unter welchem Port, mit welchem Protokoll (TCP/UDP) und auf welchem konkreten Ziel-Server ein bestimmter Dienst (z. B. LDAP oder SIP) für eine Domain erreichbar ist.

Während ein MX-Record nur für E-Mail eine vergleichbare Priorisierung kennt, verallgemeinert der SRV-Record dieses Prinzip auf beliebige Dienste – inklusive Portangabe. Das macht ihn zum zentralen Baustein der automatischen Dienste-Erkennung in der gesamten DNS-Hierarchie.

Aufbau und Syntax eines SRV-Records

Der Aufbau eines SRV-Records ist streng standardisiert und weicht vom Schema einfacher DNS-Einträge ab. Das offizielle Format lautet:

_[Service]._[Protokoll].[Domain].   [TTL]   IN   SRV   [Priorität] [Gewicht] [Port] [Ziel]

Ein reales Beispiel für einen SIP-Telefonie-Dienst:

_sip._tcp.example.com.      3600    IN    SRV    10 60 5060 sipserver.example.com.

• Service (_sip): Der Name des Dienstes, immer eingeleitet mit einem Unterstrich.
• Protokoll (_tcp): Das Transportprotokoll (meist _tcp oder _udp), ebenfalls mit Unterstrich.
• Domain (example.com.): Die Domain, für die der Dienst angeboten wird.
• Time to Live (TTL - 3600): Die Cache-Dauer.
• Klasse (IN): Internet.
• Typ (SRV): Der Eintragstyp.
• Priorität (10): Legt fest, welcher Server bevorzugt werden soll. Niedrigere Werte werden zuerst kontaktiert.
• Gewicht (60): Ein Wert zur Lastverteilung bei gleicher Priorität.
• Port (5060): Der Port, auf dem der Dienst lauscht (z. B. 5060 für SIP).
• Ziel (sipserver.example.com.): Der Hostname des physischen Servers, der den Dienst bereitstellt (muss einen A- oder AAAA-Record besitzen).

---

SRV-Record im Vergleich zu verwandten Einträgen

Der SRV-Record wird häufig mit anderen DNS-Einträgen verwechselt, die ebenfalls auf einen Server verweisen. Die folgende Tabelle grenzt sie ab:

Record	Verweist auf	Kennt Port?	Kennt Priorität/Gewicht?	Typischer Einsatz
SRV	Hostname + Port	ja	ja	Service-Discovery (SIP, LDAP, XMPP)
MX	Hostname (Mailserver)	nein (fest 25)	nur Priorität	E-Mail-Zustellung
A	IPv4-Adresse	nein	nein	Hostname → IP
CNAME	anderer Hostname	nein	nein	Alias auf anderen Namen

Wichtig: Der SRV-Record ist der einzige Standard-Record, der Port, Priorität und Gewicht zugleich transportiert. Genau das macht ihn für Dienste interessant, die nicht auf dem Standardport laufen oder über mehrere Server verteilt sind.

---

Typische SRV-Record-Fehler und ihre Folgen

Fehlerhafte SRV-Records sind tückisch, weil betroffene Dienste oft ohne klare Fehlermeldung einfach «nicht gefunden» werden. Diese Tabelle zeigt die häufigsten Fehlkonfigurationen:

Fehler	Symptom	Lösung
Ziel ist ein CNAME	sporadische Auflösungsfehler	Ziel direkt auf A-/AAAA-Hostname setzen
Fehlender Unterstrich (sip statt _sip)	Record wird nie gefunden	Service & Protokoll immer mit _ einleiten
Falscher Port	Verbindung wird abgewiesen	Port mit dem real lauschenden Dienst abgleichen
Ziel ohne A-Record	Client findet Dienst, aber keine IP	A-/AAAA-Record für den Ziel-Host anlegen
Zu hohe TTL bei Umzug	Clients nutzen alten Server weiter	TTL vor Migration absenken

---

Praxisbeispiel: Microsoft 365 Autodiscover

Ein häufiger realer Einsatz ist die automatische Konfiguration von E-Mail-Clients (Autodiscover) für einen Mailserver, der nicht auf der Hauptdomain liegt:

_autodiscover._tcp.example.com. 3600 IN SRV 0 0 443 autodiscover.outlook.com.

• Vorher (ohne SRV): Outlook sucht die Konfiguration nur unter autodiscover.example.com. Liegt dort kein passender Eintrag, scheitert die automatische Einrichtung und Nutzende müssen Server, Port und Protokoll manuell eintragen.
• Nachher (mit SRV): Der Client liest den SRV-Record aus, erfährt Ziel-Host (autodiscover.outlook.com) und Port (443) und richtet das Postfach vollautomatisch ein. Das Zusammenspiel mit korrekten MX-Records sorgt dafür, dass sowohl Zustellung als auch Client-Konfiguration reibungslos funktionieren.

Die Lehre: Der SRV-Record entkoppelt den «Dienstnamen» von der konkreten Server-Adresse. Wandert der Dienst auf einen anderen Host oder Port, genügt eine Änderung am SRV-Record – die Clients folgen automatisch.

---

Lastverteilung und Ausfallsicherheit

Das Zusammenspiel von Priorität und Gewicht im SRV-Record ermöglicht ein ausgeklügeltes Traffic-Management direkt auf DNS-Ebene:

_service._tcp.example.com.  IN  SRV  10 70 8080 host1.example.com.
_service._tcp.example.com.  IN  SRV  10 30 8080 host2.example.com.
_service._tcp.example.com.  IN  SRV  20  0 8080 backup.example.com.

1. Ein Client filtert zuerst nach der niedrigsten Priorität (10).
2. Er sieht zwei Server (host1 und host2) mit Priorität 10. Er verteilt die Anfragen gemäss dem Gewicht: host1 erhält 70 % des Traffics, host2 erhält 30 %.
3. Fallen sowohl host1 als auch host2 aus, weicht der Client auf die nächsthöhere Priorität 20 aus und sendet alle Anfragen an backup.example.com.

[!TIP] Fehler in SRV-Records blockieren das automatische Auffinden von VoIP-Telefonen oder Active-Directory-Diensten. Prüfen Sie die DNS-Auflösung Ihrer Service-Einträge bequem mit dem DNS Check auf balou.tools.