Zusammenfassung

  • RFC 10029 lässt eine DNS-Hauptfrage bestehen und fordert zusätzliche QTYPEs über EDNS an. Die Antwortoption nennt nur jene weiteren Typen, die unter demselben RCODE und den passenden Flags der Hauptantwort vollständig verarbeitet wurden.
  • Ein gemeinsames Paket ist keine atomare Mehrtypenaufnahme. Fehlende Typen erfordern eigenständige Abfragen; zurückgegebene RRsets behalten unterschiedliche Zonen, Signierer, TTLs, Cachezeitpunkte, Validierungen und Nutzungsentscheidungen.

Die Grenze zeigt sich dort, wo DNS ohnehin mehrere Autoritätsebenen hat. Eine Abfrage wählt DS als Haupttyp und fordert zusätzlich NS an. Die DS-Antwort von der Elternseite ist autoritativ. Die dort sichtbaren NS-Daten tragen nicht zwingend dieselbe AA-Aussage. Beides unter einem gemeinsamen AA-Bit auszuliefern würde eine der beiden Aussagen verfälschen.

RFC 10029 löst das nicht durch Mittelwertbildung. NS bleibt aus MQTYPE-Response heraus. DS ist vollständig beantwortet; NS muss bei Bedarf separat geklärt werden.

RFC 10029 wurde im Juli 2026 auf dem Standards Track veröffentlicht. Das Dokument greift einen praktischen Bedarf auf: Ein Client möchte etwa A, AAAA und HTTPS für denselben Namen erhalten, ohne von Anfang an drei getrennte Reisen zu erzwingen. Mehrere normale Fragen in einer QUERY sind jedoch keine tragfähige Lösung. RFC 9619 schreibt vor, dass QDCOUNT bei QUERY nicht größer als eins sein darf.

Darum bleibt genau ein Tupel aus QNAME, QCLASS und Haupt-QTYPE im Question-Abschnitt. Weitere Daten-RRTYPEs stehen in einer EDNS-Option. Das Protokoll bündelt Ergebnisse, ohne ihre getrennten Prüfungen abzuschaffen.

Wunschliste und Liefernachweis

MQTYPE-Query trägt den Code 20, MQTYPE-Response den Code 21. Das aktuelle IANA-Register für DNS-Parameter führt beide Optionen als optional mit Verweis auf RFC 10029.

Die unterschiedlichen Codes verhindern, dass ein Middlebox-Echo der Anfrage wie eine vom Server gebildete Vollständigkeitsliste aussieht. Die Hauptfrage und die QTYPEs in der Antwortoption bilden gemeinsam den Nachweis, welche Kombinationen vollständig im Paket enthalten sind.

Auch eine leere Antwortliste ist eine klare Aussage: Der Server hat die Erweiterung verstanden, aber keinen zusätzlichen Typ abgeschlossen. Fehlt die Antwortoption ganz, erscheint fälschlich die Anfrageoption, gibt es Duplikate oder FORMERR, muss der Client die Erweiterung als nicht unterstützt oder ungültig behandeln. Für weiterhin benötigte Typen folgen normale Einzelabfragen.

ANY liefert diese Semantik nicht. RFC 8482 erlaubt minimale ANY-Antworten, bis hin zu einem vom Server gewählten RRset. RFC 10029 verspricht nicht alles, sondern weist das Vollständige aus.

Die Hauptfrage setzt RCODE und Flags

Der Server baut zuerst die Antwort für den Haupttyp. Dabei werden RCODE, AA, AD, TC und weitere gemeinsame Eigenschaften festgelegt. Ist schon diese Antwort abgeschnitten, werden zusätzliche Kombinationen nicht mehr für das Bündel verarbeitet.

Jeder weitere Typ wird anschließend wie ein mögliches Einzelergebnis geprüft. Weicht sein RCODE oder ein relevantes Flag ab, kann er nicht aufgenommen werden. Ein SERVFAIL darf nicht unter dem NOERROR der Hauptantwort verschwinden. Nicht autoritative NS-Daten dürfen nicht die AA-Aussage einer autoritativen DS-Antwort erben.

RFC 2181 bleibt für Rang und Autoritätskontext der DNS-Daten maßgeblich. Gleicher Rang bedeutet dennoch weder denselben Herausgeber noch denselben Veröffentlichungsakt oder dieselbe Beweiskette.

Vollständigkeit hat eine Größenbedingung

Die RR eines zusätzlichen Typs werden in jene Abschnitte eingeordnet, in denen sie bei einer Einzelabfrage erschienen wären. Doppelte RR im selben Abschnitt werden entfernt. Ein QTYPE kommt aber nur in die Antwortliste, wenn sämtliches erforderliches Material dieser Kombination hineinpasst.

