Networking for the help desk interview questions

The ticket describes a full-tunnel VPN that sends all traffic, including DNS, through the organisation. When the tunnel is up, the user reaches internal resources but cannot resolve public names because the internal resolver is unreachable or cannot forward them. When the tunnel is down, DNS works again but internal resources are out of reach. The two things to check first, in order, are the DNS servers the client is using while connected, and whether the internal resolver can forward queries for public names. If the resolver is the cause, adding a forwarder or a conditional forwarder on the server side fixes the class of tickets rather than one user at a time.

A 169.254 address is one the device gave itself because DHCP found no server to lease from; RFC 3927 reserves 169.254.0.0/16 for such link-local addresses, and Microsoft calls the Windows behaviour APIPA. The device can only speak to other hosts on the same link, so a user with 169.254 sees "internet down". The cheap check is ipconfig /release then ipconfig /renew for that adapter on Windows, or turning Wi-Fi off and on; if a 169.254 address comes back, the DHCP server or the link to it is the suspect, not the laptop. Look at other devices on the same subnet before you touch the DHCP server: if they all show 169.254, the server is out; if only this device does, its own link to the server is the suspect.

Flushing clears the OS cache on the user's device, so the next lookup walks the chain again. It helps for the one case where the OS cache carries an answer that is older than the real record and the TTL has not run out; the classic signature is one resolver returning the old value while a public resolver returns the current one. It helps nothing when the record at the authoritative server is itself wrong (every flush replays the same bad answer until the record is fixed), when the configured resolver is down (no cache is involved), when a line in the hosts file beats the cache (hosts wins over cache every time) or when the pattern is split DNS or browser secure DNS (the lookup never goes through the OS cache you cleared). Read the resolver answers before you run the command.

Two things have to be true before a device can see 6 GHz, and either one can be missing. Its own radio must be built for the band, which means the Wi-Fi 6E or Wi-Fi 7 label; a phone rated for Wi-Fi 6 cannot see a 6 GHz network at all, however long it scans. And the band must be allowed where you are, because each country sets which bands and channels a radio may use. So the first check is your own access points, not the phone: confirm that they broadcast on 6 GHz here and that the same network name is on every band. If 6 GHz is not offered, the phone is right and there is nothing to fix. If it is offered, compare the phone's specification against the band before changing a setting on it.

Rung 1 is the link. Get-NetAdapter on Windows shows whether the adapter is Up, and ip link show on Linux or ifconfig en0 on a Mac does the same; if it is down, fix the cable or the Wi-Fi join and stop. Rung 2 is the address. ipconfig /all on Windows, ipconfig getifaddr en0 on a Mac or ip -4 addr show on Linux shows it; a 169.254 address means DHCP never answered, so look at the lease and not at DNS. Rung 3 is the gateway: ping the default gateway that ipconfig lists, and a reply in a few milliseconds means the local network works. Stop at the first rung that fails, since each rung depends on those below it, and write down which rung failed and what it printed so the next person can continue.