Zusammenfassung

  • RFC 5001 definierte im August 2007 die DNS-Option NSID. Ein Resolver fordert mit einem leeren EDNS-Feld eine Kennung an; ein kooperierender Nameserver legt seine Kennbytes in genau die Antwort, die er verschickt.
  • NSID gilt für einen einzelnen Austausch und einen einzelnen Hop. Ein rekursiver Resolver benennt sich gegenüber seinem Client selbst. Für die vorgelagerte autoritative Instanz braucht es einen eigenen Austausch. Der Inhalt der Kennung bleibt dem Betreiber überlassen.
  • Ein Betriebsbericht von L-Root aus dem Jahr 2014 beschreibt vollständig qualifizierte Hostnamen als NSID seiner antwortenden Knoten. Die IANA-DNS-Parameter führen dafür EDNS-Optionscode 3.

Der Nachtest traf womöglich den falschen Zeugen

Im Störungsbericht steht dieselbe IP-Adresse neben einer falschen und einer richtigen DNS-Antwort. Es sieht aus, als hätte ein Server erst einen Fehler gemacht und sich dann verbessert. Anycast macht diese Lesart gefährlich. Mehrere Knoten teilen sich die Dienstadresse; der aktive Netzweg wählt für jede Anfrage einen Empfänger. Ein Load Balancer kann hinter derselben Adresse ebenfalls verschiedene Prozesse aufrufen. Dieselbe Anschrift sagt noch nichts darüber, ob dieselbe Maschine gesprochen hat.

Die Anycast-Betriebsempfehlung von 2006 behandelt die Identifikation des Knotens als Hilfe bei Störungen. Eine zusätzliche Abfrage nach dem Servernamen kann den gerade antwortenden Knoten nennen. Zwischen der problematischen Antwort und dieser Abfrage kann die Route gewechselt haben. Die neue Auskunft mag stimmen und dennoch über den ersten Fehler schweigen. Wer einen Tatzeugen sucht, sollte nicht einfach den nächsten Mitarbeiter am Empfang befragen.

RFC 5001 setzte die Kennung in den ursprünglichen DNS-Austausch. Der Text nennt Anycast, Lastverteilung und andere Gründe, weshalb mehrere Nameserver eine IP teilen. DNS-Anfragen halten keine Sitzung vor, die einen Nachtest an dieselbe Instanz bindet. Für die Zuordnung einer bestimmten Antwort ist daher eine Kennung in eben dieser Antwort der zuverlässige Ort. Ein Mitschnitt enthält Ergebnis, Zeitpunkt und die erklärte Identität des Antwortenden zusammen.

Die Anfrage bleibt leer

Der Resolver sendet eine leere NSID-Option im EDNS-OPT-Pseudoeintrag. Er darf dort keine Nutzdaten mitschicken. IANA registriert die Option unter Code 3. Ein Nameserver, der die Anfrage versteht und sie erfüllen will, hängt in seiner Antwort Identifikationsbytes an. Er muss unerwartete NSID-Nutzdaten in der Anfrage ignorieren und darf keinen NSID zurückschicken, wenn der Resolver nicht darum gebeten hat. Der Frager kann diese Bytes unverändert mit der Antwort archivieren.

Die Bytes haben kein vorgeschriebenes Namensformat. RFC 5001 erlaubt als Beispiele einen wirklichen Rechnernamen, eine Wartungsadresse, einen stabilen Zufallswert, eine berechnete Ersatzkennung, einen wechselnden Wert sowie signierte oder verschlüsselte Daten. Der Standard legt Frage und Transportplatz fest. Der Betreiber bestimmt, was die Antwort preisgibt. Ein lesbarer Name erleichtert ein externes Störungsticket. Ein Pseudonym unterscheidet Instanzen, ohne deren Managementadressen zu veröffentlichen.

Eine wechselnde Kennung erschwert Außenstehenden den Vergleich über längere Zeit und erhöht zugleich die Anforderungen an interne Zuordnungstabellen.

Darin liegt eine echte Betriebsentscheidung. Wer die Wartungsadressen aller Knoten preisgibt, zeigt eine Infrastruktur, die eine gemeinsame Dienstadresse vielleicht gerade verdecken sollte. Wer gar nichts kennzeichnet, überlässt dem Kunden eine Reihe widersprüchlicher Antworten von derselben IP. Der Sicherheitsteil von RFC 5001 behandelt NSID als Signal des Übertragungskanals außerhalb des DNSSEC-Schutzes für DNS-Daten. Bei Streit über die Echtheit der Kennung helfen Kanalschutz oder passende Betriebsprotokolle.

L-Root ließ seine Knoten lesbar auftreten

Die Betreiber von L-Root veröffentlichten im Januar 2014 eine Beschreibung der eingesetzten Verfahren zur Identifikation ihrer Anycast-Knoten. Der NSID-Inhalt war der vollständige Hostname des antwortenden Knotens. Ein Beispiel zeigt dig mit Hexadezimalbytes, die sich als Name wie ytz01.l.root-servers.org lesen lassen. Das RFC-Feld blieb formal offen; L-Root wählte eine öffentlich verständliche Belegung.

Der Bericht nennt außerdem die gesonderten Abfragen HOSTNAME.BIND und ID.SERVER. Sie können den Knoten identifizieren, der diese spätere Abfrage bearbeitet. Bei geänderter Route ist das womöglich ein anderer als der Lieferant der fehlerhaften Antwort. NSID auf der problematischen Frage verbindet die problematische Antwort und den von ihr gemeldeten Knoten im selben Paketwechsel. Ein Kunde kann dem Betreiber damit mehr geben als die übliche Bitte, eine gemeinsame IP doch einmal anzusehen.

Der Bericht dokumentiert den Betrieb von L-Root zu diesem Zeitpunkt. Er liefert keine heutige Bestandsaufnahme aller Root-Server. Bei einem konkreten Vorfall braucht es die ursprüngliche Anfrage und Antwort, NSID-Rohbytes, Quelle, Transport und Uhrzeit. Die Zuordnung der Kennung zu einem bestimmten Prozess oder Gerät steht im Betriebsinventar des jeweiligen Anbieters.

Rekursion reicht die Kennung nicht durch

NSID ist Hop für Hop definiert. Fragt ein Endgerät seinen rekursiven Resolver nach NSID, so erbittet es dessen Identität. Der Resolver kann seinerseits bei einem autoritativen Server NSID anfordern, doch das ist eine zweite Unterhaltung. Die Kennung in der Antwort an das Endgerät ist keine automatische Kennung des vorgelagerten Servers. RFC 5001 verbietet zudem die freiwillige Rückgabe einer Kennung an einen Client ohne entsprechende Anfrage.

Um den autoritativen Lieferanten hinter einer rekursiven Antwort zu bestimmen, benötigt man den Mitschnitt oder das Protokoll des vorgelagerten Austauschs. Die Antwort an das Endgerät trägt keine Liste der unterwegs befragten Server. Auch innerhalb eines Hops besagt die Kennung zunächst, wie sich die antwortende Instanz ausweist. Weshalb ihr Datenstand abwich, zeigen Konfigurationen, Replikationszustand und Protokolle.

Die gemeinsame Adresse bekam einen Absender

RFC 5001 ließ die Dienstadresse stehen. Es ergänzte einen optionalen Platz für eine Kennung neben der Antwort einer konkreten Instanz. IANA verwaltet die Optionsnummer, der Betreiber den Inhalt, der Resolver die Frage und die Aufbewahrung. Das ist eine kleine Änderung mit großer Wirkung für eine Untersuchung, bei der nur ein Knoten schlecht arbeitet.

Der Server kann die Auskunft verweigern. Zusätzliche Antwortbytes können außerdem zu DNS-Trunkierung beitragen; die Rückgabe der Kennung bleibt stets freiwillig. Ein Paket ohne NSID belegt lediglich, dass in diesem Austausch keine Kennung zurückkam. Die Instanz muss aus anderen Aufzeichnungen ermittelt werden. Das Schweigen eines Feldes macht aus der gemeinsamen IP keinen individuellen Rechner.

Die gemeinsame Adresse vereinfacht die Erreichbarkeit eines verteilten Dienstes. Bei einer Störung macht sie die Zuordnung mühsam. Seit 2007 kann der tatsächlich Antwortende seine Kennung mit der fraglichen Antwort abliefern. Die nächste Abfrage mag einen Kollegen treffen; der erste Beleg behält seinen eigenen Absender.