VPN ಡಿಸ್ಕನೆಕ್ಟ್ ಆದ ನಂತರ resolv.conf ಸಂಪಾದಿಸುವುದರಿಂದ DNS ಸರಿಯಾಗುವುದಿಲ್ಲ

ನೀವು VPN ಡಿಸ್ಕನೆಕ್ಟ್ ಮಾಡುತ್ತೀರಿ, ping 1.1.1.1 ಇನ್ನೂ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಪುಟ ಅಂತಿಮವಾಗಿ ಬಿಟ್ಟುಕೊಡುವ ಮೊದಲು ಪ್ರತಿ ಹೆಸರಿನ ಹುಡುಕಾಟವೂ ನೇತಾಡುತ್ತದೆ. ನಂತರ cat /etc/resolv.conf ಟನೆಲ್ನ ಒಳಗೆ ಮಾತ್ರ ಎಂದಾದರೂ ಇದ್ದ ನೇಮ್ಸರ್ವರ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಪಟ್ಟಿಯಲ್ಲಿ ಮೊದಲನೆಯದು. ಆ ಸಾಲನ್ನು ಅಳಿಸುವುದು ಸುಮಾರು ಹತ್ತು ನಿಮಿಷಗಳ ಕಾಲ ಸರಿಪಡಿಸಿದಂತೆ ಕಾಣುತ್ತದೆ, ನಂತರ ಸಸ್ಪೆಂಡ್, Wi-Fi ರೋಮಿಂಗ್ ಅಥವಾ ಮರುಪ್ರಾರಂಭ ಅದನ್ನು ಮರಳಿ ತರುತ್ತದೆ. ನೀವು ಸಂಪಾದಿಸಿದ ಫೈಲ್ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ; ಅದು ಇನ್ನೊಂದು ಘಟಕದ ಒಡೆತನದ ಲಿಂಕ್ ಸ್ಥಿತಿಯ ರೆಂಡರಿಂಗ್.

ಒಂದು ಹಳೆಯ ನಮೂದು ಪ್ರತಿ ಹುಡುಕಾಟಕ್ಕೆ ಸೆಕೆಂಡುಗಳನ್ನು ಏಕೆ ವೆಚ್ಚ ಮಾಡುತ್ತದೆ

glibc ರೆಸಾಲ್ವರ್ ನೇಮ್ಸರ್ವರ್ ಪಟ್ಟಿಯನ್ನು ಕ್ರಮವಾಗಿ ನಡೆದು ಮುಂದಿನದನ್ನು ಪ್ರಯತ್ನಿಸುವ ಮೊದಲು ಟೈಮ್ಔಟ್ ಮುಗಿಯುವವರೆಗೆ ಕಾಯುತ್ತದೆ, ಮತ್ತು resolv.conf(5) ಆ ಪಟ್ಟಿಯನ್ನು ಮೂರು ನಮೂದುಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ. ಟನೆಲ್ ಹೋದ ನಂತರ 10.8.0.1 ನಂತಹ ಟನೆಲ್-ಬದಿಯ ರೆಸಾಲ್ವರ್ ಅನ್ನು ಪಟ್ಟಿಯ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಇರಿಸಿ, ಆಗ ಪ್ರತಿ ಹುಡುಕಾಟವೂ ಉತ್ತರಿಸುವ ಸರ್ವರ್ಗೆ ಇಳಿಯುವ ಮೊದಲು ಟೈಮ್ಔಟ್ ಪಾವತಿಸುತ್ತದೆ. ಲಕ್ಷಣವು DNS ದೋಷದಂತೆ ಅಲ್ಲದೆ ಸತ್ತ ಸಂಪರ್ಕದಂತೆ ಕಾಣಲು ಇದೇ ಕಾರಣ: ಬ್ರೌಸರ್ಗಳು ನಿರ್ಬಂಧಿಸುತ್ತವೆ, ಸಮಯ ಮುಗಿಯುತ್ತದೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ನಂತರ ಹಳೆಯದಾಗುವ ಕ್ಯಾಶ್ ಮಾಡಿದ ವಿಳಾಸವನ್ನು ನೀಡುತ್ತವೆ.

