ಎರಡು ಸೈಟ್‌ಗಳು, ಒಂದು ಖಾಸಗಿ DNS ವಲಯ: ದಾಖಲೆಗಳು ಯಾರಿಗೆ ಸೇರಿವೆ?

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

ರೋಗಲಕ್ಷಣವು ಕಾಣೆಯಾದ ಮಾಲೀಕನನ್ನು ಹೆಸರಿಸುತ್ತದೆ

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

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

ಆದ್ದರಿಂದ ವಿನ್ಯಾಸದ ಪ್ರಶ್ನೆ ಸಂಕುಚಿತ ಮತ್ತು ಉತ್ತರಿಸಬಹುದಾದದ್ದು: ದಾಖಲೆಯನ್ನು ಯಾರು ರಚಿಸಬಹುದು, ಮತ್ತು ಆ ದಾಖಲೆ ಅದಕ್ಕೆ ಉತ್ತರಿಸಬೇಕಾದ ಪ್ರತಿ ರೆಸಾಲ್ವರ್‌ಗೆ ಹೇಗೆ ತಲುಪುತ್ತದೆ?

ಆಯ್ಕೆ A: ದ್ವಿತೀಯಗಳೊಂದಿಗೆ ಒಂದು ಅಧಿಕೃತ ವಲಯ

internal.example.com ಗಾಗಿ ಪ್ರಾಥಮಿಕವನ್ನು ಚಲಾಯಿಸಿ ಮತ್ತು ಬೆಂಬಲಿತ ದ್ವಿತೀಯಗಳು ಪ್ರತಿ ಸೈಟ್‌ನಲ್ಲಿ ವಲಯವನ್ನು ಪಡೆಯಲು ಅನುಮತಿಸಿ. ಪ್ರತಿ ಸೈಟ್‌ನ ಪುನರಾವರ್ತಿತ ರೆಸಾಲ್ವರ್ ತನ್ನ ಸ್ಥಳೀಯ ದ್ವಿತೀಯಕ್ಕೆ ಕೇಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಉತ್ತರಗಳು ಕ್ಯಾಶ್‌ನಿಂದ ಅಲ್ಲ, ಅಧಿಕೃತ ಮೂಲದಿಂದ ಬರುತ್ತವೆ, ಮತ್ತು ಒಮ್ಮೆ ಮಾಡಿದ ಬದಲಾವಣೆಯನ್ನು ಮತ್ತೆ ಟೈಪ್ ಮಾಡುವ ಬದಲು ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ.

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

ವಲಯ ವರ್ಗಾವಣೆಗಳನ್ನು ವಿಳಾಸದ ಮೂಲಕ ತಿಳಿದಿರುವ ದ್ವಿತೀಯಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ ಮತ್ತು ಅನುಷ್ಠಾನವು ಬೆಂಬಲಿಸುವ ಸ್ಥಳಗಳಲ್ಲಿ ವಹಿವಾಟು ಸಹಿಗಳನ್ನು ಬಳಸಿ. ಮುಕ್ತ ವರ್ಗಾವಣೆ ಎಂದರೆ ಪೋರ್ಟ್ ತಲುಪಬಲ್ಲ ಯಾರಿಗಾದರೂ ನಿಮ್ಮ ಆಂತರಿಕ ನಾಮಸ್ಥಳದ ಪ್ರತಿ.

ಬೆಲೆ ಸಮನ್ವಯ: ಒಂದು ಸಂಪಾದನಾ ಮಾರ್ಗ, ಒಂದು ಬದಲಾವಣೆ ಪರಿಶೀಲನೆ, ಮತ್ತು ದಾಖಲೆ ತಪ್ಪಾದಾಗ ಯಾರು ಕರ್ತವ್ಯದಲ್ಲಿದ್ದಾರೆ ಎಂಬ ಹಂಚಿದ ತಿಳುವಳಿಕೆ.

ಆಯ್ಕೆ B: ಪ್ರತಿ ಸೈಟ್‌ಗೆ ಒಂದು ಉಪಡೊಮೇನ್

ಹಸಿರು ಸೈಟ್‌ಗೆ green.internal.example.com ಮತ್ತು ಹಳದಿ ಸೈಟ್‌ಗೆ yellow.internal.example.com ನಿಯೋಜಿಸಿ. ಪ್ರತಿ ಸೈಟ್ ತನ್ನದೇ ಹೆಸರುಗಳಿಗೆ ಅಧಿಕೃತವಾಗುತ್ತದೆ, ಮತ್ತು ಮೂಲ ವಲಯವು ನಿಯೋಜನಾ ದಾಖಲೆಗಳನ್ನು ಮಾತ್ರ ಹೊತ್ತಿರುತ್ತದೆ. ಒಂದು ಫೈಲ್‌ಗಾಗಿ ಸ್ಪರ್ಧೆ ಮಾಯವಾಗುತ್ತದೆ, ಮತ್ತು ಸ್ಥಳೀಯ ತಂಡವು ಕೇಂದ್ರೀಯ ಬದಲಾವಣೆಗಾಗಿ ಕಾಯದೆ ಹೋಸ್ಟ್ ಸೇರಿಸಬಹುದು.

ನಿಯೋಜನೆ ಮೂಲ ವಲಯದಲ್ಲಿ ಇರಬೇಕು, ಸೈಟ್‌ನ ಅಧಿಕೃತ ಸರ್ವರ್‌ಗಳಿಗೆ ತೋರಿಸುವ NS ದಾಖಲೆಗಳೊಂದಿಗೆ. ಪೂರ್ಣ ನಿಯೋಜನೆ ಅಪ್ರಾಯೋಗಿಕವಾದಾಗ ಉಪಡೊಮೇನ್‌ಗೆ ಷರತ್ತುಬದ್ಧ ಫಾರ್ವರ್ಡ್ ಮಾನ್ಯ ಪರ್ಯಾಯವಾಗಿದೆ, ಆದರೆ ಅದು ರೆಸಾಲ್ವರ್ ಸೆಟ್ಟಿಂಗ್, ಪ್ರಕಟಿತ ಸತ್ಯವಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರತಿ ರೆಸಾಲ್ವರ್‌ಗೆ ಅದೇ ನಿಯಮ ಬೇಕು.

ವೆಚ್ಚ ಮಾಯವಾಗುವ ಬದಲು ಸ್ಥಳಾಂತರಗೊಳ್ಳುತ್ತದೆ: ಮೂಲ ವಲಯಕ್ಕೆ ಇನ್ನೂ ಮಾಲೀಕ ಬೇಕು, ಮತ್ತು ಹೊಸ ಸೈಟ್ ರಚಿಸುವುದು ಈಗ ಒಂದರ ಬದಲು ಎರಡು ಸ್ಥಳಗಳಲ್ಲಿ ಬದಲಾವಣೆ.

ಪ್ರತಿ ರೆಸಾಲ್ವರ್ ಆಯ್ಕೆಯನ್ನು ಅನುಸರಿಸಲಿ

ಬೆಂಬಲಿತ ಸಂರಚನೆಯ ಮೂಲಕ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಅನುಮೋದಿತ ರೆಸಾಲ್ವರ್ ಮತ್ತು ಹುಡುಕಾಟ ಡೊಮೇನ್ ನೀಡಿ, ಮತ್ತು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ ರೆಸಾಲ್ವರ್‌ಗೆ ಕೇಳಬೇಕಾದ ಯಾವುದೇ ದೂರದ DNS ಸರ್ವರ್‌ಗೆ ಅನುಮತಿಸಲಾದ VPN ಮಾರ್ಗವಿದೆ. ಈ ಉತ್ತರಗಳು ಹಿಂತಿರುಗಿಸುವ ಖಾಸಗಿ ವಿಳಾಸಗಳಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೂ ಮಾರ್ಗಗಳು ಬೇಕು, ಏಕೆಂದರೆ ಮಾರ್ಗವಿಲ್ಲದ ಸರಿಯಾದ ಹೆಸರೂ ಮುರಿದ ಸಂಪರ್ಕವೇ.

Pi-hole ಸ್ಥಳೀಯ ಪರಿಹಾರವನ್ನು ಒದಗಿಸಿದರೆ, ಯಾವ ದಾಖಲೆಗಳು ಅದರ ಮಾಲೀಕತ್ವದಲ್ಲಿವೆ ಮತ್ತು ಯಾವ ಪ್ರಶ್ನೆಗಳನ್ನು ಅದು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ. ಎರಡು ಸ್ವತಂತ್ರವಾಗಿ ಸಂಪಾದಿಸಿದ Pi-hole ಪಟ್ಟಿಗಳು ಇನ್ನೂ ಪ್ರತಿಕೃತಿಯಾಗುವುದಿಲ್ಲ. Pi-hole v6 ನಲ್ಲಿ ಕಸ್ಟಮ್ dnsmasq ಸಾಲುಗಳನ್ನು TOML, CLI ಅಥವಾ ಪರಿಸರ ಚರಗಳಂತಹ ಹೋಸ್ಟ್-ಬದಿ ಆಯ್ಕೆಗಳ ಮೂಲಕ ಹೊಂದಿಸಲಾಗುತ್ತದೆ ಮತ್ತು API ಮೂಲಕ ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ; /etc/dnsmasq.d/ ಫೈಲ್‌ಗಳನ್ನು ಲೋಡ್ ಮಾಡುವುದು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಆಫ್ ಆಗಿರುವ ಪ್ರತ್ಯೇಕ ಆಯ್ಕೆ.

ನಂತರ ಎಲ್ಲೆಡೆ ಕಾಣಬೇಕಾದ ಹೆಸರಿನೊಂದಿಗೆ ಎರಡೂ ಬದಿಗಳಿಂದ ಪರೀಕ್ಷಿಸಿ:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

SOA ಉತ್ತರವು ಹಳದಿ ರೆಸಾಲ್ವರ್ ತನ್ನನ್ನು ಅಧಿಕೃತ ಎಂದು ಭಾವಿಸುತ್ತದೆಯೇ, ದ್ವಿತೀಯವನ್ನು ಕೇಳುತ್ತಿದೆಯೇ, ಅಥವಾ ಕೇವಲ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತಿದೆಯೇ ಎಂಬುದನ್ನು ತಿಳಿಸುತ್ತದೆ. ಇವು ವಿಭಿನ್ನ ವೈಫಲ್ಯ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿರುವ ವಿಭಿನ್ನ ವಿನ್ಯಾಸಗಳು, ಮತ್ತು ಉತ್ತರವು ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ನಿಜವಾಗಿ ಯಾವುದನ್ನು ನಿಯೋಜಿಸಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಗುರುತಿಸುತ್ತದೆ.

ಮೂರು ಸ್ವೀಕಾರ ಪ್ರಕರಣಗಳೊಂದಿಗೆ ಮುಗಿಸಿ: ಪ್ರತಿ ಸೈಟ್‌ನಿಂದ ಒಂದು ಹೆಸರು, ಒಂದು ಗಂಟೆಯೊಳಗೆ ಬದಲಾದ ಒಂದು ದಾಖಲೆ, ಮತ್ತು ಸೈಟ್‌ಗಳ ನಡುವಿನ ಕೊಂಡಿ ಲಭ್ಯವಿಲ್ಲದಿರುವುದು. ಮೊದಲನೆಯದನ್ನು ಮಾತ್ರ ಪಾಸ್ ಮಾಡುವ ವಿನ್ಯಾಸವು ಕಾಗದದ ಮೇಲೆ ಪ್ರಕಟಣಾ ಯೋಜನೆ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸ್ಥಳೀಯ ಓವರ್‌ರೈಡ್ ಹೊಂದಿದೆ.