Zusammenfassung

  • TC meldet, dass die Nachricht die zulässige Länge ihres Übertragungskanals überschritt. RFC 2181 präzisierte: Betroffen ist ein erforderliches RRset, das nicht vollständig hineinpasst; der Client soll die abgeschnittene Antwort ignorieren.
  • TCP trug die größere Wiederholung und wurde später regulärer DNS-Transport. RFC 7766 verlangte UDP und TCP für allgemeine Implementierungen und erlaubte TCP zuerst; RFC 9210 machte Kapazität, Durchlass und Beobachtung zu normalen Betriebsaufgaben.

Eine Paketgrenze durfte den Namensraum nicht kürzen

RFC 1035 beschrieb 1987 DNS über UDP und TCP auf Port 53. UDP war für gewöhnliche Fragen günstig: kein Verbindungsaufbau, wenig Zustand, einfache Wiederholung bei einem anderen Server. Die DNS-Nachricht war jedoch auf 512 Byte begrenzt, ohne IP- und UDP-Header.

Längere Antworten wurden abgeschnitten und mit TC=1 markiert. Das Bit sagte nichts über die Existenz des Namens oder die Gültigkeit der sichtbaren Records. Es sagte nur, dass der Kanal die Nachricht nicht vollständig getragen hatte.

Ohne diese Trennung hätte die Transportkapazität den Inhalt bestimmen können. Wenn fünf Adressen zum Namen gehören und nur drei in das Datagramm passen, sind drei nicht plötzlich das autoritative Set.

Das RRset wurde zur unteilbaren Beweiseinheit

RFC 2181 definierte 1997 Records mit gleichem Eigentümernamen, gleicher Klasse und gleichem Typ als RRset. Wird dieses Material verlangt, zählt das ganze Set.

TC soll gesetzt werden, wenn ein erforderliches RRset nicht vollständig enthalten sein kann. Fehlt nur Platz für zusätzliche Hilfsdaten, darf der Server das gesamte zusätzliche RRset weglassen und TC frei lassen. Der Empfänger kann es separat erfragen.

Steht TC auf eins, soll der Client die Antwort ignorieren und mit einem Verfahren erneut fragen, das größere Antworten zulässt, etwa TCP. Physisch vorhandene Teilrecords werden dadurch weder cachefähig noch mit älteren Fragmenten kombinierbar.

DNS opferte eine Übertragung, um keine falsche Vollständigkeit zu erzeugen. Semantische Einheit wog mehr als die Wiederverwendung plausibler Bytes.

Der Resolver behielt die nächste Entscheidung

Häufig folgt auf UDP mit TC eine erneute Frage über TCP. Dort steht vor jeder DNS-Nachricht ein Zwei-Byte-Längenfeld, und die Antwort ist nicht auf ein Datagramm beschränkt.

TC öffnet aber keine Verbindung. Der Resolver wählt Wiederholung, anderen Server oder Wiederverwendung; der Server regelt Zulassung, Gleichzeitigkeit und Leerlauf. Wer Verbindungszustand bezahlt, darf dessen Grenzen setzen.

Diese Ressourcenhoheit ist keine Datenhoheit. Der Server erklärt eng begrenzt, dass diese Lieferung nicht vollständig war. Der Empfänger übernimmt die Aufgabe, eine vollständige Fassung zu erlangen.

EDNS vergrößerte das Angebot, nicht die Gewissheit

Mit RFC 6891 konnte der Anfragende die akzeptierte UDP-Nutzlastgröße nennen. EDNS(0) ließ viele Antworten jenseits von 512 Byte auf UDP bleiben.

Die Angabe eines Endpunkts vermisst aber nicht jedes Glied, jeden Tunnel oder jede Firewall. IP-Fragmente können verloren oder gefiltert werden. DNSSEC fügte Signaturen und Nachweise hinzu; weitere Datentypen ließen Antworten wachsen.

EDNS bietet ein Budget an. TC berichtet, dass die erforderliche Antwort nicht in das nutzbare Budget passte. Eine Zahl ist kein Zustellbeleg für den Pfad. Verschwindet ein großes Datagramm, kommt womöglich nicht einmal TC an; UDP-Timeout und autoritative Negativantwort müssen deshalb getrennt bleiben.

