ನಿಮ್ಮ Mac VPN ನಲ್ಲಿ ಬಳಸುವ DNS ರೆಸಾಲ್ವರ್ಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು ಹೇಗೆ

scutil --dns macOS ನಿಜವಾಗಿ ಸಂಪರ್ಕಿಸುವ ರೆಸಾಲ್ವರ್ ಸಂರಚನೆಯನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ನೀವು ಸೆಟ್ಟಿಂಗ್ಸ್ ಪ್ಯಾನೆಲ್ನಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದ ಒಂದೇ DNS ಸರ್ವರ್ ಅನ್ನಲ್ಲ. ಔಟ್ಪುಟ್ ಹೆಚ್ಚಿನ ಜನರು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಉದ್ದವಾಗಿದೆ, ಏಕೆಂದರೆ ಸಿಸ್ಟಂ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ, ಸ್ಕೋಪ್ಡ್ ಇಂಟರ್ಫೇಸ್ಗಳು ಮತ್ತು ಡೊಮೇನ್-ನಿರ್ದಿಷ್ಟ ಫಾರ್ವರ್ಡಿಂಗ್ಗಾಗಿ ಪ್ರತ್ಯೇಕ ರೆಸಾಲ್ವರ್ ಬ್ಲಾಕ್ಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಔಟ್ಪುಟ್ನ ಮೇಲ್ಭಾಗದ ಬ್ಲಾಕ್ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವ ಬ್ಲಾಕ್ ಆಗಿರಬೇಕೆಂದಿಲ್ಲ. ಖಾಸಗಿ ಹೆಸರು ಕಚೇರಿಯಲ್ಲಿ ಪರಿಹರಿಸಾಗಿ VPN ಏರುವ ಕ್ಷಣದಲ್ಲಿ ವಿಫಲವಾದರೆ, ಅಸಂಗತಿ ಹೊಂದಿಸುವ ನಿಯಮಗಳಲ್ಲಿ ಮತ್ತು ಮಾರ್ಗಗಳಲ್ಲಿ ಇದೆ, ಸರ್ವರ್ ವಿಳಾಸದಲ್ಲಲ್ಲ. ಮೊದಲು ಕ್ರಮವನ್ನು ಓದಿ, ನಂತರ ನಿಜವಾದ ಹುಡುಕಾಟದಿಂದ ಉತ್ತರವನ್ನು ಸಾಬೀತುಪಡಿಸಿ.

ವಿಳಾಸಗಳ ಮೊದಲು ಬ್ಲಾಕ್ ಕ್ರಮವನ್ನು ಓದಿ

ಪ್ರತಿ ನಮೂದು resolver #N ನಿಂದ ಆರಂಭವಾಗಿ nameserver[0], ಕೆಲವೊಮ್ಮೆ if_index, flags ಸಾಲು, reach ಮತ್ತು ಬ್ಲಾಕ್ ಸಾಮಾನ್ಯ ಡೀಫಾಲ್ಟ್ ಅಲ್ಲದಿದ್ದಾಗ domain ಹಾಗೂ search domain ಪಟ್ಟಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಡೊಮೇನ್ ಇಲ್ಲದ 1 ನೇ ರೆಸಾಲ್ವರ್ ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಡೀಫಾಲ್ಟ್ ಆಗಿದೆ. ತನ್ನ ಫ್ಲ್ಯಾಗ್ಗಳಲ್ಲಿ Scoped ಹೊಂದಿರುವ ಯಾವುದೇ ಬ್ಲಾಕ್ if_index ಹೆಸರಿಸುವ ಇಂಟರ್ಫೇಸ್ಗೆ ಬದ್ಧವಾಗಿದೆ, ಮತ್ತು Supplemental ಎಂದು ಗುರುತಿಸಿದ ಯಾವುದೂ ಅದರ ಕೆಳಗೆ ಪಟ್ಟಿ ಮಾಡಿದ ಡೊಮೇನ್ಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ.

ಆಯ್ಕೆ ಎಂಬುದು ಪ್ರತ್ಯಯ ಹೊಂದಾಣಿಕೆ. intranet.corp.example ನಂತಹ ಹೆಸರಿಗೆ, macOS ತನ್ನ domain ನಮೂದು ಅತ್ಯಂತ ಉದ್ದದ ಹೊಂದುವ ಪ್ರತ್ಯಯವಾಗಿರುವ ರೆಸಾಲ್ವರ್ ಅನ್ನು ಆದ್ಯತೆ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ domain : corp.example ಇರುವ ಬ್ಲಾಕ್ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಬಹಳ ಕೆಳಗಿದ್ದರೂ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಸೋಲಿಸುತ್ತದೆ. ಒಂದೇ ಉದ್ದದ ಡೊಮೇನ್ಗಳ ನಡುವಿನ ಸಮಾನತೆಯನ್ನು order ಬಗೆಹರಿಸುತ್ತದೆ. ಮೊದಲ ನೋಟಕ್ಕೆ ಇದಕ್ಕಿಂತ ಹೆಚ್ಚು ಅಪರೂಪವಾಗಿ ಬೇಕಾಗುವುದಿಲ್ಲ: ಒಂದು ಬ್ಲಾಕ್ ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಓದಲು ಬಯಸಿದಾಗ ಇಡೀ ಔಟ್ಪುಟ್, ಬ್ಲಾಕ್ ಕ್ರಮ ತಿಳಿಯಲು ಆರಂಭಿಕ ಸಾಲುಗಳು, ಮತ್ತು ಕ್ಷೇತ್ರ ಸಾಲುಗಳ ಪಕ್ಕದಲ್ಲಿ ಬ್ಲಾಕ್ ಶೀರ್ಷಿಕೆಗಳನ್ನು ಮುದ್ರಿಸುವ ಫಿಲ್ಟರ್ ಮಾಡಿದ ಹಾದಿ. ಸ್ಕೋಪ್ಡ್ ಬ್ಲಾಕ್ಗಳು ತಮ್ಮದೇ ಶೀರ್ಷಿಕೆಯ ಕೆಳಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಮೇಲಿನ ಪಟ್ಟಿಯ ಮುಂದುವರಿಕೆಯಂತೆ ಓದಲ್ಪಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಔಟ್ಪುಟ್ ಉಲ್ಲೇಖಿಸುವಾಗ ಶೀರ್ಷಿಕೆಯನ್ನು ಕಣ್ಣಮುಂದೆ ಇಟ್ಟುಕೊಳ್ಳಿ.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

if_index ಅನ್ನು ಟನಲ್ ಇಂಟರ್ಫೇಸ್ಗೆ ಹೊಂದಿಸಿ

ಸೂಚ್ಯಂಕವು ಅದರ ಹಿಂದಿನ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೆಸರಿಸಬಲ್ಲಾಗ ಮಾತ್ರ ಉಪಯುಕ್ತ. scutil --nwi ಸಿಸ್ಟಂ ಹೊಂದಿರುವ ನೆಟ್ವರ್ಕ್ ಮಾಹಿತಿಯನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಅದರಲ್ಲಿ ಪ್ರಾಥಮಿಕ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ತಲುಪುವಿಕೆ ಸೇರಿವೆ, ಆದರೆ ifconfig -l ನಿಮಗೆ ಹೆಸರುಗಳನ್ನು ನೀಡುತ್ತದೆ, ಅಲ್ಲಿ utun0 ರಿಂದ utun9 ವರೆಗೆ ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ ರಚಿಸುವ ಟನಲ್ ಅಭ್ಯರ್ಥಿಗಳು. Apple ತನ್ನದೇ ಪರಿಶೀಲನಾ ಉದಾಹರಣೆಯಾಗಿ scutil --dns ಅನ್ನು ನಿಯೋಜನಾ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ ಬಳಸುತ್ತದೆ ಮತ್ತು Network Extension ಆಯ್ದ ಡೊಮೇನ್ಗಳನ್ನು ಆಯ್ದ ರೆಸಾಲ್ವರ್ಗಳಿಗೆ ಹೇಗೆ ರೂಟ್ ಮಾಡಬಹುದು ಎಂದು ದಾಖಲಿಸುತ್ತದೆ; ಆ ಸ್ಕೋಪ್ಡ್ ಬ್ಲಾಕ್ಗಳು ಬಹಿರಂಗಪಡಿಸುವ ಯಂತ್ರಾಂಶ ಅದೇ ಆಗಿದೆ.

ಪ್ರಶ್ನೆಯನ್ನು ನಿರ್ಧರಿಸುವ ಪರಿಶೀಲನೆ ಎಂದರೆ ರೆಸಾಲ್ವರ್ ಟನಲ್ ಸ್ಥಾಪಿಸಿದ ಮಾರ್ಗದಲ್ಲಿದೆಯೇ ಎಂಬುದು:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

route -n get ರೆಸಾಲ್ವರ್ ನಮೂದಿಗೆ ಹೊಂದದ ಗೇಟ್ವೇ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ, ವಿಳಾಸ ಸಂಪೂರ್ಣ ಸರಿಯಾಗಿದ್ದರೂ ತಲುಪಲಾಗದಿರಬಹುದು. ಕೇವಲ ಕಾರ್ಪೊರೇಟ್ ಉಪಜಾಲಗಳನ್ನು ಸಾಗಿಸುವ ವಿಭಜಿತ ಟನಲ್ ಅವುಗಳ ಹೊರಗಿನ DNS ಸರ್ವರ್ಗೆ ಹೋಗುವ ಪ್ರಶ್ನೆಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯ ಟೈಮೌಟ್ ಆಗಿ ಕಾಣಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂರಚನಾ ಔಟ್ಪುಟ್ ಸ್ವಚ್ಛವಾಗಿ ಕಾಣುತ್ತಲೇ ಇರುತ್ತದೆ.

ಸಿಸ್ಟಂ ರೆಸಾಲ್ವರ್ ಅನ್ನು ಕೇಳಿ, ನಂತರ ಸರ್ವರ್ ಅನ್ನು

ಮೂರು ಉಪಕರಣಗಳು ಮೂರು ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಅವನ್ನು ಗೊಂದಲಗೊಳಿಸುವುದು ಈ ಕ್ಷೇತ್ರದ ಹೆಚ್ಚಿನ ತಪ್ಪು ತೀರ್ಮಾನಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. dscacheutil -q host -a name ಸಾಮಾನ್ಯ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಬಳಸುವ ಅದೇ ಸಿಸ್ಟಂ ರೆಸಾಲ್ವರ್ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ಕೋಪ್ಡ್ ಮತ್ತು ಪೂರಕ ಬ್ಲಾಕ್ಗಳು ಅನ್ವಯಿಸುತ್ತವೆ. ಸರ್ವರ್ ಆರ್ಗ್ಯುಮೆಂಟ್ ಇಲ್ಲದ dig /etc/resolv.conf ಓದುತ್ತದೆ, ಅದು macOS ನಲ್ಲಿ ಸ್ಕೋಪ್ಡ್ ಪರಿಹಾರಕ್ಕೆ ಸತ್ಯದ ಮೂಲವಲ್ಲ, ಮತ್ತು ಡೊಮೇನ್ ಪ್ರತಿ ನಿಯಮಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. dig @address ನಿಖರವಾಗಿ ಒಂದು ಸರ್ವರ್ ತಲುಪುತ್ತದೆ ಮತ್ತು ಆಯ್ಕೆ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

ಮೊದಲ ಆಜ್ಞೆ ಉತ್ತರಿಸಿ ಎರಡನೆಯದು NXDOMAIN ಹಿಂತಿರುಗಿಸಿದಾಗ, ನೀವು ಹುಡುಕುತ್ತಿದ್ದ ವಿಭಜನೆ ಸಿಕ್ಕಿತು ಮತ್ತು ಏನೂ ಮುರಿದಿಲ್ಲ. ಮೊದಲನೆಯದು ಸಮಯ ಮೀರಿದಾಗ dig @10.20.0.53 ಉತ್ತರಿಸುತ್ತಿದ್ದರೆ, ರೆಸಾಲ್ವರ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ ಟನಲ್ ಆಯ್ಕೆ ಮಾಡಿದ ಮಾರ್ಗದಲ್ಲಿ ತಲುಪಲಾಗದು, ಆದ್ದರಿಂದ ಮುಂದಿನ ಹೆಜ್ಜೆ DNS ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬದಲಿಸುವುದಲ್ಲ, route -n get. ಖಾಸಗಿ ಹೆಸರುಗಳನ್ನು ಟಿಕೆಟ್ ಅಥವಾ ಹಂಚಿದ ಟಿಪ್ಪಣಿಗೆ ಅಂಟಿಸುವ ಯಾವುದರಿಂದಲೂ ಹೊರಗಿಡಿ.

ಔಟ್ಪುಟ್ ನಿಮಗೆ ತೋರಿಸಲಾಗದ್ದು

ರೆಸಾಲ್ವರ್ ಪಟ್ಟಿಯ ಮೇಲೆ ಅಥವಾ ಪಕ್ಕದಲ್ಲಿ ಹಲವು ಪದರಗಳು ಕುಳಿತಿವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಔಟ್ಪುಟ್ ಎಂದೂ ಉಲ್ಲೇಖಿಸದ ಸ್ಥಳಕ್ಕೆ ಪ್ರಶ್ನೆ ಕಳುಹಿಸಬಹುದು. ಸುರಕ್ಷಿತ DNS ಸಕ್ರಿಯವಾಗಿರುವ ಬ್ರೌಸರ್ ತನ್ನದೇ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಚಾನಲ್ ಮೂಲಕ ಪರಿಹರಿಸಬಹುದು, ಆದ್ದರಿಂದ dscacheutil ಸಮಯ ಮೀರಿದಾಗ ಪುಟ ಲೋಡ್ ಆಗುವುದು ವಿರೋಧಾಭಾಸವಲ್ಲ. ಭದ್ರತಾ ತಂತ್ರಾಂಶ ಸ್ಥಾಪಿಸಿದ DNS ಪ್ರಾಕ್ಸಿ Network Extension ಪೂರೈಕೆದಾರರಾಗಿ ಚಲಿಸಿ ತಾನೇ ಪ್ರಶ್ನೆಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು scutil --dns ಏನು ಸಂರಚಿಸಲಾಗಿತ್ತು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಪ್ರಾಕ್ಸಿ ಕೊನೆಗೆ ಬಳಸಿದ ಮೇಲ್ಮುಖ ವಿಳಾಸವನ್ನಲ್ಲ. ಹುಡುಕಾಟ ಡೊಮೇನ್ಗಳು ಮೂರನೇ ಮಡಿಕೆಯನ್ನು ಸೇರಿಸುತ್ತವೆ: ಅರ್ಹತೆ ಇಲ್ಲದ ಹೆಸರಿಗೆ ಪಟ್ಟಿ ಮಾಡಿದ ಪ್ರತಿ ಪ್ರತ್ಯಯವೂ ಕ್ರಮವಾಗಿ ಸೇರಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಉತ್ತರಿಸಿದ ಬ್ಲಾಕ್ ನೀವು ಎಂದೂ ಶಂಕಿಸದ ಒಂದಾಗಿರಬಹುದು.

ಹಳೆಯ ಉತ್ತರಗಳನ್ನು ಹೊರಗಿಡುವುದು ಅಗ್ಗದ್ದು ಮತ್ತು ಹೆಚ್ಚು ಕಡೆಗಣಿಸಲ್ಪಡುವುದು:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

ಫ್ಲಶ್ ನಂತರ ಔಟ್ಪುಟ್ ಬದಲಾದರೆ, ಸ್ಥಿತಿ ಕ್ಯಾಶ್ನಲ್ಲಿತ್ತು ಮತ್ತು ಹಿಂದಿನ ಔಟ್ಪುಟ್ ಇನ್ನಿಲ್ಲದ ಟನಲ್ ಅನ್ನು ವಿವರಿಸುತ್ತಿತ್ತು. ಬದಲಾಗದಿದ್ದರೆ, ಸಂರಚನೆ ಇರುವಂತೆ ಇದೆ, ಮತ್ತು ಪ್ರಶ್ನೆ ಮಾರ್ಗಗಳು ಹಾಗೂ ಅಪ್ಲಿಕೇಶನ್ ನೀತಿಯ ಕಡೆಗೆ ಸರಿಯುತ್ತದೆ.

ಮೊದಲು ಮತ್ತು ನಂತರಕ್ಕಾಗಿ ಸಣ್ಣ ಕೈಪಿಡಿ

ನೀತಿ ಅನುಮತಿಸುವಲ್ಲಿಯೇ ಮಾತ್ರ ಮೂಲರೇಖೆಯನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ, ಮತ್ತು ಫೈಲ್ಗಳನ್ನು ಯಾವುದೇ ಸಿಂಕ್ ಆದ ಫೋಲ್ಡರ್ನ ಹೊರಗೆ ಇಡಿ. ಕೆಳಗಿನ ಕ್ರಮವೇ ನಾನು ಕ್ಲೈಂಟ್ ಯಂತ್ರಗಳಲ್ಲಿ ಚಲಾಯಿಸುವುದು: ಮೂಲರೇಖೆ ತೆಗೆದುಕೊಳ್ಳಿ, ಸಂಪರ್ಕಿಸಿ, ಮತ್ತೆ ತೆಗೆದುಕೊಳ್ಳಿ, ನಂತರ ವ್ಯತ್ಯಾಸ ನೋಡಿ ಹುಡುಕಿ.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

ವ್ಯತ್ಯಾಸವನ್ನು ಸಾಲುಗಳ ಬದಲು ಬ್ಲಾಕ್ಗಳ ಮೂಲಕ ಓದಿ. ಟನಲ್ ಇಂಟರ್ಫೇಸ್ ಸೂಚ್ಯಂಕ ಮತ್ತು ಖಾಸಗಿ ಪ್ರತ್ಯಯಕ್ಕೆ domain ನಮೂದನ್ನು ಹೊತ್ತಿರುವ ಹೊಸ ಸ್ಕೋಪ್ಡ್ ರೆಸಾಲ್ವರ್ ನಿರೀಕ್ಷಿತ ರೂಪ. ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ಕಡೆ ತೋರಿಸುವ ಹೊಸ ಡೀಫಾಲ್ಟ್ ರೆಸಾಲ್ವರ್ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ನ ಮಾಲೀಕರ ಮುಂದೆ ತರಬೇಕಾದ ಸಂಶೋಧನೆ. ನಂತರ ನಿಜವಾಗಿ ವಿಫಲವಾದ ಅಪ್ಲಿಕೇಶನ್ನೊಳಗೆ ಹುಡುಕಾಟವನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಕೇವಲ ಶೆಲ್ನಲ್ಲಿ ಅಲ್ಲ, ಮತ್ತು ಫಲಿತಾಂಶದ ಪಕ್ಕದಲ್ಲಿ route -n get ನ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬರೆದಿಡಿ.

ಬದಲಾವಣೆಯನ್ನು ರದ್ದುಗೊಳಿಸಲು ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಮತ್ತು ಮೂಲರೇಖೆ ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಸ್ಕೋಪ್ಡ್ ಬ್ಲಾಕ್ ಹೋಗಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ತನ್ನ ಹಿಂದೆ ಸ್ವಚ್ಛಗೊಳಿಸಿದೆ. ಬ್ಲಾಕ್ ಇನ್ನಿಲ್ಲದ ಇಂಟರ್ಫೇಸ್ ವಿರುದ್ಧ ಇನ್ನೂ ಪಟ್ಟಿಯಾಗಿದ್ದರೆ, ಸ್ಥಿತಿ ಹಳೆಯದಾಗಿದೆ, ಮತ್ತು ಯಾರೂ ಪ್ರೊಫೈಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಫ್ಲಶ್ ಜೊತೆ ಮರುಸಂಪರ್ಕವೇ ಅತ್ಯಂತ ಮೃದು ಸರಿಪಡಿಸುವಿಕೆ.

ಈ ಕ್ರಮದಲ್ಲಿ ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳು: ಯಾವುದೇ ರೆಸಾಲ್ವರ್ ಬ್ಲಾಕ್ ಹೆಸರಿನ ಅತ್ಯಂತ ಉದ್ದದ ಪ್ರತ್ಯಯಕ್ಕೆ ಹೊಂದುತ್ತದೆಯೇ; ಆ ಬ್ಲಾಕ್ ಟನಲ್ ಸ್ಥಾಪಿಸಿದ ಇಂಟರ್ಫೇಸ್ಗೆ ಬದ್ಧವಾಗಿದೆಯೇ; ಅದರ ಹೆಸರು ಸರ್ವರ್ಗೆ ಇರುವ ಮಾರ್ಗ ಟನಲ್ ಬಳಸುತ್ತದೆಯೇ; ಮತ್ತು dig ಅಲ್ಲ, ಸಿಸ್ಟಂ ರೆಸಾಲ್ವರ್ ಉತ್ತರವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆಯೇ. ಮೊದಲು ವಿಫಲವಾದ ಪರಿಶೀಲನೆ DNS ನೀತಿ, ಟನಲ್ ಮಾರ್ಗಗಳು ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಬದಲಿಸಬೇಕೆಂದು ಹೇಳುತ್ತದೆ. ನಾಲ್ಕೂ ಉತ್ತೀರ್ಣವಾಗಿ ಹೆಸರು ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಸಮಸ್ಯೆ DNS ನ ಮೇಲಿದೆ, ಮತ್ತು ಮುಂದೆ ಪರಿಶೀಲಿಸಬೇಕಾದದ್ದು ಅದರ ಮುಂದೆ ಪೋರ್ಟ್ 53 ಗೆ ಉತ್ತರಿಸುವ ಯಾವುದೇ ವಸ್ತು.