VPN ನಲ್ಲಿ DNS ತಪ್ಪಾಗಿದೆಯೇ? ಒಂದು ಅಧಿಕಾರಯುತ ಸರ್ವರ್ ಹಳೆಯದಾಗಿರಬಹುದು

VPN ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಒಂದು ಅತಿಥೇಯನಾಮ ನಿನ್ನೆಯ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುತ್ತದೆ, ಅಥವಾ ಯಾವುದಕ್ಕೂ ಅಲ್ಲ. ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಮತ್ತು ಅದು ಮತ್ತೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಸುರಂಗ ಒತ್ತಾಯಿಸಿದ ರಿಜಾಲ್ವರ್ ಅನ್ನು ದೂಷಿಸುವುದು ಸಹಜ ಪ್ರತಿಕ್ರಿಯೆ, ಆದರೆ ಹೆಚ್ಚು ಸಾಮಾನ್ಯ ಕಾರಣ ವಲಯ ನವೀಕರಣಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ಪ್ರಕಟಿತ ನಾಮ ಸರ್ವರ್. ಹೊಸ ಮಾರ್ಗವು ನಿಮ್ಮ ಸಂಗ್ರಹಿತ ಉತ್ತರ ಬಂದ ಅಧಿಕಾರಕ್ಕಿಂತ ಬೇರೆಯದೇ ಅಧಿಕಾರವನ್ನು ತಲುಪಿತು ಅಷ್ಟೇ.

ರಿಜಾಲ್ವರ್ ಜೊತೆಗೆ ಲಕ್ಷಣ ಬದಲಾಗುತ್ತದೆ

ಪುನರಾವರ್ತಕ ರಿಜಾಲ್ವರ್ ಅಧಿಕಾರವೊಂದು ಹೇಳಿದ್ದನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ನಂತರ ಆ ಉತ್ತರವನ್ನು TTL ವರೆಗೆ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಸುರಂಗ ಬೇರೆ ರಿಜಾಲ್ವರ್ ಒತ್ತಾಯಿಸಿದರೆ, ಅಥವಾ ಹಳೆಯದು ತಲುಪಲಾಗದಂತೆ ಮಾರ್ಗ ಬದಲಾದರೆ, ಕ್ಲೈಂಟ್ ಬೇರೆ ಅಧಿಕಾರವನ್ನು ಕೇಳಿ ಬೇರೆ ಉತ್ತರ ಪಡೆಯುತ್ತದೆ. ಆ ಕ್ಷಣದಲ್ಲಿ ಡೊಮೇನ್ ಬದಲಾಗಲಿಲ್ಲ; ಅದರ ಬಗ್ಗೆ ನಿಮ್ಮ ದೃಷ್ಟಿ ಬದಲಾಯಿತು.

ಆದ್ದರಿಂದಲೇ ಒಂದೇ ಹೆಸರು ಒಂದು ಕಚೇರಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ಹೋಟೆಲಿನಿಂದ ವಿಫಲವಾಗಬಹುದು, ಮತ್ತು ಸ್ಥಳೀಯ ಕ್ಯಾಶ್ ತೆರವು ಮಾಡುವುದು ಕೆಲವೊಮ್ಮೆ ಮಾತ್ರ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಕ್ಯಾಶ್ ತೆರವು ಮಾಡಿದರೆ ಪ್ರಶ್ನೆ ಮತ್ತೆ ಅದೇ ಅಧಿಕಾರಕ್ಕೆ ಹೋಗುತ್ತದೆ.

ಭೇದ ಕಲ್ಪಿಸುವ ಪರೀಕ್ಷೆ ಪ್ರತಿ ಪ್ರಕಟಿತ ಸರ್ವರ್ಗೆ ನೇರ ಪ್ರಶ್ನೆ.

ಪ್ರತಿ ಅಧಿಕಾರವನ್ನು ನೇರವಾಗಿ ಕೇಳಿ

ನೆನಪಿನಲ್ಲಿರುವ ಪಟ್ಟಿಯಿಂದ ಅಲ್ಲ, ನಿಯೋಗದಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಪೋಷಕನಿಗೆ NS ಗುಂಪನ್ನು ಕೇಳಿ, ನಂತರ ಆ ಗುಂಪಿನ ಪ್ರತಿ ಹೆಸರಿಗೂ ನಿಮಗೆ ಬೇಕಾದ ದಾಖಲೆಯನ್ನು ಕೇಳಿ. ಒಂದೇ ಹೆಸರಿಗೆ ಬೇರೆ ಬೇರೆ ಅಧಿಕಾರಗಳಲ್ಲಿ ಎರಡು ಪ್ರಶ್ನೆಗಳು ವಲಯ ಸುಸಂಗತವೇ ಎಂದು ತಕ್ಷಣ ಹೇಳುತ್ತವೆ.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

