DNS resolution કેવી રીતે કામ કરે છે?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) એ internet ની ફોન બુક છે: તે `example.com` જેવા માણસ-વાંચી-શકાય તેવા નામને `93.184.216.34` જેવા IP સરનામામાં અનુવાદે છે. Resolution એ એક વંશવેલો lookup છે, સામાન્ય રીતે તમારા માટે એક **recursive resolver** (તમારા ISP નું કે 8.8.8.8 જેવું public) દ્વારા થાય છે જે તમારા વતી **authoritative** name servers ના વૃક્ષમાં ચાલે છે:

```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** servers ને પૂછે છે (જે TLD servers જાણે છે), પછી `.com` માટે **TLD** servers ને (જે જાણે છે કે `example.com` માટે કોણ authoritative છે), પછી **authoritative** server ને (જે ખરેખરો record ધરાવે છે). આ દર વખતે ન દોહરાવવા માટે, પરિણામો દરેક સ્તરે — browser, OS, અને resolver — **cache** થાય છે, દરેક record ના **TTL** (time-to-live) ને માન આપતાં. ગરમ cache microseconds માં resolve થાય છે; ઠંડો lookup અનેક round trips ખર્ચી શકે.

સામાન્ય **record પ્રકારો**: `A` (name → IPv4), `AAAA` (name → IPv6), `CNAME` (બીજા નામનું alias), `MX` (mail servers), `TXT` (મનસ્વી text, SPF/verification માટે વપરાય), અને `NS` (એક zone ને delegate કરે). તમે resolution ને સીધું તપાસી શકો છો:

```bash
dig example.com A       # A record અને કયા server એ જવાબ આપ્યો તે બતાવે
```

## આ શા માટે મહત્વનું છે

DNS *દરેક* request ના critical path પર બેસે છે જે નામથી શરૂ થાય છે, તેથી ધીમો કે ખોટી રીતે-configured resolver બધામાં latency ઉમેરે છે. Interviewers આ પ્રશ્ન પસંદ કરે છે કારણ કે તે છતું કરે છે કે તમે **hierarchy અને caching** સમજો છો કે નહીં — બે વિચારો જે એક વૈશ્વિક, distributed system ને અબજો queries ને ઝડપથી જવાબ આપવા દે છે. તે વાસ્તવિક production ઘટનાઓનું વારંવારનું સ્રોત પણ છે ("હંમેશા DNS જ હોય છે"): expired records, ખોટા TTLs, કે ફેરફાર પછી propagation delays — તેથી caching અને TTL કેવી રીતે કામ કરે છે તે જાણવું સીધું વ્યાવહારિક છે.

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો