DNS (Domain Name System) internet ਦੀ ਫ਼ੋਨ ਡਾਇਰੈਕਟਰੀ ਹੈ: ਇਹ example.com ਵਰਗੇ ਇਨਸਾਨ ਦੇ ਪੜ੍ਹਨਯੋਗ ਨਾਂ ਨੂੰ 93.184.216.34 ਵਰਗੇ IP address ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ। Resolution ਇੱਕ ਲੜੀਵਾਰ (hierarchical) lookup ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਲਈ ਇੱਕ recursive resolver (ਤੁਹਾਡੇ ISP ਦਾ ਜਾਂ 8.8.8.8 ਵਰਗਾ ਕੋਈ ਜਨਤਕ) ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਵੱਲੋਂ authoritative name server ਦੇ ਰੁੱਖ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ:
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 ਰੱਖਦਾ ਹੈ)। ਇਸਨੂੰ ਹਰ ਵਾਰ ਦੁਹਰਾਉਣ ਤੋਂ ਬਚਣ ਲਈ, ਨਤੀਜੇ ਹਰ ਪੱਧਰ 'ਤੇ cache ਕੀਤੇ ਜਾਂਦੇ ਹਨ — browser, OS, ਅਤੇ resolver — ਹਰ ਇੱਕ record ਦੇ TTL (time-to-live) ਦਾ ਸਨਮਾਨ ਕਰਦਾ ਹੈ। ਇੱਕ ਗਰਮ cache microsecond ਵਿੱਚ resolve ਕਰ ਲੈਂਦਾ ਹੈ; ਇੱਕ ਠੰਢੇ lookup ਦੀ ਕੀਮਤ ਕਈ round trip ਹੋ ਸਕਦੀ ਹੈ।
ਆਮ record type: A (name → IPv4), AAAA (name → IPv6), CNAME (ਕਿਸੇ ਹੋਰ name ਲਈ alias), MX (mail server), TXT (ਮਨਮਰਜ਼ੀ ਦਾ text, SPF/verification ਲਈ ਵਰਤਿਆ), ਅਤੇ NS (ਇੱਕ zone ਸੌਂਪਦਾ ਹੈ)। ਤੁਸੀਂ resolution ਨੂੰ ਸਿੱਧਾ ਦੇਖ ਸਕਦੇ ਹੋ:
dig example.com A # shows the A record and which server answered
DNS ਹਰ ਉਸ request ਦੇ ਨਾਜ਼ੁਕ ਰਾਹ 'ਤੇ ਬੈਠਦਾ ਹੈ ਜੋ ਕਿਸੇ ਨਾਂ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਹੌਲੀ ਜਾਂ ਗ਼ਲਤ-ਸੰਰਚਿਤ resolver ਹਰ ਚੀਜ਼ ਵਿੱਚ latency ਜੋੜ ਦਿੰਦਾ ਹੈ। Interviewers ਨੂੰ ਇਹ ਸਵਾਲ ਪਸੰਦ ਹੈ ਕਿਉਂਕਿ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ hierarchy ਅਤੇ caching ਨੂੰ ਸਮਝਦੇ ਹੋ ਜਾਂ ਨਹੀਂ — ਦੋ ਵਿਚਾਰ ਜੋ ਇੱਕ ਵਿਸ਼ਵ-ਪੱਧਰੀ, ਵੰਡੇ ਹੋਏ system ਨੂੰ ਅਰਬਾਂ query ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਣ ਦਿੰਦੇ ਹਨ। ਇਹ ਅਸਲ production ਘਟਨਾਵਾਂ ਦਾ ਵੀ ਇੱਕ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲਾ ਸਰੋਤ ਹੈ ("ਹਮੇਸ਼ਾ DNS ਹੀ ਹੁੰਦਾ ਹੈ"): ਮਿਆਦ-ਮੁੱਕੇ record, ਗ਼ਲਤ TTL, ਜਾਂ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ propagation ਦੀ ਦੇਰੀ, ਇਸ ਲਈ caching ਅਤੇ TTL ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ ਇਹ ਜਾਣਨਾ ਸਿੱਧਾ ਵਿਹਾਰਕ ਹੈ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