«ಇಂಟರ್ನೆಟ್ ಕೆಟ್ಟುಹೋಗಿದೆ» ಎಂಬ ದೂರು ಏಕೆ ಬರುತ್ತದೆ ಎಂಬುದನ್ನೂ ಇದು ವಿವರಿಸುತ್ತದೆ. IP ವಿಳಾಸಕ್ಕೆ ping ಲಿಂಕ್ ಸರಿಯಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಇದು ದೋಷವನ್ನು ಅಪ್ಲಿಕೇಶನ್ನದಂತೆ ಕಾಣಿಸುತ್ತದೆ. ರೆಸಾಲ್ವರ್ ಪಟ್ಟಿಯು ಓದಬೇಕಾದ ಮೊದಲ ವಿಷಯ ಮತ್ತು ಸಂಪಾದಿಸಬೇಕಾದ ಕೊನೆಯ ವಿಷಯ.

ಪುರಾಣ: resolv.conf ಒಂದು ಸೆಟ್ಟಿಂಗ್ಸ್ ಫೈಲ್

ಬದಲಿಸುವ ಮೊದಲು ಆ ಮಾರ್ಗ ವಾಸ್ತವವಾಗಿ ಏನೆಂದು ಕೇಳಿ:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

systemd-resolved ಹೋಸ್ಟ್ನಲ್ಲಿ ಅದು 127.0.0.53 ಗೆ ತೋರಿಸುವ ಸ್ಟಬ್ ಫೈಲ್ಗೆ ಸಿಂಬಾಲಿಕ್ ಲಿಂಕ್, ಮತ್ತು ನಿಜವಾದ ಸರ್ವರ್ಗಳು resolvectl ಮುದ್ರಿಸುವ ಪ್ರತಿ-ಲಿಂಕ್ ಸ್ಥಿತಿಯಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ. NetworkManager ಹೋಸ್ಟ್ನಲ್ಲಿ ಅದು NetworkManager ಸಕ್ರಿಯ ಸಂಪರ್ಕದಿಂದ ಬರೆಯುವ ಫೈಲ್ ಆಗಿರಬಹುದು. ಕೆಲವು ವೆಂಡರ್ ಕ್ಲೈಂಟ್ಗಳಲ್ಲಿ ಅದು ಸಂಪರ್ಕಿಸುವಾಗ ಸ್ಥಳದಲ್ಲೇ ಮರುಬರೆಯುವ ಮತ್ತು, ನೀವು ಅದೃಷ್ಟವಂತರಲ್ಲದಿದ್ದರೆ, ಡಿಸ್ಕನೆಕ್ಟ್ ಆಗುವಾಗ ಎಂದಿಗೂ ಮರುಸ್ಥಾಪಿಸದ ಸಾಮಾನ್ಯ ಫೈಲ್. ಇವು ಮೂರು ಬೇರೆ ಬೇರೆ ಮಾಲೀಕರು, ಮತ್ತು ಮೊದಲ ಎರಡನ್ನು ಕೈಯಿಂದ ಸಂಪಾದಿಸುವುದು ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ ಅಥವಾ ಮುಂದಿನ ನೆಟ್ವರ್ಕ್ ಘಟನೆಯವರೆಗೆ ನಿಲ್ಲುತ್ತದೆ.

resolvectl status ಸತ್ಯವನ್ನು ಹೇಳುವ ನೋಟ: ಪ್ರತಿ-ಲಿಂಕ್ DNS ಸರ್ವರ್ಗಳು, ರೂಟಿಂಗ್ ಡೊಮೇನ್ಗಳು, ಮತ್ತು ಟನೆಲ್ ಲಿಂಕ್ ಇನ್ನೂ ಇದೆಯೇ. resolvectl query example.com ಮುಂದೆ ಹೋಗಿ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಉತ್ತರಿಸಿತು ಎಂದು ತೋರಿಸುತ್ತದೆ. ಫೈಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಎರಡನ್ನೂ ಬಳಸಿ, ಮತ್ತು ತನ್ನದೇ ಸುರಕ್ಷಿತ DNS ಇರುವ ಬ್ರೌಸರ್ ಇವೆಲ್ಲವನ್ನೂ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ ಎಂದು ನೆನಪಿಡಿ.

ಏನನ್ನಾದರೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ಮಾಲೀಕರನ್ನು ಹುಡುಕಿ

ಸಾಮಾನ್ಯವಾಗಿ ಮೂರು ಘಟಕಗಳು ಒಂದೇ ಸೆಟ್ಟಿಂಗ್ಗಾಗಿ ಸ್ಪರ್ಧಿಸುತ್ತವೆ: systemd-resolved, NetworkManager ಮತ್ತು VPN ಕ್ಲೈಂಟ್ ಸ್ಥಾಪಿಸಿದ್ದು. ಮೊದಲು ಜೀವಂತವಾದದ್ದನ್ನು ಗುರುತಿಸಿ:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

