VPN ಮೇಲೆ NXDOMAIN ಎಂದರೆ ಟನೆಲ್ ಸ್ಥಗಿತವಲ್ಲ

ಒಂದು ವಿಫಲ ಹುಡುಕಾಟವನ್ನು ಟನೆಲ್ ಕುಸಿದ ಸಾಕ್ಷ್ಯವಾಗಿ ಓದುವುದು ಪ್ರಲೋಭನೆಯಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಹೆಸರು ಹತ್ತು ನಿಮಿಷಗಳ ಹಿಂದೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾಗ. ಉತ್ತರ ಬೇರೆ ಹೇಳುತ್ತದೆ. NXDOMAIN ಪೂರ್ಣಗೊಂಡ DNS ವಹಿವಾಟು, ಅದರಲ್ಲಿ ರಿಜಾಲ್ವರ್ ಕೇಳಿದ ಹೆಸರು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ಘೋಷಿಸಿದೆ; ಮುರಿದ ಟನೆಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಮೌನ, ಟೈಮೌಟ್ ಅಥವಾ ತಪ್ಪು ಸರ್ವರ್ ವಿರುದ್ಧ ರಿಜಾಲ್ಯೂಶನ್ ಪ್ರಯತ್ನವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. wireshark ಇಲ್ಲದ ವಾದದ ಆವೃತ್ತಿ ಒಂದು ಕ್ವೆರಿ, ಒಬ್ಬ ಉತ್ತರದಾತ ಮತ್ತು ಒಂದು ಉತ್ತರ ಕೋಡ್, ಮತ್ತು ಯಾವುದೇ ಸಂರಚನೆ ಬದಲಾವಣೆಗೆ ಮೊದಲು ಈ ತ್ರಯವನ್ನು ದಾಖಲಿಸುವುದು ಯೋಗ್ಯ.

ಉತ್ತರ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ

DNS ಕ್ಲೈಂಟ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ವೈಫಲ್ಯಕ್ಕೆ ಸೇರಿಸುವ ಫಲಿತಾಂಶಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಹೆಸರು NXDOMAIN ಕೋಡ್‌ನೊಂದಿಗೆ ಋಣಾತ್ಮಕ ಉತ್ತರ ನೀಡುತ್ತದೆ, ಆದರೆ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದು ಕೇಳಿದ ಪ್ರಕಾರದ ದಾಖಲೆ ಇಲ್ಲದ ಹೆಸರು ಖಾಲಿ ಉತ್ತರ ವಿಭಾಗದೊಂದಿಗೆ ಯಶಸ್ವಿ ಉತ್ತರ ನೀಡುತ್ತದೆ. ಎರಡೂ ಅನ್ವಯಕ್ಕೆ ನಿರುಪಯುಕ್ತವೆಂದು ಕಾಣುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಹೆಸರು ತಪ್ಪು ಎಂದು ಅರ್ಥ.

ಆ ವ್ಯತ್ಯಾಸ ಸರಿಪಡಿಸುವಿಕೆ ಎಲ್ಲಿರಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. A ದಾಖಲೆ ಇರುವ ಹೋಸ್ಟ್‌ನಲ್ಲಿ AAAA ದಾಖಲೆ ಇಲ್ಲದಿರುವುದು ಹೋಸ್ಟ್ ಇಲ್ಲದಿರುವುದಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಬೆನ್ನಟ್ಟಲು ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮತ್ತೆ ನೀಡುವುದು ಅಥವಾ ಟನೆಲ್ ಮತ್ತೆ ನಿರ್ಮಿಸುವುದು ಲಭ್ಯವಿದ್ದ ಏಕೈಕ ಸುಳಿವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. ಈ ಭೇದ ಮುಂದಿನ ಹೆಜ್ಜೆಯ ರೂಪವನ್ನೂ ನಿರ್ಧರಿಸುತ್ತದೆ: ಹೆಸರಿಸುವ ಸಮಸ್ಯೆ ವಲಯದಲ್ಲಿ ಸರಿಪಡಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರಕಾರದ ಸಮಸ್ಯೆ ಸರಿಯಾದ ದಾಖಲೆಯನ್ನು ಕೇಳುವ ಮೂಲಕ ಅಥವಾ ವಿಳಾಸ ಕುಟುಂಬವು ಸುಮ್ಮನೆ ಇಲ್ಲ ಎಂದು ಒಪ್ಪುವ ಮೂಲಕ ಸರಿಪಡಿಸಲಾಗುತ್ತದೆ.

ಪುರಾಣ: ಖಾಸಗಿ ಹೆಸರು ಇಲ್ಲದಿರುವುದು ಟನೆಲ್ ವಿಫಲವಾಯಿತು ಎಂದರ್ಥ

ಈ ಪುರಾಣ ಉಳಿದಿದೆ ಏಕೆಂದರೆ ಎರಡು ಘಟನೆಗಳು ಹೆಚ್ಚಾಗಿ ಒಟ್ಟಿಗೆ ಬರುತ್ತವೆ. ಕ್ಲೈಂಟ್ VPN ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂ ಈಗಾಗಲೇ ನಂಬಿದ್ದ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಈಗ ಬೇಕಾದ ಒಳಗಿನ ಹೆಸರು ಖಾಸಗಿ ವಲಯದ ಬಗ್ಗೆ ಎಂದೂ ಕೇಳದ ಸರ್ವರ್‌ಗೆ ಕೇಳಲಾಗುತ್ತದೆ. ಆ ಸರ್ವರ್ ಪ್ರಾಮಾಣಿಕವಾಗಿ ಮತ್ತು ಋಣಾತ್ಮಕವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ. ಟನೆಲ್ ಪ್ಯಾಕೆಟ್ ಸಾಗಿಸುತ್ತಿದೆ; ಉತ್ತರ ಕೇವಲ ಉತ್ತರದಾತ ಸೇವೆ ನೀಡದ ಹೆಸರಿನ ಜಾಗದ ಬಗ್ಗೆ.

