ਪੌਲ ਮੋਕਾਪੈਟ੍ਰਿਸ ਅਤੇ DNS: ਇੰਟਰਨੈੱਟ ਨੂੰ ਮਨੁੱਖੀ ਨਾਮ ਕਿਵੇਂ ਮਿਲੇ

ਇੰਟਰਨੈੱਟ ਵਰਤਣ ਵਾਲਿਆਂ ਲਈ DNS ਕਿਉਂ ਅਹੰਕਾਰਪੂਰਕ ਹੈ

ਜਦ ਵੀ ਤੁਸੀਂ ਕੋਈ ਵੈੱਬ ਐਡਰੈੱਸ ਟਾਈਪ ਕਰਦੇ ਹੋ, ਕਿਸੇ ਲਿੰਕ 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹੋ, ਜਾਂ ਈਮੇਲ ਭੇਜਦੇ ਹੋ, ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਣ ਵਿਚਾਰ 'ਤੇ ਨਿਰਭਰ ਹੋ: ਮਨੁੱਖਾਂ ਲਈ ਯਾਦ ਰਹਿਣ ਵਾਲੇ ਨਾਮ ਹੋਣ ਚਾਹੀਦੇ ਹਨ, ਜਦਕਿ ਕੰਪਿਊਟਰ ਸਹੀ ਮਸ਼ੀਨ ਲੱਭਣ ਦਾ ਕੰਮ ਕਰਨ।

DNS ਇੱਕ ਰੋਜ਼ਾਨਾ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦਾ ਹੈ: ਕੰਪਿਊਟਰ ਨੰਬਰਾਤਮਕ ਪਤੇ (IP ਪਤੇ) ਵਰਤਦੇ ਹਨ ਜਿਵੇਂ 203.0.113.42, ਪਰ ਲੋਕ ਨੰਬਰਾਂ ਦੀ ਲੜੀ ਯਾਦ ਨਹੀਂ ਰੱਖਣਾ ਚਾਹੁੰਦੇ। ਤੁਸੀਂ example.com ਯਾਦ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਨਾ ਕਿ ਉਸ ਸਾਈਟ ਦਾ ਅੱਜ ਦਾ ਪਤਾ।

ਇੱਕ ਵਰਕ ਵਿੱਚ DNS

ਡੋਮੇਨ ਨੇਮ ਸਿਸਟਮ (DNS) ਇੰਟਰਨੈੱਟ ਦੀ “ਐਡਰੈੱਸ ਬੁੱਕ” ਹੈ ਜੋ ਮਨੁੱਖ-ਮਿਤ੍ਰੀ ਡੋਮੇਨ ਨਾਮਾਂ ਨੂੰ ਉਨ੍ਹਾਂ IP ਪਤਿਆਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਕੰਪਿਊਟਰ ਜੁੜਦੇ ਹਨ।

ਇਹ ਤਬਦੀਲੀ ਛੋਟੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਇਹ ਉਦਾਹਰਣ ਤਾਂ ਉਸ ਇੰਟਰਨੈੱਟ ਵਿਚਕਾਰ ਫਰਕ ਹੈ ਜੋ ਵਰਤਣਯੋਗ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਸ ਇੰਟਰਨੈੱਟ ਵਿਚਕਾਰ ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅੰਕਾਂ ਨਾਲ ਭਰੀ ਫੋਨ ਡਾਇਰੈਕਟਰੀ ਵਾਂਗ ਹੋਏ।

ਇਸ ਗਾਈਡ ਵਿੱਚ ਕੀ ਉਮੀਦ ਰੱਖੋ

ਇਹ ਇੱਕ ਗੈਰ-ਤਕਨੀਕੀ ਸਫ਼ਰ ਹੈ—ਕੋਈ ਨੈਟਵਰਕਿੰਗ ਪृष्ठਭੂਮੀ ਲੋੜੀਂਦੀ ਨਹੀਂ। ਅਸੀਂ ਚੱਲ ਕੇ ਵੇਖਾਂਗੇ:

• DNS ਦੇ ਮੂਲ ਵਿਚਾਰ ਅਤੇ ਇਹ ਕਿਉਂ ਲੋੜੀਂਦਾ ਸੀ
• ਮੁੱਖ ਭੂਮਿਕਾਵਾਂ (ਤੁਹਾਡਾ ਡਿਵਾਈਸ, DNS ਰੀਜ਼ੋਲਵਰ, ਅਤੇ authoritative ਸਰਵਰ)
• ਉਹ ਹਿੱਸੇ ਜੋ ਤੁਸੀਂ ਵੈੱਬਸਾਈਟ ਜਾਂ ਈਮੇਲ ਚਲਾਉਂਦੇ ਸਮੇਂ ਅਮਲ ਵਿੱਚ ਵੇਖੋਗੇ
• DNS ਨਾਲ ਜੁੜੇ ਸੁਰੱਖਿਆ ਅਤੇ ਭਰੋਸੇ ਦੇ ਸਵਾਲ (ਅਤੇ ਉਹ ਸੰਦ ਜੋ ਮਦਦ ਕਰਦੇ ਹਨ)

ਰਾਹ ਵਿੱਚ, ਤੁਸੀਂ Paul Mockapetris ਨਾਲ ਮਿਲੋਗੇ, ਉਹ ਇੰਜੀਨੀਅਰ ਜਿਸ ਨੇ 1980 ਦੇ ਦਹਾਕੇ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ DNS ਡਿਜ਼ਾਇਨ ਕੀਤਾ। ਉਹਨਾਂ ਦਾ ਕੰਮ ਮਹੱਤਵਪੂਰਨ ਇਸ ਲਈ ਸੀ ਕਿ ਉਹ ਨੇ ਸਿਰਫ਼ ਨਵਾਂ ਨਾਮ ਫਾਰਮੈਟ ਨਹੀਂ ਬਣਾਇਆ—ਉਸ ਨੇ ਇੱਕ ਐਸੀ ਪ੍ਰਣਾਲੀ ਤਿਆਰ ਕੀਤੀ ਜੋ ਇੰਟਰਨੈੱਟ ਦੇ ਛੋਟੇ ਖੋਜ-ਨੈੱਟਵਰਕ ਤੋਂ ਬਿਲੀਅਨ ਲੋਕਾਂ ਵੱਲ ਫੈਲਣ 'ਤੇ ਵੀ ਸਕੇਲ ਹੋ ਸਕੇ।

ਜੇ ਤੁਸੀਂ ਕਦੇ ਕਿਸੇ ਸਾਈਟ ਦੇ “ਡਾਊਨ” ਹੋਣ, ਡੋਮੇਨ ਬਦਲਾਅ ਦੇ “ਪ੍ਰੋਪੈਗੇਟ” ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਨ, ਜਾਂ ਸੋਚਿਆ ਕਿ ਈਮੇਲ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਕਿਉਂ ਰਾਜ਼ੀ DNS ਐਂਟਰੀਜ਼ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਬਾਹਰੋਂ DNS ਨੂੰ ਮਿਲ ਚੁੱਕੇ ਹੋ। ਬਾਕੀ ਇਸ ਲੇਖ ਵਿੱਚ ਪਿਛਲੇ ਸਿਖਰਿਆਂ ਦੇ ਪਿੱਛੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ—ਸਾਫ਼ ਅਤੇ ਬਿਨਾਂ ਜਾਰਗਨ ਦੇ ਸਮਝਾਇਆ ਗਿਆ ਹੈ।

DNS ਤੋਂ ਪਹਿਲਾਂ: ਜਦ ਇੱਕ ਸਾਂਝੀ ਫਾਈਲ ਨੇ ਸਭ ਕੁਝ ਨਾਮ ਦਿੱਤਾ

ਇੱਕ ਜਾਣੇ-ਪਹਚਾਣੇ ਵੈੱਬ ਐਡਰੈੱਸ ਟਾਈਪ ਕਰਨ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ, ਸ਼ੁਰੂਆਤੀ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਇੱਕ ਸਧਾਰਣ ਸਮੱਸਿਆ ਸੀ: ਤੁਸੀਂ ਕਿਸੇ ਖਾਸ ਮਸ਼ੀਨ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚੋ? ਕੰਪਿਊਟਰ IP ਪਤਿਆਂ (10.0.0.5 ਵਰਗੇ) ਨਾਲ ਗੱਲ ਕਰ ਸਕਦੇ ਸਨ, ਪਰ ਮਨੁੱਖ hostnames ਨੂੰ ਪਸੰਦ ਕਰਦੇ ਸਨ—ਛੋਟੇ ਨਾਂ ਜਿਵੇਂ MIT-MC ਜਾਂ SRI-NIC ਜੋ ਯਾਦ ਕਰਨ ਅਤੇ ਸਾਂਝਾ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਸਨ。

ਮੁਢਲਾ “ਨੇਮ ਸੇਵਾ”: HOSTS.TXT

ਆਰਪਾਯਾਨੈਟ ਲਈ ਹੱਲ ਇੱਕ ਇੱਕਲ ਸਾਂਝੀ ਫਾਈਲ ਸੀ ਜਿਸਨੂੰ HOSTS.TXT ਕਿਹਾ ਜਾਂਦਾ ਸੀ। ਇਹ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਇੱਕ ਲੁੱਕਅੱਪ ਟੇਬਲ ਸੀ: hostnames ਨੂੰ ਉਹਨਾਂ ਦੇ IP ਪਤਿਆਂ ਨਾਲ ਜੋੜਨ ਵਾਲੀ ਸੂਚੀ।

ਹਰੇਕ ਕੰਪਿਊਟਰ ਨੇ ਇਸ ਫਾਈਲ ਦੀ ਇਕ ਸਥਾਨਕ ਨਕਲ ਰੱਖੀ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਮਸ਼ੀਨ ਨੂੰ ਨਾਮ ਨਾਲ ਕਨੈਕਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ, ਤੁਹਾਡੀ ਸਿਸਟਮ HOSTS.TXT ਚੈੱਕ ਕਰਦੀ ਅਤੇ ਮਿਲਦਾ IP ਪਤਾ ਲੱਭ ਲੈਂਦੀ।

ਇਹ ਸ਼ੁਰੂ ਵਿੱਚ ਕੰਮ ਕੀਤਾ ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਛੋਟਾ ਸੀ, ਬਦਲਾਅ ਘੱਟ ਹੁੰਦੇ ਸਨ, ਅਤੇ ਅਪਡੇਟ ਲੈਣ ਦਾ ਇੱਕ ਸਾਫ਼ ਥਾਂ ਸੀ।

ਜਦ ਇਹ ਕੰਮ ਕਰਨਾ ਬੰਦ ਹੋ ਗਿਆ

ਜਿਵੇਂ ਜ਼ਿਆਦਾ ਸੰਗਠਨ ਸ਼ਾਮਲ ਹੋਏ, ਇਹ ਢੰਗ ਸਧਾਰਨ ਵਾਧੇ ਨੂੰ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕਰ ਸਕਿਆ:

• ਅਪਡੇਟ ਲਗਾਤਾਰ ਹੋ ਗਏ। ਨਵੀਆਂ ਮਸ਼ੀਨਾਂ ਆਈਆਂ, ਪتے ਬਦਲੇ, ਨਾਂ ਸੋਧੇ ਜਾਣੇ ਲੋੜੇ।
• ਨਾਂ-ਘਟਨ ਵਧ ਗਏ। ਦੋ ਗਰੁੱਪ ਇਕੋ hostname ਚੁਣ ਸਕਦੇ ਸਨ ਬਿਨਾਂ ਅੰਦਾਜ਼ੇ ਦੇ।
• ਵੰਡ ਵਿੱਚ ਦੇਰੀ ਕਾਰਨ ਆਉਟੇਜ ਹੋਏ। ਜੇ ਤੁਹਾਡੇ HOSTS.TXT ਦੀ ਨਕਲ ਪੁਰਾਣੀ ਸੀ ਤਾਂ ਇੱਕ hostname ਗਲਤ ਪਤੇ ਨੂੰ ਜਾਂ ਕਿਸੇ ਥਾਂ ਨੂੰ ਇशਾਰਾ ਕਰ ਸਕਦੀ ਸੀ।

ਮੁਢਲਾ ਮੁੱਦਾ ਸਹਿਯੋਗ ਸੀ। HOSTS.TXT ਇਕ ਸਾਰੀ ਦੁਨੀਆ ਲਈ ਇੱਕ ਸਾਂਝੀ ਐਡਰੈੱਸ ਬੁੱਕ ਵਰਗੀ ਸੀ। ਜੇ ਹਰ ਕੋਈ ਇਕੋ ਕਿਤਾਬ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਹਰ ਸੁਧਾਰ ਨੂੰ ਗਲੋਬਲ ਸੋਧ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਨਵਾਂ ਵਰਜਨ ਤੇਜ਼ੀ ਨਾਲ ਡਾਊਨਲੋਡ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਜਦ ਨੈੱਟਵਰਕ ਇੱਕ ਨਿਸ਼ਚਿਤ ਆਕਾਰ ਤੱਕ ਪਹੁੰਚਿਆ, ਉਹ “ਸਭ ਕੁਝ ਲਈ ਇੱਕ ਫਾਈਲ” ਮਾਡਲ ਬਹੁਤ ਦੇਰ ਨਾਲ, ਬਹੁਤ ਕੇਂਦਰੀਕ੍ਰਿਤ ਅਤੇ ਗਲਤੀ-ਸੁਰੰਗ ਬਣ ਗਿਆ।

DNS ਨੇ ਨਾਮਾਂ ਨੂੰ ਨੰਬਰਾਂ ਨਾਲ ਜੋੜਨ ਦੇ ਵਿਚਾਰ ਨੂੰ ਬਦਲਾ ਨਹੀਂ—ਪਰ ਇਸਨੇ ਉਸ ਨਾਜੁਕ ਢੰਗ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਜਿਸ ਵਿੱਚ ਉਹ ਨਕਸ਼ੇ ਬਣਾਏ ਅਤੇ ਵੰਡੇ ਜਾਂਦੇ ਸਨ।

Paul Mockapetris: ਸਕੇਲ ਕਰਨਯੋਗ ਨਾਮਕਾਰੀ ਵਿਚਾਰ ਦੇ ਇੰਜੀਨੀਅਰ

1980 ਦੇ ਦਹਾਕੇ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ, ਇੰਟਰਨੈੱਟ ਇੱਕ ਛੋਟੇ ਖੋਜ ਨੈੱਟਵਰਕ ਤੋਂ ਕੁਝ ਵੱਧ, ਗੁੰਝਲਦਾਰ ਅਤੇ ਵੱਧ ਤਰੀਕੇ ਨਾਲ ਸਾਂਝਾ ਹੋਣ ਵਾਲੀ ਚੀਜ਼ ਵੱਲ ਬਦਲ ਰਿਹਾ ਸੀ। ਹੋਰ ਮਸ਼ੀਨੇ ਜੁੜ ਰਹੇ ਸਨ, ਸੰਗਠਨਾਂ ਨੇ ਆਤਮ-ਨਿਯੰਤਰਣ ਚਾਹਿਆ, ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਨੰਬਰਾਤਮਕ ਪਤੇ ਯਾਦ ਕਰਨ ਦੀ ਬਜਾਏ ਇੱਕ ਆਸਾਨ ਤਰੀਕਾ ਚਾਹੀਦਾ ਸੀ।

Paul Mockapetris, ਇਸ ਮਾਹੌਲ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹੋਏ, ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ DNS ਦਾ ਡਿਜ਼ਾਇਨਰ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਉਹਨਾਂ ਦਾ ਯੋਗਦਾਨ ਕੋਈ ਦਿੱਖਤ ਉਤਪਾਦ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ ਜਵਾਬ ਸੀ ਇੱਕ ਬਹੁਤ ਪ੍ਰਯੋਗਿਕ ਸਵਾਲ ਦਾ: ਜਦ ਨੈੱਟਵਰਕ ਵੱਧਦਾ ਜਾਵੇ ਤਾਂ ਨਾਮ ਕਿਵੇਂ ਉਪਯੋਗੀ ਰਹਿੰਦੇ?

ਮੁੱਖ ਸੋਚ: ਨਾਂ-ਰੱਖਿਆ ਨੂੰ ਸਕੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

ਨਾਂ-ਰੱਖਣ ਦੀ ਪ੍ਰਣਾਲੀ ਅਸਾਨ ਲੱਗਦੀ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਸੋਚੋ ਕਿ ਉਸ ਵੇਲੇ "ਆਸਾਨ" ਦਾ ਕੀ ਅਰਥ ਸੀ: ਇੱਕ ਸਾਂਝੀ ਸੂਚੀ ਜੋ ਹਰ ਕੋਈ ਡਾਊਨਲੋਡ ਕਰਦਾ ਅਤੇ ਰੱਖਦਾ। ਜਦ ਬਦਲਾਅ ਲਗਾਤਾਰ ਹੋ ਜਾਂਦੇ, ਉਹ ਢੰਗ ਤੁਰੰਤ ਟੁੱਟ ਜਾਂਦਾ। ਹਰ ਨਵਾਂ ਹੋਸਟ, ਰੀ-ਨਾਮ ਜਾਂ ਸੁਧਾਰ ਸਭ ਲਈ ਸਹਿਯੋਗ ਦਾ ਕੰਮ ਬਣ ਜਾਂਦਾ।

Mockapetris ਦੀ ਮੁੱਖ ਸੋਚ ਇਹ ਸੀ ਕਿ ਨਾਮ ਸਿਰਫ ਡੇਟਾ ਨਹੀਂ; ਉਹ ਸਾਂਝੇ ਸਮਝੌਤੇ ਹਨ। ਜੇ ਨੈੱਟਵਰਕ ਫੈਲਦਾ ਹੈ, ਤਾਂ ਉਹ ਸਿਸਟਮ ਜੋ ਉਹ ਸਮਝੌਤੇ ਬਣਾਉਂਦਾ ਅਤੇ ਵੰਡਦਾ ਹੈ, ਉਸਨੂੰ ਵੀ ਬਿਨਾਂ ਹਰ ਕੰਪਿਊਟਰ ਨੂੰ ਇੱਕ ਮਾਸਟਰ ਸੂਚੀ ਲਗਾਤਾਰ ਲੈਣ ਦੀ ਲੋੜ ਪਏ ਵਧਣਾ ਚਾਹੀਦਾ।

ਇੱਕ ਵੰਡਿਆ ਹੋਇਆ ਸਿਸਟਮ, ਵੱਡੀ ਫਾਈਲ ਨਹੀਂ

DNS ਨੇ “ਇੱਕ ਪ੍ਰਮਾਣਿਕ ਫਾਈਲ” ਦੇ ਵਿਚਾਰ ਨੂੰ ਇੱਕ ਵੰਡਏ ਡਿਜ਼ਾਈਨ ਨਾਲ ਬਦਲ ਦਿੱਤਾ:

• ਜ਼ਿੰਮੇਵਾਰੀ ਵੰਡੀ ਜਾਂਦੀ ਹੈ: ਵੱਖ-ਵੱਖ ਸੰਗਠਨ ਆਪਣੀ ਜ਼ੋਨ ਸੰਭਾਲਦੇ ਹਨ।
• ਉੱਤਰ ਪੁੱਛ ਕੇ ਲੱਭੇ ਜਾਂਦੇ ਹਨ, ਨਾ ਕਿ ਸਾਰੀ ਦੁਨੀਆ ਨੂੰ ਲੋਕਲ ਤੌਰ 'ਤੇ ਕਾਪੀ ਕਰਕੇ।
• ਨਤੀਜੇ ਕੈਸ਼ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਤਾਂ ਕਿ ਜ਼ਿਆਦਾਤਰ ਲੁੱਕਅਪ ਤੇਜ਼ ਹੋਣ, ਪਰ ਬਦਲਾਅ ਵੀ ਸਮੇਂ ਨਾਲ ਪ੍ਰਸਾਰਿਤ ਹੋ ਸਕਦੇ ਹਨ।

