The interesting fact is, although ROIS is responding DNS queries normaly, that rule gets no hits whatsoever. If I remove the “connection-mark=no-mark” it does, but then again, I moved that rule to the very top of the mangle list, so no other rule is marking it, and so it should get hitted by all DNS query requests. If I am wrong, I’m not able to see where.
I can simple use, instead of “connection-mark=no-mark”, “connection-state=new”, this way I can mark DNS queries to do with them what I want.
Does anyone know why those input on udp port 53 won’t hit a mangle rule with “connection-mark=no-mark”?
Maybe your connection is already marked by another rule in the Prerouting chain, which comes before Input according to the Packet Flow.
I’m not sure you can redirect a packet once it reaches Input, and is already going into the router, or can you? The typical place where you’d make the redirect is dstnat - it’s exactly how you can redirect, say, web port 80 requests to not go into the router’s WebUI, and instead go to a web server. I’ve done this a few times to DNS and it works. You would have to use NAT anyway to ensure that the response from the DNS server gets back to the client from the expected address. I suppose you could put a connection mark on the traffic beforehand in Prerouting, but I can’t think of an example why you would.
Yes, I had another rule in the prerouting chain already marking dns connections. I thought that DNS queries destined to RouterOS address wouldn’t go to prerouting chain, I thought that they would role in input chain only, so I thought I needed 2 rules, one in prerouting for DNS queries on external DNS servers, and another on input for queries directly to RouterOS. Turns out that I need only one in prerouting.
It is still not working completly fine, since my scenario is a bit crazy… I have configured an unbound server (on debian), and it access internet throught the RB, and the RB also reachs throught another interface on an different IP subnet to make DNS queries.
I have already configured a NAT rule, with dst-nat to the IP of unbound server, and the unbound server can already do dns queries throught the other interface facing internet (on the same rb). I configured static routes on unbound server do reach clients back, but for some reason, if I disable “allow-remote-requests”, internet access scrumbles out, even tho unbound can still resolve names, and ROS is redirecting DNS queries to it throught dst-nat.
If I understand correctly, you want to use Unbound DNS server on another machine instead of the caching server built into RouterOS. Maybe you can give out the address of the Unbound box directly to the clients, and not do any redirection? If not:
The src-address or in-interface of the Unbound box should obviously be excluded from the dst-nat rule, so it’s not being redirected upon itself. For dst-nat to work, the response from Unbound must return via the RB as gateway. (remark about srcnat removed, because it was wrong)
Maybe the Unbound is using the RB as its DNS server? Something must be doing it if allow-remote-requests on the RB has an effect.
You can use Tools > Packet Sniffer in Winbox to follow a DNS lookup.
I’ve reviewing the rules and refining them. I’ve already checked not to create a loop and redirect Unbound requests back to itself, I did it by IP address, like “src-address=!10.2.2.3” (10.2.2.3 is the address of unbound server).
Now it is working, and I think I know why it wasn’t…
I also have a squid, which receives port 80 only, and the squid was configured to use RB address (10.2.2.2) as DNS. So, when I typed like “www.google.com.br”, my own computer would try to resolve the host name, it does and then (since I dndn’t type https:// in front of address) tries to connect to it via port 80, that then is redirected to Squid, that takes the URL from the HTTP request and connects again. Now, Squid machine tries to resolve again “www.google.com.br” querying to 10.2.2.2 dns server, it then would redirect to 10.2.2.3, where it then have a route back to 10.2.2.2 directly, not needing to use RB as router, and I think that it is here where everything gets lost, because it tryes to respond DNS query from 10.2.2.1 (squid) directly after having been received it from 10.2.2.2 (RB), and 10.2.2.1 wasn’t especting any traffic from 10.2.2.3, but from 10.2.2.2.
Very crazy scenario. But now I changed Squid DNS to 10.2.2.3 (unbound server), and it is working for now apparently.