Why does Skie turn off Chrome's own secure DNS?
Skie turns off Chrome's built-in secure DNS so the browser uses the device's filtered system DNS instead of a provider the student could pick. Without this, Chrome could look up sites through its own resolver and skip the school filter. The rule is on by default for managed Chrome.
Chrome can send its DNS lookups to its own chosen resolver over HTTPS. That is a sensible privacy feature for a home user, but on a school device it would let a browser sidestep the filter that the organisation set at the system level.
Skie's device owner policy switches Chrome's secure DNS off, so Chrome asks the Android system for lookups. The system DNS on a managed device is the filtering DNS the organisation chose, and the Private DNS setting in Android is blocked so the student cannot change it. The result is one place where filtering happens, and every app and the browser goes through it.
This is not the same as the connection being unencrypted. The filtered system DNS itself uses encrypted DNS to reach the filter. What is removed is the browser's ability to pick a different resolver.
Where this matters most is in explaining to a technical teacher why the setting looks counterintuitive in a security review. The answer is that the control point has moved from the browser to the device owner, which is the layer the student cannot reach.
If a school network blocks the encrypted DNS port, the device falls back to the network's DNS and the dashboard flags it. The network check wizard helps you find that out before rollout.