VPN ನಲ್ಲಿ ಆಂತರಿಕ ಹೋಸ್ಟ್ ಹೆಸರುಗಳು dig ನಲ್ಲಿ ಏಕೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ ಆದರೆ curl ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ
dig ಉತ್ತರಿಸುತ್ತದೆ, ಆದರೆ curl ಹೋಸ್ಟ್ ಅನ್ನು ಪರಿಹರಿಸಲಾಗದು ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ಎರಡೂ ಹುಡುಕಾಟ ಸರಪಳಿಗಳನ್ನು ಹೋಲಿಸಿ, ನಂತರ nsswitch, ಲಿಂಕ್ ಪ್ರತಿ DNS ಅಥವಾ ತಪ್ಪು ಹುಡುಕಾಟ ಸಫಿಕ್ಸ್ ಸರಿಪಡಿಸಿ.
ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್ VPN ನಲ್ಲಿದೆ, dig service.internal.example 10.x ವಿಳಾಸದೊಂದಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ, curl ಇನ್ನೂ Could not resolve host ನೊಂದಿಗೆ ಹೊರಬರುತ್ತದೆ. ಸುರಂಗ ಸಮಸ್ಯೆ ಅಲ್ಲ: ಅದು dig ಪ್ರಶ್ನೆಯನ್ನು ದೂರಿಲ್ಲದೆ ಸಾಗಿಸಿತು. ವ್ಯತ್ಯಾಸ ಪ್ರಶ್ನೆಯನ್ನು ಯಾರು ಕೇಳುತ್ತಾರೆ ಎಂಬುದರಲ್ಲಿ. dig ನೀವು ಹೆಸರಿಸುವ ಒಂದು ಸರ್ವರ್‌ಗೆ ಒಂದು ಪ್ರಶ್ನೆ ಕಳುಹಿಸುತ್ತದೆ, ಆದರೆ curl ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಹುಡುಕಾಟ ಸರಪಳಿಯ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಆ ಸರಪಳಿಗೆ ಯಾವ ಸರ್ವರ್ ಅನ್ನು ಕೇಳಬೇಕು ಎಂಬುದರ ಬಗ್ಗೆ ತನ್ನದೇ ನಿಯಮಗಳಿವೆ.
ಒಂದೇ ಹೆಸರಿಗೆ ಎರಡು ಹುಡುಕಾಟಗಳು
dig ತನ್ನದೇ stub resolver. ಅದು /etc/resolv.conf ಓದುತ್ತದೆ, ನೇಮ್ ಸರ್ವರ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಒಂದೇ A ಅಥವಾ AAAA ಪ್ರಶ್ನೆ ಕಳುಹಿಸಿ ಉತ್ತರವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ಅದು nsswitch ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ ಮತ್ತು systemd-resolved ಅಥವಾ NetworkManager ಆ ಫೈಲ್‌ನ ಹೊರಗೆ ಇಡುವ ಲಿಂಕ್ ಪ್ರತಿ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ, ಆದ್ದರಿಂದ dig ಉತ್ತರ ಸರಿಯಾಗಿರಬಹುದು ಮತ್ತು ಆದರೂ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳದಿರಬಹುದು.
ಅಪ್ಲಿಕೇಶನ್‌ಗಳು getaddrinfo ಕರೆಯುತ್ತವೆ, getaddrinfo ಉದ್ದವಾದ ಸರಪಳಿಯ ಮೂಲಕ ಹೋಗುತ್ತದೆ: nsswitch ಮಾಡ್ಯೂಲ್‌ಗಳ ಕ್ರಮ, ನಂತರ ಹೆಸರನ್ನು ನಿರ್ವಹಿಸುವ ಮಾಡ್ಯೂಲ್, ಕೊನೆಗೆ ಪ್ರಸ್ತುತ ಲಿಂಕ್ ಸಂರಚನೆಯಿಂದ ನಿರ್ಮಿಸಿದ resolver. systemd ಯಂತ್ರದಲ್ಲಿ ಪ್ರಶ್ನೆ 127.0.0.53 ಗೆ ಹೋಗುತ್ತದೆ, systemd-resolved tun ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಜೋಡಿಸಿದ ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಆಧಾರದ ಮೇಲೆ ಪ್ರತಿ ಲಿಂಕ್‌ಗೆ ಮೇಲ್ಮಟ್ಟದ ಸರ್ವರ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.
ಎರಡು ಆಜ್ಞೆಗಳು ಈ ಪದರಗಳನ್ನು ಊಹಿಸದೆ ಬೇರ್ಪಡಿಸುತ್ತವೆ:
getent ahosts service.internal.example
resolvectl query service.internal.examplegetent curl ತೆಗೆದುಕೊಳ್ಳುವ ಅದೇ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುತ್ತಿರುವ dig ಪಕ್ಕದಲ್ಲಿ getent ವೈಫಲ್ಯ ದೋಷವನ್ನು ಪ್ಯಾಕೆಟ್ ರೂಟಿಂಗ್‌ನಲ್ಲಿ ಅಲ್ಲ, ಹುಡುಕಾಟ ನೀತಿಯಲ್ಲಿ ಗುರುತಿಸುತ್ತದೆ. resolvectl query ಉತ್ತರ ನೀಡಿದ ಇಂಟರ್‌ಫೇಸ್ ಮತ್ತು ಮೇಲ್ಮಟ್ಟದ ಸರ್ವರ್ ಅನ್ನೂ ಮುದ್ರಿಸುತ್ತದೆ, ಇದು ಸುರಂಗದ ಲಿಂಕ್ ಗೆದ್ದಿತೋ ಅಥವಾ ಭೌತಿಕ ಲಿಂಕ್ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.
ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಬಳಸುವ resolver ಓದಿ
/etc/resolv.conf ಹೆಚ್ಚಿನ ಡೆಸ್ಕ್‌ಟಾಪ್‌ಗಳಲ್ಲಿ ಉತ್ಪಾದನೆಯಾಗುತ್ತದೆ, VPN ಕ್ಲೈಂಟ್‌ಗೆ ಅದನ್ನು ನಿರ್ವಹಿಸಲು ಮೂರು ಮಾರ್ಗಗಳಿವೆ: ನೇಮ್ ಸರ್ವರ್ ಅನ್ನು ಮುಂದೆ ಸೇರಿಸುವುದು, ಫೈಲ್ ಮೇಲೆ ಬರೆಯುವುದು, ಅಥವಾ ತನ್ನ ಸರ್ವರ್‌ಗಳನ್ನು NetworkManager ಗೆ ಒಪ್ಪಿಸಿ ಡೀಮನ್ ಅದನ್ನು ಮರುಬರೆಯಲು ಬಿಡುವುದು. ಮೂರನೇ ಮಾದರಿ ಮಾತ್ರ ಲಿಂಕ್ ಪ್ರತಿ DNS ಉಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಸರ್ವರ್‌ಗಳು ಒಂದು ಜಾಗತಿಕ ಪಟ್ಟಿಯಲ್ಲಿ ಚಪ್ಪಟೆಯಾಗುವ ಬದಲು ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಜೋಡಿಸಲ್ಪಟ್ಟಿರುತ್ತವೆ.
NetworkManager ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಫಲಿತಾಂಶ /etc/NetworkManager/NetworkManager.conf ನಲ್ಲಿನ backend ಅನ್ನು ಅವಲಂಬಿಸಿದೆ:
[main]
dns=systemd-resolveddns=default ನೊಂದಿಗೆ ಕ್ಲೈಂಟ್‌ನ ಸರ್ವರ್‌ಗಳು ಗೆಲ್ಲುವ ಕ್ರಮದಲ್ಲಿ resolv.conf ಗೆ ವಿಲೀನಗೊಳ್ಳುತ್ತವೆ, ಖಾಸಗಿ ಪ್ರಶ್ನೆ ಇನ್ನೂ ಸಾರ್ವಜನಿಕ resolver ಗೆ ಹೋಗಬಹುದು. ಲಿಂಕ್‌ಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ backend ನೊಂದಿಗೆ, systemd-resolved ಅಥವಾ dnsmasq, ಸುರಂಗದ ಸರ್ವರ್‌ಗಳು ಸುರಂಗಕ್ಕೇ ಸೀಮಿತವಾಗಿರುತ್ತವೆ, ಅದರ ರೂಟಿಂಗ್ ಡೊಮೇನ್‌ಗೆ ಹೊಂದುವ ಹೆಸರುಗಳು ಮಾತ್ರ ಅಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ. ಈ ಮಿತಿಯೇ ಪ್ರಾಯೋಗಿಕವಾಗಿ split DNS ಎಂದರೆ ಏನು, ಮತ್ತು ಕ್ಲೈಂಟ್ ಅದನ್ನು ಬೆಂಬಲಿಸುತ್ತೇನೆ ಎಂದು ಹೇಳಿದಾಗ ಹೆಚ್ಚಾಗಿ ಕಾಣೆಯಾಗುವ ಭಾಗ ಇದೇ.
ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಸ್ಥಿತಿ ಓದಿ:
resolvectl status
resolvectl dns tun0tun ಇಂಟರ್‌ಫೇಸ್ DNS ಸರ್ವರ್ ಮತ್ತು ಖಾಸಗಿ ಸಫಿಕ್ಸ್‌ಗಾಗಿ ರೂಟಿಂಗ್ ಡೊಮೇನ್‌ನೊಂದಿಗೆ ಪಟ್ಟಿ ಮಾಡಲ್ಪಟ್ಟು, ~internal.example ಆಗಿ ತೋರಿಸಲ್ಪಡಬೇಕೆಂದು ನೀವು ಬಯಸುತ್ತೀರಿ. ಲಿಂಕ್‌ನಲ್ಲಿ ಸರ್ವರ್ ಇಲ್ಲದಿರುವುದು ಕ್ಲೈಂಟ್ ಏನನ್ನೂ ಕಳುಹಿಸಿಲ್ಲ ಎಂದರ್ಥ. ಡೊಮೇನ್ ಇಲ್ಲದ ಸರ್ವರ್ ಎಂದರೆ ಪ್ರಶ್ನೆಗಳು ಎಲ್ಲವೂ ಅಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ ಅಥವಾ ಒಂದೂ ಹೋಗುವುದಿಲ್ಲ, ಕ್ಲೈಂಟ್ ಅನ್ನು ಅವಲಂಬಿಸಿ, ಎರಡೂ split DNS ಅಲ್ಲ.
nsswitch ಹುಡುಕಾಟವನ್ನು ಬೇಗ ಮುಗಿಸುವ ಸ್ಥಳ
ಡೆಸ್ಕ್‌ಟಾಪ್‌ನ ಸಾಮಾನ್ಯ ಸಾಲು ಹೀಗೆ ಕಾಣುತ್ತದೆ:
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnamemdns4_minimal ಮಲ್ಟಿಕಾಸ್ಟ್ DNS ನಿರ್ವಹಿಸುತ್ತದೆ, .local ನಲ್ಲಿ ಮುಗಿಯುವ ಪ್ರತಿ ಹೆಸರಿನ ಮೇಲೂ ಹಕ್ಕು ಸಾಧಿಸುತ್ತದೆ. api.infra.svc.cluster.local ನಂತಹ Kubernetes ಸೇವೆಯೂ .local ನಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ. mDNS ಮಾಡ್ಯೂಲ್ NOTFOUND ವರದಿ ಮಾಡಿದಾಗ, [NOTFOUND=return] ಕ್ರಿಯೆ dns ಮಾಡ್ಯೂಲ್‌ಗೆ ಮುಂದುವರಿಯುವ ಬದಲು ಇಡೀ ಹುಡುಕಾಟವನ್ನು ಮುಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೆಸರು ಎಂದೂ VPN resolver ಗೆ ಕಳುಹಿಸಲ್ಪಡುವುದಿಲ್ಲ. dig ಫೈಲ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದಲೇ ಎರಡೂ ಸಾಧನಗಳು ಒಪ್ಪುವುದಿಲ್ಲ.
ಇದು ಈ ಸಮಸ್ಯೆಯ ಅತ್ಯಂತ ತೀಕ್ಷ್ಣ ವಿರೋಧಾಭಾಸ, ಅದು ನಿಮ್ಮ VPN ಗಿಂತ ಹಳೆಯ ಸಂರಚನಾ ಫೈಲ್‌ನ ಒಂದು ಪದದ ಮೇಲೆ ನಿಂತಿದೆ. ಕ್ರಿಯೆಯನ್ನು [NOTFOUND=continue] ಗೆ ಬದಲಿಸಿದರೆ ಪ್ರಿಂಟರ್‌ಗಳು ಮತ್ತು ಸ್ಥಳೀಯ ಸಾಧನಗಳಿಗೆ mDNS ಉಳಿಯುತ್ತದೆ, DNS ಹೆಸರನ್ನು ನೋಡಬಹುದು. ಸಾಲನ್ನು hosts: files dns ನಿಂದ ಬದಲಿಸುವುದೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚು ಒರಟು: ನೀವು ನಿಜವಾಗಿ ಬಳಸುವ ಪ್ರಿಂಟರ್‌ಗಾಗಿ .local ಪರಿಹಾರವನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ.
ಸರಿಯಾಗಿ ಒಂದೇ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ವಾಸಿಸುವ ಹೆಸರುಗಳು
ಖಾಸಗಿ ವಲಯಗಳು ಸರಿಯಾಗಿ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಅಧಿಕಾರ ಹೊಂದಿವೆ. ip-10-0-4-31.eu-west-1.compute.internal ನಂತಹ AWS ಹೆಸರು ಆ ಪ್ರದೇಶದ VPC resolver ಮೂಲಕ ಉತ್ತರಿಸಲ್ಪಡುತ್ತದೆ, ನಿಮ್ಮ VPN ಎಂಡ್‌ಪಾಯಿಂಟ್ ಸಂಪನ್ಮೂಲ ಇರುವ ಅದೇ ಪ್ರದೇಶದಲ್ಲಿರುವವರೆಗೆ ಮಾತ್ರ. ಫ್ರಾಂಕ್‌ಫರ್ಟ್ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಸಂಪರ್ಕಿಸಿ, ಐರ್ಲೆಂಡ್‌ನ compute.internal ಹೆಸರು ಕೇಳಿ, ಯಾವುದೇ ಸ್ಥಳೀಯ ಸೆಟ್ಟಿಂಗ್ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ: ದಾಖಲೆಯನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ವಲಯ ಅಲ್ಲಿಂದ ತಲುಪಲಾಗದದ್ದು.
ಹುಡುಕಾಟ ಡೊಮೇನ್‌ಗಳು ವಿರುದ್ಧ ಚಿತ್ರವನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ. ಬರೀ service resolver ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸುವ ಸಫಿಕ್ಸ್‌ನಿಂದ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ, VPN ಲಿಂಕ್‌ನೊಂದಿಗೆ ಸ್ಥಳೀಯ ಡೊಮೇನ್ ಸಾಂಸ್ಥಿಕ ಡೊಮೇನ್ ಅನ್ನು ಸೋಲಿಸಬಹುದು. ಊಹೆಯನ್ನು ತೆಗೆದುಹಾಕಲು ಕೊನೆಯಲ್ಲಿ ಚುಕ್ಕೆಯೊಂದಿಗೆ ಕೇಳಿ, getent ahosts service.internal.example., ಅದು ಕೆಲಸ ಮಾಡಿ ಸಣ್ಣ ಹೆಸರು ವಿಫಲವಾದರೆ, ತಿದ್ದುಪಡಿ ಸುರಂಗದ ಮೇಲಿನ ಹುಡುಕಾಟ ಡೊಮೇನ್, ಸರ್ವರ್ ವಿಳಾಸ ಅಲ್ಲ.
ನಿರ್ವಹಿತ ಕ್ಲೈಂಟ್‌ಗಳು ಸಿಸ್ಟಂ resolver ಮೇಲೆ ಮೂರನೇ ಪದರ ಸೇರಿಸುತ್ತವೆ. Windows VPN ಪ್ರೊಫೈಲ್ ತನ್ನದೇ ಹೆಸರು ಪರಿಹಾರ ನೀತಿ, ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ನಿಯಮಗಳು ಮತ್ತು ಸುರಂಗ ಆಫ್ ಇದ್ದಾಗಲೂ ಅನ್ವಯವಾಗುವ NRPT ಕೋಷ್ಟಕವನ್ನು ಹೊತ್ತು ತರಬಹುದು. ಸ್ವಂತ DNS ಕ್ಯಾಶ್ ಇರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, .NET ಮತ್ತು Java ರನ್‌ಟೈಮ್‌ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ, ಸರಪಳಿ ಸರಿಪಡಿಸಿದ ನಂತರವೂ ಹಳೆಯ ವೈಫಲ್ಯವನ್ನು ದೀರ್ಘಕಾಲ ಇಟ್ಟುಕೊಳ್ಳುತ್ತವೆ. Apple ಕ್ಲೈಂಟ್‌ಗಳು split DNS ಅನ್ನು DNS ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿನ ಹೊಂದಿಕೆಯಾಗುವ ಡೊಮೇನ್‌ಗಳ ಮೂಲಕ ಸೆಟ್ ಮಾಡುತ್ತವೆ, resolv.conf ಮೂಲಕ ಅಲ್ಲ, Chromium ಅಥವಾ Firefox ಸುರಕ್ಷಿತ DNS ಮೋಡ್‌ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳಿಗಾಗಿ ಸಿಸ್ಟಂ resolver ಅನ್ನು ಬಳಸದಿರಬಹುದು. VPN ಹೆಸರು ಪರಿಹಾರದ ಕುರಿತು Microsoft ಉಲ್ಲೇಖ ಆ ನೀತಿ ಪದರದ Windows ಭಾಗವನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಯಾವ ಪದರವನ್ನು ಸರಿಪಡಿಸಬೇಕೆಂದು ನಿರ್ಧರಿಸಿ
ತಿದ್ದುಪಡಿಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪ್ರಯತ್ನಿಸುವ ಬದಲು ಲಕ್ಷಣದಿಂದ ಪದರದ ಕಡೆಗೆ ಸಾಗಿ:
| Symptom | What it means | Check first |
|---|---|---|
| dig answers, getent fails | lookup chain, not the packet path | nsswitch line and resolvectl status |
| Timeout rather than NXDOMAIN | private resolver unreachable through the tunnel | resolvectl dns tun0, route to that address |
| NXDOMAIN | an authority answered and does not know the name | zone owner, endpoint region |
| FQDN works, short name fails | search suffix mismatch | resolvectl domain on the tun link |
| getent works, app fails | app cache or its own resolver | restart the app, check secure DNS |
ಎರಡು ಸಾಲುಗಳು ಹೆಚ್ಚಿನ ಭಾರ ಹೊರುತ್ತವೆ. ಟೈಮ್‌ಔಟ್ ತಲುಪುವಿಕೆಯ ಸಮಸ್ಯೆ: ಖಾಸಗಿ resolver ಸುರಂಗದ ಮೂಲಕ ಉತ್ತರಿಸುತ್ತಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದರ ವಿಳಾಸದ ಮಾರ್ಗ ಮತ್ತು ಲಿಂಕ್‌ನ DNS ಸರ್ವರ್ ನೀವು ಭಾವಿಸುವುದೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. NXDOMAIN ಅಧಿಕಾರದ ಸಮಸ್ಯೆ: ಯಾವುದೋ ಉತ್ತರಿಸಿತು ಮತ್ತು ಅದು ಹೆಸರು ತಿಳಿದಿಲ್ಲ, ಇದು ವಲಯ, ಪ್ರದೇಶ ಅಥವಾ ಈ ಪ್ರಶ್ನೆಯನ್ನು ಎಂದೂ ಪಡೆಯಬಾರದಿದ್ದ resolver ಕಡೆಗೆ ಸೂಚಿಸುತ್ತದೆ.
ಕೊನೆಯ ಸಾಲನ್ನು ಜನರು ಬಿಟ್ಟುಬಿಡುತ್ತಾರೆ ಏಕೆಂದರೆ ಎರಡೂ ಅರ್ಧಗಳು ಯಶಸ್ಸಿನಂತೆ ಕಾಣುತ್ತವೆ. FQDN ಗಿಂತ ಭಿನ್ನವಾಗಿ ಪರಿಹರಿಸಲ್ಪಡುವ ಸಣ್ಣ ಹೆಸರು ಸಫಿಕ್ಸ್ ಹೊಂದಾಣಿಕೆಯಲ್ಲದಿರುವಿಕೆ, ಸುರಂಗವನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವುದು ಕ್ಲೈಂಟ್ ಯಾವ ಸಫಿಕ್ಸ್ ಕಳುಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.
ಸಂರಚನಾ ಫೈಲ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಸ್ಥಿತಿಯನ್ನು ದಾಖಲಿಸಿ, ಸಂಪಾದನೆ ಏನಾದರೂ ಮಾಡಿದೆಯೇ ಎಂದು ಹೇಳಬಹುದು:
resolvectl status > before.txt
getent ahosts service.internal.example >> before.txtಪರಿಶೀಲನೆಗಳನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ನಡೆಸಿ ಮೊದಲ ವೈಫಲ್ಯದಲ್ಲಿ ನಿಲ್ಲಿಸಿ. getent ಮತ್ತು resolvectl query ಹೊಂದಿಕೆಯಾಗಬೇಕು; getent ವಿಫಲವಾಗಿ dig ಉತ್ತರಿಸುತ್ತಿದ್ದರೆ, ಹುಡುಕಾಟ ಸರಪಳಿಯಲ್ಲೇ ಇರಿ, ರೂಟಿಂಗ್ ಮುಟ್ಟಬೇಡಿ. resolvectl status tun ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ DNS ಸರ್ವರ್ ಮತ್ತು ರೂಟಿಂಗ್ ಡೊಮೇನ್ ತೋರಿಸಬೇಕು. nsswitch ಪರೀಕ್ಷಿಸುತ್ತಿರುವ ಸಫಿಕ್ಸ್‌ಗಾಗಿ NOTFOUND ನೊಂದಿಗೆ ಬೇಗ ಮರಳಬಾರದು. ಹೆಸರು ನಿಮ್ಮ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಸಂಪರ್ಕಿಸಿರುವ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಅಧಿಕಾರ ಹೊಂದಿರಬೇಕು, ಕೊನೆಯಲ್ಲಿ ಚುಕ್ಕೆಯೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಲ್ಪಟ್ಟಿರಬೇಕು. ಅಪ್ಲಿಕೇಶನ್ ತನ್ನದೇ ಕ್ಯಾಶ್ ಅಥವಾ ಸುರಕ್ಷಿತ DNS ಮೀರಿಕೆಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಬಾರದು.
ವಿಫಲವಾಗುವ ಮೊದಲ ಪದರವನ್ನು ಮಾತ್ರ ಸರಿಪಡಿಸಿ, ನಂತರ ಅದೇ ಆಜ್ಞೆಗಳನ್ನು ಮತ್ತೆ ನಡೆಸಿ. ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎರಡು ಬದಲಾವಣೆಗಳು ಯಾವುದು ಮುಖ್ಯವಾಗಿತ್ತು ಎಂದು ಹೇಳಲು ಬಿಡುವುದಿಲ್ಲ, ಮುಂದಿನ ಅಂದದೋಷ ತನಿಖೆಯನ್ನು ಶೂನ್ಯದಿಂದ ಪ್ರಾರಂಭಿಸುತ್ತದೆ.