ನಿಜವಾದ ಮೂಲವನ್ನು ಕಂಡುಹಿಡಿಯಲು DNS ಪ್ರಶ್ನೆಯನ್ನು ಹೆಜ್ಜೆ ಹೆಜ್ಜೆಯಾಗಿ ಅನುಸರಿಸಿ
ತಳ್ಳಲಾದ ರಿಸಾಲ್ವರ್ ವಿಳಾಸ ರಿಸಾಲ್ವರ್ ಯಾವ ಮೂಲವನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್, ಫಾರ್ವರ್ಡರ್ ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಸರ್ವರ್ ಅನ್ನು ಅನುಸರಿಸಿ, ನಂತರ ಮಾರ್ಗವನ್ನು ಬರೆಯಿರಿ.
ಕ್ಲೈಂಟ್ಗೆ ರಿಸಾಲ್ವರ್ ವಿಳಾಸ ನೀಡುವುದು ಪ್ರಶ್ನೆಗಳು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ರಿಸಾಲ್ವರ್ ಯಾವ ಮೂಲವನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನಲ್ಲ. ರೂಟಿಂಗ್, ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಅನುವಾದ ಎರಡು ತುದಿಗಳ ನಡುವೆ ಸರದಿಯಾಗಿ ಬರುತ್ತವೆ. ಮೂಲದ ಬಗ್ಗೆ ಇರುವ ಪ್ರಶ್ನೆಗಳಿಗೆ ರನ್ಬುಕ್ ಪ್ರಶ್ನೆಯನ್ನು ಹೆಜ್ಜೆ ಹೆಜ್ಜೆಯಾಗಿ ಅನುಸರಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ವೀಕ್ಷಕನು ನಿಜವಾಗಿ ಏನನ್ನು ನೋಡಿದನು ಎಂಬುದನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಕ್ರಮ ಮುಖ್ಯ, ಏಕೆಂದರೆ ವೀಕ್ಷಣೆಗೆ ಮೊದಲು ಹೇಳಿದ ಪ್ರತಿಪಾದನೆ ಉತ್ತಮ ಸ್ವರೂಪದ ಊಹೆ ಮಾತ್ರ.
ಸಾಕ್ಷ್ಯ ಸಂಗ್ರಹಿಸುವ ಮೊದಲು ವ್ಯವಸ್ಥೆಯನ್ನು ಬರೆಯಿರಿ
ನಾಲ್ಕು ಸ್ಥಳಗಳು DNS ಮೂಲದ ಬಗ್ಗೆ ನಿಮಗೆ ಏನನ್ನಾದರೂ ಹೇಳಬಹುದು, ಎಲ್ಲವೂ ಒಂದೇ ವಿಷಯ ಹೇಳುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ ಕರ್ನಲ್ ಯಾವ ಮೂಲವನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ತಿಳಿದಿದೆ, ಫಾರ್ವರ್ಡರ್ ಮೇಲೆ ಏನು ಕಳುಹಿಸಿತು ಎಂದು ತಿಳಿದಿದೆ, ಅನುವಾದಿಸುವ ಸಾಧನ ಏನನ್ನು ಮತ್ತೆ ಬರೆಯಿತು ಎಂದು ತಿಳಿದಿದೆ, ಸ್ವೀಕರಿಸುವ ರಿಸಾಲ್ವರ್ ಏನು ಬಂದಿತು ಎಂದು ತಿಳಿದಿದೆ. ಏನನ್ನಾದರೂ ಸಂಗ್ರಹಿಸುವ ಮೊದಲು ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನು ನೀವು ನಿಜವಾಗಿ ತಲುಪಬಹುದು ಎಂದು ಬರೆಯಿರಿ.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
ನಿಮ್ಮ ನಿರೀಕ್ಷೆಯನ್ನೂ ಬರೆಯಿರಿ, ಬಳಕೆಯಲ್ಲಿದೆ ಎಂದು ನೀವು ಭಾವಿಸುವ ರಿಸಾಲ್ವರ್ ಸೇರಿದಂತೆ. ವಿಭಜಿತ ಮಾರ್ಗ ಪ್ರಶ್ನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆಡೆಗೆ ಕಳುಹಿಸಬಹುದು, ಕ್ಯಾಶ್ ಯಾವುದೇ ಮೇಲ್ಮುಖ ವಿನಿಮಯವಿಲ್ಲದೆ ಉತ್ತರಿಸಬಹುದು, ಆದ್ದರಿಂದ ಕೇವಲ ನೆನಪಿನಲ್ಲಿ ಇಟ್ಟುಕೊಂಡ ಊಹೆ ಮೊದಲ ಆಶ್ಚರ್ಯದವರೆಗೂ ನಿಲ್ಲುವುದಿಲ್ಲ. ಘೋಷಿತ ವಿನ್ಯಾಸ ಮತ್ತು ಗಮನಿಸಿದ ಮಾರ್ಗವನ್ನು ಒಂದೇ ಟಿಪ್ಪಣಿಯ ಬೇರೆ ಬೇರೆ ಕಾಲಮ್ಗಳಲ್ಲಿ ಇರಿಸಿ; ಎರಡೂ ಹೊಂದಿಕೆಯಾಗದಿದ್ದಾಗ, ನೀವು ಅನುಸರಿಸಲು ಯೋಗ್ಯವಾದ ಪ್ರಶ್ನೆಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ.
ಪ್ರಶ್ನೆಯನ್ನು ನಿಜವಾಗಿ ಯಾವ ಪ್ರಕ್ರಿಯೆ ಕಳುಹಿಸಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ
ಕ್ಲೈಂಟ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ: ರಿಸಾಲ್ವರ್ ವಿಳಾಸ, ಪ್ರಶ್ನೆಯ ಹೆಸರು ಮತ್ತು ಸಮಯವನ್ನು ದಾಖಲಿಸಿ, ನಂತರ ಯಾವ ಪ್ರಕ್ರಿಯೆ ಕಳುಹಿಸಿತು ಎಂದು ಖಚಿತಪಡಿಸಿ. ಕೆಳಗಿನ ಮೊದಲ ಸಾಲು UDP ಸಾಕೆಟ್ ಹೊಂದಿರುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಇದೇ ಈ ಶೀರ್ಷಿಕೆ ಭರವಸೆ ನೀಡುವ ಪರಿಶೀಲನೆ. ಆ ಪ್ರಕ್ರಿಯೆ ಸಿಸ್ಟಮ್ ರಿಸಾಲ್ವರ್ ಬದಲು ಬ್ರೌಸರ್ ಸಹಾಯಕ ಅಥವಾ ಕಂಟೇನರ್ ರನ್ಟೈಮ್ ಆಗಿದ್ದರೆ, ಉಳಿದ ಜಾಡು ಯಾರೂ ಕೇಳದ ಮಾರ್ಗವನ್ನು ವಿವರಿಸುತ್ತದೆ.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53ಹಲವು ಇಂಟರ್ಫೇಸ್ಗಳಿರುವ ಹೋಸ್ಟ್ನಲ್ಲಿ, ಬೇರೆಡೆ ನೋಡುವ ಮೊದಲು ಕರ್ನಲ್ ಆ ಗಮ್ಯಕ್ಕೆ ಯಾವ ಮೂಲ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ. ಮಾರ್ಗ ಸಂಪೂರ್ಣವಾಗಿ ನಿಮ್ಮ ನಿಯಂತ್ರಣದಲ್ಲಿರುವ ಕೊನೆಯ ಬಿಂದು ಅದು, ಮತ್ತು ರಿಸಾಲ್ವರ್ ವರದಿ ಮಾಡುವುದಕ್ಕೆ ನೀವು ಹೋಲಿಸಲಿರುವ ಮೌಲ್ಯವೂ ಅದೇ. ವ್ಯತ್ಯಾಸ ಎಂದರೆ ಮಧ್ಯದಲ್ಲಿ ಏನೋ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮತ್ತೆ ಬರೆಯಿತು, ಅಥವಾ ಎರಡು ಬೇರೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಳುಹಿಸಲಾಯಿತು ಎಂಬ ಸೂಚನೆ.
ಪರೀಕ್ಷಾ ಹೆಸರುಗಳನ್ನು ಆಂತರಿಕವಾಗಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವರ್ಗೆ ಕಳುಹಿಸಿದ ಆಂತರಿಕ ಹೆಸರು ಆಂತರಿಕ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ ಮತ್ತು ಪ್ರಕಟಿಸುವ ಅಗತ್ಯವಿಲ್ಲದ ಹೆಸರನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ. ಸುರಕ್ಷಿತ DNS ಆನ್ ಆಗಿರುವ ಬ್ರೌಸರ್ ಆ ಸಾಕೆಟ್ ಪಟ್ಟಿಯಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಕಾಣಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಆ ಅನುಪಸ್ಥಿತಿಯೇ ಸ್ವತಃ ಉತ್ತರ.
ಫಾರ್ವರ್ಡರ್ ಎರಡನೇ, ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆ ಮಾಡುತ್ತದೆ
ಫಾರ್ವರ್ಡರ್ ಒಂದು ವಿನಿಮಯವನ್ನು ಎರಡಾಗಿಸುತ್ತದೆ. ಕೆಳಗಿನಿಂದ ವಿನಂತಿ ಬರುತ್ತದೆ, ನಂತರ ಫಾರ್ವರ್ಡರ್ ತಾನು ಆಯ್ಕೆ ಮಾಡುವ ವಿಳಾಸದಿಂದ ತನ್ನ ಪ್ರಶ್ನೆಯನ್ನು ಮೇಲೆ ಕಳುಹಿಸುತ್ತದೆ. ಮೇಲಿನ ರಿಸಾಲ್ವರ್ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ಕ್ಲೈಂಟ್ ಅಲ್ಲ, ಅದರ ಸಂರಚನೆ ನಿರ್ಧರಿಸುತ್ತದೆ.
dnsmasq ಕೈಪಿಡಿ ಇದೇ ಕಾರಣಕ್ಕೆ ಓದಲು ಯೋಗ್ಯವಾಗಿದೆ: ಫಾರ್ವರ್ಡರ್ ಮೇಲಿನ ಸರ್ವರ್ಗಳನ್ನು ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ತನ್ನ ಕೇಳುವ ಭಾಗವನ್ನು ಹೇಗೆ ಕಟ್ಟುತ್ತದೆ ಎಂಬುದನ್ನು ಅದು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಆ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಯಾವುದೂ ಕ್ಲೈಂಟ್ ಮೂಲವನ್ನು ಮೇಲೆ ಒಯ್ಯುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಗೇಟ್ವೇ ವಿಳಾಸವನ್ನು ತೋರಿಸುವ ರಿಸಾಲ್ವರ್ ಲಾಗ್ ಸಾಮಾನ್ಯ, ದೋಷಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಅನುಪಸ್ಥಿತಿಯನ್ನೂ ಅಷ್ಟೇ ಸುಲಭವಾಗಿ ತಪ್ಪಾಗಿ ಓದಬಹುದು, ಏಕೆಂದರೆ ಕ್ಯಾಶ್ ಹಿಟ್ ಯಾವುದೇ ಮೇಲ್ಮುಖ ಪ್ರಶ್ನೆಯನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ ಮತ್ತು ಎಂದೂ ಬಾರದ ಪ್ರಶ್ನೆಯಂತೆಯೇ ಕಾಣುತ್ತದೆ. ಎರಡರಲ್ಲಿ ಯಾವುದೇ ತೀರ್ಮಾನ ತೆಗೆದುಕೊಳ್ಳುವ ಮೊದಲು ಫಾರ್ವರ್ಡರ್ನ ಸಂರಚನೆ ಮತ್ತು ಅದರ ಕ್ಯಾಶ್ ಸ್ಥಿತಿಯನ್ನು ಓದಿ. ಎರಡು ಪ್ರಶ್ನೆಗಳು, ನೋಡಲು ಎರಡು ಸ್ಥಳಗಳು.
ಮೂಲವನ್ನು ಸ್ವೀಕರಿಸುವ ರಿಸಾಲ್ವರ್ನಲ್ಲಿ ಓದಿ
ಇದನ್ನು ನಿರ್ಣಯಿಸುವ ಏಕೈಕ ವೀಕ್ಷಣೆ ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್ನ ಇಂಟರ್ಫೇಸ್ ಪಟ್ಟಿಯಿಂದ ಏನನ್ನು ಅನುಮಾನಿಸಿದರೂ ರಿಸಾಲ್ವರ್ ನಿಜವಾಗಿ ಏನು ಬಂದಿತು ಎಂದು ವರದಿ ಮಾಡುವವರೆಗೆ ಊಹೆಯಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ.
tcpdump -ni any port 53 and host 10.20.30.53ರಿಸಾಲ್ವರ್ ಹೋಸ್ಟ್ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ, ಸೆರೆಯನ್ನು ಚಿಕ್ಕದಾಗಿ ಮತ್ತು ಸೀಮಿತವಾಗಿ ಇರಿಸಿ, ಮತ್ತು ನೀತಿ ಅನುಮತಿಸುವಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ. ಗಮನಿಸಿದ ಮೂಲವು ಅನುವಾದಿತ ವಿಳಾಸವಾಗಿದ್ದರೆ, ಮುಂದಿನ ಪ್ರಶ್ನೆ ಯಾವ ಸಾಧನವು ಅನುವಾದ ಮಾಡಿತು ಮತ್ತು ಅದರ ನೀತಿ ಉದ್ದೇಶಿಸಿದ್ದೇ ಎಂದು. ಸೆರೆ ಏನು ಬಂದಿತು ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ; ನೀತಿ ಏಕೆ ಅನುಮತಿಸಿತು ಎಂದು ವಿವರಿಸುವುದಿಲ್ಲ. ಟಿಪ್ಪಣಿಯಲ್ಲಿ ವೀಕ್ಷಕ ಮತ್ತು ಹೆಜ್ಜೆಯನ್ನು ಹೆಸರಿಸಿ, ಏಕೆಂದರೆ ಗೇಟ್ವೇ ಬಗ್ಗೆ ಇರುವ ಗೋಪ್ಯತೆಯ ಪ್ರತಿಪಾದನೆ ಆ ಹೆಜ್ಜೆಯ ಬಗ್ಗೆ, ಇಡೀ ಮಾರ್ಗದ ಬಗ್ಗೆ ಅಲ್ಲ.
ಕಂಡುಕೊಂಡದ್ದನ್ನು ಮಾರ್ಗವಾಗಿ ಬರೆಯಿರಿ, ವಿಳಾಸವಾಗಿ ಅಲ್ಲ
ಕ್ಲೈಂಟ್, ರಿಸಾಲ್ವರ್, ಯಾವುದೇ ಫಾರ್ವರ್ಡರ್, ಪ್ರತಿ ಹೆಜ್ಜೆಯಲ್ಲಿ ಗಮನಿಸಿದ ಮೂಲ ಮತ್ತು ಅದನ್ನು ನಿಯಂತ್ರಿಸುವ ನೀತಿಯನ್ನು ದಾಖಲಿಸಿ. ಅಂತಹ ದಾಖಲೆ ಭವಿಷ್ಯದ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವಕ್ಕೆ ಇನ್ನೊಂದು ಸೆರೆ ಇಲ್ಲದೆ ಉತ್ತರಿಸುತ್ತದೆ. ಅದನ್ನು ಸರಪಳಿಯಾಗಿ ಎಳೆಯಿರಿ, ಏಕೆಂದರೆ ವಿಳಾಸಗಳ ಪಟ್ಟಿ ಯಾವ ಹೆಜ್ಜೆ ಯಾವುದನ್ನು ಉತ್ಪಾದಿಸಿತು ಎಂಬುದನ್ನು ಮರೆಮಾಡುತ್ತದೆ.
ಚಿತ್ರಕ್ಕೆ ದಿನಾಂಕ, ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿ ಮತ್ತು ಸಂರಚನೆಯ ಪರಿಷ್ಕರಣೆಯನ್ನು ಲಗತ್ತಿಸಿ, ಇದರಿಂದ ಮುಂದಿನ ಓದುಗರು ಅದು ಇನ್ನೂ ಅನ್ವಯವಾಗುತ್ತದೆಯೇ ಎಂದು ಹೇಳಬಹುದು. ಸಾರಿಗೆ ಮೂಲವನ್ನು ಸೇವೆ ಸಂಸ್ಕರಿಸುವ ಉಳಿದ ಎಲ್ಲದರಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ, ಏಕೆಂದರೆ ಗೇಟ್ವೇ ವಿಳಾಸವನ್ನು ನೋಡುವುದು ಇನ್ನೇನು ಸಂಗ್ರಹವಾಗಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ರಿಸಾಲ್ವರ್ನ ಸ್ಥಳವೂ ಯಾವ ಕ್ಲೈಂಟ್ ಕೇಳಿತು ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಈ ಪ್ರತಿಪಾದನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುವುದೇ ತೀರ್ಮಾನವನ್ನು ಪರಿಶೀಲನೆಯಲ್ಲಿ ನಿಲ್ಲಿಸಬಲ್ಲದಾಗಿಸುತ್ತದೆ.