Zusammenfassung

  • NSID belegt den EDNS-Optionscode 3, vergibt aber keine weltweiten Serverkennungen. Den Inhalt bestimmt der jeweilige Betreiber.
  • Die Kennung gehört zur konkreten DNS-Antwort. Eine spätere Identitätsabfrage an dieselbe Adresse könnte eine andere Instanz erreichen.
  • Das Verfahren bleibt auf den einzelnen DNS-Austausch beschränkt. Es liefert weder eine vollständige Rekursionsgeschichte noch von sich aus einen Echtheitsnachweis.

Eine Registrierung mit absichtlich offenem Inhalt

Im DNS-Parameterregister der IANA ist die EDNS-Option 3 als NSID eingetragen. Diese eindeutige Zuweisung lässt Implementierungen erkennen, welche Funktion angefordert wird. Sie sagt ihnen nicht, wie die zurückgegebenen Bytes zu einem Standort, einem Rechner oder einer internen Betriebsakte passen.

Die gemeinsame Nummer und die lokale Kennung sind zwei verschiedene Ebenen. Wer sie verwechselt, erwartet von einem Optionsregister eine weltweite Vergabe von Maschinenidentitäten, die es nie vorgenommen hat. NSID schafft einen verständlichen Transportweg für einen möglicherweise unverständlichen Inhalt.

Diese Entscheidung ist keine unvollendete Standardisierung. Der Nutzen entsteht gerade daraus, dass ein Benutzer eine Kennung unverändert weiterreichen kann, obwohl nur der Betreiber sie deuten kann. Eine gemeinsame Grammatik für sämtliche Rechenzentren und Instanzen wäre dafür unnötig. Entscheidend ist zunächst, dass die Kennung zur richtigen Antwort gehört.

Der Fehler steckt zwischen zwei Fragen

Man stelle sich eine unerwartete DNS-Antwort vor. Zur Untersuchung wird dieselbe Adresse erneut gefragt, welcher Server dort antwortet. Die zweite Antwort nennt eine unauffällige Instanz. In deren Protokollen fehlt die erste Anfrage.

Das ist eine mögliche Diagnosefolge, kein hier gemessener Vorfall. Sie erfordert weder eine falsche Identität noch verlorene Protokolle. Die zweite Anfrage kann schlicht bei einem anderen Teilnehmer angekommen sein. Ein richtiger Name wurde dann einem Ereignis zugeordnet, über das er nichts aussagt.

RFC 4892, im Juni 2007 veröffentlicht, beschreibt diese Zuordnungslücke bei Anycast und Lastverteilung. Mehrere DNS-Anfragen an dieselbe IP-Adresse müssen nicht denselben Server erreichen. Ein zusätzliches Diagnoseverfahren über ICMP oder andere Protokolle bietet noch weniger Gewissheit, das ursprüngliche System zu treffen.

Die Anforderung war deshalb nicht bloß ein schönerer Servername. Die Identitätsfrage sollte Bestandteil einer gewöhnlichen betrieblichen DNS-Anfrage werden. Damit ließe sich die Auskunft mit der Antwort verbinden, die tatsächlich untersucht werden sollte.

Die gemeinsame Adresse hatte ihren Zweck erfüllt

Anycast verbindet einen Dienst mit stabilen Adressen, die von mehreren unabhängigen Knoten aus angekündigt werden. Die Routenwahl bestimmt, welcher Knoten Verkehr erhält. Der Benutzer muss weder sämtliche Wartungsadressen kennen noch eine wechselnde Liste einzelner Instanzen verwalten.

Dieser Vorteil bedeutet nicht, dass stets die geografisch nächste Maschine antwortet. Ebenso wenig erzwingt Anycast einen Wechsel bei jedem Paket. Es reicht, dass eine gleichbleibende Zieladresse allein keine dauerhafte Gleichheit des Antwortenden beweist.

Das Betriebspapier RFC 4786 vom Dezember 2006 behandelte die zusätzliche Diagnosevariable ausdrücklich. Traceroute konnte in manchen Fällen helfen, doch bis zu seiner Ausführung konnten sich die Bedingungen geändert haben. Der Text empfahl eine Identifikation innerhalb des Dienstprotokolls sowie verteilte Beobachtungen, bei denen Knotenkennung, Verfügbarkeit und Leistung zusammen erfasst werden.