ਇਹ ਚੁਪਚਾਪ ਬੁਧੀਮਾਨੀ ਹੈ: DNS ਨੂੰ ਚਤੁਰ ਬਣਾਉਣ ਲਈ ਨਹੀਂ, ਬਲਕਿ ਅਸਲ ਬੰਧਨਾਂ ਦੇ ਹੇਠਾਂ ਕੰਮ ਕਰਦੇ ਰਹਿਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ—ਸੀਮਤ ਬੈਂਡਵਿਡਥ, ਬਾਰੰਬਾਰ ਬਦਲਾਅ, ਬਹੁਤ ਸਾਰੇ ਸੁਤੰਤਰ ਐਡਮਿਨ ਅਤੇ ਰੁਕਣ ਵਾਲਾ ਨੈੱਟਵਰਕ।

ਉਹ ਡਿਜ਼ਾਈਨ ਦੇ ਲਕੜੀਆਂ ਜੋ DNS ਨੂੰ ਆਕਾਰ ਦਿੱਤਾ

DNS ਕਿਸੇ ਚਲਾਕ ਸ਼ੌਟਕਾਟ ਵਜੋਂ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ—ਇਹ ਸਪੱਸ਼ਟ ਲਕੜੀਆਂ ਹੱਲ ਕਰਨ ਲਈ ਰਚਿਆ ਗਿਆ ਸੀ ਜੋ ਸ਼ੁਰੂਆਤੀ ਇੰਟਰਨੈੱਟ ਦੇ ਵੱਧਣ ਤੇ ਸਾਹਮਣੇ ਆ ਰਹੀਆਂ ਸਨ। Mockapetris ਨੇ ਪਹਿਲਾਂ ਸਪਸ਼ਟ ਲੱਖੇ ਰੱਖੇ, ਫਿਰ ਇੱਕ ਐਸੀ ਨਾਂ-ਪ੍ਰਣਾਲੀ ਬਣਾਈ ਜੋ ਦਹਾਕਿਆਂ ਤੱਕ ਨਾਲ ਨਾਲ ਰਹਿ ਸਕੇ।

ਲਕੜੀਆਂ, ਸਧੇ ਭਾਸ਼ਾ ਵਿੱਚ

• ਸਕੇਲੇਬਲ: ਇਹ ਸਿਰਫ ਸੈਂਕੜਿਆਂ ਲਈ ਨਹੀਂ, ਸਗੋਂ ਮਿਲੀਅਨ (ਅਤੇ ਆਖ਼ਿਰਕਾਰ ਬਿਲੀਅਨ) ਨਾਮਾਂ ਲਈ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਸੀ।
• ਵੰਡਿਆ ਹੋਇਆ: ਕੋਈ ਇਕ ਮਾਸਟਰ ਫਾਈਲ ਜਾਂ ਇਕ ਕੇਂਦਰੀ ਮਸ਼ੀਨ ਹਰੇਕ ਚੀਜ਼ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਨਹੀਂ ਹੋ ਸਕਦੀ।
• ਭਰੋਸੇਯੋਗ: ਪਰਣਾਲੀ ਨੂੰ ਉਹਦੇ ਵੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਸੀ ਜਦ ਕੁਝ ਸਰਵਰ ਡਾਊਨ ਹੋ ਜਾਂ ਜਾਂਨ-ਪਹੁੰਚਯੋਗ ਨਾ ਹੋਣ।
• ਸੰਭਾਲਣ ਵਿੱਚ ਆਸਾਨ: ਸੰਗਠਨਾਂ ਨੂੰ ਆਪਣੀ ਆਪਣੀ ਨਾਂ-ਸਥਾਪਨਾ ਅਪਡੇਟ ਕਰਨ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਸੀ ਬਿਨਾਂ ਇੱਕ ਗਲੋਬਲ ਐਡਮਿਨ ਨੂੰ ਬੜੀ ਸੂਚੀ ਸੋਧਣ ਲਈ ਪੁੱਛਣ ਦੇ।

Delegation: “ਰਹੱਸ”

ਮੁੱਖ ਸੰਕਲਪ delegation ਹੈ: ਵੱਖ-ਵੱਖ ਗਰੁੱਪ ਨਾਂ-ਦਰੱਖ਼ਤ ਦੇ ਵੱਖਰੇ ਹਿੱਸਿਆਂ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦੇ ਹਨ।

ਉਦਾਹਰਣ ਲਈ, .com ਦੇ ਹੇਠਾਂ ਦੀ ਚੀਜ਼ ਦਾ ਪ੍ਰਬੰਧ ਇਕ ਸੰਸਥਾ ਕਰਦੀ ਹੈ, ਇੱਕ registrar ਤੁਹਾਨੂੰ example.com ਕਲੈਮ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਤੁਸੀਂ (ਜਾਂ ਤੁਹਾਡਾ DNS ਪ੍ਰਦਾਤਾ) www.example.com, mail.example.com ਆਦਿ ਲਈ ਰਿਕਾਰਡ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ। ਇਸ ਨਾਲ ਜ਼ਿੰਮੇਵਾਰੀ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਵੰਡ ਜਾਂਦੀ ਹੈ ਤਾਂ ਕਿ ਵਾਧਾ ਸਾਰਥਕ ਤੌਰ 'ਤੇ ਬੋਤਲ-ਨੇਕ ਨਾ ਬਣੇ।

ਫੇਲ੍ਹ ਹੋਣ ਨੂੰ ਸਹਿਣ ਲਈ ਬਣਾਇਆ ਗਿਆ

DNS ਇਹ ਮੰਨਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆਵਾਂ ਹੋਣਗੀਆਂ—ਸਰਵਰ ਗਿਰ ਜਾਂਦੇ ਹਨ, ਨੈੱਟਵਰਕ ਕਟ ਸਕਦੇ ਹਨ, ਰੂਟ ਬਦਲ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ ਇਹ ਡੋਮੇਨ ਲਈ ਕਈ authoritative ਸਰਵਰਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ ਅਤੇ resolverਾਂ ਵਿੱਚ ਕੈਸ਼ਿੰਗ 'ਤੇ, ਤਾਂ ਜੋ ਇੱਕ ਅਸਥਾਈ ਆਉਟੇਜ ਤੁਰੰਤ ਹਰ ਲੁੱਕਅਪ ਨਹੀਂ ਤੋੜੇ।

DNS ਕੀ ਹੈ (ਅਤੇ ਕੀ ਨਹੀਂ)

DNS ਮਨੁੱਖ-ਮਿਤ੍ਰੀ ਨਾਮਾਂ ਨੂੰ ਤਕਨੀਕੀ ਡੇਟਾ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ, ਸਭ ਤੋਂ ਪ੍ਰਚਲਤ ਤੌਰ 'ਤੇ IP ਪੱਤੇ। ਇਹ "ਆਪਣ-ਆਪ" ਇੰਟਰਨੈੱਟ ਨਹੀਂ ਹੈ—ਇਹ ਇੱਕ ਨਾਂ-ਅਤੇ-ਲੁੱਕਅੱਪ ਸੇਵਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਡਿਵਾਈਸ ਨੂੰ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿ ਕਿੱਥੇ ਜੁੜਨਾ ਹੈ।

ਇੱਕ ਫੋਟੋ ਵਿੱਚ DNS: ਨਾਮਾਂ ਦੀ ਇੱਕ ਹਾਇਰਾਰਕੀ

DNS ਨਾਮਾਂ ਨੂੰ ਇੱਕ ਦਰੱਖ਼ਤ ਵਾਂਗ ਸੰਗਠਿਤ ਕਰ ਕੇ ਸੰਭਾਲਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਹਰ ਨਾਮ ਨੂੰ ਗਲੋਬਲੀ ਅਨੁਨਾਇਕੀ ਬਣਾਉਣ ਦੇ ਬਜਾਏ (ਜਿੱਥੇ ਕਿਸੇ ਨੂੰ ਸਭ ਕੁਝ ਨਿਯੰਤਰਿਤ ਕਰਨਾ ਪੈਂਦਾ), DNS ਨਾਮਾਂ ਨੂੰ ਪੱਧਰਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਵੰਡ ਦਿੰਦਾ ਹੈ।

ਹਾਇਰਾਰਕੀ: root → TLD → domain → subdomain

ਇੱਕ DNS ਨਾਮ ਨੂੰ ਖੱਬੇ ਤੋਂ ਸੱਜੇ ਵੱਲ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ:

• Root: ਹਰ ਨਾਮ ਦੇ ਅੰਤ 'ਤੇ ਛੁਪਿਆ ਹੋਇਆ ਡਾਟ (ਅਕਸਰ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ). www.example.com. ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ . ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ।
• TLD (Top-Level Domain): .com, .org, .net, ਦੇਸ਼ ਕੋਡ ਜਿਵੇਂ .uk
• Domain: example ਜੋ example.com ਵਿੱਚ ਹੈ
• Subdomain / host: www ਜੋ www.example.com ਵਿੱਚ ਹੈ

ਇਸ ਤਰ੍ਹਾਂ www.example.com ਨੂੰ ਤੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ:

• com (TLD)
• example (ਡੋਮੇਨ .com ਹੇਠਾਂ ਰਜਿਸਟਰ ਕੀਤਾ ਗਿਆ)
• www (ਡੋਮੇਨ ਮਾਲਕ ਬਣਾਉਂਦਾ ਅਤੇ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ)

ਹਾਇਰਾਰਕੀ ਕਿਉਂ ਮਦਦ ਕਰਦੀ ਹੈ

