3.4 KiB
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: 6Camera: 3Old 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=truedhcpd_dns_enabled=falsedhcpd_ntp_enabled=falsedhcpd_gateway_enabled=falsemdns_enabled=truenetwork_isolation_enabled=true
Camera
- subnet:
10.5.20.1/24 - VLAN:
520 - DHCP range:
10.5.20.6-10.5.20.254 dhcpd_enabled=truedhcpd_dns_enabled=falsedhcpd_ntp_enabled=falsedhcpd_gateway_enabled=falsemdns_enabled=truenetwork_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=truedhcpd_dns_enabled=falsedhcpd_ntp_enabled=falsedhcpd_gateway_enabled=falsemdns_enabled=truenetwork_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:
IoTclients likely still use10.5.10.1for default DNS deliveryCameraclients likely still use10.5.20.1for default DNS deliveryOld IoTclients likely still use192.168.1.1for 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:
- restricted-lane clients are intentionally moved to explicit non-gateway DNS/NTP targets, or
- the broader gateway policy explicitly preserves the exact gateway services those lanes still need, or
- 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:
- decide whether
10.5.30.53should be the DHCP-advertised DNS target forIoT,Camera, andOld IoT - decide whether NTP should stay public, stay gateway-provided, or move to a local service
- if DNS/NTP stay gateway-dependent, model the exact gateway exceptions first
- only then convert the current surgical admin-surface block into a broader
Untrusted -> Gatewayshield
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.