როგორ მუშაობს DNS-ის რეზოლუცია?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) არის ინტერნეტის სატელეფონო წიგნი: ის თარგმნის ადამიანისთვის წასაკითხ სახელს, როგორიც `example.com`, IP მისამართად, როგორიც `93.184.216.34`. რეზოლუცია იერარქიული lookup-ია, ჩვეულებრივ თქვენ ნაცვლად შესრულებული **recursive resolver-ის** მიერ (თქვენი ISP-ის ან საჯარო, როგორიც 8.8.8.8), რომელიც თქვენ ნაცვლად **authoritative** name server-ების ხეს გადის:

```text
Browser ──▶ Recursive Resolver ──▶ Root (.)          "ask .com's servers"
                     │        ◀──
                     ├────────▶ TLD (.com)            "ask example.com's servers"
                     │        ◀──
                     └────────▶ Authoritative         "example.com = 93.184.216.34"
                                (example.com)   ◀──
Browser  ◀── 93.184.216.34
```

resolver ეკითხება **root** სერვერებს (რომლებმაც TLD სერვერები იციან), შემდეგ `.com`-ის **TLD** სერვერებს (რომლებმაც იციან, ვინ არის authoritative `example.com`-ისთვის), შემდეგ **authoritative** სერვერს (რომელიც რეალურ ჩანაწერს ინახავს). იმისათვის, რომ ეს ყოველ ჯერზე არ განმეორდეს, შედეგები **cache-დება** ყველა დონეზე — ბრაუზერი, OS და resolver — თითოეული ჩანაწერის **TTL**-ს (time-to-live) იცავს. თბილი cache მიკროწამებში ხსნის; ცივი lookup შეიძლება რამდენიმე round trip დაჯდეს.

გავრცელებული **ჩანაწერის ტიპები**: `A` (name → IPv4), `AAAA` (name → IPv6), `CNAME` (სხვა სახელის alias), `MX` (mail სერვერები), `TXT` (ნებისმიერი ტექსტი, გამოიყენება SPF/ვერიფიკაციისთვის) და `NS` (delegates a zone). რეზოლუციის პირდაპირ დათვალიერება შეგიძლიათ:

```bash
dig example.com A       # shows the A record and which server answered
```

## რატომ არის ეს მნიშვნელოვანი

DNS *ყველა* იმ request-ის კრიტიკულ გზაზე ზის, რომელიც სახელით იწყება, ამიტომ ნელი ან არასწორად კონფიგურირებული resolver ყველაფერს latency-ს უმატებს. ინტერვიუერებს ეს კითხვა მოსწონთ, რადგან ის ცხადყოფს, გესმით თუ არა **იერარქია და caching** — ორი იდეა, რომელიც გლობალურ, განაწილებულ სისტემას საშუალებას აძლევს მილიარდობით query-ს სწრაფად უპასუხოს. ეს ასევე რეალური production ინციდენტების ხშირი წყაროა ("ყოველთვის DNS-ია"): ვადაგასული ჩანაწერები, არასწორი TTL-ები ან გავრცელების დაყოვნებები ცვლილების შემდეგ, ამიტომ იმის ცოდნა, თუ როგორ მუშაობს caching და TTL, პირდაპირ პრაქტიკულია.

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები