Check-Host.cc

Początkowo zaprojektowany w latach 80. jako prosta piaskownica (sandbox) dla administratorów systemów do pozostawiania czytelnych dla człowieka notatek w pliku strefy, rekord TXT (Text) ewoluował i stał się jednym z najbardziej krytycznych pod względem strukturalnym komponentów nowoczesnego bezpieczeństwa sieci. Ponieważ protokół DNS nie stosuje praktycznie żadnej walidacji składni do Payloadów TXT, programiści i platformy bezpieczeństwa wykorzystują te rekordy do przechowywania dowolnych ciągów danych czytelnych dla maszyn. Obecnie rekordy TXT są wykorzystywane głównie do rygorystycznych struktur uwierzytelniania poczty e-mail, dystrybucji kluczy kryptograficznych i zautomatyzowanej weryfikacji własności domeny.

Triada uwierzytelniania e-mail: SPF, DKIM i DMARC

Jeśli wiadomości wychodzące z Twojej aplikacji internetowej lub serwera korporacyjnego trafiają prosto do folderów ze spamem, prawie zawsze winne są źle skonfigurowane rekordy TXT. Nowoczesne serwery odbierające MTA (takie jak Microsoft 365 lub Gmail) żądają kryptograficznego dowodu tożsamości za pomocą trzech określonych polityk TXT:

• SPF (Sender Policy Framework): Ściśle sformatowany ciąg TXT (np. v=spf1 include:_spf.google.com ~all) działający jako publiczna biała lista (whitelist). Autoryzuje określone bloki adresów IP i usługi wysyłkowe stron trzecich (takie jak Mailgun lub SendGrid) do wysyłania poczty w imieniu domeny.
• DKIM (DomainKeys Identified Mail): Rekord TXT zawierający potężny, zakodowany w Base64 publiczny klucz kryptograficzny. Twój serwer poczty wychodzącej hashuje nagłówki wiadomości i podpisuje je kluczem prywatnym. Serwer odbierający pobiera klucz publiczny z tego rekordu TXT w celu matematycznej weryfikacji podpisu, zapewniając, że Payload nie został zmieniony podczas przesyłania.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Warstwa egzekwująca. Ten rekord TXT instruuje serwery odbierające, jak obsługiwać wiadomości, które nie przejdą kontroli SPF lub DKIM, dyktując, czy zastosować politykę p=none (monitorowanie), p=quarantine (kwarantanna/spam), czy p=reject (całkowite odrzucenie).

Automatyczna własność domeny i Zero-Trust

Poza pocztą e-mail, rekordy TXT są uniwersalnym standardem udowadniającym kontrolę administracyjną nad nazwą domeny. Integrując domenę z dostawcą chmury (takim jak Google Search Console, GitHub Pages lub AWS SES), platforma wygeneruje losowy hash kryptograficzny. Wymagając od administratora opublikowania tego hashu jako rekordu TXT, dostawca potwierdza za pomocą automatycznego zapytania DNS, że użytkownik posiada dostęp na poziomie root do infrastruktury routingu domeny. Podobnie protokół ACME wykorzystywany przez Let's Encrypt w dużej mierze opiera się na wyzwaniu DNS-01, w którym wdrażany jest tymczasowy rekord TXT w celu autoryzacji wydania certyfikatów SSL/TLS typu wildcard.

Limity bajtów i konkatenacja ciągów znaków

Ograniczeniem technicznym często napotykanym przez programistów jest limit ciągu znaków wynoszący 255 dla każdego fragmentu TXT w specyfikacji DNS. Podczas publikowania ogromnych Payloadów, takich jak 2048-bitowe klucze RSA dla DKIM, Payload przekracza ten limit bajtów. Aby rozwiązać ten problem, standardowe oprogramowanie DNS (takie jak BIND) automatycznie dzieli długi rekord na wiele ujętych w cudzysłowy ciągów (np. "string1" "string2"). Klient resolvera jest odpowiedzialny za płynne połączenie (konkatenację) tych fragmentów z powrotem podczas procesu odczytu.