61 lines
2.8 KiB
Markdown
61 lines
2.8 KiB
Markdown
# UniFi Restricted-Lane DNS/NTP Recommendation — 2026-05-23
|
|
|
|
Purpose: turn the DHCP/DNS verification result into a concrete next-step design decision for `IoT`, `Camera`, and `Old IoT`.
|
|
|
|
## Inputs
|
|
- John wants restricted lanes to use `10.5.30.53` so those devices inherit the DNS blacklist policy.
|
|
- Fresh live verification showed `IoT`, `Camera`, and `Old IoT` still rely on default gateway-delivered DNS behavior.
|
|
- Current live firewall hardening stops at `Block Untrusted to Gateway Admin Surfaces`.
|
|
|
|
## Recommended decision
|
|
|
|
### DNS
|
|
Use explicit DHCP-advertised DNS for all restricted lanes:
|
|
- `IoT` -> `10.5.30.53`
|
|
- `Camera` -> `10.5.30.53`
|
|
- `Old IoT` -> `10.5.30.53`
|
|
|
|
Why:
|
|
- puts those devices behind John's DNS blacklist policy
|
|
- removes default dependency on each lane's gateway IP for DNS
|
|
- makes later `Untrusted -> Gateway` tightening much safer
|
|
- centralizes DNS behavior instead of hiding it in per-subnet gateway defaults
|
|
|
|
### NTP
|
|
Do not force restricted lanes onto a new local NTP dependency yet.
|
|
|
|
Recommended day-one posture:
|
|
- keep NTP non-gateway-dependent if UniFi's policy model can express it cleanly as outbound/public time sync
|
|
- if that cannot be expressed cleanly in the first pass, explicitly preserve only the exact gateway NTP behavior still needed until a later cleanup window
|
|
|
|
Why:
|
|
- DNS filtering value is clear and immediate
|
|
- local NTP adds another service dependency without the same immediate user-visible benefit
|
|
- many embedded devices are tolerant as long as they can reach some valid time source
|
|
- this avoids pretending PD or another host is the canonical house NTP service before that has been deliberately verified
|
|
|
|
## Practical rollout shape
|
|
1. Update the UniFi network definitions for `IoT`, `Camera`, and `Old IoT` so DHCP hands out `10.5.30.53` explicitly.
|
|
2. Re-read `networkconf` to confirm the custom DNS setting stuck.
|
|
3. Only after that, stage the broader `Untrusted -> Gateway` shield.
|
|
4. In that broader shield, preserve only:
|
|
- DHCP
|
|
- mDNS if still intentionally needed
|
|
- NTP path as explicitly chosen
|
|
5. Do not guess Google/cast discovery carve-outs into the same wave.
|
|
|
|
## What this means for the firewall plan
|
|
After the DNS cutover, the broader management shield can stop assuming the gateway must remain reachable for restricted-lane DNS.
|
|
|
|
That makes the next firewall phase much cleaner:
|
|
- block general `Untrusted -> Gateway`
|
|
- preserve only narrow exceptions actually proven necessary
|
|
- keep admin surfaces blocked regardless
|
|
|
|
## Bottom line
|
|
Recommended design:
|
|
- DNS for `IoT` / `Camera` / `Old IoT`: `10.5.30.53`
|
|
- NTP for those lanes: leave as minimal non-gateway/public behavior for now rather than inventing a new local dependency
|
|
|
|
This is the safest next step that gives immediate value and reduces hidden gateway dependency before broader firewall tightening.
|