I know you’re asking how to do this with a Mikrotik router, and I’m about to give you a combination Mikrotik/non-Mikrotik solution. So please forgive me. It is not possible to get all the IP addresses of “youtube.com” and just block them. The layer 7 stuff in the router that you’re doing works a little, but it is not robust enough. A layer 7 list in the router is hard to manage and it gets messy quickly the more things you decide you want to block. It’s really easy to bypass the layer 7 list in the router using DoH (see step 5 at the end), so you have to do more.
Step 1: Create a local resolver
Get some kind of DNS resolver in your network that is not the router. This is a big step and it’s kinda beyond the scope of what I’m writing here. I am a big fan of the pi-hole because I like blocking ads. It also gives you a nice GUI interface for managing DNS block lists and it gives you a database of what domains your network users are visiting. I’ll pretend you have installed one and it has IP address 10.0.0.5.
NOTE: The only way to do this reasonably is to create a server of some kind (a VM, a Raspberry Pi, etc.), running software on it, and keeping it alive. It becomes your DNS server for your network, so it is critical infrastructure. If it goes down, end users will say “the internet doesn’t work” because DNS can’t resolve anything. If you can’t or won’t run a separate DNS resolver for your network, DNS-based blocking (i.e., blocking based on the “domain name”) is not something you’ll be able to do (step 5 below explains why).
Step 2: Get your local resolver blocking things
Block domains on your DNS filter. E.g., block youtube.com, googlevideo.com, etc. If you don’t want to block ads at the pi-hole, you can turn off the ad blocking features and lists. You just block things named on your manually-curated block list. Ad blocking is pretty pervasive and it can sometimes interfere with normal users’ stuff. Half the links they click in Google search are ads. So if they’re used to searching the internet by using the world’s largest internet advertiser, and then clicking one of the top 5 links, which are all advertisements, they’ll discover that these top 5 links don’t usually work. It depends on your user population and what’s behind this router whether ad blocking will be good, bad, or indifferent.
Now, here’s where you can test and try things out without disrupting anyone on your network. On a test system you control, like a laptop, manually configure the DNS and tell it to use 10.0.0.5 (or whatever the IP address of your DNS resolver is). Your test system should browse the internet just fine. If you’ve enabled ad blocking, that one system should see fewer ads. If you’ve only blocked a few domains, then try visiting those domains and see that they’re blocked. Assuming this one test system is behaving as expected (youtube blocked, everything else working fine), keep going.
In Step 3, you switch all the devices on your network so that they will use the new blocking resolver.
Step 3: Get everyone on the network using the local resolver
Step 3 Variation A: Make sure all your DHCP leases give out your DNS resolver (I’m pretending that’s 10.0.0.5) as the DNS server. Assuming your Mikrotik router is your DHCP server, set the DNS server using the right options to
/ip dhcp-server network
. See DHCP documentation). If you do this, the change will take effect gradually, as each device’s DHCP lease runs out.
Step 3 Variation B: Instead of (not in addition to) the above, you can give out the router’s IP address as the DNS resolver. (This is normal and probably what you do now). Configure the router itself to resolve DNS by going to the pi-hole on 10.0.0.5. E.g.,
/ip dns set servers=10.0.0.5
. You’ll do this instead of having your router resolve DNS via the Internet (upstream ISP). If you do this version, the change is essentially instant and affects everyone. So please test before doing this.
Both variations of of Step 3 are reversible. If you mess up, just put it back how it was before.
At this point, lots of devices will find YouTube blocked, but not all. And it’s trivial to bypass. In the same way you tested after step 2, someone else can follow those same steps and opt-out of ad blocking/youtube blocking. If they go to their device, change IP their DNS to point to 9.9.9.9 or 1.1.1.1, they will get unfiltered DNS and they’ll get YouTube or other blocked domains.
If you really want to make it hard to avoid your filters, the next two steps are where you go back to the Mikrotik and really commit.
Step 4: block any DNS that is not the local resolver
Step 4 A: Impose IP firewall filters that block UDP to port 53 and TCP to port 53 to an IP address except 10.0.0.5 (or whatever DNS server you run). Note that whatever system you choose (e.g. the pi-hole or some other solution) must be exempted from this rule.
In my network I have:
/ip firewall address-list
add address=9.9.9.9 list=allowedDNS
add address=172.30.2.5 list=allowedDNS
add address=172.30.2.1 list=allowedDNS
Then I have firewall rules:
/ip firewall filter
add action=accept chain=forward dst-address-list=allowedDNS dst-port=53 \
in-interface-list=LAN protocol=udp
add action=accept chain=output comment="Accept TCP 53 to allowable DNS" \
dst-address-list=allowedDNS dst-port=53 protocol=tcp
add action=accept chain=output comment="Block UDP/53 except allowedDNS" \
dst-address-list=allowedDNS dst-port=53 protocol=udp
add action=drop chain=output dst-address-list=!allowedDNS dst-port=53 protocol=tcp
Step 4 B: If the source IP is your DNS resolver (e.g., the pi-hole at 10.0.0.5), it must be allowed to connect to any IP address on port 53 either UDP or TCP. The idea here is that the only way to do DNS on your network is to talk to YOUR DNS server. No others will be reachable.
Caution: If you think users on your network may have manually configured DNS somehow, their device will break when you do this. if they have have manually configured DNS (e.g., to use the world’s largest internet advertiser 8.8.8.8 or 8.8.4.4), they will find that the internet suddenly doesn’t work. Their system will stop resolving DNS names. Until someone manually fixes the device (making it use your local DNS or use DHCP), the device will be unable to use the internet.
Step 5: Try to block some DNS over HTTPS
We’re not done. There’s a new way of doing DNS, however, called DNS over HTTP (DoH). Frankly, this is pretty hard to block. The clients will make outbound HTTPS connections on port 443 to some well-known services that provide DNS. Chrome does this by default. This means that when the browser tries to look up “www.youtube.com” it will make an HTTPS connection to a well known cloudflare server (or other server) and it will get the DNS answer. You’ll need to block some new domains, just to block DNS over HTTPS. Go back to your pi-hole or whatever DNS resolver you’re using for blocking and block at least these 3 domains.
At this point, you’ve done a lot. Only the craftiest people will be able to get around this. It’s not bulletproof. I’m sure there are public DoH servers out there other than CloudFlare and Google. If one of your users figures out how to configure their browser to use that DoH resolver, they’ll be able to watch YouTube. There are probably some other bypasses possible. But this raises the bar a lot. It will block a lot of YouTube for ordinary users.
Conclusion
This will block a lot of stuff. it’s not perfect. There is no perfect solution. It really depends on who your users are, how hard they will try, and how bad it is if they succeed as to how much work you want to put into making it harder and harder.
It all depends on the video source and whether you’re using the HTML5 video player which supports several streaming protocols such as HLS, RTMP/RTMPS, and DASH. For example, MPEG-DASH (high-res) and HLS use TCP, whereas UDP is used for HTTP/3 QUIC streams and RTMP which is the most commonly used protocol on YouTube.