ವಲಯದ ತುದಿಯ NS ದಾಖಲೆಗಳಿಗೂ ಅದನ್ನೇ ಮಾಡಿ, ಏಕೆಂದರೆ ವಲಯಾಂತರದ ನಂತರ ಪೋಷಕ ನಿಯೋಗ ಮತ್ತು ವಲಯದ ಸ್ವಂತ NS ಗುಂಪು ಭಿನ್ನವಾಗಬಹುದು. SOA ಯ ಕ್ರಮ ಸಂಖ್ಯೆಗಳು ಮುಂದಿನ ಹೋಲಿಕೆ, ಮತ್ತು ಬಹಳ ಹಿಂದೆ ಉಳಿದ ದ್ವಿತೀಯ ಸರ್ವರ್ ವರ್ಗಾವಣೆ ಸಮಸ್ಯೆ, ಉತ್ತರದ ಸಮಸ್ಯೆ ಅಲ್ಲ.

ಆ ಪ್ರಶ್ನೆಗಳನ್ನು ನಿಮ್ಮ ಮೇಜಿನಿಂದ ಮಾತ್ರವಲ್ಲ, ವಿಫಲವಾಗುವ ಜಾಲದಿಂದ ನಡೆಸಿ.

ಉದ್ದೇಶಿತ ದೃಶ್ಯಗಳನ್ನು ಮುರಿದ ದೃಶ್ಯಗಳಿಂದ ಬೇರ್ಪಡಿಸಿ

ಕೆಲವು ಡೊಮೇನ್ಗಳು ಪ್ರದೇಶ ಅಥವಾ ರಿಜಾಲ್ವರ್ ಗುಂಪಿನ ಪ್ರಕಾರ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಬೇರೆಯಾಗಿ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ವಿಭಜಿತ ಕ್ಷಿತಿಜ ಸಂರಚನೆಗಳು ಉದ್ಯಮ ಜಾಲಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ.

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

SERVFAIL ಉತ್ತರಿಸುವ ಸರ್ವರ್ ಅನ್ನು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ತಪ್ಪಾಗಿ ಉತ್ತರಿಸುವ ಸರ್ವರ್ಗಿಂತ ಸುಲಭವಾಗಿ ಪತ್ತೆಹಚ್ಚಬಹುದು.

ವಲಯಾಂತರವು ಕ್ಯಾಶ್ ಮುಚ್ಚಿಟ್ಟದ್ದನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ

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

ದೀರ್ಘಕಾಲಿಕ ಕ್ಯಾಶ್ ಮುಚ್ಚಿಡುವ ಸ್ಥಿತಿ ನಿಖರವಾಗಿ ಇದೇ. ವಾರವಿಡೀ ಕೆಲಸ ಮಾಡಿದ ಕಾರ್ಯಸ್ಥಾನವು ಹೊಸ ಅಧಿಕಾರದ ತಾಜಾ ಉತ್ತರವನ್ನು ಹೊಂದಿದ್ದ ರಿಜಾಲ್ವರ್ ಜೊತೆ ಮಾತನಾಡುತ್ತಿತ್ತು, ಆದರೆ ಹಳೆಯದು ಉಳಿದ ಎಲ್ಲರಿಗೂ ಹಳೆಯ ಡೇಟಾವನ್ನು ಹಂಚುತ್ತಲೇ ಇತ್ತು.

ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ರಿಜಾಲ್ವರ್ ಬದಲಿಸಿದರೆ ಆ ಲ್ಯಾಪ್ಟಾಪ್ ಸರಿಯಾಗುತ್ತದೆ, ಬೇರೇನೂ ಅಲ್ಲ.

ವಲಯವನ್ನು ಸರಿಪಡಿಸಿ, ರಿಜಾಲ್ವರ್ ಅಲ್ಲ

ಯಾವ ಸರ್ವರ್ಗಳು ವಲಯಕ್ಕೆ ಅಧಿಕಾರಯುತವಾಗಿರಬೇಕು ಎಂದು ಗುರುತಿಸಿ, ನಿರ್ವಹಿತ ವಲಯ ಅಥವಾ ನಿಯೋಗವನ್ನು ಸರಿಪಡಿಸಿ ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಉದ್ದೇಶಿತ ಡೇಟಾವನ್ನು ನೀಡುವಂತೆ ಮಾಡಿ, ಮತ್ತು ನೀವು ಯೋಜಿಸಿದ ಪುನರುಕ್ತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ. ಒಂದು VPN ನಿರ್ಗಮನಕ್ಕೆ ವಿಚಿತ್ರ ಉತ್ತರ ಸಿಕ್ಕಿದ್ದರಿಂದ ನಾಮ ಸರ್ವರ್ ಅನ್ನು ಅಳಿಸುವುದು ಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅಸಂಗತಿಯನ್ನು ಅಲ್ಲಿಯೇ ಬಿಡುತ್ತದೆ.

ನಂತರ ಎರಡೂ ಜಾಲಗಳಿಂದ ನೇರ ಪ್ರಶ್ನೆಗಳನ್ನು ಮತ್ತೆ ನಡೆಸಿ ಮತ್ತು ನೀವು ಬದಲಿಸಿದ ದಾಖಲೆಯ TTL ಮುಗಿಯುವವರೆಗೆ ಕಾಯಿರಿ.

ಪ್ರತಿ ಅಧಿಕಾರದಿಂದ ಉತ್ತರ ಸ್ಥಿರವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ಮುಂದಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಸುಲಭವಾಗಿ ವರ್ಗೀಕರಿಸಲು ಉದ್ದೇಶಿತ ದೃಶ್ಯವನ್ನು ವಲಯ ದಾಖಲಾತಿಯಲ್ಲಿ ಬರೆಯಿರಿ.