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ಅಪ್ಲಿಕೇಶನ್ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಸಾಕ್ಷ್ಯಗಳು ಅನುಮತಿಸುವಷ್ಟು ಚಿಕ್ಕದಾಗಿ ಹೇಳಿಕೆಯನ್ನು ಇರಿಸಿ. ಆ ಬದಲಾವಣೆ ಒಂದು ಪರೀಕ್ಷೆಗೆ ಸಹಾಯ ಮಾಡಿತು, ಮತ್ತು ಹಿಂದಿನ ರೆಸಾಲ್ವರ್ ಕೆಟ್ಟ ಉದ್ದೇಶದಿಂದ ವರ್ತಿಸಿತೇ, ಸುರಂಗ ಮುರಿದಿತ್ತೇ, ಅಥವಾ ಇನ್ನೊಂದು ಸಾಧನಕ್ಕೆ ಅದೇ ಬದಲಿ ಬೇಕೇ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಶಾಶ್ವತ ಫಲಿತಾಂಶವೆಂದರೆ ನೀವು ಅದರ ನಿರ್ವಾಹಕರು ಮತ್ತು ಉದ್ದೇಶವನ್ನು ವಿವರಿಸಬಹುದಾದ ಸಂರಚನೆ.