Zusammenfassung

  • Eine offizielle Fehlermeldung zu GPOS betrifft vertauschte Bezeichnungen von Länge und Breite. Ihr Status lautet „Held for Document Update“, nicht „Verified“.
  • LOC unterscheidet die Größe einer beschriebenen Entität von der Unsicherheit ihres Ortes. Feine Winkelauflösung bedeutet deshalb keine entsprechend genaue Messung.
  • Ein Rückgriff auf Netzstandorte liefert eine gröbere Aussage über einen anderen Gegenstand. TTL und DNSSEC bestätigen weder eine Vermessung noch deren Aktualität.

Ein Parser konnte den Irrtum sauber lesen

Eine Zahlenfolge kann vollständig, syntaktisch korrekt und trotzdem falsch verstanden sein. Dazu genügt, dass eine Achsenbezeichnung etwas anderes meint als ihre Definition. Keine zusätzliche Nachkommastelle hilft dann weiter.

Beim experimentellen RFC 1712 vom November 1994, der den DNS-Typ GPOS einführte, ist genau diese Vorsicht nötig. Teile des Textes vertauschen Bezeichnungen und Definitionen von geografischer Länge und Breite. Das offizielle Erratum 541, 2006 gemeldet, beschreibt das Problem und schlägt vor, bei beibehaltener Zahlenreihenfolge die Bezeichnungen zu berichtigen.

Der Status des Eintrags ist wichtig: „Held for Document Update“. Er lautet nicht „Verified“ und belegt keine bereits abgeschlossene Änderung des ursprünglichen Standards. Ebenso wenig beweist er, dass sämtliche Implementierungen denselben Umgang mit den alten Beispielen gewählt haben. Deshalb dienen diese Beispiele hier nicht als kopierbare Konfiguration.

Die Episode ist mehr als eine Kuriosität. Ein gemeinsames Zahlenformat muss auch die Bedeutung der Zahlen gemeinsam festlegen. Sonst kann die Übertragung fehlerfrei sein, während die Aussage ihren Gegenstand verfehlt.

Der Ort sollte beim Namen gepflegt werden

GPOS wollte geografische Informationen lokal wartbar und über DNS allgemein abfragbar machen. Im Hintergrund standen unter anderem die Pflege und Überprüfung zentraler UUCP-Karten. Wenn sich ein Standort änderte, sollte die zuständige Stelle ihre Beschreibung nahe beim eigenen Namen ändern können.

Der Text verglich dieses Vorgehen mit sysLocation in SNMP, das an Agenten, Leseberechtigungen und lokale Ortsbeschreibungen gebunden war, sowie mit der damaligen Verbreitung von X.500. Das sind Erwägungen aus dem Jahr 1994, keine aktuelle Bestandsaufnahme dieser Systeme.

GPOS verwendete drei druckbare numerische Zeichenfolgen, keine drei binären IEEE-Gleitkommazahlen. Viele Dezimalstellen ließen sich hinschreiben. Ob es eine Beobachtung gab, die sie rechtfertigte, blieb eine andere Frage.

DNS bot hier eine Verteilung der Pflegeverantwortung. Es gab dem Namensverwalter nicht zugleich die Fähigkeit zur Vermessung. Die Berechtigung, einen Datensatz zu ändern, und der Nachweis, dass ein Gerät an einem bestimmten Ort steht, sind unterschiedliche Dinge.

Ein späterer Entwurf, keine stillschweigende Abschaffung

Im Januar 1996 folgte der ebenfalls experimentelle RFC 1876 mit LOC. Dieser Typ konnte Positionen von Hosts, Netzen und Subnetzen beschreiben. Vorgeschlagene Anwendungen umfassten Netzverwaltungskarten und geografische Darstellungen von traceroute oder Nachrichtenflüssen.

Das sind vorgeschlagene Verwendungen. Sie belegen weder eine umfassende Einführung noch, dass eingetragene Orte tatsächlich den physischen Paketweg messen. Auch die Beispiele des Dokuments sind Lehrbeispiele, keine zuverlässige Karte realer Infrastruktur.

LOC erschien später als GPOS, erklärte RFC 1712 aber nicht für obsolet. Im DNS-Parameterregister von IANA stehen weiterhin GPOS mit Typnummer 27 und LOC mit Typnummer 29. Die Registrierung schafft unterscheidbare Formate. Sie beantwortet nicht, wie häufig sie verwendet oder wie sorgfältig sie gepflegt werden.

Drei Arten von Genauigkeit, die keine waren

Bei LOC lohnt es sich, das Wort Genauigkeit zunächst auseinanderzunehmen. Es gibt die Auflösung, mit der eine Koordinate codiert wird. Es gibt die räumliche Größe der beschriebenen Entität. Und es gibt die Unsicherheit darüber, wo diese Entität liegt.

SIZE bezeichnet den Durchmesser einer Kugel, die die Entität umschließt. Die horizontale Präzisionsangabe bezeichnet den Durchmesser eines Fehlerkreises. Die vertikale Angabe ist die gesamte mögliche vertikale Fehlerspanne. Keine dieser Angaben ist ohne Weiteres ein Wert „plus/minus“ derselben Größe.

Ein kleiner Gegenstand kann schlecht lokalisiert sein. Bei einem großen Gegenstand kann dagegen sein Bezugspunkt recht gut bekannt sein. Wer die Objektgröße als Positionsfehler verwendet, löst diese beiden Aussagen unzulässig ineinander auf.

Auch Wahrscheinlichkeiten darf der Leser nicht ergänzen. Der RFC ordnet dem Fehlerkreis kein statistisches Konfidenzniveau zu. Ein Kreis mit bestimmtem Durchmesser ist deshalb nicht automatisch die Zusicherung, dass ein bestimmter Prozentsatz aller Messungen darin liegt.

Die ausgelassenen Werte waren trotzdem vorhanden

In der Textdarstellung sind Größe, horizontale und vertikale Präzision optional. Ohne Angabe gelten ein Meter, zehntausend Meter und zehn Meter. Der RFC erklärt diese Wahl mit der Verfügbarkeit ungefährer geografischer Angaben anhand von Postleitzahlen.

Ein Meter Objektgröße und zehn Kilometer Durchmesser des horizontalen Fehlerkreises sind somit eine zulässige Kombination. Die kleine Kugel macht die große Unsicherheit nicht kleiner. Zehn Kilometer sind dabei ausdrücklich der Durchmesser und nicht der Radius.

Beim Umsetzen des Textes in den Datensatz werden die Vorgabewerte eingesetzt. Sie fehlen also nicht in der binären Antwort, nur weil der Betreiber sie nicht ausgeschrieben hat. Eine Anwendung, die allein Länge und Breite herausnimmt, kann vorhandene Einschränkungen verlieren.

Die Textform verwendet Meter für Höhe, Größe und Präzisionswerte. Die entsprechenden Binärfelder rechnen in Zentimetern. Einheit und Darstellung gehören deshalb zur Bedeutung des Wertes. Eine nackte Zahl kann diese Information beim Export nicht ersetzen.

Sechzehn Oktette vermessen nichts

Version null von LOC hat sechzehn Oktette RDATA. Gemeint ist nur der typspezifische Datenanteil, nicht der ganze Resource Record und nicht die DNS-Nachricht. Version, Größe und die beiden Präzisionsfelder belegen jeweils ein Oktett, Breite, Länge und Höhe jeweils vier.

Breite und Länge werden in Tausendsteln einer Bogensekunde mit einem verschobenen ganzzahligen Wertebereich dargestellt. Zwei hoch einunddreißig steht für Äquator beziehungsweise Nullmeridian, größere Werte bedeuten Norden oder Osten. Das ist nicht die gewöhnliche direkte Ablage vorzeichenbehafteter Winkel.

Die feine Teilung sagt, welche Zahlen das Format unterscheiden kann. Sie sagt nicht, welche Orte der Verfasser unterscheiden konnte. Bei Längendifferenzen hängt die entsprechende Bodenentfernung zudem von der Breite ab; eine überall gleiche Umrechnung in Meter wäre irreführend.

