When Meridian Electric Cooperative's DNS filter profile blocks a category, browser-based traffic to a blocked domain typically shows the technician a FortiGuard block/landing page, while a non-browser OT client attempting to reach that same blocked domain simply fails to connect with no page shown. What explains this difference?

When a DNS filter profile blocks a category, FortiGate commonly resolves the query to a redirect address associated with its own block portal rather than simply refusing to answer. A web browser receiving that address makes an HTTP request to it as it would to any site, and FortiGate's portal renders the familiar block/landing page in response, which is why browser-based attempts produce a visible notice. A non-browser OT client resolving the same blocked domain gets the identical redirect address, but since it isn't making an HTTP request expecting a rendered page, it simply attempts whatever connection its own protocol expects, fails against that redirect address, and shows the user nothing, even though the underlying block mechanism is exactly the same. The idea that DNS filtering only affects browser traffic is backwards — DNS filtering intercepts the name resolution stage for any client, and the browser-versus-non-browser difference shows up afterward, in how each type of client reacts to the resulting address. Application control isn't involved in this particular block at all, since the scenario describes a DNS-level block, not an app-control action. Browser traffic doesn't bypass DNS filtering either — it goes through the same resolution step as any other client before reaching the redirect address. Confirm this mechanism by checking the DNS query log for the blocked domain and noting that both clients received the same resolved address despite the different visible outcomes.