Zusammenfassung

  • IQUERY kehrte die übliche DNS-Nachricht um: Ein Resource Record wurde im Answer-Abschnitt vorgegeben, damit der Server passende Owner Names im Question-Abschnitt zurückgab.
  • DNS ordnete Autorität nach Namen und Zonen, nicht nach beliebigen Record-Werten; deshalb konnte eine lokal richtige Liste niemals belegen, dass sie den verteilten Namensraum vollständig erfasste.
  • Vollständige Datenbanksuchen, Zusatzindizes, ungeeignete Cache-Semantik, große Antworten und Offenlegungsrisiken machten die schwache Zusage teuer, während PTR unter IN-ADDR.ARPA die Adressumkehr als gewöhnliche delegierbare Namensabfrage ausdrückte.

Eine Antwort stand fest, bevor die Frage bekannt war

Bei einer normalen DNS query nennt der Client QNAME, QTYPE und QCLASS im Question-Abschnitt. Die Antwort liefert passende Records. IQUERY begann mit einer ungewöhnlichen Anordnung: Question blieb leer, während Answer etwa A IN 10.1.0.52 enthielt. Gesucht waren alle Namen, für die dieser Record eine Antwort bilden würde.

RFC 1035 wies der Operation opcode 1 zu. Owner name und TTL des vorgegebenen RR waren bedeutungslos; ein einzelnes Null-Oktett für die Root konnte als kürzester Platzhalter dienen. Der Server schrieb null, einen oder mehrere Sätze aus QNAME, QTYPE und QCLASS in den Question-Abschnitt der response und passte den Answer-Record an den ersten Treffer an.

Auf Paketebene entstand eine saubere Symmetrie. Die Standardoperation ging vom Namen zur Ressource, die inverse Operation von der Ressource zu Namen. Das flexible Nachrichtenformat konnte beide Richtungen tragen.

Das verteilte System war jedoch nicht symmetrisch aufgebaut. Ein Resolver mit einem Namen kann Delegationen von der Root bis zu der Zone verfolgen, die für diesen Namen zuständig ist. Für eine Adresse, ein MX-Ziel oder eine andere in RDATA gespeicherte Zeichenfolge gab es keinen entsprechenden Pfad zu allen Zonen, in denen derselbe Wert vorkommen könnte.

Die Grenze war bereits 1983 Teil der Beschreibung

RFC 882 hielt fest, dass das domain system Vollständigkeit und Eindeutigkeit inverser queries nicht garantieren könne. Es sei nach domain names organisiert und nicht nach host addresses oder anderen resource types. Wer eine Garantie benötigte, musste einen Server kennen, der die passenden Daten besaß, oder alle Server im interessierenden Bereich befragen.

Das war keine vorübergehende Entschuldigung für geringe Rechenleistung. Es fehlte ein Verfahren, Zuständigkeit anhand des Suchwerts zu finden. Bei Namen sind Delegationen selbst Teil des DNS. Ein Parent weist auf den nächsten Verantwortlichen. Ein beliebiger Wert besitzt keinen Parent und keinen referral, der den Suchraum Schritt für Schritt eingrenzt.

RFC 883 behandelte inverse queries folglich umgebungsabhängig. Innerhalb einer Organisation konnte ein Resolver zu ausgewählten Servern geschickt werden, die eine ausreichend breite lokale Kopie hielten. Das half bei Verwaltung und Diagnose, ohne aus einer lokalen Datenbasis eine globale Instanz zu machen.

Drei gefundene Beziehungen können vollkommen wahr sein. Dennoch kann ein vierter Name in einer unbekannten Zone stehen. Wahrhaftigkeit über sichtbare Daten ist nicht dasselbe wie Vollständigkeit und verleiht keine Autorität über abwesende Daten.

Der eigentliche Geltungsbereich war das Wissen des gewählten Servers

RFC 1035 formulierte die Einschränkung direkt: Eine response nennt passende Namen, which the name server knows. Da kein Server den gesamten domain space kennt, darf das Ergebnis niemals als vollständig gelten. IQUERY wurde vor allem für database management und debugging beschrieben und ausdrücklich als ungeeignet für die allgemeine Abbildung von host addresses auf host names bezeichnet.

Null Treffer bedeuteten lediglich, dass der angesprochene Server in seinem sichtbaren Bestand nichts fand. Sie bewiesen keine weltweite Abwesenheit. Ein Treffer zeigte eine sichtbare Beziehung, aber keine Eindeutigkeit. Eine sehr lange Liste konnte sich immer noch nur aus autoritativen lokalen Zonen, zufälligem Cache-Inhalt oder den Record-Typen mit vorhandenem Index zusammensetzen.

Eine normale negative DNS-Antwort besitzt einen erkennbaren Rahmen. Der abgefragte Name führt zu einer autoritativen Zone, innerhalb derer eine Aussage über Nichtexistenz möglich ist. IQUERY definierte keine Zone für „alle Records mit diesem Wert“. Um Abwesenheit zu beweisen, hätte der Client jeden möglichen Ort ausschließen müssen.

Die Beweiskraft einer Suche besteht daher nicht nur aus korrekten Ergebniszeilen. Sie verlangt ein benanntes Suchuniversum, einen Verantwortlichen, einen Zeitpunkt und eine Methode, ausgelassene Partitionen zu erkennen. Fehlt dieser Kontext, sieht eine sauber sortierte Teilliste vollständiger aus, als sie ist.

Die Umkehr verlangte eine zweite Datenbank neben der ersten

Name server legen Records naturgemäß unter Owner Names ab, denn Standardqueries beginnen mit QNAME. Eine schnelle Suche nach RDATA-Inhalten benötigt einen anderen Zugriffspfad.

RFC 883 beschrieb Inversionstabellen je Zone und Suchschlüssel. Änderungen an der Zone mussten diese Strukturen mitführen. RFC 1035 stellte zwei Möglichkeiten gegenüber: die Datenbank erschöpfend durchsuchen oder eine separate, nach Werten der Primärdatenbank indizierte Datenbank pflegen. Der Scan kostet bei jeder request Rechenzeit; der Index kostet dauerhaft Speicher, Synchronisation und Fehlerfläche.

Auch der Vergleich war typabhängig. RDATA kann Adressen, domain names, character strings oder komplexe Strukturen enthalten. RFC 1035 empfahl soweit möglich Vergleiche ohne Beachtung der Großschreibung, räumte aber ein, dass ein Server manche gespeicherten Oktette nicht als Text erkennen kann. „Finde diesen Wert“ war keine universelle Byteoperation.

Die Kostenverteilung blieb einseitig. Der entfernte Client sandte einen kleinen Suchwert. Der Betreiber trug Index, Scan, Zusammenstellung und Übertragung. Die query zeigte weder einen Nutzen für die Zone noch eine natürliche Obergrenze für die Ergebnismenge.

Einzelne DNS records öffentlich auflösbar zu machen ist nicht dasselbe wie beliebige Analysen über ihren gesamten Inhalt anzubieten. IQUERY band die zweite Leistung an dieselbe Infrastruktur, die bereits den Betriebsdaten dienen musste.

Ein Cache vervielfältigt eine Sicht, nicht deren Autorität

DNS skaliert, weil Resolver RRsets bis zum Ablauf ihrer TTL wiederverwenden. IQUERY-Ergebnisse passten nicht sauber in dieses Verfahren. RFC 1035 warnte, dass sie nicht auf dieselbe Weise wie gewöhnliche Antworten gecacht werden können.

Ein multihomed Host kann mehrere Adress-RRs desselben Typs besitzen. Wird sein Name über eine einzige Adresse gefunden, liegt damit nicht zwangsläufig der vollständige RRset vor. Speichert ein Cache den extrahierten Record wie eine normale Antwort unter dem rekonstruierten QNAME, macht er aus einer Teilrelation scheinbar einen ganzen Namensbestand.

Zudem geht der ursprüngliche corpus leicht verloren. Welche Zonen der Server tatsächlich kannte, welche Cache-Daten einflossen und welche Partitionen nie geprüft wurden, steht nicht selbstverständlich am weitergegebenen Ergebnis. Mehr Kopien senken die Zugriffskosten, erweitern jedoch nicht den Geltungsbereich.

In einer Standardquery richten sich lookup key, Delegation, Autorität, cache key und TTL am Namen aus. IQUERY verwendete das Nachrichtenformat weiter, löste aber diese Ausrichtung. Jede Optimierung musste die unbequeme Bedingung erhalten: gültig nur für das Wissen dieses Servers zu diesem Zeitpunkt.

PTR machte aus der Umkehr wieder eine Namensfrage

Die erfolgreiche Adressrückauflösung entstand nicht durch eine bessere globale Wertsuche. RFC 1034 beschreibt IN-ADDR.ARPA. Die Oktette einer IPv4 address werden in umgekehrter Reihenfolge als Labels unter eine besondere Domain gesetzt. Am so gebildeten owner name kann ein PTR record auf einen domain name verweisen.

Für 10.1.0.52 erzeugt der Resolver einen vorhersagbaren Namen im Reverse Tree und stellt eine normale query. Teile dieses Baums lassen sich delegieren. Autoritative Server können gefunden, RRsets mit TTL gecacht und negative Antworten innerhalb einer benannten Zone verstanden werden.

Die zusätzliche Indirektion ist der entscheidende Gewinn. PTR verspricht nicht, dass jede Adresse einen Record besitzt, dass nur ein Name existiert oder dass der zurückgegebene Name eine Maschine authentisiert. Es stellt die umgekehrte Behauptung unter einen Owner Name, für den DNS bereits einen Zuständigkeitsweg hat.

IQUERY verlangte, aus einem Wert einen unbekannten Index im verteilten System zu entdecken. PTR verlangt vom Verantwortlichen des Reverse Space, eine ausdrückliche Beziehung an einem bekannten Namen zu veröffentlichen. Aus offener Suche wird delegiertes Retrieval.

Dem ehrlichen Client fehlte Gewissheit, dem Angreifer genügte der Aufwand

