URL filtering is based on matching the specified string to what the router finds in the DNS query to that same domain name. If it matches, it just DROPs the DNS request and the client receives no response.
That's all well and good AS LONG AS your DNS queries are being handled over port 53, and NOT, for example, being handled internally by the browser to something other than port 53, perhaps some DoT/DoH DNS server! Or perhaps if the client is running an OpenVPN client, thus hiding all activity from the router, including DNS.
That's why a lot of this stuff isn't as reliable as you might assume, esp. these days w/ browsers now defaulting to their own internal DNS configurations (which can usually be disabled), and the proliferation of client-side VPNs. A clever person can also get around the problem by just using an explicit IP, or just by configuring their own local hosts file w/ those domains.
It's a tough world out there these days for those trying to restrict access. More and more, everything is working against you.
P.S. I just noticed it's trying to do L7 matching as well, which means it's searching the TCP packet's payload for a match on the domain name. Problem is, most traffic is https these days, NOT http, making L7 matching ineffective since the payload is encrypted! I told you it's tough out there.
Just so you can see for yourself, here's a dump of the FORWARD chain on the filter table.
Code:
0 0 DROP udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 STRING match "|06726f626c6f7803636f6d|" ALGO name bm TO 65535 ICASE
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 WEBSTR match url roblox.com reject-with tcp-reset
URL filtering may be headed the way of the dodo bird the way things are going.
