Check-Host.cc

Ursprünglich in den 1980er Jahren als einfache Sandbox für Systemadministratoren konzipiert, um menschenlesbare Notizen in einer Zonendatei zu hinterlassen, hat sich der TXT-Record (Text) zu einer der strukturell wichtigsten Komponenten der modernen Netzwerksicherheit entwickelt. Da das DNS-Protokoll praktisch keine Syntaxvalidierung auf TXT-Payloads anwendet, nutzen Entwickler und Sicherheitsplattformen diese Records, um beliebige maschinenlesbare Datenstrings zu speichern. Heute werden TXT-Records hauptsächlich für strenge E-Mail-Authentifizierungs-Frameworks, die Verteilung kryptografischer Schlüssel und die automatisierte Überprüfung der Domain-Inhaberschaft eingesetzt.

Die Triade der E-Mail-Authentifizierung: SPF, DKIM und DMARC

Wenn ausgehende E-Mails von Ihrer Webanwendung oder Ihrem Unternehmensserver direkt im Spam-Ordner landen, sind falsch konfigurierte TXT-Records fast immer die Ursache. Moderne empfangende MTAs (wie Microsoft 365 oder Gmail) verlangen einen kryptografischen Identitätsnachweis über drei spezifische TXT-Richtlinien:

• SPF (Sender Policy Framework): Ein streng formatierter TXT-String (z. B. v=spf1 include:_spf.google.com ~all), der als öffentliche Whitelist fungiert. Er autorisiert bestimmte IP-Blöcke und Versanddienste von Drittanbietern (wie Mailgun oder SendGrid), E-Mails im Namen der Domain zu versenden.
• DKIM (DomainKeys Identified Mail): Ein TXT-Record, der einen massiven, Base64-kodierten öffentlichen kryptografischen Schlüssel enthält. Ihr ausgehender Mailserver hasht die E-Mail-Header und signiert sie mit einem privaten Schlüssel. Der empfangende Server ruft den öffentlichen Schlüssel aus diesem TXT-Record ab, um die Signatur mathematisch zu verifizieren und sicherzustellen, dass der Payload während der Übertragung nicht manipuliert wurde.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Der Enforcement-Layer. Dieser TXT-Record weist empfangende Server an, wie sie Nachrichten behandeln sollen, die bei SPF- oder DKIM-Prüfungen durchfallen, und diktiert, ob eine p=none (Beobachten), p=quarantine (in den Spam verschieben) oder p=reject (komplett verwerfen) Richtlinie angewendet wird.

Automatisierte Domain-Inhaberschaft und Zero-Trust

Über E-Mails hinaus sind TXT-Records der universelle Standard zum Nachweis der administrativen Kontrolle über einen Domainnamen. Bei der Integration einer Domain mit einem Cloud-Anbieter (wie Google Search Console, GitHub Pages oder AWS SES) generiert die Plattform einen zufälligen kryptografischen Hash. Indem der Anbieter verlangt, dass der Administrator diesen Hash als TXT-Record veröffentlicht, bestätigt er über einen automatisierten DNS-Lookup, dass der Benutzer Root-Level-Zugriff auf die Routing-Infrastruktur der Domain besitzt. Auch das von Let's Encrypt verwendete ACME-Protokoll verlässt sich stark auf die DNS-01-Challenge, bei der ein temporärer TXT-Record deployt wird, um die Ausstellung von Wildcard-SSL/TLS-Zertifikaten zu autorisieren.

Byte-Limits und String-Verkettung (Concatenation)

Eine technische Einschränkung, auf die Entwickler häufig stoßen, ist das Limit von 255 Zeichen pro TXT-Chunk innerhalb der DNS-Spezifikation. Bei der Veröffentlichung massiver Payloads, wie etwa 2048-Bit-RSA-Schlüssel für DKIM, überschreitet der Payload dieses Byte-Limit. Um dies zu lösen, bricht Standard-DNS-Software (wie BIND) den langen Record automatisch in mehrere in Anführungszeichen gesetzte Strings auf (z. B. "string1" "string2"). Der Client-Resolver ist dafür verantwortlich, diese Chunks während des Lesevorgangs nahtlos wieder zusammenzusetzen.