TCP verlor den Status der Ausnahme

Die Kurzform „TCP für Zonentransfers und Fallback“ ließ manche Netze TCP/53 als entbehrlich behandeln. Damit blieb das Warnsignal bestehen, während sein erwarteter Ausweg blockiert wurde.

RFC 7766 änderte 2016 die Stellung. Allgemeine autoritative und rekursive Server, Forwarder und Stub-Resolver müssen UDP und TCP unterstützen. Normale Fragen müssen auch nicht mehr zwingend mit UDP beginnen; lokale Gründe dürfen TCP zuerst wählen, und eine offene Verbindung soll wiederverwendet werden.

TC führt also oft zu TCP, bestimmt jedoch nicht jede moderne Transportwahl. TCP ist eine eigenständige Alternative, spätere DNS-Transporte kommen hinzu. Dauerhaft ist die Pflicht zur vollständigen Antwort, nicht eine starre Reihenfolge.

Ein Stream brauchte eigene Sparsamkeit

Eine neue Verbindung pro Frage wiederholt den Handshake. RFC 7766 empfiehlt Wiederverwendung und Pipelining: Mehrere Fragen gehen ohne Warten hinaus, der Server verarbeitet parallel und darf anders geordnet antworten.

Der Client muss Antworten den offenen Fragen zuordnen. Server und Messwerkzeuge müssen den Stream zusammensetzen; ein TCP-Segment ist nicht zwingend eine vollständige DNS-Nachricht.

Verbindungsgrenzen pro Client oder Subnetz und Leerlauf-Timeouts bleiben legitim. Schutz von Speicher, Deskriptoren und Arbeitern gehört zum Betrieb. Er darf nur keine abgeschnittene Antwort zum Erfolg erklären.

Betrieb musste beide Transporte sehen

RFC 9210 verlangte 2022, dass Resolver und Server UDP und TCP bedienen und Netzbetreiber beide grundsätzlich zulassen. TCP-Filterung ist schädlich, weil sie den Wiederherstellungsweg größerer Antworten entfernt.

Ressourcen dürfen begrenzt werden; eine Frage darf aber nicht allein deshalb abgewiesen werden, weil sie über einen anderen Transport hätte gelingen können. Grenzen folgen Kosten und Missbrauch, nicht einer künstlichen Rangordnung der DNS-Wahrheit.

Auch Überwachung muss Streams rekonstruieren, Wiederverwendung, Pipeline und ungeordnete Antworten verstehen. Wer nur UDP zählt, sieht weder normale Rettung noch Angriffe auf dem zweiten Weg.

Fragmentvermeidung hielt das alte Signal relevant

RFC 9715 empfahl 2025, IP-Fragmentierung bei DNS/UDP zu vermeiden und 1400 Byte als empfohlenes Maximum zu verwenden, sofern keine kleinere Grenze gilt. Fragmente sind störanfällig und können Cache-Poisoning erleichtern.

Die Wirkung von TC bleibt unverändert. Passt eine Antwort nicht sicher, kann sie als abgeschnitten gekennzeichnet werden; gehen Fragmente verloren, soll der Empfänger schließlich einen anderen Transport versuchen. TCP kann ebenfalls blockiert oder überlastet sein. Die Architektur verspricht nicht Unfehlbarkeit, sondern Ehrlichkeit über fehlende Daten.

Das Bit behauptete nur, was es wusste

TC beweist weder DNSSEC-Fehler noch Zensur, Angriff, Nichtexistenz oder Eigentum. Nicht jede ausgelassene Zusatzinformation verlangt TC, und TCP ist nicht für alle Zukunft der einzige größere Kanal.

Die enge Aussage ist belastbar: Diese Übertragung lieferte nicht alles Erforderliche. DNS erlaubte einen billigen ersten Umschlag, aber nicht, dass dessen Grenze den Inhalt verfälschte.

Quellen und Grenzen

Grundlage sind RFC 1035, RFC 2181, RFC 6891, RFC 7766, RFC 9210 und RFC 9715. Sie messen keine heutigen weltweiten TC-Raten, Filterquoten, Produktvorgaben oder Resolver-Erfolge.