diff --git a/docs/Infrastructure/LAN-DNS.md b/docs/Infrastructure/LAN-DNS.md
index ad62277..17811cb 100644
--- a/docs/Infrastructure/LAN-DNS.md
+++ b/docs/Infrastructure/LAN-DNS.md
@@ -91,6 +91,34 @@ The Dankclaw host itself resolves the flat names through Pi-hole:
 
 Without this, the host would resolve the names through the router to the WAN IP and time out (no hairpin).
 
+## Dankware host DNS
+
+`dankware` is a LAN client, not a Pi-hole server. Its flat names resolve through Pi-hole (`192.168.0.143`), but its resolver setup differs from Dankclaw's because it carries two `+DefaultRoute` links.
+
+- **Two default links:** `enp47s0` (ethernet, metric 100) and `wlan0` (wifi, metric 600), each getting the same DHCP DNS list `[192.168.0.143, 1.1.1.1, …]`.
+- **The flap:** `systemd-resolved` picks a different "current" resolver per link — `enp47s0` settled on the Comcast v6 upstream (→ WAN IP, times out on the LAN), `wlan0` on Pi-hole (→ LAN IP). Flat-name resolution flapped between the two on every query.
+- **The fix:** pin `192.168.0.143` as the static IPv4 resolver on both NetworkManager connections. `resolved.conf`'s own `DNS=` is a per-link fallback, so the link itself must be pinned:
+
+```bash
+for c in "Wired connection 1" FRANKFI-5G; 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 1"
+nmcli connection up FRANKFI-5G
+systemctl restart systemd-resolved
+```
+
+`method:auto` keeps DHCP for the address/gateway/route (dual-default traffic path preserved); `ignore-auto-dns=yes` uses only the static resolver; `ignore-auto-routes=no` keeps the DHCP routes. Verify with a cache-clear loop — `romm.franksdank.cloud` should return `192.168.0.143` on every run:
+
+```bash
+for i in $(seq 1 10); do resolvectl flush-caches; dig romm.franksdank.cloud +short; done
+```
+
+The apex and unknown subdomains still fall through to Porkbun (→ `71.227.227.172`), so WAN clients and a bare `dig franksdank.cloud` keep working.
+
 ## WAN records (Porkbun)
 
 The Porkbun zone `franksdank.cloud` carries an A record for every vhost plus the apex, all pointing at `71.227.227.172`. TTL is 300. The zone has no wildcard record: unknown subdomains return NXDOMAIN. Caddy's DNS-01 challenges add and remove `_acme-challenge.*` TXT records through the same API during issuance. See [[Caddy]] for the TLS flow.
@@ -103,6 +131,7 @@ The Porkbun zone `franksdank.cloud` carries an A record for every vhost plus the
 |---------|-------------|
 | Name does not resolve on a new client | `resolv.conf` shows 192.168.0.1, not .143 — the G36 hand-off step is missing |
 | Name resolves to 71.227.x and times out on the LAN | Client used the router DNS — same root cause |
+| Flat name flaps between 192.168.0.143 and 71.227.x on one client | Two `+DefaultRoute` links; resolved picks a different "current" resolver per link. Pin 192.168.0.143 as static DNS on both NM connections — see [[#Dankware host DNS]] |
 | `dig @192.168.0.143` fails entirely | Pi-hole quadlet down: `systemctl --user status pihole` |
 | Single-label name (for example `dankclaw`) answers `127.0.1.1` | The rootless container `/etc/hosts` carries the host entry (`127.0.1.1 <host>`). FTL serves it. Use the FQDN, or an `/etc/hosts` entry on the client |
 | HTTPS works from the host but not the WAN | No port forward on the G36 for that service (manual router step) |