Zusammenfassung

  • WKS verband eine IPv4-Adresse mit einer IP-Protokollnummer und einer nach Ports geordneten Bitmap. Das gesetzte Bit erklärte, dass dort ein Dienst lauschen sollte; es war keine aktuelle Messung.
  • RFC 974 empfahl, MX-Ziele ohne passende SMTP-Anzeige auszusortieren. RFC 1123 nahm diesen Schritt wegen geringer Verbreitung zurück: Eine fehlende Verzeichnisangabe war kein verlässlicher Beweis für einen fehlenden Dienst.
  • Nummernvergabe, DNS-Veröffentlichung, Prozesszustand, Netzfreigabe und Anwendungsidentität liegen bei unterschiedlichen Instanzen. Erst der Verbindungsversuch konnte die Behauptung mit der laufenden Wirklichkeit abgleichen.

Die Prüfung vor dem ersten Verbindungsversuch

Ein früher Mailserver hat mehrere MX-Ziele zur Auswahl. Bevor er ein TCP-SYN sendet, fragt er noch einmal das DNS. Er möchte wissen, ob die Zieladresse SMTP anbietet. WKS liefert dafür eine Protokollnummer und eine Bitfolge. Bei TCP steht Bit 25 für Port 25. Ist es gesetzt, sollte dort ein SMTP-Server lauschen.

Aus Sicht des Mailprogramms versprach das einen vernünftigen Gewinn. Fehlgeschlagene Verbindungen kosten Zeit, besonders wenn ein Zeitlimit abgewartet werden muss. Ein verteiltes Dienstverzeichnis könnte ungeeignete Ziele vorab entfernen. Das DNS kannte schließlich schon die Adresse; warum sollte es nicht auch die dort angebotenen Dienste kennen?

Die zusätzliche Aussage stammte jedoch nicht aus einer Beobachtung des Dienstes. Der DNS-Server las weder die Prozesstabelle des Zielrechners noch prüfte er den Weg des Clients. Er gab veröffentlichte Zonendaten zurück, möglicherweise aus einem Cache. Die Genauigkeit der Bitposition verdeckte, wie viele Annahmen zwischen dieser Auskunft und einer erfolgreichen SMTP-Sitzung lagen.

Ein Dienst war eine Koordinate im Portfeld

RFC 883 definierte WKS im November 1983. RFC 1035 übernahm 1987 denselben Aufbau: eine 32-Bit-Internetadresse, eine acht Bit breite IP-Protokollnummer und eine variable Bitmap, deren Länge ein Vielfaches von acht Bit ist.

Die erste Position bezeichnet Port null, die zweite Port eins. Nicht übertragene Positionen hinter dem Ende gelten als null. Das SMTP-Beispiel der Spezifikation sagt ausdrücklich, dass bei TCP das 26. Bit dem Port 25 entspricht. Eins bedeutet, dass ein SMTP-Server lauschen sollte; null bedeutet, dass dieser Dienst an der angegebenen Adresse nicht unterstützt wird.

WKS beschrieb damit kein bewegliches Dienstobjekt, sondern eine feste Kombination aus Adresse und Protokoll. Ein mehrfach adressierter Rechner brauchte mehrere Einträge. TCP und UDP benötigten ebenfalls getrennte WKS-Datensätze. Im Dienstrecord stand eine IPv4-Adresse, kein Zielname, dessen Adressen später aufgelöst werden konnten.

Die Bitmap ist dicht. Ihr Umfang richtet sich nach dem höchsten angekündigten Port, nicht nach der Zahl der tatsächlich angebotenen Dienste. Zwei weit auseinanderliegende gesetzte Bits benötigen alle Zwischenpositionen. Nur nachlaufende Nulloktette lassen sich weglassen. Das ist eine rechnerische Eigenschaft des Formats, keine Behauptung über gemessene historische Bandbreitenverluste.

Für bekannte Dienste an niedrigen Portnummern war die Darstellung kompakt. Für eine Welt mit beliebigen Ports und wandernden Instanzen war sie weniger passend. Es fehlen Felder für Priorität, Gewicht, Ausweichziel, Wartungszustand oder einen vom Dienstnamen getrennten Zielport. Mehrere Records vergrößern den Katalog, liefern aber kein Auswahlverfahren.

Als der Katalog über die Zustellung entschied

Im Januar 1986 machte RFC 974 WKS zu einer möglichen Vorprüfung der Mailzustellung. Für jedes MX-Ziel sollte eine WKS-Abfrage klären, ob der gewünschte Maildienst unterstützt wurde. Ungeeignete Namen sollten aus der Liste verschwinden. Der Schritt war optional, wurde aber nachdrücklich empfohlen.

Das funktioniert, wenn der Katalog vollständig und aktuell ist. Dann erspart eine Null eine aussichtslose Verbindung. Bei freiwilliger Veröffentlichung kann dieselbe Null jedoch bedeuten, dass der Betreiber WKS nie eingerichtet hat. Sie kann auch eine vergessene Aktualisierung oder eine alte Cachekopie anzeigen. SMTP selbst benötigt keinen WKS-Eintrag, um Nachrichten anzunehmen.

Damit wurde aus unvollständiger Information eine Ausschlussentscheidung. Ein funktionierender Mailserver konnte vor dem ersten Paket aus dem Zustellplan fallen. Der Versuch, Fehlschläge zu vermeiden, schuf einen neuen Fehlschlag, den eine direkte Verbindung womöglich verhindert hätte.

Die Verwaltungsgrenzen verschärfen dieses Problem grundsätzlich. DNS und Rechner können verschiedene Verantwortliche haben. MX und WKS können zu unterschiedlichen Zeiten geändert werden. Ein neuer Prozess kann während eines bestehenden TTL starten. Die Spezifikationen garantieren keine atomare Kopplung dieser Vorgänge.

Auch ein positives Bit trägt nur begrenzte Evidenz. Der Prozess kann nach Veröffentlichung ausfallen. Ein Filter kann den konkreten Client sperren. Die Adresse kann einem anderen Rechner zufallen, der Port einem anderen Programm. Selbst eine offene TCP-Verbindung beweist noch nicht die erwartete Anwendung, ihre Identität oder die erfolgreiche Annahme einer Nachricht.

DNS-Caching ist dabei nicht bloß eine lästige Fehlerquelle. Es macht den Namensdienst skalierbar, weil nicht jede Nutzung eine neue Rückfrage bei der Quelle verlangt. Gerade deshalb ist eine gecachte Konfigurationsaussage keine Echtzeitprobe.

1989 wurde der Versuch wieder zur Bestätigung

RFC 1123 hielt im Oktober 1989 die Betriebserfahrung fest. Anwendungen sollten nicht darauf vertrauen, für eine Adresse einen WKS-Eintrag mit einer genauen Liste aller Dienste zu finden, weil Internetstandorte diesen Typ nur selten verwendeten. Ob ein Dienst vorhanden sei, solle durch einen Nutzungsversuch bestätigt werden.

Für MX-Verarbeitung zog das Dokument die Konsequenz ausdrücklich. Die von RFC 974 vorgeschlagene WKS-Prüfung sollte nicht mehr verwendet werden, da sich die Unterstützung als wenig verbreitet erwiesen hatte. Die Normgeschichte zeigt hier keine bloße Formatkorrektur, sondern den Entzug einer Entscheidungsbefugnis: Der Katalog durfte den Versuch nicht mehr zuverlässig verhindern.

Das war kein Urteil, jeder WKS-Record sei falsch. Sorgfältig gepflegte Daten konnten stimmen. Ebenso wenig wurde Typ 11 aus DNS entfernt. Die aktuelle IANA-Registrierung der DNS-Parameter führt WKS weiterhin. Die Belegung bewahrt die Bedeutung des Codes und verhindert Kollisionen; sie belegt keine heutige Nutzung.

Geändert wurde die Schlussregel. Die Abwesenheit aus einem optionalen, lückenhaften Verzeichnis darf nicht als Abwesenheit im Netz gelten. Für Mail war das irrtümliche Verwerfen eines geeigneten Ziels schwerwiegender als ein zusätzlicher Verbindungsversuch. Die bessere Evidenz lag jenseits des DNS.

Fünf Zuständigkeiten hinter einer Aussage

