Hi all,
I was wondering if anyone could maybe shed light on dns in mikrotik for me.
What is the UDP packet size and Cache Size used for? How does changing these values affect network performance and what should you use to work out the best settings you should be using?
Are the static servers different from the servers entered under dns?
When is it time to make your own dns server? 255/500/1000 clients?
many thanks
Re: DNS
As with most things, the answer is "it depends"
Packet size you can probably leave set to default without any real issues one way or another. Some DNS queries might require more data to complete, especially with a large number of entries (e.g. the root hint reply has servers a.root-servers.net .. m.root-servers.net because 13 servers was the most that would fit in a single packet with the original packet size limit.) If you use DNSSec and have lots of large queries then larger packet size might help slightly, but generally, DNS traffic isn't significant in bandwidth - mostly CPU load of servers.
The same thing holds for cache size. You can have tons and tons of users if they all ask for the same bunch of domains, facebook.com, youtube.com, etc - if they all have very different browsing habits, then it's going to require a larger cache to hold all of the data than if the same 50 or so hostnames cover 99% of your customers' activities. Cache misses will simply require the router to go out to the configured resolver and retreive the data. This can be fast or "slow" depending on how responsive the recursive resolver host is, and of course on the data being requested. If the hostnames are being requested in a domain whose servers are on the other side of the planet, then those replies are going to have a slightly noticeable latency compared to nearby servers....
As for running your own server, I'd say that it's almost never REQUIRED - google's globally anycasted public 8.8.8.8 and 8.8.6.6 addresses are pretty speedy and highly available.... but you may have other reasons, such as wanting to use RPZ to block some domains, or you may have so much DNS query traffic that having an on-net caching resolver host with several mikrotik proxy resolver caches pointing to it will take a few megs off of your upstream internet connection (that's QUITE a lot of traffic - individual instances of some of the root servers only get about a T1's worth of bandwidth (the entire collective of nodes get substantially more, obviously)
As for static DNS - if you wanted to create a hostname that's not really in public DNS, but there for your users, e.g. you wanted http://support/ to be a valid URL for your customers, you could create a static host "support" and put your web server's IP as the value. So your users whose DNS queries go to your Mikrotik can simply type "support" in their browsers to see your customer support portal.
Now that you know a little bit more about what the behaviors are going to do, you can watch for things like CPU utilization, memory utilization, etc on your routers and if DNS proxying is placing a significant percentage of system resources on the system, you'll be able to identify it and make necessary changes.
Packet size you can probably leave set to default without any real issues one way or another. Some DNS queries might require more data to complete, especially with a large number of entries (e.g. the root hint reply has servers a.root-servers.net .. m.root-servers.net because 13 servers was the most that would fit in a single packet with the original packet size limit.) If you use DNSSec and have lots of large queries then larger packet size might help slightly, but generally, DNS traffic isn't significant in bandwidth - mostly CPU load of servers.
The same thing holds for cache size. You can have tons and tons of users if they all ask for the same bunch of domains, facebook.com, youtube.com, etc - if they all have very different browsing habits, then it's going to require a larger cache to hold all of the data than if the same 50 or so hostnames cover 99% of your customers' activities. Cache misses will simply require the router to go out to the configured resolver and retreive the data. This can be fast or "slow" depending on how responsive the recursive resolver host is, and of course on the data being requested. If the hostnames are being requested in a domain whose servers are on the other side of the planet, then those replies are going to have a slightly noticeable latency compared to nearby servers....
As for running your own server, I'd say that it's almost never REQUIRED - google's globally anycasted public 8.8.8.8 and 8.8.6.6 addresses are pretty speedy and highly available.... but you may have other reasons, such as wanting to use RPZ to block some domains, or you may have so much DNS query traffic that having an on-net caching resolver host with several mikrotik proxy resolver caches pointing to it will take a few megs off of your upstream internet connection (that's QUITE a lot of traffic - individual instances of some of the root servers only get about a T1's worth of bandwidth (the entire collective of nodes get substantially more, obviously)
As for static DNS - if you wanted to create a hostname that's not really in public DNS, but there for your users, e.g. you wanted http://support/ to be a valid URL for your customers, you could create a static host "support" and put your web server's IP as the value. So your users whose DNS queries go to your Mikrotik can simply type "support" in their browsers to see your customer support portal.
Now that you know a little bit more about what the behaviors are going to do, you can watch for things like CPU utilization, memory utilization, etc on your routers and if DNS proxying is placing a significant percentage of system resources on the system, you'll be able to identify it and make necessary changes.