split-horizon ವ್ಯವಸ್ಥೆಗಳು ಇದನ್ನು ದಿನನಿತ್ಯ ಮಾಡುತ್ತವೆ: ಅದೇ ವಲಯ ಹೆಸರು ಸಾರ್ವಜನಿಕವಾಗಿ ಮತ್ತು ಒಳಗೆ ಬೇರೆ ಬೇರೆ ವಿಷಯದೊಂದಿಗೆ ಇರುತ್ತದೆ, ಮತ್ತು ಖಾಸಗಿ ದಾಖಲೆಗಳನ್ನು ಒಳಗಿನ ರಿಜಾಲ್ವರ್ ಮಾತ್ರ ತಿಳಿದಿದೆ. ಆದ್ದರಿಂದ ಅಧಿಕೃತವೆಂದು ಕಾಣುವ ಋಣಾತ್ಮಕ ಉತ್ತರ ಪಡೆಯುವುದು ಯಾವ ರಿಜಾಲ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯ, ಇಂಟರ್‌ಫೇಸ್ ಸ್ಥಿತಿಗೆ ಸಾಕ್ಷ್ಯವಲ್ಲ.

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

ಸರಿಯಾದ ಹೆಸರಿನೊಂದಿಗೆ ಸರಿಯಾದ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಕೇಳಿ

ತೀರ್ಪು ದಾಖಲಿಸುವ ಮೊದಲು ಉತ್ತರದಾತನನ್ನು ದಾಖಲಿಸಿ. ಯಾವ ಸರ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂದು ತೋರಿಸದ ಹುಡುಕಾಟ ನೀತಿ ಸಮಸ್ಯೆ ಮತ್ತು ಹೆಸರಿನ ಜಾಗದ ಸಮಸ್ಯೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾರದು, ಮತ್ತು ಎರಡರ ಸರಿಪಡಿಸುವಿಕೆಗಳು ಸಂಬಂಧವಿಲ್ಲದವು.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

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

ಋಣಾತ್ಮಕ ಕ್ಯಾಶಿಂಗ್ ಸರಿಪಡಿಸಿದ ನಂತರದ ವಿಳಂಬವನ್ನು ವಿವರಿಸುತ್ತದೆ

ಋಣಾತ್ಮಕ ಉತ್ತರಗಳನ್ನು ವಿನ್ಯಾಸದಂತೆ ಕ್ಯಾಶ್ ಮಾಡಲಾಗುತ್ತದೆ, ಮತ್ತು RFC 2308 ಋಣಾತ್ಮಕ ಕ್ಯಾಶ್‌ನ ಜೀವಿತಾವಧಿ ವಲಯದ ಅಧಿಕಾರ ದಾಖಲೆಯಿಂದ ಹೇಗೆ ಪಡೆಯಲಾಗುತ್ತದೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ದಾಖಲೆ ಅಥವಾ ರಿಜಾಲ್ವರ್ ನಿಯಮವನ್ನು ಸರಿಪಡಿಸುವುದು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ತಕ್ಷಣದ ಬದಲಾವಣೆಗೆ ಖಾತರಿ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಕ್ಯಾಶ್ ಮಾಡಿದ ಉತ್ತರವನ್ನು ಮರಳಿಸುವ ಹುಡುಕಾಟವನ್ನು ಪುನಃ ಪ್ರಯತ್ನಿಸುವುದು ಹೊಸದನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಬೇರೆ ಉತ್ತರದಾತ, ಬೇರೆ ಹೆಸರು ಅಥವಾ ಖಾಲಿ ಮಾಡಿದ ಕ್ಯಾಶ್ ಮಾತ್ರ ತಾಜಾ ಸಾಕ್ಷ್ಯ ನೀಡುತ್ತದೆ.

ಸ್ಥಳೀಯ ಕ್ಯಾಶ್ ಖಾಲಿ ಮಾಡಿ, ನಂತರ ಅದೇ ಉತ್ತರದಾತನಿಗೆ ಅದೇ ಕ್ವೆರಿಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಸ್ಥಳೀಯ ರಿಜಾಲ್ವರ್ ಸೇವೆ ಬಳಸುವ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಅದು ಒಂದು ಆಜ್ಞೆ; ಇತರವುಗಳಲ್ಲಿ ಅದು ಸೇವೆ ಮರುಪ್ರಾರಂಭ ಅಥವಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸಾಧನ, ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಸಾಧನಕ್ಕಿಂತ ನಂತರ ಒಂದೇ ರೀತಿಯ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸುವುದು ಹೆಚ್ಚು ಮುಖ್ಯ.

ಹೆಸರನ್ನು ಮಾರ್ಗದಿಂದ ಬೇರ್ಪಡಿಸಿ

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

ಪ್ರತಿಲೇಖನವನ್ನು ಇರಿಸಿ: ಕ್ವೆರಿ, ಉತ್ತರದಾತ, ಕೋಡ್ ಮತ್ತು ರಿಜಾಲ್ವ್ ಆದ ವಿಳಾಸ. ಆ ದಾಖಲೆಯೇ ನಂತರದ ವರದಿಯನ್ನು ಪರಿಶೀಲನೀಯವಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ರೋಗನಿರ್ಣಯ ಮತ್ತು ನಿಧಾನವೆಂದು ಕಂಡ ಟನೆಲ್ ಕುರಿತ ಕಥೆಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸ.