Zusammenfassung

  • Ein NSID belegt, dass ein DNS-Antwortender bestimmte Bytes an eine konkrete Antwort angehängt hat. Er belegt weder Hostnamen noch physische Maschine, Standort, Softwarestand oder dauerhafte Identität.
  • Für eine belastbare Zuordnung braucht es vier verbundene Belege: ursprüngliche Anfrage und Antwort, Beobachtungspunkt und Zeit, die gültige Betreiberzuordnung sowie die Einheit, auf die sich eine Maßnahme stützen darf.

Die Adresse bezeichnet den Dienst, nicht zwingend den Rechner

Eine IP-Adresse als eindeutigen Namen eines Servers zu verwenden, war lange eine brauchbare Abkürzung. Verteiltes DNS hat diese Eindeutigkeit aufgelöst. Bei Anycast kündigen mehrere Knoten dieselbe Dienstadresse an; das Routing wählt abhängig vom Ausgangsnetz und dem momentanen Pfadzustand einen davon. Hinter einem Load Balancer kann sich eine weitere Gruppe von Prozessen und Hosts verbergen.

Die Adresse bleibt ein wichtiger Beleg. Sie sagt, welchen Dienst der Client angesprochen hat. Sie sagt nicht mehr eindeutig, welches System die Anfrage bearbeitet hat. RFC 4786 nennt die topologische Region, die zu einem bestimmten Anycast-Knoten geroutet wird, dessen Catchment. Es hängt vom Beobachtungspunkt ab und kann sich mit der Routinglage verändern; eine feste geografische Grenze ist es nicht.

RFC 3258 beschreibt die Folge für autoritative DNS-Server. Zwei unabhängige Anfragen an dieselbe geteilte Adresse müssen nicht dieselbe Instanz erreichen. Ein Ping, ein Traceroute-Lauf oder eine separate TCP-Verbindung liefern noch weniger Gewissheit darüber, ob sie den Prozess der fraglichen DNS-Transaktion getroffen haben. Jede Messung kann korrekt sein und dennoch ein anderes Subjekt betreffen.

Genau diese Lücke rahmten Suzanne Woolf und David Conrad im Informational RFC 4892 von 2007. Das Dokument definiert weder eine universelle Maschinenidentität noch einen fertigen Drahtmechanismus. Es fragt, wie ein Betreiber eine falsche, veraltete oder ungewöhnlich langsame Antwort in einer verteilten Servergruppe eingrenzen kann, ohne seine interne Wartungstopologie offenlegen zu müssen.

Im Störungsbericht sind deshalb zwei Sätze auseinanderzuhalten. „Der unter dieser Adresse erreichte Dienst lieferte diese Antwort“ folgt aus der Transaktion. „Diese physische Maschine lieferte sie“ ist eine zusätzliche Topologiebehauptung. Die erste Aussage trägt die zweite nicht von selbst.

Warum die zweite Anfrage den falschen Zeugen finden kann

BIND kannte bereits eine praktische Konvention. Eine CHAOS-TXT-Abfrage nach HOSTNAME.BIND. konnte den konfigurierten Hostnamen zurückgeben; ID.SERVER. löste den Namen vom einzelnen Produkt, behielt aber das Verfahren. Weil die Abfrage selbst DNS nutzt, passiert sie gewöhnlich ähnliche Filter- und Routingregeln. Der Betreiber kontrolliert zudem den Rückgabewert und kann eine Wartungsadresse verbergen.

Der entscheidende Nachteil ist der zeitliche Abstand. Erst kommt die auffällige Antwort, danach die Identitätsabfrage. Dazwischen kann sich eine Anycast-Route ändern, der Lastverteiler ein anderes Backend auswählen oder die fehlerhafte Instanz verschwinden. Das Etikett ist für die zweite Antwort echt, aber nicht sicher mit der ersten verknüpft.

Die Fehlzuordnung wirkt plausibel, weil alle Einzelteile stimmen. Die Dienstadresse ist gleich. Von ihr kam tatsächlich ein Etikett. Der gemessene Weg sieht vernünftig aus. Doch gerade die gemeinsame Adresse erlaubt mehreren Instanzen, unter derselben Oberfläche zu erscheinen. Sie als Bindeglied zu verwenden, nimmt die zu untersuchende Mehrdeutigkeit einfach weg.

RFC 4892 verlangte deshalb, dass Identifikationsdaten in der normalen Betriebsantwort selbst mitgeführt werden können. Eine gesonderte Anfrage darf weiterhin existieren, ersetzt diese Bindung aber nicht. Die Zuordnung in derselben Antwort schließt ein Zeitrennen; sie ist keine bloße Komfortfunktion.

Die Anforderungen hinter der Kennung

Woolf und Conrad wollten nicht lediglich ID.SERVER. standardisieren. Sie machten aus den Schwächen der Konvention Entwurfsanforderungen.

Der Mechanismus sollte innerhalb von DNS arbeiten, herstellerneutral sein und eine gewöhnliche Antwort begleiten können. Aktivierung und Abschaltung mussten einfach sein; Zugriffskontrollen sollten möglich werden. Eine Instanz sollte unterscheidbar sein, ohne dass der Betreiber einen internen Hostnamen oder eine Unicast-Wartungsadresse offenlegen muss. Auch eine ganze Klasse samt Pseudozone sollte nicht nur für diese Funktion benötigt werden.

Authentisierung behandelten sie als eigene Eigenschaft. Eine lesbare Zeichenfolge beweist ihre Herkunft nicht. DNSSEC validiert signierte DNS-Daten in seinem Modell, authentisiert aber nicht automatisch jedes vom Antwortenden hinzugefügte Kanalmetadatum. Ein besserer Mechanismus sollte Schutz ermöglichen, ohne Lesbarkeit mit Integrität zu verwechseln.

RFC 4892 beantragte selbst keine IANA-Zuweisung. Der spätere RFC 5001 von Rob Austein definierte die NSID-Option und würdigte Woolfs Beiträge. Die Autorschaft des Standards bleibt bei Austein. Diese saubere Provenienz ist mehr als Höflichkeit: Der Artikel darf Zuschreibungen genauso wenig ausweiten wie der Betrieb die Bedeutung eines Etiketts.

Was NSID tatsächlich belegt

Ein Resolver setzt eine leere NSID-Option in eine EDNS-Anfrage. Ein Server, der sie versteht und beantworten will, fügt seiner Antwort NSID-Daten hinzu. Damit lässt sich zuverlässig sagen, dass der Antwortende dieser Transaktion genau diese Bytes geliefert hat. Das Rennen einer späteren Identitätsabfrage ist beseitigt.

Die Semantik bleibt offen. RFC 5001 definiert den Inhalt als undurchsichtige Bytefolge; Syntax und Bedeutung liegen bei Implementierung und Betreiber. Möglich sind Hostname, Unicast-Adresse, persistente Zufallskennung, dynamischer Wert, verschlüsselter Block oder beliebige Oktette. Die hexadezimale Darstellung soll die Rohdaten verlustfrei erhalten, statt ihnen durch hübschen Text eine nicht vorhandene Universalbedeutung zu geben.

Ein Wert kann daher eine Maschine bezeichnen, aber ebenso einen Prozess, Container, Pool, Standort oder Anycast-Knoten. Er kann Neustarts überdauern oder bei jedem Start wechseln. Er kann flottenweit eindeutig oder versehentlich überall identisch sein. Das Protokoll transportiert den Umschlag; der Betreiber bestimmt den Inhalt.

NSID ist zudem nicht transitiv. Fragt ein Stub einen rekursiven Resolver, identifiziert eine mögliche Antwort diesen Resolver. Sie nennt nicht automatisch den autoritativen Server, den er im Hintergrund befragt hat. Fordert der Resolver dort selbst NSID an, entsteht ein zweiter Beleg für einen zweiten Hop. EDNS ist ebenfalls Hop-by-Hop.

Von Haus aus ist NSID nicht authentisiert. RFC 5001 ordnet diese Kanalsignalisierung nicht dem unmittelbaren DNSSEC-Schutz zu und verweist bei Integritätsbedarf auf Kanalsicherung wie TSIG. Auch statische signierte oder verschlüsselte Blöcke können wiederholt werden. Kryptografische Form beweist weder Aktualität noch physischen Ort oder administrative Verantwortung.

Vier Belege statt einer großen Identitätsbehauptung

Der erste Beleg verbindet Antwort und Kennung. Anfrage, Antwort und rohe NSID-Bytes werden gemeinsam gespeichert. War NSID in der ursprünglichen Anfrage nicht angefordert, bleibt die Instanz offen. Eine spätere ID.SERVER.-Abfrage liefert einen Hinweis, aber keine rückwirkende Autorschaft.

Der zweite Beleg hält die Perspektive fest: Messquelle, angesprochene Dienstadresse, Transport und Zeitpunkt. Ein Anycast-Ergebnis beschreibt, was dieser Client in diesem Moment erreicht hat. Eine andere Perspektive kann zu einem anderen Catchment führen, ohne den ersten Befund zu widerlegen.

Der dritte Beleg ist die Betreiberzuordnung. Eine versionierte Tabelle verbindet das undurchsichtige Token mit der gemeinten Betriebseinheit und nennt den Gültigkeitszeitraum. Ohne diese Zeitachse erzeugt die Wiederverwendung nach einem Neuaufbau eine falsche Kontinuität. Ohne Tabelle gruppiert das Token Antworten, benennt aber keinen Vermögenswert.

Der vierte Beleg begrenzt die Maßnahme. Die Zuordnung muss angeben, ob Prozess, Container, Host, Pool, Standort oder Anycast-Knoten gemeint ist und welches Team darüber verfügt. Erst dadurch wird klar, ob Protokollvergleich, Drain eines Backends, Neustart oder Routenrücknahme angemessen sind. Eine Prozesskennung ermächtigt nicht zur Abschaltung eines Standorts.

Diese Begrenzung macht NSID nicht schwächer. Sie erhält seine eigentliche Stärke: abweichende Antworten erkennen, passende Protokolle finden und den Vorfall an die richtige Stelle geben, ohne ein vom Betreiber gesetztes Etikett zum Maschinenpass zu erklären.

Quellen