VPN DNS ಅನ್ನು ಸರಿಪಡಿಸಿತೇ, ಅಥವಾ ಕೇವಲ ಕ್ಯಾಶ್ ಮಾಡಿದ ಉತ್ತರವನ್ನು ಮರುಬಳಕೆ ಮಾಡಿತೇ?

ಸುರಂಗ ಏರಿದ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಂತರ ಪುಟ ತೆರೆಯುವುದು DNS ಈಗ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ, ಟಿಕೆಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಹಾಗೆ ಹೇಳುತ್ತದೆಯಾದರೂ. ಆ ಅವಲೋಕನದಲ್ಲಿ ಯಾವುದೂ ಪ್ರಶ್ನೆಯನ್ನು ಅಗತ್ಯವಾಗಿರಲಿಲ್ಲ: ಹೆಸರು ಬದಲಾವಣೆಗೆ ಮೊದಲು ಪರಿಹರಿಸಲ್ಪಟ್ಟಿರಬಹುದು ಮತ್ತು ಸುರಂಗ ಎಂದಿಗೂ ಮುಟ್ಟದ ಕ್ಯಾಶ್‌ನಿಂದ ಮರುಬಳಕೆಯಾಗಿರಬಹುದು. ಎರಡು ವಿಭಿನ್ನ ಪರೀಕ್ಷೆಗಳು ಒಂದೇ ಪರದೆಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ.

ಬದಲಾವಣೆಗೆ ಶ್ರೇಯ ನೀಡುವ ಮೊದಲು ಪ್ರತಿ ಪರೀಕ್ಷೆ ನಿಜವಾಗಿ ಏನನ್ನು ಅಭ್ಯಾಸ ಮಾಡಿತು ಎಂಬುದನ್ನು ಹೋಲಿಸಿ.

ಪುಟ ಲೋಡ್ ಮಾಡುವುದು ಪ್ರಶ್ನೆಯಲ್ಲ

ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ರಿಸಾಲ್ವರ್ ನಡುವಿನ ಪ್ರತಿಯೊಂದು ಪದರವು ತನ್ನ ಜೀವಿತಾವಧಿಯಲ್ಲಿ ಉತ್ತರವನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬಹುದು. ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂ ಒಂದನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಬ್ರೌಸರ್ ತನ್ನದನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ದೀರ್ಘಕಾಲಿಕ ಸಂಪರ್ಕವಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಸೆಷನ್‌ನಲ್ಲಿ ಇನ್ನು ಏನನ್ನೂ ಪರಿಹರಿಸದೇ ಇರಬಹುದು. ಆದ್ದರಿಂದ ಸುರಂಗ ಬದಲಾವಣೆಯ ನಂತರ ಯಶಸ್ವಿ ಲೋಡ್ ರೂಟಿಂಗ್‌ನ ಬದಲು ನೆನಪಿನ ಪ್ರದರ್ಶನವಾಗಿರಬಹುದು. ವೈಫಲ್ಯದ ಅನುಪಸ್ಥಿತಿ ಪ್ರಶ್ನೆಯ ಉಪಸ್ಥಿತಿಯಲ್ಲ.

ಈ ವ್ಯತ್ಯಾಸವು ಮುಂದೆ ನೀವು ಏನನ್ನು ಪರೀಕ್ಷಿಸಬೇಕು ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಹೊಸ ರಿಸಾಲ್ವರ್ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸುವುದು ಗುರಿಯಾಗಿದ್ದರೆ, ನೀವು ತೆರವು ಮಾಡದ ಕ್ಯಾಶ್‌ನಿಂದ ಒದಗಿಸಲಾಗದ ಪ್ರಶ್ನೆ ಬೇಕು.

ಕ್ಯಾಶ್ ಮಾಡಿದ ಯಶಸ್ಸನ್ನು ಹಿಂದೆ ತಲುಪಲಾಗದ ಸರ್ವರ್ ಚೇತರಿಸಿಕೊಂಡಿದೆ ಎಂಬ ಸಾಕ್ಷಿಯಾಗಿ ಓದುವುದು ಈ ತಪ್ಪಿನ ಅತ್ಯಂತ ದುಬಾರಿ ರೂಪ, ಏಕೆಂದರೆ ಅದು ಘಟನೆಯನ್ನು ಸುಳ್ಳು ಊಹೆಯ ಮೇಲೆ ಮುಚ್ಚುತ್ತದೆ.

ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಕ್ಯಾಶ್‌ಗಳನ್ನು ಎಣಿಸಿ

ನಾಲ್ಕನ್ನು ಹೆಸರಿಸುವುದು ಯೋಗ್ಯ: ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ಪರಿಹಾರ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಕ್ಲೈಂಟ್ ಕ್ಯಾಶ್, ಬ್ರೌಸರ್‌ನ ಆಂತರಿಕ ಸ್ಥಿತಿ, ಮತ್ತು ಪ್ರಶ್ನೆ ಅಂತಿಮವಾಗಿ ತಲುಪುವ ಯಾವುದೇ ಪುನರಾವರ್ತಿತ ರಿಸಾಲ್ವರ್. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಪ್ರತ್ಯೇಕ ಜೀವಿತಾವಧಿ ಮತ್ತು ತೆರವು ಮಾಡುವ ಪ್ರತ್ಯೇಕ ದಾರಿ ಇದೆ. ಒಂದನ್ನು ತೆರವು ಮಾಡಿ ಇನ್ನೊಂದನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಜನರು ತೆರವು ಏನನ್ನೂ ಮಾಡಲಿಲ್ಲ ಎಂದು ತೀರ್ಮಾನಿಸುವ ದಾರಿ. ಒಂದು ಫ್ಲಶ್ ಆದೇಶ ಪ್ರಶ್ನೆಯನ್ನು ಎಂದಿಗೂ ನಿರ್ಣಯಿಸುವುದಿಲ್ಲ.

