What domain filtering sees
A group of users must be restricted from a domain, but blocking its IP may interrupt other services. With DNS policy, the resolver that translates names into IP addresses restricts its answer for that domain. The tls-host method uses SNI, the server name a client normally sends at the start of TLS to select a site. The router does not read encrypted HTTPS content. A content delivery network (CDN) can host multiple sites on one IP, and ECH can hide that initial server name. This guide tests the effects and limits of each method separately.
Resolver and RouterOS requirements
Use RouterOS v7 and verify type=NXDOMAIN and match-subdomain on the selected patch. Do not assume identical syntax across all v7 releases.
Identify LAN/WAN membership and client IPv6 paths. Record CPU, connection tracking and FastTrack rules before the change.
Keep an off-router export and console access. Use router recursion only with permitted LAN DNS and blocked WAN DNS access.
Wildcards in DNS and address lists
An address-list value of *.example.com is not a general DNS wildcard. DNS match-subdomain and tls-host glob syntax have distinct behavior. Historical content rules are not modern HTTPS enforcement.
DNS policy and SNI filtering differ
DNS policy returns NXDOMAIN so the client receives no address from that resolver. The tls-host method instead examines a visible ClientHello on TCP. QUIC uses UDP, ECH hides names and a VPN changes the path; strict enforcement therefore also needs endpoint management and a secure web gateway design.
Example: a managed-client policy
Users query an internal resolver and example.com is the test domain. Test DNS and TCP independently. Endpoint management controls DoH and VPN use. Router rules alone do not guarantee organization-wide enforcement.
Avoid open recursion and CDN collateral damage
Do not expose router DNS recursion to WAN. Scope resolver enforcement to user subnets with explicit exceptions. A CDN IP might host unrelated services, so avoid blocking it from one DNS answer. Generic Layer7 matching does not reliably inspect encrypted HTTPS content.
Configure the domain and test DNS/TLS separately
Record DNS/firewall state and verify LAN/WAN membership. Permit router TCP/UDP 53 from LAN only and prevent WAN recursion.
/ip dns print
/ip firewall filter print detail
/ip dns static add name=example.com match-subdomain=yes type=NXDOMAIN comment="ENT-WEB DNS policy"
/ip firewall filter add chain=forward in-interface-list=LAN out-interface-list=WAN protocol=tcp dst-port=443 tls-host=example.com action=drop comment="ENT-WEB root SNI"
/ip firewall filter add chain=forward in-interface-list=LAN out-interface-list=WAN protocol=tcp dst-port=443 tls-host=*.example.com action=drop comment="ENT-WEB subdomain SNI"Use an existing restricted resolver. Do not enable allow-remote-requests before firewall controls. Put SNI rules before relevant FastTrack/established accepts and test fresh connections.
/ip firewall filter print stats where comment~"ENT-WEB"
/ip dns static print detail where comment~"ENT-WEB"Test DNS and TCP TLS separately from a managed client.
dig @10.20.30.1 example.com
curl --http1.1 --connect-timeout 5 https://example.comEstablish two independent results. For DNS, replace 10.20.30.1 with the actual resolver and verify NXDOMAIN. For SNI, obtain the current destination IP through an approved alternative DNS path and make a fresh TLS connection using the real hostname. DNS failure alone does not show that the TLS rule matched.
Measure user impact
Compare rule counters with actual client outcomes. Record UDP/443 volume, user reports and false positives. Test application fallback before blocking QUIC.
When the site still opens
If the site still opens, establish which domain and subdomains the client requests and what its DNS cache contains. Then investigate DoH, QUIC, ECH, proxies and IPv6 separately. A ClientHello split across TCP segments may also evade matching. An SNI test needs approved resolution and a fresh connection to be meaningful.
Prove DNS and SNI policy independently
A failed DNS query prevents any later TLS test, so it cannot prove SNI filtering. In an isolated managed client, first test example.com and a subdomain against the policy resolver and record NXDOMAIN. For a separate authorized SNI test, obtain a current server address through an approved alternate resolution path and use curl --resolve with the real hostname, forcing HTTP/1.1. Do not substitute the IP in the URL because that changes SNI and certificate-name validation. Compare a permitted control hostname; only the intended policy should fail. Recheck fresh connections, rule counters and IPv6 before acceptance.
# Replace documentation hostname/address with the authorized lab endpoint.
curl --http1.1 --connect-timeout 3 --max-time 10 --resolve example.com:443:203.0.113.20 https://example.com/The documentation IP is not an Internet service. A timeout alone is inconclusive: inspect whether the intended SNI drop counter increments while the permitted control completes with valid TLS. ECH, QUIC, segmented ClientHello and VPNs remain limitations. Do not claim this policy blocks all HTTPS access to a brand or CDN.
Undo policy and handle caches
Disable ENT-WEB rules and DNS entries to undo this policy, leaving unrelated firewall configuration intact.
/ip firewall filter disable [find where comment~"ENT-WEB"]
/ip dns static disable [find where comment~"ENT-WEB"]Then clear relevant client/resolver caches through their supported methods and retest the application. Cached answers affect immediate test results.
Policy owners and exceptions
The deliverable is an explicit list of domains, subdomains, user groups and exceptions whose effects have been checked on clients. If organizational policy must hold across all paths, evaluate router filtering alongside endpoint management and a web gateway; observing one drop does not establish that level of enforcement.
Best Practices
- Version-control configuration and review changes.
- Use least privilege and explicit allow-lists.
- Automate repeatable checks and monitor the expected state.
- Test upgrades and restores before production rollout.
Conclusion
A reliable implementation of Block Domains on MikroTik: DNS and SNI Limits is more than a successful first run. Keep the configuration documented, observable, recoverable, and aligned with the team's change-management process.
Frequently Asked Questions
Does tls-host block all HTTPS?
No. ECH, QUIC, fragmentation and VPNs limit its visibility.
Does one destination IP identify one website?
No. A CDN can share an IP across multiple services.
