VOIP phones, smart TVs, printers, and IoT devices have no OS you can log into — you cannot run nslookup, dig, or ipconfig directly on them. When one of these devices is being blocked while everything else on the network works fine, you need to approach the diagnosis from the network level outward. This guide walks through that process step by step.
This is always the right starting point. The activity log tells you two critical things at once: whether CleanBrowsing is seeing the device's DNS queries at all, and whether any of those queries are being blocked. The answer determines everything else.
If the activity log shows no queries from the device, it is resolving DNS through a different server — not CleanBrowsing. Since you cannot check the device's network settings directly, the next place to look is your DHCP server or router.
Log in to your router or DHCP server and find the lease entry for the device's MAC address. Check what DNS servers are being assigned to it. If the device was added to the network later than others, it may have been placed on a different VLAN, subnet, or DHCP scope that does not have CleanBrowsing configured as the DNS resolver.
Compare the DHCP configuration for the working devices against the problem device. The DNS server pushed by DHCP should be identical. If it is not, update the scope or VLAN configuration so that CleanBrowsing is assigned to that device.
Common reasons a device gets different DNS via DHCP:
Most embedded devices — IP phones, smart TVs, printers, access points — have a browser-accessible admin interface. This lets you view (and sometimes change) the device's network configuration, including DNS, without needing physical access or a terminal.
http://<device-ip>.CleanBrowsing's DNS resolver IPs are 185.228.168.x and 185.228.169.x. If the device shows different IPs, that is the root cause — the fix is at the DHCP or device provisioning level.
Note: some devices do not have a web interface, or may have DNS hardcoded via a provisioning server rather than DHCP. In that case, the fix needs to happen at the provisioning system level, not on the device itself.
If the steps above have not identified the issue, a packet capture is the next tool. You run it from a computer on the same network segment as the device, filtering traffic by the device's IP address. This shows you every DNS query the device makes and every response it receives — without touching the device at all.
Replace <device-ip> with the actual IP address of the problem device:
To save the output to a file for later review:
Open Command Prompt as Administrator:
If you have Wireshark available, run a capture and use this display filter to isolate the device's DNS traffic:
VOIP phones use SIP (Session Initiation Protocol) to register with their cloud server and set up calls. SIP runs on port 5060. If a VOIP phone is connecting but calls are failing, or the phone cannot register, there is an additional layer to capture beyond DNS.
On Mac / Linux, include port 5060 alongside DNS:
In Wireshark, add SIP to the display filter:
If you are unsure how to interpret the capture output, share it with your support team along with the phone's IP address and the exact time the failure occurred.
that creates safe browsing experiences on your network.
What is DNS Filtering?
