From 8b245d00c62b4847be726453576703f309ac92ce Mon Sep 17 00:00:00 2001 From: ff Date: Sun, 12 Jul 2026 23:34:48 -0400 Subject: [PATCH] docs: add troubleshooting for router DNS rebinding protection Some routers (confirmed on Verizon Fios/G3100) block the local- hostname from resolving because it's a public domain pointing at a private LAN IP, which matches the DNS rebinding attack pattern. Document the router-level fix (DNS Rebind Protection exception) and the per-machine hosts-file workaround for both the Debian server and Windows staff PCs, including the antivirus hosts-file-lock gotcha on Windows. Co-Authored-By: Claude Sonnet 5 --- README.md | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/README.md b/README.md index db48cbad..69dea892 100644 --- a/README.md +++ b/README.md @@ -657,6 +657,74 @@ sudo nginx -t && sudo systemctl reload nginx Staff can now use `https://local-.mydentalofficemanagement.com` with a trusted padlock — no certificate warnings, no CA install on any PC. +### Troubleshooting — router blocks the hostname (DNS rebinding protection) + +Some routers (this has been confirmed on Verizon Fios gateways, e.g. the G3100) refuse to resolve +`local-.mydentalofficemanagement.com` even though the DNS record is correct and public +resolvers (`1.1.1.1`, `8.8.8.8`) answer it fine. Symptoms: `ping`/`dig` against the hostname fails +or returns no answer when using the router as the DNS server, while `dig @1.1.1.1 ` +returns the right LAN IP. + +Cause: the router's **DNS rebinding protection** blocks any public hostname that resolves to a +private IP (`192.168.x.x`) — a heuristic meant to stop DNS rebinding attacks, which happens to +match this setup's pattern (public domain → private LAN IP) exactly. + +Preferred fix: on the router's admin page (e.g. `https://192.168.1.1` for Fios), look under +**Advanced → Network Settings → DNS Server** for a **DNS Rebind Protection** exception list, and +add `local-.mydentalofficemanagement.com`. If no exception list exists, disabling DNS +Rebind Protection entirely also works, at the cost of that protection network-wide. + +If you don't have router access, override DNS resolution per machine with a hosts-file entry +instead — this works because every OS checks its local hosts file before asking the router's DNS, +so the query never reaches the router: + +**Debian/Linux server itself:** +```sh +sudo nano /etc/hosts +``` +Add a line at the bottom (replace with this office's actual LAN IP and hostname): +``` +192.168.1.229 local-.mydentalofficemanagement.com +``` +Save and exit — no service restart needed, `/etc/hosts` is checked before DNS automatically. + +**Windows staff PCs (PowerShell):** +```powershell +# 1. Open PowerShell as Administrator, then confirm it's actually elevated +([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) +# must print True — if False, close this window and reopen via right-click "Run as administrator" + +# 2. Append the entry +Add-Content -Path C:\Windows\System32\drivers\etc\hosts -Value "192.168.1.229 local-.mydentalofficemanagement.com" + +# 3. Verify it saved +Get-Content C:\Windows\System32\drivers\etc\hosts -Tail 3 + +# 4. Flush the DNS cache and test +ipconfig /flushdns +ping local-.mydentalofficemanagement.com +``` + +> **If `Add-Content` fails with "the process cannot access the file... being used by another +> process,"** antivirus software (Malwarebytes, Avast/AVG "Hosts File Guard", McAfee, and some VPN +> clients are known to do this) is locking the hosts file to prevent tampering. Temporarily +> disable real-time protection, redo step 2, verify with step 3, then **re-enable antivirus** — +> the hosts file entry itself doesn't need protection disabled to keep working, only to make the +> edit. + +Editing Notepad directly instead of PowerShell is not recommended: saving +`C:\Windows\System32\drivers\etc\hosts` without true elevation fails silently in some cases (the +file appears saved but `LastWriteTime` never changes) — PowerShell's `Add-Content` surfaces a +clear permission error instead, which is easier to diagnose. + +The real Let's Encrypt certificate from Step 5 keeps working normally regardless of how each +client resolves the hostname — it was validated via DNS-01 against Cloudflare at issuance time, +not by a live connection to the server, so staff still get a trusted padlock with no warnings. + +This is a per-machine workaround; the router-level exception above is preferred when possible +since it fixes every device on the network in one place instead of requiring a hosts-file edit +(and possibly an antivirus fight) on every PC. + --- ## Twilio In-Browser Calling Setup (Dial Pad)