VPN ಇಲ್ಲದೆ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ DNS ಪ್ರಶ್ನೆಯನ್ನು ಮರೆಮಾಡುತ್ತದೆ, ನಿಮ್ಮ ವಿಳಾಸವನ್ನು ಅಲ್ಲ

ನಿಮ್ಮ ಮನೆಯ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ತೋರಿಸುವ 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 ಸೆಟ್ಟಿಂಗ್ ಅದನ್ನು ಎಂದಿಗೂ ನೀಡುತ್ತಿರಲಿಲ್ಲ.

ಸ್ವೀಕೃತಿ ಸಾಲನ್ನು ಗುರಿಯ ಭಾಷೆಯಲ್ಲಿ ಬರೆಯಿರಿ: ಈ ಹುಡುಕಾಟಗಳು ಈ ಷರತ್ತುಗಳ ಅಡಿಯಲ್ಲಿ ಈ ಪರಿಶೀಲಿತ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತವೆ. ಇದಕ್ಕಿಂತ ವಿಶಾಲವಾದ ಯಾವುದೇ ಹೇಳಿಕೆ ನೀವು ಪರೀಕ್ಷಿಸಲಾಗದ ದಾವೆ.