Zusammenfassung

  • DNS SRV ließ eine Domain für einen bestimmten Dienst und Transport mehrere Ziele, deren Ports, Primär- und Ausweichstufen sowie eine statische Auswahlneigung unter gleichrangigen Hosts veröffentlichen.
  • Priority und Weight sind getrennte Entscheidungen. Der Client versucht zuerst die erreichbare Stufe mit der kleinsten Zahl; nur innerhalb dieser Stufe erstellt er eine gewichtete Zufallsreihenfolge.
  • Der Record beweist weder Gesundheit noch Identität. Der Client muss das kanonische Ziel auflösen, Transport und Port erreichen und den antwortenden Anwendungsdienst prüfen.

Als der Dienstort im Client steckte

Das frühe DNS verband Hostnamen mit Adressen. Die Anwendung ergänzte einen bekannten Port, eine lokale /etc/services-Tabelle oder einen dokumentierten Servernamen. Öffentlicher Name, Diensthost, Port und Ausweichplan erschienen als eine Konvention.

RFC 2052 schlug im Oktober 1996 einen experimentellen Record für eine andere Frage vor: Wo befindet sich ein Dienst innerhalb dieser Domain? Die Antwort konnte mehrere Ziele mit Priorität, Gewicht und Port nennen.

Im Februar 2000 ersetzte RFC 2782 den Text als Proposed Standard. Dienste sollten sich mit wenig Aufwand zwischen Hosts bewegen, mehrere Server nutzen und Primär- von Ausweichsystemen trennen lassen. IANA führt SRV weiterhin als DNS-Typ 33, Server Selection.

Der Queryname trennte Dienst, Transport und Domain

Ein LDAP-Client für TCP unter example.com fragt _ldap._tcp.example.com. Die linken Labels nennen Dienst und Transport, der Rest den administrativen Bereich. RFC 2782 ergänzte Unterstriche, um Metadaten von gewöhnlichen DNS-Namen abzugrenzen, und präzisierte den Gewichtungsalgorithmus.

RFC 6335 vereinte später die Verfahren für Dienstnamen und Portnummern. Ein registrierter Dienstname kann SRV dienen, auch wenn keine Portnummer zugeteilt ist. Registrierung verhindert Namenskollisionen, billigt aber weder Produkt noch Verkehr.

RFC 8552 schuf 2019 das Register globaler DNS-Knotennamen mit Unterstrich. RFC 8553 passte SRV-Spezifikationen daran an und bewahrte bestehende Praxis. Aus Kollisionsvermeidung wurde eine prüfbare Zuteilungsgrenze.

Priorität ist kein Gewicht

SRV enthält Priority, Weight, Port und Target.

Priority bildet Failover-Stufen. Der Client muss ein erreichbares Ziel mit der niedrigsten Zahl versuchen. Eine höhere Stufe ist kein gleichberechtigter Host mit weniger Last, sondern Reserve, bis die bevorzugte Stufe ausfällt.

Weight wirkt nur unter Records gleicher Priority. Der Client summiert Gewichte, zieht eine gleichverteilte Zufallszahl, wählt über laufende Summen, entfernt das Ziel und wiederholt. Die Zone veröffentlicht eine relative Neigung; der Client erzeugt die Reihenfolge. Gewicht null ist bei positiven Gewichten kein absolutes Verbot, sondern erhält eine sehr kleine Chance.

Im Beispiel von RFC 2782 haben zwei Priority-0-Hosts die Gewichte eins und drei. Über viele unabhängige Erstwahlen tendiert der zweite zu drei Vierteln. Zwei Priority-1-Hosts folgen erst, wenn das bevorzugte Paar nicht dienen kann. Eine einzelne Abfrage verspricht kein exaktes Verhältnis.

Weight ist keine Live-Lastmessung. CPU, Warteschlange und Latenz ändern sich schneller als DNS-Caches. Sehr kurze TTLs würden DNS belasten und Zuverlässigkeit schwächen. Gemeint sind statische Unterschiede wie relative Kapazität oder bessere Anbindung.

Port verlagert weiteres Wissen in DNS. Er kann dem registrierten Wert entsprechen, muss es aber nicht. Ein Dienst kann umziehen, ohne jede Clienttabelle zu aktualisieren.

Target muss Address Records besitzen und darf kein Alias sein. Der Client nutzt A/AAAA aus Additional Data oder fragt separat. SRV endet an einem kanonischen Host und versteckt keine weitere CNAME- oder DNAME-Kette.

Fehlende Antwort und ausdrückliche Nichtverfügbarkeit

Ein einziges Target . erklärt, dass dieser Dienst unter der Domain entschieden nicht verfügbar ist. Domain und andere Dienste können weiter existieren.

Fehlt ein nutzbarer SRV-Record, sieht das ursprüngliche Verfahren einen Address Lookup der Domain und die alte Konvention vor. RFC 2782 hielt ein gleichzeitiges Upgrade aller Clients für unrealistisch. Sinnvolle Adressen sollten alte Clients stützen; reine Backuphosts sollten dort aber nicht als vermeintliche Primärziele erscheinen.

Kompatibilität blieb eine Betreiberentscheidung. Sie erhält Zugang und kann Priority und Port umgehen. Ihre Entfernung vereinheitlicht Policy und kann Legacysoftware abschneiden.

Veröffentlichte Kandidaten sind kein bewiesener Dienst

Der Client liest das gesamte RRset, gruppiert nach Priority, ordnet nach Weight, löst Adressen auf und versucht Transport, Adresse und Port. Eine authentische DNS-Antwort beweist, was die DNS-Autorität veröffentlichte. Sie beweist keinen gesunden Prozess, keine Anwendungsidentität, keine Zustimmung des Zielhosts und kein gemeinsames Eigentum.

Mehr Ausdruckskraft vergrößert die Wirkung falscher Daten. Ein DNS-Fälscher kann neben Host und Adresse einen falschen Port liefern. Eine Domain kann einen fremden Host als Ziel nennen und unerwünschten Verkehr erzeugen. Feine Ports erschweren Filter und verlangen Zusammenarbeit zwischen DNS- und Netzbetrieb.

Auch der Anwendungsstandard setzt eine Grenze. Er muss SRV vorsehen, den symbolischen Dienstnamen festlegen und Sicherheit behandeln. Das Protokoll gibt Bedeutung, die Domain veröffentlicht, der Client handelt und das Ziel muss den Dienst beweisen.

Quellen und Beweisgrenze

Grundlage sind ausschließlich RFC 2052, RFC 2782, RFC 6335, RFC 8552, RFC 8553 und die IANA DNS Parameters. Sie belegen Semantik und Entwicklung, nicht heutige Nutzung, Latenzgewinn, Implementierungstreue oder Live-Gesundheit.

SRV machte den Dienstnamen unabhängiger von einem Host und Port, ohne DNS die Autorität über Verbindung und Anwendung zu geben.