TXT record — DNS zone’da ixtiyoriy matn satrlarini saqlash uchun mo‘ljallangan resource record turi. Dastlab inson o‘qiydigan izohlar uchun yaratilgan bo‘lsa-da, bugun domen nazoratini tasdiqlash, email autentifikatsiyasi, service discovery va security policy’larni e’lon qilishda keng ishlatiladi. TXT qiymatining ma’nosini DNS emas, uni o‘qiydigan alohida protokol belgilaydi.
Record ko‘rinishi
Zone faylida record quyidagicha yozilishi mumkin:
example.uz. 300 IN TXT "service-verification=abc123"
Bitta TXT record bir yoki bir nechta character-stringdan iborat bo‘lishi mumkin; har qism DNS wire formatida 255 byte bilan cheklangan. Uzun qiymat zone faylida bir nechta quoted segmentga bo‘linadi, resolver ularni bitta record data sifatida talqin qilishi mumkin. Turli TXT recordlar esa alohida qiymatlar bo‘lib qoladi; ularning tartibiga tayanilmaydi.
Quote va escape zone provider interfeysiga qarab avtomatik boshqarilishi mumkin. Admin panelga literal qo‘shtirnoq kiritish natijada qo‘shtirnoqning o‘zi value’ga tushishiga olib kelishi mumkin. dig TXT chiqishi authoritative wire qiymatni tekshirishga yordam beradi.
SPF
SPF policy odatda domen apexidagi v=spf1 ... TXT recordida e’lon qilinadi. U qaysi serverlar domain nomidan envelope sender bilan email yuborishi mumkinligini bildiradi. Bir domen uchun bir nechta mustaqil SPF record qo‘yish permerror yaratadi; mexanizmlar bitta policy’da birlashtiriladi.
SPF include va DNS lookup mexanizmlariga ega, ammo protokol lookup sonini cheklaydi. Juda ko‘p provider include’i policy’ni ishlamas holga keltirishi mumkin. SPF visible From headerni emas, SMTP envelope identityni tekshiradi; DMARC alignment bu farqni bog‘laydi.
DKIM va DMARC
DKIM public key selector ostida TXT sifatida e’lon qilinadi:
selector1._domainkey.example.uz. IN TXT "v=DKIM1; k=rsa; p=..."
Mail server private key bilan xabarni imzolaydi, receiver DNSdan public keyni olib tekshiradi. Key rotation yangi selector yaratish, yuboruvchini o‘tkazish va eski mail oqimi tugagach eski recordni olib tashlashdan iborat.
DMARC _dmarc.example.uz nomida policy e’lon qiladi. U SPF yoki DKIM natijasining visible From domeniga alignmentini tekshiradi va aggregate report manzilini belgilashi mumkin. p=none monitoring, quarantine va reject enforcement darajalaridir. Report emaili tashqi domen bo‘lsa, qo‘shimcha authorization record talab qilinishi mumkin.
Domen tasdiqlash
Certificate Authority DNS-01 challenge uchun _acme-challenge nomiga vaqtinchalik TXT qiymat qo‘yishni talab qiladi. SaaS provider ham domen egasi ekanini tekshirish uchun tasodifiy token beradi. Token odatda secret credential emas, ammo muddati va maqsadi bor. Eski verification recordlarni keraksiz saqlash zone’ni chalkashtiradi va qaysi integratsiya faol ekanini yashiradi.
DNS propagation “butun internetga bir vaqtda tarqalish” emas. Authoritative server yangilangach, recursive resolverlar eski recordni TTL tugaguncha cache’da saqlashi mumkin. Negative caching oldin mavjud bo‘lmagan nomning yangi recordini ham vaqtincha yashiradi.
Hajm va xavfsizlik
Juda katta TXT response UDP fragmentation yoki amplificationga hissa qo‘shishi mumkin. DNS server response size va rate limitni boshqaradi. TXT ichiga parol, API secret yoki private key qo‘yilmaydi: public DNSni istalgan odam o‘qiy oladi. Hatto “tasdiqlash tokeni” ham provider protokoli bo‘yicha faqat ownership challenge sifatida baholanadi.
DNSSEC TXT record yaxlitligi va authenticated originini tekshirishi mumkin, lekin qiymatni shifrlamaydi. Noto‘g‘ri policy sintaksisi DNSSEC bilan ham to‘g‘ri bo‘lib qolmaydi; SPF, DKIM va DMARC parserlari alohida validation qiladi.