DNS resolution எவ்வாறு செயல்படுகிறது?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) என்பது internet-இன் தொலைபேசி புத்தகம்: அது `example.com` போன்ற மனிதர் படிக்கக்கூடிய பெயரை `93.184.216.34` போன்ற ஒரு IP address ஆக மொழிபெயர்க்கிறது. Resolution என்பது ஒரு படிநிலை (hierarchical) lookup, பொதுவாக ஒரு **recursive resolver** (உங்கள் ISP-இன் அல்லது 8.8.8.8 போன்ற ஒரு பொது resolver) உங்களுக்காகச் செய்கிறது — அது உங்கள் சார்பாக **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** server களைக் கேட்கிறது (அவை TLD server களை அறியும்), பின்னர் `.com`-க்கான **TLD** server களை (அவை `example.com`-க்கு யார் authoritative என்பதை அறியும்), பின்னர் **authoritative** server ஐ (அது உண்மையான record ஐ வைத்திருக்கிறது). இதை ஒவ்வொரு முறையும் மீண்டும் செய்வதைத் தவிர்க்க, முடிவுகள் ஒவ்வொரு நிலையிலும் — browser, OS, மற்றும் resolver — **cache** செய்யப்படுகின்றன, ஒவ்வொன்றும் record-இன் **TTL** (time-to-live) ஐ மதிக்கிறது. ஒரு warm cache micro-second களில் resolve செய்கிறது; ஒரு cold lookup பல round trip களைச் செலவழிக்கலாம்.

பொதுவான **record வகைகள்**: `A` (name → IPv4), `AAAA` (name → IPv6), `CNAME` (மற்றொரு பெயருக்கு alias), `MX` (mail server கள்), `TXT` (தன்னிச்சையான text, SPF/verification-க்குப் பயன்படுகிறது), மற்றும் `NS` (ஒரு zone ஐ delegate செய்கிறது). Resolution ஐ நீங்கள் நேரடியாகப் பரிசோதிக்கலாம்:

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

## இது ஏன் முக்கியம்

DNS என்பது ஒரு பெயரிலிருந்து தொடங்கும் *ஒவ்வொரு* request-இன் critical path-இல் அமர்ந்திருக்கிறது, எனவே ஒரு மெதுவான அல்லது தவறாக configure செய்யப்பட்ட resolver அனைத்திற்கும் latency ஐச் சேர்க்கிறது. நீங்கள் **hierarchy மற்றும் caching** ஐப் புரிந்துகொள்கிறீர்களா என்பதை இக்கேள்வி வெளிப்படுத்துவதால் interviewer கள் இதை விரும்புகிறார்கள் — ஒரு உலகளாவிய, distributed system கோடிக்கணக்கான query களை வேகமாகப் பதிலளிக்க அனுமதிக்கும் இரண்டு கருத்துக்கள் இவை. இது நிஜமான production incident களின் அடிக்கடி மூலமும் ஆகும் ("எப்போதும் DNS தான்"): காலாவதியான record கள், தவறான TTL கள், அல்லது ஒரு மாற்றத்திற்குப் பிறகான propagation தாமதங்கள் — எனவே caching மற்றும் TTL எவ்வாறு செயல்படுகின்றன என்பதை அறிவது நேரடியாகவே நடைமுறைப் பயனுள்ளது.

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்