DNS Resolution qanday ishlaydi: bosqichma-bosqich qo‘llanma

DNS Resolution qanday ishlaydi: bosqichma-bosqich

Brauzerga www.example.com manzilini kiritganingizda, brauzer bu nomning o‘ziga to‘g‘ridan-to‘g‘ri ulana olmaydi. Avval unga manzil serveriga ulanish uchun tarmoq manzili — odatda IPv4 yoki IPv6 manzili — kerak bo‘ladi. DNS resolution — domen nomi bilan bog‘liq DNS ma’lumotlarini topish jarayonidir.

Muhim jihati shundaki, bu har doim bitta global ma’lumotlar bazasiga yuboriladigan bitta so‘rov degani emas. DNS taqsimlangan tizim. Agar kerakli javob cache’da bo‘lmasa, recursive resolver DNS ierarxiyasining bir nechta bosqichlari orqali referral’larni kuzatib, so‘ralgan nom uchun authoritative bo‘lgan servergacha yetib borishi mumkin. (rfc-editor.org)

Qisqa javob

DNS resolution domen nomi bo‘yicha yuborilgan so‘rovni ilova uchun kerakli DNS record’larga aylantiradi. Qurilmangiz odatda so‘rovni recursive resolver’ga yuboradi. Agar resolver’da yaroqli cached javob bo‘lsa, uni darhol qaytarishi mumkin. Aks holda, u DNS ierarxiyasi bo‘ylab so‘rov yuboradi — odatda root haqidagi ma’lumotdan boshlab, tegishli top-level domain orqali authoritative name server’gacha boradi — javobni oladi va keyingi foydalanish uchun cache’ga saqlaydi. (rfc-editor.org)

Asosiy ma’lumotlar

Hozirgi DNS terminologiyasi to‘liq resolution jarayonini bajarish uchun boshqa resolver’ga tayanadigan stub resolver bilan client uchun recursion’ni bajaradigan recursive resolver o‘rtasini ajratadi. (rfc-editor.org)

DNS Resolution nima?

Domain Name System — taqsimlangan nomlash tizimi. Turli name server’lar domen nomlari makonining turli qismlari uchun authoritative ma’lumotlarni saqlaydi. Resolver bu taqsimlangan tuzilmaning katta qismini ilovalardan yashiradi: ilova savol yuboradi, resolver esa tegishli DNS record’larni topish uchun kerakli ishlarni bajaradi. (rfc-editor.org)

Masalan, brauzerga quyidagi nom uchun manzillar kerak bo‘lishi mumkin:

www.example.com

U IPv4 uchun A record, IPv6 uchun AAAA record yoki ikkalasini ham so‘rashi mumkin. AAAA record bitta IPv6 manzilini saqlaydi. (rfc-editor.org)

DNS CNAME alias’lari, email routing record’lari, name server record’lari va boshqa ko‘plab turdagi ma’lumotlarni ham qaytarishi mumkin.

Resolution qanday ishlaydi

Faraz qilaylik, foydalanuvchi quyidagi manzilni ochmoqchi:

www.example.com

va cache’da foydali javob hali yo‘q.

1. Ilova lookup so‘rovini yuboradi

Brauzer yoki boshqa ilova tizim resolver’idan www.example.com haqidagi DNS ma’lumotini so‘raydi.

Ko‘p tizimlarda bu lokal komponent stub resolver sifatida ishlaydi. U DNS ierarxiyasini boshidan oxirigacha mustaqil ravishda aylanib chiqmaydi. Buning o‘rniga, so‘rovni operatsion tizim, internet provayder, korporativ tarmoq, VPN yoki DNS xizmati tomonidan sozlangan recursive resolver’ga yuboradi. (rfc-editor.org)

2. Recursive resolver cache’ni tekshiradi

Boshqa DNS server’larga murojaat qilishdan oldin recursive resolver o‘zida yaroqli cached javob bor-yo‘qligini tekshirishi mumkin.

Agar javob mavjud bo‘lsa, resolution shu yerning o‘zida tugashi mumkin.

Shuning uchun real DNS lookup har safar ham root, TLD va authoritative server’larga murojaat qilmaydi. Oldin olingan manzillar, delegation ma’lumotlari yoki boshqa record’lar hali ham cache’da bo‘lishi mumkin.

3. Resolver root’dan foydalanadi

Agar resolver lookup’ni o‘zi bajarishi kerak bo‘lsa va cache’da yetarli ma’lumot bo‘lmasa, u DNS root’dan boshlashi mumkin.

Root server odatda www.example.com uchun yakuniy IP manzilni qaytarmaydi. Buning o‘rniga, resolver’ni tegishli top-level domain uchun mas’ul server’lar tomon yo‘naltiradi — bu holatda .com tomon.

Bunday referral modeli DNS resolution’ning asosiy qismlaridan biridir. RFC 1035 resolver so‘ralgan ma’lumotning o‘zini yoki boshqa name server’ga murojaat qilish uchun referral olishi mumkinligini tasvirlaydi. (rfc-editor.org)

4. Resolver TLD’ga so‘rov yuboradi

Keyin resolver example.com haqida tegishli .com name server’iga so‘rov yuboradi.

TLD server ham odatda saytning yakuniy address record’ini saqlamaydi. U domen uchun authoritative name server’larni ko‘rsatuvchi delegation ma’lumotini beradi.

Shundan keyin resolver domenning o‘ziga tegishli so‘rovni qayerga yuborish kerakligini biladi.

5. Authoritative server javob qaytaradi

Resolver tegishli zona uchun authoritative server’ga so‘rov yuboradi.

Agar server’da kerakli ma’lumot bo‘lsa, u record’ni qaytarishi mumkin. Masalan:

www.example.com.  3600  IN  A  192.0.2.10

Haqiqiy qiymatlar domen konfiguratsiyasiga bog‘liq.

Javobda CNAME ham bo‘lishi mumkin. DNS’da CNAME record bir nom boshqa canonical nomning alias’i ekanini ko‘rsatish uchun ishlatiladi. Shunda resolver o‘sha target nomni ham resolution qilishda davom etishi kerak bo‘lishi mumkin. (rfc-editor.org)

6. Javob cache’ga saqlanadi

DNS resource record’lar TTL — time to live qiymatini o‘z ichiga oladi. U cached ma’lumot manbaga qayta murojaat qilishdan oldin qancha vaqt qayta ishlatilishi mumkinligini belgilaydi. (rfc-editor.org)

Agar resolver javobni cache’ga saqlasa, keyingi foydalanuvchilar xuddi shu record’ni so‘raganda butun resolution yo‘lini qayta bosib o‘tmasdan javob olishi mumkin.

Natija client’ga qaytariladi va ilova keyingi tarmoq bosqichiga, masalan TCP yoki QUIC connection o‘rnatishga o‘tishi mumkin.

TTL nega muhim?

TTL odamlar odatda DNS propagation deb ataydigan jarayonning katta qismini tushuntiradi.

DNS o‘zgarishlari odatda butun dunyodagi barcha resolver cache’lariga bir vaqtda yuborilmaydi. Agar resolver’da eski record hali saqlanayotgan bo‘lsa va uning TTL’i tugamagan bo‘lsa, resolver eski qiymatni qaytarishda davom etishi mumkin. Shu record cache’da bo‘lmagan boshqa resolver esa yangi qiymatni allaqachon olgan bo‘lishi mumkin.

Shu sabab DNS o‘zgartirilgandan keyin ikki foydalanuvchi vaqtincha turli javob olishi mumkin va bunda resolver’lardan hech biri noto‘g‘ri ishlayotgan bo‘lishi shart emas.

INTERNAL LINK: DNS Propagation qanday ishlaydi

Demak, TTL — bu muvozanat masalasi. Uzoqroq caching takroriy DNS ishlarini va authoritative query yukini kamaytirishi mumkin, qisqaroq TTL esa o‘zgarishlarning cache’larda tezroq ko‘rinishiga yordam beradi.

Salbiy javoblar ham cache’lanadi

DNS caching faqat muvaffaqiyatli javoblar bilan cheklanmaydi.

Authoritative server nom mavjud emasligini, odatda NXDOMAIN javobi orqali bildirishi mumkin. DNS standartlarida negative caching belgilangan: resolver’lar bir xil mavjud bo‘lmagan nom haqida authoritative infratuzilmaga qayta-qayta murojaat qilmaslik uchun bunday javoblarni vaqtincha cache’da saqlashi mumkin. (rfc-editor.org)

Buning amaliy oqibati bor: agar hostname yaqinda mavjud bo‘lmagan bo‘lsa va keyin yaratilsa, ayrim resolver’lar bir muddat cached salbiy javobni qaytarishda davom etishi mumkin.

DNS va performance

DNS resolution ilova hali manzilini bilmaydigan host’ga ulanishidan oldin sodir bo‘ladi. Shu sabab sekin yoki ishonchsiz DNS yo‘li keyingi connection jarayonlarining boshlanishini kechiktirishi mumkin.

