什么是紫癜

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

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). Erlaubt ist ein Wert entsprechend einer vorzeichenlosen Zahl von 16 bit, also zwischen 0 (oberste) und 65535 (niedrigste Priorit?t).

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 zweiten mit Gewicht 2 wird ein Client angewiesen, im Mittel zu 60 % den ersten Dienst zu w?hlen – dies dient zur Lastverteilung). Erlaubt ist hier ebenfalls ein Wert zwischen 0 und 65535 (16 bit, vorzeichenlos). Ein korrekt programmierter Client trifft eine zuf?llige Wahl mit einem dem Gewicht entsprechender H?ufigkeit.

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

_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

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 Felder 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        10      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

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

• APT
• Autodiscover (E-Mail)
• Kerberos
• LDAP
• Matrix
• Minecraft (seit Vollversion 1.3.1)
• Mumble
• SIP
• SMTP, POP, IMAP
• TeamSpeak3 (seit Client-Version 3.0.8)
• XMPP (Jabber)

Von Microsoft-Windows-2000-Clients werden SRV-RRs verwendet, um für einen ben?tigten Dienst den zust?ndigen Domain Controller zu ermitteln.

Weblinks

• RFC: 2782 – A DNS RR for specifying the location of services (DNS SRV). Februar 2000 (englisch).
• Service Name Registry (RFC 6335). iana.org – Liste von Diensten, zugeh?rigen SRV-Eintr?gen und Ports
• DNS SRV (RFC 2782) Service Types. dns-sd.org – Alte Liste von Diensten und den zugeh?rigen SRV-Eintr?gen