DNS and DHCP Failure: First 30 Minutes

This article applies when yacht users report that "the internet is down," but the actual failure may be local DNS, DHCP, gateway assignment, firewall forwarding, Wi-Fi client addressing, or a stale upstream resolver.

Applicability depends on the yacht network design, whether DNS and DHCP live on the firewall, Windows/Linux server, Wi-Fi controller, cloud-managed gateway, SatCom router, or separate appliance, and whether the affected network is guest, crew, owner office, AV/control, CCTV, infrastructure management, bridge-adjacent, or engineering OT.

This is a first-response runbook. It does not replace the yacht's approved incident procedures, vendor support process, cyber response plan, or class/flag expectations where safety-related systems are involved.

DNS and DHCP faults often look like internet faults.

A guest phone may show Wi-Fi connected but no internet. A laptop may join the crew network but fail to open websites. A TV may stream from a local server but fail to open Netflix. The firewall dashboard may show WAN online, while users still say everything is down.

The first mistake is assuming that the satellite link failed. The second mistake is rebooting every visible box until something changes.

The first 30 minutes should answer three questions:

• Are devices getting valid addresses?
• Can addressed devices reach the gateway and internet by IP?
• Can they resolve names reliably?

If those three answers are separated, the team can stop guessing.

Start by identifying who is affected.

Ask:

• Is the problem on one device, one cabin, one SSID, one VLAN, or the whole yacht?
• Are wired and wireless devices both affected?
• Are guest, crew, owner, AV, CCTV, or technical devices affected differently?
• Did the issue start after a WAN failover, firewall change, Wi-Fi change, shore-power event, or vendor support session?
• Are local services still reachable?

This matters because DNS and DHCP faults can be local to one zone. A guest DHCP scope can fail while owner office still works. A DNS forwarder on the firewall can fail while direct IP connectivity is fine. A Wi-Fi controller can place clients in the wrong VLAN while the WAN remains healthy.

Tell the bridge or captain what you know in plain language:

"We are checking whether this is a vessel-wide internet failure or a local addressing/name-service fault. Please avoid asking vendors to reset WAN equipment until we confirm the fault boundary."

That message prevents parallel troubleshooting from making the evidence worse.

Pick one affected device and one known-good test device if available. Do not start with ten devices at once.

Check the affected device:

• IP address.
• Subnet mask or prefix.
• Default gateway.
• DNS server.
• Lease time.
• Wi-Fi SSID or switch port.
• VLAN if visible from the network controller.

Common clues:

• An address beginning `169.254` usually means the device did not receive DHCP.
• A valid-looking IP with no gateway points toward DHCP option or scope trouble.
• A valid IP and gateway with a bad DNS server points toward DNS option trouble.
• A valid IP on the wrong subnet points toward VLAN, SSID mapping, or switch-port assignment.
• A very old lease may hide a DHCP outage until devices renew.

Compare the result with the IP plan. If the device should be in guest VLAN 20 but has an address from an AV/control range, stop and investigate VLAN assignment before chasing the WAN.

Now separate routing from name resolution.

From an affected device, test:

• Can it reach its default gateway?
• Can it reach the firewall or router address for its zone?
• Can it reach a public IP address where allowed?
• Can it reach another known local service in the same zone?

If the device cannot reach its gateway, the likely fault is local: Wi-Fi association, VLAN mapping, switch port, DHCP assignment, or firewall interface state.

If the device can reach the gateway but cannot reach a public IP, look at firewall policy, WAN failover, SD-WAN route, NAT, or upstream link state.

If the device can reach a public IP but cannot open websites by name, focus on DNS.

Keep the tests simple. The goal is not a perfect network audit. The goal is to choose the correct fault path.

DNS failure can make a healthy connection look broken.

Test name resolution from an affected device:

• Resolve a public name.
• Resolve a known internal name if used onboard.
• Try the DNS server handed out by DHCP.
• Compare with a known alternative resolver only as a diagnostic step.

Do not permanently point random yacht devices at public DNS just to make the immediate problem go away. That can break internal names, filtering, logging, split DNS, captive portals, or provider-specific functions.

