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 tun0ਤੁਸੀਂ tun ਇੰਟਰਫ਼ੇਸ ਨੂੰ 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 ਕਲਾਇੰਟ DNS ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਮੇਲ ਖਾਂਦੇ ਡੋਮੇਨ ਰਾਹੀਂ split 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 ਦਾ ਓਵਰਰਾਈਡ ਨਾ ਰੱਖੇ।
ਸਿਰਫ਼ ਪਹਿਲੀ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀ ਪਰਤ ਠੀਕ ਕਰੋ, ਫਿਰ ਉਹੀ ਕਮਾਂਡ ਦੁਬਾਰਾ ਚਲਾਓ। ਇੱਕੋ ਵੇਲੇ ਦੋ ਬਦਲਾਅ ਤੁਹਾਨੂੰ ਇਹ ਦੱਸਣ ਤੋਂ ਰੋਕਦੇ ਹਨ ਕਿ ਕਿਹੜਾ ਮਾਇਨੇ ਰੱਖਦਾ ਸੀ, ਅਤੇ ਅਗਲੀ ਖਰਾਬੀ ਜਾਂਚ ਸਿਫ਼ਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ।