Gitead/DentalManagementMH07
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: add troubleshooting for router DNS rebinding protection

Browse Source 
Some routers (confirmed on Verizon Fios/G3100) block the local-<office>
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 <noreply@anthropic.com>
This commit is contained in:
ff
2026-07-12 23:34:48 -04:00
parent c4c69bfd62
commit 8b245d00c6
1 changed files with 68 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
README.md
View File

@@ -657,6 +657,74 @@ sudo nginx -t && sudo systemctl reload nginx
Staff can now use `https://local-<office>.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-<office>.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 <hostname>`
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-<office>.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-<office>.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-<office>.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-<office>.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)