If Kali reports Temporary failure resolving, first check which name failed and how your system tried to resolve it. This guide separates connection problems, system name lookup, VPN-only names and application errors before you change a DNS setting.
Environment: this guide uses a Kali terminal and, where available, NetworkManager. WSL, containers, custom images and other network managers may use a different configuration path. Start with the inspection steps. Commands labelled configuration change apply only to the stated branch.
1. Inspect name lookup before changing settings
Run in: Kali terminal. Keep the exact failing hostname and error. For a public-domain example, the commands below use kali.org. Replace it with the actual permitted hostname you are investigating. A successful test of one name does not establish that every other name works.
System name lookup — no configuration change
getent ahosts kali.orgIf addresses appear: the system name-service path returned addresses for this query. Continue with the application branch if the original app still fails.
If nothing appears or lookup fails: record that result and inspect the connection below. getent uses the system’s Name Service Switch configuration, which may include local files and other sources as well as DNS. Success does not prove that a particular upstream DNS server answered. Reference: getent manual.
Connection and resolver inspection — run and read each line
nmcli general status
nmcli device status
nmcli connection show --active
ip -br address
ip route
ip -6 route
ls -l /etc/resolv.conf
cat /etc/resolv.confRead these together: the active profile name and UUID, its device, available routes, and whether /etc/resolv.conf is generated or points to another file. A loopback nameserver can be a local forwarding resolver. Its presence alone is not a fault.
nmcli is missing, NetworkManager is inactive, or the device is unmanaged
Stop the NetworkManager-specific instructions here. Identify the component that configures this environment, such as its WSL networking integration, container runtime, VPN client or another network manager. Installing or starting NetworkManager is not a universal repair. Use that environment’s documented configuration path.
For a device managed by NetworkManager, replace DEVICE with the device name shown above:
nmcli device show "DEVICE"Look for: active IPv4 and IPv6 addresses, routes, DNS servers and domains. Several devices or VPNs may contribute settings. A listed DNS address is configuration evidence; it does not by itself show that a query reached that server.
Checkpoint: keep the failing hostname, lookup result, profile UUID, device and resolver-file information. Choose the branch below instead of changing every DNS setting.
2. Choose the branch that matches your result
| What you observed | What it supports | Next check |
|---|---|---|
| Public-name lookup fails and the intended outside connection is missing | Connection or routing needs investigation. | Check the intended connection or VM network. |
| System lookup fails although an appropriate resolver and route are configured | The name-service or resolver path still needs diagnosis. | Identify the resolver manager and compare a DNS query. |
| Public names work; a private VPN name fails | The failure is specific to that name or resolution path. | Check VPN DNS and domain routing. |
| System lookup works; the browser or apt still fails | Name lookup succeeded in that system context. | Read the application’s exact error. |
| Kali only has an intentionally isolated lab connection | Internet access may be absent by design. | Confirm the design before changing adapters. |
What do route checks and ping actually tell me?
A default route is relevant when the destination needs it. A local resolver or VPN network may have a specific route without a general internet default. Check the route to the intended resolver, not just whether default via appears.
Replace RESOLVER_IP with the appropriate configured resolver address.
ip route get RESOLVER_IPFor an IPv6 resolver, use ip -6 route get RESOLVER_IPV6 with its real address. The selected path alone does not establish reachability or a DNS response.
A successful ping shows an ICMP response from that address under those conditions. It does not prove that DNS, HTTPS or package downloads work. A timeout can reflect ICMP filtering. Record the error rather than turning every failed ping into a DNS diagnosis.
3. Identify the resolver path before editing a file
Read the symlink and contents of /etc/resolv.conf from step 1. Then check which component manages it. NetworkManager, a local resolver, DHCP integration or VPN software may supply the configuration. A file owner or symlink alone is not a complete diagnosis.
Compare system lookup with a direct DNS query
If dig is already available and querying this resolver is permitted, compare the same name against an explicit resolver. Use the resolver intended for that domain; do not send private lab names to a public service.
dig @RESOLVER_IP QUERY_NAME A +time=2 +tries=1Replace both placeholders. This is a direct A-record query to the selected server, not a replay of the entire system name-service path. Record the status, answer, server and any timeout. For an IPv6 address-record question, use AAAA; A and AAAA are record types, distinct from the transport used to contact the resolver.
- NOERROR with an answer: this resolver answered that query. If getent still fails, investigate the system name-service integration.
- NOERROR without the requested answer: inspect the record type, aliases and response; do not call it universal DNS failure.
- NXDOMAIN: the server reports that the queried name does not exist. Check spelling, the fully qualified private name and the correct resolver.
- SERVFAIL or REFUSED: retain the status and investigate the resolver or its policy.
- Timeout: investigate the path, filtering and resolver availability. It is not proof of a nonexistent name.
If dig is unavailable, keep the getent result and configuration record. Do not depend on installing a new package to begin diagnosing a connection that cannot reach repositories. Reference: BIND dig documentation.
If this machine uses systemd-resolved
When that service is present and active, inspect resolvectl status to see link-specific DNS and domains, and use resolvectl query QUERY_NAME for the actual name. These commands are a branch for that resolver setup, not a requirement for every Kali installation. Follow the systemd VPN DNS guidance when private names need a particular link.
Checkpoint: you should know what name failed, which configuration component owns the intended path, and what remains unverified. Configure that component rather than repeatedly overwriting a generated file.
If the host works but Kali VM does not
Open the Kali VM’s adapter settings and the hypervisor’s virtual-network configuration. Compare the exact network name, cable state, addressing service and intended outside access. A working host browser does not establish the guest’s configuration.
| Intended setup | First comparison |
|---|---|
| Ordinary browsing or package downloads through a VM NAT connection | Check the guest’s connected adapter, DHCP settings, routes and assigned resolver. |
| Host-only or internal vulnerable-machine lab | Confirm whether outside access is intentionally absent. Public DNS cannot create a missing internet path. |
| Bridged guest | Check whether the physical network permits that guest and supplies the expected addressing. |
| Multiple Kali adapters or a VPN | Identify which device, route and resolver serve the queried domain. |
Keep the lab boundary deliberate. Do not switch the vulnerable target to bridged networking or add an outward path just to make updates work. If Kali needs a separate update connection, plan it separately, keep the vulnerable target off while changing the arrangement, and recheck adapters and forwarding before lab practice. See the lab network setup guide and VirtualBox networking documentation.
If only VPN or private lab names fail
Keep the exact private name, VPN state, intended resolver and relevant domain. Compare connection details before and after VPN activation. A public resolver may correctly be unable to answer a private name.
- Use the VPN or training provider’s documented resolver and domain settings.
- Check that the intended resolver has a route through the appropriate connection.
- Distinguish a short name that needs a search domain from a fully qualified name.
- Where split DNS is required, check which domains use which resolver.
Do not replace required private DNS with public DNS to test a private hostname. NetworkManager’s DNS handling depends on its resolver integration and profile properties. Use the profile reference or the VPN’s instructions for that actual configuration. Proxy-specific behavior belongs in the proxy DNS guide.
If lookup works but apt or the browser still fails
| Error or discrepancy | Check next |
|---|---|
| Temporary failure resolving / Could not resolve | Test the exact hostname from that error in the same network context. Another domain working does not settle this one. |
| 404 or missing repository metadata | Inspect the repository URL and official Kali source configuration. |
| Signature or NO_PUBKEY error | Use official Kali repository/key guidance. A DNS override does not repair repository trust. |
| TLS or certificate error | Inspect date/time, hostname, certificate, proxy and network policy. |
| Browser works but getent fails | Compare browser cache, secure DNS and proxy behavior with the system lookup path. |
| getent returns addresses but the application times out | Inspect the app’s chosen address family, route, port, proxy and service availability. |
Keep the exact error before editing repositories or buying replacement services. Follow official Kali repository guidance for source configuration. A resolver fix and an application fix answer different questions.
4. Make a profile change only when the diagnosis supports it
Applies to: a connection actually managed by NetworkManager, with a verified DNS configuration issue, on a network whose settings you may change. Stop here for a required VPN, managed network or different resolver owner until you have its documented configuration requirements.
Record the original values first
Use the profile UUID from nmcli connection show --active. Profile UUIDs help distinguish similarly named connections. Replace PROFILE_UUID below. Save this output privately before changing anything; it is the source for your rollback.
nmcli -f connection.id,connection.uuid,ipv4.method,ipv4.dns,ipv4.dns-search,ipv4.ignore-auto-dns,ipv6.method,ipv6.dns,ipv6.dns-search,ipv6.ignore-auto-dns connection show uuid "PROFILE_UUID"The following branches change only the named IPv4 DNS properties. They do not repair all IPv6, split-DNS, routing or resolver-integration problems. Preserve any intentional private domains and test both address families when relevant.
Branch A — Restore automatic IPv4 DNS on a DHCP connection
Configuration change. Use only if the profile has ipv4.method auto, this network is meant to supply DNS automatically, and you have established that a stale manual override should be removed. Clearing the manual DNS list is intentional in this branch; do not do it when those entries are required.
sudo nmcli connection modify uuid "PROFILE_UUID" ipv4.dns "" ipv4.ignore-auto-dns noThis does not clear or repair a separate search-domain override. Review that recorded property separately if it is part of the fault. Continue to the activation step only after reviewing the intended change.
Branch B — Use a chosen IPv4 resolver on an unmanaged test connection
Configuration change. Use only when an explicit IPv4 resolver is appropriate for this connection and you have confirmed it serves the required public names. Replace DNS_SERVER_IP with the resolver you chose; no public resolver is a universal fix.
sudo nmcli connection modify uuid "PROFILE_UUID" ipv4.dns "DNS_SERVER_IP" ipv4.ignore-auto-dns yesWith automatic IPv4 configuration, ignore-auto-dns yes ignores automatically supplied name servers and search domains. Existing manual search-domain values remain relevant. Review these consequences before applying the change. This branch does not override every DNS source on other active devices or fix IPv6.
Apply separately from editing the profile
Connection interruption: reactivation can interrupt the network, SSH or VPN. Use the local console with access to the recorded original settings and any credentials the connection normally needs. Do not run a down command in a remote-only session without an established recovery method.
Replace PROFILE_UUID. Run the lines individually from the local console:
sudo nmcli connection down uuid "PROFILE_UUID"
sudo nmcli connection up uuid "PROFILE_UUID"If activation fails, keep the error and use the recorded profile values for rollback rather than repeatedly trying different DNS addresses. See nmcli activation and profile commands.
5. Repeat the same query and keep a rollback
Keep the same failing name, network and VPN state for a meaningful before-and-after comparison. Repeat the system lookup, the relevant application request and, if used, the explicit DNS query. Inspect the active device settings again.
- Public lookup: does the original public name resolve through the intended path?
- Private names: do required local or VPN names still resolve correctly?
- Application: does the original failing operation now work?
- Reconnect: does the result survive reconnection? Check reboot behavior when practical.
- Address families: compare IPv4 and IPv6 behavior where both are relevant.
If the change made things worse: restore the exact original values of every property you changed. For either IPv4 example above, replace the placeholders from your saved record:
sudo nmcli connection modify uuid "PROFILE_UUID" ipv4.dns "ORIGINAL_DNS_LIST" ipv4.ignore-auto-dns ORIGINAL_YES_OR_NOIf the recorded manual DNS list was empty, replace "ORIGINAL_DNS_LIST" with "". Use the recorded yes/no value, not a guessed default. Restore any additional properties you changed, then reactivate from the local console as above and repeat the original checks. Configuration changes need activation before the active connection reflects them.
Finish line: you can state the failing name and stage, the evidence for your diagnosis, the one change made, whether the original problem improved, and how to restore the prior settings. If the cause remains unknown, a precise record is still useful progress.
Keep a before-and-after DNS note
Use sanitized notes. This field has no submission or automatic saving. Copy or download it before leaving or reloading; do not enter passwords, tokens or private client information.
Teaching example: browser success and system lookup failure
Illustrative example, not a performed lab test. A browser opens a site while getent fails for the same name. The browser may use a cache, proxy or its own resolver. Record the queried name and application settings, then compare an uncached permitted query through the intended path. This discrepancy does not by itself justify replacing system DNS settings.
Short answers to common questions
Should I edit resolv.conf? Identify its manager first. An edit to a generated file may disappear at reconnect.
Should I use public DNS? Only where it serves the intended names and fits the network’s requirements. It will not create a missing route or answer private domains it does not know.
Must I reinstall Kali? The symptoms here do not establish a need to reinstall. Diagnose the connection, name-service path and application first.
What should I share when asking for help? The exact error, sanitized environment, queried name category, relevant connection details and the tests already performed. Keep full private configuration in your own record.
Editorial update: October 26, 2026. Reorganized by symptom and environment; separated inspection, conditional changes, activation and rollback. Command semantics reviewed against the linked documentation. Examples are illustrative; no live Kali network change, VPN test or resolver test was performed. Author and evidence policy.