resolved ಸಕ್ರಿಯವಾಗಿದ್ದು ಸಿಂಬಾಲಿಕ್ ಲಿಂಕ್ ಅದರ ಸ್ಟಬ್ಗೆ ತೋರಿಸಿದರೆ, ಜಾಗತಿಕ ಫೈಲ್ ರಚಿಸಲಾದ ಔಟ್ಪುಟ್ ಮತ್ತು ನಿಮ್ಮ ಸಂಪಾದನೆ ಕೇವಲ ದೃಶ್ಯ. NetworkManager ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿದ್ದರೆ, ಸರ್ವರ್ಗಳು ಸಂಪರ್ಕ ಪ್ರೊಫೈಲ್ಗೆ ಸೇರಿದ್ದವು, ಆದ್ದರಿಂದ ಸರಿಪಡಿಸುವಿಕೆ ಫೈಲ್ ಸಂಪಾದನೆಯಲ್ಲ, nmcli ಗುಣಲಕ್ಷಣ ಬದಲಾವಣೆ. ವೆಂಡರ್ ಡೀಮನ್ ನಡೆಯುತ್ತಿದ್ದರೆ, ಮುಂದಿನ ಸಂಪರ್ಕದವರೆಗೆ ಅದರ ಸ್ವಂತ ಮರುಸ್ಥಾಪನಾ ಮಾರ್ಗ ಮಾತ್ರ ಉಳಿಯುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಬಿಟ್ಟುಹೋದ ಲಿಂಕ್ ಸ್ಥಿತಿಯನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಿ

ಕೊಲ್ಲಲ್ಪಟ್ಟ ಕ್ಲೈಂಟ್ ತನ್ನ ಸ್ವಚ್ಛಗೊಳಿಸುವ ಕೊಕ್ಕನ್ನು ಚಲಾಯಿಸಲಾರದು. SIGKILL ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಹಿಡಿಯಲಾಗದು, ಆದರೆ SIGINT ಮತ್ತು SIGTERM ಅನ್ನು ಹಿಡಿಯಬಹುದು, ಆದ್ದರಿಂದ ಬಲವಂತದ ಕೊಲೆಯ ನಂತರ «ಸುಮ್ಮನೆ ನಿಂತುಹೋದ» ಟನೆಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಇಂಟರ್ಫೇಸ್ ನೋಂದಣಿ ಮತ್ತು ರೆಸಾಲ್ವರ್ ನಮೂದು ಎರಡನ್ನೂ ಸ್ಥಳದಲ್ಲೇ ಬಿಡುತ್ತದೆ. ನಿರ್ದಿಷ್ಟ PID ಹುಡುಕಿ ಸಿಗ್ನಲ್ ಅದಕ್ಕೆ ಮಾತ್ರ ಕಳುಹಿಸಿ:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

ಪೂರ್ಣ ಹೊಂದಾಣಿಕೆ ಪಟ್ಟಿಯನ್ನು ಓದುವ ಮೊದಲು pkill -f vpn ಅಥವಾ killall vpn ಕಡೆಗೆ ಕೈ ಚಾಚಬೇಡಿ. -f ಸಂಪೂರ್ಣ ಆಜ್ಞಾ ಸಾಲಿಗೆ ಹೊಂದುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಸುತ್ತು ಸ್ಕ್ರಿಪ್ಟ್, ಸಂಪಾದಕ ಅಧಿವೇಶನ ಅಥವಾ ಮಾರ್ಗದಲ್ಲಿ ಆ ಸ್ಟ್ರಿಂಗ್ ಇರುವ ಸಂಬಂಧವಿಲ್ಲದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊನೆಗೊಳಿಸಬಹುದು. ಕೆಲಸದ ಮಧ್ಯದಲ್ಲಿ ತಪ್ಪು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊನೆಗೊಳಿಸುವುದು ರೆಸಾಲ್ವರ್ ಸಮಸ್ಯೆ ಕಳೆದುಹೋದ ಫೈಲ್ ಆಗುವ ದಾರಿ.

