# 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.