Zusammenfassung

  • Ein individueller Internet-Draft vom August 2026 empfiehlt, ANY gewöhnlich mit NOTIMP zu beantworten, sofern kein konkreter lokaler Grund für die alte Interpretation oder eine minimale Antwort vorliegt. Der Entwurf ist weder RFC noch IETF-Konsens.
  • Betreiber sollten jeden Verwendungszweck einzeln migrieren: Entscheidung und Client zuordnen, passende RRtypes oder einen begrenzten lokalen Diagnoseweg bereitstellen, das Ergebnis prüfen und Ausnahmen auslaufen lassen. Ein EDE erklärt eine Ablehnung, belegt aber keine abgeschlossene Migration.

Technische Gewohnheiten werden selten als institutionelle Verpflichtung bestellt. Eine schnelle Diagnoseabfrage landet in einer Arbeitsanweisung. Jemand automatisiert sie. Die Ausgabe wird Teil einer Überwachung, später vielleicht einer Umschaltentscheidung. Der ursprüngliche Autor ist längst weg, doch die Abfrage bleibt. Wenn die Infrastruktur ihr Verhalten ändert, trifft sie nicht mehr nur eine Gewohnheit, sondern eine unbeschriebene Abhängigkeit.

DNS ANY ist dafür besonders geeignet, weil schon der Name Vollständigkeit nahelegt. Tatsächlich liefert QTYPE 255 keine überall gleich interpretierte Gesamtliste eines Namens. Ein autoritativer Server kennt seine Zone. Ein rekursiver Resolver verfügt möglicherweise nur über zuvor beschaffte Datensätze. Ein Cache bildet eine zeitabhängige Auswahl ab. An Zonengrenzen und Delegationen wird zusätzlich unklar, welche Daten in die vermeintliche Gesamtheit gehören. Was nicht in einer ANY-Antwort steht, ist deshalb nicht automatisch im DNS abwesend.

draft-jabley-dnsop-no-longer-support-any-00, veröffentlicht am 6. August 2026, will diese offene Antwortpflicht weiter zurücknehmen. Der Entwurf empfiehlt als gewöhnliche Reaktion RCODE 4, NOTIMP. Bei einem bestimmten lokalen Grund lässt er die historische Interpretation der RFC 1034 und 1035 oder die von RFC 8482 zugelassenen Minimalantworten bestehen. Außerdem schlägt er einen Extended DNS Error vor, der die fehlende Unterstützung für ANY auf dem antwortenden Nameserver erklärt.

Die institutionelle Reichweite ist begrenzt. Datatracker führt einen aktiven individuellen Internet-Draft ohne RFC-Stream und mit dem Status, dass ein Entwurf existiert. Die Standards-Track-Absicht im Kopf des Dokuments ist ein Ziel der Autoren, keine Adoption durch DNSOP und keine Zustimmung der IETF. Betreiber können die Idee bewerten, ohne eine mögliche spätere Standardisierung als bereits gültige Vorgabe darzustellen.

Die offene Antwortpflicht ist nicht kostenlos

Große Antworten können für Reflexions- und Verstärkungsangriffe genutzt werden. RFC 5358 beschreibt den Missbrauch offener rekursiver Server. RFC 8482 erläutert die Motivation, ANY mit kleineren Antworten zu bedienen. Daten zusammenzustellen kostet CPU und Speicher, sie zu versenden Bandbreite. Große UDP-Nachrichten bringen Fragmentierungsprobleme mit sich; der Wechsel zu TCP verschiebt Ressourcenbedarf und Fehlerbedingungen, statt sie aufzuheben.

Eine ausdrückliche Ablehnung kann daher ein sinnvoller öffentlicher Standardfall sein. Der Betreiber muss nicht jede beliebige Informationsanforderung mit einer schwer definierbaren Menge beantworten. Doch das Abschalten von ANY ist keine vollständige DNS-Verstärkungsabwehr. Andere Abfragen können weiterhin große Antworten erzeugen. Die Reichweite rekursiver Dienste, die Kapazität autoritativer Systeme und weitere Missbrauchskontrollen bleiben eigenständige Aufgaben.

Auch legitime Anwendungen verschwinden nicht durch die Sicherheitsbegründung. Ein Administrator nutzt ANY vielleicht für einen ersten Blick. Eine alte Bibliothek erwartet eine bestimmte Antwortform. Ein internes Werkzeug versucht, einen Cache zu untersuchen. Diese Zwecke rechtfertigen nicht automatisch das alte Verhalten für beliebige öffentliche Clients. Sie verlangen eine differenzierte Entscheidung über Wert, Zuständigkeit, Ersatz und Dauer.

Eine erfolgreiche Serveränderung kann mit einem gescheiterten Übergang zusammenfallen. Der alte Client erhält NOTIMP, wiederholt die Anfrage oder wechselt das Ziel. Vielleicht verwendet er zunächst gespeicherte Daten und meldet nichts. Erst die Cache-Ablaufzeit, eine Delegationsänderung oder ein Notfallwechsel bringt den Fehler hervor. Ein ruhiger Betrieb unmittelbar nach der Umstellung ist dann geliehene Zeit, keine Migrationsbestätigung.

Der Zweck bestimmt den Ersatz

Eine Maildiagnose braucht MX und die von ihrer Logik verlangten Folgeschritte. Eine Delegationsprüfung braucht NS, ein Verständnis von Verweisen und die notwendigen Adressauflösungen. Ein Dienstentdeckungsprotokoll sollte seine ausdrücklich festgelegten RRtypes abfragen. Eine Cacheinspektion gehört auf eine autorisierte lokale Diagnoseschnittstelle, deren Umfang und Aktualität bekannt sind. Eine externe ANY-Antwort war nie eine zuverlässige Inventur des gesamten Resolver-Caches.

ANY pauschal durch eine Salve aller bekannten Datensatztypen zu ersetzen, wäre deshalb keine saubere Migration. Sie könnte mehr Verkehr und Datensammlung erzeugen, ohne die beabsichtigte Entscheidung genauer zu machen. Der Zielzustand ist nicht eine ähnlich große Antwort. Es ist eine ausdrücklich formulierte, angemessen begrenzte Informationsanforderung.

Vor dem Rollout sollten Betreiber ein Zweckregister aufbauen. Ein begrenztes Beobachtungsfenster kann empfangenden Dienst, Quellenklasse, bekannte interne Arbeitslast, Wiederkehr, Transport, Antwortgröße und Zuordnungshinweise erfassen. Dazu braucht es keine unbegrenzte Speicherung aller abgefragten Namen. Datenminimierung, Aufbewahrungsfrist und beschränkter Zugriff halten die Erhebung an ihren Migrationsauftrag gebunden.

Für jede wiederkehrende Gruppe muss jemand die funktionale Behauptung erklären. Welche Entscheidung verbraucht das Ergebnis? Wer kann den Client ändern? Was geschieht heute bei einer unvollständigen Antwort? Wird Cacheinhalt mit autoritativer Vollständigkeit verwechselt? Wann wird der Pfad tatsächlich aktiv? Dabei zeigt sich häufig, dass der alte Client schon vor dem geplanten Rückzug auf einem nicht garantierten Verhalten beruhte.

Unzugeordnete Quellen bleiben ausdrücklich unbekannt. Es könnte sich um Scanner, nicht inventarisierte Partner oder vergessene Systeme handeln. Unbekanntheit begründet keinen ewigen Anspruch auf öffentliche Kompatibilität. Sie darf aber auch nicht als Harmlosigkeit verbucht werden. Eine benannte Instanz muss über verbleibende Untersuchung oder akzeptiertes Restrisiko entscheiden.

Ausnahmen sind Entscheidungen, keine Eigenschaft des Servers

Ein notwendiger Zweck erhält einen Ersatz mit RRtype oder passender Schnittstelle, Clientversion, ausgerollter Population und Ergebnisprüfung. Ein überflüssiger Zweck wird entfernt; die Organisation beobachtet die Arbeitszyklen, in denen er wieder auftauchen könnte. Eine sinnvolle interne Diagnose wird an Authentisierung und einen beherrschten Netzwerkbereich gebunden.

Für ein nicht sofort änderbares Programm ist eine befristete Ausnahme möglich. Sie braucht Eigentümer, Zweck, erlaubte Quellen, betroffenen Bereich, kompensierende Kontrolle, Ablaufdatum und Abschaltbedingung. Ist das Programm nicht mehr wartbar, gehört es in einen Ersatzplan. Ein regelmäßig automatisch verlängertes Ablaufdatum macht aus einer Ausnahme eine Dauerpolitik, ohne diese offen zu benennen.

Ein unbekannter Zweck erhält dagegen einen Untersuchungsschritt oder eine ausdrückliche Risikoentscheidung. Das Register muss nicht jeden öffentlichen Absender retten. Es soll verhindern, dass die Organisation eine unbekannte Last als abgeschlossene Arbeit ausgibt.

Diese Zuordnung erlaubt einen abgestuften Rollout. Aktualisierte verwaltete Clients können früh auf das neue Verhalten umgestellt werden, während eine kleine bekannte Gruppe vorübergehend ausgenommen bleibt. Öffentliche autoritative Dienste und lokale Diagnosewerkzeuge brauchen nicht denselben Kompatibilitätspfad, nur weil sie dieselbe Software verwenden. Gemeinsamer Code ist keine gemeinsame Rechtfertigung für jede Betriebsentscheidung.

