truenas-stacks/home/doris-dashboard/docs/unifi-restricted-lane-dns-ntp-recommendation-2026-05-23.md

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.