RFC 3425 erklärte IQUERY 2002 vollständig für obsolete. Die Operation war nicht allgemein implementiert worden und Betreiber schalteten vorhandene alte Unterstützung häufig ab. Genannt werden Fehler in selten ausgeführtem Code, Datenbanklast und die Offenlegung großer Namensblöcke.

Einige Werte konnten außerordentlich viele Treffer erzeugen. Eine Anfrage nach allen Domains, die an den Nameserver eines großen Providers delegiert waren, konnte zehntausende Tupel und Megabytes an Antwortdaten liefern. Eine kleine Anfrage löste so unverhältnismäßige Berechnung und Übertragung aus und bot einen Ansatz für denial of service.

Inverse MX queries konnten zahlreiche Namen hinter gemeinsamer Mail-Infrastruktur zusammenstellen. Dass einzelne RR öffentlich abrufbar sind, bedeutet nicht, dass ein Zonenbetreiber einen Massenkatalog nach jeder beliebigen Dimension anbietet. IQUERY senkte die Aggregationskosten und verlagerte sie zugleich auf den Server.

Der legitime Nutzer wollte eine vollständige Liste und bekam sie nicht. Ein Angreifer brauchte keine Vollständigkeit: CPU, Speicher oder Bandbreite zu verbrauchen oder einen großen lokalen Namensbestand zu sammeln, reichte aus. Die epistemische Schwäche schützte nicht vor operativem Missbrauch.

Dauerhafte Stilllegung bewahrte die Eindeutigkeit des Opcodes

RFC 3425 gab opcode 1 nicht für eine neue Bedeutung frei. Das Dokument ersetzte den einschlägigen Teil von RFC 1035, bezeichnete IQUERY als obsolete, empfahl Not Implemented als Antwort und verlangte die permanente Stilllegung der Nummer.

Eine Wiederverwendung hätte altes software dazu bringen können, neue Pakete nach der aufgegebenen Semantik auszulegen. Ein stillgelegter Wert ist daher kein bloßer Verlust. Er bewahrt eine eindeutige Protokollgeschichte und beendet die Serviceerwartung, ohne eine neue Kollision zu schaffen.

Das RFC stellte außerdem fest, dass kein bekannter Client IQUERY für einen bedeutsamen Dienst verwendete, während PTR unter IN-ADDR.ARPA die übliche Rückabbildung seit Jahren trug. Die Entfernung respektierte damit tatsächlich vorhandene Abhängigkeiten.

DNSSEC zeigte das Beweisproblem noch schärfer. RFC 3425 hält die Absicherung von IQUERY responses ohne Signatur bei der Antworterzeugung für äußerst schwierig. Eine signierte Zone authentisiert benannte RRsets und negative Nachweise in einer Namensstruktur. Eine beliebige Wertsuche müsste zusätzlich glaubhaft machen, dass aus einem nicht global definierten Suchuniversum kein Treffer fehlt.

Der Server blieb Zeuge und wurde nicht zum gesamten Namensraum

Ein DNS server kann ein realer Teilnehmer, für Zonen autoritativ und im Besitz korrekter Daten sein. Damit ist er ein guter Zeuge für einen bestimmten Bereich. Eine durchsuchbare Kopie macht ihn nicht zum Principal aller außerhalb liegenden Namen mit demselben Wert.

Lu Hengs Notizen trennen Teilnahme von Ermächtigung und Datenbankverwaltung von Autorität über das Beschriebene. IQUERY macht dieselbe Grenze technisch sichtbar. Sichtbarkeit erlaubt eine Aussage über das Sichtbare, aber keine globale Negation über abwesende Zonen.

Die Reparatur bestand nicht in einem größeren zentralen Katalog. DNS behielt eine kleine gemeinsame Schicht aus Namen, Delegationen, RR types, TTL und ausdrücklich veröffentlichten Reverse Records. Teilnehmer äußern Behauptungen in begrenzten Zonen; Resolver folgen gemeinsamen Regeln, ohne einem Vermittler Allwissen zu verleihen.

Grenzen der Quellen

Die fünf RFCs belegen Nachrichtenform, bekannte Beschränkungen, den PTR-Weg und die normative Stilllegung. Sie messen keinen heutigen opcode-1-Verkehr, erfassen nicht jede historische Implementation und schließen private Diagnoseanwendungen nicht aus.

NOTIMP ist die erwartete Antwort, aber kein Beweis dafür, dass ein Server die request nie untersucht hat. Ein timeout kann auf Filterung oder Verlust beruhen. Eine positive response beweist lokale Verarbeitung, nicht globale Vollständigkeit.

Auch PTR ist kein Identitätsnachweis. Forward- und Reverse-Daten können fehlen, voneinander abweichen oder mehrere Werte enthalten. Der Vorteil liegt hier in der auffindbaren Verantwortung für eine Behauptung, nicht in ihrer automatischen Wahrheit.

IQUERY gab der Frage eine Richtung, aber der Autorität keine. Ein Bit konnte die Nachricht umkehren; es konnte die Delegationen des verteilten Systems nicht umkehren. DNS wurde verlässlicher, als es die reizvolle Symmetrie aufgab und Reverse-Beziehungen wieder unter Namen stellte.

Quellen