1.1.1.1 ਕੌਣ ਚਲਾਉਂਦਾ ਹੈ? ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ DNS ਪਤੇ ਦੀ ਜਾਂਚ
VPN ਨਾਲ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ DNS ਪਤਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਉਹੀ VPN ਚਲਾਉਂਦਾ ਹੋਵੇ। ਰਿਜ਼ੌਲਵਰ ਦੀ ਪਛਾਣ ਕਰੋ, ਫਿਰ ਰਸਤਾ ਅਤੇ ਨਿੱਜੀ ਨਾਵਾਂ ਦੀ ਨੀਤੀ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਜਾਂਚੋ।
ਤੁਸੀਂ 1.1.1.1 ਨੂੰ VPN ਦੇ DNS ਖੇਤਰ ਵਿੱਚ ਪੇਸਟ ਕੀਤਾ, ਸਫ਼ਾ ਲੋਡ ਹੋਇਆ, ਅਤੇ ਟਿਊਟੋਰਿਅਲ ਹੁਣ ਪੁਸ਼ਟ ਦਿਸਦਾ ਹੈ। ਇਹ ਨਿਰੀਖਣ ਮਹਿਸੂਸ ਹੋਣ ਨਾਲੋਂ ਸੰਧਰਾ ਹੈ: ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕੀਤਾ, ਅਤੇ ਬਦਲਾਅ ਅਜੇ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਸਵਾਲ ਦਾ ਜਵਾਬ ਕਿਸ ਨੇ ਦਿੱਤਾ ਜਾਂ ਪੁਰਾਣਾ ਪ੍ਰਬੰਧ ਕਿਉਂ ਫੇਲ੍ਹ ਹੋਇਆ। ਨਕਲ ਕੀਤਾ ਟਿਊਟੋਰਿਅਲ ਅਕਸਰ ਜਾਣੇ-ਪਛਾਣੇ ਜਨਤਕ ਪਤੇ ਨੂੰ “VPN ਦਾ DNS” ਕਹਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਮਾਲਕੀਅਤ ਦਾ ਦਾਅਵਾ ਹੈ, ਪਹੁੰਚ ਦਾ ਨਹੀਂ। ਪਤਾ ਕੀ ਦਰਸਾਉਂਦਾ ਹੈ ਇਹ ਜਾਂਚਣ ਵਿੱਚ ਪੰਜ ਮਿੰਟ ਲੱਗਦੇ ਹਨ ਅਤੇ ਗਲਤ ਕਾਰਨ ਨਾਲ ਕੀਤਾ ਸਥਾਈ ਬਦਲਾਅ ਰੁਕ ਜਾਂਦਾ ਹੈ।
ਕੰਮ ਕਰਦੀ ਸੈਟਿੰਗ ਪਛਾਣ ਨਹੀਂ ਹੁੰਦੀ
ਸੈਟਿੰਗ ਖੇਤਰ ਦਾ ਪਤਾ ਇੱਕ ਅੰਤ ਬਿੰਦੂ ਹੈ, ਅਤੇ ਅੰਤ ਬਿੰਦੂ ਦਾ ਇੱਕ ਸੰਚਾਲਕ ਹੁੰਦਾ ਹੈ। ਇਹ ਦੋ ਤੱਥ ਵੱਖਰੇ ਹਨ, ਅਤੇ ਦੂਜਾ ਉਹ ਹੈ ਜਿਸ ਨੂੰ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਸਭ ਤੋਂ ਵੱਧ ਨਕਲ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਜੋੜੀ ਲਈ ਜਵਾਬ ਜਨਤਕ ਹੈ: Cloudflare 1.1.1.1 ਅਤੇ 1.0.0.1 ਨੂੰ ਆਪਣੇ ਰਿਜ਼ੌਲਵਰ ਪਤਿਆਂ ਵਜੋਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਅਧਿਕਾਰਤ ਪਤਾ ਹਵਾਲੇ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ ਸੰਚਾਲਕ ਦਾ ਨਾਮ ਪਤੇ ਦੇ ਕੋਲ ਹੁੰਦਾ ਹੈ, ਵੱਖਰੇ ਟਿਊਟੋਰਿਅਲ ਵਿੱਚ ਨਹੀਂ।
ਟਨਲ ਚਾਲੂ ਹੋਣ ਵੇਲੇ ਉਹ ਜੋੜੀ ਦਰਜ ਕਰਨਾ VPN ਕੰਪਨੀ ਨੂੰ ਉਸ ਦਾ ਸੰਚਾਲਕ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਅਤੇ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਨਾਮ ਰਹਿਤ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਸਵਾਲ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਤੋਂ ਪਤਾ-ਸੀਮਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਵਾਲੀ ਕੰਪਨੀ ਵੱਲ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਕੰਪਨੀ ਸਤਿਕਾਰਤ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਉਹ ਧਿਰ ਨਾ ਹੋਵੇ ਜਿਸ ਦੀ ਟਿਊਟੋਰਿਅਲ ਨੇ ਸੰਕੇਤ ਕੀਤਾ। ਹਦਾਇਤਾਂ ਦਾ ਲੇਬਲ ਅਤੇ ਅਸਲੀਅਤ ਦਾ ਸੰਚਾਲਕ ਦੋ ਵੱਖਰੇ ਦਾਅਵੇ ਹਨ। ਕੋਈ ਵੀ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਵਿਚਕਾਰਲਾ ਨੈੱਟਵਰਕ ਰਸਤਾ ਕੌਣ ਚਲਾਉਂਦਾ ਹੈ।
ਪਤਾ-ਜੋੜੀ ਜਾਂ ਐਨਕ੍ਰਿਪਟਡ ਅੰਤ ਬਿੰਦੂ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਰਿਜ਼ੌਲਵਰ ਦੇ ਆਪਣੇ ਪ੍ਰਕਾਸ਼ਿਤ ਹਵਾਲੇ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਕਿਸੇ ਹੋਰ ਸਪਲਾਇਰ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਜਾਇਜ਼ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ “ਦੁਆਰਾ ਸਿਫ਼ਾਰਸ਼ ਕੀਤਾ”, “ਰਾਹੀਂ ਪਹੁੰਚਿਆ” ਅਤੇ “ਦੁਆਰਾ ਸੰਚਾਲਿਤ” ਅਜੇ ਵੀ ਤਿੰਨ ਵੱਖਰੇ ਸਬੰਧ ਦੱਸਦੇ ਹਨ।
ਰਿਕਾਰਡ ਨੂੰ ਜਿਨ੍ਹਾਂ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਹੈ, ਉਹਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ
ਸਮੀਖਿਆ ਲਈ ਤਿਆਰ ਰਿਕਾਰਡ ਤਿੰਨ ਸਵਾਲ ਵੱਖ ਕਰਦਾ ਹੈ: ਸਵਾਲ ਕਿਸ ਨੂੰ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਦਾਨ-ਪ੍ਰਦਾਨ ਸਾਦਾ ਹੈ ਜਾਂ ਐਨਕ੍ਰਿਪਟਡ, ਅਤੇ ਕਿਹੜਾ ਰਸਤਾ ਇਸ ਨੂੰ ਢੋਵੇਗਾ। ਸਪਲਾਇਰ ਦਾ ਨਾਮ ਦੂਜਾ ਜਾਂ ਤੀਜਾ ਨਹੀਂ ਭਰ ਸਕਦਾ, ਅਤੇ ਦੇਸ਼ ਦਾ ਲੇਬਲ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਹੀਂ ਭਰ ਸਕਦਾ। ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨੇ ਐਂਟਰੀਆਂ ਲਿਖੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਉਹ ਐਂਟਰੀਆਂ ਬਦਲੀਆਂ ਨਹੀਂ ਜਾ ਸਕਦੀਆਂ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਮੰਨਣਾ ਉਹ ਰਾਹ ਹੈ ਜਿਸ ਰਾਹੀਂ ਅਨੁਮਾਨ ਦਸਤਾਵੇਜ਼ ਬਣ ਜਾਂਦਾ ਹੈ।
ਤੁਲਨਾ ਹੀ ਕੰਮ ਕਰਦੀ ਸੈਟਿੰਗ ਨੂੰ ਦਰਜ ਕੀਤੇ ਫ਼ੈਸਲੇ ਵਿੱਚ ਬਦਲਦੀ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਕਾਰਨ ਦੇ ਪਤਾ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦਾ ਹੈ। ਪਹਿਲਾਂ ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਦਾ ਤੀਜਾ ਕਾਲਮ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਉੱਥੇ ਹੀ ਬਹੁਤੀਆਂ ਭਰੋਸੇਵਾਨ ਵਿਆਖਿਆਵਾਂ ਅਸਲ ਵਿੱਚ ਰੁਕਦੀਆਂ ਹਨ।
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
ਸਾਰਣੀ ਜਾਣ-ਬੁੱਝ ਕੇ ਛੋਟੀ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ ਐਂਟਰੀ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਕੋਈ ਇੱਕ ਖੇਤਰ ਤਿੰਨੇ ਨਹੀਂ ਭਰਦਾ।
ਸਥਾਨਕ ਫਾਰਵਰਡਰ ਅਸਲ ਸਰੋਤ ਲੁਕਾਉਂਦਾ ਹੈ
ਜੋ ਡਿਵਾਈਸ ਆਪਣੇ ਰਾਊਟਰ ਨੂੰ DNS ਵਜੋਂ ਵਰਤਣ ਲਈ ਸੈੱਟ ਹੈ, ਉਹ ਫਾਰਵਰਡਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਰਿਹਾ ਹੈ। ਉਹ ਪਤਾ ਸਵਾਲ ਦੇ ਅਗਲੇ ਪ੍ਰਾਪਤਕਰਤਾ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ, ਅੰਤ ਵਿੱਚ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਰਿਜ਼ੌਲਵਰ ਦੀ ਨਹੀਂ। ਸਥਾਨਕ ਸਟਬ ਰਿਜ਼ੌਲਵਰ ਉਹੀ ਵਾਧੂ ਕਦਮ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਅਸਲ ਚੀਜ਼ ਨਾਲ ਉਲਝਾਉਣਾ ਸੌਖਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹਰ ਸਥਿਤੀ ਆਉਟਪੁੱਟ ਵਿੱਚ ਦਿਸਦਾ ਹੈ।
ਸਟਬ ਉਹਨਾਂ ਸਰੋਤਾਂ ਵੱਲ ਭੇਜਦਾ ਹੈ ਜੋ ਉਹੀ ਆਉਟਪੁੱਟ ਵੀ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ, ਆਮ ਤੌਰ ’ਤੇ ਹੋਰ ਹੇਠਾਂ। ਸੰਚਾਲਕ ਬਾਰੇ ਕੁਝ ਵੀ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰੀ ਲੜੀ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਪਹਿਲੀ ਲਾਈਨ ਪੂਰਾ ਜਵਾਬ ਨਹੀਂ ਹੈ। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਰਿਸੈਪਸ਼ਨ ਨੂੰ ਹੀ ਕੰਪਨੀ ਕਹਿ ਰਹੇ ਹੋ।
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'ਦੂਜਾ ਕਮਾਂਡ ਰਿਜ਼ੌਲਵਰ ਦੇ ਗੂੰਜ ਨਾਮ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਸੰਚਾਲਕ ਇੱਕ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਆਪਣੇ ਦੇਖੇ ਸਰੋਤ-ਪਤੇ ਦੀ ਰਿਪੋਰਟ ਕਰਨ ਲਈ। ਤੀਜਾ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਸਰਵਰ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ, ਜੋ ਅਕਸਰ ਤੁਹਾਡੇ ਦੁਆਰਾ ਸੰਰਚਿਤ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ। ਸੰਚਾਲਕ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨੇ ਆਉਟਪੁੱਟ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਐਨਕ੍ਰਿਪਟਡ DNS ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਕੀ ਦਿਸਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਕੌਣ ਦੇਖਦਾ ਹੈ
DNS over HTTPS ਅਤੇ DNS over TLS ਕਲਾਇੰਟ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਵਿਚਕਾਰ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ। ਰਿਜ਼ੌਲਵਰ ਅਜੇ ਵੀ ਹਰ ਉਹ ਨਾਮ ਪੜ੍ਹਦਾ ਹੈ ਜੋ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਜਵਾਬ ਦੇਣਾ ਹੀ ਕੰਮ ਹੈ। ਜੋ ਬਦਲਦਾ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਕੌਣ ਦੇਖ ਸਕਦਾ ਹੈ: ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਇੱਕ ਅੰਤ ਬਿੰਦੂ ਨਾਲ ਕਨੈਕਸ਼ਨ ਦੇਖਦਾ ਹੈ, ਸਾਦੇ ਟੈਕਸਟ ਸਵਾਲਾਂ ਦੀ ਧਾਰਾ ਨਹੀਂ।
ਜੋ ਨਹੀਂ ਬਦਲਦਾ ਉਹ ਭਰੋਸੇ ਦਾ ਸਬੰਧ ਹੈ, ਜੋ ਅਜੇ ਵੀ ਉਸ ਸੰਸਥਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਜੋ ਉਹ ਅੰਤ ਬਿੰਦੂ ਚਲਾਉਂਦੀ ਹੈ। ਆਪਣੀ ਸੁਰੱਖਿਅਤ DNS ਸੈਟਿੰਗ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰ ਸਕਦਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਦੋ ਵਾਰ ਲਾਗੂ ਕੀਤੀ ਇੱਕ ਸੈਟਿੰਗ ਵਜੋਂ ਨਹੀਂ, ਸਗੋਂ ਅਸਹਿਮਤ ਹੋ ਸਕਣ ਵਾਲੀਆਂ ਦੋ ਸੰਰਚਨਾਵਾਂ ਵਜੋਂ ਲਓ।
ਨਿੱਜੀ ਨਾਵਾਂ ਨੂੰ ਫਿਰ ਆਪਣਾ ਫ਼ੈਸਲਾ ਚਾਹੀਦਾ ਹੈ। ਕੰਮ ਦਾ ਟਨਲ ਚੁਣੇ ਡੋਮੇਨਾਂ ਨੂੰ ਸੰਸਥਾਗਤ ਰਿਜ਼ੌਲਵਰਾਂ ਵੱਲ ਭੇਜ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਜਨਤਕ ਸੇਵਾ ਨਾਲ ਬਦਲਣਾ ਅੰਦਰੂਨੀ ਖੋਜਾਂ ਤੋੜ ਸਕਦਾ ਹੈ ਜਾਂ ਅੰਦਰੂਨੀ ਨਾਵਾਂ ਨੂੰ ਗਲਤ ਧਿਰ ਨੂੰ ਜ਼ਾਹਰ ਕਰ ਸਕਦਾ ਹੈ। ਪੂਰੇ ਅਡਾਪਟਰ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਡੋਮੇਨ ਨੀਤੀ ਜਾਂਚੋ।
ਨਿਰੀਖਣ ਸੰਧਰਾ ਰੱਖੋ
ਤੁਲਨਾ ਕਰਦੇ ਸਮੇਂ ਪੁਰਾਣੀ ਸੰਰਚਨਾ ਸੰਭਾਲੋ ਅਤੇ ਇੱਕ ਸਮੇਂ ਇੱਕ ਸੈਟਿੰਗ ਬਦਲੋ। ਐਪਲੀਕੇਸ਼ਨ, ਕਾਰਵਾਈ, ਰਿਜ਼ੌਲਵਰ ਨੀਤੀ, ਅਤੇ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਜਨਤਕ ਤੇ ਮਨਜ਼ੂਰ ਨਿੱਜੀ ਨਾਵਾਂ ਹਾਲੇ ਵੀ ਹੱਲ ਹੁੰਦੇ ਹਨ ਜਾਂ ਨਹੀਂ, ਦਰਜ ਕਰੋ। ਦੋ ਬਦਲਾਅ ਵਾਲੀ ਤੁਲਨਾ ਕਿਸੇ ਇੱਕ ਨੂੰ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ। ਨਤੀਜਾ ਉੱਥੇ ਲਿਖੋ ਜਿੱਥੇ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਮਿਲੇ, ਸੈਟਿੰਗ ਦੇ ਬਿਲਕੁਲ ਕੋਲ।
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comਜੇ ਐਪਲੀਕੇਸ਼ਨ ਕੰਮ ਕਰਨ ਲੱਗੇ, ਦਾਅਵਾ ਓਨਾ ਹੀ ਛੋਟਾ ਰੱਖੋ ਜਿੰਨਾ ਸਬੂਤ ਆਗਿਆ ਦਿੰਦੇ ਹਨ। ਉਸ ਬਦਲਾਅ ਨੇ ਇੱਕ ਟੈਸਟ ਵਿੱਚ ਮਦਦ ਕੀਤੀ, ਅਤੇ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਪਿਛਲੇ ਰਿਜ਼ੌਲਵਰ ਨੇ ਮਾੜੀ ਨੀਅਤ ਨਾਲ ਕੰਮ ਕੀਤਾ, ਟਨਲ ਟੁੱਟੀ ਸੀ, ਜਾਂ ਕਿਸੇ ਹੋਰ ਡਿਵਾਈਸ ਨੂੰ ਉਹੀ ਬਦਲੀ ਚਾਹੀਦੀ ਹੈ। ਟਿਕਾਊ ਨਤੀਜਾ ਉਹ ਸੰਰਚਨਾ ਹੈ ਜਿਸ ਦਾ ਸੰਚਾਲਕ ਅਤੇ ਮਕਸਦ ਤੁਸੀਂ ਸਮਝਾ ਸਕੋ।