SRV Resource Record

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Mittels SRV (Service) Resource Records kann per DNS propagiert werden, welche IP-basierenden Dienste in einer Domain angeboten werden. Zu jedem Dienst werden weitere Informationen geliefert, wie zum Beispiel der Server-Name, der diesen Dienst bereitstellt.

Ein Dienst wird durch den Namen und das mit einem Punkt angehängte Protokoll bezeichnet. Beiden Komponenten wird ein _ vorangestellt, um Verwechslungen mit anderen Domain-Namen zu verhindern.

Aufbau[Bearbeiten | Quelltext bearbeiten]

Service
Dienst + Protokoll + Domain
TTL (Time to live)
gibt an, wie lange dieser RR (Resource Record) im Cache gehalten werden darf
IN
Internet
SRV
Der String "SRV"
Priorität
falls mehrere identische Dienste angeboten werden, hat die niedrigste Priorität Vorrang (die Dienste mit höherem Prioritätswert dienen im Falle eines Ausfalls als Ersatz)
Gewicht
innerhalb gleicher Priorität sollte die Wahrscheinlichkeit für die Auswahl eines Dienstes relativ zum Gewicht sein (bei einem Dienst mit Gewicht 3 und einem mit Gewicht 2 sollte also im Mittel zu 60 % der erste Dienst gewählt werden – dies dient zur Lastverteilung)
Port
TCP- oder UDP-Portnummer
Server
Server, der diesen Dienst bereitstellt (dabei darf es sich weder um eine IP-Adresse noch um einen Alias, also eine Domain mit einem CNAME RR, handeln)

Beispiel[Bearbeiten | Quelltext bearbeiten]

_ldap._tcp.example.com. 3600 IN SRV 10 0 389 ldap01.example.com.

Ein Client kann in diesem Beispiel per DNS ermitteln, dass in der DNS-Domain example.com der LDAP-Server ldap01 existiert, der über TCP Port 389 erreichbar ist.

Beispiel einer hochverfügbaren Konfiguration[Bearbeiten | Quelltext bearbeiten]

Das Feld Priorität definiert die Rangordnung zwischen Records des gleichen Dienstes. Clients sollten zuerst die SRV-Records mit der zahlenmäßig niedrigsten Priorität verwenden und erst auf die Records mit höherem Prioritätswert zurückgreifen, wenn die Verbindungsversuche fehlschlagen. Wenn ein Dienst mehrere SRV-Records mit gleichem Prioritätswert hat, sollten die Clients proportional zum Wert des Felds Gewicht die Last verteilen. Im nachfolgenden Beispiel werden die Fehler Priorität und Gewicht gemeinsam verwendet, um eine Kombination aus Lastverteilung und Reserve zur Verfügung zu stellen.

# _dienst._proto.name.   TTL   Klasse SRV Priorität Gewicht Port Ziel.
_sip._tcp.example.com.   86400 IN     SRV 10        60      5060 bigbox.example.com.
_sip._tcp.example.com.   86400 IN     SRV 10        20      5060 smallbox1.example.com.
_sip._tcp.example.com.   86400 IN     SRV 10        20      5060 smallbox2.example.com.
_sip._tcp.example.com.   86400 IN     SRV 20        0       5060 backupbox.example.com.

Die ersten drei Records haben alle die Priorität 10, also werden die Clients das Gewichtsfeld nutzen, um einen der drei Ziele (Host und Port) auszuwählen. Die Summe aller drei Gewichtswerte ist 100, also wird bigbox.example.com bei 60 % aller Verbindungen verwendet. Die zwei Hosts smallbox1 und smallbox2 werden insgesamt für 40 % der Verbindungen verwendet; die Hälfte davon wird an smallbox1 und die andere Hälfte an smallbox2 geleitet. Sollte bigbox nicht erreichbar sein, wird die Last gleichmäßig unter die beiden verbleibenden Maschinen aufgeteilt, da beide dann jeweils bei 50 % aller Verbindungsversuche kontaktiert werden.

Wenn keiner der drei Server mit Priorität 10 verfügbar ist, wird der Eintrag mit dem nächstniedrigsten Prioritätswert gewählt, also backupbox.example.com. Dies könnte eine Maschine an einem anderen Standort sein, die nicht im Einflussbereich des Problems liegt, der die ersten drei Server unerreichbar gemacht hat.

Die Lastverteilung über SRV-Records ist von Natur aus eingeschränkt, da die Information effektiv statisch ist. Die aktuelle Auslastung der Server wird nicht berücksichtigt, es sei denn, die TTL-Werte sind niedrig genug (etwa eine Minute oder weniger), damit sich schnelle eine Änderung der Priorität (oder des Gewichts) auszahlt.

Verwendung[Bearbeiten | Quelltext bearbeiten]

SRV-RRs werden häufig von Microsoft-Windows-2000-Clients verwendet, um für einen benötigten Dienst den zuständigen Domain Controller zu ermitteln.

Weiter sind SRV-Einträge üblich bei folgenden standardisierten Protokollen:

  • XMPP (Jabber)
  • SIP
  • LDAP
  • Kerberos
  • Teamspeak3 (seit Client-Version 3.0.8): _ts3._udp.example.com
    • TSDNS, ein eigenes Protokoll, bei dem zur Namensauflösung schlicht der Domänenname per TCP gesendet und zurückgegeben wird (falls kein SRV-RR vorhanden ist, wird Port 41144 des A-RR verwendet; seit Client-Version 3.1 erfordert TSDNS zwingend einen SRV-Record auf der Second-Level-Domain)
  • Minecraft (seit Vollversion 1.3.1): _minecraft._tcp.example.com

Weblinks[Bearbeiten | Quelltext bearbeiten]