Zusammenfassung

  • Ein RRset umfasst zusammengehörige Records gleichen Namens, gleicher Klasse und gleichen Typs. Eine kleine ANY-Antwort kann ein solches Set vollständig liefern, ohne sämtliche verfügbaren Typen aufzuzählen.
  • RFC 8482 erlaubte 2019 mehrere optionale Verfahren für kleine Antworten, darunter ein synthetisches HINFO. Ein nichtleerer, normal speicherbarer Eintrag sollte weitere ANY-Anfragen begrenzen, ohne neue Fehlerbehandlung bei allen Clients vorauszusetzen.
  • Die Wiederverwendung von HINFO hatte einen Preis: Im Cache konnte sie echte Hostinformationen verdecken. Die TTL musste zugleich Wiederholungen dämpfen und spätere Änderungen der Antwortpolitik ermöglichen.

Vollständig innerhalb welcher Grenze?

Mehrere Adress-Records können zu einem Namen gehören. Liefert ein Server den zugehörigen Satz, darf er nicht willkürlich nur ein Mitglied auswählen und den Rest so behandeln, als sei er nie vorhanden gewesen. Diese Einheit ist jedoch etwas anderes als die Menge sämtlicher Recordtypen, die zu dem Namen existieren.

RFC 2181 präzisierte im Juli 1997 den Begriff RRset: Records mit gleichem Namen, gleicher Klasse und gleichem Typ, aber gegebenenfalls unterschiedlichen Daten. Ein solches Set wird als Einheit übertragen. Passt ein erforderliches Set nicht vollständig in die Antwort, greifen die Regeln für eine gekürzte Antwort.

Bei ANY kann der Server dagegen entscheiden, nur ein vollständiges RRset aus mehreren verfügbaren Sets zurückzugeben. Dann ist die interne Einheit erhalten, die Bestandsaufnahme aber unvollständig. Wer das erste Merkmal prüft und daraus das zweite ableitet, fragt die Antwort nach einer Zusicherung, die sie nicht enthält.

Diese Unterscheidung wurde zum Kern einer Antwortpolitik, die weniger Daten und weniger Folgearbeit erzeugen sollte.

Das Sternchen war keine Zonenübertragung

Die DNS-Spezifikation von November 1987 verwendete für den Abfragetyp 255 das Zeichen Sternchen. RFC 1035 beschrieb ihn als Anfrage nach allen Records; Implementierungen verwendeten dafür gewöhnlich den Namen ANY. Das Wort lud dazu ein, mehr Vollständigkeit zu erwarten, als der konkrete Austausch tragen konnte.

Schon die Grundstruktur in RFC 1034 trennt den abgefragten Namen, den Abfragetyp und die Klasse. ANY im Typfeld ist weder ein Platzhalter im Namen noch AXFR, die besondere Anfrage für eine Zonenübertragung. Nach Informationen zu einem Namen zu fragen bedeutet nicht, alle Namen der Zone aufzuzählen.

Auch der Speicherort der Antwort zählt. Der beschriebene Serveralgorithmus unterscheidet Zonendaten und Cache. Im Cache vorhandene passende Records bilden keine Garantie dafür, dass dort alle Informationen liegen, die ein autoritativer Server liefern könnte. Ein erfolgreicher Cachetreffer war nie von selbst ein vollständiges Inventar.

Die heutige IANA-Registrierung der DNS-Parameter macht die Begrenzung ausdrücklich: Typ 255 betrifft einige oder alle beim Server verfügbaren Records. HINFO bleibt daneben als Typ 13 für Hostinformationen registriert. Diese Einträge belegen Bedeutungen und Nummern, nicht die aktuelle Verbreitung bestimmter Betriebsweisen.

Eine Ablehnung konnte neue Arbeit auslösen

RFC 8482, veröffentlicht im Januar 2019, aktualisierte RFC 1034 und RFC 1035. Er behandelte eine lokale Entscheidung autoritativer Betreiber: konventionelle ANY-Antworten aus Sicherheits-, Leistungs- oder anderen Gründen nicht in gewohnter Größe liefern zu wollen.

