You switched the adlist on in the DNS section and most of your network got quieter for it. Except that on one site the checkout no longer loads, or a map stays grey, or the login button does nothing. The page itself is there, a piece of it is missing.
This chapter is about one site breaking because of filtering. If nothing resolves at all, that is not a filter problem but DNS itself: see Names are not resolved.
The quick checks, in order
- Is the list working at all?
/ip dns adlist print. A good answer is one line with the URL and aname-countin the hundreds of thousands. A zero there means the list was never fetched, and this is not your cause. - Which name is blocked? Open your browser's developer console, the Network tab, and reload the page. The requests that fail name their host. That is the only way to know; guessing does not work here.
- Confirm it through the router. From a client:
nslookup that.name 192.168.88.1. A good answer for a working name is a real address. Getting0.0.0.0back means the name is on the list. - Switch the list off for a moment.
/ip dns adlist disable [find]followed by/ip dns cache flush. If the site works after that, you know for certain./ip dns adlist enable [find]puts it back. - Look at your own records.
/ip dns static print. An old or wrong manual entry gives the same picture. - Is the client resolving through the router at all? A browser with DNS over HTTPS goes around your router. Then the same site works on the laptop and not on the phone, which is confusing but not broken.
The usual causes, most common first
The site needs a domain that is on the list
Many sites load scripts, images or payment modules from domains that appear on ad and tracking lists. Consent banners, tag managers and payment fraud detection are the best known cases: the page waits for a script that never arrives and therefore stops halfway.
The cache on both sides
The router remembered the answer and so did your browser. After a change you have to clear both: /ip dns cache flush, plus a hard reload or a private window in the browser.
An app rather than a site
The same list also catches telemetry domains that some apps need in order to start. You do not notice that as a block, you notice it as an app that keeps loading.
The list could not be fetched
Without a working internet connection, or with a clock that is far off, the download fails. The filter is then in place but filters nothing, which does no harm in itself.
What the configurator does about it
The DNS section has one toggle: Adlist, off by default. Switching it on produces exactly one line: /ip dns adlist add url=https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts ssl-verify=no.
That is the whole feature. It is the StevenBlack hosts list and nothing else: there is no field for a different list, no second list, and no allow list. If you want one domain through anyway, that is yours to arrange. On RouterOS older than 7.15 /ip dns adlist does not exist yet; the tool then leaves the line out and says so.
What the tool does have is static DNS records, in the same section: a name and an address, type A, AAAA, CNAME or regexp. RouterOS answers a name it has its own record for from that record, so a static record with the site's real address is the way out available to you. It is maintenance, though: when that service changes address, your record breaks it again. For one stubborn case it is fine, for three or more you are better off switching the list off.
The Force LAN clients through the router toggle redirects port 53 to the router, so devices with a hard-coded 8.8.8.8 cannot go around it. The help text is honest that browser DNS over HTTPS is not stopped by it.
Not checked: what is on the list, whether the list can be downloaded, which domains your sites need, and whether a block breaks anything. The tool tests nothing after you paste. There is also no exception per client or per network: the filter applies to everyone using the router as DNS.
If you do want real allow lists, different profiles per network and a view of what is being blocked, a proper filter in a container is the way: see Recipe: AdGuard Home.
When it is not your router
If you use a filtering upstream such as Quad9, that filters too, and you have no exceptions there. As a test, point the upstream at a non-filtering resolver for a moment. Browsers with their own DoH, VPN clients on the laptop and the security software on the device itself all filter as well, and none of that shows up in RouterOS.
Read on: DNS, How DNS works and Names are not resolved.