Ammo “DNS tezligi”ni o‘lchashda kontekst muhim. Cached lookup bilan uncached lookup o‘rtasida katta farq bo‘lishi mumkin. Bundan tashqari, resolver’da yakuniy record bo‘lmasa ham, delegation ma’lumotlari allaqachon cache’da bo‘lishi mumkin.

Web performance tahlilida quyidagilarni alohida ko‘rib chiqish kerak:

• brauzer yoki operatsion tizim caching’i;
• recursive resolver caching’i;
• authoritative DNS response time;
• tanlangan resolver’gacha bo‘lgan network latency;
• DNS ierarxiyasi bo‘ylab uncached resolution.

Bitta DNS benchmark barcha real foydalanuvchilarning tajribasini avtomatik ravishda ifodalamaydi.

INTERNAL LINK: DNS va website speed

Resolution jarayonini qanday tekshirish mumkin

dig utilitasi DNS javoblarini tekshirish uchun foydali.

Oddiy lookup:

dig example.com A

IPv6 lookup:

dig example.com AAAA

Delegation yo‘lini ko‘rish uchun:

dig +trace example.com A

BIND hujjatlariga ko‘ra, +trace root’dan boshlaydi va iterative query’lar orqali referral’larni kuzatib, nomni resolution qilishda qatnashgan server’larni ko‘rsatadi. (bind9.readthedocs.io)

Bu, masalan, quyidagi muammolarni aniqlashda foydali:

Root works
→ TLD delegation works
→ authoritative server fails

yoki:

Authoritative server returns the correct record
→ recursive resolver still has an older cached answer

Bitta muhim cheklov bor: dig +trace brauzer ishlatadigan aynan o‘sha yo‘lni takrorlashi shart emas. Brauzerlar, operatsion tizimlar, VPN’lar, korporativ tarmoqlar yoki encrypted DNS konfiguratsiyalari boshqa resolver’lardan foydalanishi mumkin.

Keng tarqalgan noto‘g‘ri tushunchalar

“DNS har doim avval root’ga murojaat qiladi.” Yo‘q. Cache’da yakuniy javob yoki ierarxiyaning pastroq qismidan boshlash uchun yetarli delegation ma’lumoti bo‘lishi mumkin.

“Root server har bir saytning IP manzilini saqlaydi.” Yo‘q. DNS taqsimlangan tizim. Root server’lar asosan resolution jarayonini tegishli TLD infratuzilmasiga yo‘naltirishga yordam beradi.

“DNS’ni o‘zgartirsam, hamma darhol yangi qiymatni ko‘radi.” Har doim ham emas. Oldingi cached javoblar tegishli TTL tugaguncha ishlatilishi mumkin.

“DNS odatda faqat IP manzil qaytaradi.” Yo‘q. DNS ko‘plab turdagi resource record’larni qo‘llab-quvvatlaydi. Hatto address resolution jarayonida ham A yoki AAAA javobigacha CNAME record’lar qatnashishi mumkin.

DNS xavfsizligi va maxfiylik

DNSSEC va encrypted DNS turli muammolarni hal qiladi.

DNSSEC DNS ma’lumotlarining manbasini autentifikatsiya qilish va yaxlitligini tekshirish mexanizmlarini beradi. U maxfiylikni ta’minlamaydi; DNSSEC spetsifikatsiyasi authentication va integrity’ni secrecy’dan aniq ajratadi. (rfc-editor.org)

DNS over TLS (DoT) DNS transporti uchun maxfiylikni ta’minlashda TLS’dan foydalanadi, DNS over HTTPS (DoH) esa DNS query va response’larni HTTPS almashinuvi ichida uzatadi. (rfc-editor.org)

Shuning uchun bu texnologiyalarni bir-birining o‘rnini bosuvchi deb qarash kerak emas.

INTERNAL LINK: DNSSEC vs DoH vs DoT

DNS implementation’lar UDP va TCP’ni ham qo‘llab-quvvatlashi kerak. RFC 7766 asosiy talablarni yangilab, general-purpose DNS implementation’lar ikkala transportni ham qo‘llab-quvvatlashi kerakligini belgilagan. (rfc-editor.org)

SeoNest tavsiyasi

DNS muammolarini tekshirayotganda faqat “domen resolve bo‘lyapti” yoki “domen resolve bo‘lmayapti” degan xulosa bilan cheklanib qolmang.

Natijani aynan qaysi qatlam qaytarayotganini aniqlang:

