Raise the auth.yokogawa.tech pinpoint record, and check for it

The DC is authoritative for a yokogawa.tech zone holding pinpoint records only,
so from inside the VNet every name not in that zone is NXDOMAIN rather than
forwarded. ai and influx are in it. auth is not.

So an operator on cicore1 resolves ai.yokogawa.tech, reaches Caddy, is
redirected to https://auth.yokogawa.tech/?rd=... and cannot resolve it. The
assistant is reachable and cannot be signed into. Nothing caught this because
influx is the only other pinpointed hostname and LAN traffic to it uses the
bypassed API paths, which never touch the portal - ai.yokogawa.tech is the
first thing here a LAN client must interactively sign in to.

verify.sh now resolves auth.yokogawa.tech alongside the hostnames that redirect
to it, and fails rather than shrugging when it is missing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

REQUESTS.md

@@ -5,6 +5,9 @@ is blocking: as at **21 August 2026** the assistant runs end to end on `lin001`
 resolution, the data translator, document search, all four answer lanes, the rulebook, the
 working panel and the logbook are all live and were exercised by hand on the host.
 
+**Item 4 was found on 27 August 2026 while verifying item 2 and is the smallest of the
+four — one DNS record — but it blocks the operator demo completely.**
+
 **Item 2 was delivered on 27 August 2026 and is closed** — it is kept below as a record of
 what was asked for and what arrived. What is still missing is the AI model itself and real
 plant data. Both depend on someone outside this project and neither can be hurried at the
@@ -19,6 +22,7 @@ Item 3 needs the owner of the `imh` historian, who is not yet identified.
 | 1 | Azure OpenAI account, 3 deployments | The two AI steps — classifying the question, wording the answer | Phases 6, 8; the safety review |
 | 2 | ~~Three public DNS records + DC pinpoint records~~ | Reaching the assistant by name from a control-room PC | **Delivered 27 Aug 2026 — closed** |
 | 3 | Read-only login to the `imh` historian | Real plant figures instead of stand-ins | Phases 4, 5; every data answer |
+| 4 | One more DC pinpoint record: `auth.yokogawa.tech` | Signing in from a control-room PC at all | Phase 7; any operator demo |
 
 ---
 
@@ -124,6 +128,47 @@ when a person outside this project opens a browser. It also depends on two diffe
 
 ---
 
+## 4. One more pinpoint record on the DC: `auth.yokogawa.tech`
+
+### What is needed
+
+**`auth.yokogawa.tech` → `10.0.0.17`** on the domain controller, the same treatment
+`ai.yokogawa.tech` and `influx.yokogawa.tech` already have. Contact: **Daniel Watson**.
+
+Nothing else. No public record — `auth.yokogawa.tech` already resolves publicly and works.
+
+### What it is for
+
+Signing in. The DC is authoritative for a `yokogawa.tech` zone that contains pinpoint
+records only, so from inside the VNet every name **not** in that zone is NXDOMAIN — not
+forwarded to public DNS. `ai` and `influx` are in it. `auth` is not.
+
+An operator at `cicore1` therefore gets: `ai.yokogawa.tech` resolves to `10.0.0.17`, Caddy
+answers, Authelia redirects the browser to `https://auth.yokogawa.tech/?rd=...`, and the
+browser cannot resolve it. The assistant is reachable and cannot be logged into.
+
+### Why it was not caught earlier
+
+Every other service behind Authelia is reached from the internet, where `auth` resolves
+normally. `influx.yokogawa.tech` is the one exception with a pinpoint record, and LAN
+traffic to it uses the **bypassed** API paths — `^/api/v2/write`, `^/api/v2/query`,
+`^/health` — which never touch the portal. `ai.yokogawa.tech` is the first thing on this
+host that a LAN client must interactively sign in to.
+
+Duo is unaffected: Authelia calls the Duo API server-side from `lin001`, so the browser
+never needs to reach `duosecurity.com`.
+
+### How to confirm it is fixed
+
+On the SCADA machine, before opening a browser:
+
+```
+nslookup ai.yokogawa.tech      → 10.0.0.17
+nslookup auth.yokogawa.tech    → 10.0.0.17   (NXDOMAIN today; this is the request)
+```
+
+---
+
 ## 3. A read-only login to the `imh` historian
 
 ### What is needed

scripts/verify.sh

@@ -58,10 +58,17 @@ head_ "Public endpoints - expect 302 to the auth portal"
 # and cube do not. So on this host those three do not resolve at all, and that
 # says nothing about whether they work from a browser. The check reports the
 # two cases separately rather than calling both a failure.
-for host in lf.yokogawa.tech cube.yokogawa.tech api.yokogawa.tech ai.yokogawa.tech; do
+# auth.yokogawa.tech is in this list because every one of the others redirects
+# to it. A hostname that resolves and answers is still unusable if the portal it
+# sends the browser to does not resolve - which is exactly the case on the LAN.
+for host in lf.yokogawa.tech cube.yokogawa.tech api.yokogawa.tech ai.yokogawa.tech auth.yokogawa.tech; do
   if ! getent hosts "$host" >/dev/null 2>&1; then
-    printf '  ??   %s does not resolve FROM THIS HOST (no DC pinpoint record) - check it from outside the VNet
+    if [ "$host" = "auth.yokogawa.tech" ]; then
+      bad "auth.yokogawa.tech does not resolve from inside the VNet - every gated hostname redirects here, so nobody on the LAN can sign in. Needs a DC pinpoint record -> 10.0.0.17 (REQUESTS.md item 4)"
+    else
+      printf '  ??   %s does not resolve FROM THIS HOST (no DC pinpoint record) - check it from outside the VNet
 ' "$host"
+    fi
     continue
   fi
   code=$(curl -s -o /dev/null -w '%{http_code}' -I "https://$host" --max-time 10 || echo "000")