Größe und Präzision passen durch eine kompakte Darstellung in je ein Oktett: eine Dezimalziffer und ein Zehnerexponent, bezogen auf Zentimeter. Werte von zehn bis fünfzehn in den Halbbytes sind nicht definiert. Null mal zehn hoch null bedeutet weniger als einen Zentimeter und nicht mathematisch perfekte Fehlerfreiheit.

Auch die Versionsprüfung gehört zum Lesen. Für eine nicht verstandene Version darf ein Programm nicht einfach dieselbe Auslegung annehmen. Empfangene Bytes und verstandene Daten sind nicht gleichbedeutend.

Eine Höhe braucht eine Bezugsebene

Die Höhe bezieht LOC auf das WGS84-Referenzellipsoid. Für die Speicherung liegt der Nullpunkt des Zählers hunderttausend Meter darunter; gezählt werden Zentimeter. Null Meter relativ zum Ellipsoid ergibt deshalb den gespeicherten Wert zehn Millionen.

Der Versatz macht negative Höhen relativ zur Bezugsfläche ohne negative Speicherwerte darstellbar. Er hebt keinen Standort tatsächlich um hundert Kilometer an. Ebenso wenig setzt er mittleren Meeresspiegel und Referenzellipsoid gleich.

Eine Näherung anhand des Meeresspiegels ist nach dem RFC mit angemessener Behandlung von Höhe oder vertikaler Präzision möglich. Entscheidend ist, den Unterschied nicht zu unterschlagen. Mehr Nachkommastellen korrigieren keinen falsch gewählten Bezugspunkt.

Wenn der Host fehlte, half manchmal das Netz

Von einem Namen aus muss zunächst dessen LOC abgefragt werden; CNAME wird wie gewohnt verfolgt. Fehlt der direkte Datensatz, darf die Anwendung anhand zugehöriger A-Adressen nach einer Netz- oder Subnetzposition suchen. Von einer IPv4-Adresse aus beginnt sie dagegen mit der Rückwärtsauflösung über IN-ADDR.ARPA und fragt anschließend LOC für den ermittelten Namen ab.

Der optionale Rückgriff auf Netze verwendet ein historisches Verfahren aus RFC 1101. Spezielle Rückwärtsnamen, PTR und Daten in A-Form liefern Netzbezeichnungen und Subnetzmasken. Die betreffenden A-Werte sind in diesem Zusammenhang Masken, keine Adressen eines erreichbaren Dienstes.

Die LOC-Suche sammelt Namen und prüft vom spezifischeren Subnetz in Richtung größerer Netze. Das ist kein gewöhnliches Aufsteigen über DNS-Elternlabels und keine BGP-Weiterleitung nach längstem Präfix. Das Verfahren trägt die IPv4- und klassenbezogenen Annahmen seiner Zeit; eine allgemeine IPv6-Erweiterung ist damit nicht definiert.

Eine Netzposition kann eine gröbere Karte ermöglichen. Sie wird dadurch aber nicht zur vermessenen Position eines einzelnen Hosts. Bei mehreren A-Adressen kann eine Anwendung eine, mehrere oder kombinierte Näherungen wählen. Das Ergebnis enthält somit auch eine Entscheidung des Verbrauchers, nicht nur eine Antwort des Namensservers.

Frisch abgefragt ist nicht frisch beobachtet

Das Ressourcenmodell von RFC 1035 enthält neben Name, Typ und Klasse auch TTL. Diese Lebensdauer steuert, wann eine zwischengespeicherte Antwort erneut von der Quelle beschafft werden muss. Sie datiert keine Ortsbegehung.

RFC 4033 unterscheidet 2005 zusätzlich Cache-Kohärenz und Gültigkeitszeitraum einer DNSSEC-Signatur. DNSSEC authentifiziert Datenherkunft und schützt Integrität. Es liefert weder eine Vermessung noch Vertraulichkeit.

Daraus folgt als begrenzte Schlussfolgerung: Eine authentisch veröffentlichte Koordinate kann veraltet sein oder mit falscher Einheit und falschem Gegenstandsbezug gelesen werden. Eine erneuerte Signatur beseitigt diese Probleme nicht. Die frühen Warnungen vor öffentlich abrufbaren, sehr genauen Orten behalten deshalb ihre sachliche Bedeutung, ohne dass damit ein konkreter Angriff behauptet wird.