SkieWhat happens when a network blocks the encrypted DNS port?
The device uses that network's own DNS while it is connected and the Skie dashboard flags it, so you know the filter is not in the path on that Wi-Fi. Back on any other network, the filtering DNS applies again. Nothing breaks for the student, and browsing keeps working.
Encrypted DNS uses a specific port that some firewalls block. A hotel, a library or an older school network may do this without anyone remembering why. If the port is blocked, the device cannot reach the filter from there.
Skie's approach is to keep the device usable. Rather than leave the student with no browsing, the device falls back to the network's DNS for that connection, and the dashboard records that the filter is not reaching the device on that network. The flag tells an admin what to follow up with the network owner.
That fallback is a trade-off the admin should understand. On such a network the protection depends on what the network itself filters. Many schools already have filtering at their gateway, so in practice that is often acceptable, but you should know it is happening, which is the reason for the flag.
To close the gap, ask the network administrator to permit outbound encrypted DNS to the filter provider. The network check wizard gives you something concrete to share with them. Re-run it afterwards to confirm.
The same applies to individual families' routers, but those rarely block the port, and mobile data networks generally allow it. When a device is taken home and works through a different path, the filtering returns by itself, with no action by the student or the admin.