ANY hatte legitime Anwendungen, etwa die Fehlersuche und die Untersuchung des Zustands eines Servers für einen Namen. Manche Anwendungen versuchten damit auch, mehrere benötigte Typen wie MX, A und AAAA in einer Abfrage zu erhalten. Der RFC warnte jedoch davor, sich darauf zu verlassen, dass die Anfrage tatsächlich einen autoritativen Server erreicht und sämtliche vorhandenen Sets zurückbringt.

Daneben konnten kleine UDP-Anfragen große Antworten auslösen und damit für Reflexionsangriffe attraktiv sein. Manche Server mussten für die konventionelle Antwort zusätzliche Arbeit leisten. Der Text liefert hier keine aktuelle Angriffszählung und keine allgemeine Aussage, dass jede ANY-Anfrage bösartig sei.

Eine diskutierte Lösung war ein neuer Antwortcode für die abweichende Behandlung. Nach der Darstellung des RFC hatte dieser Ansatz einen unerwünschten Effekt: Resolver verstanden den unbekannten Code nicht als dauerhaft nützliche Begrenzung, sondern versuchten die Anfrage bei weiteren verfügbaren autoritativen Servern.

Die Alternative gab ihnen etwas Gewöhnliches: ein nichtleeres RRset, das sich normal im Cache halten ließ. Eine kleine erfolgreiche Antwort konnte dadurch wiederholte ANY-Anfragen begrenzen, wo eine neuartige Ablehnung zusätzliche Arbeit ausgelöst hatte. Das ist eine Aussage über den beschriebenen Mechanismus, nicht über jedes Fehlersignal in jeder heutigen Implementierung.

Drei Wege, nicht ein vorgeschriebenes HINFO

Die Regeln von RFC 8482 betreffen in diesem Abschnitt existierende Namen mit Klasse IN und Abfragetyp ANY. Sonst bleiben die normalen Antwortalgorithmen maßgeblich. Ein nicht existierender Name soll deshalb nicht einfach mit einer erfundenen Hostinformation versehen werden.

Ein erster Weg ist die Auswahl eines oder weniger verfügbarer RRsets. Der RFC sagt ausdrücklich, dass dabei kein Signal anzeigt, dass weitere Sets weggelassen wurden. Das Fehlen etwa eines TXT-Sets in dieser Antwort beweist nicht, dass es beim Namen kein TXT gibt.

Der zweite Weg erzeugt ein HINFO, sofern beim passenden Namen kein CNAME vorhanden ist. Empfohlen wird ein einzelner HINFO-Record mit der Zeichenfolge RFC8482 im CPU-Feld und einer leeren Zeichenfolge im OS-Feld. Das ist keine Aufforderung, die Zone dauerhaft um diesen Record zu erweitern.

Ein dritter Weg versucht, die vermutete Absicht zu bedienen: vorhandene Sets der Typen CNAME, MX, A und AAAA liefern, andere wie TXT oder DNSKEY weglassen. Diese Heuristik kann größer ausfallen als die anderen kleinen Antworten und versteht nicht zuverlässig den Bedarf jeder Anwendung.

Die Verfahren sind optional. RFC 8482 schaffte ANY nicht ab und verpflichtete nicht jeden Betreiber, HINFO zu synthetisieren. Er eröffnete unterschiedliche Möglichkeiten, die Folge eines überbreiten Abrufs lokal zu begrenzen.

Ein Host-Record mit einer anderen Aufgabe

HINFO war für etwas anderes entworfen worden. RFC 1035 definiert zwei Zeichenfolgen für CPU und Betriebssystem. Als Verwendung nennt er allgemeine Hostinformationen und Verfahren wie FTP, die bei ähnlichen Maschinen oder Betriebssystemen besondere Übertragungsweisen nutzen können.

Die synthetische Form nutzt dieselbe Struktur. Ein leeres OS bleibt eine vorhandene Zeichenfolge der Länge null; es ist kein weggelassenes zweites Feld und keine Entdeckung, der entfernte Rechner habe kein Betriebssystem. Bei einer bewusst nach RFC 8482 erzeugten Antwort ist RFC8482 im CPU-Feld ebenfalls keine gemessene Prozessorarchitektur.

Auf der Empfangsseite ist jedoch Vorsicht nötig. Der RFC warnt davor, allein anhand dieser Daten sicher zu entscheiden, ein HINFO sei synthetisch oder der Server implementiere genau dieses Verfahren. Die Zeichenfolge ist kein beglaubigtes Politikkennzeichen.

