---
type: reference
title: Network
description: LAN topology for the fleet and the client-side DNS pinning rule for multi-homed Linux workstations.
tags:
  - network
  - dns
  - systemd-resolved
  - workstation
  - unverified
verified: 2026-08-28
---

# Network

How the LAN is addressed, which host answers what, and the one DNS rule that
bites every Linux workstation with both Wi-Fi and Ethernet plugged in.

---

## Topology

| Host | IP | Role |
|------|----|------|
| Router | 192.168.0.1 | DHCP; hands out the DNS server to clients |
| Dankclaw | 192.168.0.143 | Pi-hole DNS, Caddy edge, Gitea, large inference model |
| Dankserver | 192.168.0.235 | small inference model |
| Clients | DHCP from 192.168.0.0/24 | workstations, phones |

The router hands clients `192.168.0.143` as their DNS server; Pi-hole answers
every `*.franksdank.cloud` name with the LAN address of the box that serves
it. Names that resolve to the public WAN address time out on the LAN because
the G36 has no NAT loopback — a symptom that looks like "the network is
down" and is not. Full DNS mechanics live in the serverAppConfigs knowledge
base (`Infrastructure/LAN-DNS.md`); this page is the client-side view.

---

## The multi-link resolver rule

**A Linux client with two `+DefaultRoute` links will flap its DNS.**

NetworkManager marks both a wired and a Wi-Fi connection as default routes.
Both get the same DHCP DNS list from the router, and `systemd-resolved`
resolves queries against one "current" resolver *per link*. When the links
disagree — one landed on the Pi-hole address, the other on a DHCP-provided
upstream that answers with the public WAN IP — every lookup can return a
different address, and half of them time out on the LAN.

Enumerate the links and their resolvers before changing anything:

```bash
nmcli -t -f NAME,DEVICE connection show --active   # one entry per default link
resolvectl status                                 # per-link "Current DNS Server"
ip -br addr
```

The fix is to pin the LAN resolver **on each connection**, because
`/etc/systemd/resolved.conf`'s `DNS=` is only a per-link fallback and does
not override what the link itself was handed:

```bash
for c in "<wired connection>" "<wifi connection>"; do
  nmcli connection modify "$c" ipv4.method auto \
    ipv4.dns 192.168.0.143 \
    ipv4.ignore-auto-dns yes \
    ipv4.ignore-auto-routes no
done
nmcli connection up "<wired connection>"
nmcli connection up "<wifi connection>"
systemctl restart systemd-resolved
```

`method auto` keeps DHCP for address, gateway, and routes; `ignore-auto-dns
yes` makes the static resolver the only one used; `ignore-auto-routes no`
keeps the DHCP routes, so the dual-default traffic path survives.

Verify with a cache-clear loop — the name must return the LAN address on
every run, not on average:

```bash
for i in $(seq 1 10); do resolvectl flush-caches; dig romm.franksdank.cloud +short; done
```

A single successful `dig` proves nothing on a flapping resolver.

---

## Servers

- [Dankserver](/system/dankserver.md) — small inference model
- [Dankclaw](/system/dankclaw.md) — large inference model, DNS, proxy

## See Also

- [System Documentation](/system/index.md) — bundle navigation
- [CachyOS](/tools/cachyos.md) — NetworkManager, systemd-resolved, BlueZ