ಋಣಾತ್ಮಕ ಉತ್ತರಗಳೂ ಕ್ಯಾಶ್ ಆಗುತ್ತವೆ. ಕಾಣೆಯಾಗಿದೆ ಎಂದು ವರದಿಯಾದ ಹೆಸರು ನೆಟ್‌ವರ್ಕ್ ಸರಿಪಡಿಸಿದ ನಂತರವೂ ಕಾಣೆಯಾಗಿ ಉಳಿಯಬಹುದು, ಅದನ್ನು ಮುರಿದ ಸುರಂಗ ಎಂದು ಓದಲಾಗುತ್ತದೆ ಆದರೆ ಅದು ಇನ್ನೂ ಮುಗಿಯದ TTL. DNS ವಿಶೇಷಣೆ ಈ ಡೇಟಾವನ್ನು ಹೇಗೆ ಇಡಬೇಕು ಮತ್ತು ಮರುಬಳಕೆ ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಘಟನೆಯನ್ನು ದಾಖಲಿಸಿ, ಅನಿಸಿಕೆಯನ್ನಲ್ಲ

ಮೂರರಲ್ಲಿ ಯಾವುದು ಬದಲಾಯಿತು ಎಂದು ಬರೆಯಿರಿ: ದಾಖಲೆ, ರಿಸಾಲ್ವರ್‌ಗೆ ಇರುವ ಮಾರ್ಗ, ಅಥವಾ ಕ್ಲೈಂಟ್ ಸೆಟ್ಟಿಂಗ್. ದಾಖಲೆ ಸಂಪಾದನೆ ತನ್ನದೇ ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ ಹರಡುತ್ತದೆ, ಮಾರ್ಗ ಬದಲಾವಣೆ ಮರುಸಂಪರ್ಕದಲ್ಲಿ ಜಾರಿಗೆ ಬರುತ್ತದೆ, ಮತ್ತು ಬ್ರೌಸರ್ ಸೆಟ್ಟಿಂಗ್ ಆ ಬ್ರೌಸರ್‌ಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ. ಅವುಗಳನ್ನು ಒಂದೇ ಮೊದಲು-ಮತ್ತು-ನಂತರ ಆಗಿ ಸಂಕುಚಿಸುವುದು ಯಾರೂ ಪರಿಶೀಲಿಸಲಾಗದ ಕಾಲರೇಖೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಸಮಯ, ಬಳಸಿದ ರಿಸಾಲ್ವರ್ ಮತ್ತು ಸ್ವೀಕರಿಸಿದ ಉತ್ತರವನ್ನು ದಾಖಲಿಸಿ, ಉತ್ತರ ಋಣಾತ್ಮಕವಾದ ಸಂದರ್ಭವನ್ನೂ ಸೇರಿಸಿ. ಅದು ಬೇರೆ ಯಾರಾದರೂ ಪರಿಶೀಲಿಸಬಹುದಾದ ಸತ್ಯ.

ಹೋಲಿಕೆಯನ್ನು ಎರಡು ಬಾರಿ ಅದೇ ರೀತಿಯಲ್ಲಿ ಮಾಡಿ

ನೀವು ಪರೀಕ್ಷಿಸಲು ಉದ್ದೇಶಿಸಿರುವ ಕ್ಯಾಶ್ ಅನ್ನು ತೆರವು ಮಾಡಿ, ಮೂಲ ಅವಲೋಕನವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ, ನಂತರ ಸಾಧ್ಯವಾದಷ್ಟು ನೆನಪನ್ನು ಬಳಸದಂತೆ ಪ್ರಶ್ನೆ ಮಾಡಿ. ರಿಸಾಲ್ವರ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೆಸರಿಸುವುದು ಆ ರಿಸಾಲ್ವರ್ ಏನು ತಿಳಿದಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ; ಅಪ್ಲಿಕೇಶನ್ ಯಾವ ರಿಸಾಲ್ವರ್ ಆಯ್ಕೆ ಮಾಡುತ್ತಿತ್ತು ಎಂದು ಹೇಳುವುದಿಲ್ಲ.

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

Windows ನಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಕ್ಯಾಶ್ ಫ್ಲಶ್ DNS ಕ್ಲೈಂಟ್ ಕ್ಯಾಶ್ ಅನ್ನು ತೆರವು ಮಾಡುತ್ತದೆ, ಬೇರೇನೂ ಅಲ್ಲ. ಅದು ಬ್ರೌಸರ್‌ನ ಖಾಸಗಿ ಸ್ಥಿತಿಯನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಸರ್ವರ್ ಅನ್ನು ತೆರವು ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದರ ಮೇಲೆ ನಿರ್ಮಿಸಿದ ಪರೀಕ್ಷೆಯನ್ನು ಸಂಕುಚಿತವಾಗಿ ಮಾತ್ರ ಅರ್ಥೈಸಬಹುದು. ಫಲಿತಾಂಶವನ್ನು ವರದಿ ಮಾಡುವಾಗ ಯಾವ ಕ್ಯಾಶ್ ತೆರವು ಮಾಡಿದಿರಿ ಎಂದು ಹೇಳಿ.

ನಂತರ ಹೊಸ ವಿನಂತಿ ಮತ್ತು ಉದ್ದೇಶಿತ ರಿಸಾಲ್ವರ್ ನೀತಿ ಸಕ್ರಿಯವಾಗಿರಿಸಿ ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ. ಬೇರೆ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ಉತ್ಪಾದಿಸಿದ ಫಲಿತಾಂಶ ವರ್ಗಾವಣೆಯಾಗುವುದಿಲ್ಲ.