Check the DNS service itself:

• Is the resolver running?
• Is the firewall DNS proxy healthy?
• Are upstream forwarders reachable?
• Did WAN failover leave DNS forwarding pointed at an unavailable provider?
• Are filtering or security services blocking resolution?
• Are internal DNS records still present?

On a yacht, DNS may be involved in more than web browsing. Cloud controllers, monitoring tools, AV services, update systems, VPNs, and identity platforms may all depend on it.

If devices are not receiving valid addresses, check DHCP.

Find the authoritative DHCP server for the affected network. It may be:

• Firewall.
• Windows server.
• Linux service.
• Router.
• Wi-Fi gateway.
• Cloud-managed network appliance.
• Vendor controller.

Check:

• Is the scope enabled?
• Is the scope exhausted?
• Is the lease pool too small for the number of guest devices?
• Are reservations conflicting?
• Are DHCP relay or helper addresses correct?
• Is the server reachable from the affected VLAN?
• Are there duplicate DHCP servers on the same network?

Scope exhaustion is common on guest networks during charter or owner trips. A small pool that worked during commissioning may fail when guests arrive with phones, tablets, watches, laptops, consoles, and streaming devices.

Duplicate DHCP is another common refit problem. A temporary router or vendor device may start handing out wrong gateways or DNS servers. If some devices work and others get strange settings, look for an unauthorised DHCP source.

By this point, the team should know the likely fault path:

• DHCP failure.
• DNS failure.
• VLAN or SSID mapping issue.
• Firewall/gateway problem.
• WAN or upstream provider issue.
• Device-specific issue.

Stabilise only what you understand.

Reasonable short-term actions may include:

• Restarting a failed DNS or DHCP service.
• Expanding a guest DHCP pool if the design allows it.
• Removing an unauthorised DHCP device.
• Restoring a known-good firewall/DHCP configuration.
• Temporarily changing DNS forwarders with approval and a rollback note.
• Moving a misassigned SSID or port back to the correct VLAN.
• Escalating to the WAN/SatCom provider if local services are confirmed healthy.

Record what changed. A quick fix that is not recorded becomes the next mystery.

Capture evidence before resets where practical.

Keep:

• Time and affected network.
• Device IP, gateway, DNS, and SSID/port.
• DHCP scope status.
• DNS test result.
• Gateway and public IP test result.
• Firewall or router WAN status.
• Recent changes or vendor sessions.
• Screenshots of relevant errors.
• Logs if available.
• Action taken and rollback note.

If the issue affects owner office systems, personal data, bridge-adjacent gateways, CCTV, access control, or engineering networks, treat the evidence more carefully. The incident may be more than guest convenience.

A yacht reports that guest internet has failed during a trip. The Starlink and VSAT dashboards both show online. Crew phones still work. Owner office laptops still work. Guest phones show Wi-Fi connected but no internet.

The first useful test is not calling the satellite provider. It is checking a guest device.

The guest phone has no valid DHCP lease. The firewall shows the guest DHCP scope is exhausted. The yacht added more connected guest devices than the original pool allowed, and several old leases are still active.

The short-term fix is to extend the scope within the approved guest subnet and clear stale leases if safe. The proper closeout is to update the IP plan, adjust lease time for guest networks, review DHCP monitoring, and make the change visible in the network record pack.

The WAN was never down. The address plan was too narrow for the real guest load.

Do not reboot the WAN edge before checking local addressing. If the WAN is healthy, rebooting provider equipment wastes time and may make logs harder to read.

Do not change DNS settings permanently without understanding why the original resolver failed. A public resolver can hide the symptom while breaking internal services.

Do not forget DHCP lease timing. Devices can continue working on old leases after the DHCP server fails, so the fault may appear gradually.

Do not ignore one-zone failures. Guest outage, AV controller outage, CCTV management outage, and crew admin outage have different consequences.

Do not leave temporary fixes undocumented. DNS and DHCP changes are small enough to be forgotten and important enough to cause serious confusion later.