resolvectl revert ಆ ಲಿಂಕ್ನ ರನ್ಟೈಮ್ DNS ಸಂರಚನೆಯನ್ನು ಮರುಹೊಂದಿಸುತ್ತದೆ, ಇದು ರೆಸಾಲ್ವರ್ ಮರುಪ್ರಾರಂಭಕ್ಕಿಂತ ಕಿರಿದಾದದ್ದು ಮತ್ತು ಜಾಗತಿಕ ಫೈಲ್ ಸಂಪಾದನೆಗಿಂತ ಬಹಳ ಕಿರಿದಾದದ್ದು. ಟನೆಲ್ ಲಿಂಕ್ ಸಂಪೂರ್ಣವಾಗಿ ಹೋಗಿದ್ದರೆ, systemctl restart NetworkManager ಸಂಪರ್ಕ ಸ್ಥಿತಿಯನ್ನು ಮರುನಿರ್ಮಿಸುತ್ತದೆ ಮತ್ತು ಮೂಲ ಥ್ರೆಡ್ಗಳು ಪದೇ ಪದೇ ಮರಳುವ ಹಂತ ಅದೇ. Restart=always ಇರುವ ಸೇವಾ ನಿರ್ವಾಹಕರ ಬಗ್ಗೆ ಎಚ್ಚರವಿರಲಿ, ಏಕೆಂದರೆ ಅದು ಕೊಲ್ಲಲ್ಪಟ್ಟ ಕ್ಲೈಂಟ್ ಮತ್ತು ಅದರ DNS ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ನೇರವಾಗಿ ಮರಳಿ ಇಡಬಹುದು.

ಇನ್ನೊಂದು ದಿಕ್ಕು: ತಳ್ಳಲಾದ ಆದರೆ ಎಂದಿಗೂ ತಲುಪದ DNS

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

ಹಸ್ತಾಂತರವನ್ನು ಕೈಯಿಂದ ಮಾಡಿ ಪರೀಕ್ಷಿಸಿ, ಇದು «ಸರ್ವರ್ ತಪ್ಪು» ಮತ್ತು «ಯಾರೂ ಅನ್ವಯಿಸಲಿಲ್ಲ» ನಡುವೆ ವ್ಯತ್ಯಾಸ ಮಾಡುತ್ತದೆ:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

ಎಲ್ಲವನ್ನೂ ಹಿಡಿಯುವ ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಪ್ರತಿ ಹೆಸರನ್ನೂ ಆ ಲಿಂಕಿಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಇದು ಪೂರ್ಣ-ಟನೆಲ್ ಕ್ಲೈಂಟ್ ಬಯಸುವುದು ಮತ್ತು ವಿಭಜಿತ DNS ಬಳಸಬಾರದಾದದ್ದು. ಈ ಸೆಟ್ಟಿಂಗ್ಗಳು ಮುಂದಿನ ಸಂಪರ್ಕದಲ್ಲಿ ಮಾಯವಾಗುತ್ತವೆ. NetworkManager ನಲ್ಲಿ ಅವನ್ನು ಶಾಶ್ವತಗೊಳಿಸಲು ಸ್ವಯಂಚಾಲಿತ DNS ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ, ಸಂಪರ್ಕದಲ್ಲಿ ಸರ್ವರ್ ಹೊಂದಿಸಿ ಮತ್ತು ಡೊಮೇನ್ ಸೇರಿಸಿ:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

ಒಳಗಿನ ಹೆಸರುಗಳಿಗೆ ಮಾತ್ರ ಉತ್ತರಿಸಬೇಕಾದ ಕಂಪನಿ ಟನೆಲ್ಗಾಗಿ, ಆ ವಲಯಗಳನ್ನು ಎಲ್ಲವನ್ನೂ ಹಿಡಿಯುವ ಬದಲು ಆರಂಭದ ಟಿಲ್ಡೆಯೊಂದಿಗೆ ಪಟ್ಟಿ ಮಾಡಿ, ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಸ್ಥಳೀಯ ರೆಸಾಲ್ವರ್ ಬಳಸುವಂತೆಯೇ.

ಮುಂದಿನ ಅಡಚಣೆಯಾಗುವ ಪರಿಹಾರಗಳು

