diff --git a/session-logs/2026-06/2026-06-27-mike-jupiter-plexrequest-seerr-dns-relay.md b/session-logs/2026-06/2026-06-27-mike-jupiter-plexrequest-seerr-dns-relay.md
index eeffa28c..946da594 100644
--- a/session-logs/2026-06/2026-06-27-mike-jupiter-plexrequest-seerr-dns-relay.md
+++ b/session-logs/2026-06/2026-06-27-mike-jupiter-plexrequest-seerr-dns-relay.md
@@ -131,3 +131,48 @@ general advisory on forcing SharePoint docs to open in desktop Office (no change
   "Open in the client application"; site-collection feature "Open Documents in Client Applications
   by Default"; or per-user Sync/"Add shortcut to OneDrive". Caveat: Business Basic (no desktop
   Office license) users can hit an error instead of browser fallback.
+
+## Update: 06:52 PT — finish killing the dead `.50` resolver (Jupiter host + pfSense)
+
+Continuation of the DNS-relay work: eradicated the dead `172.16.3.50` from all active config.
+
+**1. Jupiter host DNS1 -> 172.16.0.1.** `/boot/config/network.cfg` `DNS_SERVER1="172.16.3.50"`
+-> `"172.16.0.1"` (kept `8.8.8.8`/`1.1.1.1` as DNS2/3), and live `/etc/resolv.conf` first
+nameserver updated. No network restart (would risk the SSH session). Backups
+`network.cfg.bak-20260627`, `resolv.conf.bak-20260627`. Host lookups now fast (was ~5s stall;
+the host couldn't use the `.50` relay container due to ipvlan host->own-container).
+
+**2. pfSense LAN DHCP DNS — already correct, no change.** Read `config.xml`: the only DHCP scope
+(`lan`, range `172.16.1.1-254`) already hands out `<dnsserver>172.16.0.1</dnsserver>` first, then
+`8.8.8.8`, `1.1.1.1`. So DHCP was never the source of the dead `.50` — affected hosts were
+statically configured (e.g. Jupiter, now fixed) and/or covered by the relay. pfSense system DNS =
+`8.8.8.8`/`1.1.1.1`; unbound (DNS Resolver) running on `:53`.
+
+**3. pfSense OpenVPN wizard state scrubbed.** The only other `.50` in `config.xml` was
+`$config['ovpnserver']['step10']['dns1']=172.16.3.50` — pfSense's saved **OpenVPN setup-wizard**
+state, NOT a live server (the `<openvpn>` config is empty; remote access is Tailscale/WireGuard).
+So it was inert (not pushed to any client) — my earlier "VPN clients get .50" framing was wrong.
+Scrubbed to `172.16.0.1` anyway (hygiene; prevents a future wizard re-run reintroducing it) via
+`php` `write_config()` using the skill's proven `config.inc` bootstrap, no service reload. Backup
+`/tmp/config.xml.predns-20260627.bak` on the box + pfSense config-history revision. The only
+remaining `.50` string in config is that revision's own change-note (metadata, scrolls off).
+
+**Tooling note:** all pfSense access went through the `unifi-wifi` pfSense SSH backend
+(`pfsense-ssh.sh infrastructure/pfsense-firewall run "<cmd>"`) — authenticated path (askpass +
+vaulted password, port 2248), not hand-rolled ssh. No dedicated DHCP/DNS verb exists, so used `run`.
+
+### Update — Configuration Changes
+- Jupiter (live): `/boot/config/network.cfg` DNS_SERVER1 -> `172.16.0.1`; `/etc/resolv.conf` live.
+- pfSense (live, `config.xml` via write_config): `ovpnserver/step10/dns1` `172.16.3.50` -> `172.16.0.1`.
+- No repo files changed in this update (infra-only). `wiki/systems/pfsense.md` note still TODO.
+
+### Update — Infrastructure & Servers
+- **pfSense office gateway** `172.16.0.1`, SSH port **2248**, user `admin`, pfSense 2.8.1 (FreeBSD).
+  Vault `infrastructure/pfsense-firewall.sops.yaml`. Tailscale `100.79.69.82`/`100.119.153.74`.
+  LAN DHCP scope `172.16.1.1-254`; unbound resolver on `:53` (verified 0.06s).
+- Dead host `172.16.3.50` now fully decommissioned in config; `dns-relay` container still answers
+  `.50` for any static straggler. New DHCP clients get `172.16.0.1` directly.
+
+### Update — Pending / Incomplete Tasks
+- Optional: note this pfSense `.50` cleanup + DHCP finding in `wiki/systems/pfsense.md`.
+- Seerr Plex Scan error follow-up (re-select Plex libraries) still open from earlier.