Client
→ configured recursive resolver
→ cached data
→ root/TLD delegation
→ authoritative DNS
→ final A/AAAA/CNAME response

Keyin TTL, delegation, authoritative javoblar va cached response’larni alohida tekshiring.

Bu usul DNS record’larni qayta-qayta o‘zgartirib, shunchaki kutishdan ishonchliroq. Chunki u muammo zonaning o‘zidami, delegation yo‘lidami, resolver cache’idami yoki client muhitidami — shuni ko‘rsatadi.

FAQ

DNS resolution nima qiladi?

U domen nomi bilan bog‘liq DNS ma’lumotlarini oladi. Web traffic uchun bu odatda brauzer host’ga ulanishda ishlatishi mumkin bo‘lgan IPv4 yoki IPv6 manzilini topishni ham o‘z ichiga oladi.

Har bir DNS lookup authoritative server’gacha boradimi?

Yo‘q. Yaroqli cached javob authoritative server’ga yangi so‘rov yubormasdan ham so‘rovni qondirishi mumkin.

Recursive DNS resolver nima?

Bu client uchun recursive service bajaradigan resolver bo‘lib, recursion mavjud bo‘lsa, shunchaki referral qaytarish o‘rniga yakuniy javobni topadi. (rfc-editor.org)

Recursive DNS va authoritative DNS o‘rtasidagi farq nima?

Recursive resolver client’lar uchun javoblarni topadi. Authoritative server esa o‘zi mas’ul bo‘lgan zonalar uchun authoritative DNS ma’lumotlarini beradi.

Nega eski DNS record’lar hali ham ko‘rinishi mumkin?

Resolver’da oldingi javob hali ham cache’da bo‘lishi mumkin. TTL resource record manbaga qayta murojaat qilishdan oldin cache’da qancha vaqt saqlanishi mumkinligini belgilaydi. (rfc-editor.org)

DNSSEC DNS query’larni shifrlaydimi?

Yo‘q. DNSSEC DNS ma’lumotlari manbasini autentifikatsiya qilish va ularning yaxlitligini tekshirish mexanizmlarini beradi, lekin maxfiylikni ta’minlamaydi. DoT va DoH kabi encrypted transport’lar DNS transport maxfiyligini ta’minlaydi. (rfc-editor.org)

Yakuniy xulosa

DNS resolution’ni bitta markaziy server domenni IP manzilga aylantiradigan oddiy jarayon deb emas, balki taqsimlangan lookup jarayoni deb tushunish to‘g‘riroq.

Client odatda recursive resolver’ga murojaat qiladi. Cache darhol javob berishi mumkin. Agar qo‘shimcha ma’lumot kerak bo‘lsa, resolver DNS ierarxiyasi va undagi referral’lar bo‘ylab yurib, authoritative ma’lumotni oladi, so‘ng natijani DNS caching qoidalariga muvofiq cache’ga saqlaydi.

Javob qayerdan kelganini — client cache’idanmi, recursive cache’danmi, delegation’danmi yoki authoritative DNS’danmi — tushunsangiz, DNS performance muammolari va konfiguratsiya xatolarini aniqlash ancha osonlashadi.

Manbalar

1. Paul Mockapetris — RFC 1034: Domain Names — Concepts and Facilities, November 1987. RFC Editor. RFC 1034
2. Paul Mockapetris — RFC 1035: Domain Names — Implementation and Specification, November 1987. RFC Editor. RFC 1035
3. Paul Hoffman, Kazunori Fujiwara — RFC 9499: DNS Terminology, March 2024. IETF / RFC Editor. RFC 9499
4. Mark Andrews — RFC 2308: Negative Caching of DNS Queries, March 1998. RFC Editor. RFC 2308
5. Roy Arends et al. — RFC 4033: DNS Security Introduction and Requirements, March 2005. IETF / RFC Editor. RFC 4033
6. Susan Thomson et al. — RFC 3596: DNS Extensions to Support IP Version 6, October 2003. RFC Editor. RFC 3596
7. John Dickinson et al. — RFC 7766: DNS Transport over TCP — Implementation Requirements, March 2016. IETF / RFC Editor. RFC 7766
8. Z. Hu et al. — RFC 7858: Specification for DNS over Transport Layer Security (TLS), May 2016. IETF / RFC Editor. RFC 7858
9. Paul Hoffman, Patrick McManus — RFC 8484: DNS Queries over HTTPS (DoH), October 2018. IETF / RFC Editor. RFC 8484
10. Internet Systems Consortium — BIND 9 dig documentation, BIND 9.20 documentation. BIND 9 Manual Pages