ਇਸ ਸਰਚਨਾ ਨਾਲ ਟਕਰਾਅ ਘਟਦਾ ਹੈ ਕਿਉਂਕਿ ਨਾਮ ਸਿਰਫ਼ ਆਪਣੇ ਮਾਪੇ (parent) ਦੇ ਅੰਦਰ ਵਿਲੱਖਣ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਸਥਾਵਾਂ www ਵਰਗੇ ਉਪਡੋਮੇਨ ਰੱਖ ਸਕਦੀਆਂ ਹਨ ਕਿਉਂਕਿ www.example.com ਅਤੇ www.another-example.com ਟਕਰਾਅ ਨਹੀਂ ਕਰਦੇ।

ਇਹ ਵਰਕਲੋਡ ਨੂੰ ਵੀ ਵੰਡਦਾ ਹੈ। .com ਓਪਰੇਟਰ ਹਰ ਵੈੱਬਸਾਈਟ ਦੇ ਰਿਕਾਰਡ ਨੂੰ ਪ੍ਰਬੰਧਨ ਨਹੀਂ ਕਰਦੇ; ਉਹ ਸਿਰਫ਼ ਦੱਸਦੇ ਹਨ ਕਿ example.com किस ਨਾਂ ਸਰਵਰ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ example.com ਮਾਲਕ ਦੇਖਭਾਲ ਕਰਦਾ ਹੈ।

"Zone" ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ

ਇੱਕ ਜ਼ੋਨ ਉਹ ਦਰੱਖ਼ਤ ਦਾ ਇੱਕ ਪ੍ਰਬੰਧਯੋਗ ਹਿੱਸਾ ਹੈ—DNS ਡੇਟਾ ਜਿਹਨੂੰ ਕਿਸੇ ਨੇ ਛਾਪਨਾ ਹੋਇਆ ਹੈ। ਬਹੁਤ ਟੀਮਾਂ ਲਈ, "ਸਾਡੀ ਜ਼ੋਨ" ਦਾ ਮਤਲਬ ਹੈ "example.com ਦੇ DNS ਰਿਕਾਰਡ ਅਤੇ ਜਿਹੜੇ ਉਪਡੋਮੇਨ ਅਸੀਂ ਹੋਸਟ ਕਰਦੇ ਹਾਂ", ਜੋ ਉਹਨਾਂ ਦੇ authoritative DNS ਪ੍ਰਦਾਤਾ 'ਤੇ ਸਟੋਰ ਹੁੰਦੇ ਹਨ।

ਕੌਣ ਕੀ ਕਰਦਾ ਹੈ: Resolvers, Authoritative Servers, ਅਤੇ ਤੁਸੀਂ

ਜਦ ਤੁਸੀਂ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਇੱਕ ਵੈੱਬਸਾਈਟ ਦਾ ਨਾਮ ਟਾਈਪ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ "ਇੰਟਰਨੈੱਟ" ਨੂੰ ਸਿੱਧਾ ਨਹੀਂ ਪੁੱਛ ਰਹੇ। ਕੁਝ ਖਾਸ ਸਹਾਇਕ ਕੰਮ ਵੰਡ ਕੇ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਜਵਾਬ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਮਿਲੇ।

ਮੁੱਖ ਅਦਾਕਾਰ

ਤੁਸੀਂ (ਤੁਹਾਡਾ ਡਿਵਾਈਸ ਅਤੇ ਬਰਾਊਜ਼ਰ) ਇੱਕ ਸਧਾਰਣ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ: "ਕਿਸ IP ਪਤੇ 'ਤੇ example.com ਮੈਚ ਕਰਦਾ ਹੈ?" ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡਾ ਡਿਵਾਈਸ ਅਜੇ ਤੱਕ ਜਵਾਬ ਨਹੀਂ ਜਾਣਦਾ, ਹਮ ਇੱਥੇ ਤੱਕ ਇਕ ਦਰਜਨ ਸਰਵਰਾਂ ਨੂੰ ਪੁਕਾਰਨਾ ਨਹੀਂ ਚਾਹੁੰਦਾ।

ਇੱਕ recursive resolver ਤੁਹਾਡੇ ਵਾਸਤੇ ਲੱਭ ਕਰਦਾ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ISP, ਤੁਹਾਡੇ ਕੰਪਨੀ/ਸਕੂਲ IT, ਜਾਂ ਇੱਕ ਪਬਲਿਕ resolver ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਮੁੱਖ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਇਹ ਪਹਿਲਾਂ ਵਾਲੀਆਂ ਲੁੱਕਅਪ ਤੋਂ ਕੈਸ਼ ਕੀਤੇ ਜਵਾਬ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦਾ ਹੈ, ਜੋ ਹਰ ਕਿਸੇ ਲਈ ਗਤੀ ਤੇਜ਼ ਕਰਦਾ ਹੈ।

Authoritative DNS servers ਕਿਸੇ ਡੋਮੇਨ ਲਈ ਸੱਚ ਦੀ ਸਰੋਤ ਹੁੰਦੇ ਹਨ। ਉਹ "ਇੰਟਰਨੈੱਟ ਖੋਜ" ਨਹੀਂ ਕਰਦੇ; ਉਹ ਆਫੀਸ਼ਲ ਰਿਕਾਰਡ ਰੱਖਦੇ ਹਨ ਜੋ ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਸ IP, ਮੇਲ ਸਰਵਰ, ਜਾਂ ਵੈਰੀਫਿਕੇਸ਼ਨ ਟੋਕਨ ਕੰਢੇ ਡੋਮੇਨ ਨਾਲ ਜੁੜੇ ਹਨ।

ਇੱਕ ਲੁੱਕਅੱਪ, ਕਦਮ-ਬ-ਕਦਮ (ਉੱਚ-ਸਤਹ)

1. ਤੁਹਾਡਾ ਡਿਵਾਈਸ ਆਪਣੇ ਕੰਫਿਗਰ ਕੀਤੇ recursive resolver ਨੂੰ example.com ਲਈ ਪੁੱਛਦਾ ਹੈ।
2. ਜੇ resolver ਕੋਲ ਤਾਜ਼ਾ ਕੈਸ਼ ਕੀਤਾ ਜਵਾਬ ਹੈ, ਤਾਂ ਇਹ ਤੁਰੰਤ ਜਵਾਬ ਦੇ ਦਿੰਦਾ ਹੈ।
3. ਨਹੀਂ ਤਾਂ, resolver DNS ਹਾਇਰਾਰਕੀ ਨੂੰ ਪੁੱਛਦਾ ਹੈ ਕਿ उस ਡੋਮੇਨ ਦੇ authoritative servers ਕਿੱਥੇ ਹਨ (ਉਪਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ ਅਤੇ ਧੀਰੇ-ਧੀਰੇ ਨਜ਼ਦੀਕ ਹੁੰਦਾ)।
4. Resolver ਡੋਮੇਨ ਦੇ authoritative server ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਆਖ਼ਰੀ ਜਵਾਬ ਲੈ ਕੇ ਤੁਹਾਡੇ ਡਿਵਾਈਸ ਨੂੰ ਵਾਪਸ ਭੇਜਦਾ ਹੈ।
5. ਤੁਹਾਡਾ ਬਰਾਊਜ਼ਰ ਉਸ IP ਪਤੇ ਉੱਤੇ ਕਨੈਕਟ ਕਰਦਾ ਹੈ।

"Recursive" vs "authoritative" ਇਕ ਉਦਾਹਰਣ ਵਿੱਚ

ਸੋਚੋ recursive resolver ਇੱਕ ਲਾਇਬ੍ਰੇਰਿਅਨ ਵਾਂਗ ਹੈ ਜੋ ਤੁਹਾਡੇ ਲਈ ਚੀਜ਼ਾਂ ਲੱਭ ਸਕਦਾ (ਅਤੇ ਲੋਕਾਂ ਲਈ ਮਸ਼ਹੂਰ ਜਵਾਬ ਯਾਦ ਰੱਖਦਾ) ਹੈ, ਜਦਕਿ ਇੱਕ authoritative server ਪ੍ਰਕਾਸ਼ਕ ਦੀ ਅਧਿਕਾਰਿਕ ਸੂਚੀ ਹੈ: ਇਹ ਹੋਰ ਕੈਟਾਲੌਗਾਂ ਨੂੰ ਨਹੀਂ ਦੇਖਦਾ—ਬੱਸ ਆਪਣੇ ਕਿਤਾਬਾਂ ਲਈ ਜੋ ਸੱਚ ਹੈ ਉਹ ਕਹਿੰਦਾ ਹੈ।

ਇੱਕ DNS ਲੁੱਕਅੱਪ, ਕਦਮ-ਦਰ-ਕਦਮ (ਬਿਨਾਂ ਜਾਰਗਨ)

ਜਦ ਤੁਸੀਂ example.com ਆਪਣੇ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਟਾਈਪ ਕਰਦੇ ਹੋ, ਤੁਹਾਡਾ ਬਰਾਊਜ਼ਰ ਅਸਲ ਵਿੱਚ ਨਾਮ ਨਹੀਂ ਲੱਭ ਰਿਹਾ—ਉਸਨੂੰ ਇੱਕ IP ਪਤੇ (ਨੰਬਰ ਜਿਵੇਂ 93.184.216.34) ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਉਹ ਜਾਣੇ ਕਿ ਕਿੱਥੇ ਕਨੈਕਟ ਕਰਨਾ ਹੈ। DNS ਉਹ "ਮੇਨੂੰ ਇਸ ਨਾਮ ਲਈ ਨੰਬਰ ਲੱਭੋ" ਸਿਸਟਮ ਹੈ।

1) ਬਰਾਊਜ਼ਰ ਓਐਸ ਨੂੰ ਪੁੱਛਦਾ ਹੈ

ਤੁਹਾਡਾ ਬਰਾਊਜ਼ਰ ਪਹਿਲਾਂ ਤੁਹਾਡੇ ਕੰਪਿਊਟਰ/ਫੋਨ ਦੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਪੁੱਛਦਾ ਹੈ: "ਕੀ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ example.com ਲਈ IP ਪਤਾ ਜਾਣਦੇ ਹਾਂ?" ਓਐਸ ਆਪਣੀ ਛੋਟੀ-ਮਿਆਦੀ ਯਾਦ (cache) ਚੈੱਕ ਕਰਦਾ। ਜੇ ਤਾਜ਼ਾ ਜਵਾਬ ਮਿਲ ਜਾਂਦਾ, ਤਾਂ ਲੁੱਕਅੱਪ ਇੱਥੇ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।

2) ਓਐਸ ਇੱਕ DNS resolver ਨੂੰ ਪੁੱਛਦਾ ਹੈ

ਜੇ ਓਐਸ ਕੋਲ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ DNS resolver ਨੂੰ ਸਵਾਲ ਭੇਜਦਾ—ਅਕਸਰ ਤੁਹਾਡੇ ISP, ਤੁਹਾਡੇ ਕੰਪਨੀ ਜਾਂ ਇੱਕ ਪਬਲਿਕ ਪ੍ਰਦਾਤਾ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ। resolver ਤੁਹਾਡੇ "DNS concierge" ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ: ਉਹ ਮਿਹਨਤ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਡਾ ডਿਵਾਈਸ ਕਰਕੇ ਨਾ ਹੋਵੇ।

3) Resolver ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ: root → TLD → authoritative

ਜੇ resolver ਕੋਲ ਜਵਾਬ ਕੈਸ਼ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਮਾਰਗ-ਦਰਸ਼ਨ ਨੁਸਖਾ ਅਨੁਸਰਦਾ ਹੈ:

• Root server: resolver ਪੁੱਛਦਾ ਹੈ ਕਿ ਡੋਮੇਨ ਅੰਤ (ਜਿਵੇਂ .com) ਲਈ ਜਾਣਕਾਰੀ ਕਿੱਥੇ ਮਿਲੇਗੀ। root server ਆਖ਼ਰੀ IP ਨਹੀਂ ਦਿੰਦਾ—ਇਹ referrals ਦਿੰਦਾ ਹੈ: "ਆਗੇ ਇਹ .com ਸਰਵਰ ਪੁੱਛੋ।"
• TLD server (.com): resolver .com ਸਰਵਰਾਂ ਨੂੰ ਪੁੱਛਦਾ ਹੈ ਕਿ example.com ਕਿੱਥੇ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ। ਫਿਰ ਵੀ, ਇਹ ਆਖ਼ਰੀ IP ਨਹੀਂ ਦਿੰਦਾ—ਹੋਰ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼: "ਇਸ authoritative server ਨੂੰ ਪੁੱਛੋ।"
• Authoritative server: ਇਹ ਉਸ ਡੋਮੇਨ ਲਈ ਸੱਚ ਦਾ ਸਰੋਤ ਹੁੰਦਾ ਹੈ। ਇਹ ਆਖ਼ਰੀ ਜਵਾਬ ਭੇਜਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, A ਜਾਂ AAAA ਰਿਕਾਰਡ) ਜਿਸ ਵਿੱਚ IP ਪਤਾ ਹੁੰਦਾ ਹੈ।

4) ਜਵਾਬ ਵਾਪਸ ਆਉਂਦਾ ਹੈ (ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ)

resolver IP ਵਾਪਸ ਤੁਹਾਡੇ ਓਐਸ ਨੂੰ ਭੇਜਦਾ ਹੈ, ਫਿਰ ਤੁਹਾਡਾ ਬਰਾਊਜ਼ਰ ਉਸ IP ਨਾਲ ਕਨੈਕਟ ਕਰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਲੁੱਕਅਪ ਝਟ ਤੋਂ ਲੱਗਦੇ ਹਨ ਕਿਉਂਕਿ resolvers ਅਤੇ ਡਿਵਾਈਸ TTL ਦੁਆਰਾ ਨਿਰਧਾਰਿਤ ਸਮੇਂ ਲਈ ਜਵਾਬਾਂ ਨੂੰ ਕੈਸ਼ ਕਰਦੇ ਹਨ।

ਇੱਕ ਆਸਾਨ ਮਾਨਸਿਕ ਮਾਡਲ

ਇੱਕ ਸਧਾਰਣ ਫਲੋ ਯਾਦ ਰੱਖਣ ਲਈ ਹੈ: Browser → OS cache → Resolver cache → Root (referral) → TLD (referral) → Authoritative (answer) → back to Browser।

ਕੈਸ਼ਿੰਗ ਅਤੇ TTL: DNS ਤੇਜ਼ ਕਿਉਂ ਹੈ (ਅਤੇ ਕਦੇ ਕਦੇ ਬਦਲਾਅ ਹੌਲੇ ਕਿਉਂ ਫੈਲਦੇ ਹਨ)

ਜੇ ਹਰ ਵਾਰੀ ਵੈੱਬਸਾਈਟ ਤੇ ਜਾਣ ਲਈ DNS ਨੂੰ ਨਵਾਂ-ਨਵਾਂ ਸ਼ੁਰੂ ਤੋਂ ਪੁੱਛਣਾ ਪੈਂਦਾ, ਤਾਂ ਇਹ ਚਿੰਨ੍ਹਤ ਕਰਨ ਵਾਲਾ ਹੋ ਜਾਂਦਾ। ਇਸਦੀ ਥਾਂ, DNS ਕੈਸ਼ਿੰਗ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ—ਹਾਲੀਆ ਲੁੱਕਅਪ ਦੀ ਅਸਥਾਈ "ਯਾਦ"—ਤਾਂ ਜੋ ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਮਿਲਣ ਵਾਲੇ ਉੱਤਰ ਮਿਲੀਸੈਕਿੰਡਾਂ ਵਿੱਚ ਮਿਲ ਸਕਣ।

ਕੈਸ਼ਿੰਗ ਕੀ ਹੈ (ਅਤੇ ਕਿਉਂ ਮੌਜੂਦ ਹੈ)

ਜਦ ਤੁਸੀਂ example.com ਲਈ ਇੱਕ DNS resolver ਨੂੰ ਪੁੱਛਦੇ ਹੋ, ਪਹਿਲੀ ਵਾਰ resolver ਨੂੰ ਕੁਝ ਕੰਮ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਇਕ ਵਾਰੀ ਜਦ ਇਹ ਜਵਾਬ ਸਿੱਖ ਲੈਂਦਾ ਹੈ, ਇਹ ਉਸਨੂੰ ਕੈਸ਼ ਕਰ ਲੈਂਦਾ ਹੈ। ਅਗਲਾ ਵਿਅਕਤੀ ਜੋ ਉਹੀ ਨਾਮ ਪੁੱਛੇਗਾ, ਤੁਰੰਤ ਜਵਾਬ ਮਿਲ ਸਕਦਾ ਹੈ।

ਕੈਸ਼ਿੰਗ ਦੋ ਕਾਰਨਾਂ ਲਈ ਹੈ:

• ਗਤੀ: ਘੱਟ ਨੈੱਟਵਰਕ ਰਾਊਂਡ-ਟ੍ਰਿਪ, ਤੇਜ਼ ਪੇਜ਼ ਲੋਡ।
• ਲੋਡ ਘਟਾਉਣਾ: authoritative DNS ਸਰਵਰਾਂ ਨੂੰ ਹਰ ਇੱਕ ਯੂਜ਼ਰ ਦੀ ਹਰ ਇੱਕ ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇਣਾ ਪੈਂਦਾ।

TTL: "ਇਸ ਉੱਤਰ ਨੂੰ ਕਿੰਨੇ ਸਮੇਂ ਲਈ ਰੱਖਣਾ ਹੈ"

ਹਰੇਕ DNS ਰਿਕਾਰਡ ਇੱਕ TTL (Time To Live) ਮੁੱਲ ਨਾਲ ਸਰਵ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। TTL ਨੂੰ ਤੁਸੀਂ ਇਸ ਨਿਰਦੇਸ਼ ਵਜੋਂ ਸੋਚੋ: ਇਸ ਜਵਾਬ ਨੂੰ X ਸਕਿੰਟ ਲਈ ਰੱਖੋ, ਫਿਰ ਮੁੜ ਜਾਣਚ ਕਰੋ।

ਜੇ ਕਿਸੇ ਰਿਕਾਰਡ ਦੀ TTL 300 ਹੈ, ਤਾਂ resolvers ਉਸਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ 5 ਮਿੰਟ ਲਈ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੇ ਹਨ ਪੂਨ: ਚੈੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।

ਵਪਾਰ-ਅਸੀਂਮ: ਬਦਲਾਅ vs. ਸਥਿਰਤਾ

TTL ਇੱਕ ਸੰਤੁਲਨ ਹੈ:

• ਛੋਟੀ TTLs ਬਦਲਾਅ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਾਉਣ 'ਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ (ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌਰਾਨ ਉਪਯੋਗੀ), ਪਰ DNS ਕੁਏਰੀਆਂ ਦੀ ਸੰਖਿਆ ਵਧ ਜਾਂਦੀ ਹੈ।
• ਲੰਮੀ TTLs ਕੁਏਰੀ ਟ੍ਰੈਫਿਕ ਘਟਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਚੀਜ਼ਾਂ ਨੂੰ ਜ਼ਿਆਦਾ ਸਥਿਰ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਪਰ ਬਦਲਾਅ ਹਰ ਥਾਂ ਤਕ ਪਹੁੰਚਣ ਲਈ ਵੱਧ ਸਮਾਂ ਲੈਂਦੇ ਹਨ।

ਅਸਲ ਹਾਲਤਾਂ ਜਿੱਥੇ TTL ਮੈਟਰ ਕਰਦਾ ਹੈ

ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਵੈੱਬਸਾਈਟ ਨੂੰ ਨਵੇਂ ਹੋਸਟ 'ਤੇ ਮੂਵ ਕਰ ਰਹੇ ਹੋ, CDN ਬਦਲ ਰਹੇ ਹੋ, ਜਾਂ ਈਮੇਲ ਕਟਓਵਰ (MX ਰਿਕਾਰਡ ਬਦਲਣਾ) ਕਰ ਰਹੇ ਹੋ, TTL ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਕਿਵੇਂ ਤੇਜ਼ੀ ਨਾਲ ਪੁਰਾਣੀ ਥਾਂ ਤੋਂ ਨਵੀਂ ਥਾਂ ਵੱਲ ਨਹੀਂ ਜਾਵੇਂਗੇ।

