ਤੁਹਾਡੇ ਘਰ ਦਾ ਨੈੱਟਵਰਕ ਦਿਖਾਉਣ ਵਾਲਾ DNS ਲੀਕ ਟੈਸਟ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ ਕਿ ਐਨਕ੍ਰਿਪਟਿਡ DNS ਫੇਲ੍ਹ ਹੋਇਆ, ਅਤੇ ਇਹ ਵੀ ਸਬੂਤ ਨਹੀਂ ਕਿ ਕੁਝ ਕੰਮ ਕੀਤਾ। ਟੈਸਟ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਇਹ ਪੁੱਛਗਿੱਛ ਇਸ ਨੈੱਟਵਰਕ ਤੋਂ ਕਿਹੜੇ ਰਿਜ਼ੌਲਵਰ ਤੱਕ ਪਹੁੰਚੀ। ਇਹ ਸਮੱਸਿਆ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸ ਤੋਂ ਅਤੇ ਕਿਸ ਤੋਂ ਬਚਾ ਰਹੇ ਸੀ।

ਕੋਈ ਵੀ ਟੈਸਟ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਟੀਚਾ ਲਿਖੋ।

ਕਦਮ 1: ਉਸ ਸੁਰੱਖਿਆ ਦਾ ਨਾਂ ਲਓ ਜੋ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਚਾਹੁੰਦੇ ਹੋ

ਤਿੰਨ ਟੀਚੇ ਰਲ-ਮਿਲ ਜਾਂਦੇ ਹਨ। ਤੁਸੀਂ ਚਾਹ ਸਕਦੇ ਹੋ ਕਿ ਰਾਹ ਵਿੱਚ ਬੈਠਾ ਕੋਈ ਨਿਗਰਾਨ ਪੁੱਛਗਿੱਛ ਪੜ੍ਹਨਾ ਬੰਦ ਕਰ ਦੇਵੇ। ਤੁਸੀਂ ਚਾਹ ਸਕਦੇ ਹੋ ਕਿ ਕੋਈ ਖਾਸ ਰਿਜ਼ੌਲਵਰ ਉਹ ਪ੍ਰਾਪਤ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਵੇ। ਤੁਸੀਂ ਚਾਹ ਸਕਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਜਿਨ੍ਹਾਂ ਵੈੱਬਸਾਈਟਾਂ 'ਤੇ ਜਾਂਦੇ ਹੋ, ਉਹ ਤੁਹਾਡਾ ਘਰ ਦਾ ਪਤਾ ਦੇਖਣਾ ਬੰਦ ਕਰ ਦੇਣ. ਐਨਕ੍ਰਿਪਟਿਡ DNS ਪਹਿਲੇ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ, ਦੂਜੇ ਨੂੰ ਕੌਣ ਪੂਰਾ ਕਰਦਾ ਹੈ ਇਹ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਤੀਜੇ ਲਈ ਕੁਝ ਵੀ ਨਹੀਂ ਕਰਦਾ।

VPN ਤੀਜੇ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ ਅਤੇ, ਪ੍ਰਦਾਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ, ਪਹਿਲੇ ਦੀ ਵੀ। ਦੋਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸੰਦ ਦੂਜੇ ਦਾ ਸੁਪਰਸੈੱਟ ਨਹੀਂ।

ਕਦਮ 2: ਇੱਕ ਰਿਜ਼ੌਲਵਰ ਚੁਣੋ ਅਤੇ ਉਸ ਦੀ ਪਛਾਣ ਪਰਖੋ

DNS over TLS ਪੁੱਛਗਿੱਛ ਨੂੰ ਰਿਜ਼ੌਲਵਰ ਨਾਲ TLS ਸੈਸ਼ਨ ਵਿੱਚ ਲਪੇਟਦਾ ਹੈ, ਅਤੇ DNS over HTTPS ਇਸ ਨੂੰ HTTP ਬੇਨਤੀ ਵਿੱਚ ਲਪੇਟਦਾ ਹੈ; RFC 7858 ਅਤੇ RFC 8484 ਦੋਨਾਂ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਵੀ ਟਨਲ ਦੀ ਲੋੜ ਨਹੀਂ। ਕਾਰਜ-ਪ੍ਰਣਾਲੀ ਪੱਖੋਂ ਮਹੱਤਵਪੂਰਨ ਇਹ ਹੈ ਕਿ ਸਰਟੀਫਿਕੇਟ ਤੁਹਾਡੇ ਦੁਆਰਾ ਸੰਰਚਿਤ ਨਾਂ ਦੇ ਵਿਰੁੱਧ ਪਰਖਿਆ ਜਾਵੇ, ਕਿਉਂਕਿ ਗਲਤ ਧਿਰ ਨਾਲ ਐਨਕ੍ਰਿਪਟਿਡ ਸੈਸ਼ਨ ਸਹੀ ਧਿਰ ਨਾਲ ਸਾਧਾਰਨ ਟੈਕਸਟ ਤੋਂ ਮਾੜਾ ਹੈ। ਇਸ ਦਾ ਅਰਥ ਹੈ ਕਿ ਪਲੇਟਫਾਰਮ ਜਿੱਥੇ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਉੱਥੇ ਸਖ਼ਤ ਮੋਡ, ਪਰਖ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਪਿੱਛੇ ਹਟਣ ਵਾਲਾ ਮੌਕਾਪ੍ਰਸਤ ਮੋਡ ਨਹੀਂ। ਸੈਟਿੰਗ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੈਸ਼ਨ ਨੂੰ ਸਿੱਧਾ ਜਾਂਚੋ: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

ਹੈਂਡਸ਼ੇਕ ਨੂੰ ਤੁਹਾਡੇ ਦੁਆਰਾ ਸੰਰਚਿਤ ਰਿਜ਼ੌਲਵਰ ਦਾ ਨਾਂ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਅਜਿਹੀ ਚੇਨ ਵਾਪਸ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਪਰਖ ਸਕੋ।

ਕਦਮ 3: ਫੇਲ੍ਹ ਹੋਣ ਵੇਲੇ ਦਾ ਵਿਵਹਾਰ ਤੈਅ ਕਰੋ

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

systemd-resolved 'ਤੇ ਮੌਕਾਪ੍ਰਸਤ ਮੋਡ ਨਹੀਂ, DNSOverTLS=yes ਇਹ ਸੈਟਿੰਗ ਲੋੜੀਂਦੀ ਹੈ; opportunistic; ਅਤੇ Android 'ਤੇ ਇਸ ਦਾ ਅਰਥ ਹੈ ਸਵੈਚਾਲਿਤ ਨਹੀਂ ਸਗੋਂ Private DNS ਹੋਸਟਨਾਂ ਮੋਡ।

ਅਸਲ ਵਿੱਚ ਕੀ ਲਾਗੂ ਹੈ ਇਹ ਇਸ ਨਾਲ ਜਾਂਚੋ: resolvectl status | grep -i -A1 "dns over tls", ਕਿਉਂਕਿ ਕਦੇ ਵੀ ਦੁਬਾਰਾ ਲੋਡ ਨਾ ਹੋਈ drop-in ਫਾਈਲ ਕੁਝ ਨਹੀਂ ਬਦਲਦੀ।

ਕਦਮ 4: ਜਾਂਚੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸਿਸਟਮ ਰਿਜ਼ੌਲਵਰ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ

ਆਪਣੀ ਸੁਰੱਖਿਅਤ-DNS ਸੈਟਿੰਗ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਸਿਸਟਮ ਸੰਰਚਨਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਏਮਬੈੱਡਿਡ ਰਿਜ਼ੌਲਵਰ ਵਾਲਾ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਜਾਂ ਹਾਰਡਕੋਡ ਕੀਤੀ ਸੂਚੀ ਪੜ੍ਹਨ ਵਾਲਾ ਭਾਸ਼ਾ ਰਨਟਾਈਮ ਵੀ ਅਜਿਹਾ ਹੀ ਕਰਦਾ ਹੈ। ਜਾਂ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਿਸਟਮ ਦੀ ਪਾਲਣਾ ਕਰਨ ਦਿਓ ਜਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸੰਰਚਿਤ ਕਰੋ ਅਤੇ ਇਹ ਲਿਖੋ। ਫਿਰ ਹਰ ਇੱਕ ਦੇ ਫਾਲਬੈਕ ਵਿਵਹਾਰ ਨੂੰ ਦੇਖੋ, ਕਿਉਂਕਿ ਸਾਰੇ ਬੰਦ ਰੂਪ ਵਿੱਚ ਫੇਲ੍ਹ ਨਹੀਂ ਹੁੰਦੇ। ਸੂਚੀ ਵਿਵਹਾਰ ਵਿੱਚ ਛੋਟੀ ਹੈ: ਬ੍ਰਾਊਜ਼ਰ, ਕੰਟੇਨਰ ਰਨਟਾਈਮ, ਅਤੇ ਕੋਈ ਵੀ VPN ਕਲਾਇੰਟ ਜੋ ਤੁਸੀਂ ਵੀ ਚਲਾਉਂਦੇ ਹੋ।

ਸੰਸਥਾ ਦੇ ਨਿੱਜੀ ਨਾਂ ਮਨਜ਼ੂਰ ਅੰਦਰੂਨੀ ਰਿਜ਼ੌਲਵਰ 'ਤੇ ਹੀ ਰਹਿੰਦੇ ਹਨ। ਟੈਸਟ ਸਾਫ਼ ਦਿਖੇ ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਜਨਤਕ ਸੇਵਾ 'ਤੇ ਭੇਜਣਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਵੱਖਰੀ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਕਦਮ 5: ਲੋੜ ਦੇ ਮੁਕਾਬਲੇ ਲੀਕ ਟੈਸਟ ਪੜ੍ਹੋ

ਅਣਕਿਆਸੇ ਰਿਜ਼ੌਲਵਰ ਦੀ ਰਿਪੋਰਟ ਕਰਨ ਵਾਲਾ ਟੈਸਟ ਸੰਕੇਤ ਹੈ, ਫੈਸਲਾ ਨਹੀਂ. ਹੋ ਸਕਦਾ ਹੈ ਉਸ ਨੇ ਤੁਹਾਡਾ ਇੱਛਤ ਐਨਕ੍ਰਿਪਟਿਡ ਰਿਜ਼ੌਲਵਰ, ਐਪ-ਖਾਸ ਸੈਟਿੰਗ, ਜਾਂ ਸਾਧਾਰਨ ਟੈਕਸਟ ਦਾ ਫਾਲਬੈਕ ਦੇਖਿਆ ਹੋਵੇ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਸੀ। ਰਿਪੋਰਟ ਕੀਤੇ ਰਿਜ਼ੌਲਵਰ ਦੀ ਤੁਲਨਾ ਕਦਮ 2 ਵਿੱਚ ਸੰਰਚਿਤ ਕੀਤੇ ਨਾਲ ਕਰੋ, ਅਤੇ ਨਤੀਜੇ ਦੀ ਤੁਲਨਾ ਕਦਮ 1 ਦੇ ਟੀਚੇ ਨਾਲ ਕਰੋ।

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

ਸਵੀਕ੍ਰਿਤੀ ਦੀ ਲਾਈਨ ਟੀਚੇ ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ: ਇਹ ਖੋਜਾਂ ਇਹਨਾਂ ਸ਼ਰਤਾਂ ਹੇਠ ਇਸ ਪਰਖੇ ਹੋਏ ਰਿਜ਼ੌਲਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ। ਇਸ ਤੋਂ ਵਿਸ਼ਾਲ ਕੁਝ ਵੀ ਅਜਿਹਾ ਦਾਅਵਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਪਰਖ ਨਹੀਂ ਸਕਦੇ।

ਸੰਬੰਧਿਤ ਲੇਖ