Zusammenfassung

  • RFC 3425 legte DNS-Opcode 1, IQUERY, dauerhaft still und verlangte auf solche Anfragen Not Implemented; die Antwort betraf die Operation, nicht die Existenz eines Namens.
  • Reverse DNS blieb als expliziter PTR-Datensatz in einem delegierten Namensraum bestehen. NOTIMP, NXDOMAIN, NODATA, PTR und DNSSEC-Validierung sind getrennte Belege.

Eine Entscheidung vor der Namenssuche

RFC 3425 erschien im November 2002, erklärte IQUERY vollständig für obsolet und ersetzte Abschnitt 6.4 von RFC 1035. Ein Nameserver sollte auf Opcode 1 mit Not Implemented antworten.

Das kann normgerechtes Verhalten belegen. Es belegt nicht, dass der Server einen owner name gesucht, NXDOMAIN ermittelt oder das Fehlen eines PTR festgestellt hat. Die Anfrage wurde bereits an der Operationsgrenze beendet.

Wer diesen Zustand „nicht gefunden“ nennt, wechselt unbemerkt das Subjekt der Aussage.

IQUERY kehrte den lokalen Datenbestand um

Nach RFC 1035 legte der Client einen RR-Wert in die Answer Section. Der Server sollte dazu passende Tripel aus Typ, Name und Klasse aus seinen Daten liefern. Das war keine Anfrage an einen PTR-owner-name unter in-addr.arpa.

Eine allgemeine Antwort erforderte einen vollständigen Scan oder einen zusätzlichen Index nach Werten. RFC 1035 nannte die Belastung, RFC 3425 beschrieb die Größenordnung: Bei Millionen Namen konnten außergewöhnlich große Antworten entstehen.

Die Suche nach allen Domains, die an einen Nameserver eines großen Providers delegiert waren, konnte zehntausende Tripel liefern. Eine kleine Eingabe löste umfangreiche Arbeit, Namensaufzählung und wenig getesteten Altcode aus. Das Dokument weist eine Entwurfsfläche aus; es behauptet keinen beobachteten Angriff.

Der kontaktierte Server konnte nicht weiterverweisen

Gewöhnliche DNS-Auflösung folgt der Delegation eines Namens. IQUERY fragte den ausgewählten Server nach seinem Datenbestand. Lag die relevante Information anderswo, bot die Operation keinen natürlichen Verweis zur zuständigen Autorität.

Zwei Server durften unterschiedliche Mengen liefern, weil ihre Daten verschieden waren. Ein Server konnte IQUERY ablehnen und zugleich passende RRsets beherbergen. Seine Antwort war daher keine globale Liste aller Namen zu einem Wert.

Eine lokale Datenbankinversion und eine Suche im delegierten Namensraum besitzen unterschiedliche Autorität.

PTR gab der Rückwärtsfrage einen owner name

Der verbreitete Weg veröffentlichte die Zuordnung als normales DNS-Datum. Für IPv4 wird ein owner name unter in-addr.arpa gebildet und nach PTR gefragt. RFC 1033, RFC 1034 und RFC 1035 beschreiben den Rahmen; RFC 2317 zeigt, dass auch Netze kleiner als /24 eine ausdrückliche Delegationskonstruktion brauchen.

PTR garantiert weder Vollständigkeit noch Identität. Es macht die Frage aber routbar: owner name, Delegationskette, Autorität, TTL und gegebenenfalls DNSSEC-Status können festgehalten werden. Fehlen hat damit eine eigene negative DNS-Semantik und muss nicht aus einer fremden Operationsablehnung erraten werden.

Fehlerklassen sind keine Synonyme

NOTIMP betrifft eine nicht unterstützte Operation. NXDOMAIN betrifft die Existenz des owner name. NODATA beschreibt einen vorhandenen Namen ohne angeforderten Typ. Timeout bedeutet nur, dass im Beobachtungsfenster keine akzeptable Antwort eintraf.

RFC 8020 präzisierte die Nutzung autoritativer NXDOMAIN-Antworten, ohne Opcode-Ablehnung in Namensfehlen zu verwandeln. RFC 8499 hält die Terminologie auseinander.

Nach IQUERY-NOTIMP folgt eine korrekt gebildete PTR-Anfrage. Nach NXDOMAIN bleiben Autorität und negativer Cache-Kontext erhalten. Ein Validierungsfehler darf nicht als gewöhnliches Fehlen gespeichert werden.

Die Stilllegung reservierte die Geschichte

RFC 3425 kennzeichnete Opcode 1 als „IQUERY (obsolete)“ und verlangte dauerhafte Stilllegung. Das IANA-DNS-Parameterregister und RFC 6895 bewahren die Zuordnung.

Stillgelegt heißt nicht frei. Eine Wiedervergabe würde historische Pakete mehrdeutig machen. Die Reservierung schützt ihre Lesbarkeit. Sie beweist jedoch nicht, dass jede alte Implementierung verschwunden ist; Norm, Binary, Konfiguration und beobachteter Verkehr bleiben getrennt.

DNSSEC braucht benannte Daten

RFC 3425 bemerkte, dass IQUERY-Antworten mit DNSSEC ohne spontane Signatur kaum abzusichern wären. Eine synthetische, womöglich riesige Wertinversion ist kein vorbereitetes RRset an einem owner name.

RFC 4033, RFC 4034 und RFC 4035 definieren die Validierung expliziter DNS-Daten und negativer Belege. Ein validierter PTR stützt eine Aussage der Zone. Er beweist nicht automatisch Adresszuteilung, Hostkontrolle, Forward-Confirmation, Erreichbarkeit, Authentisierung oder Diensterfolg.

Auch IQUERY-NOTIMP wird nicht zur authentisierten Nichtexistenz, nur weil es in einem DNS-Paket steht.

Eine nützliche Ablehnung behält ihren Gegenstand

RFC 3425 beseitigte Reverse DNS nicht. Es schloss eine teure lokale Inversion mit unklarer globaler Autorität und ließ den delegierten PTR-Pfad bestehen.

Die bleibende Regel lautet: Operation abgelehnt, Name nicht vorhanden, Typ fehlt, RRset validiert, Identität bestätigt und Dienst erfolgreich sind verschiedene Sätze. Getrennt gespeichert ist der Fehler wertvoll. Zu „kein Name“ verdichtet erzeugt er eine Wirklichkeit, die nie beobachtet wurde.

Quellen und Grenzen

Der Primärbestand umfasst RFC Editor HTML, Text, Informationsseite, Datatracker, Historie, Referenzen und Errata-Suche. DNS-Kontext liefern RFC 1033, RFC 1034, RFC 1035, RFC 2317, RFC 6895, RFC 8499, RFC 4033, RFC 4034, RFC 4035, RFC 8020 und das IANA-Register. Die Trennung symbolischer und operativer Ebenen folgt Heng Lus Essays über Realitätsebenen und laufenden Code als Primärbeleg.

Diese Quellen belegen keine heutige Verbreitung, benannte verwundbare Implementierung, gemessenen Angriff, vollständige PTR-Abdeckung, Identität, Erreichbarkeit, Autorisierung oder Anwendungsergebnis.