How can i make it so the 450G i have catches all DNS traffic and points it to our opendns account?
I know how to do it in dd-wrt with a simple command but i am new to mikrotik, and its safe to say i have a lot to learn. I have a 450G that was setup by a really great guru, but im all alone now.
So basically i dont want anyone to by able to bypass our dns. (i know that smart techies can probably find a way past it, but for 80% of the folks out there…)
Its v 3.25.
(do you know if i update it, will i need to pay a license fee? also, if i update it, will all settings stay in tact? If it doesn’t, im screwed.)
Also, i just purchased another 450G, and i am thinking i will just load the same firmware 3.25 on it and copy the backup file from the 3.25 and then make a few small changes to ips. is this a dumb idea for a mikrotik noob? If i downgrade my new one, which comes with a license, is the license backwards compatible?
Consult the NAT wiki for details on what the rule does.
Upgrading versions does NOT cost money. There are two variables about RouterOS: the license level (what can the license do, details are at http://wiki.mikrotik.com/wiki/Manual:License_levels), and the version. Changing license levels costs money. Upgrading versions does not. Upgrading should not affect the existing configuration, but make sure to take a backup beforehand. Should things go wrong you can downgrade via NetInstall and then restore your config. Since you have two routers maybe get familiar with the procedure on the spare before upgrading the configured unit. Having spares is great.
The configuration restore can be used for restoring the router’s configuration, exactly as it was at the backup creation moment, from a backup file. The restoration procedure assumes the cofiguration is restored on the same router, where the backup file was originally created, so it will create partially broken configuration if the hardware has been changed.
Any packets hitting that rule will be redirected to the router itself either on the original port (if the to-ports= field is not defined) or on the specified port (if you do specify a to-ports=xxx)
While it is true that DNS primarily uses UDP, it switches over to TCP whenever the answer is over 512 Bytes. With DNSSec deployment starting, we are seeing more and more TCP DNS requests on our networks.
Hi there!
I am the original poster on this thread, yet i have not chimed in for a year! I never got the emails. ill have to look into that.
I got a friend of mine to help me with the dns forwarder and this is what i used to configure the catch all dns. It is a bit different, so i am wondering which is more efficient from a resources point of view. (its a very busy network. average 60-80 mbps, 100 peak, 300+ users)
You’re natting tcp 53 to one server and udp 53 to another server. If both these servers are serving clients, I would recommend natting tcp and udp to BOTH servers, then use netwatch to enable/disable rules as necessary.
‘Allow remote requests’ simply enables the DNS server in routeros. If you leave it off, your clients cannot use the router as their dns server. If you turn it on, it just starts the dns server service on the router, you still need to point your clients’ dns settings to your router (or use nat redirect rules).
/ip firewall nat add chain=dstnat in-interface=LAN protocol=udp dst-port=53 action=redirect
/ip dns
set servers=208.67.222.222,208.67.220.220
set allow-remote-requests=YES
static add name=router address=192.168.5.1
is it correct to assume that with the script below, users ARE getting those dns addresses dynamically assigned, but it is not full proof unless the DNS cache is enabled via Allow-remote-requests OR permanent firewall rules on port 53?
/ip dns
set servers=208.67.222.222,208.67.220.220
set allow-remote-requests=no
static add name=router address=192.168.5.1
Im basically trying to figure out if my current set up is actually full proof at diving dns dynamically and in the event someone changes their dns to something else, they will still get forwarded to the opendns servers specified in the firewall.
Which version is less resource intensive and will provide a better over all experience when it is a very very busy network?
Yes, you are correct now. Both options will work, but:
With option A, users will always hit the top two rules, because mikrotik firewall works by matching the first rule it encounters and stops there.. Since your match rules are the same for the top two and bottom two rules (protocol=tcp\udp dst-port=53) the bottom two rules are never used, even if the first DNS server fails. You could use something fancy like net watch or the ‘Every’ firewall match rule, or you can use address lists or src-address matcher to split your clients into two groups, with some clients being redirected to the primary server, and other clients redirected to the secondary server.
With option B (which I personally prefer), you get the advantage of having a local DNS server. It caches responses, so saves bandwidth. If primary server fails it will retry the request on the secondary server. The problem with option B is that it is more resource intensive than option A. I have used it on some high bandwidth networks with no problem, but I don’t know your scenario. You will definitely want to use a high end router (rb1000 series or high end pc). Also a minor problem with option b is that you will have a single point of failure-the router. If the dns service crashes, you will need to restart the entire router to bring it back. In 9 years I’ve never had a DNS crash in routeros though.
I am trying to add the rule
/ip firewall nat
add chain=dstnat in-interface=LAN protocol=udp dst-port=53 action=redirect
I do not have an interface called lan. Here is my interface list. Do I add the rules for each LAN interface or is there a way to globally address all of them?
[admin@conShield] /interface> print
Flags: D - dynamic, X - disabled, R - running, S - slave
Just add the rule without specifying the in-interface, and then add drop rules in the firewall filter for requests coming from outside. This is a must anyway, otherwise you could be flooded with dns requests halting your router and traffic.
Thanks Toni. Your suggestion worked. I have added the drop rules as you suggested and have also incorporated the point about tcp in large dns requests that another poster has mentioned in this thread.