Greetings!
I’m implementing a DNS-based routing in ROSv7 (current version is 7.19.2, device is RB5009 if that matters). First of all, here’s an example of what I have now:
/ip dns forwarders
add dns-servers=192.168.100.201 name=Adguard
/ip dns static
add address-list=video forward-to=Adguard match-subdomain=yes name=youtube.com type=FWD
add address-list=video forward-to=Adguard match-subdomain=yes name=ytimg.com type=FWD
add address-list=video forward-to=Adguard match-subdomain=yes name=googlevideo.com type=FWD
/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-list=video new-connection-mark=MarkVideo
add action=mark-routing chain=prerouting connection-mark=MarkVideo dst-address-type=!local new-routing-mark=ISP1 passthrough=no
The idea is to use MikroTik as primary DNS in network, let it forward requests to upstream DNS and add them to address-list, then mark connections based on the list. Most of the time, this works fine, but sometimes rarely it breaks like this:
- Open browser and type youtube.com, feel like connection goes wrong ISP
- Open WinBox, open Address list, here I see that resolving happened through MikroTik and records are added to video list
- Open connection tracking in Firewall → Connections. Find corresponding connections by dst-address, find out that they are not marked.
- Restart browser, let connection initiate again, while address is already in list - now all perfect again.
My thoughts on the problem is that internal action of adding addresses to list happens too slow or maybe done synchronously after sending DNS response to client, so client already receives its DNS response and manages to establish connection, and only then address is added to list, when it is already a bit late. Anyone have the same problem and what can be the resolution?
I have a very similar config and exactly same symptoms, as you described, but don’t know, how to solve this. It looks like RouterOS issue.
I’m created ticket SUP-193774
My config DNS FWD:
/ip dns static add address-list=za_vpn_FWD forward-to=fwd_doh match-subdomain=yes name=cdninstagram.com type=FWD
/ip dns static add address-list=za_vpn_FWD forward-to=fwd_doh match-subdomain=yes name=instagram.com type=FWD
The resolved list of addresses is wrapped in a tunnel by Mangle. In the case when different DNS names receive the same IP addresses, after the shortest TTL expires, the address is removed from the list and despite the fact that other records with the same address live in the DNS cache, sending these addresses to the tunnel breaks, because it is no longer in the list.
This is a side case, as the problem is also reproducible with clean cache, so I believe there’re two bugs probably. Would be nice if someone from MikroTik could give a summary about the feature state and if they can/want reproduce the problem. FWD+mangle is huge QoL
I just got the idea. Some devices are trying to bypass local DNS server. For example, my TV is actively trying to bypass local DNS, provided by DHCP and attempts to use 8.8.8.8 instead. In such case, FWD rule won’t work. I’ve blocked all DNS requests except local in the router, but can’t check, if it solves the problem (I’m far from that location).
This is not related to my case, since I use these rules to make sure all DNS requests (except DNS-over-something - not possible to catch) are served by router:
/ip dns
set address-list-extra-time=1h allow-remote-requests=yes servers=192.168.100.201
/ip dns forwarders
add dns-servers=192.168.100.201 name=Adguard
/ip firewall nat
add action=redirect chain=dstnat dst-address-type=!local dst-port=53 protocol=udp src-address=!192.168.100.201
add action=redirect chain=dstnat dst-address-type=!local dst-port=53 protocol=tcp src-address=!192.168.100.201
/ipv6 firewall nat
add action=redirect chain=dstnat dst-address-type=!local dst-port=53 protocol=udp
add action=redirect chain=dstnat dst-address-type=!local dst-port=53 protocol=tcp
Somehow address-list-extra-time smoothed things a bit, not sure if this is related.
