# UniFi DHCP/DNS Verification — 2026-05-23

Purpose: determine whether the restricted lanes (`IoT`, `Camera`, `Old IoT`) are safe for a broader `Untrusted -> Gateway` management shield, specifically by checking what DHCP/DNS behavior they actually appear to rely on.

## Live verification performed
Fresh read-only UniFi poll executed from PD against the live controller.

Verified live from UniFi:
- site: `default`
- controller path: `rest/networkconf`
- supporting reads: `stat/sta`, `v2/api/site/default/firewall-policies`
- current custom policy still present: `Block Untrusted to Gateway Admin Surfaces`

Observed restricted-lane client counts during the same read:
- `IoT`: 6
- `Camera`: 3
- `Old IoT`: 11

## Restricted-lane DHCP/DNS findings from the live controller

### IoT
- subnet: `10.5.10.1/24`
- VLAN: `510`
- DHCP range: `10.5.10.6` - `10.5.10.254`
- `dhcpd_enabled=true`
- `dhcpd_dns_enabled=false`
- `dhcpd_ntp_enabled=false`
- `dhcpd_gateway_enabled=false`
- `mdns_enabled=true`
- `network_isolation_enabled=true`

### Camera
- subnet: `10.5.20.1/24`
- VLAN: `520`
- DHCP range: `10.5.20.6` - `10.5.20.254`
- `dhcpd_enabled=true`
- `dhcpd_dns_enabled=false`
- `dhcpd_ntp_enabled=false`
- `dhcpd_gateway_enabled=false`
- `mdns_enabled=true`
- `network_isolation_enabled=false`

### Old IoT
- subnet: `192.168.1.1/24`
- VLAN: `2`
- DHCP range: `192.168.1.100` - `192.168.1.199`
- `dhcpd_enabled=true`
- `dhcpd_dns_enabled=false`
- `dhcpd_ntp_enabled=false`
- `dhcpd_gateway_enabled=false`
- `mdns_enabled=true`
- `network_isolation_enabled=false`

## Interpretation
The common pattern across all three restricted lanes is unchanged:
- DHCP is on
- custom DHCP DNS is off
- custom DHCP NTP is off
- no explicit per-network DNS servers are configured for those three lanes

Operationally, that means these lanes still look gateway-dependent for their default DHCP-delivered DNS behavior.

Safe working assumption from the live config:
- `IoT` clients likely still use `10.5.10.1` for default DNS delivery
- `Camera` clients likely still use `10.5.20.1` for default DNS delivery
- `Old IoT` clients likely still use `192.168.1.1` for default DNS delivery
- NTP is likewise not explicitly overridden per network

## Decision
Do not apply a broad `Untrusted -> Gateway` deny yet.

The currently deployed surgical rule remains the right safe stopping point:
- `Block Untrusted to Gateway Admin Surfaces`

A broader management shield is still unsafe until one of these becomes true and is verified:
1. restricted-lane clients are intentionally moved to explicit non-gateway DNS/NTP targets, or
2. the broader gateway policy explicitly preserves the exact gateway services those lanes still need, or
3. a later live validation proves those clients no longer depend on gateway DNS/NTP despite the current network definitions

## Practical next step before any broader gateway block
Preferred next live order:
1. decide whether `10.5.30.53` should be the DHCP-advertised DNS target for `IoT`, `Camera`, and `Old IoT`
2. decide whether NTP should stay public, stay gateway-provided, or move to a local service
3. if DNS/NTP stay gateway-dependent, model the exact gateway exceptions first
4. only then convert the current surgical admin-surface block into a broader `Untrusted -> Gateway` shield

## Bottom line
Fresh live UniFi reads confirm the restricted lanes still look gateway-dependent for default DHCP-delivered DNS behavior.

So the answer to "can we safely broaden the gateway shield right now?" is: not yet.