Gleichzeitig erlaubt der Abschnitt über Initiatoren das normale Caching und beschreibt eine optionale Unterdrückung weiterer ANY-Anfragen bei entsprechendem HINFO im Cache. Alternativ kann gewöhnlich aus dem Cache geantwortet werden. Diese Erlaubnis zur Cachebehandlung ist nicht mit einer sicheren Erkennung der Herkunft jedes HINFO gleichzusetzen.

Die alte Bedeutung verschwand nicht kostenlos

Ein synthetisches HINFO kann nach dem Speichern auch spätere gezielte HINFO-Anfragen bedienen und dadurch die echte Hostinformation in der Zone verdecken. Genau diesen Nebeneffekt nennt RFC 8482. Wer die gewöhnliche HINFO-Bedeutung tatsächlich benötigt, sollte einen anderen der beschriebenen Wege oder einen anderen Typ wählen.

Die Autoren hielten HINFO aufgrund ihrer damaligen Beobachtungen für selten genutzt. Das ist eine zeitgebundene Einschätzung von 2019, kein hier erhobener Bestand für 2026. Seltene Nutzung ist außerdem nicht gleichbedeutend mit dem Fehlen jedes betroffenen Nutzers.

Die TTL verbindet den Nutzen mit einem weiteren Preis. Sie soll lang genug sein, um häufige Folgeanfragen desselben Initiators nach demselben Namen zu dämpfen. Zu lange Werte erschweren aber spätere Änderungen der ANY-Politik. Ein fester universeller Wert wird daraus nicht.

RFC 2181 stellt zusätzlich klar, dass eine TTL die maximale und nicht die verpflichtende Aufbewahrungszeit bezeichnet. Caches können sie begrenzen. Der Betreiber kontrolliert damit weder eine exakt gleichlange Speicherung überall noch ein augenblickliches gemeinsames Vergessen, sobald er seine eigene Einstellung ändert.

Klein ist nicht negativ, ungekürzt nicht allwissend

RFC 2308 unterscheidet seit März 1998 negative Antworten auf unterschiedliche Fragen. NXDOMAIN ist ein Namensfehler. NODATA wird aus einer Antwort erschlossen, die für einen gültigen Namen keinen passenden Typ liefert; es ist kein eigener Antwortcode. Die negative Cachebehandlung verwendet ihre eigenen Voraussetzungen, unter anderem SOA-Informationen.

Eine nichtleere kleine ANY-Antwort ist nicht schon deshalb eine negative Aussage über alles, was sie nicht enthält. Ein gezielt benötigter Typ muss gezielt erfragt werden, statt aus seiner Abwesenheit in einer Auswahl auf Nichtexistenz zu schließen.

Ähnlich begrenzt ist das TC-Bit. Die Regeln für ein nicht vollständig passendes erforderliches RRset sind nicht mit der Auswahl weniger Typen zu verwechseln. Ein nicht gesetztes TC-Bit bescheinigt deshalb keine vollständige Bestandsaufnahme des Namens. RFC 8482s ausdrücklicher Hinweis auf die fehlende Kennzeichnung einer Auswahl ist hier entscheidend.

Auch die kleine Antwort behält Sicherheitsbedingungen

Das DO-Bit, dessen Bedeutung RFC 3225 im Dezember 2001 erläuterte, zeigt die Fähigkeit an, DNSSEC-Sicherheitsrecords anzunehmen. Es beweist nicht, dass bereits eine Validierung stattgefunden hat, und ist kein Vollständigkeitsmerkmal für ANY.

RFC 8482 erhält die jeweiligen Signaturanforderungen. Für die synthetische Antwort sind gültige RRSIGs erforderlich, wenn DO gesetzt ist und der Antwortende die Zone als signiert kennt; ohne DO sollen sie in diesem Fall entfallen. Auch die Auswahl vorhandener Sets und die Heuristik haben die beschriebenen Bedingungen für Signaturen.

Die Authentizität zurückgelieferter Sets ist logisch etwas anderes als die Aufzählung aller weggelassenen Typen. Ebenso kann die Antwortpolitik je Transport variieren: konventionelle Antworten über TCP und kleine über UDP sind ein erlaubtes Beispiel, kein Versprechen, dass TCP überall ein vollständiges Inventar beschafft.