DNS resolution ఎలా పనిచేస్తుంది?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) అనేది internet phone book: ఇది `example.com` వంటి మనుషులు చదవగల పేరును `93.184.216.34` వంటి IP addressగా అనువదిస్తుంది. Resolution అనేది hierarchical 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 ఉన్నది). ప్రతిసారీ దీన్ని పునరావృతం చేయకుండా ఉండటానికి, results ప్రతి స్థాయిలోనూ **cache** చేయబడతాయి — browser, OS, మరియు resolver — ప్రతి ఒక్కటి record యొక్క **TTL** (time-to-live)ను గౌరవిస్తూ. warm cache microsecondsలో resolve చేస్తుంది; cold lookup అనేక round trips ఖర్చు కావచ్చు.

సాధారణ **record types**: `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లో ఉంటుంది, కాబట్టి నెమ్మది లేదా misconfigured resolver ప్రతిదానికీ latency జోడిస్తుంది. Interviewers ఈ ప్రశ్నను ఇష్టపడతారు ఎందుకంటే మీరు **hierarchy మరియు caching** అర్థం చేసుకున్నారో లేదో బయటపెడుతుంది — ఒక global, distributed system billions of queriesకు వేగంగా సమాధానం ఇవ్వనిచ్చే రెండు ఆలోచనలు. ఇది నిజ production incidentsకు కూడా తరచుగా మూలం ("it's always DNS"): expired records, తప్పు TTLs, లేదా మార్పు తర్వాత propagation delays — కాబట్టి caching మరియు TTL ఎలా పనిచేస్తాయో తెలుసుకోవడం నేరుగా ఆచరణాత్మకం.

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు