Wie definiere ich einen SRV Record?
Ein SRV Record bei uns im DNS kann z. B. so aussehen:
Beispiel:
| Recordname | RR-Type | Ziel | Priorität | TTL |
|---|---|---|---|---|
| _sip._tls | SRV | 1 443 sipdir.online.lync.com | 100 | 3600 |
Der Recordname ergibt sich also aus dem Dienst und dem Protokoll.
Ziel ergibt sich aus Gewichtung, Port und Server, mit Leerzeichen getrennt. In Ziel kommen also exakt zwei Leerzeichen vor.
Was ist ein SRV-Eintrag und wann brauchen Sie ihn?
Ein SRV-Eintrag (Service Record) ist ein DNS-Eintragstyp, der beschreibt, wie Clients einen Dienst für eine Domain finden sollen. Anders als ein A- oder CNAME-Eintrag zeigt ein SRV-Eintrag nicht nur auf einen Host, sondern gibt auch den Port an und enthält Routing-Informationen wie Priorität und Gewicht. So können Anwendungen automatisch den richtigen Server-Endpunkt finden, ohne dass Adressen fest codiert werden müssen.
SRV-Einträge werden häufig für Dienste wie VoIP/SIP, XMPP-Chat, bestimmte Microsoft-Dienste und andere Anwendungen benötigt, die die Dienstermittlung über DNS unterstützen. In der Regel erstellen Sie einen SRV-Eintrag, wenn ein Anbieter oder Dienstleister Ihnen eine bestimmte SRV-Definition gibt und Sie anweist, diese in der DNS-Zone Ihrer Domain zu veröffentlichen. Der SRV-Eintrag teilt der Client-Software z.B. mit: „Für diesen Dienst und dieses Protokoll verbinde Dich mit diesem Host und Port und verwende diese Werte für Failover und Lastverteilung."
Wenn Ihr Dienstanbieter keinen SRV-Eintrag ausdrücklich verlangt, füge keinen hinzu. Dies ist besonders wichtig für Dienste wie gehostete E-Mails, also Webmail, bei denen die Standardzustellung von MX-Einträgen abhängt und das Hinzufügen unnötiger SRV-Einträge die Clientkonfiguration oder die automatische Erkennung verwirren kann. Falsche SRV-Einträge können dazu führen, dass Clients eine Verbindung zum falschen Host herstellen oder gar keine Verbindung herstellen können.
Erläuterung der Felder eines SRV-Eintrags (Priorität, Gewicht, Port, Ziel)
SRV-Einträge haben mehrere Felder, die steuern, wie Clients den richtigen Zielserver auswählen. Wenn Sie diese Felder verstehen, können Sie die Werte richtig eingeben und die Anweisungen des Anbieters richtig interpretieren.
Priorität: Legt die Reihenfolge für das Failover fest. Eine niedrigere Zahl ist besser. Clients versuchen es zuerst mit der niedrigsten Priorität und greifen nur dann auf höhere Prioritäten zurück, wenn das bevorzugte Ziel nicht verfügbar ist.
Gewichtung: Legt die Lastverteilung zwischen Einträgen mit derselben Priorität fest. Eine höhere Gewichtung bedeutet normalerweise eine höhere Wahrscheinlichkeit, ausgewählt zu werden, aber das Verhalten kann je nach Client-Implementierung variieren.
Port: Der TCP/UDP-Port, auf dem der Dienst empfangsbereit ist. Dies ist entscheidend, da ein falscher Port die Verbindung unterbricht, selbst wenn der Zielhost korrekt ist.
Ziel: Der Hostname des Servers, der den Dienst bereitstellt (z. B. sip.example.tld).
Im DNS-Editor von hosting.de werden diese Felder normalerweise wie folgt in die SRV-Einträge eingegeben: Der Name des Eintrags spiegelt den Dienst und das Protokoll wider, und das Zielfeld enthält das Gewicht, den Port und den Server in einem bestimmten Format. Halten Sie sich immer genau an die numerischen Werte Ihres Providers für Priorität/Gewicht/Port, da schon kleine Abweichungen das Verhalten verändern oder den Client daran hindern können, den Dienst zu finden.
So erstellst Du den Datensatznamen richtig (Dienst + Protokoll)
Der SRV-Datensatzname besteht aus zwei Bezeichnungen: dem Dienst und dem Protokoll. Das Standardformat lautet:
_service._protocol
Beide Bezeichnungen beginnen mit einem Unterstrich. Der Dienst gibt an, was gesucht wird (z. B. _sip), und das Protokoll gibt an, wie es erreicht wird (z. B. _tcp, _udp oder manchmal _tls, je nach Definition des Anbieters). Im Beispiel hosting.de wird ein SIP-over-TLS-Eintragsname als _sip._tls angezeigt.
Praktische Regeln:
Verwenden Sie genau die von Ihrem Anbieter bereitgestellten Dienst-/Protokollbezeichnungen. „Normalisieren" sie diese nicht.
Behalten Sie die Unterstriche bei. Wenn Sie diese weglassen, wird der Eintrag häufig von Clients ignoriert.
Geben Sie nur den relativen Namensteil ein, den der DNS-Zonen-Editor erwartet. Duplizieren Sie den Domainnamen nicht, es sei denn, die Benutzeroberfläche verlangt dies ausdrücklich.
Wenn mehrere SRV-Einträge für denselben Dienst existieren, stellen Sie sicher, dass jeder den richtigen Namen verwendet und dass Prioritäten/Gewichtungen absichtlich festgelegt wurden. Falsche Benennungen sind einer der häufigsten Gründe dafür, dass SRV im Panel „korrekt aussieht", die Anwendung den Dienst aber dennoch nicht finden kann.
Validierung und Fehlerbehebung: Bestätigung der SRV-Auflösung und Behebung häufiger Fehler
Nachdem Sie einen SRV-Eintrag gespeichert haben, überprüfen Sie ihn, bevor Sie davon ausgehen, dass der Dienst richtig konfiguriert ist. SRV-Probleme kommen normalerweise von Formatierungsfehlern, falschen Hostnamen, falschen Ports oder DNS-Caching.
Validierungsablauf:
Stellen Sie sicher, dass der Eintrag genau wie beabsichtigt in der DNS-Zone angezeigt wird (Name, Priorität und Format des Zielwerts).
Fragen Sie die SRV-Auflösung mit einem DNS-Tool (z. B. dig oder nslookup) aus möglichst mehr als einem Netzwerk ab, da Caches unterschiedlich sein können.
Überprüfe, ob der Zielhostname selbst zur richtigen IP-Adresse aufgelöst wird (A/AAAA-Einträge müssen für das Ziel vorhanden sein).
Häufige Fehlerursachen:
Falsche Abstände im Zielfeld: Einige Editoren erfordern ein genaues Format (z. B. strenge Abstände zwischen den Feldern). Wenn im Feld zwei Leerzeichen angegeben sind, halten Sie sich genau daran.
Falsche Dienst-/Protokollbezeichnung: _tcp vs. _udp (oder herstellerspezifisches _tls) muss mit den Erwartungen der Anwendung übereinstimmen.
Falscher Port: Selbst mit korrektem DNS schlagen Clients fehl, wenn der Dienst diesen Port nicht überwacht.
DNS-Propagierung/TTL: Es kann eine Weile dauern, bis Änderungen global sichtbar werden; vermeiden Sie wiederholte Bearbeitungen während des Propagierungsfensters.
Wenn der Dienst nach korrekter DNS-Auflösung immer noch nicht funktioniert, müssen Sie als Nächstes überprüfen, ob der Dienst auf dem Zielhost und -port tatsächlich erreichbar ist (Netzwerk-/Firewall-/Anwendungskonfiguration). DNS sagt den Clients nur, wohin sie gehen sollen; es kann den Dienst nicht dazu bringen, zu antworten.