NOTIMP meldet den Rand, nicht den Fortschritt

RCODE 4 macht die Ablehnung auf der DNS-Ebene klar. Das ist ehrlicher als eine Antwort, deren geringe oder wechselnde Inhalte der Client als umfassend missversteht. Betreiber können die Ablehnungen zählen, konzentrierte Quellen suchen und mit dem Register abgleichen. Der Code kennt aber den Zweck der Anfrage nicht und weiß nichts über die Ersatzfähigkeit des Clients.

Rekursive Resolver und Weiterleitungswege können beeinflussen, welche Information am Ende sichtbar wird. Ein Client kann Transport oder Ziel wechseln. Ein Supportwerkzeug zeigt vielleicht nur einen allgemeinen Fehler. Eine gewünschte RCODE-Verteilung bestätigt die Serverkonfiguration, nicht die Bewahrung einer betrieblichen Entscheidung.

RFC 8914 definiert EDE als zusätzliche Erklärung, ohne die normale RCODE-Verarbeitung zu ändern. Mehrere EDEs können vorkommen. Weiterleitung und Umschreiben hängen von der Implementierung ab. Der optionale Zusatztext richtet sich an Menschen und kann bei Größenbeschränkungen entfallen. Er ist keine stabile maschinenlesbare Anweisung.

Der vorgeschlagene Hinweis auf fehlende ANY-Unterstützung kann einem Administrator helfen, eine beabsichtigte Grenze von einem Defekt zu unterscheiden. Ein Programm sollte aber nicht einen englischen Satz auswerten, um seine neuen RRtypes zu wählen. Und ein Projekt darf nicht als migriert gelten, weil der Satz seinen Resolver passiert.

Der belastbare Nachweis liegt in der tatsächlich installierten Version, den gesendeten ausdrücklichen Abfragen und dem funktionalen Ergebnis. Erklärbarkeit und Ersatz sind unterschiedliche Leistungen. Werden sie zu einem einzigen grünen Status zusammengezogen, entsteht eine leicht erfüllbare Kennzahl, die gerade die entscheidende Abhängigkeit nicht prüft.

Die Prüfung muss bis zur Entscheidung reichen

ANY zu senden und NOTIMP zu empfangen ist ein Servertest. Eine Übergangsprüfung stellt die Aufgabe des Verbrauchers nach. Findet die Maildiagnose die relevanten Daten und behandelt ihre Abwesenheit korrekt? Unterscheidet der Delegationscheck autoritative Antworten und Verweise? Führt er erforderliche Adressabfragen aus? Fragt die Dienstentdeckung alle von ihrem Protokoll benötigten RRsets ab? Ist die Cacheinspektion autorisiert und ihr Datenstand verständlich?

Leere RRsets, Kürzung, DNSSEC-Validierungsfehler, TCP-Verzögerung, Teil-Caches und reale Weiterleitungswege gehören dazu. Autoritative und rekursive Systeme müssen getrennt untersucht werden. Bei gemischten Clientversionen braucht jede Population eigene Ergebnisse, damit eine gesunde Mehrheit keine kleine kritische Altgruppe verdeckt.

Auch seltene Auslöser zählen: Monatsroutinen, Notfallwiederherstellung, Zonenänderungen und die Aktivierung stillgelegter Reservegeräte. Zwei störungsfreie Tage prüfen keinen Aufruf, der erst im nächsten Monat erfolgt. Der Zweck bestimmt das Beobachtungsfenster. Zweck, Ersatz, Verantwortlicher, Population und Frist bilden gemeinsam eine überprüfbare Stilllegung.

Quellen

  1. Aktueller Entwurfsdatensatz
  2. Entwurfshistorie
  3. Revision 00 als HTML
  4. Revision 00 als Text
  5. XML der Revision 00
  6. DNSOP-Charta
  7. DNSOP-Dokumente
  8. RFC 1034: DNS-Konzepte
  9. RFC 1035: DNS-Spezifikation
  10. RFC 6895: DNS und IANA
  11. RFC 8482: Minimalantworten für ANY
  12. RFC 8914: Erweiterte DNS-Fehler
  13. RFC 5358: Rekursive Server in Reflexionsangriffen
  14. RFC 9364: DNS-Sicherheit und Betrieb
  15. RFC 9499: DNS-Terminologie
  16. RFC 7766: DNS über TCP
  17. IANA-DNS-Parameter
  18. IANA-EDE-Codes
  19. Lu Heng: Minimale Anfangsspezifikation und lokale Entscheidung
  20. Lu Heng: Der Spiegel der Politik