Check-Host.cc

Prvobitno osmišljen 1980-ih kao jednostavan prostor za sistemadministratore da ostave čitljive beleške unutar zone fajla, TXT (Text) zapis je evoluirao u jedan od strukturno najkritičnijih delova savremene mrežne bezbednosti. Pošto DNS protokol praktično uopšte ne validira sintaksu TXT sadržaja, programeri i bezbednosne platforme koriste ove zapise za čuvanje proizvoljnih stringova podataka čitljivih mašinama. Danas se TXT zapisi prvenstveno koriste za stroge okvire za autentifikaciju pošte, distribuciju kriptografskih ključeva i automatsku verifikaciju vlasništva nad domenom.

Trojac za autentifikaciju pošte: SPF, DKIM i DMARC

Ako odlazne poruke sa vaše veb aplikacije ili korporativnog servera završavaju direktno u folderu neželjene pošte, gotovo uvek su krivci loše podešeni TXT zapisi. Savremeni prijemni MTA-ovi (poput Microsoft 365 ili Gmail-a) zahtevaju kriptografski dokaz identiteta putem tri specifične TXT politike:

• SPF (Sender Policy Framework): Strogo formatiran TXT string (npr. v=spf1 include:_spf.google.com ~all) koji deluje kao javna bela lista. On ovlašćuje određene IP blokove i servise trećih strana za slanje (poput Mailgun-a ili SendGrid-a) da šalju poštu u ime domena.
• DKIM (DomainKeys Identified Mail): TXT zapis koji sadrži ogroman javni kriptografski ključ kodiran u Base64. Vaš odlazni mejl server hešira zaglavlja poruke i potpisuje ih privatnim ključem. Prijemni server dobavlja javni ključ iz ovog TXT zapisa da bi matematički verifikovao potpis, čime se osigurava da sadržaj nije izmenjen tokom prenosa.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Sloj sprovođenja. Ovaj TXT zapis govori prijemnim serverima kako da postupaju sa porukama koje ne prođu SPF ili DKIM proveru, određujući da li da primene politiku p=none (praćenje), p=quarantine (slanje u neželjenu poštu) ili p=reject (potpuno odbacivanje).

Automatsko dokazivanje vlasništva i Zero-Trust

Osim za poštu, TXT zapisi su univerzalni standard za dokazivanje administrativne kontrole nad domenskim imenom. Prilikom integracije domena sa cloud provajderom (poput Google Search Console, GitHub Pages ili AWS SES), platforma generiše nasumičan kriptografski heš. Zahtevajući od administratora da objavi ovaj heš kao TXT zapis, provajder putem automatske DNS provere potvrđuje da korisnik ima root pristup infrastrukturi za rutiranje domena. Slično tome, ACME protokol koji koristi Let's Encrypt se u velikoj meri oslanja na DNS-01 izazov, gde se privremeni TXT zapis postavlja da bi se ovlastilo izdavanje wildcard SSL/TLS sertifikata.

Ograničenja bajtova i spajanje stringova

Tehničko ograničenje na koje programeri često nailaze jeste ograničenje od 255 karaktera po TXT delu u DNS specifikaciji. Prilikom objavljivanja velikih sadržaja, poput 2048-bitnih RSA ključeva za DKIM, sadržaj premašuje ovo ograničenje bajtova. Da bi se to rešilo, standardni DNS softver (poput BIND-a) automatski deli dugačak zapis na više stringova okruženih navodnicima (npr. "string1" "string2"). Klijentski rezolver je zadužen da tokom čitanja ove delove neprimetno spoji nazad u celinu.