ਆਮ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ পরিকল্পਿਤ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ TTL ਘੱਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਬਦਲਾਅ ਕਰਕੇ, ਸਭ ਕੁਝ ਠੀਕ ਹੋ ਜਾਣ 'ਤੇ TTL ਨੂੰ ਦੁਬਾਰਾ ਵੱਧ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸੀ ਲਈ DNS ਰੋਜ਼ਾਨਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਕਦੇ ਕਦੇ ਅਪਡੇਟ ਤੋਂ ਬਾਅਦ "ਜ਼ਿਦੀ" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।

ਉਹ DNS ਰਿਕਾਰਡ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਵੇਖੋਗੇ (A, AAAA, CNAME, MX, TXT)

ਜਦ ਤੁਸੀਂ ਕਿਸੇ DNS ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਲੌਗਿਨ ਕਰਦੇ ਹੋ, ਅਕਸਰ ਤੁਸੀਂ ਕੁਝ ਹੀ ਰਿਕਾਰਡ ਕਿਸਮਾਂ ਨੂੰ ਐਡ/ਐਡਿਟ/ਹਟਾਉਂਦੇ ਹੋ। ਹਰ ਰਿਕਾਰਡ ਇੱਕ ਛੋਟੀ ਹਦਾਇਤ ਹੁੰਦੀ ਹੈ ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਇੰਟਰਨੈੱਟ ਕਿਸੇ ਨਾਮ ਨੂੰ ਕਿੱਥੇ ਭੇਜੇ (ਵੈੱਬ), ਈਮੇਲ ਕਿੱਥੇ ਡਿਲਿਵਰ ਕੀਤੀ ਜਾਵੇ, ਜਾਂ ਮਾਲਕੀ ਕਿਵੇਂ ਵੈਰੀਫਾਈ ਕੀਤੀ ਜਾਵੇ।

ਆਮ ਰਿਕਾਰਡ ਕਿਸਮਾਂ (ਰੋਜ਼ਾਨਾ ਉਦਾਹਰਣਾਂ ਨਾਲ)

ਲੋਕ ਜਿਹੜੀਆਂ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ

ਕੁਝ DNS ਗਲਤੀਆਂ ਵਾਰ-ਵਾਰ ਵੇਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ:

• Apex ਤੇ CNAME ਰੱਖਣਾ (example.com). ਬਹੁਤ ਸਾਰੇ DNS ਪ੍ਰਦਾਤਾ ਇਸਨੂੰ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੇ ਕਿਉਂਕਿ ਰੂਟ ਨਾਮ ਨੂੰ NS ਅਤੇ SOA ਵਰਗੇ ਰਿਕਾਰਡ ਵੀ ਨਿਭਾਉਣੇ ਪੈਂਦੇ ਹਨ। ਜੇ ਤੁਹਾਨੂੰ "root ਨੂੰ ਕਿਸੇ hostname ਵੱਲ" ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ A/AAAA ਰਿਕਾਰਡ ਵਰਤੋ ਜਾਂ ALIAS/ANAME ਫੀਚਰ ਜੇ ਤੁਹਾਡਾ ਪ੍ਰਦਾਤਾ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ।
• ਟਕਰਾਉਂਦੇ ਰਿਕਾਰਡ: ਇੱਕੋ hostname (ਜਿਵੇਂ www) 'ਤੇ ਇਕੋ ਸਮੇਂ CNAME ਅਤੇ A ਦੋਹਾਂ ਨਾ ਰੱਖੋ। ਇੱਕ ਰਣਨੀਤੀ ਚੁਣੋ।
• ਟਾਈਪੋ ਅਤੇ ਫਾਰਮੈਟਿੰਗ ਗਲਤੀਆਂ: mail.provider.com ਵਿੱਚ ਇੱਕ ਗਲਤ ਅੱਖਰ ਈਮੇਲ ਨੂੰ ਬਰਬਾਦ ਕਰ ਸਕਦਾ ਹੈ; ਘੱਟ/ਵੱਧ ਡਾਟ/ਰਹਿਤ ਫੀਲਡਾਂ ਅਤੇ ਗਲਤ ਹੋਸਟ ਫੀਲਡ (ਜਿਵੇਂ @ vs www) ਆਮ ਕਾਰਨ ਹਨ।

ਜੇ ਤੁਸੀਂ ਟੀਮ ਨਾਲ DNS ਨਿਰਦੇਸ਼ ਸਾਂਝਾ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਆਪਣੀਆਂ ਡੌਕਸ (ਜਾਂ ਰਨਬੁੱਕ) ਵਿੱਚ ਉਪਰ ਦਿੱਤੀ ਸਧਾਰਨ ਟੇਬਲ ਰਿਵਿਊ ਅਤੇ ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਤੇਜ਼ ਬਣਾ ਦਿੰਦੀ ਹੈ।

ਕੌਣ DNS ਚਲਾਉਂਦਾ ਹੈ: ਡੋਮੇਨ, ਰਜਿਸਟ੍ਰਾਰ, ਅਤੇ ਰੂਟ ਸਰਵਰ

DNS ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿੰਮੇਵਾਰੀ ਕਈ ਸੰਸਥਾਵਾਂ 'ਚ ਵੰਡੱੀ ਹੋਈ ਹੈ। ਇਹ ਵੰਡ ਇਹ ਵੀ ਯਕੀਨੀ ਬਣਾਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਪ੍ਰਦਾਤਾ ਬਦਲ ਸਕਦੇ ਹੋ, ਸੈਟਿੰਗਾਂ ਬਦਲ ਸਕਦੇ ਹੋ, ਅਤੇ ਬਿਨਾਂ "ਇੰਟਰਨੈੱਟ" ਤੋਂ ਇਜਾਜ਼ਤ ਮੰਗੇ ਆਪਣਾ ਨਾਮ ਬਣਾਈ ਰੱਖ ਸਕਦੇ ਹੋ।

ਡੋਮੇਨ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਅਤੇ DNS ਹੋਸਟਿੰਗ (ਇਹ ਇਕੋ ਚੀਜ਼ ਨਹੀਂ)

ਡੋਮੇਨ ਰਜਿਸਟਰ ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ ਇੱਕ ਨਾਮ (ਜਿਵੇਂ example.com) ਨੂੰ ਇੱਕ ਨਿੱਜੀ ਸਮੇਂ-ਅਵਧੀ ਲਈ ਖਰੀਦਣਾ। ਇਹ ਲੇਬਲ ਰਿਜ਼ਰਵ ਕਰਨ ਵਰਗਾ ਹੈ ਤਾਂ ਕਿ ਕੋਈ ਹੋਰ ਇਸਨੂੰ ਦਾਅਵਾ ਨਾ ਕਰ ਸਕੇ।

DNS ਹੋਸਟਿੰਗ ਉਹ ਹੁੰਦੀ ਹੈ ਜੋ ਦੁਨੀਆ ਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਉਹ ਨਾਮ ਕਿੱਤੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ—ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ, ਈਮੇਲ ਪ੍ਰਦਾਤਾ, ਵੈਰੀਫਿਕੇਸ਼ਨ ਰਿਕਾਰਡ ਆਦਿ। ਤੁਸੀਂ ਇਕ ਕੰਪਨੀ ਤੋਂ ਡੋਮੇਨ ਰਜਿਸਟਰ ਕਰਵਾ ਕੇ DNS ਕਿਸੇ ਹੋਰ ਕੋਲ ਹੋਸਟ ਕਰ ਸਕਦੇ ਹੋ।

ਰਜਿਸਟਰੀ, ਰਜਿਸਟਰ, ਅਤੇ ਨਾਂ ਸਰਵਰ—ਸਧੀ ਭਾਸ਼ਾ ਵਿੱਚ ਭੂਮਿਕਾਵਾਂ

• Registry: ਉਹ ਸੰਸਥਾ ਜੋ ਇੱਕ top-level domain (TLD) ਜਿਵੇਂ .com, .org, ਜਾਂ .uk ਚਲਾਉਂਦੀ ਹੈ। ਇਹ ਹਰ TLD ਹੇਠਾਂ ਆਉਣ ਵਾਲੇ ਨਾਮਾਂ ਦੀ ਅਧਿਕਾਰਿਕ ਡੇਟਾਬੇਸ ਅਤੇ ਕਿਸ name servers ਨੇ ਜ਼ਿੰਮੇਵਾਰ ਹਨ ਉਹ ਰੱਖਦੀ ਹੈ।
• Registrar: ਰੀਟੇਲਰ ਜੋ ਤੁਸੀਂ ਡੋਮੇਨ ਰਜਿਸਟਰ/ਨਵੀਨੀਕਰਨ ਲਈ ਵਰਤਦੇ ਹੋ। Registrar registry ਨਾਲ ਤੁਹਾਡੀ ਝਾਂਝੜੀ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਮੁੱਖ ਡੋਮੇਨ ਸੈਟਿੰਗਾਂ ਸੋਧਣ ਦਿੰਦਾ ਹੈ।
• Name servers: ਮਸ਼ੀਨਾਂ (ਤੁਹਾਡੇ DNS host ਦੁਆਰਾ ਚਲਾਈਆਂ ਜਾਂਦੀਆਂ) ਜੋ ਤੁਹਾਡੇ ਡੋਮੇਨ ਦੇ DNS ਰਿਕਾਰਡ (A/AAAA, MX, TXT, CNAME ਆਦਿ) ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ—ਇਹਨਾਂ ਨੂੰ authoritative ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡੇ ਡੋਮੇਨ ਲਈ ਅੰਤਿਮ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ।

