merry xmas everyone
i m trying to make a tutorial about mikrotik and i would like to know what does Allow Remote Requests mean?
i know i need it check up to have internet. Please can you answer with one or two examples of how it work.
thank you
You mean the one in the “/ip dns” menu?
This is whether to let other devices use RouterOS as a DNS server. If this option is not checked, client devices must use another device set as their DNS server. Regardless of this option, requests originating from RouterOS itself (e.g. from a script via the “:resolve” command) will check up the DNS entries defined there, and use the defined servers if the router doesn’t know the answer.
You don’t need to have this option enabled to have internet. If you disable it, you can give your client devices a different DNS, such as Google’s 8.8.8.8 for example. That’s what the DNS setting in “/ip dhcp-server network” is for. Or if you don’t use DHCP, you can instruct clients to enter that other IP in their network settings.
A DNS server in general is not required to be in the same subnet. Only the default gateway must be.
thank you very much for the answer.
here it is picture i upload.
so in few words it means that option let the router solve dns?
what is the remote requests? does it mean it permit or allow requests from outside of the LAN network to the server or internet?
or when i got a host in my network requesting a data outside of my lan to internet ,mikrotik will let that data get into my network.
let’s say i do ping to yahoo, from my pc, then the data goes outside to yahoo server and when it want to come back, if that option is not set they packet wont be able to return if that option is not check.
These settings apply only when clients use router’s own address as DNS resolver.
If your clients use some external resolver, these settings will not influence them in any way.
If you do not check Allow Remote Requests, router will resolve names only for itself (e.g. when you have hostname in its VPN client, etc..). If you do check it, router will act as resolver for any other machine that asks for it.
Unfortunately there’s no option to allow just LAN clients (there’s a feature request, but who knows if it ever gets implemented). So when you enable Allow Remote Requests, you have to make sure that you allow incoming port 53 only for your clients and block the rest of the world using firewall. Otherwise you’ll create open resolver and it’s a bad thing.
When you ping yahoo.com from a client device, the client device first makes a connection to the DNS server defined in its own settings, asking it for the IP that “yahoo.com” corresponds to.
If your client device (e.g. 192.168.88.254) has 8.8.8.8 defined as their DNS server, it will contact the default gateway (e.g. 192.168.88.1), and ask it to forward a packet to 8.8.8.8, and send back the reply. The gateway connects to 8.8.8.8 via the internet, and eventually gives the client back the reply. The client only then asks the default gateway to make a connection to the IP that it just received via DNS.
That same procedure happens if the client device’s DNS server is set to 192.168.88.1, but if the “Allow remote requests” option is not checked, the DNS exchange with 192.168.88.1 will fail, and thus you wouldn’t be able to ping “yahoo.com”. If you already knew the IP that “yahoo.com” is on, you can still ping to that IP, since it doesn’t require a DNS lookup.
Ok sorry for bumping but basically i check “allow remote requests” and added public IP address of that mikrotik router as dns server for “outside” computer and he cant resolve the DNS…im using RouterOS v6.40.8 … I even made a firewall rule, chain - dstnat, protocol - udp, dst.port - 53, action - redirect, to ports - 53
…what im missing ? why i cant use my router as an extrenal dns and use static routes in it ?
You don’t do dstnat for connections to the router itself. Rather you add FW rule to chain=input allowing particular connection. Something like
/ip firewall filter
add action=accept chain=input comment="Accept DNS - UDP" port=53 protocol=udp
add action=accept chain=input comment="Accept DNS - TCP" port=53 protocol=tcp
perhaps adding src-address=xx.yy.ww.zz to allow connections only from select remote hosts (don’t forget to allow LAN hosts!).
Tried with those firewall rules (i tought if u dont set that rule it will accept automaticly !?).
The thing is that i put public IP directly into DNS TCP/IP configuration of external computer of my router and it still doesnt resolve anything…even tho i can see some 285 UDP accepted packets with ur first firewall rule…
Dont know what im doing wrong…i thought i only need to check that “Allow Remote Requests” and its done (ofc with public IP on WAN interface)
I’m reading some topics here and someone said that router should not be in DNS “client” mode but in DNS Server mode…how can i check that, when is he operating as a client and when as a server ?
The DNS process on the router always handles the requests of other processes on the router to translate an fqdn to IP address (e.g. when you write ping mikrotik.com on router’s command line, the DNS process translates mikrotik.com to an IP address). The process has two sources of information - local static DNS records you configure and external DNS servers. The addresses of the external servers can be configured manually and/or received via dynamic host configuration protocols such as DHCP or various alternatives embedded into ppp-type protocols. The process caches the responses from external servers.
allow-remote-requests=yes solely permits the DNS process to listen for incoming requests at UDP port 53 and process these requests. The DNS process itself doesn’t care about the source address of those requests. So whether a particular client will be served or not depends on firewall settings. A typical firewall ignores any packets coming from WAN side, except those it knows (thanks to connection-tracking) to be responses for packets previously sent out via the WAN interface. Order of rules in the firewall matters, so the rule action=accept chain=input protocol=udp dst-port=53 must be at the right place in the list to do what you expect it to do.
But opening a local DNS service for requests coming from anywhere in the internet is not a good idea as DNS is a UDP service so it is easy to make your device participate in a DDoS attack if it is configured to send a packet back to the source address of an incoming packet. So if I want to attack UDP port X on address x.x.x.x, it is enough to send to your UDP port 53 a DNS query packet with source address x.x.x.x and source port X; your device will send the DNS response to that address and port and my own address remains invisible to the target - from the target’s perspective, it is you who attacks him.
Sindy tnx for the answer, and i get that totally…awesome explanation of how dns works tho…but…
Im losing all the hope after all of these days…
So basically i set up everything, tried every solution possible (all kind of firewall rules, different routerOS, change every little thing in DNS conf) and it cant resolve anything that i put as a static address or even anything when i put public IP of my mikrotik DNS server… It can resolve from the inside tho, but from WAN interfaces nothing (i have two comupters, one with completely different ISP, and one on VPN, so i treat those as a clients that are accessing from WAN)…and nothing 
…
Are you sure your ISP is not filtering DNS requests targeted at their clients? Use torch tool and check if there are any packets targeting your public IP TCP/UDP port 53 coming to your WAN interface …
OK, I see that you mentioned filter counters going up. However, that doesn’t rule out IPS filtering. Recently we’ve seen on this forum a case where ISP was filtering replies rather than incoming packets. After user asked ISP about that, ISP ceased doing it (at least for that particular user).
Tnx for getting into conversation and trying to help mkx…
That was a nice idea and i did the torch, and looks like there are packets from ISP’s side that are hitting my Public IP (Wan), but only packets that i create from those remote computers (which is nice, i dont get any spam, attacks, etc.)…its looks like the DNS server cant replay anything for public side…so i have some feeling that i need to do something so server can, not resolve, but proceed the respond to the WAN interface (something on firewall maybe), because he gets the packets from WAN but he is not responding to request (but he is responding and resolving anything from LAN)…im gonna check with the ISP if they are blocking or not.
EDIT: just had a conversation with the technicians from ISP and they are not blocking anything on 53…
If the torch doesn’t show the responses, there is no need to talk to ISP - if ISP was blocking it, you would see the responses in torch but they wouldn’t get through the ISP network to the asking PC.
So follow the instructions in my automatic signature, it must be something in your firewall settings.
I thought they are blocking the replay’s from ISP’s clients just like mkx said, not requests
I saw on torch packets that are hitting on WAN but that does not confirm that ISP is not blocking the DNS replays from my side. Did i miss something, am i getting this right ?
If the ISP would be blocking the queries, you wouldn’t see them in torch. As you can see the queries, the ISP is not blocking them.
If you could see the responses in torch but the client wouldn’t get them, it would mean that the ISP is blocking the responses. However, as you cannot see the responses, you cannot tell whether the ISP is blocking them or not, but you can see that either the DNS process does not respond the queries (which I doubt), or your routing sends them via some other port than the WAN through which the requests came in, or your firewall blocks them.
The torch conditions should, in addition to the interface name, look like this:
src-address=0.0.0.0/0 dst-address=0.0.0.0/0 ip-protocol=udp port=53
Don’t get distracted by src and dst addresses being swapped, torch sometimes behaves funny. If you see packets in both directions (on one row 53 is src-port and on another row 53 is dst-port), then the ISP is filtering the responses. If you only see 53 as dst-port but never as src-port, something inside your 'Tik is wrong.
And one important point - if the client is using TCP to query the Mikrotik, everything is clear, Mikrotik’s DNS server doesn’t support TCP queries.
Yea i used the torch exactly like that and there is no src-adr thats my WAN ip and dst-adr thats remote DNS client…
This is the case…so i hope its something wrong that i can fix…what firewall rule should i apply ? And does the place of firewall rule matter ?
Yes, the order of the rules does matter, so without knowledge of the overall configuration, no one can suggest you what rule to add or which rule to remove or modify. So again, to get a useful advice, follow the instructions in my automatic signature.
I dont have any rules in firewall, so i just need basic command like chain=output protocol=udp port=53 action=accept …i tried a few rules but seems that non of those works…
No rules in firewall mean everything is permitted. This is a) a very bad idea (to put it softly) on a machine with a public address on it, and b) an indication that the issue must be within routing or the DNS process itself.