Die Aussage „diese Adresse bietet SMTP“ enthält mindestens fünf Fragen. Welcher Dienst ist mit der Portnummer koordiniert? Was behauptet der Zonenbetreiber? Welcher Prozess lauscht tatsächlich? Erlaubt der Netzpfad diesem Client den Zugriff? Und ist die antwortende Anwendung wirklich die erwartete Gegenstelle?

Das Nummernregister beantwortet die erste, DNS die zweite, der Host die dritte, Netzbetrieb und Filter die vierte. Protokollaustausch und Authentifizierung müssen die fünfte klären. Ein Eintrag kann im DNS-Sinn authentisch sein und trotzdem veraltete Betriebsdaten enthalten. Eine korrekte lokale Konfiguration kann von außen unerreichbar sein. Eine erreichbare Portnummer ist keine Identität.

RFC 6335 formulierte später die Grenze der Registrierung. Die Vergabe eines Dienstnamens oder Ports ist keine Empfehlung eines Produkts. Verkehr auf einem zugeteilten Port muss weder unbedenklich sein noch überhaupt zum registrierten Dienst gehören. Sicherheitsregeln sollen auf Kenntnis des Verkehrs beruhen, nicht auf der Nummer allein.

Diese spätere Formulierung wird nicht den Autoren von 1983 untergeschoben. Sie macht jedoch denselben Kategorienfehler sichtbar: Ein gemeinsam verstandenes Zeichen ist kein Beweis für einen laufenden und erlaubten Vorgang. WKS konnte Nummern koordinieren und Absichten transportieren, nicht die Zuständigkeiten dahinter vereinigen.

SRV gab dem Dienst einen anderen Bezugspunkt

RFC 2782 beschrieb mit SRV eine andere Art der Dienstsuche. Dienst, Transport und Domain stehen im Abfragenamen. Die Antwort enthält Priorität, Gewicht, Port und Zielname. Der Zielhost besitzt eigene Adressrecords; die Dienstbeschreibung hängt nicht mehr an einer eingebetteten 32-Bit-Adresse.

Dadurch kann ein Dienst zwischen Hosts wechseln, mehrere Kandidaten veröffentlichen und für jedes Ziel einen Port angeben. Haupt- und Ersatzziele werden unterscheidbar. Statt eines vollständigen Hostkatalogs erhält der Client eine begrenzte Auswahl.

RFC 6335 erlaubte zudem die Registrierung eines Dienstnamens ohne feste Portzuteilung, wenn ein Verfahren wie SRV den Port zur Laufzeit liefert. Name und Nummer bleiben verbunden, sind aber keine untrennbare Einheit mehr. Bei WKS war der Dienst gerade seine Bitposition gewesen.

Auch SRV misst keine aktuelle Gesundheit. Gewicht ist keine Live-Auslastung; ein Ziel kann während der Cachezeit ausfallen. Der Client muss weiter auflösen, verbinden und die Anwendung prüfen. Der Fortschritt bestand in präziserer Ausdrucksfähigkeit und klareren Übergaben, nicht in einem allwissenden DNS.

Beleglage und Grenzen

Die sieben offiziellen Quellen belegen Definition, Wire-Format, die frühere MX-Empfehlung, deren Rücknahme, den späteren SRV-Kontrast, die Trennung von Dienstname und Port sowie die fortbestehende Typbelegung. Sie messen weder heutige WKS-Abfragen noch Zonenbestände oder Produktunterstützung.

Sie beweisen auch nicht, dass ein bestimmter historischer Eintrag veraltet war oder dass jeder Mailserver RFC 974 befolgte. Die Betrachtung der dichten Bitmap ist Format-Arithmetik, keine Verkehrsstudie. SRV wird nicht als universeller direkter Ersatz jeder WKS-Verwendung dargestellt.

WKS bleibt interessant, weil sein Fehler so genau benennbar ist. Eine administrative Beschreibung erhielt mehr Entscheidungsgewicht, als ihre Abdeckung und Aktualität tragen konnten. Das Internet wurde robuster, als ein fehlendes Bit nicht länger den Versuch blockierte, mit dem ein Client die Wirklichkeit selbst feststellen konnte.