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

ಉತ್ತರವನ್ನು ಸ್ವೀಕರಿಸುವುದು ಮತ್ತು ಅದನ್ನು ಹಿಂತಿರುಗಿಸಲು ಆರಿಸುವುದು ಎರಡು ಬೇರೆ ಬೇರೆ ಹಂತಗಳು.

ಎರಡೂ ರಿಜಾಲ್ವರ್‌ಗಳಲ್ಲಿ ಅದೇ ಹೆಸರನ್ನು ಹೋಲಿಸಿ

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

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

ಲಕ್ಷಣವನ್ನಲ್ಲ, ನಿರಾಕರಣೆಯನ್ನು ಓದಿ

dnsmasq ನ stop-dns-rebind ಆಯ್ಕೆಯು ಮೇಲಿನಿಂದ ಬರುವ ಮತ್ತು ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸುವ ಖಾಸಗಿ ವಿಳಾಸದ ಉತ್ತರಗಳನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ ಮತ್ತು ಹಾಗೆ ಮಾಡುವಾಗ ಅವನ್ನು ಲಾಗ್‌ನಲ್ಲಿ ದಾಖಲಿಸುತ್ತದೆ. ಈ ರಕ್ಷಣೆ ಒಂದು ಒಳ್ಳೆಯ ಕಾರಣಕ್ಕಾಗಿ ಇದೆ: ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ತಿರುಗುವ ಸಾರ್ವಜನಿಕ ಹೆಸರೇ ಸಾಂಪ್ರದಾಯಿಕ rebinding ದಾಳಿ. ಆದರೆ ಇದು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಖಾಸಗಿ ಸೇವೆಯೊಂದಿಗೂ ಘರ್ಷಿಸುತ್ತದೆ, ಅದೇ ನಿಮ್ಮ ಸಂದರ್ಭ.

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಲಾಗ್‌ನಲ್ಲಿ ನಿರಾಕರಣೆಯನ್ನು ಹುಡುಕಿ, ಏಕೆಂದರೆ ಸಂದೇಶವು ಕಾರ್ಯವಿಧಾನವನ್ನು ಹೆಸರಿಸುತ್ತದೆ.

ನಿರಾಕರಣೆಯೂ ಇಲ್ಲದೆ, ಮೇಲಿನಿಂದ ಉತ್ತರವೂ ಇಲ್ಲದೆ ಇದ್ದರೆ, rebinding ರಕ್ಷಣೆ ನಿಮ್ಮ ಸಮಸ್ಯೆ ಅಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಆಫ್ ಮಾಡುವುದು ಏನನ್ನೂ ಸರಿಪಡಿಸದ, ಅಪಾಯವನ್ನು ಹೆಚ್ಚಿಸುವ ಬದಲಾವಣೆಯಾಗುತ್ತದೆ. ಇದು ಮೂಲ ದೋಷಕ್ಕಿಂತ ಕೆಟ್ಟದು, ಏಕೆಂದರೆ ಒಂದು ನಿಯಂತ್ರಣವನ್ನು ತೆಗೆದು ದೋಷವನ್ನು ಹಾಗೆಯೇ ಬಿಡುತ್ತದೆ. ಮೊದಲು ನಿರ್ದಿಷ್ಟ ಲಾಗ್ ಸಾಲನ್ನು ಖಚಿತಪಡಿಸಿ. ನಂತರ ನಿರ್ಧರಿಸಿ.

ವಿನಾಯಿತಿಯನ್ನು ಒಂದೇ ಡೊಮೇನ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಿ

ಪರಿಶೀಲಿಸಿದ ಡೊಮೇನ್‌ಗಾಗಿ dnsmasq ಕೈಪಿಡಿಯು ಜಾಗತಿಕ ಸ್ವಿಚ್‌ ಬದಲಿಗೆ ಡೊಮೇನ್-ಸೀಮಿತ ವಿನಾಯಿತಿಯನ್ನು ನೀಡುತ್ತದೆ.

rebind-domain-ok=corp.example

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

rebinding ಪತ್ತೆಗೆ ಮಾಡುವ ವಿನಾಯಿತಿ ನಿಖರವಾಗಿ ಒಂದು ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಆ ಡೊಮೇನ್‌ನ ಉತ್ತರಗಳನ್ನು ದಾಟಲು ಬಿಡುತ್ತದೆ.

ಅದು split-DNS ಫಾರ್ವರ್ಡರ್ ಅನ್ನು ಸಂರಚಿಸುವುದಿಲ್ಲ, ತಲುಪಲಾಗದ ಮೇಲಿನ ಮೂಲವನ್ನು ತಲುಪಬಹುದಾದಂತೆ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಹಿಂತಿರುಗಿಸಿದ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಇವು ಒಂದೊಂದೂ ಪ್ರತ್ಯೇಕ ಅಗತ್ಯವಾಗಿದ್ದು ಅದರದೇ ವೈಫಲ್ಯದ ಗುರುತನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಒಂದೊಂದೂ ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಬೇರೆಯಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ.

ಗಡಿಯನ್ನು ತೆಗೆಯದೆ ಪರಿಶೀಲಿಸಿ

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

ವಿನಾಯಿತಿಯ ಕಾರಣವನ್ನು ಸಂರಚನೆಯ ಪಕ್ಕದಲ್ಲಿ, ದಿನಾಂಕ ಮತ್ತು ಜವಾಬ್ದಾರರೊಂದಿಗೆ ಇರಿಸಿ.

ಖಾಸಗಿ ಸೇವೆ ಸ್ಥಳಾಂತರಗೊಂಡಾಗ ಅಥವಾ ಡೊಮೇನ್ ಬದಲಾದಾಗ ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ. ರಕ್ಷಣೆಯನ್ನು ಜಾಗತಿಕವಾಗಿ ಆಫ್ ಮಾಡುವುದು ಸಂಬಂಧವಿಲ್ಲದ ಉತ್ತರಗಳ ನಿರ್ವಹಣೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು rebinding ಎಂದೂ ಕಾರಣವಾಗದಿದ್ದರೆ ಮಾರ್ಗ ಅಥವಾ ಸೇವೆಯ ದೋಷವನ್ನು ಹಾಗೆಯೇ ಬಿಡುತ್ತದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು