VPN ಮೇಲೆ BIND: ಷರತ್ತುಬದ್ಧ ಮುಂದುವರಿಕೆ ಅಥವಾ ಸ್ಟಬ್ ವಲಯ?
VPN ಮೂಲಕ ಒಂದು ಖಾಸಗಿ ವಲಯವನ್ನು ಪರಿಹರಿಸುವ ಮೂರು ಮಾರ್ಗಗಳು ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಯಾವಾಗ ಸೂಕ್ತ: ಫಾರ್ವರ್ಡ್, ಸ್ಟಬ್ ಅಥವಾ ಸೆಕೆಂಡರಿ, ಜೊತೆಗೆ ಮೂಲ-ವಿಳಾಸದ ಪರಿಶೀಲನೆ.
ನಿಮ್ಮ ಕಚೇರಿ ರಿಜಾಲ್ವರ್ ಒಂದು ಕಾರ್ಪೊರೇಟ್ ನಾಮಸ್ಥಳವನ್ನು ಹೊರತುಪಡಿಸಿ ಎಲ್ಲದಕ್ಕೂ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ತಿಳಿದಿರುವ ಕಾರ್ಪೊರೇಟ್ DNS ಸರ್ವರ್ VPN ಹಿಂದೆ ಇದೆ. BIND ಆ ಒಂದೇ ವಲಯವನ್ನು ಅಪ್ಸ್ಟ್ರೀಮ್ಗೆ ಮೂರು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಒಪ್ಪಿಸಬಹುದು, ಮತ್ತು ಅವು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ಷರತ್ತುಬದ್ಧ ಮುಂದುವರಿಕೆ ಅತಿ ಚಿಕ್ಕ ಬದ್ಧತೆ, ಸ್ಟಬ್ ವಲಯ ಡೆಲಿಗೇಶನ್ ಡೇಟಾವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಸೆಕೆಂಡರಿ ಪೂರ್ಣ ಪ್ರತಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಅಪ್ಸ್ಟ್ರೀಮ್ ಏನು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ರಿಜಾಲ್ವರ್ ಏನನ್ನು ಇಟ್ಟುಕೊಳ್ಳಬೇಕೆಂದು ನೀವು ಬಯಸುತ್ತೀರಿ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಆಯ್ಕೆಮಾಡಿ, ನೀವು ಮೊದಲು ಕಂಡ ಸ್ನಿಪೆಟ್ ಆಧಾರದ ಮೇಲೆ ಅಲ್ಲ.
ಒಂದು ನಾಮಸ್ಥಳಕ್ಕೆ ಮೂರು ವ್ಯವಸ್ಥೆಗಳು
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
ಷರತ್ತುಬದ್ಧ ಮುಂದುವರಿಕೆ: ಅತಿ ಚಿಕ್ಕ ಬದ್ಧತೆ
ಕಚೇರಿ ರಿಜಾಲ್ವರ್ 192.168.10.53 ನಲ್ಲಿ ಮತ್ತು ಕಾರ್ಪೊರೇಟ್ ಸರ್ವರ್ 10.40.0.53 ನಲ್ಲಿ, ಅನುಮೋದಿತ ಟನೆಲ್ ಮೂಲಕ ತಲುಪಬಹುದು ಎಂದು ಭಾವಿಸಿ. ಘೋಷಣೆ ಮೂರು ಸಾಲುಗಳು, ಮತ್ತು ಆಸಕ್ತಿಕರವಾದದ್ದು forward only, ಏಕೆಂದರೆ ಅದು ಮಾರ್ಗವನ್ನಲ್ಲ, ವಿಫಲತೆಯ ವರ್ತನೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ.
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};
forward only ಜೊತೆಗೆ, ತಲುಪಲಾಗದ ಅಪ್ಸ್ಟ್ರೀಮ್ ಈ ವಲಯಕ್ಕೆ ಪುನರಾವರ್ತಿತ ಪರಿಹಾರಕ್ಕೆ ಹಿಂತಿರುಗುವ ಬದಲು SERVFAIL ನೀಡುತ್ತದೆ. ಖಾಸಗಿ ನಾಮಸ್ಥಳಕ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಇದೇ ಬೇಕು, ಏಕೆಂದರೆ ಹಿಂತಿರುಗುವಿಕೆ ಖಾಸಗಿ ಹೆಸರುಗಳನ್ನು ಸಾರ್ವಜನಿಕ ರಿಜಾಲ್ವರ್ಗೆ ಕಳುಹಿಸಿ ಇಂಟರ್ನೆಟ್ನಿಂದ ನಿಷ್ಪ್ರಯೋಜಕ ಉತ್ತರವನ್ನು ತರುತ್ತಿತ್ತು. BIND ಉಲ್ಲೇಖ ಎರಡೂ ನೀತಿಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ವ್ಯತ್ಯಾಸವು ಸ್ನಿಪೆಟ್ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ. ಅದೇ ಹೆಸರಿಗೆ ಈಗಾಗಲೇ ಇರುವ ವಲಯವನ್ನು ಬದಲಿಸುವ ಬದಲು ವಲಯವನ್ನು ಇರುವ ಸಂರಚನೆಗೆ ವಿಲೀನಗೊಳಿಸಿ.
ಸ್ಟಬ್ ಅಥವಾ ಸೆಕೆಂಡರಿ: ಡೆಲಿಗೇಶನ್ ಮುಖ್ಯವಾದಾಗ
ಸ್ಟಬ್ ವಲಯವು ಕಾರ್ಪೊರೇಟ್ ಸರ್ವರ್ನಿಂದ ವಲಯದ NS ದಾಖಲೆಗಳನ್ನು ಕೇಳಿ ನಂತರ ಅಧಿಕೃತ ಸರ್ವರ್ಗಳನ್ನು ನೇರವಾಗಿ ಕೇಳುತ್ತದೆ. ಅಪ್ಸ್ಟ್ರೀಮ್ ಪ್ರದೇಶ ದೊಡ್ಡದಾಗಿದ್ದಾಗ ಅಥವಾ ವಿಭಜಿಸಲ್ಪಟ್ಟಾಗ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಒಂದೇ ವಿಳಾಸಕ್ಕೆ ಬಿಗಿಯುವ ಬದಲು ನಿಮ್ಮ ರಿಜಾಲ್ವರ್ ಡೆಲಿಗೇಶನ್ ಅನ್ನು ಅನುಸರಿಸಬೇಕೆಂದು ಬಯಸಿದಾಗ ಇದನ್ನು ಆಯ್ಕೆಮಾಡಿ. ಬೆಲೆ ಎಂದರೆ NS ಡೇಟಾ ತಾಜಾವಾಗಿರುವುದರ ಮೇಲಿನ ಅವಲಂಬನೆ ಮತ್ತು ಪಟ್ಟಿ ಮಾಡಿದ ಪ್ರತಿ ನೇಮ್ಸರ್ವರ್ ನಿಮ್ಮ ರಿಜಾಲ್ವರ್ನ ಮೂಲ-ವಿಳಾಸದಿಂದ ತಲುಪಬಹುದಾಗಿರುವುದರ ಮೇಲಿನ ಅವಲಂಬನೆ.
zone "corp.example" {
type stub;
masters { 10.40.0.53; };
};
zone "corp.example" {
type secondary;
primaries { 10.40.0.53; };
file "corp.example.db";
};
ಸೆಕೆಂಡರಿ ಸ್ಥಳೀಯ ಡೇಟಾದಿಂದ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಸ್ಟ್ರೀಮ್ ವಿರಾಮವನ್ನು ತಾಳಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ವರ್ಗಾವಣೆ ಅವಲಂಬನೆಯನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಬಹುದು. ಇದರರ್ಥ ನಿಮ್ಮ ರಿಜಾಲ್ವರ್ ಈಗ ತನ್ನದಲ್ಲದ ವಲಯದ ಪ್ರತಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಫೈಲ್ ಮಾರ್ಗ, ಪ್ರಾಥಮಿಕದಲ್ಲಿನ ವರ್ಗಾವಣೆ ACL ಮತ್ತು ರಿಫ್ರೆಶ್ ಟೈಮರ್ಗಳು ನಿಮ್ಮ ಕಾರ್ಯಾಚರಣಾ ಮೇಲ್ಮೈಯ ಭಾಗವಾಗುತ್ತವೆ.
ಅವುಗಳ ನಡುವೆ ನಿರ್ಣಯಿಸುವ ಪರಿಶೀಲನೆ
BIND ತನ್ನ ಹೊರಹೋಗುವ ಪ್ರಶ್ನೆಯನ್ನು ತಾನೇ ರಚಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರಶ್ನೆ ಲ್ಯಾಪ್ಟಾಪ್ 10.40.0.53 ತಲುಪಬಹುದೇ ಎಂಬುದಲ್ಲ, ರಿಜಾಲ್ವರ್ ಹೋಸ್ಟ್ ಕಾರ್ಪೊರೇಟ್ ಸರ್ವರ್ ನೋಡುವ ಮೂಲ-ವಿಳಾಸದಿಂದ ತಲುಪಬಹುದೇ ಎಂಬುದು. ಮೊದಲು ಕರ್ನೆಲ್ಗೆ ಕೇಳಿ, ನಂತರ ಸರ್ವರ್ಗೆ, ಆ ಕ್ರಮದಲ್ಲಿ.
ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example
ಮಾರ್ಗದಲ್ಲಿ UDP ಮತ್ತು TCP ಗೆ ಅನುಮತಿ ನೀಡಿ: ಕತ್ತರಿಸಿದ ಉತ್ತರ TCP ಅನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ, ಮತ್ತು UDP ಮಾತ್ರ ಅನುಮತಿಸುವ ನೀತಿ ಪ್ಯಾಕೆಟ್ ನಷ್ಟದಂತೆ ಕಾಣುವ ಮಧ್ಯಂತರ ವೈಫಲ್ಯಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಕಾರ್ಪೊರೇಟ್ ಬದಿಗೆ ನಿಮ್ಮ ರಿಜಾಲ್ವರ್ನ ಮೂಲಕ್ಕೆ ಸ್ವೀಕಾರ ನಿಯಮ ಮತ್ತು ಅಲ್ಲಿಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಎರಡೂ ಬೇಕು; ಆ ಮೂಲ ರಿಜಾಲ್ವರ್ನ ರೂಟ್ ಆದ ವಿಳಾಸ ಅಥವಾ ಸ್ಪಷ್ಟವಾಗಿ ಅನುವಾದಿಸಿದ ವಿಳಾಸ ಆಗಿರಬಹುದು, ಮತ್ತು ಅದು ಅಪರೂಪಕ್ಕೆ ಕ್ಲೈಂಟ್ ಪೂಲ್ನ ವಿಳಾಸ. NS ಪ್ರಶ್ನೆ ವಿಫಲವಾದರೆ, ಫಾರ್ವರ್ಡ್ ವಲಯ ಹೇಗೇ ವರ್ತಿಸಿದರೂ ಸ್ಟಬ್ ವಲಯ ಕೆಲಸ ಮಾಡಲಾರದು.
ಟನೆಲ್ ಅಲ್ಲ, ಉತ್ತರವನ್ನು ಪರಿಶೀಲಿಸಿ
ನೀವು ಎಂದೂ ಕೇಳದ ಹೆಸರಿಗೆ ಕಚೇರಿ ರಿಜಾಲ್ವರ್ ಮೂಲಕ ಪ್ರಶ್ನೆ ಮಾಡಿ, ಮತ್ತು ಉತ್ತರದ authority ಭಾಗವನ್ನು ನೋಡಿ ಅದು ಕಾರ್ಪೊರೇಟ್ ವಲಯದಿಂದ ಬಂದಿದೆಯೇ ಎಂದು ತಿಳಿಯಿರಿ. ಕ್ಯಾಶ್ನಲ್ಲಿರುವ ಉತ್ತರ ಪ್ರಸ್ತುತ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅಪ್ಸ್ಟ್ರೀಮ್ಗೆ ನೇರವಾದ ಯಶಸ್ವಿ ಪ್ರಶ್ನೆ ನಿಮ್ಮ ರಿಜಾಲ್ವರ್ ಆ ವಲಯವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಅದೇ ಪ್ರಶ್ನೆಯನ್ನು TCP ಮೇಲೆ ಪುನರಾವರ್ತಿಸಿ ಮಾರ್ಗವು ಕತ್ತರಿಸುವಿಕೆಯನ್ನು ತಾಳಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.
ಕ್ಲೈಂಟ್ಗಳನ್ನು ಕಚೇರಿ ರಿಜಾಲ್ವರ್ನತ್ತ ಇರಿಸಿ, ಮತ್ತು DNSSEC ಪರಿಶೀಲನೆಯನ್ನು ಆನ್ ಆಗಿರಿಸಿ. ಸ್ವತಂತ್ರ ಎನ್ಕ್ರಿಪ್ಟೆಡ್ ರಿಜಾಲ್ವರ್ನೊಂದಿಗೆ ಸಂರಚಿಸಿದ ಬ್ರೌಸರ್ ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅನಿರೀಕ್ಷಿತ ಉತ್ತರ ಸರಿಯಾಗಿ ಕಾಣಲು ಪರಿಶೀಲನೆಯನ್ನು ಆಫ್ ಮಾಡುವುದು ಕಾಣುವ ವೈಫಲ್ಯವನ್ನು ಕಾಣದ ವೈಫಲ್ಯಕ್ಕೆ ಬದಲಿಸುತ್ತದೆ.
ಮೂರರಲ್ಲಿ ಯಾವ ಪ್ರಕಾರವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದಿರಿ ಮತ್ತು ಏಕೆ ಎಂದು ಬರೆಯಿರಿ. ವಲಯ ವಿಫಲವಾಗುವುದನ್ನು ನೋಡುವ ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಸಂರಚನಾ ಫೈಲ್ಗಿಂತ ಆ ವಾಕ್ಯ ಹೆಚ್ಚು ಬೇಕಾಗುತ್ತದೆ.