ಸಂಪರ್ಕಿಸುವ ಮೊದಲು resolv.conf ನಕಲಿಸಿ ನಂತರ ಮರುಸ್ಥಾಪಿಸುವುದು runbook ನಲ್ಲಿ ಕಾನೂನುಬದ್ಧ ಸಾಲು, ಮತ್ತು ಇದು ಸರಿಪಡಿಸುವಿಕೆ ಅಲ್ಲ, ಪರಿಹಾರ. ಕ್ರ್ಯಾಶ್ ಅಥವಾ ಬಲವಂತದ ಮರುಬೂಟ್ ಮರುಸ್ಥಾಪನೆಯನ್ನು ಬಿಟ್ಟುಬಿಡುವುದರಿಂದ ಅದು ಮುಖ್ಯವಾದಾಗಲೇ ವಿಫಲವಾಗುತ್ತದೆ. ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದರ ಮೇಲೆ ಕಟ್ಟದಂತೆ ಪರಿಹಾರ ಎಂದು ಬರೆದಿಡಿ.

systemd-resolved ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ಸಾರ್ವಜನಿಕ ಸರ್ವರ್ಗಳನ್ನು ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡುವುದು ಇನ್ನೊಂದು ಜನಪ್ರಿಯ ಹೆಜ್ಜೆ. ಇದು ಸಂಪರ್ಕ ಮತ್ತು ಡಿಸ್ಕನೆಕ್ಟ್ ಅನ್ನು ಊಹಿಸಬಹುದಾದಂತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಇತರ ನೆಟ್ವರ್ಕ್ಗೆ ಪ್ರತಿ-ಲಿಂಕ್ DNS ತೆಗೆದುಹಾಕುತ್ತದೆ, ಇದು ಒಳಗಿನ ಹೆಸರುಗಳ ವಿಭಜಿತ DNS ಮುರಿಯುತ್ತದೆ ಮತ್ತು ಪ್ರಶ್ನೆಗಳನ್ನು ಒಳಗೆ ಇಡಲು ಮಾಡಿದ ಟನೆಲ್ನ ಉದ್ದೇಶವನ್ನು ವಿಫಲಗೊಳಿಸುತ್ತದೆ. resolvconf ಸ್ಥಾಪಿಸಿ ಸಾರ್ವಜನಿಕ ಸರ್ವರ್ಗಳನ್ನು ಪಿನ್ ಮಾಡುವುದು ಹೆಚ್ಚುವರಿ ಪದರದೊಂದಿಗೆ ಅದೇ ವೆಚ್ಚ. ಎರಡರಲ್ಲಿ ಯಾವುದನ್ನೂ ರೋಗನಿರ್ಣಯವೆಂದು ಪರಿಗಣಿಸಿ: ಅದು ಬ್ರೌಸಿಂಗ್ ಮರಳಿಸಿದರೆ, ರೆಸಾಲ್ವರ್ ಸಂಯೋಜನೆಯೇ ದೋಷಿ ಎಂದು ತಿಳಿದೀರಿ, ಸಾರ್ವಜನಿಕ ಸರ್ವರ್ಗಳು ಸರಿ ಎಂದಲ್ಲ.

ಶಾಶ್ವತ ಪರಿಹಾರ ಪ್ರತಿ ಪದರಕ್ಕೆ ಒಬ್ಬ ಮಾಲೀಕ: ಟನೆಲ್ ಲಿಂಕ್ನ DNS ಯಾರ ಘಟಕದ್ದು ಮತ್ತು ಜಾಗತಿಕ ಡೀಫಾಲ್ಟ್ ಯಾರದ್ದು ಎಂದು ನಿರ್ಧರಿಸಿ, ಅದನ್ನು ಬರೆಯಿರಿ ಮತ್ತು ಉಳಿದವನ್ನು ಮಾರ್ಗದಿಂದ ತೆಗೆದುಹಾಕಿ. ನಂತರ ಡಿಸ್ಕನೆಕ್ಟ್ ನಂತರ VPN ಮಾತ್ರ ಪರಿಹರಿಸುವ ಹೆಸರಿನಿಂದ ಪರಿಶೀಲಿಸಿ. ಖಾಸಗಿ ಹೆಸರು ಇನ್ನೂ ಉತ್ತರಿಸಿದರೆ ನೋಂದಣಿ ತೆಗೆದಿಲ್ಲ; ಏನೂ ಪರಿಹರಿಸದಿದ್ದರೆ ಫೈಲ್ ಇನ್ನಿಲ್ಲದ ಸರ್ವರ್ಗೆ ತೋರಿಸುತ್ತದೆ. ಎರಡೂ ಬ್ರೌಸರ್ ತೆರೆಯುವ ಮೊದಲು resolvectl ನಲ್ಲಿ ಕಾಣುತ್ತವೆ.