OpenDNS - Catch all DNS traffic

fastmesh · Sat Jul 02, 2011 10:56 pm

Hi!

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?

Thanks!

fewi · Sun Jul 03, 2011 12:07 am

Let's take this bit by bit - that's a lot of different questions for one post.

For DNS, set up your router to use OpenDNS and to allow remote requests so it can act as a caching DNS forwarder: http://wiki.mikrotik.com/wiki/Manual:IP/DNS

Then force all DNS traffic going through the router to use the internal forwarder, which in turn will use OpenDNS:

/ip firewall nat add chain=dstnat in-interface=LAN protocol=udp dst-port=53 action=redirect

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.

Do NOT copy the binary backup file from one router to the other.
http://wiki.mikrotik.com/wiki/Manual:Co ... escription

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.

Instead export text configuration (http://wiki.mikrotik.com/wiki/Manual:Co ... figuration), edit the file to remove information unique to the router (such as interface MAC addresses), and then paste it into the new router. The lack of good configuration management is one of the sore points about RouterOS.

steixeira · Tue Aug 09, 2011 8:19 pm

What are you redirecting here? When you use the redirect action, aren't you redirecting to another port? Do we want to do this?

andreacoppini · Wed Sep 07, 2011 5:37 pm

action=redirect actually is a redirect to self.

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)

CCDKP · Wed Sep 07, 2011 6:50 pm

You also want to add

/ip firewall nat add chain=dstnat in-interface=LAN protocol=tcp dst-port=53 action=redirect

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.

fastmesh · Mon Jan 02, 2012 1:20 am

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)

/ip firewall nat
add chain=dstnat action=dst-nat to-addresses=208.67.222.222 to-ports=53 protocol=tcp dst-port=53
add chain=dstnat action=dst-nat to-addresses=208.67.220.220 to-ports=53 protocol=udp dst-port=53

I also used:
/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

I'm wondering if it is a good idea to set allow-remote-requests to YES on a network of this size.

Thoughts?
(if opendns is configured correctly, the mikrotik will remember which sites are blocked via opendns filters right?)

andreacoppini · Mon Jan 02, 2012 1:57 am

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).

givemesam · Mon Jan 02, 2012 2:15 am

Thank you for the reply!

I thought i was missing some rules there. My understanding is quite primitive but i will catch on as i learn.

So can this be explained as either

/ip firewall nat
add chain=dstnat action=dst-nat to-addresses=208.67.222.222 to-ports=53 protocol=tcp dst-port=53
add chain=dstnat action=dst-nat to-addresses=208.67.222.222 to-ports=53 protocol=udp dst-port=53
add chain=dstnat action=dst-nat to-addresses=208.67.220.220 to-ports=53 protocol=tcp dst-port=53
add chain=dstnat action=dst-nat to-addresses=208.67.220.220 to-ports=53 protocol=udp dst-port=53

OR

/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?

Thank you!

andreacoppini · Mon Jan 02, 2012 10:24 am

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.

slimprize · Sat Jan 31, 2015 5:06 am

Hi all,

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
# NAME TYPE ACTUAL-MTU L2MTU
0 R ether1-gateway ether 1500 1598
1 RS ether2-master-local ether 1500 1598
2 S ether3-slave-local ether 1500 1598
3 RS ether4-slave-local ether 1500 1598
4 RS ether5-slave-local ether 1500 1598
5 RS wlan1 wlan 1500 2290
6 R bridge-local bridge 1500 1598
7 X ppp-out1 ppp-out
8 R pppoe-out1 pppoe-out 1480

Pranav

Caci99 · Sat Jan 31, 2015 12:31 pm

Hi all,

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
# NAME TYPE ACTUAL-MTU L2MTU
0 R ether1-gateway ether 1500 1598
1 RS ether2-master-local ether 1500 1598
2 S ether3-slave-local ether 1500 1598
3 RS ether4-slave-local ether 1500 1598
4 RS ether5-slave-local ether 1500 1598
5 RS wlan1 wlan 1500 2290
6 R bridge-local bridge 1500 1598
7 X ppp-out1 ppp-out
8 R pppoe-out1 pppoe-out 1480

Pranav

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.

/ip firewall filter
chain=input action=drop protocol=tcp in-interface=WAN dst-port=53
chain=input action=drop protocol=udp in-interface=WAN dst-port=53

slimprize · Sat Jan 31, 2015 3:08 pm

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.