ਰੂਟ ਸਰਵਰ ਕੀ ਕਰਦੇ ਹਨ (ਅਤੇ ਕੀ ਨਹੀਂ)

ਰੂਟ ਸਰਵਰ DNS ਦੇ ਸਿਖਰ ਤੇ ਬੈਠੇ ਹੁੰਦੇ ਹਨ। ਉਹ ਤੁਹਾਡੇ ਵੈੱਬਸਾਈਟ ਦਾ IP ਪਤਾ ਨਹੀਂ ਜਾਣਦੇ ਅਤੇ ਉਹ ਤੁਹਾਡੇ ਡੋਮੇਨ ਦੇ ਰਿਕਾਰਡ ਨਹੀਂ ਸਟੋਰ ਕਰਦੇ। ਉਹਨਾਂ ਦਾ ਕੰਮ ਤੰਗ ਹੈ: ਉਹ resolvers ਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਹਰ TLD ਕਿੱਥੇ ਹੈ (ਜਿਵੇਂ .com ਕਿੱਥੇ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ)।

Delegation: ਨਿਯੰਤਰਣ ਕਿਵੇਂ TLD ਤੋਂ ਤੁਹਾਡੇ ਡੋਮੇਨ ਨੂੰ ਚਲੇ

ਜਦ ਤੁਸੀਂ registrar 'ਤੇ ਆਪਣਾ ਡੋਮੇਨ ਲਈ "name servers" ਸੈੱਟ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਇੱਕ delegation ਬਣਾਉਂਦੇ ਹੋ। .com registry (ਆਪਣੇ authoritative servers ਰਾਹੀਂ) ਫਿਰ example.com ਲਈ ਪੁੱਛਤાચ ਨੂੰ ਉਹ name servers ਵੱਲ ਰੂਟ ਕਰ ਦੇਵੇਗਾ।

ਉਸ ਸਮੇਂ ਤੋਂ, ਉਹ name servers ਬਾਕੀ ਇੰਟਰਨੈੱਟ ਨੂੰ ਦਿੱਤੇ ਜਾਣ ਵਾਲੇ ਉੱਤਰਾਂ 'ਤੇ ਕਾਬੂ ਰੱਖਦੇ ਹਨ—ਜਦ ਤੱਕ ਤੁਸੀਂ ਦੁਬਾਰਾ delegation ਨਹੀਂ ਬਦਲਦੇ।

ਸੁਰੱਖਿਆ ਅਤੇ ਭਰੋਸਾ: ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ DNS ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ

DNS ਭਰੋਸੇ ਉੱਤੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ: ਜਦ ਤੁਸੀਂ ਇੱਕ ਨਾਮ ਟਾਈਪ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਮੰਨਦੇ ਹੋ ਕਿ ਜਵਾਬ ਅਸਲੀ ਸੇਵਾ ਵੱਲ ਹੀ ਲੈ ਕੇ ਗਿਆ। ਬਹੁਤ ਵਾਰ ਇਹ ਸੱਚ ਹੁੰਦਾ ਹੈ—ਪਰ DNS ਹਮਲਾ ਕਰਨ ਲਈ ਇੱਕ ਮਸ਼ਹੂਰ ਥਾਂ ਵੀ ਹੈ, ਕਿਉਂਕਿ "ਇਸ ਨਾਮ ਨੂੰ ਕਿੱਥੇ ਭੇਜੋ" ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਬਹੁਤ ਸਾਰਿਆਂ ਨੂੰ ਗਲਤ ਥਾਂ ਭੇਜ ਸਕਦਾ ਹੈ।

ਆਮ DNS ਖਤਰੇ (ਅਤੇ ਇਹ ਕਿਵੇਂ ਦਿਸਦੇ ਹਨ)

ਇੱਕ ਆਮ ਸਮੱਸਿਆ spoofing ਜਾਂ cache poisoning ਹੈ। ਜੇ ਕੋਈ ਹਮਲਾਕਾਰ resolver ਨੂੰ ਇੱਕ ਝੂਠਾ ਜਵਾਬ ਸਟੋਰ ਕਰਵਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਯੂਜ਼ਰ ਗਲਤ IP 'ਤੇ ਭੇਜੇ ਜਾ ਸਕਦੇ ਹਨ ਭਾਵੇਂ ਉਹ ਸਹੀ ਡੋਮੇਨ ਲਿਖਿਆ ਹੋਵੇ। ਨਤੀਜਾ ਫਿਸ਼ਿੰਗ ਪੇਜ਼, ਮਾਲਵੇਅਰ ਡਾਊਨਲੋਡ ਜਾਂ ਟ੍ਰੈਫਿਕ ਦਾ ਇੰਟਰਸੈਪਸ਼ਨ ਹੋ ਸਕਦਾ ਹੈ।

ਹੋਰ ਸਮੱਸਿਆ registrar ਲੈਵਲ ਤੇ ਡੋਮੇਨ ਹਾਈਜੈਕਿੰਗ ਹੈ। ਜੇ ਕੋਈ ਤੁਹਾਡੇ registrar ਖਾਤੇ ਵਿੱਚ ਦਾਖ਼ਲ ਹੋ ਜਾਵੇ, ਉਹ name servers ਜਾਂ DNS ਰਿਕਾਰਡ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ ਬਿਨਾਂ ਹੋਸਟਿੰਗ ਨੂੰ ਛੁਹੇ ਤੁਹਾਡਾ ਡੋਮੇਨ "ਜਿੱਤ" ਸਕਦਾ ਹੈ।

ਫਿਰ ਹੈ ਰੋਜ਼ਾਨਾ ਦਾ ਖ਼ਤਰਾ: ਗਲਤ ਸੰਰਚਨਾ। ਇਕ ਗ਼ਲਤ CNAME, ਇੱਕ ਪੁਰਾਣਾ TXT ਰਿਕਾਰਡ, ਜਾਂ ਇੱਕ ਗਲਤ MX ਰਿਕਾਰਡ ਲੌਗਇਨ ਫਲੋਜ਼, ਈਮੇਲ ਡਿਲਿਵਰੀ, ਜਾਂ ਵੈਰੀਫਿਕੇਸ਼ਨ ਚੈਕ ਤੋੜ ਸਕਦੇ ਹਨ। ਇਹ ਫੇਲ੍ਹ-ਅਕਸਰ ਦਿਸਦੇ ਹਨ ਕਿ "ਇੰਟਰਨੈੱਟ ਡਾਊਨ ਹੈ", ਪਰ ਅਸਲ ਕਾਰਨ ਇੱਕ ਛੋਟਾ DNS ਸੋਧ ਹੋ ਸਕਦਾ ਹੈ।

DNSSEC ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ (ਉੱਚ-ਸਤਹ)

DNSSEC DNS ਡੇਟਾ 'ਤੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਸਾਈਨ ਇੰਨੀਮਾ ਜੋੜਦਾ ਹੈ। ਸਧਾਰਨ ਬੋਲ ਚਾਲ ਵਿੱਚ: DNS ਉੱਤਰ ਨੂੰ ਵੈਰੀਫਾਈ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ताकि ਪਤਾ ਲੱਗੇ ਕਿ ਇਹ ਟਰਾਂਜ਼ਿਟ ਵਿੱਚ ਬਦਲਿਆ ਨਹੀਂ ਗਿਆ ਅਤੇ ਇਹ ਸੱਚਮੁਚ ਡੋਮੇਨ ਦੇ authoritative ਸਰਵਰ ਤੋਂ ਆਇਆ ਹੈ। DNSSEC DNS ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਨਹੀਂ ਲੁੱਕਾਉਂਦਾ ਕਿ ਤੁਸੀਂ ਕੀ ਦੇਖ ਰਹੇ ਹੋ, ਪਰ ਇਹ ਅਕਸਰ ਕਿਸੇ ਭੂਠੇ ਜਵਾਬ ਨੂੰ ਮੰਨਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਪਰਾਈਵੇਸੀ: DoH ਅਤੇ DoT

ਪ੍ਰੰਪਰਾਗਤ DNS ਕਵੇਰੀਆਂ ਨੈੱਟਵਰਕਾਂ ਲਈ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰ ਅੰਦਾਜ਼ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। DNS-over-HTTPS (DoH) ਅਤੇ DNS-over-TLS (DoT) ਤੁਹਾਡੇ ਡਿਵਾਈਸ ਅਤੇ resolver ਦਰਮਿਆਨ ਕਨੈਕਸ਼ਨ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਦੇ ਹਨ, ਸਣੀਪਿੰਗ ਅਤੇ ਕੁਝ ਰਸਤੇ ਵਿੱਚ ਹੋਣ ਵਾਲੇ ਮੈਨੂਪਲੇਸ਼ਨ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। ਇਹ DNS ਨੂੰ "ਗੁਪਤ" ਨਹੀਂ ਬਣਾਉਂਦੇ, ਪਰ ਇਹ ਬਦਲ ਦਿੰਦੇ ਹਨ ਕਿ ਕਿਸ ਨੂੰ ਕਵੇਰੀਆਂ ਦੇਖਣ ਅਤੇ ਬਦਲਣ ਦਾ ਅਧਿਕਾਰ ਹੈ।

ਟੀਮਾਂ ਲਈ ਪ੍ਰਯੋਗਕ ਅਸਫਲਾਂ

• ਆਪਣੇ registrar 'ਤੇ MFA ਲਗਾਓ, ਡੋਮੇਨ/ਟ੍ਰਾਂਸਫਰ ਲੌਕਸ ਯਕੀਨੀ ਬਣਾਓ, ਅਤੇ ਕਿਸ ਨੂੰ DNS ਸੋਧ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ ਉਹ ਸੀਮਿਤ ਕਰੋ।
• DNS ਬਦਲਾਅਾਂ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਡਿਪਲੋਇਮੈਂਟ ਵਾਂਗ ਵਰਤੋਂ: ਰਿਵਿਊ ਦੀ ਮੰਗ ਕਰੋ, ਬਦਲਾਅ ਲੌਗ ਰੱਖੋ, ਅਤੇ ਰਿਕਾਰਡ ਜਾਂ name server ਬਦਲਾਅਾਂ ਲਈ ਮਾਨੀਟਰਿੰਗ/ਅਲਰਟ ਸੈੱਟ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਚਾਨਕ ਬਦਲਾਅਾਂ ਬਾਰੇ ਜਲਦੀ ਜਾਣੋ।

ਟੀਮਾਂ ਲਈ ਪ੍ਰਯੋਗਕ DNS ਸੁਝਾਅ (ਵੈੱਬਸਾਈਟ ਜਾਂ ਈਮੇਲ ਚਲਾਉਂਦੇ ਸਮੇਂ)

DNS ਨੂੰ "ਸੈੱਟ ਅਤੇ ਭੁੱਲ ਜਾਓ" ਵਰਗਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ, ਜਦ ਤੱਕ ਇਕ ਛੋਟੀ ਸੋਧ ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ ਜਾਂ ਈਮੇਲ ਨੂੰ ਠਪ ਨਾ ਕਰ ਦੇ। ਚੰਗੀ ਖਬਰ: ਕੁਝ ਆਦਤਾਂ DNS ਪ੍ਰਬੰਧਨ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਦਿੰਦੀਆਂ ਹਨ—ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ ਵੀ।

ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ ਇੱਕ ਸਧਾਰਣ ਚੈੱਕਲਿਸਟ

ਆਰੰਭ ਕਰੋ ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਜਿਸਨੂੰ ਤੁਸੀਂ ਦੁਹਰਾਉਂ:

• ਇੱਕ ਭਰੋਸੇਯੋਗ DNS ਪ੍ਰਦਾਤਾ ਚੁਣੋ: ਆਸਾਨ UI, ਸਪੱਸ਼ਟ ਚੇਂਜ ਇਤਿਹਾਸ, ਅਤੇ ਆਧੁਨਿਕ ਰਿਕਾਰਡਾਂ ਦੀ ਸਹਾਇਤਾ ਲੱਭੋ (ਟੈਕਸਟ ਲਈ TXT ਆਦਿ). ਜੇ ਤੁਹਾਡਾ ਡੋਮੇਨ ਇੱਕ ਕੰਪਨੀ ਵਿੱਚ ਰਜਿਸਟਰ ਹੈ, ਤਾਂ ਵੀ DNS ਹੋਰ ਥਾਂ ਹੋਸਟ ਕਰਨਾ ਠੀਕ ਹੈ।
• TTL ਰਣਨੀਤੀ ਨਿਰਧਾਰਤ ਕਰੋ: TTL (time to live) ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਹੋਰ ਲੋਕ ਤੁਹਾਡੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਕਿੰਨੇ ਸਮੇਂ ਲਈ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹਨ। ਸਥਿਰ ਸੇਵਾਵਾਂ ਲਈ ਲੰਮੀ TTLs ਵਰਤੋ (ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ), ਅਤੇ ਯੋਜਿਤ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਤੋਂ ਪਹਿਲਾਂ ਅਸਥਾਨਕ ਛੋਟੀ TTLs।
• ਹਰ ਬਦਲਾਅ ਦਾ ਦਸਤਾਵੇਜ਼ ਰੱਖੋ: ਸਾਂਝਾ ਨੋਟ ਰੱਖੋ ਕਿ ਕੀ ਬਦਲਿਆ, ਕਿਉਂ, ਕਦੋਂ, ਅਤੇ ਕਿਸ ਨੇ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ। ਪਿਛਲੇ ਮੁੱਲ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਲਦੀ ਗਲਤੀਆਂ ਵਾਪਸ ਕਰ ਸਕੋ।

ਭਰੋਸੇਯੋਗ ਆਦਤਾਂ ਜੋ “ਰਹੱਸਮਈ ਆਉਟੇਜ” ਰੋਕਦੀਆਂ ਹਨ

ਬਹੁਤ ਸਾਰੇ DNS ਸਮੱਸਿਆਵਾਂ ਮੁਸ਼ਕਿਲ ਨਹੀਂ ਹੁੰਦੀਆਂ—ਸਿਰਫ਼ ਝੱਲਣ ਵਿੱਚ ਕਠਿਨ।

• ਕਈ name servers ਵਰਤੋ: ਤੁਹਾਡਾ DNS ਪ੍ਰਦਾਤਾ ਘੱਟੋ-ਘੱਟ ਦੋ authoritative name servers ਵੱਖ-ਵੱਖ ਥਾਵਾਂ 'ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੇ। ਇਹ ਇਕੱਲੇ ਤੋੜ ਦੀ ਸੰਭਾਵਨਾ ਘਟਾਉਂਦਾ ਹੈ।
• ਆਪਣੇ ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਹਰ ਤੋਂ ਮਾਨੀਟਰ ਕਰੋ: ਬੁਨਿਆਦੀ uptime ਮਾਨੀਟਰਿੰਗ ਜੋ DNS ਰਿਜ਼ੋਲੂਸ਼ਨ (ਸਿਰਫ HTTP ਨਹੀਂ) ਚੈੱਕ ਕਰਦੀ ਹੈ, ਮੁੱਦਿਆਂ ਨੂੰ ਜਲਦੀ ਫੜ ਸਕਦੀ ਹੈ।
• ਰੋਲਬੈਕ ਯੋਜਨਾ ਰੱਖੋ: ਸੋਧ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ zone ਰਿਕਾਰਡਾਂ ਦੀ ਨਕਲ ਕਰੋ। ਕੁਝ ਟੁੱਟੇ ਤਾਂ ਜਾਣ-ਪਛਾਣ ਵਾਲੇ ਮੁੱਲ ਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਨਾਲ ਮਿੰਟਾਂ ਵਿੱਚ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਘੰਟਿਆਂ ਵਿੱਚ ਨਹੀਂ।

ਜੇ ਤੁਸੀਂ ਅਕਸਰ ਐਪ ਡਿਪਲੋਇਮੈਂਟ ਕਰਦੇ ਹੋ, ਤਾਂ DNS ਤੁਹਾਡੇ ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਉਹ ਟੀਮਾਂ ਜੋ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਤੋਂ ਵੈੱਬ ਐਪ ਭੇਜਦੀਆਂ ਹਨ (ਜਿੱਥੇ ਤੁਸੀਂ ਚੈਟ ਰਾਹੀਂ ਐਪ ਬਣਾ ਸਕਦੇ ਹੋ, ਫਿਰ custom domains ਜੁੜ ਸਕਦੇ ਹੋ), ਉਹ ਵੀ ਉਹੀ ਮੂਲ ਸਿਧਾਂਤਾਂ 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੀਆਂ ਹਨ: ਸਹੀ A/AAAA/CNAME ਟਾਰਗੇਟ, katta TTLs ਛੇਤੀ cutovers ਦੌਰਾਨ, ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਵੱਲ ਪਾਇੰਟ ਹੋਵੇ ਤਾਂ ਇੱਕ ਸਾਫ਼ rollback ਰਸਤਾ।

ਈਮੇਲ ਡਿਲਿਵਰੇਬਿਲਟੀ: ਉਹ DNS ਰਿਕਾਰਡ ਜੋ ਮੈਟਰ ਕਰਦੇ ਹਨ

ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਡੋਮੇਨ ਤੋਂ ਈਮੇਲ ਭੇਜਦੇ ਹੋ, DNS ਸਿੱਧਾ ਪ੍ਰਭਾਵ ਪਾਂਦਾ ਹੈ ਕਿ ਸੁਨੇਹੇ ਇਨਬਾਕਸ ਤੱਕ ਪਹੁੰਚਣਗੇ ਕਿ ਨਹੀਂ।

• SPF (TXT record): ਕਿਹੜੇ ਸਰਵਰ ਤੁਹਾਡੇ ਡੋਮੇਨ ਦੀ ਨਾਂ ਤੋਂ ਈਮੇਲ ਭੇਜਣ ਦੀ ਆਗਿਆ ਹਨ।
• DKIM (TXT record): ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਸਾਇਨ ਜੋ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਨ ਦਿੰਦਾ ਹੈ ਕਿ ਸੁਨੇਹਾ ਬਦਲਿਆ ਨਹੀਂ ਗਿਆ।
• DMARC (TXT record): ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਿਆਂ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ SPF/DKIM ਫੇਲ ਹੋਣ 'ਤੇ ਕੀ ਕਰਨਾ ਹੈ (ਅਤੇ ਤੁਹਾਨੂੰ ਰਿਪੋਰਟਿੰਗ ਦਿੰਦਾ ਹੈ)। ਸ਼ੁਰੂ ਵਿੱਚ “ਮੋਨੀਟਰਨਗ” ਨੀਤੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਭਰੋਸਾ ਹੋਣ ਤੇ ਕਸੌਟੀ ਕਠੋਰ ਕਰੋ।

ਮਨੁੱਖ-ਮਿਤ੍ਰੀ ਨਾਮਾਂ ਨੇ ਇੰਟਰਨੈੱਟ ਨੂੰ ਇੱਕ ਛੋਟੀ ਖੋਜ ਭਾਈਚਾਰੇ ਤੋਂ ਬਾਹਰ ਵਧਣ ਯੋਗ ਬਣਾਇਆ। DNS ਨੂੰ ਸਾਂਝੀ ਇੰਫਰਾਸਟਰਕਚਰ ਵਾਂਗ ਮੰਨੋ—ਛੋਟੀ ਧਿਆਨ ਨਾਲ ਤੁਹਾਡੀ ਸਾਈਟ ਪਹੁੰਚਯੋਗ ਰਹੇਗੀ ਅਤੇ ਤੁਹਾਡੀ ਈਮੇਲ ਭਰੋਸੇਮੰਦ ਰਹੇਗੀ ਜਿਵੇਂ ਤੁਸੀਂ ਵਧਦੇ ਹੋ।