NSID wurde dort als laufende Arbeit erwähnt. Die endgültige Spezifikation von 2007 darf nicht rückwirkend als bereits veröffentlichte Grundlage des Dokuments von 2006 dargestellt werden. Der praktische Bedarf war früher formuliert als die fertige Option.

Alte Werkzeuge, eine eng umrissene Schwäche

Für die Identifikation gab es bereits DNS-Konventionen. Eine TXT-Anfrage der Klasse CHAOS nach HOSTNAME.BIND. konnte eine administrativ gewählte Kennung liefern. ID.SERVER. vermied den Bezug auf eine bestimmte Implementierung. VERSION.BIND. beantwortete dagegen die andere Frage nach einer Softwareversion.

Die Verfahren waren einfach einzurichten, nutzten DNS und ließen den Betreiber über die Offenlegung entscheiden. NSID verbot sie nicht. Ihre Schwäche lag darin, dass eine zusätzliche Anfrage die Instanz einer früheren Antwort nicht verlässlich festhielt.

RFC 4892 verlangte daher eine implementierungsneutrale Möglichkeit ohne gesonderte Klasse oder eigenen Diagnosenamensraum. Administratoren sollten die Auskunft einschalten, abschalten oder beschränken können. Eine nützliche Kennung sollte nicht zwangsläufig interne Hostnamen oder Unicast-Wartungsadressen offenlegen. Genauere Zuordnung musste kein öffentliches Inventar der Infrastruktur nach sich ziehen.

Nichts in der Anfrage ist eine wichtige Regel

R. Austein definierte in RFC 5001 vom August 2007 den DNS Name Server Identifier als EDNS-Option. Der Anfragende fügt eine leere NSID-Option in den OPT-Pseudo-Ressourceneintrag seiner Anfrage ein. Nutzdaten sind dort nicht zulässig; ein Server muss dennoch empfangene Nutzdaten ignorieren.

Damit ist die Anfrage weder eine zurückzuspiegelnde Zufallsaufgabe noch die Wahl eines bestimmten Servers. Der Client gibt seinem Gegenüber auch keinen Namen vor. Er bittet den tatsächlich erreichten Teilnehmer, seine eigene Kennung an genau diese Antwort anzuhängen.

Ein unterstützender Server kann die Bitte erfüllen, muss es aber nicht. Ohne vorherige Anforderung darf er NSID nicht senden. Eine fehlende Kennung beweist somit weder einen DNS-Ausfall noch den Verzicht auf Anycast oder die Existenz nur einer Instanz. Unterstützung, Konfiguration, Anfrage und tatsächliche Antwort sind getrennte Sachverhalte.

Die Nutzdaten bleiben eine undurchsichtige Bytefolge. Der Betreiber darf sie nach seinen Bedürfnissen gestalten; die Norm stellt keine allgemeine Syntax für Städtenamen, Maschinenbezeichnungen oder Seriennummern bereit. Was auf der Leitung eindeutig erkannt wird, muss außerhalb des Betriebs nicht allgemein lesbar sein.

Ein rekursiver Resolver nennt nicht seine ganze Vorgeschichte

Fragt ein Client einen rekursiven Resolver nach NSID, fragt er nach dessen Kennung. Der Resolver kann seinerseits bei autoritativen Servern NSID anfordern. Das geschieht in anderen Transaktionen und bleibt eine eigenständige Entscheidung.

Die vom autoritativen Server erhaltene Kennung wird nicht als Identität des Resolvers an dessen Client weitergereicht. NSID ist ausdrücklich nicht transitiv. Mit dem einzelnen Sprung sind DNS-Transaktionspartner gemeint, nicht sämtliche IP-Router auf einem Weg. Das Verfahren sammelt weder deren Kennungen noch eine vollständige Liste aller an der Rekursion beteiligten Server.

Die spätere EDNS-Fassung RFC 6891 vom April 2013 beschreibt OPT als Steuerinformation für eine bestimmte Frage-Antwort-Transaktion, nicht als DNS-Daten. OPT darf nicht wie ein gewöhnlicher Datensatz zwischengespeichert, weitergereicht oder in Zonendateien aufbewahrt werden.

Aus diesen Grenzen folgt eine wichtige Unterscheidung: Ein Resolver kann zwischengespeicherte Ressourcendaten liefern und mit NSID die jetzt antwortende Instanz kennzeichnen. Die Kennung belegt dann nicht, welcher autoritative Server die Daten ursprünglich geliefert hat. Wer beides gleichsetzt, macht aus einem gegenwärtigen Diagnosehinweis einen nicht vorhandenen Herkunftsnachweis.

Verlustfrei kopieren ist wichtiger als sofort verstehen

RFC 5001 verlangt eine hexadezimale Darstellung mit zwei Ziffern je Oktett. Verglichen werden die binären Daten. Beim Kopieren darf kein Nullbyte als Ende einer Zeichenkette vorausgesetzt werden. Führende oder eingebettete Nullen gehören zum Wert.

Auch eine scheinbar lesbare Kennung wird dadurch nicht zu einem DNS-Namen. Werkzeuge dürfen ihr keine unvereinbarten Regeln für Großschreibung, Kleinschreibung oder Unicode-Normalisierung aufzwingen. Unterschiedliche Buchstabenschreibung in der Hexdarstellung kann dieselben Bytes repräsentieren; eine Änderung des vermeintlichen Textinhalts ist etwas anderes.

Eine lesbare Vorschau kann nützlich sein, ersetzt aber nicht den exakten Wert. Der Benutzer soll die Kennung in eine Nachricht oder ein Ticket übernehmen können. Der Betreiber soll sie dort wiederfinden, auch wenn der Benutzer ihren Aufbau nicht kennt. So ermöglicht sorgfältige Darstellung lokale Freiheit, ohne die Weitergabe der Information zu gefährden.

Lokale Bedeutung verlangt lokale Pflege

Ein Betreiber kann Namen, Wartungsadressen, zufällige oder veränderliche Kennungen wählen. Jede Wahl hat Folgen. Eine Wartungsadresse kann eine Instanz offenlegen, die hinter dem gemeinsamen Dienst sonst weniger sichtbar bleibt. Der Hash einer IPv4-Adresse hat weiterhin nur einen 32-Bit-Eingaberaum. Auch vorhersehbare Namen werden durch Hashing nicht automatisch vertraulich.

Zufallswerte benötigen eine Zuordnung und eine Regel für ihre Lebensdauer. Identische Konfigurationen auf allen Knoten können sämtliche Instanzen mit derselben Kennung versehen und den diagnostischen Zweck zunichtemachen. Wechselnde Werte wiederum beweisen nicht von sich aus einen Routenwechsel oder einen Hardwaretausch.

RFC 5001 erörtert signierte oder verschlüsselte Inhalte, liefert aber keine vollständige Sicherheitskonstruktion. Ein statischer Block kann wiederholt werden. NSID gilt als Kanalsignalisierung und ist nicht automatisch durch DNSSEC geschützt. Eine überprüfte Ressourcendatenmenge authentifiziert nicht zwangsläufig die benachbarte Kennung. Der historische Verweis auf Kanalschutz wie TSIG beschreibt diese Grenze, nicht den gesicherten Zustand jedes NSID-Austauschs.

Ein dokumentierter Schalter ist keine Einsatzstatistik

Die für diesen Beitrag gesicherte BIND-Konfigurationsreferenz, ausgewiesen als 9.20.27, trennt server-id und request-nsid. Ersteres bestimmt die eigene Auskunft über NSID oder ID.SERVER, standardmäßig none, mit einer Option zur Verwendung des Hostnamens. Letzteres fordert bei iterativen Anfragen Kennungen an, ist standardmäßig ausgeschaltet und ermöglicht die Protokollierung empfangener Werte in der Kategorie nsid.

Eigene Identität preiszugeben und fremde Identität abzufragen sind also verschiedene Entscheidungen. Die BIND-Handbuchseiten beschreiben außerdem dig +nsid zum Hinzufügen der Anfrage. Das erzwingt keine Antwort und überprüft nicht die Echtheit ihres Inhalts. Dokumentation belegt eine Implementierungsmöglichkeit, nicht ihre Aktivierung in einem bestimmten Netz oder ihre weltweite Verbreitung.

Zusätzliche Bytes können eine Antwort an Grenzen der Kürzung bringen. NSID ändert die geltenden Regeln jedoch nicht und verlangt keine Kürzung allein zur Aufnahme der optionalen Kennung. Ein diagnostischer Zusatz ist weder eine neue Liefergarantie noch wichtiger als der eigentliche Zweck der DNS-Antwort.

Die gemeinsame Nummer drei löste deshalb nicht das gesamte Identitätsproblem. Sie schuf einen kleinen, belastbaren Zusammenhang: Diese Kennung kam mit dieser Antwort. Für die Untersuchung war das wertvoller als ein nachträglich erfragter, aber falsch zugeordneter Name.