Reicht die Größen- oder Arbeitsgrenze nicht, bleibt der Typ aus der Liste. Die zusätzlichen Wünsche dürfen nicht selbst eine abgeschnittene Antwort erzwingen. Deshalb sagt TC=0 nur, dass das endgültige Paket nicht abgeschnitten ist. Es sagt nicht, dass alle vom Client gewünschten Typen erledigt sind.

RFC 6891 begrenzt die Aussage weiter. Ein OPT-Record wird nicht gecacht, und die angekündigte UDP-Nutzlastgröße gilt für die Transaktion. Pfad-MTU, Fragmentverlust oder Firewallregeln können kleiner sein. Konforme Middleboxes sollen Optionen nicht löschen; ob ein realer Pfad das einhält, muss dennoch beobachtet werden.

Auslassung ist keine negative Antwort

Der rekursive Cache kann den Typ nicht enthalten. Ein individuelles Ergebnis kann andere Flags oder einen anderen RCODE haben. Der Server kann ein Arbeitslimit erreichen oder das Paket kann zu klein sein. RFC 10029 kodiert in der Auslassung keine eindeutige Ursache.

Ein fehlendes HTTPS in der Antwortliste beweist daher nicht die Nichtexistenz eines HTTPS-RRsets. Es ist weder automatisch die negative Antwort aus RFC 2308 noch ein authentifizierter Nichtexistenznachweis nach RFC 4035. Es belegt auch keine Sperre, Störung oder Produktentscheidung.

Benötigt die Anwendung den Typ, muss eine Einzelabfrage folgen. Dieser Fallback ist keine lästige Ausnahme, sondern die Korrektheitsregel, die eine optionale Transportoptimierung daran hindert, die fachliche Anforderung zu verkleinern.

Gemeinsame Zustellung synchronisiert keine Herkunft

RRsets in einem Paket können aus verschiedenen DNS-Zonen stammen. Nichtexistenznachweise können verschiedene Signierer haben. TTLs und Zeitpunkte der Cacheaufnahme bleiben verschieden. A kann älterer Cacheinhalt sein, AAAA frisch geholt und HTTPS von einem anderen Autoritätspfad stammen.

Die Terminologie aus RFC 9499 sollte deshalb in der Betriebsbeobachtung erhalten bleiben. RRset, autoritativer Server, rekursiver Resolver und Cache sind nicht bloß Unterfelder eines einheitlichen „DNS-Erfolgs“.

Selbst ein vollständig geliefertes HTTPS-RRset beendet die Entscheidung nicht. RFC 9460 überlässt dem Client die Prüfung von Prioritäten, Pflichtparametern, Adressen und Verwendbarkeit. Zustellung beweist keine Auswahl und keine erfolgreiche Verbindung.

Ein Vollständigkeitsbuch pro Typ

Für jeden Versuch gehören QNAME, QCLASS, Haupt-QTYPE, geordnete Zusatztypen, Resolverpfad, EDNS-Größe, Vorhandensein und Inhalt der Antwortoption sowie RCODE, AA, AD und TC in einen gemeinsamen Vorgang. Die Differenz zwischen angefordertem und abgeschlossenem Set muss explizit bleiben.

Für jeden gelieferten Typ werden RRsets, Negativnachweise, Ursprungszone, Autoritätsstatus, Signierer, DNSSEC-Ergebnis, TTL, Cacheherkunft und Beobachtungszeit festgehalten. Einzel-Fallbacks, Auswahl der Anwendung und Verbindungsresultat erhalten dieselbe Entscheidungs-ID.

Damit bleiben vier Zustände getrennt: Paket empfangen, QTYPE vollständig, RRset validiert, Anwendungsbedarf erfüllt.

Heng Lus Running-Code-Primat verbietet, Veröffentlichung und Registrierung als Nachweis für Pfadunterstützung auszugeben. Seine minimale Anfangsspezifikation, lokale Zukunftsentscheidung und freiwillige Übernahme passen zu einem engen gemeinsamen Format, lokalen Grenzwerten, sichtbarer Kompatibilität und dem gewöhnlichen DNS-Pfad als Ausstieg. Der Grundsatz Realität statt Fürsprache trennt Möglichkeit und Betrieb: Das Register belegt die Option; Pakete, Listen, Validierung und Anwendungsergebnis belegen die Wirklichkeit.

Ein gemeinsamer Umschlag schafft keine gemeinsame Beweishoheit.